Yesterday, I was facing the issue only with the Download specific site. But today even the main home page seems broken.

Same. Tried on both Chrome and IE

@David-Brigden said:

Guess I just leave those long lines alone manually wrap inside a region

Maybe I misunderstood. Fold/nest (which I was talking about) implies the hiding of lines from a block structure, such as a c-function, like

⊟ int blah(args) { int a = 1; int b = 2; } ⊟ double yo(args) { double a = 1; double b = 2; }

being collapsed down to

⊞ int blah(args) { ⊞ double yo(args) {

Whereas “long lines … wrap” is a completely different setting (View > Word Wrap or equivalent toolbar icon), and just converts

13 Pretend this line... is very, very long 14 And another line

into

13 Pretend this line... is very, very long (but now it is wrapped) 14 And another line

@guy038

thank you for your tests. ~10s for your aged laptop seems to be ok, I guess.

What do you mean by

Your script is correct as long as the word wrap feature is NOT set

?
While testing I didn’t encounter a situation that duplicates still exists after running the script. WordWrap and long lines are performance killers, that’s for sure, but the script should still work correctly.

@Tom-Wak

with the provided data I would assume that something like
find: (?-s)(\w+:\w+):\w+(?=.*)
replace: \1
should do the job.

@liuming-zhu

this is a python programming question rather than a npp related one.
See here. Npp doesn’t silently change your code.
Why you get different result can’t be answered from remote - obviously you do have different configurations.

@Derek-Muller

Afaik, no.

I agree. I was bad. The original post does not belong here and it would be more appropriate in a forum for the programming language involved.

@James-Shanley: Welcome to the Notepad++ Community forum. You said:

I looked at the other file I have that runs properly I found it was saved as a .html file. I saved my other file as one and it worked

Good detective work, @James-Shanley ; I like it when new Community members are so helpful in their first post; it’s a refreshing change from “do everything for me” posts that we often see from new members.

There was a more-recent discussion about that in this other topic from a couple weeks ago (vs years ago for this topic), which came to the same conclusion. As a result, I opened the issue#5903 to request that more file types would allow View > View Current File In… Hopefully, that will make it into a future release.

@Bhavtosh-Sharma

Not really sure what you are going for for #1, but for #2 an approach would be to find all non-digits while disregarding whitespace, maybe something like this:

Find: [^\d\s]+

Thanks a lot, that’s exactly what I need. I know about the difference in the first example, so first I need to apply the space insertion and then replace more than 2 spaces with a semicolon.

Thank you @guy038 that is very helpful! Since I got into the print industry I learned a lot about all the various dashes and spaces, and even non-breaking spaces.

I will very likely be unable to install PythonScript to get that character value since I’m on a multi-user machine I don’t have permissions to install it in c:\program files (x86)\ or any variant thereof. Plus we are super busy right now.

@Ekopalypse Yes, that fixed it, thank you!

Switching to the “new” dialog solves that issue and seems to use the system-wide Save As… dialog.

Thank you for your response. It looks like I lost the file at this point. I tried Recuva but it doesn’t even recognize the file.

@Mohideen-Pitchai

I assume only by using/finding a font which is capable of displaying it correctly, or, if possible, by creating an UDL which sets different fonts for different parts of the text but this means there must be an start and end indicator for each text part.

@Stéphane-Lavergne

you can only edit within the 180 seconds, afterwards it is locked.
Makes sense if one reads your post later because otherwise one would read answers
to questions which don’t match anymore as either answers or questions have been edited.

Hello, @sean, @alan-kilborn, @steven-haymes, and All,

I’m afraid that, in order to use the column mode, in a reliable way, we should align the comma symbols, padding preceding positions with spaces chars !

So, this time, the regex solution seems to be more secure ;-))

For instance, with that sample text, below :

#,6100795442608787,1 #,205300099864,1 #,65433455333,5 #,20530002200815618844,1 #,3360,20 #,718103267854,2 #,67764334775,8

Here is a regex S/R which deletes any non-null range of digits, after the 11th, till the second comma of each line :

SEARCH ^#,\d{11}\K\d+(?=,)

REPLACE Leave EMPTY

Tick the Wrap around

Select the Regular expression search mode

Click, exclusively, on the Replace All button

And, we would obtain the expected result :

#,61007954426,1 #,20530009986,1 #,65433455333,5 #,20530002200,1 #,3360,20 #,71810326785,2 #,67764334775,8

Best Regards,

guy038

Thanks for both useful answers !

Thanks once again @guy038. Your valuable suggestions/corrections have been incorporated once again:

<parser displayName="CiCode" id ="cicode_function" commentExpr="(?x) # free-spacing for commenting (?s:\x2F\x2A.*?\x2A\x2F) # Multi Line Comment: /* ... */ | (?m-s:\x2F{2}.*$) # Single Line Comment: // ... | (?m-s:\!.*$) # Single Line Comment: ! ... | (?s:\x22(?:[^\x22\x5C]|\x5C.)*\x22) # String Literal - Double Quoted | (?s:\x27(?:[^\x27\x5C]|\x5C.)*\x27) # String Literal - Single Quoted " > <function mainExpr="(?x) # free-spacing for commenting (?i) # ignore case FUNCTION\s+ # CiCode functions marked by keyword 'function' (any case) \K # discard everything matched so far - 'function' keyword not part of function name \w+? # function name itself (non-greedy match) \(.*?\) # function parameter list surrounded by brackets " /> </parser>

This is my latest version of the parser with a proper commentExpr parser. (CiCode supports C-style comments with the addition of !<comment-to-end-of-line> being synonymous with //<comment-to-end-of-line>.

One of my files does indeed have several commented functions - these are now correctly ignored. Thanks again.