Hi,
First of all, thanks for this great piece of code that is Geany !
Now, I would like to use auto-close brackets, brace and string in Geany. As it doesn't looks very complicated, it could be a fairly easy feature to implement for a first time contributor like me.
So here is my proposal: These options will auto-close ( [ { ' and " while typing, positionning the cursor between the pair. Nothing really revolutionar here as some IDE already implement that. Moreover, it sounds this cannot be done using snippets and I can't seriously think about doing a plugin for such a feature (I'm not even sure it's fesable). So I believe it belongs to Geany's core.
I had a look in the sources, but before coding, I would like some feedback about this proposal and the following questions:
- where should I put the booleans options in the conf panel ? "Editor" > "Completion" tab sounds obvious, what do you think about that ? - should I group brackets and braces, under the same checkbox and [single-]quotes in an other one ? - what about adding a "Typing" Section to group these options in the completion tab ?
Thanks for your feedbacks and comments !
On Fri, 28 Nov 2008 05:55:25 +0100 (CET), ioguix@free.fr wrote:
Hi,
First of all, thanks for this great piece of code that is Geany !
Now, I would like to use auto-close brackets, brace and string in Geany. As it doesn't looks very complicated, it could be a fairly easy feature to implement for a first time contributor like me.
So here is my proposal: These options will auto-close ( [ { ' and " while typing, positionning the cursor between the pair. Nothing really revolutionar here as some IDE already implement that. Moreover, it sounds this cannot be done using snippets and I can't seriously think about doing a plugin for such a feature (I'm not even sure it's fesable). So I believe it belongs to Geany's core.
As long as it is configurable(i.e. I can disable it :D) I'm fine with this. We already have the basic code for this in Geany, even though it's only used for LaTeX right now. Check auto_close_bracket() in src/editor.c. Remove the check for the lexer == latex and add the missing characters (currently it only works for { and [.
- where should I put the booleans options in the conf panel ?
"Editor" > "Completion" tab sounds obvious, what do you think about that ?
- should I group brackets and braces, under the same checkbox and
[single-]quotes in an other one ?
- what about adding a "Typing" Section to group these options in the
completion tab ?
Just put one checkbox in Editor->Completions, toggling the feature on and off. The easiest solution to make the completed characters configurable could be: Add a text field (GtkEntry) which holds all valid opening braces (and a single and double quote). The user can remove some of these to disable completion for those. The tooltip should make clear what can be entered and what not.
But this is not the most user-friendly way, I think :).
Alternatively, you could add a frame containing checkboxes for each of your suggested characters but for storage in the config file use a string containing the opening braces/brackets/... or an integer containing a bitmask to avoid having too many trivial settings.
Last note: if you edit the preferences dialog, please use Glade 2.10, newer versions generate code which is incompatible with GTK 2.6. If you can't use it, then just skip the GUI part of the prefs dialog, we will do this then.
Regards, Enrico
Hi,
Thanks for the feedback ! Your advices and tips are appreciated :)
On Sun, 30 Nov 2008, Enrico Tröger wrote:
On Fri, 28 Nov 2008 05:55:25 +0100 (CET), ioguix@free.fr wrote:
Hi,
First of all, thanks for this great piece of code that is Geany !
Now, I would like to use auto-close brackets, brace and string in Geany. As it doesn't looks very complicated, it could be a fairly easy feature to implement for a first time contributor like me.
So here is my proposal: These options will auto-close ( [ { ' and " while typing, positionning the cursor between the pair. Nothing really revolutionar here as some IDE already implement that. Moreover, it sounds this cannot be done using snippets and I can't seriously think about doing a plugin for such a feature (I'm not even sure it's fesable). So I believe it belongs to Geany's core.
As long as it is configurable(i.e. I can disable it :D) I'm fine with this. We already have the basic code for this in Geany, even though it's only used for LaTeX right now. Check auto_close_bracket() in src/editor.c. Remove the check for the lexer == latex and add the missing characters (currently it only works for { and [.
Thanks for this info. I began to play with that, it looks to be the perfect place.
- where should I put the booleans options in the conf panel ?
"Editor" > "Completion" tab sounds obvious, what do you think about that ?
- should I group brackets and braces, under the same checkbox and
[single-]quotes in an other one ?
- what about adding a "Typing" Section to group these options in the
completion tab ?
Just put one checkbox in Editor->Completions, toggling the feature on and off. The easiest solution to make the completed characters configurable could be: Add a text field (GtkEntry) which holds all valid opening braces (and a single and double quote). The user can remove some of these to disable completion for those. The tooltip should make clear what can be entered and what not.
But this is not the most user-friendly way, I think :).
Alternatively, you could add a frame containing checkboxes for each of your suggested characters but for storage in the config file use a string containing the opening braces/brackets/... or an integer containing a bitmask to avoid having too many trivial settings.
I choosed the alternative :) I added a "Auto-close brackets and quotes" frame in the "Completion" tab with 5 checkboxes for each ( { [ " '.
Last note: if you edit the preferences dialog, please use Glade 2.10, newer versions generate code which is incompatible with GTK 2.6. If you can't use it, then just skip the GUI part of the prefs dialog, we will do this then.
Well, I already noticed that before mailing here and setted up a glade 2.10 binary in my geany dev folder :) After some mess with it (first time I'm using it), I finally managed to create to interface and connect everything to the conf file. As you wished, the checkboxes states are saved in an integer so far.
One question: to keep the code readable, I used these macros to define the values: #define AC_PARENTHESIS 1 #define AC_CBRACKET 2 #define AC_SBRACKET 4 #define AC_SQUOTE 8 #define AC_DQUOTE 16
What is your policy about that ? Is it ok or do you prefer to put values directly in the code ?
I hope I'll find time this week to finish everything...I have the feeling the "hardest" part is behind me ;)
On Tue, 2 Dec 2008 06:03:36 +0100 (CET) ioguix@free.fr wrote:
One question: to keep the code readable, I used these macros to define the values: #define AC_PARENTHESIS 1 #define AC_CBRACKET 2 #define AC_SBRACKET 4 #define AC_SQUOTE 8 #define AC_DQUOTE 16
What is your policy about that ? Is it ok or do you prefer to put values directly in the code ?
It would be best if you used an (anonymous) enum instead of macros IMO.
Regards, Nick
So here is (in attachment) a first patch proposal.
I used anonymous enum as Nick wished.
Moreover, I droped the editor_prefs.complete_snippets test in the auto_close_chars function (ex. auto_close_bracket) as it seems there's no relation between auto-closing chars and auto-complete snippets.
I only built/tested this code under Linux.
Thanks for your feedbacks !
On Thu, 4 Dec 2008 06:02:42 +0100 (CET), ioguix@free.fr wrote:
So here is (in attachment) a first patch proposal.
I used anonymous enum as Nick wished.
Moreover, I droped the editor_prefs.complete_snippets test in the auto_close_chars function (ex. auto_close_bracket) as it seems there's no relation between auto-closing chars and auto-complete snippets.
Committed in r3319 with a few minor modifications, thanks a lot!
Regards, Enrico
On Thu, 2008-12-04 at 21:19 +0100, Enrico Tröger wrote:
On Thu, 4 Dec 2008 06:02:42 +0100 (CET), ioguix@free.fr wrote:
So here is (in attachment) a first patch proposal.
I used anonymous enum as Nick wished.
Moreover, I droped the editor_prefs.complete_snippets test in the auto_close_chars function (ex. auto_close_bracket) as it seems there's no relation between auto-closing chars and auto-complete snippets.
Committed in r3319 with a few minor modifications, thanks a lot!
Regards, Enrico
Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Yeah, this is great feature, thanks to all :)
-- Regards, Atanas Beloborodov
Hi,
So I began to use geany enabling the "autoclosed chars". It is usefull, but sometime anoying...
So I believe we can make it a little bit more smart.
In a first step, when opening a brace (ie. ( { [ ), we could check if no closing brace already match it before auto-closing it. That what I tried to do in the attached patch.
In a second step, I think we could try to detect if we are already in a string before auto-closing quotes. Moreover, if we are indeed in a string we could auto-secape any quotes putted in. However, I think this should be configurable.
About these second step, I hadn't too much time to investigate the code, but: - is it possible to actually know what is the current applied style ? - can we really test if we are actually in a in string whatever the current language style ? - about the auto-escaping quotes, it would need some mechanism to exactly know how the current language style is actually escaping them (obviously C or SQL doesn't escape string in the same way)
Thanks for your next answer and review :)
On Tue, 9 Dec 2008 05:14:08 +0100 (CET) ioguix@free.fr wrote:
In a first step, when opening a brace (ie. ( { [ ), we could check if no closing brace already match it before auto-closing it. That what I tried to do in the attached patch.
BTW, you could use sci_find_matching_brace() instead of SSM().
In a second step, I think we could try to detect if we are already in a string before auto-closing quotes. Moreover, if we are indeed in a string we could auto-secape any quotes putted in. However, I think this should be configurable.
About these second step, I hadn't too much time to investigate the code, but:
- is it possible to actually know what is the current applied style ?
Yes, sci_get_style_at().
- can we really test if we are actually in a in string whatever the
current language style ?
Yes, but maybe not all filetypes are completely supported. See is_string_style() in editor.c.
- about the auto-escaping quotes, it would need some mechanism to
exactly know how the current language style is actually escaping them (obviously C or SQL doesn't escape string in the same way)
Not sure about this, could be awkward to maintain. But I suppose full filetypes support is not necessary.
Personally I think good bracket completion could be fairly involved, maybe it would be better as a plugin, not sure.
Regards, Nick
On Mon, 15 Dec 2008 13:12:54 +0000, Nick Treleaven nick.treleaven@btinternet.com wrote:
On Tue, 9 Dec 2008 05:14:08 +0100 (CET) ioguix@free.fr wrote:
In a first step, when opening a brace (ie. ( { [ ), we could check if no closing brace already match it before auto-closing it. That what I tried to do in the attached patch.
I actually worked on the patch yesterday but had some weird connectivity issues (some sites weren't reachable including sourceforge.net, so no commits).
@ioguix: The second of your patch was about to change handling of GEANY_AC_SQUOTE with end_pos which was IMO a typo and should have been in the GEANY_AC_SBRACKET, so I moved it there. Correct me if I'm wrong.
- can we really test if we are actually in a in string whatever the
current language style ?
Yes, but maybe not all filetypes are completely supported. See is_string_style() in editor.c.
Though this function treats all kinds of strings equally, that is for languages like C or Python where you have different kind of strings ('blah', "blah", ''' blag ''', ...) this function returns TRUE for all kinds. But you probably want something more fine-grained to differentiate between 'blah' and "blah".
Regards, Enrico
On Mon, 15 Dec 2008, Enrico Tröger wrote:
On Mon, 15 Dec 2008 13:12:54 +0000, Nick Treleaven nick.treleaven@btinternet.com wrote:
On Tue, 9 Dec 2008 05:14:08 +0100 (CET) ioguix@free.fr wrote:
In a first step, when opening a brace (ie. ( { [ ), we could check if no closing brace already match it before auto-closing it. That what I tried to do in the attached patch.
I actually worked on the patch yesterday but had some weird connectivity issues (some sites weren't reachable including sourceforge.net, so no commits).
Ok. Let me know if this patch need some more work and you prefer me to work on this a little bit more. However, it could be easier to commit small bunch of patch instead a big one. Easier to review as well. But it's a matter of taste :) .
@ioguix: The second of your patch was about to change handling of GEANY_AC_SQUOTE with end_pos which was IMO a typo and should have been in the GEANY_AC_SBRACKET, so I moved it there. Correct me if I'm wrong.
Oops, I'm confused...Thanks.
- can we really test if we are actually in a in string whatever the
current language style ?
Yes, but maybe not all filetypes are completely supported. See is_string_style() in editor.c.
Though this function treats all kinds of strings equally, that is for languages like C or Python where you have different kind of strings ('blah', "blah", ''' blag ''', ...) this function returns TRUE for all kinds. But you probably want something more fine-grained to differentiate between 'blah' and "blah".
Ok. This is a good start anyway. We could at least disabling auto-close quotes inside a string... However, I noticed simple quoted strings and double quoted strings are sometime highlighted with different colors (depending of the current language type, C doesn't, PHP does)...So I guess Scintilla parser has some internal mechanism to handle this.
@nick: If we can do this using a plugin, I think it is do-able...I'm not really closed to the idea as I thought maybe we could fine tune this kind of feature using some language oriented configuration. Using a language oriented configuration plugin, we could do far more than just auto-closing quotes and brackets (don't ask me what tonight plz :P). I should admit however that I'm not very enclin presently to maintain such a plugin which needs a lot of work to be very interesting...
Regards, Enrico
-- Get my GPG key from http://www.uvena.de/pub.asc
On Tue, 16 Dec 2008 04:58:48 +0100 (CET) ioguix@free.fr wrote:
Though this function treats all kinds of strings equally, that is for languages like C or Python where you have different kind of strings ('blah', "blah", ''' blag ''', ...) this function returns TRUE for all kinds. But you probably want something more fine-grained to differentiate between 'blah' and "blah".
Ok. This is a good start anyway. We could at least disabling auto-close quotes inside a string... However, I noticed simple quoted strings and double quoted strings are sometime highlighted with different colors (depending of the current language type, C doesn't, PHP does)...So I guess Scintilla parser has some internal mechanism to handle this.
Yes, the sci_get_style_at() function returns an enum value specific to each lexer.
@nick: If we can do this using a plugin, I think it is do-able...I'm not
It doesn't need to be a plugin, at least not yet. Maybe I shouldn't have mentioned it ;-) It's might be better in the core at first so you can use core-only functions.
really closed to the idea as I thought maybe we could fine tune this kind of feature using some language oriented configuration. Using a language oriented configuration plugin, we could do far more than just auto-closing quotes and brackets (don't ask me what tonight plz :P). I should admit however that I'm not very enclin presently to maintain such a plugin which needs a lot of work to be very interesting...
Regards, Nick
On Tue, 16 Dec 2008 04:58:48 +0100 (CET), ioguix@free.fr wrote:
On Mon, 15 Dec 2008, Enrico Tröger wrote:
On Mon, 15 Dec 2008 13:12:54 +0000, Nick Treleaven nick.treleaven@btinternet.com wrote:
On Tue, 9 Dec 2008 05:14:08 +0100 (CET) ioguix@free.fr wrote:
In a first step, when opening a brace (ie. ( { [ ), we could check if no closing brace already match it before auto-closing it. That what I tried to do in the attached patch.
I actually worked on the patch yesterday but had some weird connectivity issues (some sites weren't reachable including sourceforge.net, so no commits).
Ok. Let me know if this patch need some more work and you prefer me to work on this a little bit more. However, it could be easier to commit small bunch of patch instead a big one. Easier to review as well. But it's a matter of taste :) .
Sure, I already committed your patch on Monday.
- can we really test if we are actually in a in string whatever the
current language style ?
Yes, but maybe not all filetypes are completely supported. See is_string_style() in editor.c.
Though this function treats all kinds of strings equally, that is for languages like C or Python where you have different kind of strings ('blah', "blah", ''' blag ''', ...) this function returns TRUE for all kinds. But you probably want something more fine-grained to differentiate between 'blah' and "blah".
Ok. This is a good start anyway. We could at least disabling auto-close quotes inside a string... However, I noticed simple quoted strings and double quoted strings are sometime highlighted with different colors (depending of the current language type, C doesn't, PHP does)...So I guess Scintilla parser has some internal mechanism to handle this.
More exactly: the lexers for different languages handle strings differently, mostly according to the language specs. E.g. in C, "blah" is something different than 'blah' though they are coloured the same in Geany. But these are two different styles, you could change the colours in your local config and so you can also differentiate them in the code (SCE_C_STRING vs. SCE_C_CHARACTER). Similar for other languages/lexers but some handle different kinds of string equally, IIRC. But in those cases there is also no need to differentiate them for brace completion.
Regards, Enrico