Hi,
I'm sending my stack of patches against geany again, this time as individual patches. Here's the full list:
[PATCH 01/19] Prevent -Wmissing-prototypes report warning when compiling a plugin
[PATCH 02/19] Add signals for project options dialog opening and closing
[PATCH 03/19] Make the project menu accessible by plugins
[PATCH 04/19] Make it possible to change project patterns by plugins
[PATCH 05/19] Don't be annoying when not necessary
[PATCH 06/19] Make it possible for plugins to change the base directory of msgwindow
[PATCH 07/19] Open the file in the msgwindow even if no linenumber is specified
[PATCH 08/19] When closing tab, return to the document at the top of the MRU list
[PATCH 09/19] Use wider entry for project file path
[PATCH 10/19] New utils function to get relative path from one directory to another
[PATCH 11/19] File name in the project settings dialog shouldn't look it is editable
[PATCH 12/19] Use relative paths in the project files
[PATCH 13/19] Remove the "set" button from the project properties dialog
[PATCH 14/19] Rewrite tab switching queue
[PATCH 15/19] Do not insert --include= when the search pattern entry is empty
[PATCH 16/19] Use project patterns in the FIF dialog
[PATCH 17/19] Make the tab switching dialog a bit more useful
[PATCH 18/19] Use standard include paths for "open selected file"
[PATCH 19/19] Use per document indent sizes
Only some of them are required by gproject - others are just suggestions for improvements. I didn't explicitly distinguish between these two types of patches but it should be pretty clear from the description. There have been some minor changes since my last post - mainly the change of the FIF dialog to contain combo box for pattern selection and there are also some new patches - the detailed description is in the individual emails. Of course many of the patches are suggestions only so further discussion is welcome.
Cheers,
Jiri
Hi folks,
I saw that the SM-branch is merged with trunk on a regular basis, but
not sure what's the current status of that branch. Can someone help me
out there?
Cheers,
Frank
--
http://frank.uvena.de/en/
On Thu, Sep 16, 2010 at 19:27, Thomas Martitz
<thomas.martitz(a)student.htw-berlin.de> wrote:
> On 16.09.2010 02:23, Lex Trotman wrote:
>>
>> Hi Jiri,
>>
>> I couldn't get this to work at all, it printed "calling indent this
>> line" all the time but didn't indent :-(
>>
>> I only had half an hour so I couldn't investigate much.
>>
>
> I have the same experience. Auto-indentation doesn't seem to work anymore
> (e.g. when hitting enter after on a line that ends with {, or when typing
> }).
I have just re-tested it again and it works on my machine (I have
forgotten one trace in the code - that's what you see in the console).
A quick question: have you read the commit log?
This patch makes it possible to specify several regex patterns for every
filetype which determine under what condition the indentation is performed.
The pattern variables are specified under the [settings] section of the
given filetype and their value is the regex to be used. The variables are
as follows:
* indent_this_line_regex - the match is performed after every keystroke
and if the regex matches, the indentation is performed on the current
line
* indent_next_line_regex - the match is performed only when enter is
pressed. The indentation is applied on the next line
* unindent_this_line_regex - like indent_this_line_regex but
unindents instead
* unindent_next_line_regex - like indent_next_line_regex but indents instead
Comments and strings are detected from the lexer so these can be ignored
inside the patterns. For instance these are very basic rules for GNU
indent style:
indent_next_line_regex=^.*\\{[[:blank:]]*$
unindent_this_line_regex=^[[:blank:]]*\\}$
indent_this_line_regex=^[[:blank:]]+\\{$
unindent_next_line_regex=^[[:blank:]]*\\}[[:blank:]]*$
By commenting-out the last two lines you get ANSI indentation style.
If you replace \\{ and \\} with begin and end, respectively, you
get analogous rules for pascal. Notice the double-escaping of { and } -
the first escape sequence is for the keyfile ini format (so for the
regex itself \\ becomes \).
This means that in order to make it work e.g. for C, you have to edit
~/.config/geany/filedefs/filetypes.c
(or the corresponding file under /usr/local/share/geany) and add
indent_next_line_regex=^.*\\{[[:blank:]]*$
unindent_this_line_regex=^[[:blank:]]*\\}$
indent_this_line_regex=^[[:blank:]]+\\{$
unindent_next_line_regex=^[[:blank:]]*\\}[[:blank:]]*$
under the [settings] section (+ restart geany). Please let me know if
it works (but also in the opposite case ;-).
Jiri
>
> Best regards.
> _______________________________________________
> Geany-devel mailing list
> Geany-devel(a)uvena.de
> http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
>
Hi,
I'm working on the Python bindings (again) and I had a simple question.
How can we know which struct members in the plugin API are supposed to
be settable vs those which should be read-only?
For example, in the GeanyDocument struct there's a member called
'readonly', which no doubt if set directly by plugin developer will not
update the read-only status of the document (ie. change GtkMenus in the
UI, tab colors, etc). Are any of the exposed struct members supposed to
be settable by the plugin developer or are they all supposed to be
read-only? In some cases in the API there are accessor functions, so
can one assume that none of the struct members should be set directly
and only ever set through an acessor function, if available? Are there
any exceptions to this, for example, some of the prefs structs?
Any hints will be much appreciated.
Cheers,
Matthew Brush
Hi All,
I have noticed Geany seems to be consuming unexpected amounts of
memory, adding and removing the same space in a C++ source file about
10-20 times seemed to consume about 100k.
I havn't been able to locate anything and have run out of time to look.
Seems to happen on Geany 0.20 and recentish SVN.
geany 0.20 (built on Jan 17 2011 with GTK 2.20.1, GLib 2.24.1, GIO)
geany 0.21 (svn >= r5688) (built on Jun 6 2011 with GTK 2.20.1, GLib
2.24.1, GIO)
On Linux Mint x86-64 no plugins in use.
Cheers
Lex
Hello folks,
has the waf install step gotten very slow for everyone, or only for me?
It takes 36s or longer here, and this laptop has an SSD.
I attach the output of the install step.
Best regards.
Hi,
You might have recognized that there have been a discussion on which
markuplangauge/technique we will use for future Geany newsletter to
write and create PDF/HTML/other output formats in.
During this discussion a lot of different languages and ways have been
suggested so decision is not easy. However, we (well, I) decided to do
it on a more democratic way by doing a poll about.
But before we are doing this poll we need to collect all possible ideas
and put some basic facts together. To do so I did create a wiki page
(please don't care about the theme for the moment as this is under
discussion inside another thread) at
http://wiki.geany.org/newsletter/markuplanguages
where I like to ask everybody to enter suggestions based on a minimal
feature list I put together you can also find at this page.
Based on that list I will create a poll upcoming weekend (around June,
4th) - I will announce tis inside another mail with some basic rules.
Cheers,
Frank
Hi folks,
I has been about two month since last release of the Geany newsletter
and even not this much happened during this time I'm planning to do a
new release by about first weekend of August so its the right moment
for you to think whether you have something interesting, which might
could be part of the next newsletter. Maybe a little how to or a new
plugin you want to introduce. Please feel free and welcome to submit
your article ;)
Cheers,
Frank
--
http://frank.uvena.de/en/
Hi,
I ran into an issue using Geany on Windows where-in using either the build
or compile
commands to kick off a custom script caused Geany to hang for about a
minute, after
which it returned and the compiler log showed only a fraction of the output
it should.
After tracking this down, it seems that on Windows, a custom spawn function
is used
in *build_spawn_cmd* and rather than *
g_spawn_async_with_pipes, utils_spawn_sync*
which ends up calling *win32_spawn*.
*win32_spawn* would set up pipes for stdout and stderr (using default buffer
size),
kick off the a child process, wait for it finish, and finally dump the
stdout/stderr pipes
to a temp file and then read that into memory. if the process didn't exit
after a minute,
it was forcefully killed.
The problem seems to be that pipes are only 4kb buffered by default, so any
process
needing to write more than this would block while writing to stdout and
Geany would
kill it, as it wasn't reading the pipes until after the process exited.
The attached patch fixes this such that the pipes are read and dumped to the
temp
file continuously as the child process runs. Now the child process will be
forcibly killed
only if it doesn't write to one of its pipes for at least 30 seconds.
Out of curiosity, why isn't *g_spawn_async_with_pipes* used on Windows? It
seems to
work with some degree of success for the grep command (as used by *
search_find_in_files*),
albeit without completion status reporting.
Regards,
Josh Pschorr