I said in Columns++ version 1.1:

There is a serious fault in my progress dialogs.
[…]
What I discovered today is that the progress dialogs themselves cause the operation to take many times longer

This is fixed in Columns++ v1.1.2.

I’m still seeing misbehavior when the same file is visible in both views, elastic tabstops is enabled for the file, there is a rectangular selection in one view, and you make edits in the other view (e.g., that enlarge a column to the left of the selection). It might be that this is like the old joke — “Doctor, it hurts when I do this!” / “Well… don’t do that!” — but I’m not sure what is happening. It looks, superficially, as if perhaps the selection remains correct but the display is wrong… then, after sufficient scrolling about, it rights itself. Very strange.

So I guess the bottom line is, another update to the 1.1.* sequence that is not yet marked as stable, and quite possibly not the last before things settle down.

@Mark-Olson said in how to call the API to rename a new tab?:

calling NPPM_INTERNAL_SETFILENAME does not automatically trigger the NPPN_FILEBEFFORERENAME and NPPN_FILERENAMED notifications,

I can’t think of any circumstance where I’d care about this. But, I suppose it could be important to others…

@PeterJones
I managed to chat with him on Twitter, and got these answers:

He did not continue with the ViSimulator because:
a. He switched laptop and not using Windows at that time.
b. Lost the code because lost his git account.

He is using Windows again due to needing the MS Office and other tools, and He mentioned that he will try to find a long holiday to rewrite the plugin as per my current request:)

@Zhixun-Qu USE SendDlgItemMessage OK.

@Alan-Kilborn Thanks.solved。

@Ekopalypse done!

@glandon OK, please forgive my ignorance

LRESULT bufID = ::SendMessage(g_nppData._nppHandle, NPPM_GETCURRENTBUFFERID, 0, 0);

Hello, @robin-ramy, @ekopalypse, @alan-kilborn, @michael-vincent and All,

@michael-vincent, I tried your very fresh new release v2.2.1.1 of your plugin, on my two laptops :

An old 32 bits XP machine

A 64 bits Windows 10 machine

Regarding the XP machine, it seems to not work anymore ! I suppose that this is an expected dehaviour as XP is quite out of date !

I don’t mind to stay with the previous 2.1.2.1 release on my old laptop.

BTW, this previous version seems to work even if I check the Use DirectWrite option. But, I suppose that it’s just because, globally, the DirectWrite technology does not work properly with Win XP ?

Now, regarding the W10 64 bits machine, no trouble at all ! However, I noticed some oddities about the coloring !

Note that these oddities are identical on both 32 and 64 versions of your plugin, for the two releases 2.1.2.1 and 2.2.1.1

As a reminder, the coloring is visible ONLY IF a document is opened with one of these four languages :

CSS

HTML

JavaScript

XML

So, @michael-vincent :

