Author Topic: Annoying home/end editor behavior on wrapped text  (Read 11873 times)

Offline dmoore

  • Developer
  • Lives here!
  • *****
  • Posts: 1576
Annoying home/end editor behavior on wrapped text
« on: July 26, 2007, 04:12:43 pm »
I'm thinking of adding an editor option to change the behavior of the home and end keys for wordwrapped text.

Currently, if you are working on a line of text that is so long that it has been wrapped and you press the end key then the cursor goes to the end of the entire line rather than the end of the displayed line (home key does the same thing with start of the entire line rather than the start of the displayed line). to move to the end of the displayed line you need to press alt+end (or alt+home). unfortunately, alt+shift+end (alt+shift+home) doesn't select the text to the end of the displayed line.

IMO the current behavior is annoying if you want to do things like edit latex in cb...

My plan is to give users the option to switch up the effect of end/alt+end, home/alt+home (and to make sure that alt+shift+end works for either case). Only question is whether the current behavior is default scintilla behavior or codeblocks own customization? suggestions of where to process the keystrokes (main.cpp, cbeditor.cpp etc) would also help...

Offline dje

  • Lives here!
  • ****
  • Posts: 683
Re: Annoying home/end editor behavior on wrapped text
« Reply #1 on: July 26, 2007, 05:23:16 pm »
Hi Damien !

I have a request that is quite similar.
I'd like Ctrl+B to bring me to corresponding curly bracket and Ctrl+Shift+B to select corresponding block of text.

I know Ctrl+B is already used by bookmarks it could be very useful when reworking code.

Dje

Offline dmoore

  • Developer
  • Lives here!
  • *****
  • Posts: 1576
