For example, in the case of parentheses and fu(8); If one enables the "auto-close opening parenthesis" feature, then:
Instead of typing f u ( 8 ) ; ENTER he/she have to type f u ( 8 ARROW_RIGHT ; ENTER ?
Is this all the gain? (The same number of keystrokes..) (Or I am missing something?)
On Sat, 15 Sep 2018 at 08:46, e2qb2a44f@prolan-power.hu wrote:
For example, in the case of parentheses and fu(8); If one enables the "auto-close opening parenthesis" feature, then:
Instead of typing f u ( 8 ) ; ENTER he/she have to type f u ( 8 ARROW_RIGHT ; ENTER ?
Is this all the gain? (The same number of keystrokes..) (Or I am missing something?)
Yep. :)
Auto close is not to save typing.
The point of auto close parens and other brackety things is so the code remains likely to be reasonably valid whilst typing, so symbol parsers will still work. The parsers are fairly tolerant of invalid code (since they don't parse most of it) but they need brackets to match so they find the right matching one, otherwise they simply go to end of file and stop missing many of your symbols, and so stopping type highlighting working while you type.
Cheers Lex
--
Users mailing list Users@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/users
On Fri, Sep 14, 2018 at 7:06 PM Lex Trotman elextr@gmail.com wrote:
Auto close is not to save typing.
I absolutely agree with the above. However,
The point of auto close parens and other brackety things is so the code remains likely to be reasonably valid whilst typing, so symbol parsers will still work.
I think this varies a lot depending on the editor. Some editors seem to be affected much worse than others, and even in the same editor, some languages could be affected much worse than others.
One thing I noticed about Atom and Visual Studio Code, for example, is that when brackets are not closed, *some* of the highlighting still works but some doesn't. Also, neither one can actively detect that an open bracket is unmatched.
However, SciTE (which uses Scintilla, the same core as Geany and Notepad++) DOES detect unmatched open brackets.
Even if you buy into the idea that closed brackets are to help the editor work better, the increased inconvenience in typing is a fairly high price to pay. Editors are supposed to work for *us*, not the other way around.
John Y.
On Sat, 15 Sep 2018 at 09:33, John Yeung gallium.arsenide@gmail.com wrote:
On Fri, Sep 14, 2018 at 7:06 PM Lex Trotman elextr@gmail.com wrote:
Auto close is not to save typing.
I absolutely agree with the above. However,
The point of auto close parens and other brackety things is so the code remains likely to be reasonably valid whilst typing, so symbol parsers will still work.
I think this varies a lot depending on the editor. Some editors seem to be affected much worse than others, and even in the same editor, some languages could be affected much worse than others.
Of course, some syntaxes are easier to parse even with errors, some are not. Any parser can parse correct code, being tolerant of errors is "more difficult". IIUC Microsoft has spent "rather a lot" on the parsers used in full VS.
One thing I noticed about Atom and Visual Studio Code, for example, is that when brackets are not closed, *some* of the highlighting still works but some doesn't. Also, neither one can actively detect that an open bracket is unmatched.
However, SciTE (which uses Scintilla, the same core as Geany and Notepad++) DOES detect unmatched open brackets.
Scite only does syntactic highlighting, it doesn't parse declarations in the code. And Geany does detect unmatched brackets, although the default theme doesn't make them terribly visible (just bold). You can of course change the theme. And if you are editing inside say C code, a new open { will always match, its the one before it that does not appear to match to the Scintilla naive algorithm :)
Geany uses the ctags parsers to parse declarations to populate the symbols tab and to feed Scintilla the type lists to be highlighted, which Scite does not do. Parsing is more dependent on legal syntax, its noticeable that following symbols will often disappear from the symbols tab when unmatched brackets occur.
Even if you buy into the idea that closed brackets are to help the editor work better, the increased inconvenience in typing is a fairly high price to pay. Editors are supposed to work for *us*, not the other way around.
And thats why the feature can be turned off at the users discretion.
Cheers Lex
John Y. _______________________________________________ Users mailing list Users@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/users
On Fri, Sep 14, 2018 at 6:46 PM e2qb2a44f@prolan-power.hu wrote:
For example, in the case of parentheses and fu(8); If one enables the "auto-close opening parenthesis" feature, then:
Instead of typing f u ( 8 ) ; ENTER he/she have to type f u ( 8 ARROW_RIGHT ; ENTER ?
Is this all the gain? (The same number of keystrokes..) (Or I am missing something?)
I haven't used Geany in a while, but I doubt you are missing anything. It's quite tricky to get this feature really right, and I still haven't found any editor that does it the way I would like.
Today, you can sort of get closer with some editors, such as Sublime Text or Visual Studio Code. These will let you "type over" the closing bracket, so it's the *exact* same keystrokes that you would have typed without autoclose (in my opinion, much better than having to use arrow keys).
So the point of autoclosing brackets then is just to make sure you don't *forget* to close the bracket, rather than really saving keystrokes. See my answer to a VS Code question here:
https://stackoverflow.com/a/46370345/95852
But even this is not good for me, because (at least in the case of VS Code), it interacts with autoindentation to put the closing bracket out of reach:
https://github.com/Microsoft/vscode/issues/34861
When that happens, there is nothing you can do to get past the automatically generated closing bracket with normal typing; you have no choice but to use arrow or mouse navigation.
So if you prefer typing normally, without jumping back and forth between arrow keys and home row, then you are probably better served leaving this feature off.
John Y.
Le 15/09/2018 à 00:46, e2qb2a44f@prolan-power.hu a écrit :
For example, in the case of parentheses and fu(8); If one enables the "auto-close opening parenthesis" feature, then:
Instead of typing f u ( 8 ) ; ENTER he/she have to type f u ( 8 ARROW_RIGHT ; ENTER ?
Is this all the gain? (The same number of keystrokes..) (Or I am missing something?)
There's also an auto-close plugin, which I believe is behaving a little better that way (like removing auto-added matching chars when they get typed, etc.
Cheers, Colomban