Unfortunately Scintila which is the editing component used by Geany does not allow any distinction between types of operators. To add this you would have to edit the C++ code in Scintilla that parses the file for highlighting.
What I'd like to be able to do is have Geany UNindent a line that closes a statement in Lua .. i.e.
if x > 1 then y = 5 else y = 2 end -- automatically Unindent the 'end'
I know this can be done in Scintilla and SciTE has a set of properties that does this as well as some other editors that use scintilla but see no way to specify using certain keywords as such a do and end only the more standard operators like {} and (). Can this be done in Geany?
-- ~Doug It may be that my sole purpose in life is simply to serve as a warning to others.
On Sun, 01 Aug 2010 17:19:54 -0700, Doug wrote:
Unfortunately Scintila which is the editing component used by Geany does not allow any distinction between types of operators. To add this you would have to edit the C++ code in Scintilla that parses the file for highlighting.
What I'd like to be able to do is have Geany UNindent a line that closes a statement in Lua .. i.e.
if x > 1 then y = 5 else y = 2 end -- automatically Unindent the 'end'
I know this can be done in Scintilla and SciTE has a set of properties that does this as well as some other editors that use scintilla but see no way to specify using certain keywords as such a do and end only the more standard operators like {} and (). Can this be done in Geany?
As usual, this just needs to be implemented. It's quite independent from Scintilla itself, this is pure application logic. I think this could be done in a plugin, maybe as component of the addons plugin.
Regards, Enrico
2010/8/6 Enrico Tröger enrico.troeger@uvena.de:
On Sun, 01 Aug 2010 17:19:54 -0700, Doug wrote:
Unfortunately Scintila which is the editing component used by Geany does not allow any distinction between types of operators. To add this you would have to edit the C++ code in Scintilla that parses the file for highlighting.
What I'd like to be able to do is have Geany UNindent a line that closes a statement in Lua .. i.e.
if x > 1 then y = 5 else y = 2 end -- automatically Unindent the 'end'
I know this can be done in Scintilla and SciTE has a set of properties that does this as well as some other editors that use scintilla but see no way to specify using certain keywords as such a do and end only the more standard operators like {} and (). Can this be done in Geany?
As usual, this just needs to be implemented. It's quite independent from Scintilla itself, this is pure application logic. I think this could be done in a plugin, maybe as component of the addons plugin.
Hey Enrico,
I guess that Geany can always ignore the fold info coming from the Scintilla lexer, but what would you propose as the algorithm. When to follow Scintilla and when to ignore it?
Cheers Lex
Regards, Enrico
-- Get my GPG key from http://www.uvena.de/pub.asc
Geany mailing list Geany@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany
On Fri, Aug 6, 2010 at 00:20, Lex Trotman elextr@gmail.com wrote:
2010/8/6 Enrico Tröger enrico.troeger@uvena.de:
On Sun, 01 Aug 2010 17:19:54 -0700, Doug wrote:
Unfortunately Scintila which is the editing component used by Geany does not allow any distinction between types of operators. To add this you would have to edit the C++ code in Scintilla that parses the file for highlighting.
What I'd like to be able to do is have Geany UNindent a line that closes a statement in Lua .. i.e.
if x > 1 then y = 5 else y = 2 end -- automatically Unindent the 'end'
I know this can be done in Scintilla and SciTE has a set of properties that does this as well as some other editors that use scintilla but see no way to specify using certain keywords as such a do and end only the more standard operators like {} and (). Can this be done in Geany?
As usual, this just needs to be implemented. It's quite independent from Scintilla itself, this is pure application logic. I think this could be done in a plugin, maybe as component of the addons plugin.
Hey Enrico,
I guess that Geany can always ignore the fold info coming from the Scintilla lexer, but what would you propose as the algorithm. When to follow Scintilla and when to ignore it?
From what I see in the sources, scintilla only says how much to indent
but it's geany itself who decides whether to indent or not.
Cheers,
Jiri
Cheers Lex
Regards, Enrico
-- Get my GPG key from http://www.uvena.de/pub.asc
Geany mailing list Geany@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany
Geany mailing list Geany@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany
On 6 August 2010 09:01, Jiří Techet techet@gmail.com wrote:
On Fri, Aug 6, 2010 at 00:20, Lex Trotman elextr@gmail.com wrote:
2010/8/6 Enrico Tröger enrico.troeger@uvena.de:
On Sun, 01 Aug 2010 17:19:54 -0700, Doug wrote:
Unfortunately Scintila which is the editing component used by Geany does not allow any distinction between types of operators. To add this you would have to edit the C++ code in Scintilla that parses the file for highlighting.
What I'd like to be able to do is have Geany UNindent a line that closes a statement in Lua .. i.e.
if x > 1 then y = 5 else y = 2 end -- automatically Unindent the 'end'
I know this can be done in Scintilla and SciTE has a set of properties that does this as well as some other editors that use scintilla but see no way to specify using certain keywords as such a do and end only the more standard operators like {} and (). Can this be done in Geany?
As usual, this just needs to be implemented. It's quite independent from Scintilla itself, this is pure application logic. I think this could be done in a plugin, maybe as component of the addons plugin.
Hey Enrico,
I guess that Geany can always ignore the fold info coming from the Scintilla lexer, but what would you propose as the algorithm. When to follow Scintilla and when to ignore it?
From what I see in the sources, scintilla only says how much to indent but it's geany itself who decides whether to indent or not.
Cheers,
Jiri
Disregard previous comment, I was confusing it with something else and the answer is kinda scrambled :-D.
I agree that indenting currently doesn't work well. For {} languages if there is anything on the line after the { then indenting fails to work right. And as you say Python really gets no help either.
There is a hard coded special case for Perl that seems to cause some of these problems. Also currently I think { in comments can affect indenting.
Your idea of per language regexes sounds good, and I'd suggest using the Scintilla style to avoid checking within comments and strings.
Cheers Lex
Cheers Lex
Regards, Enrico
-- Get my GPG key from http://www.uvena.de/pub.asc
Geany mailing list Geany@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany
Geany mailing list Geany@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany
Geany mailing list Geany@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany
2010/8/5 Enrico Tröger enrico.troeger@uvena.de:
On Sun, 01 Aug 2010 17:19:54 -0700, Doug wrote:
Unfortunately Scintila which is the editing component used by Geany does not allow any distinction between types of operators. To add this you would have to edit the C++ code in Scintilla that parses the file for highlighting.
What I'd like to be able to do is have Geany UNindent a line that closes a statement in Lua .. i.e.
if x > 1 then y = 5 else y = 2 end -- automatically Unindent the 'end'
I know this can be done in Scintilla and SciTE has a set of properties that does this as well as some other editors that use scintilla but see no way to specify using certain keywords as such a do and end only the more standard operators like {} and (). Can this be done in Geany?
As usual, this just needs to be implemented. It's quite independent from Scintilla itself, this is pure application logic. I think this could be done in a plugin, maybe as component of the addons plugin.
By coincidence, I have been playing with TextMate under MacOS and it has an extremely elegant system of indent detection, see:
http://manual.macromates.com/en/appendix#indentation_rules
This is extremely flexible because the indent and unindent conditions can be set based on per-language regular expressions (and not like now hardcoded for languages with braces and python). I think that geany's way of indent detection could be completely substituted by this - in fact, I think that this would actually reduce the amount of code needed because you would just do matches against the regular expressions instead of checking the lines character by character. The patterns could be set for every language e.g. in filetype_extensions.conf.
Some observations from playing with TextMate: 1. increaseNextLinePattern is not normally used, see
http://ticket.macromates.com/show?ticket_id=425D3D1C
so we could drop it.
2. decreaseIndentPattern appears to be matched against the current line after every single keypress (e.g. once you type ':' in "elsif:" in python, the line containing it unindents). Apparently regex matching is fast enough to do this. The other patterns are matched only when enter is pressed.
From playing with the editor this system seems to work really well. I
think we could even steal the patterns from it - I wonder how much illegal/unethical it is to copy configuration options from a commercial editor...
What is your opinion about this?
(By the way, TextMate is a really nice editor with similar scope as Geany and there are definitely lessons Geany could learn from it [but vice versa too])
Regards,
Jiri
Regards, Enrico
-- Get my GPG key from http://www.uvena.de/pub.asc
Geany mailing list Geany@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany
On Thu, Aug 5, 2010 at 6:54 PM, Jiří Techet techet@gmail.com wrote:
By coincidence, I have been playing with TextMate under MacOS and it has an extremely elegant system of indent detection, see:
It does seem elegant. I actually have wondered why there aren't more editors that do this, and I had always thought maybe it was just not as fast to use regexes. But I could be wrong, and even if regexes are indeed slower, they might certainly be Fast Enough (tm) on today's computers.
Some observations from playing with TextMate:
- increaseNextLinePattern is not normally used, see
http://ticket.macromates.com/show?ticket_id=425D3D1C
so we could drop it.
I disagree. The bracketless if-statement (or other single-line "blocks") is extremely common, and SciTE has relatively ugly code just to handle that case.
- decreaseIndentPattern appears to be matched against the current
line after every single keypress (e.g. once you type ':' in "elsif:" in python, the line containing it unindents). Apparently regex matching is fast enough to do this. The other patterns are matched only when enter is pressed.
Well, Python uses elif, not elsif. But aside from that, Python is a very special case. It would be more natural for Python to not have any automatic decreases, since your elif might apply to not the latest if but rather a previous one (more than one level deep). In Python, it really makes sense for the programmer to explicitly decide the amount of de-indentation, and Python programmers are used to making this decision for every single block. It would be very weird to have elif be an oddball that doesn't fall in line with everything else in the language.
For the record, Python should be a very easy language to get right with the autoindentation, and it is kind of surprising how many editors still manage to mess it up. If I recall correctly, last time I used Geany (several versions ago), it handled Python quite well (either perfectly, or only quite unlikely situations could mess it up).
I wonder how much illegal/unethical it is to copy configuration options from a commercial editor...
In my opinion, it is not unethical at all. I would not want to be a part of copying or stealing someone else's not-open-source source code, but I have no problem with the idea of reimplementing a published spec. I don't know if the law agrees with me.
John
On 6 August 2010 17:46, John Yeung gallium.arsenide@gmail.com wrote:
On Thu, Aug 5, 2010 at 6:54 PM, Jiří Techet techet@gmail.com wrote:
By coincidence, I have been playing with TextMate under MacOS and it has an extremely elegant system of indent detection, see:
It does seem elegant. I actually have wondered why there aren't more editors that do this, and I had always thought maybe it was just not as fast to use regexes. But I could be wrong, and even if regexes are indeed slower, they might certainly be Fast Enough (tm) on today's computers.
Glib regex uses PCRE which seems to have reasonable performance (From Boost Regex performance comparisons with other regex engines) where times are sub .001 sec for files about the length of Geany source files. I'd say that was Fast Enough (C).
Some observations from playing with TextMate:
- increaseNextLinePattern is not normally used, see
http://ticket.macromates.com/show?ticket_id=425D3D1C
so we could drop it.
I disagree. The bracketless if-statement (or other single-line "blocks") is extremely common, and SciTE has relatively ugly code just to handle that case.
- decreaseIndentPattern appears to be matched against the current
line after every single keypress (e.g. once you type ':' in "elsif:" in python, the line containing it unindents). Apparently regex matching is fast enough to do this. The other patterns are matched only when enter is pressed.
Well, Python uses elif, not elsif. But aside from that, Python is a very special case. It would be more natural for Python to not have any automatic decreases, since your elif might apply to not the latest if but rather a previous one (more than one level deep). In Python, it really makes sense for the programmer to explicitly decide the amount of de-indentation,
I agree with that, Geany does my Python fine because it doesn't get in the way, but some may like additional "help". So long as I can turn it off per language too.
and Python programmers are used to making
this decision for every single block. It would be very weird to have elif be an oddball that doesn't fall in line with everything else in the language.
For the record, Python should be a very easy language to get right with the autoindentation, and it is kind of surprising how many editors still manage to mess it up. If I recall correctly, last time I used Geany (several versions ago), it handled Python quite well (either perfectly, or only quite unlikely situations could mess it up).
I wonder how much illegal/unethical it is to copy configuration options from a commercial editor...
In my opinion, it is not unethical at all. I would not want to be a part of copying or stealing someone else's not-open-source source code, but I have no problem with the idea of reimplementing a published spec. I don't know if the law agrees with me.
Too complicated since it is likely that it depends on which country you are in as to legality. But I would observe that there is likely to be only one optimal regex for each language for each setting so even from first principles you will likely get the same answer ;-)
Cheers Lex
John _______________________________________________ Geany mailing list Geany@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany
On Fri, Aug 6, 2010 at 10:42, Lex Trotman elextr@gmail.com wrote:
On 6 August 2010 17:46, John Yeung gallium.arsenide@gmail.com wrote:
On Thu, Aug 5, 2010 at 6:54 PM, Jiří Techet techet@gmail.com wrote:
By coincidence, I have been playing with TextMate under MacOS and it has an extremely elegant system of indent detection, see:
It does seem elegant. I actually have wondered why there aren't more editors that do this, and I had always thought maybe it was just not as fast to use regexes. But I could be wrong, and even if regexes are indeed slower, they might certainly be Fast Enough (tm) on today's computers.
Glib regex uses PCRE which seems to have reasonable performance (From Boost Regex performance comparisons with other regex engines) where times are sub .001 sec for files about the length of Geany source files. I'd say that was Fast Enough (C).
That sounds really good. Of course the exact numbers depend on for how long the regex is a candidate to match a line - the results will be better if it fails on the first character in every line than on the last character. But since we will be matching against a single line, this should be a non-issue.
Some observations from playing with TextMate:
- increaseNextLinePattern is not normally used, see
http://ticket.macromates.com/show?ticket_id=425D3D1C
so we could drop it.
I disagree. The bracketless if-statement (or other single-line "blocks") is extremely common, and SciTE has relatively ugly code just to handle that case.
- decreaseIndentPattern appears to be matched against the current
line after every single keypress (e.g. once you type ':' in "elsif:" in python, the line containing it unindents). Apparently regex matching is fast enough to do this. The other patterns are matched only when enter is pressed.
Well, Python uses elif, not elsif. But aside from that, Python is a very special case. It would be more natural for Python to not have any automatic decreases, since your elif might apply to not the latest if but rather a previous one (more than one level deep). In Python, it really makes sense for the programmer to explicitly decide the amount of de-indentation,
I agree with that, Geany does my Python fine because it doesn't get in the way, but some may like additional "help". So long as I can turn it off per language too.
and Python programmers are used to making
this decision for every single block. It would be very weird to have elif be an oddball that doesn't fall in line with everything else in the language.
For the record, Python should be a very easy language to get right with the autoindentation, and it is kind of surprising how many editors still manage to mess it up. If I recall correctly, last time I used Geany (several versions ago), it handled Python quite well (either perfectly, or only quite unlikely situations could mess it up).
I wonder how much illegal/unethical it is to copy configuration options from a commercial editor...
In my opinion, it is not unethical at all. I would not want to be a part of copying or stealing someone else's not-open-source source code, but I have no problem with the idea of reimplementing a published spec. I don't know if the law agrees with me.
Too complicated since it is likely that it depends on which country you are in as to legality. But I would observe that there is likely to be only one optimal regex for each language for each setting so even from first principles you will likely get the same answer ;-)
Well, after some more exploration this looks quite good. The bundles SVN for TextMate is here:
http://svn.textmate.org/trunk/
and the license says this:
http://svn.textmate.org/trunk/LICENSE
Under tags you can find settings for all the files:
http://svn.textmate.org/tags/release_1.1b5/
including indentation settings. So I think we could use it, at least as a base for further customization if we are not satisfied with the settings.
Cheers,
Jiri
Cheers Lex
John _______________________________________________ Geany mailing list Geany@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany
Geany mailing list Geany@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany
On Fri, Aug 6, 2010 at 09:46, John Yeung gallium.arsenide@gmail.com wrote:
On Thu, Aug 5, 2010 at 6:54 PM, Jiří Techet techet@gmail.com wrote:
By coincidence, I have been playing with TextMate under MacOS and it has an extremely elegant system of indent detection, see:
It does seem elegant. I actually have wondered why there aren't more editors that do this, and I had always thought maybe it was just not as fast to use regexes. But I could be wrong, and even if regexes are indeed slower, they might certainly be Fast Enough (tm) on today's computers.
Some observations from playing with TextMate:
- increaseNextLinePattern is not normally used, see
http://ticket.macromates.com/show?ticket_id=425D3D1C
so we could drop it.
I disagree. The bracketless if-statement (or other single-line "blocks") is extremely common, and SciTE has relatively ugly code just to handle that case.
Well, TextMate doesn't use them either. The problem is that you may get too "eager" indents (see the above link) which is, as you correctly say below, worse than not indenting at all. What I like about geany is that it doesn't try to be too smart, which is the problem of other editors that in 95pct do the smart thing correctly but those 5pct cases are extremely annoying.
- decreaseIndentPattern appears to be matched against the current
line after every single keypress (e.g. once you type ':' in "elsif:" in python, the line containing it unindents). Apparently regex matching is fast enough to do this. The other patterns are matched only when enter is pressed.
Well, Python uses elif, not elsif. But aside from that, Python is a
Typical 1AM email :-).
very special case. It would be more natural for Python to not have any automatic decreases, since your elif might apply to not the latest if but rather a previous one (more than one level deep). In Python, it really makes sense for the programmer to explicitly decide the amount of de-indentation, and Python programmers are used to making this decision for every single block. It would be very weird to have elif be an oddball that doesn't fall in line with everything else in the language.
Agree - this is what TextMate does but geany probably shouldn't do that.
Jiri