Re: Annoying home/end editor behavior on wrapped text
« Reply #2 on: July 26, 2007, 05:37:08 pm »
the good news is that scintilla fully supports remapping all of its keystroke commands. I still need to figure out where cb does all of its keystroke mgt for editors (probably in lots of different places :( ). the bad news is lack of time to do all the things i want to do in a day  :lol:  when i get to it I'll look at your request too dje.

Offline thomas

  • Administrator
  • Lives here!
  • *****
  • Posts: 3979
Re: Annoying home/end editor behavior on wrapped text
« Reply #3 on: July 26, 2007, 07:32:01 pm »
Quote
Currently, if you are working on a line of text that is so long that it has been wrapped and you press the end key then the cursor goes to the end of the entire line rather than the end of the displayed line
But that is just how it should be?

Quote
(home key does the same thing with start of the entire line rather than the start of the displayed line)
A lot more complicated: It goes to the indent position, i.e. the first non-whitespace character. On the second "home", it goes to the beginning of the line. Yet another "home" makes it jump back to the indentation, very useful.

Personally, I would rather not have this configurable. It adds changes and complexity which are not necessary, and it will be superseded in a future version, too. Once a stable release is out, Yiannis' event scheduler will come into play.

There are countless other things that someone might want to customize, for example, one might want page-up and page-down to jump to the next class. I wouldn't want to include three dozen such special cases that 1% of people will ever really use, especially since it is decided that key/menu/mouse handling will be superseded.
"We should forget about small efficiencies, say about 97% of the time: Premature quotation is the root of public humiliation."

Offline dmoore

  • Developer
  • Lives here!
  • *****
  • Posts: 1576
Re: Annoying home/end editor behavior on wrapped text
« Reply #4 on: July 26, 2007, 09:21:06 pm »
A lot more complicated: It goes to the indent position, i.e. the first non-whitespace character. On the second "home", it goes to the beginning of the line. Yet another "home" makes it jump back to the indentation, very useful.

yes, I just didn't feel the need to pad out the explanation any further.

Quote
But that is just how it should be?

actually very few rich editing wrapping text controls exhibit this behavior. end key goes to the end of the displayed line, home to the start (or first indent as you point out). it really does get in the way: think of hand editing xml files that don't have line feeds.

Quote
Once a stable release is out, Yiannis' event scheduler will come into play... snip ...
especially since it is decided that key/menu/mouse handling will be superseded.

which is what i've been hoping for. it seems to take posts like this to get inside your heads...  :)

Offline dmoore

  • Developer
  • Lives here!
  • *****
  • Posts: 1576
Re: Annoying home/end editor behavior on wrapped text
« Reply #5 on: July 27, 2007, 05:47:38 am »
to clarify my position here: I'm claiming that current home/end behavior for wrapped text is WRONG and that i would like to fix it (moreover the behavior of alt+shift+home/end is an outright bug). the only reason i want to make it an option rather than force the change on everyone is so that people who are used to the wrong behavior aren't left out in the cold.

Offline thomas

  • Administrator
  • Lives here!
  • *****
  • Posts: 3979
Re: Annoying home/end editor behavior on wrapped text
« Reply #6 on: July 27, 2007, 10:32:23 am »
actually very few rich editing wrapping text controls exhibit this behavior. end key goes to the end of the displayed line
I have just tested the following 6 applications which all exhibit exactly this "wrong" behaviour:
Scite (1.66)
Notepad (5.1/Win XP SP2)
Microsoft Word (2002/SP3)
phase5 HTML editor (6.1.05)
nano (1.3.12)
vi (VIM 7.0)
"We should forget about small efficiencies, say about 97% of the time: Premature quotation is the root of public humiliation."

Offline dmoore

  • Developer
  • Lives here!
  • *****
  • Posts: 1576
Re: Annoying home/end editor behavior on wrapped text
« Reply #7 on: July 27, 2007, 01:18:49 pm »
no, nano, word and notepad implement home/end for wrapped text the way i want it to work and so does word pad, nvu, open office and gedit.  (obviously scite and other scintilla based apps will not, because they are probably all using the same default scintilla keybinds, if you are using vim you shouldn't be using home/end at all and i couldn't get  the apparently german-only phase5 to work at all on my pc). are you sure we are talking about the same thing or is there some weird localization thing going on?

Offline thomas

  • Administrator
  • Lives here!
  • *****
  • Posts: 3979
Re: Annoying home/end editor behavior on wrapped text
« Reply #8 on: July 27, 2007, 03:37:21 pm »
no, nano, word and notepad implement home/end for wrapped text the way i want it to work

This is what nano looks like, pressing home and end alternatingly:


Scite, Notepad, Word, <insert random application> and Code::Blocks all work like that too.
"We should forget about small efficiencies, say about 97% of the time: Premature quotation is the root of public humiliation."

Offline dmoore

  • Developer
  • Lives here!
  • *****
  • Posts: 1576
Re: Annoying home/end editor behavior on wrapped text
« Reply #9 on: July 27, 2007, 04:07:42 pm »
I can't see the image (filtered). can you upload it or e-mail it to me?

I've attached images of cb and notepad with the cursor centered in wrapped text and then pressing shift+home. different right?

[attachment deleted by admin]

Offline dmoore

  • Developer
  • Lives here!
  • *****
  • Posts: 1576
Re: Annoying home/end editor behavior on wrapped text
« Reply #10 on: July 27, 2007, 05:08:49 pm »
so many words over something as simple as this:

~line 948 of cbeditor.cpp

Code
    control->SetWrapMode(mgr->ReadBool(_T("/word_wrap"), false));
+    if(mgr->ReadBool(_T("/word_wrap_style_home_end"), true))
+    {
+    control->CmdKeyAssign(wxSCI_KEY_HOME,wxSCI_SCMOD_NULL,wxSCI_CMD_VCHOMEWRAP);
+    control->CmdKeyAssign(wxSCI_KEY_END,wxSCI_SCMOD_NULL,wxSCI_CMD_LINEENDWRAP);
+    control->CmdKeyAssign(wxSCI_KEY_HOME,wxSCI_SCMOD_SHIFT,wxSCI_CMD_VCHOMEWRAPEXTEND);
+    control->CmdKeyAssign(wxSCI_KEY_END,wxSCI_SCMOD_SHIFT,wxSCI_CMD_LINEENDWRAPEXTEND);
+    }
    control->SetViewEOL(mgr->ReadBool(_T("/show_eol"), false));

note that you get standard behavior if you don't use word wrapping. if you do, then press end once to go to the wrap point, press again to go to the end of the actual line (similar with the home key home, and yes, the home key respects leading indentation)

the beauty of xml configuration is that there is no need to add the entries to the editor settings dialog if we think this is something 99% of users will be comfortable with...
« Last Edit: July 27, 2007, 05:14:10 pm by dmoore »

Offline dmoore

  • Developer
  • Lives here!
  • *****
  • Posts: 1576
Re: Annoying home/end editor behavior on wrapped text
« Reply #11 on: July 27, 2007, 05:13:44 pm »
@dje: is there currently a keyboard shortcut to goto matching brace? I know scite uses ctrl+E and ctrl+shift+E, but notice that doesn't work in cb either.

Offline thomas

  • Administrator
  • Lives here!
  • *****
  • Posts: 3979
Re: Annoying home/end editor behavior on wrapped text
« Reply #12 on: July 27, 2007, 05:38:51 pm »
Your image helped understand what you actually want better, is slightly different from what I understood first, and indeed, Word and Notepad behave differently here.
But it doesn't matter, the way Scite and Code::Blocks do it is still correct, and should not be changed.

The key is that the beginning of a line is either the beginning of the document or the first character after a newline char, not whatever happens to be leftmost on your screen. For MS Word, the latter may even be acceptable (and possibly intuitive to some people), since it's a word processor. Historically, word processors were made for people who hit Return at the end of every line (my mother still does that today) and expect the mechanical slide to zoom left when they hit home. That doesn't mean it is conceptually correct, though. It's a relict, and a wrong one.
For many years, word processors have been working in terms of paragraphs, not lines, and they do it in every other respect, only not for some legacy keys.

For an IDE or for an editor, the way it is implemented makes perfect sense.  A compiler/interpreter doesn't care if you word-wrap your sources. A new line starts after a newline char, nowhere else. Also, remember you can select words by double-click, and lines by triple-click, too. The way it is implemented is consistent with click-selecting (which is implemented as paragraph-select in Word, too.)

Think of less sophisticated languages like Python (or Basic?), or of .ini files, bash scripts, typical shell-style config files. You sure want to select a whole line if you mean to, not some random part that happens to be wrapped in a certain window at a certain time, or it can get very, very painful to track down later.



About the alt-shift combinations, I can't tell anything, have neither ever used them, nor would I know what they are supposed to do. Whatever it's supposed to do, it's weird, agreed.
"We should forget about small efficiencies, say about 97% of the time: Premature quotation is the root of public humiliation."

Offline dmoore

  • Developer
  • Lives here!
  • *****
  • Posts: 1576
Re: Annoying home/end editor behavior on wrapped text
« Reply #13 on: July 27, 2007, 06:30:07 pm »
sheesh, am i sorry i invoked wrong/right/correct/incorrect language...

A compiler/interpreter doesn't care if you word-wrap your sources. A new line starts after a newline char, nowhere else. Also, remember you can select words by double-click, and lines by triple-click, too. The way it is implemented is consistent with click-selecting (which is implemented as paragraph-select in Word, too.)

what compilers/interpreters understand is completely irrelevant (and pointedly c/c++ compilers largely don't distinguish between newlines and whitespace, that doesn't mean you shouldn't care as a user). this is about human interface with an editor. I want a quick way to move to the left or right side of what i can see on the current line without touching the mouse. if that means i have to hit the same key twice to get to the actual line ending (or hold down alt -- yuk), that isn't as big a deal for me.

by your logic the up and down arrow should move to the next actual line.

Quote
Think of less sophisticated languages like Python (or Basic?), or of .ini files, bash scripts, typical shell-style config files. You sure want to select a whole line if you mean to, not some random part that happens to be wrapped in a certain window at a certain time, or it can get very, very painful to track down later.

while you think this has logical merit, it is also irrelevant. Python (and others) support \ line continuations as well as continuations of newlines enclosed in braces, so you still aren't safe copying whole lines. The only safe way to edit code is to actually LOOK at what you are doing.

if it really hurts your pysche that much just change true to false in the patch.
« Last Edit: July 27, 2007, 06:37:55 pm by dmoore »

Offline dje

  • Lives here!
  • ****
  • Posts: 683
Re: Annoying home/end editor behavior on wrapped text
« Reply #14 on: July 27, 2007, 09:02:45 pm »
@dje: is there currently a keyboard shortcut to goto matching brace? I know scite uses ctrl+E and ctrl+shift+E, but notice that doesn't work in cb either.
@dmoore
Ctrl+Shift+B brings you to the matching brace.
With keybinder, I could link goto matching brace to Ctrl+B and select block until brace to Ctrl+Shift+B if behaviour is available.

It is true your pictures speak better than words. I agree with you.

Dje

Offline dmoore

  • Developer
  • Lives here!
  • *****
  • Posts: 1576
Re: Annoying home/end editor behavior on wrapped text
« Reply #15 on: July 30, 2007, 12:42:45 am »
@dje: I've added your requested matching brace behavior to the patch (#2116): http://developer.berlios.de/patch/index.php?func=detailpatch&patch_id=2116&group_id=5358
because bookmarks already use ctrl+b, i made ctrl+. and ctrl+shift+. the default keys to goto and select to matching brace respectively, but I have no personal attachment to this key combo and maybe someone can think of a better default (ctrl+e and ctrl+shift+e are available). also note that i modified the behavior of matching brace slightly to move inside (or outside) the matching brace if your original position was inside (outside) the original brace (this is also true for extending the selection)

@thomas: keep in mind that the home/end change only has any effect if the text is wordwrapped and, in that case, it is a feature enhancement. pressing end (home) goes to the wrap point. if already at the wrap point (i.e. if you press the key a second time), pressing end (home) goes to the end (starting indent) of the entire line. alt+end and alt+home will always goto the end of the entire line or first indent of the entire line, respectively (and thus follow the typical convention that modified keys have an incrementally larger effect). As someone who uses the CB editor as a C/C++ editor, a scripting editor, a latex editor and xml editor I can assure you this is more usable than the current behavior.

Offline dje

  • Lives here!
  • ****
  • Posts: 683
Re: Annoying home/end editor behavior on wrapped text
« Reply #16 on: July 30, 2007, 09:21:45 am »
Hi Damien !

Thanks !!  :D
I'll try it this week and hope it will be applied.

Dje