Developer forums (C::B DEVELOPMENT STRICTLY!) > Development
Annoying home/end editor behavior on wrapped text
dmoore:
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));
--- End code ---
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...
dmoore:
@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.
thomas:
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.
dmoore:
sheesh, am i sorry i invoked wrong/right/correct/incorrect language...
--- Quote from: thomas on July 27, 2007, 05:38:51 pm --- 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.)
--- End quote ---
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.
--- End quote ---
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.
dje:
--- Quote from: dmoore 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.
--- End quote ---
@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
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version