Re: master 08c80c45dde: Don't use file-truepath in Eglot (bug#70036)

[Theodor Thornhill]

> Hey Theo,
>

Hey!

> I don't disagree strongly with these changes (*), but was surprised
> to find them pushed without asking me specifically about this patch.
> It's true you CCed me about the need for file-truename and I didn't
> reply.  But still, another email with the patch about to be pushed
> would have been nice.

Sure thing - I'll consider this next time. I did mention it in the bug
report, but could have been more clear, absolutely.

>
> I have been looking for an Eglot maintainer but everyone I contacted
> said no, so I assume I'm still the maintainer.  This is in contrast
> to Flymake and Jsonrpc where I've found two people willing to take it
> up.
>
> I still get some email and GitHub traffic about Eglot.  I'd very much
> like to hand it over to you guys formally, I think you, Felicián,
> Stefan, and others will do a fine job, collectively.  Even if I would
> prefer to hand it over to someone with some kind of vision for it
> (but hey beggars can't be choosers).
>
> I'd also like to be a "whole-package situation", where you guys also
> watch over the downstream GitHub repo (or convert it or phase it out
> or whatever) so I can unsubscribe in peace.

If you want I can do this - so that you don't have to. I've been
considering it for some time after I responded to your call for
maintainers.

>
> Just now I got this report in the GitHub tracker about Eglot
> spamming *Messages* https://github.com/joaotavora/eglot/discussions/1389
> and was caught a bit off-guard, as I had nothing to do with it.
>

;-)

> So I propose that as long as you and others (legitimately, of course)
> decline the "whole package" offer, you keep giving me just a tiny bit of heads
> up about what's being proposed to the code (beside the trivial "add
> support for XYZ server" of course).  Or if you prefer just _inform_ me
> that this or that change was pushed recently, so I can comment back
> while the matter is still fresh.
>
> Felicián did this just today with a patch proposal.
>

Sure

> Thanks.  And thanks for your work on Eglot, of course.
> João
>
>
> (*) As to the actual change...
>
> On Wed, Apr 3, 2024 at 2:27 PM Theodor Thornhill via Mailing list for
> Emacs changes <emacs-diffs@gnu.org> wrote:
>
>>     the implementation to a hash map will yield similar performance
>>     benefits, but wouldn't require us to rewrite `file-truename' in C.
>
>
> The change seems well structured, well coded, and well described in the
> commit message, so I could understand it easily.  Do keep that up.
>
> But of course going from file-buffer-visiting to something else
> whose underlying implementation is faster but doesn't chase
> symlinks is probably going to have some kind of functional implication
> right?  I wonder if (or rather "I hope that") you guys considered it.

I did - and afaict it has no such implications. It

> Also, when using a cache to solve a problem, remember cache invalidation
> is one of the 2 hard ones ;-)  Sure this cache won't ever need
> invalidation?  Even when the user moves file around during an Eglot
> session?

The cache cleans itself up - when a buffer is deleted or the minor mode
shut off. Eglot before this change was basically the same, except it
kept buffers in a list rather than a lookup map. The change is mostly a
complexity improvement, with the added benefit that we don't have to
rely on file-truename.

>
> If you ask me, this 'rewrite `file-truename' in C.' is what should be
> done.   No idea how hard that is, but a hash table just isn't fit to answer 
> the
> same questions as 'find-buffer-visiting'.

That's right, and to some extent I agree. However, find-buffer-visiting
isn't really what's needed in this case, at least from what I can see.
I'm still considering rewriting it in C, but I didn't get to this yet.

Theo