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

[ossi]

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.

[angel_il]

i think it's intuitive behaviour.

[ossi]

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

[ossi]

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 ...

[slavazanko]

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?

[ossi]

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);
     }

[angel_il]

• 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...

[ossi]

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

[angel_il]

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.

[angel_il]

no profit. you entirely missed the point.

fixed in #2094

[ossi]

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

[slavazanko]

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?

[slavazanko]

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.

[slavazanko]

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

[angel_il]

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

[ossi]

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".

[angel_il]

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...

[ossi]

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. :)

[zaytsev]

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.

[angel_il]

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.

[ossi]

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).

[angel_il]

there is nothing "logical" about it.

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

[ossi]

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.

[angel_il]

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

[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.

[angel_il]

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?

[ossi]

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.

[angel_il]

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

[ossi]

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.

[angel_il]

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

[ossi]

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.

[angel_il]

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

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

make option 'stop_cursor_on_BOL'.

[ossi]

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.

[angel_il]

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.

[ossi]

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.

[angel_il]

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.

[angel_il]

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

[zaytsev]

"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.