left/right arrow behavior inconsistent with "Cursor beyond end of line"

[mc-butler]

Important

This issue was migrated from Trac:

Origin	https://midnight-commander.org/ticket/1801
Reporter	ossi (@ossilator)

enabling "Cursor beyond end of line" stops the right-arrow from wrapping into the next line. however, the left-arrow continues to wrap to the previous line. this feels highly unnatural and often causes "navigation challenges". so enabling this option should make the left-arrow stop at the beginning of the line.

Note

Original attachments:

• 0001-don-t-allow-cursor-to-wrap-at-BOL-in-cursor_beyond_e.patch (raw) by ossi (@ossilator) on Oct 14, 2020 at 12:01 UTC

[mc-butler]

Changed by angel_il (@ilia-maslakov) on Nov 7, 2009 at 16:03 UTC (comment 1)

i think it's intuitive behaviour.

[mc-butler]

Changed by angel_il (@ilia-maslakov) on Dec 23, 2009 at 6:44 UTC (comment 2)

• Resolution set to wontfix
• Status changed from new to closed

[mc-butler]

Changed by ossi (@ossilator) on Dec 31, 2009 at 9:49 UTC (comment 3)

do you really *have* to be different than any other editor in use out there?

[mc-butler]

Changed by ossi (@ossilator) on Mar 9, 2010 at 7:48 UTC (comment 4)

i see that you copied that behavior from FAR, so it makes you different from every other editor BUT ONE. wow. what a remarkable precedent of braindamage ...

[mc-butler]

Changed by slavazanko (@slavaz) on Mar 9, 2010 at 22:03 UTC (comment 5)

i see that you copied that behavior from FAR, so it makes you different from every other
editor BUT ONE. wow. what a remarkable precedent of braindamage ...

You may switch off this behaviour:

• run mcedit
• F9 -> options -> general -> [ ] Cursor beyond end of line -> [< OK >]
• F9 -> options -> save setup

profit?

[mc-butler]

Changed by ossi (@ossilator) on Mar 9, 2010 at 22:32 UTC (comment 6)

no profit. you entirely missed the point.

--- a/src/editor/edit.c
+++ b/src/editor/edit.c
@@ -2128,8 +2128,11 @@ static void edit_left_char_move_cmd (WEdit * edit)
         if ( cw < 1 )
             cw = 1;
     }
-    if (option_cursor_beyond_eol && edit->over_col > 0) {
-        edit->over_col--;
+    if (option_cursor_beyond_eol) {
+        if (edit->over_col > 0)
+            edit->over_col--;
+        else if (edit->curs1 != edit_bol(edit, edit->curs1))
+            edit_cursor_move (edit, -cw);
     } else {
         edit_cursor_move (edit, -cw);
     }

[mc-butler]

Changed by angel_il (@ilia-maslakov) on Mar 10, 2010 at 6:08 UTC (comment 7)

• run mcedit
  • press home
  • F9 -> options -> general -> [ ] Cursor beyond end of line -> [< OK >]
  • F9 -> options -> save setup

profit? :)

and need fix trouble with 'over_col' you are right...

[mc-butler]

Changed by ossi (@ossilator) on Mar 10, 2010 at 21:06 UTC (comment 8)

sorry guys, are you a bit dense? do you understand what the patch does?

[mc-butler]

Changed by angel_il (@ilia-maslakov) on Mar 11, 2010 at 20:34 UTC (comment 9)

i'm so sorry, but i have not watched a patch, a lot of work on the my works... after the deadline, i see what's that.

[mc-butler]

Changed by angel_il (@ilia-maslakov) on Mar 11, 2010 at 20:46 UTC (comment 10)

• Status changed from closed to reopened
• Resolution wontfix deleted

[mc-butler]

Changed by angel_il (@ilia-maslakov) on Mar 19, 2010 at 6:09 UTC (comment 11)

• Status changed from reopened to closed
• Resolution set to wontfix

[mc-butler]

Changed by angel_il (@ilia-maslakov) on Mar 19, 2010 at 6:12 UTC (comment 12)

no profit. you entirely missed the point.

fixed in #2094

[mc-butler]

