Additional Npp messages needed

Ekopalypse

@PeterJones, @Alan-Kilborn, @michael-vincent, @Derek-Brown, @dail, @Nick-Brown, @Vitalii-Dovgan, @pnedev, @Bas-de-Reuver

There is an area in the LSP protocol that relates to workspaces that, in my view, cannot simply be implemented by a plugin due to lack of support from Npp. Before I make a FR, I wanted to discuss this to see what your opinions are.

Briefly to my understanding of what this is about on the part of LSP.
A language server needs to know that a project (workspace) can consist of one or more root directories.
This is supported by Npp through Projects (multiple root directories) and FAW (one root directory).

In order to be able to use this in an LSP client, however, further Npp requests are required that provide information about which directories are available in this regard.
For example, nppm_getfawroot which returns a directory and nppm_getprojectroots which returns an array of directories. Furthermore, it would be advantageous if changes in these directories could be delivered via notifications. However, this could also be realised via a separate mechanism if the directories can be queried. What do you think?

The open question would be:
What if FAW or Projects are not visible, what should be returned by the nppm_* requests?
I am of the opinion that the current configuration should also be determined and returned and the LSP client compares whether the current document is contained there.
What do you think? Am I missing something?

Sorry for explicitly pinging individual members, but I hope and think that this is also relevant for you.

Michael Vincent

@ekopalypse said in Additional Npp messages needed:

What if FAW or Projects are not visible, what should be returned by the nppm_* requests?

That’s a great question as I never use Projects Panel(s) and rarely use Folder as Workspace. I use the Explorer plugin for file system access and I use an NppExec script to set a “project directory” that my other NppExec scripts (compile, run, lint, etc.) can “see” and use. So I’m probably an edge case, but my thought would be if Project Panel / FAW are not visible / used, maybe the “project root directory” is just that of the current file in Notepad++?

Cheers.

PeterJones

@ekopalypse ,

through Projects (multiple root directories) and FAW (one root directory).
…
nppm_getfawroot which returns a directory and nppm_getprojectroots which returns an array of directories.

Both should return an array, because as I recently discovered, FaW is additive: if you File>OpenFaW when you already have one open, it will put a second top-level folder in the FaW window – so it’s not limited to one root:

What if FAW or Projects are not visible, what should be returned by the nppm_* requests?

I would say: if current file resides in invisible FAW/Projects hierarchy, then return the same as when visible – just because I temporarily hide the panel (maybe to give me more real estate) doesn’t mean I’m not working in the same project; if current file is not in invisible FAW/Projects hierarchy, then as @Michael-Vincent suggests, just return the current directory.

Derek Brown

I haven’t implemented anything with workspaces in my LSP plugin so far, so I have no particular opinion. Your proposal seems reasonable to me.

However this will be a somewhat tricky message to implement due to memory management in C++. The typical way to return an array from a message is done by using two calls: The first call passes a null pointer and the message returns a size. The caller should then allocate an array of the given size and send the message again with a pointer to the new array.

However here we are returning an array of arrays (strings). There are a few things that could be done here:

The message could return all the null-terminated paths concatenated together, ending with two consecutive null characters. The downside is that the caller must do some work to get pointers to each of the paths separately. The first call would return the size in bytes of this super-string.
The message could require that fixed size buffers are provided by the caller. This is somewhat similar to existing messages, like NPPM_GETFILENAME, which recommends allocating a buffer of MAX_PATH. In this option, the first call would return the number of paths, with the caller would then allocate an array of char[MAX_PATH] buffers.
Instead of returning an array at all, an indexed approach could be used. I used this when I implemented SCI_GETMULTIEDGECOLUMN because Scintilla doesn’t like messages that return arrays. In this method the message takes in index parameter N and returns the N-th value. If N is greater than the size, a sentinel value like 0 or -1 is returned. However for this problem it would still be returning arrays (strings) for each value, so it doesn’t get rid of the memory management issues, it just moves it down to the level of arrays instead of arrays of arrays.

I would lean towards the first approach myself, but I’m not sure what Don would prefer.

Derek Brown

On the topic of additional messages, I filed a bug on Github asking for WM_MOUSEMOVE to be exposed to plugins so that it would be easier to implement custom hover logic, but it’s received no response.

pnedev

@ekopalypse ,

I’ve never used Projects or FaW in my workflow and thus I don’t have any experience with them so I cannot be of help here, sorry.
The suggestions/feedback by others seem reasonable though and having the additional plugins API is a good thing in my opinion for use cases like yours.