@donho
Sometimes there are users (like me) that do some silly thing, that are not expected.

In version 8.6 a new style had been introduced: “Multi selected text colour”. The effect for me was, that in column-select mode the selection was shown only partially (last line only). It took me some time to find out what was my fault. I use a personalised style, where the default background colour happens to have the value “C0C0C0”, the same value as the background for this new style. Therefore I could not see the selection because it had the same bg-colour as the rest of my text. For “Selected text colour” I use the value “A0A0A0”; after applying this value to the new style, it worked again.

I know, it is really a very special case, but it may happen. A similar situation might arise with other changes in the future. For these cases it would help to have a backup for comparison.

So with installation of a new notepad 8.9 version, these settings in shortcuts.xml should be updated (maybe automatically with installation):

from:
1c3beaba-3b9c-46be-8fff-2f9dace10a63-image.png

to:
f08a7ae4-6d8d-486a-89b2-57b79dee1091-image.png

I’m only a user so I don’t know the details, but maybe simply CR could be changed to 
 and CRLF to 
 (and if existent LF to 
)?

@Terry-R
Thanks for letting me know.

@xomx After restarting our Samba instance, the issues appear to be resolved. Apologies for the false alarm, but thank you for the responses!

@Terry-R This is very helpful and I was unaware of that issue. Thank you. Based on dates, it looks like I was using 8.8.5. It seems likely, especially the description of removing the structure around the installation.

@guy038 said in Columns++ version 1.3: All Unicode, all the time:

As you can see, a lot of Format characters return an erroneous result of 3,240 occurrences. But we’re not going to bother about these wrong equivalence classes, as long as the similar collating names, with the [[.XXX.]] syntax, are totally correct !

Luckily, all the other equivalence classes are also correct, except for [[=ls=]] which returns 2 matches \x{2028} and \x{FE47} ??

Still looking into this, I find this statement in the Boost::regex documentation (emphasis mine):

An expression of the form [[=col=]], matches any character or collating element whose primary sort key is the same as that for collating element col, as with collating elements the name col may be a symbolic name. A primary sort key is one that ignores case, accentation, or locale-specific tailorings; so for example [[=a=]] matches any of the characters: a, À, Á, Â, Ã, Ä, Å, A, à, á, â, ã, ä and å. Unfortunately implementation of this is reliant on the platform’s collation and localisation support; this feature can not be relied upon to work portably across all platforms, or even all locales on one platform.

I used:

LCMapStringEx(locale.data(), LCMAP_SORTKEY | LINGUISTIC_IGNOREDIACRITIC | NORM_IGNORECASE | NORM_IGNOREKANATYPE | NORM_IGNOREWIDTH | NORM_LINGUISTIC_CASING, ...

as my best guess at how to do this.

There are some differences other than the format characters between my search and Notepad++. For example, [[=k=]] matches Ʞ (U+A7B0) in Columns++ search, but not in Notepad++ native search; though both match its lower-case counterpart, ʞ (U+029E).

I do wonder why [[=ls=]] matches ﹇ (U+FE47) as well as U+2028. Though Notepad++ native search does not accept the [[=ls=]] syntax, substituting the actual U+2028 character, [[=
=]] (you can copy that even though you can’t see it), yields 12 matches, including U+FE47.

Do you know if there is a precise definition of what should count as an equivalence class in Unicode regular expressions? It is unclear to me for what target I should be aiming.

FYI
For the security reason, the https://download.notepad-plus-plus.org/ will be shutdown for some days.
It might be back online next year.

@guy038 said in Perl keywords "class" and "method" not recognised by Function List:

for these two syntaxes, I just supposed that standard ASCII characters are used, from \x20 to \x7E, except for \x28 and \x29 in one part and \x7B in second part ! May be, the \t should be part of each class character, either

Perl allows Unicode alphanumeric/“word character” in any such identifier or token (just cannot start with a numeric), so restricting to ASCII is not going to work

@Coises

Already an issue about this feature:
https://github.com/notepad-plus-plus/notepad-plus-plus/issues/17170

The 2 blank tabs known when the feature was committed:
https://github.com/notepad-plus-plus/notepad-plus-plus/issues/11134#issuecomment-1575226268

@Charles-Fraichot

Glad you found a good solution. Thanks for letting us know.

Thank you for your explanation! I’m glad I wasn’t alone with this problem. It’s very well written and easy for me to understand. Thank you!

@Alan-Kilborn said in 'Find in Files' doesn't appear to work:

If a folder doesn’t exist, I think when the search is initiated, input focus will immediately jump to the Directory: box, signaling a problem with that folder to the user (without a message box). Not on a PC right now, so can’t verify; going from memory.

I see you are correct. However… I also see that the search results show 0 files searched. So I don’t see how it could be a problem with what is in the Find box. The directory might exist, but not be the one OP meant to search.

OK, if it’s the intended behaviour then I’ll just live with it. It’s not a very big deal.

Thank you all who answered!

@Laura-Harrison ,

Don’t post essentially the same thing twice. The posting form reminds you that until you have enough upvotes, you have to wait for the posting queue for the post to show up.

If all of your badly-quoted dates have the quotes in exactly the same places (3 digits, quote, digit, hyphen, quote, digit, quote, digit, hyphen, quote, two digits), then you can use a similar idea to above, but put each into capture groups using the (...) notation: FIND = (\d{3})"(\d)-"(\d)"(\d)-"(\d{2}) . Each capture group gets numbered 1-5 for each set of parens, and is $1 - $5 in the REPLACE WITH field. So REPLACE WITH = "$1$2-$3$4-$5"
This will take

199"0-"0"8-"28 199"2-"1"1-"12

and make it

"1990-08-28" "1992-11-12"

But I have a feeling you are going to tell me in the next post that what you really have is quotes in different places each time, like

1"99"0-"0"8-"28 199"2-"1"1-"12 "2"0"2"6"0"1"0"6"

In which case, I’d say, look for “possible quote, digit, possible quote, digit, possible quote, …etc”, where “possible quote” is in regex as "? (which means "0 or 1 quote mark)
FIND = "?(\d)"?(\d)"?(\d)"?(\d)"?-"?(\d)"?(\d)"?-"?(\d)"?(\d)"?
REPLACE = "$1$2$3$4-$5$6-$7$8"
REPLACE ALL
would give