Changed by ossi (@ossilator) on Mar 19, 2010 at 7:44 UTC (comment 13)

• Status changed from closed to reopened
• Resolution wontfix deleted

no, not fixed. you still don't seem to understand what this is all about.

[mc-butler]

Changed by slavazanko (@slavaz) on Mar 19, 2010 at 7:57 UTC (comment 14)

Ossi, why you think, what cursor must wrap into the next line? Is this normal behavior? I think, current behavior very usefull for future feature 'drawing lines and boxes' (like it does good old MiltiEdit for DOS).

May be, need to add option info ini-file for change this behavior?... What you think?

[mc-butler]

Changed by slavazanko (@slavaz) on Mar 19, 2010 at 7:59 UTC (comment 15)

Typo-fix:

-May be, need to add option info ini-file for change this behavior?
+May be, need to add option into ini-file for change this behavior?

Sorry.

[mc-butler]

Changed by slavazanko (@slavaz) on Mar 19, 2010 at 8:04 UTC (comment 16)

Ossi: Ops, big sorry :) Now I fully understand about you say.

[mc-butler]

Changed by angel_il (@ilia-maslakov) on Mar 19, 2010 at 8:14 UTC (comment 17)

• Type changed from defect to enhancement

it's really not defect...
Ossi, you want option for cursor stop in first column?

[mc-butler]

Changed by ossi (@ossilator) on Mar 19, 2010 at 8:30 UTC (comment 18)

well, it is a low-impact usability defect. but call it what you will. :)
why would you want to add an option? what makes you think that anybody actually *wants* the current behavior? the wrong cursor movements resulting from the asymmetry easily outweight any possible speed gain from actively exploiting the behavior. the brain simply does not expect "right" not being the exact opposite of "left".

[mc-butler]

Changed by angel_il (@ilia-maslakov) on Mar 19, 2010 at 8:40 UTC (comment 19)

i am used to the current behavior, and it seems to me convenient. what you propose is very uncomfortable for me, but it is convenient for you... why do I want the option... probably to find a compromise...

[mc-butler]

Changed by ossi (@ossilator) on Mar 19, 2010 at 9:04 UTC (comment 20)

well, obviously you trained yourself so far that you can deal with it. one can get used to about everything, after all ...
however, i'd argue that you'd get used to the new behavior rather quickly and soon won't miss the old one. just try it - i'm in no hurry. :)

[mc-butler]

Changed by andrew_b (@aborodin) on Nov 1, 2011 at 16:52 UTC (comment 21)

• Milestone changed from 4.7 to Future Releases
• Branch state set to no branch

[mc-butler]

Changed by zaytsev (@zyv) on Oct 10, 2020 at 14:02 UTC (comment 22)

andrew_b, should we get this in? I'm not sure how other editors handle this in virtual space mode, but if everybody other than FAR behave this way, maybe it's a good idea.

[mc-butler]

Changed by angel_il (@ilia-maslakov) on Oct 12, 2020 at 23:05 UTC (comment 23)

Please do not apply that patch, this broke customary behavior, like a FAR.
may be need options - stop_cursor_on_BOL

---
I specifically wrote this code so that it was logical behavior. Yes, at now FAR has same behavior as mcedit.

[mc-butler]

Changed by ossi (@ossilator) on Oct 13, 2020 at 10:17 UTC (comment 24)

there is nothing "logical" about it. to convince someone, you need to make a coherent argument in favor of your expectations. my argument is consistency - both internal (symmetry in this case) and external (with most other editors that are out there). if you want compatibility with the obvious outlier you can have it, but the onus would be on you to implement said option to enable FAR-compatible behavior (and i'd argue that it should be a hidden one, as "littering" the UI with such mostly useless stuff degrades UX for the average user). but i for one would suggest the opposite route of pushing FAR to change its behavior (optionally, if they insist).

[mc-butler]

Changed by angel_il (@ilia-maslakov) on Oct 13, 2020 at 12:15 UTC (comment 25)

there is nothing "logical" about it.

try ANY text exitors? Notepad++, gedit, faredit, DosNavigator editor, and many (not vim).

[mc-butler]

Changed by ossi (@ossilator) on Oct 13, 2020 at 12:32 UTC (comment 26)

i just tried gedit, and quite unsurprisingly it doesn't do what you claim (it doesn't do cursor beyond and of line in the first place, and the UI contains no related options).
faredit is just a repetition.
i won't try the dos/windows editors, because i don't have these platforms quickly accessible. but back when i did, FAR was definitely the only editor i tried which behaved like that. i'd also bet that notepad++ has an option for that, because it has an option for everything.

