Since you apparently use that plugin,

Actually… I only use it because I forgot I had it hanging around! :-)
I’ve now disabled it and I will see if my workflow is impacted at all…

BetterMultiSelection

Since you apparently use that plugin, I have a question. In release notes for Columns++ v 1.1.2 I wrote:

Some new features and fixes are probably incompatible with the BetterMultiSelection plugin. I believe that most if not all of that plugin’s features are now incorporated natively in current versions of Notepad++; if there are specific problems you cannot solve without that plugin and you observe conflicts with Columns++, please open an issue in the GitHub repository for Columns++ and I will see if there is anything I can do about it.

Are there features you use from BetterMultiSelection that haven’t been made native to Notepad++? (If so, I’d like to identify them, test whether there is a conflict and see if I can resolve any conflicts that do occur. BetterMultiSelection hasn’t been updated in two and a half years, but then again there are only two open issues and one open pull request, none later than June 2022.)

• it won’t do its intended functionality if you are also using the BetterMultiSelection plugin and you have it Enable’d (at least on my system that plugin seems to steal keystrokes before the script can get ahold of them)
• the script is not needed if you have Enable Column Selection to Multi-Editing uncheckmarked, ref. (this is I guess obvious, but it tripped me up at one point so I’m noting it here).

but wouldn’t it be better to cancel multiline selection on cursor up and cursor down? 🤔

A script can allow an up/down arrow press with an active column selection to cancel the selection.

Here’s a Python3 script for it, I call the script ArrowUpOrDownCancelsColumnSelection.py:

# -*- coding: utf-8 -*-

#########################################
#
#  ArrowUpOrDownCancelsColumnSelection (AUODCCS)
#
#########################################

# note:
#  This script was developed and tested under Python3 64-bit on unicode (non-ANSI) encoded data.
#  It may work as-is using Python2 and/or ANSI-encoded data and/or 32-bits, but that would be incidental.

# references:
#  https://community.notepad-plus-plus.org/topic/25221/moveable-multi-line-carets
#  for newbie info on PythonScripts, see https://community.notepad-plus-plus.org/topic/23039/faq-desk-how-to-install-and-run-a-script-in-pythonscript

from Npp import *
from ctypes import ( WinDLL, WINFUNCTYPE )
from ctypes.wintypes import ( HWND, UINT, INT, WPARAM, LPARAM )

user32 = WinDLL('user32')

LRESULT = LPARAM

WndProcType = WINFUNCTYPE(
    LRESULT,  # return type
    HWND, UINT, WPARAM, LPARAM  # arguments
    )

SetWindowLong = user32.SetWindowLongPtrW
SetWindowLong.restype = WndProcType
SetWindowLong.argtypes = [ HWND, INT, WndProcType ]
GWL_WNDPROC = -4

WM_KEYDOWN = 0x0100
VK_SHIFT = 0x10
VK_CONTROL = 0x11
VK_MENU = 0x12
VK_UP = 38
VK_DOWN = 40

