On 17 September 2010 18:28, Jiří Techet techet@gmail.com wrote:
On Fri, Sep 17, 2010 at 01:23, Lex Trotman elextr@gmail.com wrote:
On 17 September 2010 06:17, Jiří Techet techet@gmail.com wrote:
On Thu, Sep 16, 2010 at 19:27, Thomas Martitz thomas.martitz@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:]]*$
Yes, I read the instructions (rare I admit) and I copied these regexen.
I'll see if I get time to look at it some more today or tomorrow.
Note that unless you are going to add the regexes to all filetypes then Geany still needs to behave as it currently does when there is no filetype regex(es).
Currently geany only indents languages with braces (C, C++, Java, Perl, ...) and Python, so these are the only languages whose patterns have to be set.
No, the "basic" setting just indents the same as the previous line and AFAIK works in all languages including "none" so it needs to work with no regexes.
The regexes should replace both "current chars" and "match braces" settings (I think).
I think it is really best to set the patterns
per-langauge - there may be slight differences between C and Perl for example.
Agree, in fact I think one of the current problems is caused by a "fix" to accomodate a common Perl usage.
But it should be no problem to copy the patterns to the
filetype settings files that go under /usr/local/share/geany.
What I'd like to see and what I'm not sure about how to do it in a nice way is the possibility to switch between different indent styles for different projects/files. For instance I maintain a project that uses the GNU indent style while geany uses the ANSI style. Suggestions are welcome.
Ditto, I've got C++ in both GNU and Stroustrup styles, and despite my best arguments I'm not allowed to run them through a prettifier to make them all the same, and thats in ONE project :-(
To handle multiple styles, I'd have an entry in the [settings] section with a list of styles and each set of settings in its own section [indent-xxx] where xxx is the style name.
I'd recommend that method over having all the settings in the same section with each setting having the style name in its key, although thats the way I did it for build settings and it works and is OK for computers it is hard for humans and these are hand edited settings.
The styles could be added as a second section to the document-> indent type-> submenu, that would remove any need to add another top level menu entry.
Maybe a later extension would be to save the style with the filename in sessions and/or recognise some mode line in the file eg Emacs type // -*- variable:value -*- settings. There are several other things that have been suggested to be recognised like that (eg .h header files C or C++??).
Cheers Lex
Cheers,
Jiri
Cheers Lex
Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel