Hi there!
I'd very much like to see some auto-parentheses indentation in Geany. I mean that this kind of indentation would be auto-generated on typing: if (cond1 && fun_call (param1, param2) && cond3) { another_call (param1, param2); /* and so on */ }
This includes:
* Indent new lines to match the position of the last opening parenthesis (lines 2, 3, 7); * Automatically reduce indentation on closing parenthesis to fit the indentation of it's matching opening one (lines 4, 5, 8).
I'm trying to get this to work (attached WIP patch, which works but have caveats)[1], but I have a couple of problems (probably related to my little habit of Scintilla) and questions. First, the problems:
1. How to know if a character is or not part of a comment, string or so? (e.g. should be interpreted as a syntactic element by itself) I need this to find the parenthesis -- and no, I can't do the same than brace_match() since I don't know the position of any of the parentheses. 2. Why brace_match() uses the character at (pos - 1) but the style at (pos)? This seems to be needed for brackets but breaks with parentheses (see comments in the WIP patch).
And now the unique question (not that urgent since the patch isn't ready): how to add this as part of the auto-indentation? (I mean, always enable it -- I don't think everybody will like --, add a new indent method, a new separated setting, or what?)
Thanks for your help! Colomban
[1] But if anybody would like to do this, I'd be happy to let him/her do :D
Le 07/06/2010 16:43, Colomban Wendling a écrit :
- How to know if a character is or not part of a comment, string or so? (e.g. should be interpreted as a syntactic element by itself) I need this to find the parenthesis -- and no, I can't do the same than brace_match() since I don't know the position of any of the parentheses.
- Why brace_match() uses the character at (pos - 1) but the style at (pos)? This seems to be needed for brackets but breaks with parentheses (see comments in the WIP patch).
Again... a little update of the current state that fixes some errors of the previous one (which broke some existing indentation). Notably, my original problem 2) is gone by using sci_find_matching_brace(). Last known problem is 1) -- which is not a problem most of the time, but still.
Regards, Colomban
On 8 June 2010 00:43, Colomban Wendling lists.ban@herbesfolles.org wrote:
Hi there!
I'd very much like to see some auto-parentheses indentation in Geany. I mean that this kind of indentation would be auto-generated on typing: if (cond1 && fun_call (param1, param2) && cond3) { another_call (param1, param2); /* and so on */ }
This includes:
Indent new lines to match the position of the last opening parenthesis (lines 2, 3, 7); Automatically reduce indentation on closing parenthesis to fit the indentation of it's matching opening one (lines 4, 5, 8).
I'm trying to get this to work (attached WIP patch, which works but have caveats)[1], but I have a couple of problems (probably related to my little habit of Scintilla) and questions. First, the problems:
How to know if a character is or not part of a comment, string or so? (e.g. should be interpreted as a syntactic element by itself) I need this to find the parenthesis -- and no, I can't do the same than brace_match() since I don't know the position of any of the parentheses.
Use editor.c/is_comment_style()
The brace match indenting code needs fixing too, since it adjusts the indent of a } in a comment!!!
Also brace_match ability to go forward and backward is wasted since it is only ever called from close_brace which AFAICT is only ever called with the current character a }
Why brace_match() uses the character at (pos - 1) but the style at (pos)? This seems to be needed for brackets but breaks with parentheses (see comments in the WIP patch).
Hmmm, actually the question is how do braces work when it does that?
Probably pos is always > sci_get_end_styling since a } has just been added to the buffer and the scintilla documentation says the charadded notification is called before styling is done.
And now the unique question (not that urgent since the patch isn't ready): how to add this as part of the auto-indentation? (I mean, always enable it -- I don't think everybody will like --, add a new indent method, a new separated setting, or what?)
I think it needs to be a separate setting, parentheses indent mode.
Cheers Lex
Thanks for your help! Colomban
[1] But if anybody would like to do this, I'd be happy to let him/her do :D
Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Le 08/06/2010 04:34, Lex Trotman a écrit :
On 8 June 2010 00:43, Colomban Wendling lists.ban@herbesfolles.org wrote:
How to know if a character is or not part of a comment, string or so? (e.g. should be interpreted as a syntactic element by itself) I need this to find the parenthesis -- and no, I can't do the same than brace_match() since I don't know the position of any of the parentheses.
Use editor.c/is_comment_style()
Hey, almost perfect, found is_code_style() which is exactly what I need, thanks a lot!
The brace match indenting code needs fixing too, since it adjusts the indent of a } in a comment!!!
True, and same for opening ones. Should be relatively easy to fix though, even if it's perhaps not a change trivial enough to be in 0.19.
Also brace_match ability to go forward and backward is wasted since it is only ever called from close_brace which AFAICT is only ever called with the current character a }
Why brace_match() uses the character at (pos - 1) but the style at (pos)? This seems to be needed for brackets but breaks with parentheses (see comments in the WIP patch).
Hmmm, actually the question is how do braces work when it does that?
Probably pos is always > sci_get_end_styling since a } has just been added to the buffer and the scintilla documentation says the charadded notification is called before styling is done.
It doesn't seems that simple since if I replace pos by pos - 1, the brace matching indentation breaks…
And now the unique question (not that urgent since the patch isn't ready): how to add this as part of the auto-indentation? (I mean, always enable it -- I don't think everybody will like --, add a new indent method, a new separated setting, or what?)
I think it needs to be a separate setting, parentheses indent mode
You mean a complete setting like the indent mode (with different levels, etc) or simply a kinda boolean setting like "auto-indent parentheses"? Maybe a complex setting might be interesting to allow not only alignment, but also Geany-style of extra-indentation that isn't alignment and even other if somebody needs it.
Ah, and there is another thing I would have to improve bracket matching indentation when the opening one is indented because of an alignment: backward parentheses matching after bracket matching. This would fix indentation of something like: if (a && b) { /* code */ } which currently result to: if (a && b) { /* code */ } which is obviously wrong here. I mean that the bracket is first matched, and then if there is a non-balanced parenthesis, it is matched to finally get the indentation. Well, of course it's probably not enough in some cases an/or languages, but it would probably fix the majority of scenario. Not sure if it should be completely related to parentheses auto-indentation and/or matching, or if it should be part of a sort of "intelligent detection of alignment vs. indentation".
Anyway, I join an updated patch that seems to work very well (at least for me), thanks to is_code_style()! It still misses settings, and I would like to know your thoughts about what should depend on which setting (there's FIXME in the patch for them); and even how you'd like to see it in the preference dialogue.
Regards, Colomban
On 9 June 2010 10:08, Colomban Wendling lists.ban@herbesfolles.org wrote:
Le 08/06/2010 04:34, Lex Trotman a écrit :
On 8 June 2010 00:43, Colomban Wendling lists.ban@herbesfolles.org wrote:
How to know if a character is or not part of a comment, string or so? (e.g. should be interpreted as a syntactic element by itself) I need this to find the parenthesis -- and no, I can't do the same than brace_match() since I don't know the position of any of the parentheses.
Use editor.c/is_comment_style()
Hey, almost perfect, found is_code_style() which is exactly what I need, thanks a lot!
The brace match indenting code needs fixing too, since it adjusts the indent of a } in a comment!!!
True, and same for opening ones. Should be relatively easy to fix though, even if it's perhaps not a change trivial enough to be in 0.19.
Yeah, the whole brace_match needs work.
Also brace_match ability to go forward and backward is wasted since it is only ever called from close_brace which AFAICT is only ever called with the current character a }
Why brace_match() uses the character at (pos - 1) but the style at (pos)? This seems to be needed for brackets but breaks with parentheses (see comments in the WIP patch).
Hmmm, actually the question is how do braces work when it does that?
Probably pos is always > sci_get_end_styling since a } has just been added to the buffer and the scintilla documentation says the charadded notification is called before styling is done.
It doesn't seems that simple since if I replace pos by pos - 1, the brace matching indentation breaks…
Which pos? there are lots in brace_match, what about if pos-1 is replaced by pos?
And now the unique question (not that urgent since the patch isn't ready): how to add this as part of the auto-indentation? (I mean, always enable it -- I don't think everybody will like --, add a new indent method, a new separated setting, or what?)
I think it needs to be a separate setting, parentheses indent mode
You mean a complete setting like the indent mode (with different levels, etc) or simply a kinda boolean setting like "auto-indent parentheses"? Maybe a complex setting might be interesting to allow not only alignment, but also Geany-style of extra-indentation that isn't alignment and even other if somebody needs it.
I was thinking something similar to the brace matching settings for the reasons you give below. There is plenty of room in that page of the prefs dialog. Of course with my GUI record Enrico is sure to disgree :D
Ah, and there is another thing I would have to improve bracket matching indentation when the opening one is indented because of an alignment: backward parentheses matching after bracket matching. This would fix indentation of something like: if (a && b) { /* code */ } which currently result to: if (a && b) { /* code */ }
Sadly this example came through the email without any indentation at all so I'm not sure what you mean.
which is obviously wrong here. I mean that the bracket is first matched, and then if there is a non-balanced parenthesis, it is matched to finally get the indentation. Well, of course it's probably not enough in some cases an/or languages, but it would probably fix the majority of scenario. Not sure if it should be completely related to parentheses auto-indentation and/or matching, or if it should be part of a sort of "intelligent detection of alignment vs. indentation".
Anyway, I join an updated patch that seems to work very well (at least for me), thanks to is_code_style()! It still misses settings, and I would like to know your thoughts about what should depend on which setting (there's FIXME in the patch for them); and even how you'd like to see it in the preference dialogue.
I don't have a chance just now but will as soon as possible, I like the idea of assisted function parameter indentation.
Cheers Lex
Regards, Colomban
Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Le 09/06/2010 02:48, Lex Trotman a écrit :
Also brace_match ability to go forward and backward is wasted since it is only ever called from close_brace which AFAICT is only ever called with the current character a }
Why brace_match() uses the character at (pos - 1) but the style at (pos)? This seems to be needed for brackets but breaks with parentheses (see comments in the WIP patch).
Hmmm, actually the question is how do braces work when it does that?
Probably pos is always > sci_get_end_styling since a } has just been added to the buffer and the scintilla documentation says the charadded notification is called before styling is done.
It doesn't seems that simple since if I replace pos by pos - 1, the brace matching indentation breaks…
Which pos? there are lots in brace_match, what about if pos-1 is replaced by pos?
I'm talking about this code chunk:
chAtPos = sci_get_char_at(sci, pos - 1); styAtPos = sci_get_style_at(sci, pos);
And I doubt that simply using pos and not pos-1 would fix the problem, even if it'd probably be less hackish not to use pos-1 (which might even become -1 if I read this right).
And now the unique question (not that urgent since the patch isn't ready): how to add this as part of the auto-indentation? (I mean, always enable it -- I don't think everybody will like --, add a new indent method, a new separated setting, or what?)
I think it needs to be a separate setting, parentheses indent mode
You mean a complete setting like the indent mode (with different levels, etc) or simply a kinda boolean setting like "auto-indent parentheses"? Maybe a complex setting might be interesting to allow not only alignment, but also Geany-style of extra-indentation that isn't alignment and even other if somebody needs it.
I was thinking something similar to the brace matching settings for the reasons you give below. There is plenty of room in that page of the prefs dialog. Of course with my GUI record Enrico is sure to disgree :D
Let's wait for other thoughts then ^^
Ah, and there is another thing I would have to improve bracket matching indentation when the opening one is indented because of an alignment: backward parentheses matching after bracket matching. This would fix indentation of something like: if (a && b) { /* code */ } which currently result to: if (a && b) { /* code */ }
Sadly this example came through the email without any indentation at all so I'm not sure what you mean.
Oh, sorry. with s/ /_/g, it is:
if (a && ____b) { __/* code */ }
results to:
if (a && ____b) { __/* code */ ____}
...the closing bracket is aligned with the indentation of the maching opening one, but here it isn't indentation but alignment; then it breaks.
which is obviously wrong here. I mean that the bracket is first matched, and then if there is a non-balanced parenthesis, it is matched to finally get the indentation. Well, of course it's probably not enough in some cases an/or languages, but it would probably fix the majority of scenario. Not sure if it should be completely related to parentheses auto-indentation and/or matching, or if it should be part of a sort of "intelligent detection of alignment vs. indentation".
Anyway, I join an updated patch that seems to work very well (at least for me), thanks to is_code_style()! It still misses settings, and I would like to know your thoughts about what should depend on which setting (there's FIXME in the patch for them); and even how you'd like to see it in the preference dialogue.
I don't have a chance just now but will as soon as possible, I like the idea of assisted function parameter indentation.
Cool, I'm not alone! :D
Regards, Colomban
On 13 June 2010 03:09, Colomban Wendling lists.ban@herbesfolles.org wrote:
Le 09/06/2010 02:48, Lex Trotman a écrit :
Also brace_match ability to go forward and backward is wasted since it is only ever called from close_brace which AFAICT is only ever called with the current character a }
Why brace_match() uses the character at (pos - 1) but the style at (pos)? This seems to be needed for brackets but breaks with parentheses (see comments in the WIP patch).
Hmmm, actually the question is how do braces work when it does that?
Probably pos is always > sci_get_end_styling since a } has just been added to the buffer and the scintilla documentation says the charadded notification is called before styling is done.
It doesn't seems that simple since if I replace pos by pos - 1, the brace matching indentation breaks…
Which pos? there are lots in brace_match, what about if pos-1 is replaced by pos?
I'm talking about this code chunk:
chAtPos = sci_get_char_at(sci, pos - 1); styAtPos = sci_get_style_at(sci, pos);
And I doubt that simply using pos and not pos-1 would fix the problem, even if it'd probably be less hackish not to use pos-1 (which might even become -1 if I read this right).
Yes, I think it can, presumably sci_get_char_at checks the position is in range and doesn't crash.
In general I don't understand how it works, it uses the style from the newly inserted brace to look for the match, but AFAICT it is called before the brace is styled.
And now the unique question (not that urgent since the patch isn't ready): how to add this as part of the auto-indentation? (I mean, always enable it -- I don't think everybody will like --, add a new indent method, a new separated setting, or what?)
I think it needs to be a separate setting, parentheses indent mode
You mean a complete setting like the indent mode (with different levels, etc) or simply a kinda boolean setting like "auto-indent parentheses"? Maybe a complex setting might be interesting to allow not only alignment, but also Geany-style of extra-indentation that isn't alignment and even other if somebody needs it.
I was thinking something similar to the brace matching settings for the reasons you give below. There is plenty of room in that page of the prefs dialog. Of course with my GUI record Enrico is sure to disgree :D
Let's wait for other thoughts then ^^
Ah, and there is another thing I would have to improve bracket matching indentation when the opening one is indented because of an alignment: backward parentheses matching after bracket matching. This would fix indentation of something like: if (a && b) { /* code */ } which currently result to: if (a && b) { /* code */ }
Sadly this example came through the email without any indentation at all so I'm not sure what you mean.
Oh, sorry. with s/ /_/g, it is:
if (a && ____b) { __/* code */ }
results to:
if (a && ____b) { __/* code */ ____}
...the closing bracket is aligned with the indentation of the maching opening one, but here it isn't indentation but alignment; then it breaks.
I see what you mean, that would be *very* annoying, but not easy to fix.
which is obviously wrong here. I mean that the bracket is first matched, and then if there is a non-balanced parenthesis, it is matched to finally get the indentation. Well, of course it's probably not enough in some cases an/or languages, but it would probably fix the majority of scenario. Not sure if it should be completely related to parentheses auto-indentation and/or matching, or if it should be part of a sort of "intelligent detection of alignment vs. indentation".
Anyway, I join an updated patch that seems to work very well (at least for me), thanks to is_code_style()! It still misses settings, and I would like to know your thoughts about what should depend on which setting (there's FIXME in the patch for them); and even how you'd like to see it in the preference dialogue.
I don't have a chance just now but will as soon as possible, I like the idea of assisted function parameter indentation.
Cool, I'm not alone! :D
Regards, Colomban
Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel