Tab-related bugs in devel and master

[Edward K. Ream]

The fix to #1731 has created a new bug. With the default bindings, it is not possible to insert whitespace at the end of the line by typing a tab. Instead:

- Typing a tab character anywhere on a line inserts leading whitespace (lws).

- When multiple lines are selected, a tab character increases the lws of all selected lines.

Background

Leo 6.3 substantially revised how Leo handles all incoming keystrokes. As the result of those changes, the indent region command (in commanderEditCommands.py) contains the following dubious code:

if sel_1 == sel_2:
     c.editCommands.selfInsertCommand(event)
     return

This kinda works. In particular, it (mostly) works when indent-region is bound to the tab character, which is the default binding. However, the hack requires that existing users change their bindings, as reported here.

Handling tabs and insert-region

Editors typically do the following with tabs:

- When multiple lines are selected, a tab indents those lines.

- When there is no selection, a tab inserts a (hard or soft) tab a the insertion point.

- When there is a selection on a single line, a tab replaces that selection.

Alas, Leo has no way to change key bindings based on the selection range. This means that tab (indent-region) must handle the special cases list above.

Handling shift-tab and unindent region

Editors typically do the following:

- Shift-tab unindents all selected lines.

- Shift-tab unindents one line if there is no selection or the selection doesn't cross lines.

This is much easier to handle because Shift-tab is not an "insertable" character.

Summary

The code in devel does not properly handle tab characters at the end of a line. Ditto for the ekr-undo branch, which is based on devel. Ditto for Leo 6.3 in the master branch.

The indent-region command must handle the special cases listed above. More complex tests will be required. I have just reopened #1731.

All comments welcome.

Edward

[gar]

but at the same time editors typically have shortcuts to indent single line despite where the cursor is with a single keypress.

afair leo didnt, and it was a pain (some more key pressing to select a line, which leo surprisingly cannt do from the middle of the line too - so user must first move cursor to the very beginning of the line)

so to be like all other editors leo should have 2 commands: indent-region and indent-line

i use your current fix w/o special handling of tabs and I am VERY happy! i vote not to change it.

вт, 17 нояб. 2020 г. в 19:20, Edward K. Ream <edre...@gmail.com>:

--
You received this message because you are subscribed to the Google Groups "leo-editor" group.
To unsubscribe from this group and stop receiving emails from it, send an email to leo-editor+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/leo-editor/191afa5a-95ef-4fc6-82cd-a92fd74d8f0dn%40googlegroups.com.

[Edward K. Ream]

On Wed, Nov 18, 2020 at 1:47 AM gar <gar...@gmail.com> wrote:

so to be like all other editors leo should have 2 commands: indent-region and indent-line.

Good idea.

i use your current fix w/o special handling of tabs and I am VERY happy! i vote not to change it.

What do you mean by "the current fix w/o special handling of tabs"?

In any case, something has to be done so that tabs can be inserted in lines :-)

Edward

[gar]

What do you mean by "the current fix w/o special handling of tabs"?

I merged your commits where any 'tab' causes the whole line indentation - and I love this behavior

 

In any case, something has to be done so that tabs can be inserted in lines :-)

For me (and this is my private opinion) it'll be enough to have another command - `indent-line` - which I''l be able to bind to say 'ctrl >' 

Having this option I wont be worrying about what does 'tab' key actually do

 

Well, a few offtop lines. I use leo for a long time - about an year, I believe. And I love it more and more. But I'd love have  most of the vim commands - and complicated indentation is must have. Also I want more versatile select commands - select whatever in braces/quotes/..., goto to the maching brace, goto the closes symbol etc. Now I have to make too many mouse movements for simple tasks.

[Edward K. Ream]

On Wed, Nov 18, 2020 at 2:47 AM gar <gar...@gmail.com> wrote:

What do you mean by "the current fix w/o special handling of tabs"?

 

I merged your commits where any 'tab' causes the whole line indentation - and I love this behavior

 

In any case, something has to be done so that tabs can be inserted in lines :-)

 

For me (and this is my private opinion) it'll be enough to have another command - `indent-line` - which I''l be able to bind to say 'ctrl >' 

Having this option I wont be worrying about what does 'tab' key actually do

The present code does not allow a tab to insert whitespace at the end of a line. This is jarring for me, and I suspect most users. I have just created #1739 for this issue. The work is in the ekr-indent branch.

The new code inserts a tab if the selection range is empty. Unlike 6.3, it only does this if the user actually typed a plain tab! PR 1740 shows the new code.

Therefore, Ctrl-Shift->, always indents the line, as you want. Note that Ctrl-Shift-> is already bound to indent-region, so my guess is that this should be good enough for you.

Please test the ekr-indent branch and tell me what you think.

Edward

[Edward K. Ream]

On Wed, Nov 18, 2020 at 2:47 AM gar <gar...@gmail.com> wrote:

I use leo for a long time - about an year, I believe. And I love it more and more. But I'd love have  most of the vim commands - and complicated indentation is must have. Also I want more versatile select commands - select whatever in braces/quotes/..., goto to the maching brace, goto the closes symbol etc. Now I have to make too many mouse movements for simple tasks.

Please file enhancement requests for the commands you would like. Thanks.

Edward

[gar]

Tested for a while. Looks like it works as I wanted, but you still have some misbehaviors:

1. when inserting TAB char - then cannot undo it (ctrl-z does nothing)

2. when single line is selected and ctrl-> or tab is pressed - two lines are indented (this is very old bug, I told you about it and even now do not understand why do you treat this as valid behavior)

3. when indenting a single line - cursor is moved to the beginning of it, which is uncommon (same with multiline indent)

4. seems like auto-indent after braces doesnt work anymore (but I'm not sure that it was not broken before)

ср, 18 нояб. 2020 г. в 13:02, Edward K. Ream <edre...@gmail.com>:

--

You received this message because you are subscribed to the Google Groups "leo-editor" group.
To unsubscribe from this group and stop receiving emails from it, send an email to leo-editor+...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/leo-editor/CAMF8tS1cRhcmpkeY5aM2-xsHY%2Bf-aRA0KvShXChf1rgXM3AbNQ%40mail.gmail.com.

[Edward K. Ream]

On Wed, Nov 18, 2020 at 4:17 AM gar <gar...@gmail.com> wrote:

Tested for a while. Looks like it works as I wanted, but you still have some misbehaviors:

Rev f666402 adds the always-indent-region command, which never adds a tab.

 

1. when inserting TAB char - then cannot undo it (ctrl-z does nothing)

Fixed at rev bdbdd8b.

2. when single line is selected and ctrl-> or tab is pressed - two lines are indented (this is very old bug, I told you about it and even now do not understand why do you treat this as valid behavior)

I don't see this.

 

3. when indenting a single line - cursor is moved to the beginning of it, which is uncommon (same with multiline indent)

I don't see exactly this. I do see that after indenting a region the last character isn't selected. This doesn't affect much, but I will correct it.

 

4. seems like auto-indent after braces doesnt work anymore (but I'm not sure that it was not broken before)

Please give an example.

Edward

[Edward K. Ream]

On Wednesday, November 18, 2020 at 6:13:53 AM UTC-6 Edward K. Ream wrote:

>> 3. when indenting a single line - cursor is moved to the beginning of it, which is uncommon (same with multiline indent)

> I don't see exactly this. I do see that after indenting a region the last character isn't selected. This doesn't affect much, but I will correct it.

Done at a9a7417 in ekr-indent.

Edward

[gar]

2. when single line is selected and ctrl-> or tab is pressed - two lines are indented (this is very old bug, I told you about it and even now do not understand why do you treat this as valid behavior)

I don't see this.

Put your cursor to the beginning of the line (position 0, not the first char). Hold shift, press down - the line is selected. Press tab - next line becomes selected and both of them are indented. What was expected? the only selected line is indented. 

3. when indenting a single line - cursor is moved to the beginning of it, which is uncommon (same with multiline indent)

I don't see exactly this. I do see that after indenting a region the last character isn't selected. This doesn't affect much, but I will correct it.

put cursor to the middle of the line, press ctrl> - line is indented but cursor moved to another position - to the beginning sometimes. 

4. seems like auto-indent after braces doesnt work anymore (but I'm not sure that it was not broken before)

Please give an example.

I remember that leo had a feature - when the node has @language and there are rules that after some symbols (like { for js)  newline also triggers indentation +1 - it happens

highlighting rules for js contain such a rule, but there is no indentation. but actually I am not sure if it should or not.

[Edward K. Ream]

On Wed, Nov 18, 2020 at 8:45 AM gar <gar...@gmail.com> wrote:

Put your cursor to the beginning of the line (position 0, not the first char). Hold shift, press down - the line is selected. Press tab - next line becomes selected and both of them are indented. What was expected?

Yes, this is expected. All lines with any selection at all are indented.

To get the behavior you want, press Shift-End instead of the Down arrow.

HTH.

Edward

[gar]

Leo does have a match-brackets command, which I have hot-keyed to Ctrl+]. It selects the region between a bracket and its matching one.  There is also add-comments/delete-comments,  which I find very helpful. goto-next-marked is another one I use often, along with mark/unmark-all.

Know about that. But that's not enough. It selects area in (...)  What about [], {}, // ? What about moving cursor to the matching symbol? Etc etc etc

[gar]

Put your cursor to the beginning of the line (position 0, not the first char). Hold shift, press down - the line is selected. Press tab - next line becomes selected and both of them are indented. What was expected?

Yes, this is expected. All lines with any selection at all are indented.

Other editors never do so.

 

To get the behavior you want, press Shift-End instead of the Down arrow.\

This is very expensive hand movement. Almost as expensive as mouse touching. Never do it, have to remember about such an odd manner and select minus one line.

[tbp1...@gmail.com]

On Wednesday, November 18, 2020 at 11:19:44 AM UTC-5 Edward K. Ream wrote:

On Wed, Nov 18, 2020 at 8:45 AM gar <gar...@gmail.com> wrote:

Put your cursor to the beginning of the line (position 0, not the first char). Hold shift, press down - the line is selected. Press tab - next line becomes selected and both of them are indented. What was expected?

Yes, this is expected. All lines with any selection at all are indented.

Most other editors I commonly use would act as follows, which is what I would like as well:

1. Put cursor at start of a line of text.

2. Select the line by pressing <SHIFT-DOWNARROW>.

3.  Press <TAB>.

Expected behavior - The single selected line gets indented.

Leo behavior - the selected line and the next one down get indented.

To get the behavior you want, press Shift-End instead of the Down arrow.

This isn't a good idea because other editors don't act this way.  Some editors that act as expected:

- Editplus

- Notepad++

- VSCode

- Pyzo

- Atom

Leo shouldn't require a different motor operation for such a common action.

 

Edward

[tbp1...@gmail.com]

match-brackets does work on [], and {} as well.  What kind of syntax regards "//" as bracket markers?.

[tbp1...@gmail.com]

I just checked <!--   -->, and match-brackets worked there, too. It didn't work for /*....*/ though, if that's what you meant by "//".

[tbp1...@gmail.com]

Looking in Leo's code, I see that the following are considered (end) brackets: )]}>

I'm not sure if the code would work right if the end marker were the same as the start marker (e.g., / ../).

See the constructor for class g.MatchBrackets.

[gar]

match-brackets does work on [], and {} as well.  What kind of syntax regards "//" as bracket markers?.

Oh, really? Didnt know that. And thus never used it in this way. Well, it's wonderful. But...

Do you know that if you have construction like `text(brackets{curly})` - the actual selection will depend on where your cursor is standing?

Say you'rу on letter 'r' of 'bracket' - the (...) would be selected. Say you're on 'e' - {...}.

Why? Because, that's why. 

And next - why WITH brackets? I dont want them, all my use cases do not want them to be selected. That's why actually I never use it - cause it selects also brackets. This is not what I expect command to do (compare with vim's `ci(`). This looks like if ctrl-w would select word WITH surrounding spaces. Who wants that?

And again. I miss not only __select the inner area__. I generally miss __move to the closest symbol (maybe even closing bracket)__. Selecting area surrounded by brackets is practically useless feature.

[gar]

See the constructor for class g.MatchBrackets.

I have a huge list of what to investigate (and maybe fix) in Leo's code. It is so huge that I aint even start - wont be able to pay that much time for it :-)

[Edward K. Ream]

On Wed, Nov 18, 2020 at 12:44 PM tbp1 wrote:

Most other editors I commonly use would act as follows, which is what I would like as well:

1. Put cursor at start of a line of text.

2. Select the line by pressing <SHIFT-DOWNARROW>.

3.  Press <TAB>.

Ok. I'm convinced. I've just created #1742. Note that the fix will be in getBodyLines, which affects several other commands.

Edward

[Edward K. Ream]

On Wed, Nov 18, 2020 at 1:46 PM gar <gar...@gmail.com> wrote:

I have a huge list of what to investigate (and maybe fix) in Leo's code. It is so huge that I aint even start - wont be able to pay that much time for it :-)

The place to start is to create an issue for every separate issue. Please be as clear as you can. Thomas's (tbp1) example convinced me. It would be wise to use his example as a model for other issues.

I make no promises about editor improvements during the sabbatical. The way to get things done is to do them yourself.

Edward

[gar]

Thanks. I'll try. But I have a barrier - my poor english. Sometimes I just cannt write what I actually mean. So some of my thoughts are going directly to the trash bin.

But thanks.

чт, 19 нояб. 2020 г. в 00:06, Edward K. Ream <edre...@gmail.com>:

--

You received this message because you are subscribed to the Google Groups "leo-editor" group.
To unsubscribe from this group and stop receiving emails from it, send an email to leo-editor+...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/leo-editor/CAMF8tS2kfJxfCgBAn1nk0eD903xfHJ61oc6scuQHfbC3gbpiCA%40mail.gmail.com.

[Edward K. Ream]

On Wed, Nov 18, 2020 at 8:42 PM gar <gar...@gmail.com> wrote:

Thanks. I'll try. But I have a barrier - my poor english. Sometimes I just cannt write what I actually mean. So some of my thoughts are going directly to the trash bin.

Hehe. Me too. Writing clearly takes focused intention and attention, in any language.

Writing in github issues helps, for several reasons. First, the fonts are gorgeous, which makes writing and revision fun. Second, it's dead easy to revise any comment, especially the first comment.

But thanks.

Let me emphasize that your ideas and critiques of Leo's commands are very important to me.  Hangnails infuriate users and give the mistaken impression that Leo is a low-quality product.

It's also important that you enjoy using vim. Only a "native" vim speaker will understand what's most important. I welcome any improvements to Leo's vim mode. I also welcome any stand-alone vim-like commands that you might suggest.

During my sabbatical I'll focus on learning new technologies, so I probably won't be starting new programming projects myself. However, I am always happy to discuss Leo's code base, offer advice, or handle pull requests.

Edward