emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: master 1e3b0f2: Improve doc strings of project.el


From: Dmitry Gutov
Subject: Re: master 1e3b0f2: Improve doc strings of project.el
Date: Tue, 7 Jul 2020 18:23:17 +0300
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0

On 07.07.2020 18:04, Eli Zaretskii wrote:

That would still potentially leave hundreds of buffers in which said
commands have never been used.

I don't see how this would happen.  But we can cross that bridge if we
ever get to it.

In the same fashion that the author of bug#41029 arrived at the number of ~6000 buffers (we could ask). Maybe some long search-and-replace? Or something more automated.

I also worry about Tramp buffers, where both process invocations and traversals up the directory tree are unavoidably slower.

- A project configuration can change mid-session (due to a customization
of some user option, or due to an edit in some .dir-locals.el). Or
simply due to 'git init'. As a result, a given file's current project
can change. It will be good to be able to support that without
necessitating Emacs' restart or requiring manual cache invalidation.

I don't see how you can avoid some user command which would mean a
project configuration change.  Alternatively, this could be solved
lazily, when the cached value is found to be outdated.

Speaking of standards set by other editors, have you ever seen an IDE
with an "invalidate project cache" button? I haven't.

I didn't say anything about a need for such a knob.  You are probably
misinterpreting what I wrote above.

All right.

If you have suggestions of how we would reliably find outdated cached values, please don't hesitate to tell.

Examples of caches we could use:

  * file or directory -> project
  * project -> list of files

We don't need to solve every possible complication up front before we
decide that a method is workable, we just need to have a vague idea
how it could be solved when the time comes.

As mentioned, I have that "vague idea" now.

Then why are we still arguing?

I thought we were having a design discussion.

Does commit 4ca13d9 look good to you? It's been in master shortly after my last reply here.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]