Ticket #1801 (reopened enhancement) — at Version 29

Opened 14 years ago

Last modified 3 years ago

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

Reported by: ossi Owned by:
Priority: minor Milestone: Future Releases
Component: mcedit Version: master
Keywords: Cc:
Blocked By: Blocking:
Branch state: no branch Votes for changeset:

Description (last modified by ossi) (diff)

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.

Change History

comment:1 Changed 14 years ago by angel_il

i think it's intuitive behaviour.

comment:2 Changed 14 years ago by angel_il

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

comment:3 Changed 14 years ago by ossi

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

comment:4 Changed 14 years ago by 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 ...

comment:5 Changed 14 years ago by 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?

comment:6 Changed 14 years ago by 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);
     }
Last edited 10 years ago by ossi (previous) (diff)

comment:7 Changed 14 years ago by 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...

comment:8 Changed 14 years ago by ossi

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

comment:9 Changed 14 years ago by 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.

comment:10 Changed 14 years ago by angel_il

  • Status changed from closed to reopened
  • Resolution wontfix deleted

comment:11 Changed 14 years ago by angel_il

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

comment:12 Changed 14 years ago by angel_il

no profit. you entirely missed the point.

fixed in #2094

comment:13 Changed 14 years ago by ossi

  • Status changed from closed to reopened
  • Resolution wontfix deleted

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

comment:14 Changed 14 years ago by 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?

comment:15 Changed 14 years ago by 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.

comment:16 Changed 14 years ago by slavazanko

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

comment:17 Changed 14 years ago by angel_il

  • Type changed from defect to enhancement

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

comment:18 Changed 14 years ago by 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".

comment:19 Changed 14 years ago by 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...

comment:20 Changed 14 years ago by 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. :)

comment:21 Changed 12 years ago by andrew_b

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

comment:22 Changed 3 years ago by 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.

comment:23 Changed 3 years ago by 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.

comment:24 Changed 3 years ago by 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).

comment:25 Changed 3 years ago by angel_il

there is nothing "logical" about it.

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

comment:26 Changed 3 years ago by 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.

comment:27 Changed 3 years ago by 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

comment:28 Changed 3 years ago by 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.

comment:29 Changed 3 years ago by ossi

  • Description modified (diff)
Note: See TracTickets for help on using tickets.