class AUODCCS(object):

    def __init__(self):
        self.new_editor1_wnd_proc_hook_for_SetWindowLong = WndProcType(self.new_editor1_wnd_proc_hook)
        self.orig_editor1_wnd_proc = SetWindowLong(editor1.hwnd, GWL_WNDPROC, self.new_editor1_wnd_proc_hook_for_SetWindowLong)
        self.new_editor2_wnd_proc_hook_for_SetWindowLong = WndProcType(self.new_editor2_wnd_proc_hook)
        self.orig_editor2_wnd_proc = SetWindowLong(editor2.hwnd, GWL_WNDPROC, self.new_editor2_wnd_proc_hook_for_SetWindowLong)

    def new_editor1_wnd_proc_hook(self, hwnd, msg, wParam, lParam):
        retval = self.common_editor_wnd_proc_hook(hwnd, msg, wParam, lParam)
        if retval: retval = self.orig_editor1_wnd_proc(hwnd, msg, wParam, lParam)
        return retval

    def new_editor2_wnd_proc_hook(self, hwnd, msg, wParam, lParam):
        retval = self.common_editor_wnd_proc_hook(hwnd, msg, wParam, lParam)
        if retval: retval = self.orig_editor2_wnd_proc(hwnd, msg, wParam, lParam)
        return retval

    def common_editor_wnd_proc_hook(self, hwnd, msg, wParam, lParam):
        retval = True  # default to letting N++ handle the message
        if msg == WM_KEYDOWN:
            if (wParam == VK_UP or wParam == VK_DOWN) and \
                    (user32.GetAsyncKeyState(VK_SHIFT) & 0x8000) == 0 and \
                    (user32.GetAsyncKeyState(VK_CONTROL) & 0x8000) == 0 and \
                    (user32.GetAsyncKeyState(VK_MENU) & 0x8000) == 0:
                sel_mode = editor.getSelectionMode()
                rect_sel_mode = True if (sel_mode == SELECTIONMODE.RECTANGLE or sel_mode == SELECTIONMODE.THIN) else False
                if rect_sel_mode:
                    cp = editor.getCurrentPos()
                    editor.setSelectionMode(SELECTIONMODE.STREAM)
                    editor.setSel(cp, cp)
                else:
                    editor.lineUp() if wParam == VK_UP else editor.lineDown()
                retval = False  # don't let N++ do any more processing on the key that was pressed
        return retval

ARROW_UP_OR_DOWN_CANCELS_COLUMN_SELECTION = AUODCCS()

To try out the script, all you have to do is run it ONCE. It will then sit there and listen for up or down arrow presses.

If you like the script and you want to have it always active, you can set this script to run from user startup.py by adding the following line to that file:

from ArrowUpOrDownCancelsColumnSelection import ARROW_UP_OR_DOWN_CANCELS_COLUMN_SELECTION

If I, recall, we already went down the road of asking for automatic cancellation of a multi-selection when the Up/Down arrow keys were used. The best we got was the Enable Column Selection to Multi-Editing switch which disables multi-selection when any of the arrow keys, Home, or End are used.

I think you are failing to distinguish between rectangular (aka column) selections and multiple selections. They are not interchangeable.

Cursor arrows and the Home and End keys have never, to the best of my knowledge, canceled multiple selections. What those of us who use column selections more often than multiple selections requested, and received, was the ability to restore the previously familiar behavior of having cursor movement keys cancel column selections.

The new behavior, when Enable Column Selection to Multi-Editing is checked, is that a column selection is changed to a multiple selection when a cursor movement key is pressed, then moved accordingly. (It has never been possible to move a column selection and keep it as a column selection. There would, for example, be glaring inconsistencies when using proportional fonts.)

You can (almost) tell the difference by looking at the status bar; a zero-width column selection looks like Sel: 4 x 0 = 0 while a multiple selection looks like Sel 4: 0 | 4.

I say “almost” because Scintilla creates something called a thin selection after you type into a rectangular selection. A thin selection behaves like a zero-width column selection, but the status bar indicator shown in Notepad++ looks like the one for a multiple selection. (I don’t know why this choice was made; it might be an oversight.)

Strange… that is not the behavior I see. When that box is unchecked, any cursor key (horizontal, vertical, home or end) cancels a column selection; any cursor key moves each cursor in a multiple selection.

You are right. I normally use zero-width multi-selections and so that’s how I tested the behavior. I see that the OP had a one character wide selection. I tried that with both Enable Multi-Editing and Enable Column Selection to Multi-Editing turned on and match your results.

If I, recall, we already went down the road of asking for automatic cancellation of a multi-selection when the Up/Down arrow keys were used. The best we got was the Enable Column Selection to Multi-Editing switch which disables multi-selection when any of the arrow keys, Home, or End are used. Maybe it’s time to try again?

A slightly “better way” is available via the settings under Preferences / Editing 2 / Multi-Editing. Turn off the option Enable Column Selection to Multi-Editing.