"1990-08-28" "1992-11-12" "2026-01-06"

(Note that if you had more digits than that, like if you also had hh:mm:ss, so it would be up to 14, the replacements for 10-14 would be ${10} - ${14})

Chill, Peter :-) Breath in, breath out. Everything is fine. (This is meant in a very positive way. I feel that you are very busy right now.)

Of course, yes, this is definitly no big deal. But it is nothing wrong in talking about it. Or just bringing up a question about it. Or an idea.

IMO, Thomas is not wrong with his observation/question/request. The red x icon is the only colorized icon while using light mode and fluent UI. So a more consistant behaviour would be, to have the x icon appearance coupled on the icon choice rather than the light/dark mode choice. (Means red x icon coupled to standard icons, a fluent x icon to the fluent UI.)

Yes sure, this issue is nothing important compared to the more urgent topics in the issue tracker.

@xomx said in Notepad++ 8.8.8: 2 issues detected:

or the 3rd option - as I said, create new MenuIcons plugin GitHub issue and its author most likely fixes it and publishes a new compatible version

Oh yes, of course, sorry. The third option is to create a GitHub issue which I’ve done. Here’s the link if anyone else should mention experiencing similar behaviour:

https://github.com/francostellari/NppPlugins/issues/73

@Terry-R This has worked perfectly. Its a very long document so this was great. Thanks again, greatly appreciated.

@Eric-Wiseman said in Bug in sorting lines, staying there for years:

Line Operations -> Sort lines works ONLY if you convert Edit -> EOL Conversion ->Unix.

Unless I am missing something this looks like a bug…

As others have already explained, this is not a bug but rather a known and documented limitation, that all line endings must be the same.

If Sort Lines In Locale Order Ascending and Descending do what you want, those sorts implemented differently and are not dependent on consistent line endings. The ending for each line will remain with the text of the line it follows.

The Locale sorts can also sort using a rectangular selection for the keys even if there are tabs or characters of differing byte widths (such as can happen with non-ASCII characters in UTF-8) to the left of the selection, which does not work with the other sorts.

@PeterJones said in Config Files Need Updating, Too:

But, unfortunately, there were a few growing pains in transferring from the plugin to the builtin that I was really hoping wouldn’t happen, because I had ironed out so many problems in the plugin version already.

That IS why it’s called ‘developing’. and maintainers are ‘developers’. :-)

If I ever saw a first version of anything that worked unscathed on the first try, I’d be digging through the code looking for the bomb that went undetected. :-)