NPPN_FILEOPENED doesn't work as expected

[ffes]

When a file is opened the message NPPN_FILEOPENED is send to the the plugin notifier (NppIO.cpp line 244). But when this message is handle by a plugin, all following message still use the buffer of the previous file opened. For instance the message NPPM_GETFULLCURRENTPATH still return the path of previous opened path and SCI_* messages still look at the buffer of the previous file.

That is because the only at the end of fileOpen() (in NppIO.cpp as well) switchToFile() is called which sets everything right for plugins to deal with the last newly opened file.

The only moment when NPP_FILEOPENED works as expected is when the very first file is opened and the current document is an empty "new 0".

Is this the intended behavior of NPP_FILEOPENED? If not, what the best way to fix this. I gladly submit a PR, because I need it to get my new plugin to work.

[sanastasiou]

Have you tried using NPPN_BUFFERACTIVATED ? Works fine for me.

[ffes]

@sanastasiou I'm afraid that is the only workaround for my problem. I used that message in other plugin as well. But then I need to maintain a list of opened files to assure the plugin only does its thing when the files are opened/activated for the first time and not switched to.

Problem remains... What is the use of a message NPPN_FILEOPENED when API calls after that message don't work on the file just opened.

[sanastasiou]

Heh, I do exactly the same thing in my plugin :).. I guess we need to fix the core of the problem indeed.

[ffes]

I gladly help to fix this problem. But I would first like to know what @donho thinks of this problem/question. If he thinks NPPN_FILEOPENED works as expected and won't except a PR, there is no use to use afford in creating one in the first place. If he agrees this is a problem he probably has good ideas how we can fix it.

[dail8859]

I have also ran into this. My solution was to do exactly what @ffes does and maintain a list of opened files that had not been activated for the first time.

I do understand why NPPN_FILEOPENED behaves the way it does. A "file" is part of a "buffer" (the buffer also includes information like cursor position, syntax highlighting, etc). Since there are only messages (e.g. NPPM_GETFULLCURRENTPATH) to work with the current buffer, you have to wait until the buffer is activated to use certain messages.

I don't think changing the behavior of NPPN_FILEOPENED is a good idea because many other plugins may need it to operate the way it currently does -- whether or not it is right or wrong.

A better long term solution might be to create new messages such as NPPM_GET_BUFFER_FULLPATH which takes a bufferID as a parameter, so that information can be retrieved about the buffer but without needing it activated.

[sanastasiou]

On the same page, it would also be helpful to have something like

NPPM_SAVEFILEWITHPATH

In my plugin, I need to save all opened files of my dsl, and currently to do this, I have to first switch to every file I need to save. Maybe I'll open up a feature request.

[ffes]

@dail8859 I still think the current behavior makes the NPPN_FILEOPENED message useless. But maybe that is just me.
You're right that fixing it could break other plugins. Does anybody know a plugin that actually uses this message?

And still curious what @donho thinks about this.

Anyway, I will use the NPPN_BUFFERACTIVED message to get my plugin to work.

[ffes]

To make all the features I have planned by now for my plugin work NPPN_FILEOPENED is not enough and I do need the NPPN_BUFFERACTIVED message.

So since my personal need is gone to fix this problem (if that would be a wise thing to do in the first place because it might break other plugins) I think I will close this issue in a couple of days, unless someone want to keep it opened.

[milipili]

I reopen the issue to keep the conversation active since questions have been asked

[MetaChuh]

closed due to:

• author has closed this issue in 2015 himself.
• the conversation was not continued after internal reopening.