Notepad++ v8.6.3 Release Candidate

donho

Notepad++ v8.6.3 Release Candidate:
http://download.notepad-plus-plus.org/repository/8.x/8.6.3.RC/

Note that there might be the same copy/cut problem that we discovered in v8.6.1 on text fields for some non C++ plugins.
It’s not absolutely a regression of this version, and it’s due to this commit:
https://github.com/notepad-plus-plus/notepad-plus-plus/commit/9e7f1e514c44b74f2b4dabac1608ca265f2347a8
To remedy the problem, plugin should call NPPM_MODELESSDIALOG which has existed since the beginning of plugin system.

Notepad++ v8.6.3 Change log:

Make “copy/cut line while no selection” optional. (Fix #14638)
Fix all open files lost after restarting as Admin to save a file. (Fix #14694)
Fix “Replace All” crash & performance issue. (Fix #14630)
Fix calltip crash due to the division by zero. (Fix #14664)
Enhance Function List for Python to support “async def” & colons in argument list. (Fix #13908)
Fix Copy/Cut/Paste issue in Vertical Edge text field in preferences dialog. (Fix #13874)
Fix macro recording twice for some commands. (Fix #5217, #14634)
Fix “Open File” command not working with TAB preceded. (Fix #14543)
Add auto-completion keywords for PHP, JavaScript and CSS. (Fix #14635, #14705)

Coises

@donho said in Notepad++ v8.6.3 Release Candidate:

Note that there might be the same copy/cut problem that we discovered in v8.6.1 on text fields for some non C++ plugins.

I’m being somewhat of a Devil’s advocate here, but I think the question is sure to be raised sooner or later:

If you’re going to include code to work around the cut/copy/paste keyboard shortcut failure in plugins with modeless dialogs that don’t call NPPM_MODELESSDIALOG, why not put it where it will work all the time, instead of only when the corresponding menu options are enabled?

For those trying to follow what is going on:

Changes in how cut, copy and paste work in Notepad++ required changing those commands to be Notepad++ commands instead of Scintilla commands.
That caused problems in certain plugins that neglected a Notepad++ requirement. (My guess is that one or more commonly-used templates for C# plugins omit the required calls to NPPM_MODELESSDIALOG in the model code for docking dialogs.)
A work-around was added in Notepad++ to the part of the code that implements cut, copy and paste commands to redirect those commands back to the plugins when they come from windows that aren’t part of Notepad++ itself.
The changes (1 above) to cut and copy made them functional even when nothing is selected. That bothered enough users that an option is added in this release to restore the old behavior, where those commands are disabled when no text is selected in the edit window.
If the old behavior is chosen, when nothing is selected in the edit window, since the cut and copy commands are disabled, the work-around (3 above) never gets called and the keyboard shortcuts fail in the plugins that needed the work-around.

What could be done:

Instead of putting the work-around in the code that implements the commands, it could go in IsDlgsMsg, just before the return false at the end. The idea would be:

Check to see if the target window for the message is a window from Notepad++ code. (It might be sufficient just to check if it is the main or secondary Scintilla window.)
If it isn’t, check to see if the message is a WM_KEYDOWN for x, c, v, Insert or Delete.
If so, call GetKeyState to see if the right modifier keys are down to make this a cut, copy or paste keyboard shortcut.
If so, find the first dialog window that is an ancestor of (or is) the target window and call IsDialogMessage using that window.
Otherwise, return false.
Get rid of the work-around code in the cut, copy and paste command implementations.

I can attempt to sort out the details and create a commit and a pull request for this if you want it, @donho, though I am unable to promise how quickly I can do it.

donho

@Coises said in Notepad++ v8.6.3 Release Candidate:

If you’re going to include code to work around the cut/copy/paste keyboard shortcut failure in plugins with modeless dialogs that don’t call NPPM_MODELESSDIALOG, why not put it where it will work all the time, instead of only when the corresponding menu options are enabled?

It’s not about only cut/copy/paste keyboard shortcuts, it could, in the future, Ctrl-Z & Ctrl-Y and other Scintilla keyboard shortcuts are moved into Notepad++ code (though it’s not planned yet).
OTOH, the generic solution (NPPM_MODELESSDIALOG) is there for that purpose, and it works fine.
As a result, adding workaround in Notepad++ code for the plugins which don’t want to call (or ignore) the message NPPM_MODELESSDIALOG will not be considered.

Mark Olson

Since we’re discussing NPPM_MODELESSDIALOG, I’d like to mention a few (but not necessarily the only) issues that it creates for C# plugins. The fixes (or at least band-aids) for these issues can be found in NppCSharpPluginPack.

KeyUp and KeyPress event handlers no longer work consistently
Hitting the Enter key no longer creates a newline in multiline textboxes (presumably because the KeyUp message has been consumed by the preprocessing here?)
Hitting the Tab key does not traverse the form’s controls in TabIndex order, but instead follows the order in which the controls became visible/enabled (I think).

To be clear, I am not mentioning these issues to shame Don Ho, or to suggest that NPPM_MODELESSDIALOG is net negative for Notepad++. Don Ho obviously has a hard enough job as it is without having to worry about weird interactions between legacy C++ APIs and Windows Forms. I just want to crystallize generalized “maybe NPPM_MODELESSDIALOG is bad?” concerns into specific issues.

Coises

@Mark-Olson said in Notepad++ v8.6.3 Release Candidate:

Hitting the Enter key no longer creates a newline in multiline textboxes (presumably because the KeyUp message has been consumed by the preprocessing here?)

Does the edit control have both ES_MULTILINE and ES_WANTRETURN styles set?

Mark Olson

@Coises
Good question!
I assume that the Windows Forms analogs of those properties are as follows:

ES_MULTILINE <-> TextBox.MultiLine (this is necessary for a textbox to take up more than one line of vertical space, so there’s really no way to turn this off without ruining the visual presentation of the relevant controls)
ES_WANTRETURN <-> TextBox.AcceptsReturn (the default is False, I tried setting this to True and it didn’t do anything.)

Currently I have a KeyUp trigger that (if a textbox is MultiLine) replaces the selected text in \r\n and then scrolls to the caret. This fix is OK, but:

it doesn’t replace the loss of ability to hold down Enter to add a bunch of consecutive newlines
it overwrites the entire TextBox’s text, which can add latency when there’s a lot of text

Since this discussion is straying away from the topic of Notepad++ 8.6.3, I’m going to repost this as a reply to this topic and suggest that any further suggestions go there.

Mark Olson

I just wanted to say that I’ve tried out the RC, and I’m really happy with it! This is the first version of NPP that I consider an unambiguous improvement over 8.5.8.

donho

I just found a regression/bug:
Putting noColumnToMultiSelect.xml into %APPDATA%\Notepad++\ has no effect after restarting Notepad++.

Could anyone here confirm this regression please?

mkupper

@donho said in Notepad++ v8.6.3 Release Candidate:

I just found a regression/bug:
Putting noColumnToMultiSelect.xml into %APPDATA%\Notepad++\ has no effect after restarting Notepad++.

Could anyone here confirm this regression please?

Please explain that a bit more. I have been using noColumnToMultiSelect.xml in %APPDATA%\Notepad++\ and it seems to be working with v8.6.3. I renamed the file, exit/restart npp, and npp was in multiselect mode.

My test was using the keyboard. While holding Shift+Alt down I used the arrow keys to create a column. I released the Shift+Alt keys and tapped an arrow key.

With a noColumnToMultiSelect.xml file present the editor goes back to normal single cursor mode.
Without a noColumnToMultiSelect.xml file the editor is in multi-cursor mode.

I put the noColumnToMultiSelect.xml file back and the desired behavior is restored. Thus, I’m not certain what to look for that may be a regression.

donho

@mkupper said in Notepad++ v8.6.3 Release Candidate:

Please explain that a bit more.

I did exactly what you’ve done.
With or without %APPDATA%\Notepad++\noColumnToMultiSelect.xml, after creating a column, the arrow forward key (->) doesn’t cancel the column mode, but the whole column returns to vertical carets and move forward.

Obviously there’s something special in my configuration. I’ll find it out.

Thank you for the testing and the confirmation.

donho

@mkupper
It turns out that I’ve installed BetterMultiSelection plugin and I’ve forgot to disable it :D

PeterJones

@donho ,

The original author of this other post hasn’t come back to see my recommendation to post a reply here, so I’ll do it on their behalf: they noticed that, even though wingup pull #48 (fixing some proxy difficulty) has been incorporated into the wingup repo since November 21, 2023, that updated wingup was never tagged; thus, even though there have been three Notepad++ releases since that merge (making this the fourth), the gup.exe that’s shipping with Notepad++ still doesn’t incorporate that fix, which makes it harder to do Notepad++ updates in corporate environments that use a proxy.

I know it’s not a “regression” with this release, and I don’t know whether that’s critical enough to include as a change before converting this RC into a full release or not, but from proxy-users’ perspective, sooner rather than later is probably good – but since the change was accepted last Fall, just not tagged or released, I thought I’d remind you here.

donho

@PeterJones

You’re right to remind me to integrate it into a new version of WinGUp, and include it into the new release.

Thank you for your reminding!

donho

Notepad++ v8.6.3 Release Candidate 2:
https://community.notepad-plus-plus.org/topic/25478/notepad-v8-6-3-rc-2