hi everyone. my name is avi and i am a BSc CS student nearing the end of my first year of university. i really like geany and am interested in contributing to the project. i have an average knowledge in C and basic knowledge in C++, but have some experience working in collaboration with other devs on an existing code base. i'm also pretty good at figuring things out as i go along, so hopefully i'll be able to be of use without making too much of a mess :P.
there are a couple of things i would like to add to geany: 1) brace balancing - the current behavior is to auto-close a brace with no neighboring closing brace ("{" becomes "{}", but "{{}" remains "{{}" and not "{{}}"). i looked through the code that handles brace auto-closing, and noticed that braces aren't closed blindly, unlike quotes. i assume this difference is either because scintilla doesn't offer quote balancing (i didn't look though) or to try to prevent the code from being littered by accidental braces. i like the use of brace-matching, so i'm not suggesting to make braces close blindly, but am looking into adding a brace-balance calculation function. 2) an optional closing-character-overwrite (with toggleable preference) - i like the brace\quotes autocomplete features, but will sometimes close braces\quotes myself (so i type both "{" and "}") and would like the option to have geany overwrite the auto-closed brace (so if i type "{}" the result will be "{}" and not "{}}" like it is now) and the same for quotes (so " ' ' " doesn't become " ' ' ' ' "). this preference would use brace-balancing to decide when to overwrite a closing character (so when adding a "}" to "{{@}" where the @ is, no overwrite would occur, and the result would be "{{}}").
i am having trouble deciding how to implement the brace-balancing: on the one hand, the code for this would be very similar to the scintilla method Document::BraceMatch(), with the difference of returning a value indicating the balance (for example, 1 if opening braces > closing braces, 0 if even, -1 if opening < closing) instead of the index of the matching brace. so it would seem natural to write the function in scintilla, but that would require adding an api to the method and adding a scintilla wrapper for it in geany, which seems like overkill for a function that has only 1 use case (that i can think of. when else would i want to know if braces are balanced, other than when trying to balance them...?). on the other hand, by looking over the scintillaWrappers file in geany, i think it would be messy to implement the same thing directly in geany instead of in scintilla.
are these features that you would like added to geany (cause if not, i would just make a messy fix for myself and be done with it :P)? if so, any suggestions regarding my dilema?
cheers, avi.
Hi Avi,
On 6 May 2010 08:28, Avi Hayoun iceman400@gmail.com wrote:
hi everyone. my name is avi and i am a BSc CS student nearing the end of my first year of university. i really like geany and am interested in contributing to the project. i have an average knowledge in C and basic knowledge in C++, but have some experience working in collaboration with other devs on an existing code base. i'm also pretty good at figuring things out as i go along, so hopefully i'll be able to be of use without making too much of a mess :P.
there are a couple of things i would like to add to geany:
- brace balancing - the current behavior is to auto-close a brace with
no neighboring closing brace ("{" becomes "{}", but "{{}" remains "{{}" and not "{{}}")
Yes, if any brace is already followed by a matching close (matching after taking into account any following open braces) then an extra isn't added. As you say, that doesn't mean that braces balance in the file, but if they don't balance where do you put the close?? If I have { { } } and I add a brace at position 3 giving { { { } } do I want { {} { } } or do I want { { { } } }?? So the current behaviour of not adding anything other than for level one open braces is probably better.
. i looked through the code that handles brace auto-closing, and noticed that braces aren't closed blindly, unlike quotes. i assume this difference is either because scintilla doesn't offer quote balancing (i didn't look though) or to try to prevent the code from being littered by accidental braces.
Quotes don't have different open and close characters so balancing is a different concept. And because following text is styled as a string, missing close quotes are reasonably visible.
i like the use of brace-matching, so i'm not suggesting to make braces close blindly, but am looking into adding a brace-balance calculation function.
This would require either to scan the whole file to find if it is balanced in respect of the newly added open brace or storing brace level with each brace so the scan is limited. Scanning will have to be done in Scintilla because it has the information to ignore braces in strings and comments, so level saving probably should be done there as well.
- an optional closing-character-overwrite (with toggleable preference) - i
like the brace\quotes autocomplete features, but will sometimes close braces\quotes myself (so i type both "{" and "}") and would like the option to have geany overwrite the auto-closed brace (so if i type "{}" the result will be "{}" and not "{}}" like it is now)
Could be useful for the fast fingered independent of other changes. Maybe patch this for a start, what do others think?
and the same for quotes (so " ' ' " doesn't become " ' ' ' ' "). this preference would use brace-balancing to decide when to overwrite a closing character (so when adding a "}" to "{{@}" where the @ is, no overwrite would occur, and the result would be "{{}}").
i am having trouble deciding how to implement the brace-balancing: on the one hand, the code for this would be very similar to the scintilla method Document::BraceMatch(), with the difference of returning a value indicating the balance (for example, 1 if opening braces > closing braces, 0 if even, -1 if opening < closing) instead of the index of the matching brace. so it would seem natural to write the function in scintilla, but that would require adding an api to the method and adding a scintilla wrapper for it in geany, which seems like overkill for a function that has only 1 use case (that i can think of. when else would i want to know if braces are balanced, other than when trying to balance them...?). on the other hand, by looking over the scintillaWrappers file in geany, i think it would be messy to implement the same thing directly in geany instead of in scintilla.
are these features that you would like added to geany (cause if not, i would just make a messy fix for myself and be done with it :P)?
As i said above I think you would have to do it in Scintilla (or the language lexer???).
if so, any suggestions regarding my dilema?
Remember if its in Geany it has to work for different languages, not just C/C++ so it must interact properly with the lexer which Scintilla does.
Cheers Lex
cheers, avi.
Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
On Thu, May 6, 2010 at 04:54, Lex Trotman elextr@gmail.com wrote:
there are a couple of things i would like to add to geany:
- brace balancing - the current behavior is to auto-close a brace with
no neighboring closing brace ("{" becomes "{}", but "{{}" remains "{{}" and not "{{}}")
Yes, if any brace is already followed by a matching close (matching after taking into account any following open braces) then an extra isn't added. As you say, that doesn't mean that braces balance in the file, but if they don't balance where do you put the close?? If I have { { } } and I add a brace at position 3 giving { { { } } do I want { {} { } } or do I want { { { } } }?? So the current behaviour of not adding anything other than for level one open braces is probably better.
this unwanted behavior you describe is to some extent already in place in geany - given a string "(...)", when adding a new "(" to the left of the string, scintilla will return -1 for bracematching and so geany will add a ")" automatically, which results in "()(...)". but i may have wanted to produce "((...))". all the same, the example you gave is a good argument against my suggested change. for me personally, coupling brace-balancing with allowing users to wrap the current selection in braces (similar to the "comment current line" feature) would be a good solution. i would like to hear thoughts on the matter.
i like the use of brace-matching, so i'm not suggesting to make braces close blindly, but am looking into adding a brace-balance calculation function.
Scanning will have to be done in Scintilla because it has the information to ignore braces in strings and comments, so level saving probably should be done there as well.
this is true to a limited extent. both in geany 0.18 and in the trunk version, when 2 matching braces are separated by a 3rd brace in a string or in a comment, the correct pair are colored as matching. however, if there is a closing brace in a comment or string and an opening brace is added before the comment/string, the brace will not auto-close. i think i'll have a look at this to try and find out why this is happening.
kind regards, avi
On 6 May 2010 18:54, Avi Hayoun iceman400@gmail.com wrote:
On Thu, May 6, 2010 at 04:54, Lex Trotman elextr@gmail.com wrote:
there are a couple of things i would like to add to geany:
- brace balancing - the current behavior is to auto-close a brace with
no neighboring closing brace ("{" becomes "{}", but "{{}" remains "{{}" and not "{{}}")
Yes, if any brace is already followed by a matching close (matching after taking into account any following open braces) then an extra isn't added. As you say, that doesn't mean that braces balance in the file, but if they don't balance where do you put the close?? If I have { { } } and I add a brace at position 3 giving { { { } } do I want { {} { } } or do I want { { { } } }?? So the current behaviour of not adding anything other than for level one open braces is probably better.
this unwanted behavior you describe is to some extent already in place in geany - given a string "(...)", when adding a new "(" to the left of the string, scintilla will return -1 for bracematching and so geany will add a ")" automatically, which results in "()(...)". but i may have wanted to produce "((...))". all the same, the example you gave is a good argument against my suggested change. for me personally, coupling brace-balancing with allowing users to wrap the current selection in braces (similar to the "comment current line" feature) would be a good solution. i would like to hear thoughts on the matter.
That would be good. Could you think about how it would interact with indentation, any benefit from adding braces quickly would be swiftly lost if it takes a lot of effort to get the layout right. And users see a feature that "always" produces the wrong answer as worse than no feature, they demand it be fixed :-)
i like the use of brace-matching, so i'm not suggesting to make braces close blindly, but am looking into adding a brace-balance calculation function.
Scanning will have to be done in Scintilla because it has the information to ignore braces in strings and comments, so level saving probably should be done there as well.
this is true to a limited extent. both in geany 0.18 and in the trunk version, when 2 matching braces are separated by a 3rd brace in a string or in a comment, the correct pair are colored as matching. however, if there is a closing brace in a comment or string and an opening brace is added before the comment/string, the brace will not auto-close. i think i'll have a look at this to try and find out why this is happening.
Yeah, weird.
kind regards, avi
Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
On Thu, 6 May 2010 19:16:44 +1000, Lex wrote:
Hey,
welcome Avi.
I didn't really followed the thread so far but feel free to improve the current behaviour. Patches are welcome.
But one little advice: continue the discussion about this in a new thread or change the subject of the existing thread, otherwise it's too confusing. Thanks.
Regards, Enrico