Re: Project local variables.

[Ergus]

Hi:

Thanks for replying

On Sun, Nov 08, 2020 at 03:48:45AM +0200, Dmitry Gutov wrote:
> Hi!
>
> On 03.11.2020 21:41, Ergus wrote:
>
>
> Something like project-set and project-get could be arranged (or 
> perhaps just a project-session hash table). But given that the values 
> won't persist between Emacs sessions, we'd have to consider to use 
> cases first.
Yes, I was not thinking in variables that persist among sessions; but
only in the active session, so initialize them once. Let's say; when a
file is open Emacs now checks if it belongs to a project; such a project
is detected (AFAIK) looking up for a vc directory like .git or something
similar. Is exactly in this case where some environment could be
shared/scoped to the current project. In LSP I see that most of the
checks are made every time a file is opened; when using ctags it asks
every time for the tags file to use instead of reusing "what could be
inferred" from the current project information if there are other files
open. To persist among session in the worst case we can add some
declarations in dir-locals... but I was not thinking on that.

> Two things to consider: the performance of the operation you're trying 
> to "cache", and the performance of 'project-current'.
>
> The latter is not "free". And my near-term plan is to make 
> project-try-vc slower by removing the vc-file-getprop/vc-file-setprop 
> dance because it can lead to outdated information. Or at least try 
> that and see which problems that brings.
>
> In any case, what I'm saying is, 'project-current' on a remote host 
> might not be fast either. Though it could be cached to at least only 
> do the search once per user command.
I don't really know how both performance will compare indeed. In general
I would expect that looking into the local memory hash-table will be
faster that looking in a remote file system among the network for an
executable/file or path. Ex: parallel files-systems, slow networks, or
experimental boards with slow processors, big processes and so on.

I mean; after opening a file, of course a check in the file system will
be needed to know if that file is in a current opened project (I use
project-root). If it is not, then we need to initialize some things like
read the dir-locals, TAGS, look for ctags/gtags/etags executables, tag
files, clang files and so on. Else, we don't need to repeat anything. If
the project has 3000 files, that saves a lot of overhead opening files
and probably in some search engines for completions (I am not really
sure if this is actually possible). In my case; when I open many projects
at the same time I get completions in one from the other... which is
conceptually wrong too.

> Have you tried using (file-remote-p buffer-file-name) as the hash key?
I am using project-root and setting a buffer local variables to use as
the key. I set the variable after opening a file (in a hook); the rest
of my variables are set lazily... if-set->use else set-and-use. And also
added a function hook to check if other files of the same projects
remain open when I kill a buffer; else I delete the info from the hash table".

> If the operation to be sped up is really (executable-find "cat"), the 
> result is really project-independent and should only depend on the 
> host.
 Every file I open in one of the projects may share the project-root at
least. executable-find will be host dependent, but TAGS file, a build
directory, compile_commands.json, root to build or open a shell/vterm,
maybe some modes that I want to enable temporally for this project (ex:
lsp, company, langtool for Latex). 

> If there are other, actually project-dependent examples, the 
> project-local variables (or "session cache", rather) could be 
> implemented as a hash of hashes, keyed by project instance. There 
> implementation seems like it will be rather trivial, but first I would 
> like to know the use cases.
Se above; maybe this is not enough to justify the implementation of a
new level of scopes in emacs; I am just mentioning the use cases I had
in mind and facing very often.