Ticket #1801 (reopened enhancement)
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.
Attachments
Change History
comment:2 Changed 15 years ago by angel_il
- Status changed from new to closed
- Resolution set to wontfix
comment:3 Changed 15 years ago by ossi
do you really *have* to be different than any other editor in use out there?
comment:4 Changed 15 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 15 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 15 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);
}
comment:7 Changed 15 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 15 years ago by ossi
sorry guys, are you a bit dense? do you understand what the patch does?
comment:9 Changed 15 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 15 years ago by angel_il
- Status changed from closed to reopened
- Resolution wontfix deleted
comment:11 Changed 15 years ago by angel_il
- Status changed from reopened to closed
- Resolution set to wontfix
comment:12 Changed 15 years ago by angel_il
no profit. you entirely missed the point.
fixed in #2094
comment:13 Changed 15 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 15 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 15 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 15 years ago by slavazanko
Ossi: Ops, big sorry :) Now I fully understand about you say.
comment:17 Changed 15 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 15 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 15 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 15 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 13 years ago by andrew_b
- Branch state set to no branch
- Milestone changed from 4.7 to Future Releases
comment:22 Changed 4 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 4 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 4 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 4 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 4 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 4 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 follow-up: ↓ 30 Changed 4 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.
Changed 4 years ago by ossi
- Attachment 0001-don-t-allow-cursor-to-wrap-at-BOL-in-cursor_beyond_e.patch added
comment:30 in reply to: ↑ 28 Changed 4 years ago by 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?
comment:31 Changed 4 years ago by 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.
comment:32 Changed 4 years ago by 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.
comment:33 Changed 4 years ago by 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.
comment:34 follow-up: ↓ 35 Changed 4 years ago by angel_il
just switch off cursor_beyond_eol or use crtl-right key to return. why not?
comment:35 in reply to: ↑ 34 Changed 4 years ago by 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.
comment:36 Changed 4 years ago by angel_il
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'.
comment:37 Changed 4 years ago by 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.
comment:38 follow-up: ↓ 39 Changed 4 years ago by 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.
comment:39 in reply to: ↑ 38 Changed 4 years ago by 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.
comment:40 Changed 4 years ago by 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.
comment:41 Changed 4 years ago by angel_il
about dos-based ide-s i think you right, i try DN, it similar as your patch behaviour.
comment:42 Changed 4 years ago by 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.
i think it's intuitive behaviour.