From: Theodor Thornhill <theo@thornhill.no>
To: "João Távora" <joaotavora@gmail.com>, emacs-devel@gnu.org
Subject: Re: master 08c80c45dde: Don't use file-truepath in Eglot (bug#70036)
Date: Wed, 17 Apr 2024 20:41:41 +0200 [thread overview]
Message-ID: <87il0fsufu.fsf@thornhill.no> (raw)
In-Reply-To: <CALDnm52Ti1ijBJWAJ_b68mCqp+MTxvnE-zXdFYkKY-_s-HvFkw@mail.gmail.com>
> 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
next prev parent reply other threads:[~2024-04-17 18:41 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <171215083924.12380.5369373861551158668@vcs2.savannah.gnu.org>
[not found] ` <20240403132719.A18EFC12C28@vcs2.savannah.gnu.org>
2024-04-17 15:35 ` master 08c80c45dde: Don't use file-truepath in Eglot (bug#70036) João Távora
2024-04-17 18:41 ` Theodor Thornhill [this message]
2024-04-18 0:24 ` João Távora
2024-04-18 5:49 ` Eli Zaretskii
2024-04-18 6:16 ` Theodor Thornhill
2024-04-18 8:34 ` João Távora
2024-04-18 9:57 ` Theodor Thornhill
2024-04-18 15:00 ` João Távora
2024-04-18 15:44 ` Eli Zaretskii
2024-04-18 16:22 ` João Távora
2024-04-18 16:30 ` Theodor Thornhill
2024-04-18 17:12 ` João Távora
2024-04-18 16:35 ` Eli Zaretskii
2024-04-18 6:02 ` Theodor Thornhill
2024-04-18 14:49 ` João Távora
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87il0fsufu.fsf@thornhill.no \
--to=theo@thornhill.no \
--cc=emacs-devel@gnu.org \
--cc=joaotavora@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.