Hello Boliusa bol,

I really wonder how you could find your Arabic characters with that syntax [\ufec1], or even \ufec1 !?

With the BOOST regex library, used from N++ v6.00, I think that the right syntax, to find your two characters, should be \x{fec1} and \x{fec9}.

Your characters are part of the Arabic Presentation Forms-B table, from FE70 to FEFF, at the address, below :

http://www.unicode.org/charts/PDF/UFE70.pdf

Secondly, don’t forget that, in N++, the search is oriented characters and NOT bytes. So, when you search for \x{fec1}, in a file, with an UTF-8 encoding, the regex engine looks for the three consecutive bytes efbb81, which represents the ONLY Arabic character ﻁ

Note that :

With the UCS-2 BE encoding ( Low Endian ), this character would have been encoded with the two bytes C1FE

With the UCS-2 LE encoding ( Big Endian ), this character would have been encoded with the two bytes FEC1

And it good to remind what is the difference, between the UTF-16 and USC-2 encodings :

With the UCS-2 encodings, supported by Notepad++, you can encode any character, from UNICODE code-point \x0 to \x{FFFD}

With the UTF-16 encodings, NOT supported by Notepad++, you can encode ALL UNICODE code-points, from \x0 to \x{10FFFD}, with the surrogate pairs mechanism.

BTW, in N++, the regex syntax \x{...} does NOT work, presently, for code-points over FFFF !

Now, if N++ search is “characters” oriented, how to detect the individual bytes of some characters of an UTF-8 file ? It’s normally impossible and it’s rather useless to do so ! Indeed, with the only syntax \x{fec1}, you’ll always find your ARABIC LETTER TAH ISOLATED FORM, as long as your file’s encoding is an UNICODE encoding !

If you really want to see the individual bytes of an UTF-8 file, just choose the option Encode in ANSI :

For instance, let’s suppose that you have an UTF-8 file with the ONLY ARABIC LETTER AIN ISOLATED FORM : ﻉ. Once you chose the menu option Encoding - Encode in ANSI, it will display the three-characters string ﻉ.

And, as the UTF-8 representation of this character is EF BB 89, it’s easy to verify that the simple regex search of \xEF\xBB\x89 does find the string ﻉ

By the way, here is, below, a very nice Internet tool to get the main informations for each UNICODE character. By default, you must type, on top of the page, the UNICODE hexadecimal code-point of your character ( For instance fec9 ), but you may select one of the six other proposed interpretations :

http://www.cogsci.ed.ac.uk/~richard/utf-8.cgi?

Hope that this post will be useful to you, anyway !

Best Regards,

guy038

P.S. :

Waooh, by chance, the Windows ANSI Code Pages 1252 ( Latin 1 ) and 1256 ( Arabic ) have a same representation, for the three characters, of code \xEF, \xBB and \x89 !

To that purpose, consult the different Windows encodings, below :

https://msdn.microsoft.com/en-us/goglobal/bb964654

I’m not entirely sure what you are asking for, but perhaps if you check the “Wrap around” checkbox in the Find dialog you’ll eventually find what you are looking for…

Hi,

no such problem for me. Tested on Notepad++: v6.8.3 @ Windows 7 x64.

Maybe try also on another PC, mouse, … . Or try to be more specific about your release, programming language, …? Provide more info how to reproduce this issue.

@donho : Thank you very much! Tested, and it works perfectly.

One more question: Do you prefer to post suggestions/bugs here on community, or on GitHub? So I know what is better for you, not to complicate things.
If here, maybe it would be nice to have separated section for it? Or maybe even type of comments, so I can set it as resolved ;). Something like questions. But maybe I’m just thinking too much ;).

@dail : Sure, it would be also nice feature, to close selected text to typed delimiter.

Also one more suggestion for this feature in auto-insert for html/xml close tag. Let’s say we have any xml:

<node name="abc"/>

Then I’d like to add > as value, right after c. Or better say to “value” part. Just to use it while writing regular expression etc… I will get:

<node name="abc></node>"/>

So maybe to ignore this feature even in this case. Sure it’s not best to add non-xml-correct character as value. But I type it normal way. And after it’s done, I use plugin XML Tools -> Convert selection XML to text (). But on the other hand, maybe this is just my different approach, that is not needed globally. Still maybe also others would like to don’t auto-close xml tag while in value area?

Hi,

as far as I see it works in version v6.8.3. It is just not so nice visualized, but moving tabs can be done. Just check that you have UNchecked option Preferences -> General -> Tab Bar -> Lock (no drag and drop).

Hello Joao,

When the possibility to link a parser_ID to a name of user-defined language was, first, added, in N++ v6.5, on October 2014, I noticed that the other method, using the extension name of user-defined files, didn’t work at all. Of course, I informed Don ( and some other guys too ) about that issue ! Refer to the first part of my post, below :

http://sourceforge.net/p/notepad-plus/discussion/331753/thread/627d7ac2/#9ff7

Unfortunately, that issue hasn’t been fixed, yet. So, Joao, in the assocciationMap node, you MUST use the only syntax :

<association userDefinedLangName="OpenSCAD" id="OpenSCAD_file"/>

By the way, you just have to create a new user-defined language with name OpenSCAD, using the extension scad. It’s no use to define the characteristics of your language, to allow your own functionList parser to work :-)

Secondly, I, slightly, changed your regexes for, both, the mainExpr and Expr items :

I suppose that there is, at least, one blank character, after the key words Module and Function

I changed the syntax [\t ], with the simple \h syntax. Indeed, the exact meaning of \h, with the BOOST regex library, used in N++, is [\t \xA0] ( also known as an horizontal blank character )

In expr, I use the \K syntax, which allows the regex engine to forget everything located on the left of this form ! So, the exact name of the module or the function, without any possible leading blank characters, will be displayed in the FunctionList window :-)

Therefore, in the parsers node, add the lines below :

<parser id="OpenSCAD_file" displayName="OpenSCAD" commentExpr="((/*.?*)/|(//.?$))"> <function mainExpr="^\h*(module|function)\h+\w+" displayMode="$functionName"> <functionName> <nameExpr expr="^\h*(module|function)\h+\K\w+"/> </functionName> </function> </parser>

For instance, these regexes allow the detection of these four syntaxes, below :

module Test_1 function Test2 module Test3 function Test_4

Thirdly, your regex, used to detect the comments, ((/*.?*)/|(//.?$)), is NOT a valid regular expression ! So, to define the correct regex, could you tell me the different cases of comments, in OpenSCAD language. From the general form of this regex, I presume that :

A comment line begins with a double slash //

A comment block begins, with the form /* and ends with the form */

Am I right about it ?

See you soon !

Best regards,

guy038

P.S. :

Some people may think : Why couldn’t he use a lookbehind construction in expr ?

Indeed, the form below, with a positive lookbehind , seemingly, should work nice ?

<nameExpr expr="(?<=(module|function)\h+)\w+"/>

But, in the BOOST regex library, lookbehinds must represent an UNIQUE FIXED length strings. So, this regex is INVALID, for two reasons :

The two parts of the alternative, (module|function), have a different length ( 6 characters for the string module and 8 characters for the string function )

The form \h+ is NOT a fixed length string, as it stands for one or more horizontal blank character(s) !

Luckily, the \K syntax allows the regex engine to match :

First, the part of the regex, located before the \K form

Secondly, the part of the regex, located, after the \K form, which is the final regex matched !

Actually, there are a couple using this name. I did not see this one at first. It is using the N++ icon and can clearly be misleading…would be nice to have this removed ASAP!