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.