Two buffer-activated notifications instead of just one

Alan Kilborn

Consider the following short PythonScript:

from Npp import *
def bufferactivated_callback(args): print(notepad.getCurrentFilename(), args)
notepad.callback(bufferactivated_callback, [NOTIFICATION.BUFFERACTIVATED])

With this installed, set up the following scenario:

have 2 tabs open in each view
in the inactive view, click on the inactive tab

Notice that there are two indications in the PythonScript console that documents have been activated, not just one.

It seems that if you activate a tab other than the active one in the view that is not active (wow, say THAT 3 times fast!), first the existing active tab in that view produces a notify, then the tab that you are intending to activate produces a notify.

What’s the feeling here, is the first notify a bug?

PeterJones

@Alan-Kilborn said in Two buffer-activated notifications instead of just one:

first the existing active tab in that view produces a notify, then the tab that you are intending to activate produces a notify.

What’s the feeling here, is the first notify a bug?

Confusing? Definitely. A bug? I’m not sure.

My guess is that the way that Notepad++ has implemented view-change-plus-tab-change is internally as two separate events, where the view gets activated first (and thus the currently-active tab from that view), then changing to the new tab. So, from that perspective, it makes a certain sense to send a notification for each step of the process, since Notepad++ is technically taking each of those steps.

But from the script/plugin-writer’s perspective, I can definitely see that the desire would be to just be notified for the “actual” (second) tab activation.

Alan Kilborn

@PeterJones

Thanks for your thoughts, Peter.

But from the script/plugin-writer’s perspective…

Right; the normal N++ user doesn’t notice that this happens.

But if the user is using e.g. a plugin that does a not-insignificant operation on buff-activated, and that operation is time-related to the size of the file, and the currently-active tab in the inactive view is absolutely huge and the above happens, the user can notice.

Maybe I’ll open an issue about this, as an “advisory” rather than a “bug”…

Coises

@Alan-Kilborn said in Two buffer-activated notifications instead of just one:

But if the user is using e.g. a plugin that does a not-insignificant operation on buff-activated, and that operation is time-related to the size of the file, and the currently-active tab in the inactive view is absolutely huge and the above happens, the user can notice.

I can confirm from implementing Columns++ Elastic tabstops that this is an annoying problem. (I’ve worked around most of it, but there is a specific case I cannot mitigate.)

I think Notepad++ sends NPPN_BUFFERACTIVATED whenever it loads a Scintilla document into a view; but there are times when it does that only temporarily. It could be that the path through Notepad++ is such that it doesn’t “know” at the time it sends the message whether it will be temporary.

The best way I have found to work around it is to try to write NPPN_BUFFERACTIVATED processing such that doing it repeatedly on a file that hasn’t changed does nothing, and does it quickly. That usually means tracking changes with SCN_MODIFIED and keeping a map that associates Scintilla document IDs, Notepad++ buffer IDs, and status information. It’s ugly.

Edit to add: It is possible that one could wait for an SCN_UPDATEUI notification. Now that I think of it, I don’t believe I tried deferring the slow operation I can’t escape to that message; but it’s rare enough, now — and I have a progress box with a cancel button that shows up when it happens — that I don’t want to make things even more complicated than they already are.