[mc-butler]

Changed by angel_il (@ilia-maslakov) on Oct 13, 2020 at 15:27 UTC (comment 27)

i just tried gedit, and quite unsurprisingly it doesn't do what you claim (it doesn't do cursor beyond and of line in the first place, and the UI contains no related options).

No, we talk about 0001-don-t-allow-cursor-to-wrap-at-BOL-in-cursor_beyond_e.patch​, about that patch broke intuitive behavior of cursor on BOL.

cursor beyond and of line: borland editors (on turbo Vision), ms word (double click on any place), far editor

[mc-butler]

Changed by ossi (@ossilator) on Oct 13, 2020 at 20:23 UTC (comment 28)

look, i've used all of these, and far is still the only one which behaves the way mcedit does. that you seem to think otherwise indicates that you still (or again) don't understand what this patch is about. that's ... frustrating.

[mc-butler]

Changed by ossi (@ossilator) on Oct 14, 2020 at 11:55 UTC (comment 29)

• Description edited

[mc-butler]

Changed by ossi (@ossilator) on Oct 14, 2020 at 12:01 UTC

• Attachment 0001-don-t-allow-cursor-to-wrap-at-BOL-in-cursor_beyond_e.patch (raw) added

[mc-butler]

Changed by angel_il (@ilia-maslakov) on Oct 14, 2020 at 12:52 UTC (comment 28.30)

Replying to ossi:

look, i've used all of these, and far is still the only one which behaves the way mcedit does. that you seem to think otherwise indicates that you still (or again) don't understand what this patch is about. that's ... frustrating.

This patch do not allow move cursor on end of previous line, if cursor_beyond_eol is true, correct?

[mc-butler]

Changed by ossi (@ossilator) on Oct 14, 2020 at 13:41 UTC (comment 31)

a correct and unambiguous way to write it would be "This patch prevents the cursor from wrapping from the beginning of a line to the end of the previous line if, and only if, cursor_beyond_eol is true". if that's what you meant, then yes, correct.

if you still think that this is bad, you need to make a coherent argument why asymmetrical/inconsistent behavior (violating the principle of least astonishment) is preferable.
note that the fact that you're used to it is irrelevant for the default behavior, as you're a tiny fraction of potential, and probably also actual users.

the last point brings us to precedents. name editors (with version number, in case the behavior changed) that wrap on left-arrow while operating in virtual whitespace mode. exclude ones that have a separate option for it, unless the "wrap-at-bol but not-wrap-at-eol" combination is the default.

[mc-butler]

Changed by angel_il (@ilia-maslakov) on Oct 15, 2020 at 10:36 UTC (comment 32)

i'm do not see any correlations between 'cursor_beyond_eol' options and restriction to move cursor on previous line after left key pressed.

[mc-butler]

Changed by ossi (@ossilator) on Oct 15, 2020 at 11:56 UTC (comment 33)

then you aren't looking very hard. it's rather intuitive that if right-key cannot change the line, then left-key shouldn't either. the keys are expected to behave symmetrically, that is, they undo each other's effect - when you overshoot your target, you can just navigate back by using the opposite key. in practical terms that means that overshooting must not be possible if the exact opposite operation isn't available.

[mc-butler]

Changed by angel_il (@ilia-maslakov) on Oct 15, 2020 at 21:24 UTC (comment 34)

just switch off cursor_beyond_eol or use crtl-right key to return. why not?

[mc-butler]

Changed by ossi (@ossilator) on Oct 15, 2020 at 23:27 UTC (comment 34.35)

Replying to angel_il:

just switch off cursor_beyond_eol

that's the opposite of what i want.

or use crtl-right key to return. why not?