Insert this text below in a new tab •-------------------------------------------•---------------------------------------------•--------------------• | | W10 64 bits machine | XP 32 bits machine | | •---------------------------------------------•--------------------• | | N++ 8.6.5 64 bits / 32 bits | N++ 7.9.2 32 bits | | •---------------------------------------------•--------------------• | | Version 2.1.2.1 / 2.2.1.1 32 / 64 bits | 2.1.2.1 32 bits | •-------------------------------------------•---------------------------------------------•--------------------• | #ECBA57 | Coloring OK | Coloring OK | | | | | | rgb(236,186,87) | Coloring OK | Coloring OK | | | | | | rgba(236,186,87,1) | Coloring OK | Coloring OK | | | | | | hsl(40,0.80,0.63) | Coloring OK | Coloring OK | | | | | | hsl(40,80%,63%) | Coloring OK | Coloring OK | | | | | | hsla(40,0.80,0.63,1) | Coloring OK | Coloring OK | | | | | | hsla(40,80%,63%,1) | Coloring OK | Coloring OK | | | | | | | | | | <some_tag>#ECBA57</some_tag> | Coloring OK | Coloring OK | | | | | | <some_tag>rgb(236,186,87)</some_tag> | Coloring OK | Coloring OK | | | | | | <some_tag>rgba(236,186,87,1)</some_tag> | Coloring OK | Coloring OK | | | | | | <some_tag>hsl(40,0.80,0.63)</some_tag> | Coloring OK | Coloring OK | | | | | | <some_tag>hsl(40,80%,63%)</some_tag> | Coloring OK | Coloring OK | | | | | | <some_tag>hsla(40,0.80,0.63,1)</some_tag> | Coloring OK | Coloring OK | | | | | | <some_tag>hsla(40,80%,63%,1)</some_tag> | Coloring OK | Coloring OK | | | | | | | | | | "ECBA57 | Coloring ?? | Coloring ?? | | | | | | "ECBA57" | Coloring ?? | Coloring ?? | | | | | | fgColor "ECBA57 | Coloring ?? | Coloring ?? | | | | | | fgColor "ECBA57" | Coloring ?? | Coloring ?? | | | | | | fgColor "ECBA57 to get | Coloring ?? | Coloring ?? | | | | | | fgColor "ECBA57" to get | Coloring ?? | Coloring ?? | | | | | | fgColor="ECBA57 | Coloring ?? | Coloring ?? | | | | | | fgColor="ECBA57" | Coloring OK | Coloring OK | | | | | | fgColor="ECBA57 to get | Coloring ?? | Coloring ?? | | | | | | fgColor="ECBA57" to get | Coloring OK | Coloring OK | | | | | | | | | | #ECBA57 | Coloring OK | Coloring OK | | | | | | fgColor #ECBA57 | Coloring OK | Coloring OK | | | | | | fgColor #ECBA57 to get | Coloring OK | Coloring OK | | | | | | fgColor=#ECBA57 | Coloring OK | Coloring OK | | | | | | fgColor=#ECBA57 to get | Coloring OK | Coloring OK | | | | | | | | | | "#ECBA57 | Coloring OK | Coloring OK | | | | | | "#ECBA57" | Coloring OK | Coloring OK | | | | | | fgColor "#ECBA57 | Coloring OK | Coloring OK | | | | | | fgColor "#ECBA57" | Coloring OK | Coloring OK | | | | | | fgColor "#ECBA57 to get | Coloring OK | Coloring OK | | | | | | fgColor "#ECBA57" to get | Coloring OK | Coloring OK | | | | | | fgColor="#ECBA57 | Coloring OK | Coloring OK | | | | | | fgColor="#ECBA57" | Coloring OK | Coloring OK | | | | | | fgColor="#ECBA57 to get | Coloring OK | Coloring OK | | | | | | fgColor="#ECBA57" to get | Coloring OK | Coloring OK | | | | | | | | | | (#ECBA57 | Coloring OK | Coloring OK | | | | | | (#ECBA57) | Coloring OK | Coloring OK | | | | | | fgColor (#ECBA57 | Coloring OK | Coloring OK | | | | | | fgColor (#ECBA57) | Coloring OK | Coloring OK | | | | | | fgColor (#ECBA57 to get | Coloring OK | Coloring OK | | | | | | fgColor (#ECBA57) to get | Coloring OK | Coloring OK | | | | | | fgColor=(#ECBA57 | Coloring OK | Coloring OK | | | | | | fgColor=(#ECBA57) | Coloring OK | Coloring OK | | | | | | fgColor=(#ECBA57 to get | Coloring OK | Coloring OK | | | | | | fgColor=(#ECBA57) to get | Coloring OK | Coloring OK | | | | | | | | | | fgColor #ECBA57; | Coloring OK | Coloring OK | | | | | | fgColor=#ECBA57; | Coloring OK | Coloring OK | | | | | | | | | | fgColor #ECBA57. | Coloring OK | Coloring OK | | | | | | fgColor=#ECBA57. | Coloring OK | Coloring OK | •-------------------------------------------•---------------------------------------------•--------------------• Affect the HTML language ( Language > H > HTML ) to this text

=> You should see, at once, the coloring of the lines, in the first column