When you do that then:

• Left/right arrow keys keep the multi-cursor mode intact. It gets a strange when one or more of the cursors goes of the end of the line as the cursor(s) wrap to the next line.
• Up/down arrow keys cancel the multi-cursor mode and you have one cursor either on the line above or below where the multi-selection was.

Strange… that is not the behavior I see. When that box is unchecked, any cursor key (horizontal, vertical, home or end) cancels a column selection; any cursor key moves each cursor in a multiple selection.

When that box is checked, any cursor key moves each cursor in a multiple selection in the same way as if the box were unchecked; any cursor key converts a column selection to a multiple selection and then moves it the same as if the box were unchecked.

Tested with:
Notepad++ v8.7.1 (64-bit)
Build time : Oct 31 2024 - 00:48:56
Path : C:\Program Files\Notepad++\Notepad++.exe
Command Line :
Admin mode : OFF
Local Conf mode : OFF
Cloud Config : OFF
Periodic Backup : OFF
OS Name : Windows 10 Pro (64-bit)
OS Version : 22H2
OS Build : 19045.5011
Current ANSI codepage : 1252
Plugins :
DSpellCheck (1.5)
mimeTools (3.1)
NppConverter (4.6)
NppExport (0.4)
NppMarkdownPanel (0.7.3)

but wouldn’t it be better to cancel multiline selection on cursor up and cursor down?

A slightly “better way” is available via the settings under Preferences / Editing 2 / Multi-Editing. Turn off the option Enable Column Selection to Multi-Editing.

When you do that then:

• Left/right arrow keys keep the multi-cursor mode intact. It gets a strange when one or more of the cursors goes of the end of the line as the cursor(s) wrap to the next line.
• Up/down arrow keys cancel the multi-cursor mode and you have one cursor either on the line above or below where the multi-selection was.
• The End key unfortunately cancels the multi-cursor mode. Snapping all the cursors to the end of the lines seems useful. One issue with this is that you can have more than one cursor on a line. Should End put all of them at the end of the line or should it delete the surplus cursors?
• At present Home is like End in that it ends multi-cursor mode. With a standard single cursor Home looks to see if the line had leading spaces or tabs and Home jumps to the first visible character. You tap Home again and it goes to the start of the line. If we remain in multi-cursor mode to we want the various cursors to do this leading space thing?

Something else to consider is Ctrl+Left arrow and Ctrl+Right arrow. Those do word jumps in single cursor mode.

but wouldn’t it be better to cancel multiline selection on cursor up and cursor down?

I tend to agree.

in what situation is moving the multiline-select up and down useful?

I can’t think of any.

So keep the “cursor left” and “cursor right” as-is, but remove cursor up down from the “Column Selection to Multiline editing” behaviour. I mean I can see how moving the multiline-select in certain ways is useful, but I don’t quite understand the practical use-case for keeping the multiline selection when moving up or down:

• Cursor left/right = adjust multiline column position, skip existing column characters when editing etc.
• Cursor up/down = …?
• End key = Use multi-select to quickly add quotes or comma’s at end of lines with irregular lengths (JSON editing for example)
• Home key = Same as left but faster, jump to the start of long lines, re-align column multi select etc.

For example I can change all patient IDs from 001KUL to 05-001 using the multi-select and cursor left/right, see screenshot below. But when I start using cursor up and cursor down the multi-select becomes this weird situation. For example, when I move the multi-line selection up to beyond the start of the file and then press left/right then the first line has 2 cursors blinking(?).

I know the I can cancel the current multilines selection with the Esc key, or disable moving the multiline entirely in Preferences -> Editing 2 -> Enable Column Selection to Multi-editing -> uncheck.

But in what situation is moving the multiline-select up and down useful? Wouldn’t you have to make a new multiline-select in most of those cases anyway?

Sure the basics of making multiple selections was already there, but it was rather like musicians warming up individually for the symphonic performance to come. The attempt was made to get it all working in-concert…and that’s where we’re at now.