because i shouldn't have to in the first place. consistency is one of the basic concepts in UX, and trumps any possible marginal efficiency gain that you (and probably close to no-one else) gets out of actively exploiting the asymmetry.

[mc-butler]

Changed by angel_il (@ilia-maslakov) on Oct 16, 2020 at 17:08 UTC (comment 36)

but why do you want to fix it for yourself and break it for all?

why should i feel pain?
your patch that's the opposite of what i want.

make option 'stop_cursor_on_BOL'.

[mc-butler]

Changed by ossi (@ossilator) on Oct 16, 2020 at 18:46 UTC (comment 37)

you are insisting that while right-wrapping requires using ctrl-right, left-wrapping requiring ctrl-left instead of just left is unacceptable, and would cause you pain.
you don't seem to get how absurd this is, and how much your notion of "break it for all" deviates from the expectations of most people (as evidenced by the behavior of most editors).
i'm done with trying to convince you, and i certainly won't lift a finger to satisfy your outlier requirement. if the rest of the team doesn't convince or simply overrule you, i'll keep applying the patch locally. you win, most others (who even care) lose.

[mc-butler]

Changed by angel_il (@ilia-maslakov) on Oct 17, 2020 at 8:51 UTC (comment 38)

I do not have any requirements for you. You and me do anything for opensource JUST FOR FUN.
And yes most editors has similar behaviour like mcedit.

[mc-butler]

Changed by ossi (@ossilator) on Oct 17, 2020 at 15:50 UTC (comment 38.39)

Replying to angel_il:

I do not have any requirements for you.

you are making it a requirement when you make inclusion of my patch conditional on it.

You and me do anything for opensource JUST FOR FUN.

actually, no, i'm not doing it for fun, but to make my life easier.
but to counter the argument you actually had in mind: even when you give away something for free, you still take up a responsibility, for whatever that might be worth.

And yes most editors has similar behaviour like mcedit.

no, they don't, and repeating that misinformation doesn't make it any truer. the benchmark are editors operating in C-B-EOL mode, which enable it with a single switch (or don't even have other modes).

most editors don't even have C-B-EOL mode - gedit, jedit, xedit, jed, nano, libreoffice writer, in-browser textedits - not one of them (as far as my testing/rtfming goes). that makes them completely irrelevant to the discussion.
libreoffice has "direct cursor" mode (which presumably matches the msword mode you mentioned), but that doesn't affect keyboard navigation.

in vim you can enable wrap mode with :set whichwrap=<,>,[,] and C-B-EOL mode with :set virtualedit=all - and when you do both at the same time, it actually starts to behave like mcedit. that something is not quite right with that combination is evidenced by the fact that some of whichwrap's settings lose meaning, while others remain effective.

according to my recollection, the dos-based borland IDEs qualify - and behave the way my patch does.
kate has block selection mode, which actually enables C-B-EOL mode outside selection, too - and behaves "my way".
qtcreator supports block selections, and while selecting the cursor can go beyond EOL - which behaves "my way". that's a bit of a special case, though, so doesn't necessarily count. emacs also has (several) block selection modes which do C-B-EOL, but i didn't test these.

[mc-butler]

Changed by angel_il (@ilia-maslakov) on Oct 18, 2020 at 3:19 UTC (comment 40)

xedit!? are you joke?!
gedit - not enouth features, too poor.
jedit - use 4.0+
jed, nano - 0_o ???!!! sed, awk, cat - no have too.

but AndroidStudio, IntelliJ, VisualStudio, Borland IDE (ctrl+click), far - like mcedit.

[mc-butler]

Changed by angel_il (@ilia-maslakov) on Oct 18, 2020 at 3:24 UTC (comment 41)

about dos-based ide-s i think you right, i try DN, it similar as your patch behaviour.

[mc-butler]

Changed by zaytsev (@zyv) on Nov 1, 2020 at 23:37 UTC (comment 42)

"Good old" flamewars in tickets :(

but AndroidStudio, IntelliJ,

This is wrong, IntelliJ-based editors don't allow wrapping to the previous line in the virtual space mode. Just checked it myself in PyCharm.

FWIW, I'm +1 on the patch.