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

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

bug#54437: 28.0.92; command-modes returns nil for native compiled functi


From: Andrea Corallo
Subject: bug#54437: 28.0.92; command-modes returns nil for native compiled functions
Date: Mon, 21 Mar 2022 09:56:00 +0000
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux)

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Andrea Corallo <akrl@sdf.org> writes:
>
>> Yes, we'd still need to store the information in each .eln and update
>> the value of this new global hash table each time (probably in
>> comp--register-subr).  So some C should be modified anyway even if
>> (maybe?) less, I doubt is doable in the realease branch at this point
>> anyway.
>
> There's also the problem with stale entries -- if you're re-loading an
> .eln with different functions with different command modes, you'd need
> some way to nix out the old ones (for instance, if a command goes from
> having modes to not).  Or you'd have to register all the commands in the
> hash table, which seems awkward.

In comp--register-subr I'd add the entry into the hash table if the
function being loaded is connected to some mode or I'd clean the entry
in case the new function being defined has no mode but an entry is
already present.

But that said I agree with you that given the resulting patch would not
be trivial and we have to touch some C anyway having two codes to solve
the same issue doesn't sound like a good idea.

> I think if we want this in Emacs 28, it's probably safer to just
> cherry-pick the commit to master, as invasive as that is.  On the other
> hand, the command-modes stuff is new functionality in Emacs 28, so just
> documenting that it doesn't work with native-comp (yet) would also be
> fine, and then perhaps do an Emacs 28.2 later with the patch.

Agree

Thanks

  Andrea





reply via email to

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