To all : an important point to note is that if you double-click on any hexadecimal numùber or within the zones rgb, rgba, hsl or hsla , it opens the Color Palette, as expected. Just test it ;-))

Howener, @michael-vincent, you can see that, for few lines, the coloring is not trigerred, although the double-click works nicely !

So, could you consider these small issues, specifically the three cases "ECBA57", fgColor "ECBA57" and fgColor "ECBA57" to get ?

As usual, @michael-vincent, there’s no obligation to do so. Just do as you please !

Best Regards,

guy038

@Hack-Lag ,

You are right, the Document List doesn’t have a way to change the order of tabs. But all you have to do is drag the tab title in the tab bar, and you can move it wherever you want… so Notepad++ can accomplish your goal, just not in your preferred interface.

That said, this feature was officially requested last year, so you could go put your comments there, in a place where the developer will see them. (As explained in our FAQ, this Community Forum is not the feature-request/bug-report tracker.)

@rdipardo Perfect, with your guide, my code works well again, thanks!

@PeterJones Thanks for the insights, Peter, but I’m not sure where this gets me.

All of these threads are about keeping the connection active. Problems are mentioned which seemingly have prevented that approach from getting and staying off the ground.

My ideas are the opposite. Kill the connection. After each upload, if that’s easiest. Triggering a file save reopens it automatically, so there is no reason to keep it alive… am I missing something?

@PeterJones said in NLog support in Notepad++?:

Analyse plugin

My first thought on reading the OP’s original post was that he is already using Analyse. Maybe not though.

if it has the ability to automatically apply styles

I don’t believe so…but it has been some time since I used it (at work) and I don’t have it at home…

@Coises said in ASCII compatibility questions:

I got the impression somewhere — and now I cannot remember where — that Notepad++ converts certain character sets to UTF-8 on loading (and back again on saving).

I know for certain that Geany does that. You may be thinking of N++'s option to encode “opened ANSI files” as UTF-8 under Settings > New Document > Encoding, which seems to be enabled by default. There’s a least one open issue suggesting that 8-bit ANSI is what you get when that option is turned off.

What I wondered was if, in fact, it is known that by the time Notepad++ has loaded a file into Scintilla, the first or both of the properties I mentioned will always be true of the Scintilla text.

My impression is that “Scintilla text” is always a stream of “raw” 32-bit code points; in other words, the API treats every “character” as an int, never an 8-bit char. Of course the application has to encode the stream at some point; exactly when is hard to pin down. It’s probably much earlier than anything a plugin could detect. Asking Scintilla about a document’s target encoding through any of the querying APIs returns only general information, at least in my limited experience.

@PeterJones said in Additional languages (dipping my toes into code contribution):

Accepted and merged today! 🎉🥳

I saw, downloaded and tested. Already updated my custom theme for Go. Now I just have to learn how to actually use that language :-P

Congratulations!

Cheers.

@rdipardo ok, thanks! will continue the discussion there.
(I think the ARM architecture will become more and more important in the future)

@Paul-Baker said in How to iterate over the NPP file tabs (open files)?:

It’s not clear why you are recommending that the buffer id be removed on file close

I think it’s good housekeeping to delete all data regarding a file that no longer exists. In this particular case it doesn’t really matter whether you delete data on file close, but I’m sure you can imagine cases where it matters quite a lot.

@pbarney ,

I added the Hn colors and horizontal bars. I also added automatic light-mode/dark-mode switching (so it follows your browser preferences now… which I hope will make dark-mode-using folks happy)

@Coises

So far, so good — I’m unable to replicate the anomaly under same as previous circumstances. Thanks! Will let you know if it rears its ugly head again and I have any reason to think Columns++ is involved.

Here’s a classic thead from almost a decade ago, on the same subject: https://community.notepad-plus-plus.org/topic/250

@Lhuillier-Sébastien @Lycan-Thrope
Hi

I have another idea from a friend

https://www.sebastien-lhuillier.com/index.php/informatique/prog-112/scripts-en-vrac/922-comment-reformater-avec-notepad-des-pages-html-dont-les-tag-contiennent-des-propriete-data

I have tested and It works