Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Inconsistent behavior of END and SHIFT+END when line wrap is enabled (same w/ HOME) #255

Closed
toffeles opened this issue Jun 18, 2015 · 4 comments
Labels
accepted enhancement Proposed enhancements of existing features question Questions about usage, code related techniques & behaviour, as well as design choices
Milestone

Comments

@toffeles
Copy link

With word-wrap on, END moves to the furthest right location on the current display line. Pressing END again moves to the end of the actual line. However, with SHIFT+END, the END only does the latter: extend selection to end of the actual line. Similarly with HOME wrt the beginning of the display/actual line. It would be nice if the behavior was consistent for movement and for selection.

This can be fixed with the following:

  • Remove Shift+End shortcut for SCI_LINEENDEXTEND, add it to SCI_LINEENDWRAPEXTEND.
  • Remove Shift+Home shortcut for SCI_VCHOMEEXTEND, add it to SCI_VCHOMEWRAPEXTEND.

Should these changes be made to the default mappings?

@dail8859
Copy link
Contributor

👍 Totally agree the behavior is inconsistent and needs changed.

@Eldaw
Copy link

Eldaw commented Jun 18, 2015

I agree.

@milipili milipili added enhancement Proposed enhancements of existing features question Questions about usage, code related techniques & behaviour, as well as design choices labels Jun 20, 2015
@milipili milipili modified the milestone: 6.x Jun 29, 2015
dail8859 referenced this issue in dail8859/notepad-plus-plus Jul 27, 2015
@h-h-h-h
Copy link
Contributor

h-h-h-h commented Aug 26, 2015

👍

@ygoe
Copy link
Contributor

ygoe commented Sep 14, 2015

The existing mapping cannot be removed. Then I added the same hotkey to the other command. Now both commands share the same hotkey and neither can be removed again. That looks like a problem to me.

@donho donho added the accepted label Jan 10, 2016
@donho donho closed this as completed in 7fc86fb Jan 10, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
accepted enhancement Proposed enhancements of existing features question Questions about usage, code related techniques & behaviour, as well as design choices
Projects
None yet
Development

No branches or pull requests

7 participants