For example those messages might be doing only part of the job you think they are doing.

That’s probably the best reason right there. :-)

Thanks for the explanation.

Do you have insight into that?

There might be different reasons it depends on the implementation.
For example those messages might be doing only part of the job you think they are doing.
Those are used to notify the message queue of some event. For instance the file might be renamed from outside or from user action within the editor and in both cases the GUI file tab should be updated with the new name - you might use internal message to notify the GUI about that. The same is true if you do some processing in another thread and it needs to notify the main GUI thread about the job it’s doing.
Sometimes internally some action might need to be delayed - internal message might help with that because you can post it.

BR

They are named _INTERNAL_ because they should not be used externally.
In other words they are not part of the Notepad++ plugin API …

Not being part of the API is a valid argument for not using something, because there is no promise of it working a certain way, or continuing to work in the same way in the future.

But there has to be an underlying reason why those specific messages were marked as internal, and not made part of the API. Do you have insight into that?

For “rename”, there are two alternatives available to the plugin developer:

1. use NPPM_MENUCOMMAND with lParam = 41017 to run the File > Rename… menu entry, but that will pop up a dialog box.
2. use the NPPM_SAVECURRENTFILEAS with lParam pointing to a string containing the full path to the new name, and then deleting the old file

What is inherently more dangerous about allowing a plugin to rename an open file, using the same message that Notepad++ uses internally to do the rename after popping up the dialog, compared to allowing a plugin to call that dialog for the rename, or doing a save-as and then delete the original? (Or similarly for other internals with workarounds.)

They are named _INTERNAL_ because they should not be used externally.
In other words they are not part of the Notepad++ plugin API (and thus they are not defined in the plugin include file).
Some may work but it is not guaranteed and you should know what you are doing. Best is to not use them at all.

BR

why it’s … not part of: Plugin Communication: Messages and Notifications

That part’s easy: When that page was created in the new docset, I just started with the messages and notifications that were already documented in the old set. Since I don’t know the internals well, and don’t know the descriptions / usages of the other messages, I just started there. It was better to have some documentation of them, rather than none. But other messages should be documented eventually, including warning as to risks.

What risk is there when using NPPM_INTERNAL_* messages?

I don’t know of the reasons for that “internal” naming scheme, or what risks (if any) are involved. @Ekopalypse or someone else might know better why those are marked _INTERNAL_.

@Ekopalypse has already suggested and is working on documenting some of the non-_INTERNAL_ message documentation that was lacking. He may be willing to try to document the NPPM_INTERNAL_* as well; I’ve asked over there (and he frequents here as well, so he’ll doubly see it). If he doesn’t have the time or expertise to document those, then someone else (you, maybe?) could volunteer to do it. Anyone can fork the usermanual repo and submit a pull-request – it just needs to be reviewed by the team before it will be incorporated.

(I would volunteer to do it, but since I’ve never used most of the messages – and probably none that weren’t documented in the old docs – I’d have to dig through source code, see how they’re used, and try to come up with an explanation myself. That would take quite a while, especially since I have multiple Notepad++ related projects taking up a very limited free time for such things.)