I guess the discussion (especially the spin-off to Issue #14266) attracted people who use multi-edit more than they use rectangular selections, and escaped the notice of folks who use rectangular selections all the time and almost never intentionally make a multiple stream selection.

I left a comment on Issue#14464, but I suspect that ship has already sailed. :-(

I feel a bit stupid asking this question, but… is there a list of the intended changes in multi-caret editing?

No reason to feel that way about it.

What kicked off the recent development of the feature was THIS. And yes, I say sheepishly, it was all MY fault. :-)

The user “bitagoras” was a major protagonist on how it should work, i.e, the fancier parts of it.

Sure the basics of making multiple selections was already there, but it was rather like musicians warming up individually for the symphonic performance to come. The attempt was made to get it all working in-concert…and that’s where we’re at now.

Is this by design? How can I avoid this?

I see here:

https://github.com/notepad-plus-plus/notepad-plus-plus/issues/14266

that it is by design, and there is (apparently by the developer’s choice) no option to disable it.

This is annoying for people who use rectangular selections often while rarely if ever using multiple cursors. The solution seems to be to get in the habit of pressing an arrow key (which converts the rectangular selection to an empty multiple selection) and then pressing the Escape key. I believe that will always work.

official issues

I see one already open:

https://github.com/notepad-plus-plus/notepad-plus-plus/issues/14464

I almost never use multiple selections (other than rectangular selections)

This is very likely the way it is for most users; certainly true for me as well.

put in some official issues on the problems with these behaviors

I still need to find time to install a previous version and compare it with the current version, and to look at the actual code changes. I almost never use multiple selections (other than rectangular selections), so I’m not able, by memory, to recognize the difference between what used to be and what is now. Assuming I can get it clear in my own mind, if there isn’t already an issue at that time, I’ll enter one.

• You say above “If you type in either situation…because if you typed into…but if you typed into…” – What did the user type here? More arrow keys/combos or actual text?

I meant typing a character.

Some observations:

• You seem to have a good grasp on all of this

• Due to that good grasp, perhaps you are the best person to put in some official issues on the problems with these behaviors

• You say above “If you type in either situation…because if you typed into…but if you typed into…” – What did the user type here? More arrow keys/combos or actual text?

One piece of the puzzle is that the status bar shows Sel: nx0 = 0 for a zero-width rectangular selection (which is not, per Scintilla’s definition, the same as a thin selection, though it looks and behaves identically to the user), but shows Sel n : 0 | n both for thin selections and for multiple selections in which every selection is empty.

Pressing Esc clears all but the primary selection of a multiple selection, but has no effect on a rectangular selection or a thin selection.

If you make a rectangular selection and use Shift+arrow-keys to modify it, it immediately changes to a multiple selection. If you use Alt+Shift+arrow-keys, it remains a rectangular selection. (This part is visible in the status bar.) If you type in either situation, the result looks the same — all the cursors in line, and the status bar shows Sel n : 0 | n — but the result of pressing Esc is different, because if you typed into a multiple selection, you now have a empty multiple selection (which Esc will reduce to the primary selection); but if you typed into a rectangular selection, you get a thin selection (which Esc does not affect).

So I’d say one of the errors here, which based on your description is not new to 8.6, is that the status bar fails to differentiate between a thin selection and a multiple selection. (In my opinion a thin selection should appear the same as a zero-width rectangular selection, because there is no difference in user-facing behavior.)

Edit to add: Another difference which may be observed between rectangular selections (including zero-width rectangular selections and thin selections) and multiple selections (including empty multiple selections) which only look like rectangular selections is that when you switch to another tab and then switch back, rectangular selections are restored, but multiple selections are not.

That seems like a bug. Typing in column mode should leave you with a Scintilla thin selection , which behaves like a zero-width column selection, not like a multi-caret selection. I’ll have to install an older version to check, but I’m pretty sure that is new, and potentially very disconcerting, behavior.

I have started several times to try to accurately describe the issue so I can post a bug report but have discovered it’s not easy to pin down just where v8.5.8 and v8.6 diverge. v8.5.8 and earlier already seems to have a multi-caret mode. My notes so far have:

I tend to use the keyboard when using Notepad++.

I have the following:

p01
p02
p03
p04
p05
p06
p07
p08
p09

and want to change the leading p to 0 (zero). I deal with this by positioning the cursor at the front of p01 and then with the Shift+Alt keys held down I down-arrow to the line with p09 and then while still holding Shift+Alt down I right-arrow once to create a 9x1 column selection of the letter p. I then type 0 to replace the p with 0.

I think Scintilla is now in SC_SEL_THIN for both v8.5.8 and v8.6. Both versions have a 9 line high cursor blinking after the 0 I just typed. For both the status line changed from Sel : 9x 1 = 9 to Sel 9 : 0 | 9 when I typed the 0.

My notes end there for now as I saw that Esc behaves the same and typing characters behave the same in both versions. Both versions have a 9 line high cursor. I am used to this and have regularly taken advantage of it in v858 and earlier.

I know there is a point of divergence here where any of the arrow keys causes v858 to go back to single cursor mode. When I use any of the arrow keys in v86 it remains in multi-cursor mode. That seems simple enough but the Esc key before and after arrow keys needs to get explored a bit more before I’m not yet comfortable with asking via github that the behavior get changed or at least made configurable.

Now type x. You will see the four ‘x’ in a column as you expect but are also now in multi-caret mode.

That seems like a bug. Typing in column mode should leave you with a Scintilla thin selection, which behaves like a zero-width column selection, not like a multi-caret selection. I’ll have to install an older version to check, but I’m pretty sure that is new, and potentially very disconcerting, behavior.

OK, great pleasure, I will always use the Esc key - just don’t forget.

Unfortunately, the Esc key does not work consistently to get out of multi-caret mode. For example, if you have:

abc
abc
abc
abc
abc
abc

Use Shift+Alt+up or down arrow to create a 4x0 column. The example with abc has six lines but you can position that 4x0 column anywhere. The extra lines make it easier to experiment with up and down arrow.

Now type x. You will see the four ‘x’ in a column as you expect but are also now in multi-caret mode. Pressing Esc at this point will not get you out of multi-caret mode. You need to use any arrow key, which moves the four cursors, and then Esc works.

So far, the workaround I’m using is to use any arrow key and then the reverse, and then Esc. It’s three keystrokes to get out of multi-caret mode. I typically use a Right, Left, Esc finger dance but your fingers may be happier with left/right/Esc, up/down/Esc, or down/up/Esc finger dance.

You can tell which mode are in from the status line but it’s subtle. When you see Sel : 4x0 = 0 then you are in column mode. The 4x0 is the height and width of the column and the 0 is the total number of characters (height multiplied by width) in the column. When you see Sel 4 : 0 | 4 then you are in multi-caret mode. The first ‘4’ is the number of carets. The ‘0’ is the total number of characters selected. The final ‘4’ is the total number of lines that have carets. It’s easier to experiment with that using the mouse. Hold the Ctrl key down and click the mouse in various spots to create carets and/or click-drag the mouse to create selections while watching the status line.

Is this by design? How can I avoid this?

Some people want column selections (the alt+select) to be handled as multi-select as well – and in a multi-select situation, you want to be able to be able to arrow around, and have the multiple carets not aligned, so it was “by design” (though I’m not sure the developer really understood the implications of the implementation chosen).

Unfortunately, this may annoy people who liked column selections staying as column selections, and the developer got rid of the ability to turn that option off from Notepad++'s interface.

I don’t use it, but some people like the BetterMultiSelect plugin, which may-or-may-not handle your use-case better than Notepad++'s v8.6 implementation alone (and I don’t know how the plugin interacts with v8.6 feature set, as compared to the pre-8.6 feature set).