[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#53632: Function definition history
From: |
Eli Zaretskii |
Subject: |
bug#53632: Function definition history |
Date: |
Sun, 30 Jan 2022 09:43:12 +0200 |
> Date: Sun, 30 Jan 2022 00:07:57 -0500
> From: Stefan Monnier via "Bug reports for GNU Emacs,
> the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>
>
> I suggest to replace that info with something slightly more complete.
> In the patch below I store the history of the function definition of
> a symbol in its `function-history` symbol property. This history is
> stored as a list of the form (... VAL(n+1) FILE(n+1) VALn FILEn ...)
> where VALn is the value set by FILEn. To make this list cheap in the
> default case, the latest value is not stored in the list (since it's in
> the `symbol-function`) and neither is the first file. So if there's
> only been a single definition (the most common case), the list is empty
> and the property is just not present at all. If a function was first
> defined as an autoload and then overriden by the actual function
> definition, then the list will hold (FILE2 AUTOLOAD), i.e. the name of
> the file that provided the actual function definition and the autoload
> that was used before that.
> [ Note: the name of the file that provided the first definition can be
> recovered if really needed by checking all entries in `load-history`.
> In the patch below I have not needed it. ]
>
> This makes it possible to handle correctly things like unloading
> `cl-loaddefs.el` which should remove the autoloads that are still
> autoloads and leave untouched the functions whose autoload have been
> replaced by the actual function definition.
>
> In my tests it increased the size of the .pdmp by about 2KB (on a 32bit
> build).
>
> The patch also gets rid of the `autoload` vs `defun` distinction in
> `load-history` which seems unnecessary (a significant part of the
> motivation for this patch was to get rid of the special handling of
> autoloads in this part of the code). At least I couldn't find any place
> in the code which took advantage of that distinction.
>
> Comments? Objections?
Please make sure to document this in the ELisp manual.