I think you’ve been around long enough to know better for making such a posting (and in this thread, too, which is reserved for ONLY important issues regarding rel. 8.5.4). It’s sad when people don’t learn…

Whether your examples are a bug or intentional is unknown to myself as $,`, \ are special characters within double quotes as mentioned in

https://www.gnu.org/software/bash/manual/html_node/Double-Quotes.html

and the Bash lexer can optionally highlight code within these strings. The backslash escape looks correct to make $ a literal, though the person who changed the lexer may still see this as a bug in the lexer and may change it. If you want, you can submit a new issue to Lexilla to have it evaluated.

v8.5.3:

v8.5.4:

This can of course be fixed with escaping the ‘$’ sign:

Even though using an unescaped ‘$’ sign inside double quotes when not referencing a variable is not best practice, it should still not break the syntax highlighting.

…
So now everithing is fine!
BTW, maybe the reson of glitch is somewhere in localization? Historically I use russian in npp… Well, maybe it is the good reason to change language finally :)
…

Happy that you solved the problem :)

I checked the sources for Bash (Shell) and it has not changed for about 6 years. I would suspect file corruption in %AppData%\Notepad++\langs.xml as that is where the file extensions and keywords are stored for Bash. Without a working extension identification for Bash, no automatic Bash language selection which causes no document styling and the Save dialog will not pre-select Unix scripts files in the combobox. Append extension string is localized though I consider as less likely as a cause so russian should be good.

• first update - there was no Shell in syntax
• remove of the new version with data stored, then install 8.5.4 - Shell was absent yet
• remove npp (data still not removed!) with rollback to 8.7.4 - there is no Shell again
• full remove includung stored data, then 8.7.4 install - sucsess, Shell returned back!

• update up to 8.5.4 - nothing is spoiled, Shell is OK.
  So now everithing is fine!
  BTW, maybe the reson of glitch is somewhere in localization? Historically I use russian in npp… Well, maybe it is the good reason to change language finally :)

WBR
Kirill

…
There is neither syntax choice (unser 'S, as earlier) not file extantion to save.
…

As for the Save as type, look for Unix script file

Unix script file (*.bash;*.sh;*.bsh;*.csh;*.bash_profile;*.bashrc;*.profile; *.*.*.)

which can append the extension if the checkbox is checked

new 1.bash

Tip: Focus the Save as type combobox and type the letter u and it will select the Unix script file item which can be quicker than viewing the long drop down list to find the item to select.

There is no bash/shell syntax suport here?

It may be confusing because it’s called “Shell” in the Language menu but “Bash” in the Style Configurator.

I update my notepad++ to 8.5.4. Now i have 2 menus with the same name SHA-256. They do 2 different things - one generate sha256 and the other generate sha1. See printscreen. Maybe localization is broken.

That’s exactly the same thing that @Michael-Vincent pointed out in his very first reply in this topic ten days ago. It will be fixed in the next version of Notepad++.

Sorry for my bad english (i am native bulgarian).

I know it but the triggered error is seriously painful to manage.
I’m deploying several hundreds of windows with a syspreped image and if I told my users to manually install the software, they will seriously have a bit of anger toward me…

can’t have the powershell command add-appxprovisionned package working to transform the user-defined package to a computer-defined package
https://learn.microsoft.com/en-us/powershell/module/dism/add-appxprovisionedpackage?view=windowsserver2022-ps

maybe it can be used during the building of the plugin?

Of course none of the themes have been updated with the new SCE_BAT_AFTER_LABEL style (id 8). In fact, the only way to replicate the former style would be to copy and paste the existing label style, adding the attribute styleId=“8”, in every theme’s XML descriptor.

Thanks - verified that works:

Relevant section of my styler file:

        <LexerType name="batch" desc="Batch" ext="">
            <WordsStyle name="DEFAULT" styleID="0" fgColor="E0E2E4" bgColor="202020" fontName="" fontStyle="0" fontSize="" />
            <WordsStyle name="COMMENT" styleID="1" fgColor="66747B" bgColor="202020" fontName="" fontStyle="0" fontSize="" />
            <WordsStyle name="KEYWORDS" styleID="2" fgColor="93C763" bgColor="202020" fontName="" fontStyle="1" fontSize="" keywordClass="instre1">ENABLEEXTENSIONS ENABLEDELAYEDEXPANSION</WordsStyle>
            <WordsStyle name="LABEL" styleID="3" fgColor="A082BD" bgColor="202020" fontName="" fontStyle="1" fontSize="" />
            <WordsStyle name="HIDE SYMBOL" styleID="4" fgColor="D3DA50" bgColor="202020" fontName="" fontStyle="0" fontSize="" />
            <WordsStyle name="COMMAND" styleID="5" fgColor="FFCD22" bgColor="202020" fontName="" fontStyle="0" fontSize="" />
            <WordsStyle name="VARIABLE" styleID="6" fgColor="678CB1" bgColor="202020" fontName="" fontStyle="1" fontSize="" />
            <WordsStyle name="OPERATOR" styleID="7" fgColor="E8E2B7" bgColor="202020" fontName="" fontStyle="1" fontSize="" />
            <WordsStyle name="AFTER LABEL" styleID="8" fgColor="66747B" bgColor="202020" fontName="" fontStyle="1" fontSize="" />
        </LexerType>

Cheers.

@wallobit said in Notepad++ v8.5.4 Release:

Comments in batch files with colons are no longer correctly formatted across the entire line

Hmm, probably because that isn’t a “comment”; it’s a “label”. Comments in batch start with rem but a pseudo comment can start with ::. But a line starting with : is simply a label, even though the rest of the line (after the label) is ignored.

Likely what happened is that the Scintilla lexer for batch “tightened up” the definition of what a label is, and that resulted in the behavior change you’re seeing.

@Alan-Kilborn, that’s exactly what happened.

The former way of styling labels was reported as a bug and changed in Lexilla 5.2.5, which added a new style class for the rest of the line after the first word of the label.

Of course none of the themes have been updated with the new SCE_BAT_AFTER_LABEL style (id 8). In fact, the only way to replicate the former style would be to copy and paste the existing label style, adding the attribute styleId="8", in every theme’s XML descriptor. That’s really a design choice, and there’s no chance that every theme maintainer will universally adopt it.

So, basically, what you see is how Batch labels are going to look from now on.

The ability to “column select” using the Begin/End Select no longer works.

There’s a relatively new command for this, in the main menus:

In the right-click context menu: