unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
* How should modules define better load-history entries?
@ 2023-06-16 21:41 Aaron Zeng
  0 siblings, 0 replies; only message in thread
From: Aaron Zeng @ 2023-06-16 21:41 UTC (permalink / raw)
  To: emacs-devel; +Cc: Spencer Baugh

Hello,

We recently noticed a regression in the behavior of M-x
describe-function and the like on major modes defined by our
module-based extension[0].  Previously, Emacs did not add any
load-history entries for modules, but this was fixed in #30164.

However, our module installs its own load-history entries in order to
provide more helpful locations.  (It is written in OCaml using the
Ecaml[1] library).  Instead of saying that all the symbols defined by
the module are defined "in" the binary artifact (plugin.so), it adds
entries for the individual source files that are compiled into the
module and the items defined therein.  So, for example, if a major
mode foo-mode is defined in foo.ml, the following entry is added:

(".../foo.ml" (defun . foo-mode) foo-mode-hook ...)

However, after Emacs 27 (which includes the fix for bug #30164), this
no longer works correctly because Emacs itself adds a load-history
entry pointing to plugin.so, shadowing the load-history entries the
plugin itself installed.  There is no way for the plugin itself to
avoid this problem, because it cannot run code *after* it has been
loaded, of course.

We have already implemented a workaround, which is just to remove the
alist entry in load-history corresponding to plugin.so, after loading
plugin.so, and thus unshadowing the entries we want.  However, it is
unfortunate that this means you can no longer simply "require" the
plugin without doing an extra dance to get the enhanced load-history.

Is there a good way to allow modules to set up their own, better
load-history if they want to, and indicate to Emacs that they should
not be shadowed?  I don't know of an obvious mechanism for this off
the top of my head, but it seems like a general problem for modules
(presumably M-x find-function and so on are useless for module
functions unless the modules themselves install better source code
locations).

[0]: This would also affect other functions, not just major modes.  It
just so happens that our extension simulates defun using fset, which
does not modify current-load-list, and so these definitions are not
shadowed.
[1]: https://github.com/janestreet/ecaml



^ permalink raw reply	[flat|nested] only message in thread

only message in thread, other threads:[~2023-06-16 21:41 UTC | newest]

Thread overview: (only message) (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2023-06-16 21:41 How should modules define better load-history entries? Aaron Zeng

Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).