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:]]*$
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@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
On 16.09.2010 22:17, Jiří Techet wrote:
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?
I admit I didn't because it looked so long and I was tired :)
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 ;-).
I see. I assumed it would default to how it works in mainline.
Best regards
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).
Cheers Lex
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@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
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. I think it is really best to set the patterns per-langauge - there may be slight differences between C and Perl for example. 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.
Cheers,
Jiri
Cheers Lex
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
On Fri, Sep 17, 2010 at 11:23, Lex Trotman elextr@gmail.com wrote:
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.
But this should work with my patch as far as I can tell - if no regex exists for the given language, it just uses the same indent as on the previous line.
The regexes should replace both "current chars" and "match braces" settings (I think).
No, the regexes only decide "when" to indent and not "how much" to indent. the "current chars" method just looks at the previous line and indents the next line by +indent_size or -indent_size while the "match braces" method aligns } so that it is in the same column like the opening brace.
(However, I'm just wondering whether the "current chars" method couldn't be removed completely. The "match braces" falls back to "current chars" when it cannot be used and "match braces" is superior for languages with braces. Also the documentation doesn't really tell you the difference of these methods so the only way to realize what they do is to look at the source code.)
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.
Yes, at least something like that. But I'd also like to be able to set the indent style as a default style for a project (or globally) so I don't have to manually set it for every file I open. This is a per-filetype settings but having the option to set it for every file type in the project settings dialog would make it a bit bloated. Maybe some standard indent styles could exist so e.g. if you select "GNU style" in the project settings dialog, geany would search for [indent-gnu_style] section in the filetype settings file for each file you are using in your project.
Cheers,
Jiri
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
Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
On 18 September 2010 02:00, Jiří Techet techet@gmail.com wrote:
On Fri, Sep 17, 2010 at 11:23, Lex Trotman elextr@gmail.com wrote:
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.
But this should work with my patch as far as I can tell - if no regex exists for the given language, it just uses the same indent as on the previous line.
But only if none is not selected?
The regexes should replace both "current chars" and "match braces" settings (I think).
No, the regexes only decide "when" to indent and not "how much" to indent. the "current chars" method just looks at the previous line and indents the next line by +indent_size or -indent_size while the "match braces" method aligns } so that it is in the same column like the opening brace.
(However, I'm just wondering whether the "current chars" method couldn't be removed completely. The "match braces" falls back to "current chars" when it cannot be used and "match braces" is superior for languages with braces.
Thats what I meant by "replace them both". So +1 for this.
Also the documentation doesn't really tell
you the difference of these methods so the only way to realize what they do is to look at the source code.)
I thought the auto-indentation section of the manual said that?
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.
Yes, at least something like that. But I'd also like to be able to set the indent style as a default style for a project (or globally) so I don't have to manually set it for every file I open. This is a per-filetype settings but having the option to set it for every file type in the project settings dialog would make it a bit bloated.
Welcome to the per project per filetype build command configuration problem :-D
The build system solution of using the current file to select the filetype is, as you have pointed out in the past, potentially confusing, but the alternative is very bloating, especially since with custom filetypes you have to be able to handle an unknown number of filetypes.
So I'd have to say that, for now anyway, the way to go would be for the combo box in the project and global prefs dialogs to show only the styles from the current filetype (plus none and basic) and to only set the current filetype.
Maybe
some standard indent styles could exist so e.g. if you select "GNU style" in the project settings dialog, geany would search for [indent-gnu_style] section in the filetype settings file for each file you are using in your project.
Except for files where you have set it manually of course.
Well gnu-style is meaningless for Python, and I wouldn't expect C to have a Stroustrup style etc. so the fixed list for all filetypes is always going to be insufficient.
Cheers Lex
Cheers,
Jiri
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
Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
On Sat, Sep 18, 2010 at 01:48, Lex Trotman elextr@gmail.com wrote:
On 18 September 2010 02:00, Jiří Techet techet@gmail.com wrote:
On Fri, Sep 17, 2010 at 11:23, Lex Trotman elextr@gmail.com wrote:
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.
But this should work with my patch as far as I can tell - if no regex exists for the given language, it just uses the same indent as on the previous line.
But only if none is not selected?
The regexes should replace both "current chars" and "match braces" settings (I think).
No, the regexes only decide "when" to indent and not "how much" to indent. the "current chars" method just looks at the previous line and indents the next line by +indent_size or -indent_size while the "match braces" method aligns } so that it is in the same column like the opening brace.
(However, I'm just wondering whether the "current chars" method couldn't be removed completely. The "match braces" falls back to "current chars" when it cannot be used and "match braces" is superior for languages with braces.
Thats what I meant by "replace them both". So +1 for this.
Also the documentation doesn't really tell
you the difference of these methods so the only way to realize what they do is to look at the source code.)
I thought the auto-indentation section of the manual said that?
You are right - next time I really have to look at the manual instead of relying on my poor brain.
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.
Yes, at least something like that. But I'd also like to be able to set the indent style as a default style for a project (or globally) so I don't have to manually set it for every file I open. This is a per-filetype settings but having the option to set it for every file type in the project settings dialog would make it a bit bloated.
Welcome to the per project per filetype build command configuration problem :-D
Exactly what I want to avoid ;-).
The build system solution of using the current file to select the filetype is, as you have pointed out in the past, potentially confusing, but the alternative is very bloating, especially since with custom filetypes you have to be able to handle an unknown number of filetypes.
So I'd have to say that, for now anyway, the way to go would be for the combo box in the project and global prefs dialogs to show only the styles from the current filetype (plus none and basic) and to only set the current filetype.
If it's for the current filetype only, then I would just copy the most confusing part of the per-filetype settings - I definitely don't want to do it this way.
Maybe
some standard indent styles could exist so e.g. if you select "GNU style" in the project settings dialog, geany would search for [indent-gnu_style] section in the filetype settings file for each file you are using in your project.
Except for files where you have set it manually of course.
Well gnu-style is meaningless for Python, and I wouldn't expect C to have a Stroustrup style etc. so the fixed list for all filetypes is always going to be insufficient.
OK, another idea. There would be a global and per-project "preferred indent style" option containing the standard styles. Every filetype would have its own default style and arbitrary number of additional styles. If one of the styles matches the "preferred indent style", this style will be used. Otherwise the default style will be used. So for python, which has basically one style only, this single style will be always used no matter what the preferred style is.
Finally, the document menu would have a submenu with all indent styles for the document's filetype. This is IMO the only place which you expect to be per-filetype.
Cheers,
Jiri
Cheers Lex
Cheers,
Jiri
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
Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Welcome to the per project per filetype build command configuration problem :-D
Exactly what I want to avoid ;-).
Ditto :-)
The build system solution of using the current file to select the filetype is, as you have pointed out in the past, potentially confusing, but the alternative is very bloating, especially since with custom filetypes you have to be able to handle an unknown number of filetypes.
So I'd have to say that, for now anyway, the way to go would be for the combo box in the project and global prefs dialogs to show only the styles from the current filetype (plus none and basic) and to only set the current filetype.
If it's for the current filetype only, then I would just copy the most confusing part of the per-filetype settings - I definitely don't want to do it this way.
Maybe
some standard indent styles could exist so e.g. if you select "GNU style" in the project settings dialog, geany would search for [indent-gnu_style] section in the filetype settings file for each file you are using in your project.
Except for files where you have set it manually of course.
Well gnu-style is meaningless for Python, and I wouldn't expect C to have a Stroustrup style etc. so the fixed list for all filetypes is always going to be insufficient.
OK, another idea. There would be a global and per-project "preferred indent style" option containing the standard styles.
What are the standard styles and where are they defined?
Every filetype
would have its own default style and arbitrary number of additional styles.
Are these hand edited in the filetypes files? (Personally I don't think there is anything wrong with saying they are manually edited in the filetype files)
If one of the styles matches the "preferred indent style",
this style will be used. Otherwise the default style will be used.
This is still only ever going to be right for one language because only one will match, might as well just use the default from the filetype file..
So
for python, which has basically one style only, this single style will be always used no matter what the preferred style is.
Yep, Python is an exception since the indent style is part of the language syntax so there isn't any choice, but the bracketed languages have several options and they don't overlap much (I'm no Java style expert but as I understand it the default is different to GNU and ANSI but probably closest to Stroustrup, and Perl has no style :-)
Finally, the document menu would have a submenu with all indent styles for the document's filetype. This is IMO the only place which you expect to be per-filetype.
Yes.
Please note that my expectations for indenting may be a bit high because I am forced to use Emacs for work at the moment and the indenting works really well (for C/C++ anyway) but is much more complex.
Have you given any thought to if there is a regex that would indent continuation lines (eg ending in comma) but for that line only. IIUC Jedit has a regex that indents only the next line without incrementing the indent level.
Cheers Lex
Cheers,
Jiri
Cheers Lex
Cheers,
Jiri
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
Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
On Wed, Sep 22, 2010 at 14:06, Lex Trotman elextr@gmail.com wrote:
Welcome to the per project per filetype build command configuration problem :-D
Exactly what I want to avoid ;-).
Ditto :-)
The build system solution of using the current file to select the filetype is, as you have pointed out in the past, potentially confusing, but the alternative is very bloating, especially since with custom filetypes you have to be able to handle an unknown number of filetypes.
So I'd have to say that, for now anyway, the way to go would be for the combo box in the project and global prefs dialogs to show only the styles from the current filetype (plus none and basic) and to only set the current filetype.
If it's for the current filetype only, then I would just copy the most confusing part of the per-filetype settings - I definitely don't want to do it this way.
Maybe
some standard indent styles could exist so e.g. if you select "GNU style" in the project settings dialog, geany would search for [indent-gnu_style] section in the filetype settings file for each file you are using in your project.
Except for files where you have set it manually of course.
Well gnu-style is meaningless for Python, and I wouldn't expect C to have a Stroustrup style etc. so the fixed list for all filetypes is always going to be insufficient.
OK, another idea. There would be a global and per-project "preferred indent style" option containing the standard styles.
What are the standard styles and where are they defined?
There would be a list of styles e.g. in geany.conf, for instance something like this:
preferred_style_list=GNU style;ANSI style; K&R style
Just a list of names that would be used to populate the "preferred indent style" combo. The styles themselves would then be defined in individual filetypes and based on the style name match with the preferred style, either the default or the matching style would be used.
Every filetype
would have its own default style and arbitrary number of additional styles.
Are these hand edited in the filetypes files? (Personally I don't think there is anything wrong with saying they are manually edited in the filetype files)
Yes, the GUI for that would be too bloated.
If one of the styles matches the "preferred indent style",
this style will be used. Otherwise the default style will be used.
This is still only ever going to be right for one language because only one will match, might as well just use the default from the filetype file..
So
for python, which has basically one style only, this single style will be always used no matter what the preferred style is.
Yep, Python is an exception since the indent style is part of the language syntax so there isn't any choice, but the bracketed languages have several options and they don't overlap much (I'm no Java style expert but as I understand it the default is different to GNU and ANSI but probably closest to Stroustrup, and Perl has no style :-)
Depends what you want to indent. If we are talking only about indentation after braces (or, in general, begin and end block markers), I think C is a superset of all styles. Of course there are millions of variants like whether to indent public:, private:, ..., case: in switch and so on, but Geany shouldn't do that (of course if someone decides to write his own regexes, he can) because this is really very individual. So the basic set of indent styles is quite limited and can be applied to non-brace langauges as well (I think all the C styles make sense for pascal as well).
In general I think indenting less is better than indenting more - it's not such a big problem to press tab in special cases when the text doesn't get indented automatically.
Finally, the document menu would have a submenu with all indent styles for the document's filetype. This is IMO the only place which you expect to be per-filetype.
Yes.
Please note that my expectations for indenting may be a bit high because I am forced to use Emacs for work at the moment and the indenting works really well (for C/C++ anyway) but is much more complex.
Have you given any thought to if there is a regex that would indent continuation lines (eg ending in comma) but for that line only. IIUC Jedit has a regex that indents only the next line without incrementing the indent level.
I'm afraid that detecting such cases with regexes would be much harder - braces are quite unique but commas are much more overloaded. Also there are too many different options how much to indent - fized size, aligned after = in assignments, behind the latest opening brace and so on. These are almost impossible to do in a more generic way and would force the users to use some very specific style. As I said, indenting less is better IMO for a multipurpose editor like geany.
Jiri
Cheers Lex
Cheers,
Jiri
Cheers Lex
Cheers,
Jiri
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
Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
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:]]*$
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
Hi Jiri,
Got it working, I'd put the regexes in the filetypes in the wrong prefix, my mistake :-D
But it doesn't seem to be working as expected.
Using only the first two of your regexes the following gets:
class foo { struct bar { int i; }; }
fair enough, the } regex doesn't expect anything after it so I added .* after the } but now I get
class foo { struct bar { int i; }; }
The }; line undents two levels??
Cheers Lex
Best regards. _______________________________________________ Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Hi Jiri,
Got it working, I'd put the regexes in the filetypes in the wrong prefix, my mistake :-D
But it doesn't seem to be working as expected.
Using only the first two of your regexes the following gets:
class foo { struct bar { int i; }; }
fair enough, the } regex doesn't expect anything after it so I added .* after the } but now I get
class foo { struct bar { int i; }; }
The }; line undents two levels??
Cheers Lex
Another problem I found, if a comment line ends in { then the next line indents when it shouldn't
Cheers Lex
Best regards. _______________________________________________ Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
On Tue, Sep 21, 2010 at 03:10, Lex Trotman elextr@gmail.com wrote:
Hi Jiri,
Got it working, I'd put the regexes in the filetypes in the wrong prefix, my mistake :-D
But it doesn't seem to be working as expected.
Using only the first two of your regexes the following gets:
class foo { struct bar { int i; }; }
fair enough, the } regex doesn't expect anything after it so I added .* after the } but now I get
class foo { struct bar { int i; }; }
The }; line undents two levels??
Cheers Lex
Another problem I found, if a comment line ends in { then the next line indents when it shouldn't
Yes, this is a bug - I check whether I'm in a comment or in a string, but when enter is pressed, I should check the previous line as well. Should be easy to fix. Thanks for noticing.
Jiri
Cheers Lex
Hi Lex,
On Tue, Sep 21, 2010 at 02:41, Lex Trotman elextr@gmail.com wrote:
Hi Jiri,
Got it working, I'd put the regexes in the filetypes in the wrong prefix, my mistake :-D
But it doesn't seem to be working as expected.
Using only the first two of your regexes the following gets:
class foo { struct bar { int i; }; }
This works for me - if you press }, it should get unindented. How did you enter the code (copy-paste or something like that)?
fair enough, the } regex doesn't expect anything after it so I added .* after the } but now I get
class foo { struct bar { int i; }; }
The }; line undents two levels??
Your regex is not correct - the (un)indent_this_line_regex is evaluated every time you press a key and if it is satisfied, the current line gets (un)indented. So with ^[[:blank:]]*\}.*$ you used, the regex first matches
}
and after you type ";", it again matches
};
so it unindents twice. This means the last character in the regex should be the one that causes the change of indentation "}" in this case.
Cheers,
Jiri
Cheers Lex
On 22 September 2010 20:47, Jiří Techet techet@gmail.com wrote:
Hi Lex,
On Tue, Sep 21, 2010 at 02:41, Lex Trotman elextr@gmail.com wrote:
Hi Jiri,
Got it working, I'd put the regexes in the filetypes in the wrong prefix, my mistake :-D
But it doesn't seem to be working as expected.
Using only the first two of your regexes the following gets:
class foo { struct bar { int i; }; }
This works for me - if you press }, it should get unindented. How did you enter the code (copy-paste or something like that)?
No, I just typed it in order from the first character to the last }. Note that the } before did undent correctly. Any suggestions what to look at?
fair enough, the } regex doesn't expect anything after it so I added .* after the } but now I get
class foo { struct bar { int i; }; }
The }; line undents two levels??
Your regex is not correct - the (un)indent_this_line_regex is evaluated every time you press a key and if it is satisfied, the current line gets (un)indented. So with ^[[:blank:]]*\}.*$ you used, the regex first matches
}
and after you type ";", it again matches
};
so it unindents twice. This means the last character in the regex should be the one that causes the change of indentation "}" in this case.
Ok, so the previous has to be made to work.
Cheers Lex
Cheers,
Jiri
Cheers Lex
Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
On Wed, Sep 22, 2010 at 13:47, Lex Trotman elextr@gmail.com wrote:
On 22 September 2010 20:47, Jiří Techet techet@gmail.com wrote:
Hi Lex,
On Tue, Sep 21, 2010 at 02:41, Lex Trotman elextr@gmail.com wrote:
Hi Jiri,
Got it working, I'd put the regexes in the filetypes in the wrong prefix, my mistake :-D
But it doesn't seem to be working as expected.
Using only the first two of your regexes the following gets:
class foo { struct bar { int i; }; }
This works for me - if you press }, it should get unindented. How did you enter the code (copy-paste or something like that)?
No, I just typed it in order from the first character to the last }. Note that the } before did undent correctly. Any suggestions what to look at?
Hmm. Do you use "current chars" or "match braces" method? I use "match braces" normally and I haven't tested "current chars" so much so there might be some bugs. Also what line endings does your document have? I had some problems with matching lines containing CRLF because CR remained at the end of line and the pattern never matched. But this one should be fixed. No more ideas right now.
Jiri
On 22 September 2010 21:57, Jiří Techet techet@gmail.com wrote:
On Wed, Sep 22, 2010 at 13:47, Lex Trotman elextr@gmail.com wrote:
On 22 September 2010 20:47, Jiří Techet techet@gmail.com wrote:
Hi Lex,
On Tue, Sep 21, 2010 at 02:41, Lex Trotman elextr@gmail.com wrote:
Hi Jiri,
Got it working, I'd put the regexes in the filetypes in the wrong prefix, my mistake :-D
But it doesn't seem to be working as expected.
Using only the first two of your regexes the following gets:
class foo { struct bar { int i; }; }
This works for me - if you press }, it should get unindented. How did you enter the code (copy-paste or something like that)?
No, I just typed it in order from the first character to the last }. Note that the } before did undent correctly. Any suggestions what to look at?
Hmm. Do you use "current chars" or "match braces" method?
Match braces.
I use "match
braces" normally and I haven't tested "current chars" so much so there might be some bugs.
Like we both said previously, should replace "current chars" and "match braces" with "use regexes"
Also what line endings does your document have?
Normal Linux doc, \n I saved an empty .c file and then typed into it.
Cheers Lex
I
had some problems with matching lines containing CRLF because CR remained at the end of line and the pattern never matched. But this one should be fixed. No more ideas right now.
Jiri _______________________________________________ Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
But it doesn't seem to be working as expected.
Using only the first two of your regexes the following gets:
class foo { struct bar { int i; }; }
This works for me - if you press }, it should get unindented. How did you enter the code (copy-paste or something like that)?
No, I just typed it in order from the first character to the last }. Note that the } before did undent correctly. Any suggestions what to look at?
fair enough, the } regex doesn't expect anything after it so I added .* after the } but now I get
class foo { struct bar { int i; }; }
The }; line undents two levels??
Your regex is not correct - the (un)indent_this_line_regex is evaluated every time you press a key and if it is satisfied, the current line gets (un)indented. So with ^[[:blank:]]*\}.*$ you used, the regex first matches
}
and after you type ";", it again matches
};
so it unindents twice. This means the last character in the regex should be the one that causes the change of indentation "}" in this case.
Ok, so the previous has to be made to work.
Cheers Lex
Cheers,
Jiri
Hi Jiri,
Have you had any further thoughts?
Cheers Lex
Cheers Lex
Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
On Tue, Oct 26, 2010 at 03:29, Lex Trotman elextr@gmail.com wrote:
But it doesn't seem to be working as expected.
Using only the first two of your regexes the following gets:
class foo { struct bar { int i; }; }
This works for me - if you press }, it should get unindented. How did you enter the code (copy-paste or something like that)?
No, I just typed it in order from the first character to the last }. Note that the } before did undent correctly. Any suggestions what to look at?
fair enough, the } regex doesn't expect anything after it so I added .* after the } but now I get
class foo { struct bar { int i; }; }
The }; line undents two levels??
Your regex is not correct - the (un)indent_this_line_regex is evaluated every time you press a key and if it is satisfied, the current line gets (un)indented. So with ^[[:blank:]]*\}.*$ you used, the regex first matches
}
and after you type ";", it again matches
};
so it unindents twice. This means the last character in the regex should be the one that causes the change of indentation "}" in this case.
Ok, so the previous has to be made to work.
Cheers Lex
Cheers,
Jiri
Hi Jiri,
Have you had any further thoughts?
Cheers Lex
Hi Lex,
I have been pretty busy lately so I didn't spend any time looking into this. I'm afraid this will be the case for the following month or so, so until then I won't have much time for any Geany-hacking.
Cheers,
Jiri
Hi Lex,
I have been pretty busy lately so I didn't spend any time looking into this. I'm afraid this will be the case for the following month or so, so until then I won't have much time for any Geany-hacking.
Cheers,
Jiri
Hi Jiri,
Totally understand, I am just coming out of a similar period myself. Hear from you then.
Cheers Lex
Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Hi,
I know this is a more than one year old discussion, but I was messing with a very similar thing a few minutes ago when wanting to add autoindent support for SH.
Le 16/09/2010 22:17, Jiří Techet a écrit :
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 butunindents 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 ;-).
First, note that I wasn't able to find the patch, so I'm only guessing from reading the thread and from my own (much less complete) attempt.
So. This looks pretty good for line-based indents (but not brace match :(), but I ran into a really annoying problem with SH:
SH should indent after "then", "do", etc. and unindent "fi", "esac", etc. The problem is that you expect the "fi" line to be unindented (e.g. use unindent_this_line), but if you type "file" for example, it'd wrongly unindent that line too!
I thought about unindenting the previous line when entering the \n, but this isn't a real solution either since re-adding a newline after a well indented line would unindent it again. Crap.
So I haven't yet found a sensible solution for this problem -- which wouldn't apply for '}' since it's very unlikely it's part of a bigger word -- and would like to know it anybody got super clever ideas, or how other editors you know handle this.
This said, I really like the idea of configurable indentation rules that could handle languages like SH, Pascal, Ruby, Ada, etc. without the need to hard-code it.
Regards, Colomban
On Mon, Dec 5, 2011 at 19:30, Colomban Wendling lists.ban@herbesfolles.org wrote:
Hi,
I know this is a more than one year old discussion, but I was messing with a very similar thing a few minutes ago when wanting to add autoindent support for SH.
Le 16/09/2010 22:17, Jiří Techet a écrit :
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:]]*$
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 ;-).
First, note that I wasn't able to find the patch, so I'm only guessing from reading the thread and from my own (much less complete) attempt.
It doesn't apply to current trunk anyway - I've discarded it because it would need major update but more importantly, there was one limitation I wanted to address.
The problem was that a single line could be indented several times with single regular expression. Imagine a code like
if (foo) { ....if (bar) ....{ ........baz(); ....} }
Now imagine that you put cursor just behind the } following baz(); and press backspace to delete it. Now if you press } at this position again, it gets unindented again so you get
if (foo) { ....if (bar) ....{ ........baz(); } }
From the editors I tested, it seems they remember for which line
indentation was performed and don't perform it again. This means to have some per-line flag which indicates this state (e.g. NOT_INDENTABLE, INDENTABLE). When a file is loaded, all non-empty lines would be marked as NOT_INDENTABLE and every empty line as INDENTABLE (the newly created empty lines too). A line would stay in INDENTABLE state even after you start typing some text. INDENTABLE state would change to NOT_INDENTABLE under each of the following conditions:
1. The line matches a regex - in this case is indented and shouldn't be indented any more 2. The line is not empty, matches a regex and enter is pressed (you have finished editing the line and don't want it to be indented when you modify it later)
Now this approach requires some per-line data to be stored - is it possible with Scintilla?
So. This looks pretty good for line-based indents (but not brace match :(), but I ran into a really annoying problem with SH:
SH should indent after "then", "do", etc. and unindent "fi", "esac", etc. The problem is that you expect the "fi" line to be unindented (e.g. use unindent_this_line), but if you type "file" for example, it'd wrongly unindent that line too!
I thought about unindenting the previous line when entering the \n, but this isn't a real solution either since re-adding a newline after a well indented line would unindent it again. Crap.
So I haven't yet found a sensible solution for this problem -- which wouldn't apply for '}' since it's very unlikely it's part of a bigger word -- and would like to know it anybody got super clever ideas, or how other editors you know handle this.
So I've just tried TextMate and it has failed in the same way.
But I think it could be solved by introducing one more flag - INDENTED. When you are on an INDENTABLE line and it matches a regex, it would be indented and its flag would be changed to INDENTED. Now the difference is that for INDENTED lines the regex would be re-evaluated every time you type a letter and if it stops matching, the indent would be undone and INDENTED state would be changed back to INDENTABLE. For completeness, I think also UNINDENTED state would have to be introduced to perform the right undo action for the unindent regex.
This said, I really like the idea of configurable indentation rules that could handle languages like SH, Pascal, Ruby, Ada, etc. without the need to hard-code it.
Would be great if someone has time to implement it ;-).
Cheers, Jiri
[...]
First, note that I wasn't able to find the patch, so I'm only guessing from reading the thread and from my own (much less complete) attempt.
I'm afraid that if I had the patch it is on my broken hard drive :-S
And anyway we never got it to work satisfactorily.
So. This looks pretty good for line-based indents (but not brace match :(), but I ran into a really annoying problem with SH:
SH should indent after "then", "do", etc. and unindent "fi", "esac", etc. The problem is that you expect the "fi" line to be unindented (e.g. use unindent_this_line), but if you type "file" for example, it'd wrongly unindent that line too!
I thought about unindenting the previous line when entering the \n, but this isn't a real solution either since re-adding a newline after a well indented line would unindent it again. Crap.
So I haven't yet found a sensible solution for this problem -- which wouldn't apply for '}' since it's very unlikely it's part of a bigger word -- and would like to know it anybody got super clever ideas, or how other editors you know handle this.
This said, I really like the idea of configurable indentation rules that could handle languages like SH, Pascal, Ruby, Ada, etc. without the need to hard-code it.
WARNING, complex topic, big post :)
Quick summary of ones I know:
Emacs has language specific elisp, for C:
"It analyzes the line to determine its syntactic symbol(s) (the kind of language construct it's looking at) and its anchor position (the position earlier in the file that CC Mode will indent the line relative to). The anchor position might be the location of an opening brace in the previous line, for example. See Syntactic Analysis. It looks up the syntactic symbol(s) in the configuration to get the corresponding offset(s). The symbol +, which means “indent this line one more level” is a typical offset. CC Mode then applies these offset(s) to the anchor position, giving the indentation for the line. The different sorts of offsets are described in c-offsets-alist. "
And it admits that even then it gets it wrong sometimes :(
Eclipse and Netbeans also use parser results for the indent guidance.
I don't think parsing the source for indent guidance is in the Geany light and small spirit, so I reject that.
Instead I propose the following "correct most of the time" but simple option based on a combination of Jiri's and Emacs' methods:
1. Each line N has an initial indentation which is the indentation of line N-1 plus the increments/decrements for all matches to "indent next line" regexes that occur in liine N-1. (Note that each regex has a signed count of columns to indent/exdent)
2. The line N final indentation is the initial indentation adjusted by the increments/decrements for all matches to "indent this line" regexes that occur in line N
Note that this is the indent, not a delta like Jiri's algorithm. It is therefore stable no matter how many times it is calculated.
The question is then when to calculate and apply this indent, clearly when a line is first created by enter the indent should be applied.
But what about when line content changes? Should we:
1. calculate the indent each change, and then ripple that through the file 2. calculate the indent each change and only apply it to this line 3. calculate and apply the indent to lines N and N-1 only on new line or user command 4. calculate and apply the indent on user command
Option 1 is rejected because it is expensive and it will destroy manually adjusted indentation when editing an existing line and because indentation can change as you type causing distracting effects (happens with some Emacs indentation styles)
Option 2 is rejected for the same reasons
Option 4 is rejected because auto new line indent is really the minimum required to be called "auto" indentation
So that leaves option 3. The upside is that new lines get a sensible indentation automatically, the downside is that lines that should be unindented won't be until enter or user command. I have used another editor that worked this way and after a while I became used to it. Note that editing an existing line won't destroy manual indentation unless you tell it to or create a new line after.
The settings are two ("indent this line", "indent next line") lists of pairs of a regex and a signed count.
These settings are per language so they should come from the filetype files.
A final thought, as there is now an "apply auto indent" command, if there is a selection the auto indent should ripple through the whole selection.
Cheers Lex
Regards, Colomban _______________________________________________ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
- calculate the indent each change, and then ripple that through the file
- calculate the indent each change and only apply it to this line
- calculate and apply the indent to lines N and N-1 only on new line
or user command 4. calculate and apply the indent on user command
Option 1 is rejected because it is expensive and it will destroy manually adjusted indentation when editing an existing line and because indentation can change as you type causing distracting effects (happens with some Emacs indentation styles)
Option 2 is rejected for the same reasons
Option 4 is rejected because auto new line indent is really the minimum required to be called "auto" indentation
So that leaves option 3. The upside is that new lines get a sensible indentation automatically, the downside is that lines that should be unindented won't be until enter or user command. I have used another editor that worked this way and after a while I became used to it. Note that editing an existing line won't destroy manual indentation unless you tell it to or create a new line after.
Hello,
Good auto-indentation is one of the last things I'm missing after my switch from Gedit to Geany. It was something that was handled really well by the 'Smart Indent' plugin. I would like to share a short video (1:24) of the indentation behavior that I grew accustomed to:
This style of auto-indentation requires Option 1 or 2 (calculate for each change), because it unindents the 'end', 'elsif' and 'else' keywords as soon as their last characters are pressed. I did find this behavior very useful, even though I admit that it would sometimes destroy my manual indentation.
You might also find it interesting to browse the code of this plugin here:
https://github.com/gmate/gmate/blob/master/plugins/gedit2/smart_indent/smart...
At least, it contains some good indent regexs for different languages.
I might disagree that Options 1 & 2 are expensive. The gedit plugin even defines a very limited set of 'unindent_keystrokes', so the 'unindent' regex is only executed when one of these keys are pressed. For C, it's just ":", and for Ruby, it's "edfn". I also disagree that it's distracting, because I grew accustomed to it very quickly.
So if it could be written in a way that supports the behavior in the video above, I would be really grateful. But no problem if not -- like you say, I can get used to any behavior after using it for a while.
Thanks very much for your time! Nathan B
[...]
This style of auto-indentation requires Option 1 or 2 (calculate for each change), because it unindents the 'end', 'elsif' and 'else' keywords as soon as their last characters are pressed. I did find this behavior very useful, even though I admit that it would sometimes destroy my manual indentation.
Actually the plugin is option 3, It is return plus user activated, just some activations are normal keys. Maybe it works for Ruby, but it doesn't for C, and after looking at the code I don't see how it can possibly generate GNU style indentation.
if (blah) { bletch(); }
It certainly doesn't as configured, it generates
if (blah) { bletch(); }
and doesn't seem to ever lose that indent?
[...]
Cheers Lex
Actually the plugin is option 3, It is return plus user activated, just some activations are normal keys.
Aha, I understand. Thanks for the explanation.
Maybe it works for Ruby, but it doesn't for C, and after looking at the code I don't see how it can possibly generate GNU style indentation.
if (blah) { bletch(); }
It certainly doesn't as configured, it generates
if (blah) { bletch(); }
and doesn't seem to ever lose that indent?
You're right, that plugin seems to generate K&R, 1TBS or BSD KNF style indentation, and not GNU style by default - see http://en.wikipedia.org/wiki/Indent_style
However, I think it would be appropriate to support each of these popular indentation styles, and allow the user to select which style to use. Even better, perhaps the style could be auto-detected by parsing the current file.
Regards, Nathan
On Tue, Dec 6, 2011 at 08:27, Nathan Broadbent nathan.f77@gmail.com wrote:
- calculate the indent each change, and then ripple that through the file
- calculate the indent each change and only apply it to this line
- calculate and apply the indent to lines N and N-1 only on new line
or user command 4. calculate and apply the indent on user command
Option 1 is rejected because it is expensive and it will destroy manually adjusted indentation when editing an existing line and because indentation can change as you type causing distracting effects (happens with some Emacs indentation styles)
Option 2 is rejected for the same reasons
Option 4 is rejected because auto new line indent is really the minimum required to be called "auto" indentation
So that leaves option 3. The upside is that new lines get a sensible indentation automatically, the downside is that lines that should be unindented won't be until enter or user command. I have used another editor that worked this way and after a while I became used to it. Note that editing an existing line won't destroy manual indentation unless you tell it to or create a new line after.
Hello,
Good auto-indentation is one of the last things I'm missing after my switch from Gedit to Geany. It was something that was handled really well by the 'Smart Indent' plugin. I would like to share a short video (1:24) of the indentation behavior that I grew accustomed to:
This style of auto-indentation requires Option 1 or 2 (calculate for each change), because it unindents the 'end', 'elsif' and 'else' keywords as soon as their last characters are pressed. I did find this behavior very useful, even though I admit that it would sometimes destroy my manual indentation.
This is exactly what my regex-based indentation did and I assume what Colomban's experiment does too. The problem Colomban was trying to resolve was what to do when you have an end-block keyword "fi" which should unindent and then have an identifier "file" (notice the "fi" prefix) which shouldn't unindent. In this case there should be some "undo indent" when you add more letters after "fi".
Cheers, Jiri
[...]
This is exactly what my regex-based indentation did and I assume what Colomban's experiment does too. The problem Colomban was trying to resolve was what to do when you have an end-block keyword "fi" which should unindent and then have an identifier "file" (notice the "fi" prefix) which shouldn't unindent. In this case there should be some "undo indent" when you add more letters after "fi".
And that is why I chose the option for auto indentation to only be executed on return or when the user said to, then you know the word is finished.
Cheers Lex
On Tue, Dec 6, 2011 at 07:20, Lex Trotman elextr@gmail.com wrote:
[...]
First, note that I wasn't able to find the patch, so I'm only guessing from reading the thread and from my own (much less complete) attempt.
I'm afraid that if I had the patch it is on my broken hard drive :-S
And anyway we never got it to work satisfactorily.
So. This looks pretty good for line-based indents (but not brace match :(), but I ran into a really annoying problem with SH:
SH should indent after "then", "do", etc. and unindent "fi", "esac", etc. The problem is that you expect the "fi" line to be unindented (e.g. use unindent_this_line), but if you type "file" for example, it'd wrongly unindent that line too!
I thought about unindenting the previous line when entering the \n, but this isn't a real solution either since re-adding a newline after a well indented line would unindent it again. Crap.
So I haven't yet found a sensible solution for this problem -- which wouldn't apply for '}' since it's very unlikely it's part of a bigger word -- and would like to know it anybody got super clever ideas, or how other editors you know handle this.
This said, I really like the idea of configurable indentation rules that could handle languages like SH, Pascal, Ruby, Ada, etc. without the need to hard-code it.
WARNING, complex topic, big post :)
Quick summary of ones I know:
Emacs has language specific elisp, for C:
"It analyzes the line to determine its syntactic symbol(s) (the kind of language construct it's looking at) and its anchor position (the position earlier in the file that CC Mode will indent the line relative to). The anchor position might be the location of an opening brace in the previous line, for example. See Syntactic Analysis. It looks up the syntactic symbol(s) in the configuration to get the corresponding offset(s). The symbol +, which means “indent this line one more level” is a typical offset. CC Mode then applies these offset(s) to the anchor position, giving the indentation for the line. The different sorts of offsets are described in c-offsets-alist. "
And it admits that even then it gets it wrong sometimes :(
Eclipse and Netbeans also use parser results for the indent guidance.
I don't think parsing the source for indent guidance is in the Geany light and small spirit, so I reject that.
Instead I propose the following "correct most of the time" but simple option based on a combination of Jiri's and Emacs' methods:
- Each line N has an initial indentation which is the indentation of
line N-1 plus the increments/decrements for all matches to "indent next line" regexes that occur in liine N-1. (Note that each regex has a signed count of columns to indent/exdent)
Maybe I don't understand it correctly but does this mean that if you open an existing file, you'd re-indent it completely based on the regexes? I don't think this is a good idea because this could lead to whitespace change in every line when you edit just a single line.
Or does it mean to have these indent numbers just internally and use them only when when auto-indentation is done? I often work with files edited by many people over many years which have inconsistent indents. Imagine the correct indent size is 4 but someone used just 2 indents in the outer "if" block. If I insert new "if" inside this block, the indent size will be 6 because of the incorrect outer indent. This is exactly why I used the "delta" indent solution to be locally correct and have minimal impact on (and be minimally affected by) the rest of the code.
One more thing - with global indents you have to be sure that the regexes catch all the indentation cases (without false positives) otherwise one error will affect the indentation everywhere in the rest of the file. You can do crazy stuff with some languages so I can imagine such a thing can happen easily (single line with end of multi-line comment followed by end block followed by another comment). With delta indentation it's much less critical - the indent may be incorrect for the next line but this won't affect the rest of the file in any negative way. Moreover, you usually don't do things like the comment example when you write the code and when you need auto-indentation; you usually add them afterwards when no autoindentation is needed.
Final remark - better not to auto-indent at all than to indent incorrectly. There's nothing worse than an editor (actually anything) which tries to be smart in an annoying way.
Cheers, Jiri
[...]
Maybe I don't understand it correctly but does this mean that if you open an existing file, you'd re-indent it completely based on the regexes? I don't think this is a good idea because this could lead to whitespace change in every line when you edit just a single line.
No, thats another reason why I rejected option 1
Or does it mean to have these indent numbers just internally and use them only when when auto-indentation is done? I often work with files edited by many people over many years which have inconsistent indents. Imagine the correct indent size is 4 but someone used just 2 indents in the outer "if" block. If I insert new "if" inside this block, the indent size will be 6 because of the incorrect outer indent. This is exactly why I used the "delta" indent solution to be locally correct and have minimal impact on (and be minimally affected by) the rest of the code.
The algorithm will give 6 since it only considers the previous line and the line it is indenting which is the line with the cursor.
One more thing - with global indents you have to be sure that the regexes catch all the indentation cases (without false positives) otherwise one error will affect the indentation everywhere in the rest of the file. You can do crazy stuff with some languages so I can imagine such a thing can happen easily (single line with end of multi-line comment followed by end block followed by another comment). With delta indentation it's much less critical - the indent may be incorrect for the next line but this won't affect the rest of the file in any negative way. Moreover, you usually don't do things like the comment example when you write the code and when you need auto-indentation; you usually add them afterwards when no autoindentation is needed.
Final remark - better not to auto-indent at all than to indent incorrectly. There's nothing worse than an editor (actually anything) which tries to be smart in an annoying way.
Don't worry there is no intention that auto-indentation does more than give a mostly right indent on new lines and mostly correct it when you type } on that new line.
I did clearly say it should not change any manual indentation.
Cheers Lex
On Tue, Dec 6, 2011 at 21:56, Lex Trotman elextr@gmail.com wrote:
[...]
Maybe I don't understand it correctly but does this mean that if you open an existing file, you'd re-indent it completely based on the regexes? I don't think this is a good idea because this could lead to whitespace change in every line when you edit just a single line.
No, thats another reason why I rejected option 1
Or does it mean to have these indent numbers just internally and use them only when when auto-indentation is done? I often work with files edited by many people over many years which have inconsistent indents. Imagine the correct indent size is 4 but someone used just 2 indents in the outer "if" block. If I insert new "if" inside this block, the indent size will be 6 because of the incorrect outer indent. This is exactly why I used the "delta" indent solution to be locally correct and have minimal impact on (and be minimally affected by) the rest of the code.
The algorithm will give 6 since it only considers the previous line and the line it is indenting which is the line with the cursor.
One more thing - with global indents you have to be sure that the regexes catch all the indentation cases (without false positives) otherwise one error will affect the indentation everywhere in the rest of the file. You can do crazy stuff with some languages so I can imagine such a thing can happen easily (single line with end of multi-line comment followed by end block followed by another comment). With delta indentation it's much less critical - the indent may be incorrect for the next line but this won't affect the rest of the file in any negative way. Moreover, you usually don't do things like the comment example when you write the code and when you need auto-indentation; you usually add them afterwards when no autoindentation is needed.
Final remark - better not to auto-indent at all than to indent incorrectly. There's nothing worse than an editor (actually anything) which tries to be smart in an annoying way.
Don't worry there is no intention that auto-indentation does more than give a mostly right indent on new lines and mostly correct it when you type } on that new line.
I did clearly say it should not change any manual indentation.
Ah, sorry, after re-reading it again I think I misunderstood your algorithm originally so please forget what I said.
What you propose sounds good. Basically the main difference is that you take the previous line indentation into account which is what my original algorithm didn't do. This really appears to solve all the problems in quite an elegant way (much nicer than the flags thing I suggested). Just a detail that strictly speaking the "N-1 line" should be previous non-empty line.
I'm actually not completely against the immediate indent when typing (without having to press enter). Your algorithm is capable of indentation "undo" when the regex doesn't match any more. I think it's quite OK if "fi" unindents the line and subsequent letter returns it back. Something like that already happens with syntax highlighting where the keyword becomes blue when you type it but changes back to black when you add additional letters.
Cheers, Jiri
On Wed, Dec 7, 2011 at 11:06 AM, Jiří Techet techet@gmail.com wrote:
On Tue, Dec 6, 2011 at 21:56, Lex Trotman elextr@gmail.com wrote:
[...]
Maybe I don't understand it correctly but does this mean that if you open an existing file, you'd re-indent it completely based on the regexes? I don't think this is a good idea because this could lead to whitespace change in every line when you edit just a single line.
No, thats another reason why I rejected option 1
Or does it mean to have these indent numbers just internally and use them only when when auto-indentation is done? I often work with files edited by many people over many years which have inconsistent indents. Imagine the correct indent size is 4 but someone used just 2 indents in the outer "if" block. If I insert new "if" inside this block, the indent size will be 6 because of the incorrect outer indent. This is exactly why I used the "delta" indent solution to be locally correct and have minimal impact on (and be minimally affected by) the rest of the code.
The algorithm will give 6 since it only considers the previous line and the line it is indenting which is the line with the cursor.
One more thing - with global indents you have to be sure that the regexes catch all the indentation cases (without false positives) otherwise one error will affect the indentation everywhere in the rest of the file. You can do crazy stuff with some languages so I can imagine such a thing can happen easily (single line with end of multi-line comment followed by end block followed by another comment). With delta indentation it's much less critical - the indent may be incorrect for the next line but this won't affect the rest of the file in any negative way. Moreover, you usually don't do things like the comment example when you write the code and when you need auto-indentation; you usually add them afterwards when no autoindentation is needed.
Final remark - better not to auto-indent at all than to indent incorrectly. There's nothing worse than an editor (actually anything) which tries to be smart in an annoying way.
Don't worry there is no intention that auto-indentation does more than give a mostly right indent on new lines and mostly correct it when you type } on that new line.
I did clearly say it should not change any manual indentation.
Ah, sorry, after re-reading it again I think I misunderstood your algorithm originally so please forget what I said.
What you propose sounds good. Basically the main difference is that you take the previous line indentation into account which is what my original algorithm didn't do. This really appears to solve all the problems in quite an elegant way (much nicer than the flags thing I suggested). Just a detail that strictly speaking the "N-1 line" should be previous non-empty line.
In fact I also omitted to say that comments should be ignored as well, which means it has to run after scintilla lexing is complete.
I'm actually not completely against the immediate indent when typing (without having to press enter). Your algorithm is capable of indentation "undo" when the regex doesn't match any more. I think it's quite OK if "fi" unindents the line and subsequent letter returns it back. Something like that already happens with syntax highlighting where the keyword becomes blue when you type it but changes back to black when you add additional letters.
Yes, my only objection was having to run the regexes over two lines for each character, but maybe some judicious caching of the results of line N-1 and the start of line N can reduce the work required most of the time.
Cheers Lex
Cheers, Jiri _______________________________________________ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Le 06/12/2011 07:20, Lex Trotman a écrit :
[...]
First, note that I wasn't able to find the patch, so I'm only guessing from reading the thread and from my own (much less complete) attempt.
I'm afraid that if I had the patch it is on my broken hard drive :-S
And anyway we never got it to work satisfactorily.
So. This looks pretty good for line-based indents (but not brace match :(), but I ran into a really annoying problem with SH:
SH should indent after "then", "do", etc. and unindent "fi", "esac", etc. The problem is that you expect the "fi" line to be unindented (e.g. use unindent_this_line), but if you type "file" for example, it'd wrongly unindent that line too!
I thought about unindenting the previous line when entering the \n, but this isn't a real solution either since re-adding a newline after a well indented line would unindent it again. Crap.
So I haven't yet found a sensible solution for this problem -- which wouldn't apply for '}' since it's very unlikely it's part of a bigger word -- and would like to know it anybody got super clever ideas, or how other editors you know handle this.
This said, I really like the idea of configurable indentation rules that could handle languages like SH, Pascal, Ruby, Ada, etc. without the need to hard-code it.
WARNING, complex topic, big post :)
Quick summary of ones I know:
Emacs has language specific elisp, for C:
"It analyzes the line to determine its syntactic symbol(s) (the kind of language construct it's looking at) and its anchor position (the position earlier in the file that CC Mode will indent the line relative to). The anchor position might be the location of an opening brace in the previous line, for example. See Syntactic Analysis. It looks up the syntactic symbol(s) in the configuration to get the corresponding offset(s). The symbol +, which means “indent this line one more level” is a typical offset. CC Mode then applies these offset(s) to the anchor position, giving the indentation for the line. The different sorts of offsets are described in c-offsets-alist. "
And it admits that even then it gets it wrong sometimes :(
Eclipse and Netbeans also use parser results for the indent guidance.
I don't think parsing the source for indent guidance is in the Geany light and small spirit, so I reject that.
Right, we don't want such a thing. Moreover it'd need one parser for each language, something we don't (or do, if we consider sinctilla/ctags) have and don't want to write.
Instead I propose the following "correct most of the time" but simple option based on a combination of Jiri's and Emacs' methods:
- Each line N has an initial indentation which is the indentation of
line N-1 plus the increments/decrements for all matches to "indent next line" regexes that occur in liine N-1. (Note that each regex has a signed count of columns to indent/exdent)
- The line N final indentation is the initial indentation adjusted by
the increments/decrements for all matches to "indent this line" regexes that occur in line N
Note that this is the indent, not a delta like Jiri's algorithm. It is therefore stable no matter how many times it is calculated.
What do you mean here with "the indent" versus a delta? If the new indent's value is not count in "current indent + something * indent size" (where here "current indent" is previous line's indent) I don't see how this would possibly fit with configured indent sizes, nor what's the advantage?
The question is then when to calculate and apply this indent, clearly when a line is first created by enter the indent should be applied.
But what about when line content changes? Should we:
- calculate the indent each change, and then ripple that through the file
- calculate the indent each change and only apply it to this line
- calculate and apply the indent to lines N and N-1 only on new line
or user command 4. calculate and apply the indent on user command
Option 1 is rejected because it is expensive and it will destroy manually adjusted indentation when editing an existing line and because indentation can change as you type causing distracting effects (happens with some Emacs indentation styles)
Option 2 is rejected for the same reasons
I agree that re-indenting the whole file would just be pointless, but not really with the other points.
OK, it may broke a manually tuned indentation, but that'd only be on that very line and hopefully the regex would be somewhat OK.
A not-that easy (very) small improvement would be not to change the indentation if:
1) the line has greater indent that the previous line and we would also add indent (e.g. if either there's nothing to do or we'd do the same thing another way), or 2) the line has smaller indent than the previous line and we also would remove indent (just the opposite)
So then, we'd no break manual indent if it only change the width of the indent to add/remove. Maybe it's overcompliacted for the very small gain.
Option 4 is rejected because auto new line indent is really the minimum required to be called "auto" indentation
Agreed.
So that leaves option 3. The upside is that new lines get a sensible indentation automatically, the downside is that lines that should be unindented won't be until enter or user command. I have used another editor that worked this way and after a while I became used to it. Note that editing an existing line won't destroy manual indentation unless you tell it to or create a new line after.
I don't understand why we would change the N-1 line's indent?
The settings are two ("indent this line", "indent next line") lists of pairs of a regex and a signed count.
These settings are per language so they should come from the filetype files.
A final thought, as there is now an "apply auto indent" command, if there is a selection the auto indent should ripple through the whole selection.
Well. This does seem to look quite OK at first glance, but what's the real difference with Jiří's (and my) solution, but using the previous line's indent as the reference? -- which seems quite cool since it'd fix most of the problems I see, basically re-unindenting already unindented lines.
Regards, Colomban
[...]
What do you mean here with "the indent" versus a delta? If the new indent's value is not count in "current indent + something * indent size" (where here "current indent" is previous line's indent) I don't see how this would possibly fit with configured indent sizes, nor what's the advantage?
Sorry the aside about delta vs indent relates to problems I had with Jiri's patch and probably doesn't make sense without knowing the whole of the previous thread, so ignore it. [Or see very last comment]
[...]
I agree that re-indenting the whole file would just be pointless, but not really with the other points.
OK, it may broke a manually tuned indentation, but that'd only be on that very line and hopefully the regex would be somewhat OK.
A not-that easy (very) small improvement would be not to change the indentation if:
- the line has greater indent that the previous line and we would also
add indent (e.g. if either there's nothing to do or we'd do the same thing another way), or 2) the line has smaller indent than the previous line and we also would remove indent (just the opposite)
So then, we'd no break manual indent if it only change the width of the indent to add/remove. Maybe it's overcompliacted for the very small gain.
Several common cases of manual indentation will still break even with this change so I agree it wouldn't add much.
Option 4 is rejected because auto new line indent is really the minimum required to be called "auto" indentation
Agreed.
So that leaves option 3. The upside is that new lines get a sensible indentation automatically, the downside is that lines that should be unindented won't be until enter or user command. I have used another editor that worked this way and after a while I became used to it. Note that editing an existing line won't destroy manual indentation unless you tell it to or create a new line after.
I don't understand why we would change the N-1 line's indent?
It doesn't change line N-1 but when you create a new line (ie type enter) the line you are on (line N) is checked for things like } or fi and the indent set for it. Delaying checking till enter/user command avoids your fi/file problem.
The settings are two ("indent this line", "indent next line") lists of pairs of a regex and a signed count.
Because pairs are not supported by g_key_file I suggest instead of a count that only one step is allowed (step size is another parameter) and we fall back to just having four regexes per language (as per Jiri's solution) "indent this line one step", "undent this line one step" "indent next line one step", undent next line one step".
These settings are per language so they should come from the filetype files.
A final thought, as there is now an "apply auto indent" command, if there is a selection the auto indent should ripple through the whole selection.
Well. This does seem to look quite OK at first glance, but what's the real difference with Jiří's (and my) solution, but using the previous line's indent as the reference?
Well thats the main difference, (idea stolen from Emacs) and the point that indentation is only triggered on return or an explicit user command "adjust indentation" (which you should rarely need).
-- which seems quite cool since it'd
fix most of the problems I see, basically re-unindenting already unindented lines.
Well, that is actually what I was meaning by "calculating a stable indent value" vs "calculating a delta, which we then have to prevent from being re-applied to an already adjusted line"
Cheers Lex
On 12/05/2011 10:30 AM, Colomban Wendling wrote:
Hi,
I know this is a more than one year old discussion, but I was messing with a very similar thing a few minutes ago when wanting to add autoindent support for SH.
Sorry I haven't followed/read the whole thread, but I wanted to add a feature request if someone's going to hack on this.
It would be nice if the auto-indent was "undone" when you leave a blank line, example (assuming this is all being typed, not loaded from disk):
struct foobar { int baz;<--- hit enter here <--- here's an audo-indented tab char *bong;<-- auto-indented };
Would do this (assuming it happens as you type):
struct foobar { int baz;<--- hit enter here <--- indent removed, since the user hit enter again and kept typing char *bong;<-- re-indented };
This is the #1 thing I fight against in the auto-indenter, which is why I usually turn on "Strip trailing spaces and tabs", but that's too brute-force since it applies to the whole file on save instead of just the whitespace noise added by the auto-indenter.
Anyway, just a request, feel free to ignore :)
Cheers, Matthew Brush
Nevermind, I need to better RTFM: `Preferences->Editor->Features->Newline strips trailing spaces` seems to do exactly what I was talking about (awesome!).
Sorry for the noise
Cheers, Matthew Brush
On 12/06/2011 06:06 PM, Matthew Brush wrote:
On 12/05/2011 10:30 AM, Colomban Wendling wrote:
Hi,
I know this is a more than one year old discussion, but I was messing with a very similar thing a few minutes ago when wanting to add autoindent support for SH.
Sorry I haven't followed/read the whole thread, but I wanted to add a feature request if someone's going to hack on this.
It would be nice if the auto-indent was "undone" when you leave a blank line, example (assuming this is all being typed, not loaded from disk):
struct foobar { int baz;<--- hit enter here <--- here's an audo-indented tab char *bong;<-- auto-indented };
Would do this (assuming it happens as you type):
struct foobar { int baz;<--- hit enter here <--- indent removed, since the user hit enter again and kept typing char *bong;<-- re-indented };
This is the #1 thing I fight against in the auto-indenter, which is why I usually turn on "Strip trailing spaces and tabs", but that's too brute-force since it applies to the whole file on save instead of just the whitespace noise added by the auto-indenter.
Anyway, just a request, feel free to ignore :)
Cheers, Matthew Brush _______________________________________________ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel