Notepad++ v8.5.3 Release

Jerald Belleza

@donho Tried to install lower version and issue persist. Looks like the problem could be from OS version. I am using Windows 11 Version 22H2 OS Build 22621.1702

donho

@Jerald-Belleza
May I know from which version you have updated to v8.5.3?

donho

@guy038 @Alan-Kilborn

I can see the “inconsistency” of carriage return in saved shortcuts.xml.
However, after replaying the recorded macro, I see no unexpected behaviour. So it’s not a bug to me, or am I missing somethings?

If I am, please provide me here a small (as small as possible) scenario to reproduce the bug. Thank you in advance.

guy038

Hello, @don-ho,

I agree with you, that whatever the EOL of the current file, the macro is always fully functional !

It’s the case when :

You use my Test_CRLF macro with a Windows (CRLF) EOL file
You use my Test_LF macro with a Unix (LF) EOL file
You use my Test_CR macro with a Mac (CR) EOL file

However, I would have expected :

For a current Windows (CRLF) file, the following recording of the line-breaks, in the shortcuts.xml file, with a CR and LF lines ( instead of CR then CRLF ) :

            <Action type="1" message="2170" wParam="0" lParam="0" sParam="
" />
            <Action type="1" message="2170" wParam="0" lParam="0" sParam="
" />

And for a current Unix (LF) file, the following recording of the line-breaks, in the shortcuts.xml file, with two consecutive LF lines ( instead of two CRLF lines ) :

            <Action type="1" message="2170" wParam="0" lParam="0" sParam="
" />
            <Action type="1" message="2170" wParam="0" lParam="0" sParam="
" />

BR

guy038

P.S. :

For a Mac (CR) file, it’ seems OK, as we do have two consecutive CR lines, if current line-endiing is Mac (CR) !

P.P.S. :

This means that it would be necessary to take in account the current line-ending of the current file, while recording these line-breaks / a macro !

PeterJones

@donho said in Notepad++ v8.5.3 Release:

So it’s not a bug to me

Is the exact situation they showed technically a bug? No, because “it works”: it plays back what was recorded.

But since we’re requiring users to hand-edit their macros to get rid of entities, it should at least be done in a readable way, and a way that the user can easily understand. And it doesn’t meant that it isn’t pointing to a bug in the implementation.

For example, a user is hand editing their macro, and they know from Scintilla.iface that 2170 is “ReplaceSel” which maps to SCI_REPLACESEL, and they know from the Scintilla documentation that SCI_REPLACESEL allows any string, not just a string containing a single character. So then while hand-editing, they put in “A new line.[CR][LF]A second line.[CR][LF]” and save their macro file, and restart.

They now run this macro, and the macro inserts a single [LF], not the [CR][LF] that they intended.

If there’s a [CR][LF] in the string that the macro is supposed to insert in the source for the macro, it needs to be inserted into the document as a [CR][LF]. This is a bug, IMO, because the user hand-edited a macro to put in [CR][LF], and the string that they inserted in that command is not the string that gets inserted into their document.

alexolog

@PeterJones said in Notepad++ v8.5.3 Release:

For example, a user is hand editing their macro, and they know from Scintilla.iface that 2170 is “ReplaceSel” which maps to SCI_REPLACESEL, and they know from the Scintilla documentation that SCI_REPLACESEL allows any string, not just a string containing a single character.

I would expect NP++ to include the relevant documentation instead of expecting the (possibly novice) user to start hunting for it. Especially given that the user’s version NP++ may be older than the documentation available online.

Including a snapshot of the relevant documentation with the distribution should be doable.

Alan Kilborn

@alexolog

Everything you said has ABSOLUTELY NOTHING to do with the relevant points being made in this thread, and probably just obfuscates the main thrust of those points. :-(

donho

@guy038 @PeterJones

I see your point.
There’ll be no harm to create a bug for this issue.
I have just no idea how to fix it (for not having the regression).

usmcguy

@donho

“SYSPRP Package NotepadPlusPlus_1.0.0.0_neutral__7njy0v32s6xk6 was installed for a user, but not provisioned for all users. This package will not function properly in the sysprep image.”

Getting this error when trying to SysPrep on Windows 11. Noticed someone posted in the 8.5.2 Release had the same problem.

PeterJones

@usmcguy said in Notepad++ v8.5.3 Release:

Getting this error when trying to SysPrep on Windows 11. Noticed someone posted in the 8.5.2 Release had the same problem.

Did you follow the link in that discussion to the nppShell issue#29? From looking at the beginning and end of that issue, it looks like the fix for that problem is still “in progress”. It might be beneficial for you to study that discussion, looking for insights that the contributors have that might help you in the short term, or at least give you more clarity as to what’s going on, and looking for things that haven’t been said yet that you could add that might help a fix be implemented.

usmcguy

@PeterJones The Link I see (http://download.notepad-plus-plus.org/repository/MISC/nppShell.TEST20/) doesn’t load. Is this the link you were referring to?

PeterJones

@usmcguy said in Notepad++ v8.5.3 Release:

@PeterJones The Link I see (http://download.notepad-plus-plus.org/repository/MISC/nppShell.TEST20/) doesn’t load. Is this the link you were referring to?

No. I was referring to the link https://github.com/notepad-plus-plus/nppShell/issues/29 , which was the link I embedded in my most recent post.

Pete Gomersall

@usmcguy
Just checking if you are running get-appxpackage | remove-appxpackage before running sysprep? I build monthly updates of Windows 10 and 11 and run above command before I run sysprep to create them; did not have an issue with last month’s build that had 8.5.2.

usmcguy

@Pete-Gomersall I did end up using the cmdlet to remove the AppX package before Sysprep.

Cameron Gray

@Jerald-Belleza I noticed this as well (I don’t recall what my previous version I had prior to the upgraded to the v8.5.3 version, but I always keep it updated so it must have been fine in the prior version).

My instance settings are set to “Always multi-instance mode”, but in earlier versions, when selecting multiple files in file explorer and “Edit with Notepad++” context menu option, it would place it in the same new instance not 1 instance per file! I learned this the hard way when I had over 2-dozen files selected! This is quite annoying now because I rely on that functionality and don’t want to have my instance setting to the default “mono instance”.

My OS is Win10 Pro, 22H2 19045.3031

Mark Olson

If anyone else is mildly (or severely!) dissatisfied with the fact that non-printing characters and control characters no longer show up by default, here is an issue that I introduced
and here is the script that I created to show non-printing and control characters but not CR and LF:

from Npp import *

notepad.menuCommand(44130) # toggle all non-printing characters
notepad.menuCommand(44131) # toggle all control characters (e.g., BEL, ENQ)

Alan Kilborn

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

non-printing characters and control characters no longer show up by default

I haven’t looked at your issue, but defaults for these settings in 8.5.3 are:

Show Non-Printing Characters (checkmarked)
Show Control Characters & Unicode EOL (checkmarked)

guy038

There’s something that I don’t like regarding the new behaviour of the Show Symbol feature !

To explain my annoyance, follow these simple steps :

First, ensure that NO line is checked when selecting the View > Show Symbol menu
In a new UTF-8 tab, add the following line, which ends with a line-break

abc    def	ghi jklmno pqr

This line contains the string abc, then four Space chars, the string def, a Tab char, the string ghi, the Narrow Non Breaking Space char, the string jkl, the ETX char, the string mno, the LS char, the string pqr and ends with the usual \r\n line-break

Note that, as no Show Symbol option is set, at this time, the 3 chars between the strings jkl, mno and pqr cannot be seen in N++ and the Spaces and Tabs are only visible as blank chars ( Logical )

Now, successively, click on :

The View > Show Symbol > Show Space and Tab option

=> The Space characters between abc and def, as well as the tab character between def and ghi should be seen

The View > Show Symbol > Show End of Line option

=> The \r\n ( or \n ) characters should be seen

The View > Show Symbol > Show Non-Printing Characters option

=> The Narrow Non Breaking Space character should be seen

The View > Show Symbol > Show Control Characters & Unicode EOL option

=> The two characters ETX and LS should be seen

So far, everything seems logical !

However, you’ll note that the Show All Characters option was automatically checked, when we previously check the Show Control Characters & Unicode EOL option

Now, click a first time on the ¶ button ( standing for the Show All Characters option ) of the Tools bar => No visible change as all the options of the Show Symbol menu are checked ( Normal )

Then, click a second time on the ¶ button => At once, all the symbols disappeared ! Of course, it has always been the behaviour of this option. However, regarding all the new options added to the Show Symbol menu, I was expecting that :

The View > Show Symbol > Show Space and Tab option would be still checked
The View > Show Symbol > Show Non-Printing Characters option would be still checked
The View > Show Symbol > Show Control Characters & Unicode EOL option would be sill checked

Presently, after this second click on the ¶ button, we, unfortunately, have to redo all the process to be able to see most of these special characters, again !

What is your feelings regarding my proposition ? So, in other words :

The ¶ button would check the Show All Characters option, if presently not checked
The ¶ button would uncheck the Show End of Line option only, if presently checked

Best Regards,

guy038

datatraveller1

@guy038 It seems I commented nearly the same here: https://github.com/notepad-plus-plus/notepad-plus-plus/issues/13734#issuecomment-1575470110

Tragen

@PeterJones

I had the problem that the XML parsers from Microsoft ignoring CRLF in Text and always returning only LF. I don’t know if that’s in the spec but this is what happens if you read the XML.
So you will never get the real CRLF until you encode it somehow or use CDATA sections.