invisible characters make difficulties -- when searching
-
@Alan-Kilborn said in invisible characters make difficulties -- when searching:
But I only saw this because I have a script which sets “invisible” UTF8 characters to be visible with a “representation”.
Are you using Scintilla Character Representations?
-
@Michael-Vincent said in invisible characters make difficulties -- when searching:
Are you using Scintilla Character Representations?
Yes. Probably originating from a script in (probably) this thread: https://community.notepad-plus-plus.org/topic/14045/invisible-characters-unwanted
But the kicker here is I’m (now) wanting to do it (and, lately, actually doing it) in the “Search result” window. Which, in Pythonscript, isn’t merely as simple as calling
editor.setRepresentation().I suppose the onus is now on me to show how I’m doing it, since I started this… :-) I’ll put something together…
EDIT: BTW, when I said:
“Search result” window doesn’t have a “direct” way either.
I should have said “pun (again) intended” because it involves using something called
SciLexer.Scintilla_DirectFunction
Again, more later when I have time to put something (concise) together. -
@PeterJones said in invisible characters make difficulties -- when searching:
the Find dialog doesn’t have a scintilla component involved
Right. It might be hard (well, harder than what I ended up doing) to show something like this in the Find what box of the Find window.
Why? Well, that box is pure Windows, not Scintilla, so I’m not even sure what “special, invisible” characters would appear like there. I’m fairly certain that each time a Ctrl+f pulls selected characters from a Scintilla window to populate the Find what control with, it undergoes a UTF8 (or whatever Scintilla/N++ encoding is actively set)-to-Windows-mbcs conversion (probably don’t have the exact terminology right here, but the gist is that I mean “whatever encoding Windows uses internally”).
Bottom line, I’m happy with just the search-sanity check that seeing these characters in the “Search results” windows gives me. No more troubles of this nature for me!
note 1: by “mbcs” I meant “multibyte-character-set”
note 2: when I said I’m not even sure what “special, invisible” characters would appear like there, actually if I select just the LTR character and press Ctrl+f, I see “nothing”, except, no, my caret in the Find what control is now different than usual, it glimmers with a rainbow like effect…so this is helpful in one way, but not totally helpful.
-
BTW, lest some be confused by why my “Search results” window examples show:
⮞ "xxx" (0 hits in...rather than:
Search "xxx" (0 hits in...It’s because I already know it is a Search and I don’t need to see that over and over and over each time I run a…search!
So I changed a single line in my
english_customizable.xmlfile:<find-result-title value="⮞"/>and got rid of the pointless info, as much as is reasonable. I could have set it to
""I suppose. -
I’m a bit late on this, but I agree it would make more sense if this was already visible in the search dialog, so you are fully aware of what is being searched for.
But I’m not sure if this is supported by the underlying edit control. Maybe NormalizeString could be helpful in this cases. -
It makes sense to create an issue to “show non-printable characters in the find dialog” somehow.
I assume even if the dialog doesn’t support that character directly, it might be displayed like “·” or something.
And that doesn’t necessarily affect the data copied to the clipboard (i.e. it contains Unicode character as is). -
Or maybe with a warning in the status bar of the search dialog ?
-
@Ekopalypse said in invisible characters make difficulties -- when searching:
Or maybe with a warning in the status bar of the search dialog ?
Actually, I really like that idea, and it’s probably the easiest to implement:
if search-string contains invisible characters, then set status = "Warning: search string contains invisible character(s)". -
I think so too. From my naive point of view, I would guess that looping over the search string and comparing it to a vector of known zero-width characters shouldn’t take too long, since the search string itself is limited in width, (2048?), as far as I remember.
-
Could someone create a corresponding issue with the suggested options, please?
https://github.com/notepad-plus-plus/notepad-plus-plus/issues
