bug-gnu-emacs
[Top][All Lists]
Advanced

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

bug#56407: 29.0.50; desktop.el shouldn't be saving/restoring eglot--mana


From: João Távora
Subject: bug#56407: 29.0.50; desktop.el shouldn't be saving/restoring eglot--managed-mode, which is not for interactive use
Date: Wed, 6 Jul 2022 14:19:43 +0100

On Wed, Jul 6, 2022 at 2:12 PM Eli Zaretskii <eliz@gnu.org> wrote:
> From: João Távora <joaotavora@gmail.com>
> Date: Wed, 6 Jul 2022 13:59:51 +0100
> Cc: 56407@debbugs.gnu.org
>
>  That's okay: it's desktop.el's job to know about some implementation
>  details.  Just look at how much it knows about what the various modes
>  and variables do in Emacs.
>
> Wait, you're saying it's "okay" to have to do a commit to Emacs's repo
> everytime someone makes a third-party package that has a minor mode
> that needs special handling?  Or everytime someone changes the name
> or shape of a minor mode?

eglot is not a third-party package.  We intended to add it to core, I
think?

Indeed we do.  But it's not yet, because I've been so very busy.

 But if what I suggest isn't to your liking, you can always tell users
to customize desktop-minor-mode-table by themselves.  Or do what you
didn't want to do: cause desktop.el to be autoloaded by eglot.

Yes, those are alternatives. But not as good.
 
> But we do have that mechanism. It's called symbol properties and it's a nice
> feature of lisp. So let's use it, please.

If you insist.  But then don't come back crying when this is broken by
some change in desktop.el that the "loosely coupled packages" didn't
pick up.

Thanks. I can't vouch for my future emotions, but I also can't see how
this mechanism, which I've used and seen used so often, could fail
in such ways.

I'll prepare a patch.
 
João

reply via email to

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