Developer forums (C::B DEVELOPMENT STRICTLY!) > Development

Annoying home/end editor behavior on wrapped text

(1/4) > >>

dmoore:
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...

dje:
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

dmoore:
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.

thomas:

--- 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
--- End quote ---
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)
--- End quote ---
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.

dmoore:

--- Quote from: thomas on July 26, 2007, 07:32:01 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.
--- End quote ---

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


--- Quote ---But that is just how it should be?
--- End quote ---

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.
--- End quote ---

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

Navigation

[0] Message Index

[#] Next page