remove Space & Break line while Copying a line in notepad++
-
@Sultan said in remove Space & Break line while Copying a line in notepad++:
this is too tough to copy
If you stick to keyboard actions, you can make a MACRO of the whole sequence:
- press Home twice
- press Shift+End
- press Ctrl+c
Then assign the macro to a keycombo.
Can’t be any quicker than that. -
So the OP’s desire to select to end of line content, but not any trailing whitespace, got me thinking about how using the Shift+End keycombo works in comparison to Shift+Home.
Shift+End will select to the end of data (be it whitespace or not), just before the end-of-line character(s) on a line. Shift+Home, however, selects from current position to the first non-whitespace on a line. If, after doing Shift+Home the first time, the user presses it again, THEN it will extend the selection to column 1.
But really, why this difference? Why shouldn’t Shift+End first select to the last non-whitespace character on a line, then a subsequent re-press of that keycombo selects the remaining (less line-ending char(s))? I mean, one could argue it either way, but I say “why not act similarly”?
So I wrote a script to provide this functionality for Shift+End (and End alone as well). I call the script
EndKeyReplacementFunctionality.py
and here it is:# -*- coding: utf-8 -*- from __future__ import print_function # references: # https://community.notepad-plus-plus.org/topic/23381 from Npp import * from ctypes import (WinDLL) #------------------------------------------------------------------------------- class EKRF(object): def __init__(self): VK_SHIFT = 0x10 is_selecting = (WinDLL('user32').GetAsyncKeyState(VK_SHIFT) & 0x8000) != 0 if editor.selectionIsRectangle(): editor.lineEndRectExt() if is_selecting else editor.lineEndDisplay() return if editor.getSelections() > 1: editor.lineEndWrapExtend() if is_selecting else editor.lineEndWrap() return caret_pos = editor.getCurrentPos() cur_line = editor.lineFromPosition(caret_pos) cur_line_end_pos = editor.getLineEndPosition(cur_line) match_pos_list = [] editor.research(r'\h+$', lambda m: match_pos_list.append(m.span(0)[0]), 0, editor.positionFromLine(cur_line), cur_line_end_pos, 1) new_caret_pos = cur_line_end_pos if (len(match_pos_list) == 0 or caret_pos == match_pos_list[0]) else match_pos_list[0] editor.setSelection(new_caret_pos, editor.getAnchor() if is_selecting else new_caret_pos) #------------------------------------------------------------------------------- if __name__ == '__main__': EKRF()
To use the script, remap the shortcut for the Shift+End keycombo from its default function to run this script instead.
To have the functionality for the End key alone requires a second script with a similar keycombo remapping. The scripts can be identical; what I did was just copy
EndKeyReplacementFunctionality.py
toEndKeyReplacementFunctionality2.py
. -
-
@Alan-Kilborn
Home
andEnd
different behavior with whitespaces disturbed me too. This script is very clever, thank you!
I’d suggest to addeditor.chooseCaretX()
aftereditor.setSelection...
to remember caret new horizontal position for next up/down moves.
Remapping ofEnd
andShift+End
works even with conflicts with Scintilla default commands, but I don’t know, what exactly is going on in behind :) These keys can be disabled in Scintilla withSCI_CLEARCMDKEY
, but they remain in N++ Shortcut Mapper as conflicts. May this be a problem somehow, I don’t know.
Thanks again for this useful idea and script! -
@Andi-Kiissel said:
I’d suggest to add editor.chooseCaretX() after editor.setSelection… to remember caret new horizontal position for next up/down moves
Yes, that’s a very good idea.
@Andi-Kiissel said :
Remapping of End and Shift+End works even with conflicts with Scintilla default commands, but I don’t know, what exactly is going on in behind :) These keys can be disabled in Scintilla with SCI_CLEARCMDKEY, but they remain in N++ Shortcut Mapper as conflicts. May this be a problem somehow, I don’t know.
I do know something about how keys are processed, but I think the easiest/safest thing if someone wants to use the script(s) here is to first go in and unmap End and Shift+End, then assign them to the script(s).
-
@Alan-Kilborn said:
I do know something about how keys are processed, but I think the easiest/safest thing if someone wants to use the script(s) here is to first go in and unmap End and Shift+End, then assign them to the script(s).
I didn’t realize until now that if
Remove
isn’t available andNone
withOK
don’t work, thenNone
withApply
do!
Thanks for emphasizing that it’s best to unmap those keys first! -
@Andi-Kiissel said in remove Space & Break line while Copying a line in notepad++:
I didn’t realize until now that if Remove isn’t available and None with OK don’t work, then None with Apply do!
See:
-
@Andi-Kiissel said in remove Space & Break line while Copying a line in notepad++:
I didn’t realize until now that if
Remove
isn’t available andNone
withOK
don’t work, thenNone
withApply
do!
Thanks for emphasizing that it’s best to unmap those keys first!BTW: per Alan’s recent prompting, the documentation has been updated in the github copy of the online user manual to reflect that oddity. The next time the usermanual is pushed to npp-user-manual.org (probably after the next release of Notepad++ (v8.4.5 or v8.5 or whatever it’s called)), the updated instructions will be there.
-
I propose one more significant change to this script:
If the line is longer than width of the window andWordWrap=OFF
then witheditor.setSelection
the caret (cursor) remains invisible (outside the window).
Better to use
editor.setSel(editor.getAnchor() if is_selecting else new_caret_pos, new_caret_pos)
(NB! arguments swapped!)
which moves the view as needed.
WithWordWrap=ON
this script behaves differently than ScintillaEnd
/Shift+End
default, but that’s OK for me :) -
@Andi-Kiissel said in remove Space & Break line while Copying a line in notepad++:
editor.setSel(editor.getAnchor() if is_selecting else new_caret_pos, new_caret_pos) (NB! arguments swapped!)
Another good suggestion. :-)
-
@Andi-Kiissel said i:
With WordWrap=ON this script behaves differently than Scintilla End/Shift+End default, but that’s OK for me
I considered this case, but I didn’t see an easy way to handle it.
As line “breaks” caused by word-wrap are artificial, it would be extremely rare for me to want to move to one.
So wrap consideration got defeatured from the spec for this problem. :-) -