GNU bug report logs - #76748
31.0.50; `unload-feature' unbinds NEW-ALIAS and BASE-VARIABLE of variable alias

Previous Next

To reply to this bug, email your comments to 76748 AT debbugs.gnu.org.
There is no need to reopen the bug first.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Jens Schmidt <jschmidt4gnu <at> vodafonemail.de>
To: bug-gnu-emacs <at> gnu.org
Subject: 31.0.50; `unload-feature' unbinds NEW-ALIAS and BASE-VARIABLE of
 variable alias
Date: Tue, 04 Mar 2025 21:57:18 +0100

1. `defalias' on builtin variable, like in vhdl-mode.el:

     ./progmodes/vhdl-mode.el:2331:  (defvaralias 'vhdl-last-input-event 'last-input-event)

   Start with "emacs -Q", then execute with C-j in *scratch*:

     (require 'vhdl-mode)
     vhdl-mode

     (unload-feature 'vhdl-mode)
     =>
     Lisp error: (error "Built-in variables may not be unbound")
       makunbound(vhdl-last-input-event)
       #f(compiled-function (x) #<bytecode -0x15f00789bdf1ec4b>)(vhdl-last-input-event)
       apply(#f(compiled-function (x) #<bytecode -0x15f00789bdf1ec4b>) vhdl-last-input-event nil)
       loadhist-unload-element(vhdl-last-input-event)
       unload-feature(vhdl-mode)

2. `define-obsolete-variable-alias' on non-builtin, like this:

     ./net/shr.el:164:(define-obsolete-variable-alias 'shr-external-browser 'browse-url-secondary-browser-function "27.1")

   Start with "emacs -Q", then execute with C-j in *scratch*:

     (require 'browse-url)
     browse-url

     browse-url-secondary-browser-function
     browse-url-default-browser

     (require 'shr)
     shr

     (unload-feature 'shr)
     nil

     browse-url-secondary-browser-function
     => Lisp error: (void-variable browse-url-secondary-browser-function)

My understanding is that `unload-feature' in

case 1. tries to unbind BASE-VARIABLE of the alias, and not NEW-ALIAS,
and fails to do so and in

case 2. unbinds both CURRENT-NAME and OBSOLETE-NAME.

I would expect that in these cases `unload-feature' should unbind
NEW-ALIAS/OBSOLETE-NAME from the feature being unloaded, but leave
BASE-VARIABLE/CURRENT-NAME unchanged.  (Except of course if both items
of the alias originate from the same feature.)


In GNU Emacs 31.0.50 (build 3, x86_64-pc-linux-gnu, GTK+ Version
 3.24.38, cairo version 1.16.0) of 2025-03-04 built on sappc2
Repository revision: e978737f57ef8447bba5796dd945ac185fcadffa
Repository branch: master
Windowing system distributor 'The X.Org Foundation', version 11.0.12201009
System Description: Debian GNU/Linux 12 (bookworm)

Configured using:
 'configure --with-native-compilation --with-mailutils'

Configured features:
ACL CAIRO DBUS FREETYPE GIF GLIB GMP GNUTLS GPM GSETTINGS HARFBUZZ JPEG
LCMS2 LIBOTF LIBSELINUX LIBSYSTEMD LIBXML2 M17N_FLT MODULES NATIVE_COMP
NOTIFY INOTIFY PDUMPER PNG RSVG SECCOMP SOUND THREADS TIFF
TOOLKIT_SCROLL_BARS WEBP X11 XDBE XIM XINERAMA XINPUT2 XPM XRANDR GTK3
ZLIB

Important settings:
  value of $LC_COLLATE: POSIX
  value of $LC_TIME: POSIX
  value of $LANG: en_US.UTF-8
  value of $XMODIFIERS: @im=ibus
  locale-coding-system: utf-8-unix

Major mode: Lisp Interaction

Minor modes in effect:
  tooltip-mode: t
  global-eldoc-mode: t
  eldoc-mode: t
  show-paren-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  minibuffer-regexp-mode: t
  line-number-mode: t
  indent-tabs-mode: t
  transient-mark-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t

Load-path shadows:
None found.

Features:
(shadow sort mail-extr comp-run bytecomp byte-compile comp-common rx
emacsbug lisp-mnt message mailcap yank-media puny dired dired-loaddefs
rfc822 mml mml-sec password-cache epa derived epg rfc6068 epg-config
gnus-util text-property-search time-date subr-x mm-decode mm-bodies
mm-encode mail-parse rfc2231 mailabbrev gmm-utils mailheader cl-loaddefs
cl-lib sendmail rfc2047 rfc2045 ietf-drums mm-util mail-prsvr mail-utils
rmc iso-transl tooltip cconv eldoc paren electric uniquify ediff-hook
vc-hooks lisp-float-type elisp-mode mwheel term/x-win x-win
term/common-win x-dnd touch-screen tool-bar dnd fontset image regexp-opt
fringe tabulated-list replace newcomment text-mode lisp-mode prog-mode
register page tab-bar menu-bar rfn-eshadow isearch easymenu timer select
scroll-bar mouse jit-lock font-lock syntax font-core term/tty-colors
frame minibuffer nadvice seq simple cl-generic indonesian philippine
cham georgian utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao
korean japanese eucjp-ms cp51932 hebrew greek romanian slovak czech
european ethiopic indian cyrillic chinese composite emoji-zwj charscript
charprop case-table epa-hook jka-cmpr-hook help abbrev obarray oclosure
cl-preloaded button loaddefs theme-loaddefs faces cus-face macroexp
files window text-properties overlay sha1 md5 base64 format env
code-pages mule custom widget keymap hashtable-print-readable backquote
threads dbusbind inotify lcms2 dynamic-setting system-font-setting
font-render-setting cairo gtk x-toolkit xinput2 x multi-tty move-toolbar
make-network-process tty-child-frames native-compile emacs)

Memory information:
((conses 16 58395 9074) (symbols 48 6196 0) (strings 32 15316 2044)
 (string-bytes 1 469694) (vectors 16 9916)
 (vector-slots 8 139508 9528) (floats 8 23 12) (intervals 56 263 0)
 (buffers 984 11))

Message #8 received at 76748 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Jens Schmidt <jschmidt4gnu <at> vodafonemail.de>,
 Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 76748 <at> debbugs.gnu.org
Subject: Re: bug#76748: 31.0.50;
 `unload-feature' unbinds NEW-ALIAS and BASE-VARIABLE of variable alias
Date: Wed, 05 Mar 2025 14:33:49 +0200

> Date: Tue, 04 Mar 2025 21:57:18 +0100
> From:  Jens Schmidt via "Bug reports for GNU Emacs,
>  the Swiss army knife of text editors" <bug-gnu-emacs <at> gnu.org>
> 
> 1. `defalias' on builtin variable, like in vhdl-mode.el:
> 
>      ./progmodes/vhdl-mode.el:2331:  (defvaralias 'vhdl-last-input-event 'last-input-event)
> 
>    Start with "emacs -Q", then execute with C-j in *scratch*:
> 
>      (require 'vhdl-mode)
>      vhdl-mode
> 
>      (unload-feature 'vhdl-mode)
>      =>
>      Lisp error: (error "Built-in variables may not be unbound")
>        makunbound(vhdl-last-input-event)
>        #f(compiled-function (x) #<bytecode -0x15f00789bdf1ec4b>)(vhdl-last-input-event)
>        apply(#f(compiled-function (x) #<bytecode -0x15f00789bdf1ec4b>) vhdl-last-input-event nil)
>        loadhist-unload-element(vhdl-last-input-event)
>        unload-feature(vhdl-mode)
> 
> 2. `define-obsolete-variable-alias' on non-builtin, like this:
> 
>      ./net/shr.el:164:(define-obsolete-variable-alias 'shr-external-browser 'browse-url-secondary-browser-function "27.1")
> 
>    Start with "emacs -Q", then execute with C-j in *scratch*:
> 
>      (require 'browse-url)
>      browse-url
> 
>      browse-url-secondary-browser-function
>      browse-url-default-browser
> 
>      (require 'shr)
>      shr
> 
>      (unload-feature 'shr)
>      nil
> 
>      browse-url-secondary-browser-function
>      => Lisp error: (void-variable browse-url-secondary-browser-function)
> 
> My understanding is that `unload-feature' in
> 
> case 1. tries to unbind BASE-VARIABLE of the alias, and not NEW-ALIAS,
> and fails to do so and in
> 
> case 2. unbinds both CURRENT-NAME and OBSOLETE-NAME.
> 
> I would expect that in these cases `unload-feature' should unbind
> NEW-ALIAS/OBSOLETE-NAME from the feature being unloaded, but leave
> BASE-VARIABLE/CURRENT-NAME unchanged.  (Except of course if both items
> of the alias originate from the same feature.)

Stefan, any suggestions?

Message #11 received at 76748 <at> debbugs.gnu.org (full text, mbox):

From: Jens Schmidt <jschmidt4gnu <at> vodafonemail.de>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 76748 <at> debbugs.gnu.org
Subject: Re: bug#76748: 31.0.50; `unload-feature' unbinds NEW-ALIAS and
 BASE-VARIABLE of variable alias
Date: Wed, 12 Mar 2025 21:36:40 +0100

On 2025-03-05  13:33, Eli Zaretskii wrote:
>> Date: Tue, 04 Mar 2025 21:57:18 +0100
>> From:  Jens Schmidt via "Bug reports for GNU Emacs,
>>  the Swiss army knife of text editors" <bug-gnu-emacs <at> gnu.org>
>>
>> 1. `defalias' on builtin variable, like in vhdl-mode.el:
>>
>>      ./progmodes/vhdl-mode.el:2331:  (defvaralias 'vhdl-last-input-event 'last-input-event)
>>
>>    Start with "emacs -Q", then execute with C-j in *scratch*:
>>
>>      (require 'vhdl-mode)
>>      vhdl-mode
>>
>>      (unload-feature 'vhdl-mode)
>>      =>
>>      Lisp error: (error "Built-in variables may not be unbound")
>>        makunbound(vhdl-last-input-event)
>>        #f(compiled-function (x) #<bytecode -0x15f00789bdf1ec4b>)(vhdl-last-input-event)
>>        apply(#f(compiled-function (x) #<bytecode -0x15f00789bdf1ec4b>) vhdl-last-input-event nil)
>>        loadhist-unload-element(vhdl-last-input-event)
>>        unload-feature(vhdl-mode)
>>
>> 2. `define-obsolete-variable-alias' on non-builtin, like this:
>>
>>      ./net/shr.el:164:(define-obsolete-variable-alias 'shr-external-browser 'browse-url-secondary-browser-function "27.1")
>>
>>    Start with "emacs -Q", then execute with C-j in *scratch*:
>>
>>      (require 'browse-url)
>>      browse-url
>>
>>      browse-url-secondary-browser-function
>>      browse-url-default-browser
>>
>>      (require 'shr)
>>      shr
>>
>>      (unload-feature 'shr)
>>      nil
>>
>>      browse-url-secondary-browser-function
>>      => Lisp error: (void-variable browse-url-secondary-browser-function)
>>
>> My understanding is that `unload-feature' in
>>
>> case 1. tries to unbind BASE-VARIABLE of the alias, and not NEW-ALIAS,
>> and fails to do so and in
>>
>> case 2. unbinds both CURRENT-NAME and OBSOLETE-NAME.
>>
>> I would expect that in these cases `unload-feature' should unbind
>> NEW-ALIAS/OBSOLETE-NAME from the feature being unloaded, but leave
>> BASE-VARIABLE/CURRENT-NAME unchanged.  (Except of course if both items
>> of the alias originate from the same feature.)
> 
> Stefan, any suggestions?

Gentle ping to Stefan ...

... thanks!

Message #14 received at 76748 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Jens Schmidt <jschmidt4gnu <at> vodafonemail.de>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 76748 <at> debbugs.gnu.org
Subject: Re: bug#76748: 31.0.50; `unload-feature' unbinds NEW-ALIAS and
 BASE-VARIABLE of variable alias
Date: Wed, 12 Mar 2025 17:01:28 -0400

>> Stefan, any suggestions?
> Gentle ping to Stefan ...

Not sure what is expected from me, here.
This looks like a plain bug to me, with a good recipe to reproduce and
diagnose it.


        Stefan

Message #17 received at 76748 <at> debbugs.gnu.org (full text, mbox):

From: Jens Schmidt <jschmidt4gnu <at> vodafonemail.de>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 76748 <at> debbugs.gnu.org
Subject: Re: bug#76748: 31.0.50; `unload-feature' unbinds NEW-ALIAS and
 BASE-VARIABLE of variable alias
Date: Wed, 12 Mar 2025 23:18:11 +0100

On 2025-03-12  22:01, Stefan Monnier wrote:

> Not sure what is expected from me, here.
> This looks like a plain bug to me, with a good recipe to reproduce and
> diagnose it.

Is there a way to undo a `defvaralias' from Lisp?

Meaning a hypothetical function `unalias' so that after

  (defvar foo nil "Foo")
  (defvaralias 'bar 'foo "Bar")

  (unalias 'bar)

`foo' is untouched, but everything about `bar' forgotten.

I haven't found one, but then I haven't been searching very
thoroughly.

Message #20 received at 76748 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Jens Schmidt <jschmidt4gnu <at> vodafonemail.de>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 76748 <at> debbugs.gnu.org
Subject: Re: bug#76748: 31.0.50; `unload-feature' unbinds NEW-ALIAS and
 BASE-VARIABLE of variable alias
Date: Wed, 12 Mar 2025 18:20:39 -0400

> Is there a way to undo a `defvaralias' from Lisp?

I think there is currently no such thing, no.


        Stefan

Message #23 received at 76748 <at> debbugs.gnu.org (full text, mbox):

From: Jens Schmidt <jschmidt4gnu <at> vodafonemail.de>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 76748 <at> debbugs.gnu.org
Subject: Re: bug#76748: 31.0.50; `unload-feature' unbinds NEW-ALIAS and
 BASE-VARIABLE of variable alias
Date: Wed, 12 Mar 2025 23:41:55 +0100

On 2025-03-12  23:20, Stefan Monnier wrote:

> I think there is currently no such thing, no.

Thanks.  So the way to go here would be to implement a function
like that, presumably in eval.c (plus update of Elisp manual,
NEWS, tests, etc.), and then use that function to fix function
`unload-feature', correct?

I can give it a try, but please expect me asking more questions
when it comes to Emacs C code ...

Thanks again!

Message #26 received at 76748 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Jens Schmidt <jschmidt4gnu <at> vodafonemail.de>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 76748 <at> debbugs.gnu.org
Subject: Re: bug#76748: 31.0.50; `unload-feature' unbinds NEW-ALIAS and
 BASE-VARIABLE of variable alias
Date: Wed, 12 Mar 2025 18:53:47 -0400

>> I think there is currently no such thing, no.
> Thanks.  So the way to go here would be to implement a function
> like that, presumably in eval.c (plus update of Elisp manual,
> NEWS, tests, etc.), and then use that function to fix function
> `unload-feature', correct?

Sounds right.  You could also choose to keep that function "internal"
and not document it in the manual/NEWS (like we did for
`internal-make-var-non-special`), mostly justified in case its semantics
is delicate/messy/ugly.

> I can give it a try, but please expect me asking more questions
> when it comes to Emacs C code ...

Sounds great!


        Stefan

Message #29 received at 76748 <at> debbugs.gnu.org (full text, mbox):

From: Jens Schmidt <jschmidt4gnu <at> vodafonemail.de>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 76748 <at> debbugs.gnu.org
Subject: Re: bug#76748: 31.0.50; `unload-feature' unbinds NEW-ALIAS and
 BASE-VARIABLE of variable alias
Date: Fri, 14 Mar 2025 23:14:05 +0100

[Message part 1 (text/plain, inline)]

On 2025-03-12  23:53, Stefan Monnier wrote:

> You could also choose to keep that function "internal"
> and not document it in the manual/NEWS (like we did for
> `internal-make-var-non-special`), mostly justified in case its
> semantics is delicate/messy/ugly.

I decided to do exactly that - if anybody else except `unload-feature'
is ever going to need that function, she/he can do the documentation.
Will add some tests, anyway, when the rest of this has been decided
upon.

Adding the function `internal-delete-indirect-variable' and calling it
from loadhist.el was easy enough (too easy?), please see the attached
patch for a first draft.  I decided that the right way to unbind an
alias, as far as `unload-feature' is concerned, is to make it a regular
variable and unbind that.

More questions:

1. I have a bad feeling about butting in between 1st class citizens
   makunbound and fmakunbound in data.c, but couldn't find a better
   other place for that function.

2. Before or after switching the variable from an alias to a plain one
   in `internal-delete-indirect-variable', do I somehow need to clean or
   zero ...val->alias before overwriting it as ...val->value with
   "Fset (symbol, Qunbound);"?

3. defvaralias attaches the new alias to the load history as symbol.
   One could also attach it as (Fcons (Qalias, new_alias)) and provide a
   new cl method loadhist-unload-element for that case instead of handling
   aliases together with regular symbols.

Finally, `defvaralias' and `define-obsolete-variable-alias' have a
number of other side-effects, which I have not covered in function
`internal-delete-indirect-variable'.  Please let me know if I should
care about any of these:

4. defvaralias potentially calls

     notify_variable_watchers (new_alias, base_variable, Qdefvaralias, Qnil);

5. defvaralias declares both new alias and base symbol as special.

6. defvaralias sets

     XSYMBOL (new_alias)->u.s.trapped_write =
       XSYMBOL (base_variable)->u.s.trapped_write;

7. defvaralias puts the alias docstring into the variable-documentation
   property.

8. define-obsolete-variable-alias copies properties `saved-value',
   `saved-variable-comment'  from the obsolete to the non-obsolete
   symbol.

9. define-obsolete-variable-alias sets property `byte-obsolete-variable'
   on the obsolete symbol.

Thanks.

[0001-Correctly-unload-variable-aliases.patch (text/x-patch, attachment)]

Message #32 received at 76748 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Jens Schmidt <jschmidt4gnu <at> vodafonemail.de>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 76748 <at> debbugs.gnu.org
Subject: Re: bug#76748: 31.0.50; `unload-feature' unbinds NEW-ALIAS and
 BASE-VARIABLE of variable alias
Date: Fri, 14 Mar 2025 19:13:37 -0400

>> You could also choose to keep that function "internal"
>> and not document it in the manual/NEWS (like we did for
>> `internal-make-var-non-special`), mostly justified in case its
>> semantics is delicate/messy/ugly.
>
> I decided to do exactly that - if anybody else except `unload-feature'
> is ever going to need that function, she/he can do the documentation.
> Will add some tests, anyway, when the rest of this has been decided
> upon.

At first, I thought it would be better to make it official, but seeing
the number of details you encountered in the semantics, I think you made
the right call: it's fairly delicate/messy/ugly.

> More questions:
>
> 1. I have a bad feeling about butting in between 1st class citizens
>    makunbound and fmakunbound in data.c, but couldn't find a better
>    other place for that function.

I think I'd put it just after `Fdefvaralias`.

> 2. Before or after switching the variable from an alias to a plain one
>    in `internal-delete-indirect-variable', do I somehow need to clean or
>    zero ...val->alias before overwriting it as ...val->value with
>    "Fset (symbol, Qunbound);"?

No, I think the way you do it is fine.

> 3. defvaralias attaches the new alias to the load history as symbol.
>    One could also attach it as (Fcons (Qalias, new_alias)) and provide a
>    new cl method loadhist-unload-element for that case instead of handling
>    aliases together with regular symbols.

Indeed, we could, but I don't see a strong need for that.

> Finally, `defvaralias' and `define-obsolete-variable-alias' have a
> number of other side-effects, which I have not covered in function
> `internal-delete-indirect-variable'.  Please let me know if I should
> care about any of these:
>
> 4. defvaralias potentially calls
>
>      notify_variable_watchers (new_alias, base_variable, Qdefvaralias, Qnil);

I guess we could add a corresponding "unalias" event, indeed.  Not sure
it's worth the trouble, tho, since your code will already call the
watcher because of the `Fset`: for debug purposes (which is what watchers
are designed for) that should be sufficient.

> 5. defvaralias declares both new alias and base symbol as special.

No need to undo that.

> 6. defvaralias sets
>
>      XSYMBOL (new_alias)->u.s.trapped_write =
>        XSYMBOL (base_variable)->u.s.trapped_write;

We already have a mess here, AFAICT, because `add-variable-watcher`
doesn't keep those two in-sync, so I wouldn't worry.

> 7. defvaralias puts the alias docstring into the variable-documentation
>    property.

I think this does need to be undone.

> 8. define-obsolete-variable-alias copies properties `saved-value',
>    `saved-variable-comment'  from the obsolete to the non-obsolete
>    symbol.

This doesn't need to be undone, I think.

> 9. define-obsolete-variable-alias sets property `byte-obsolete-variable'
>    on the obsolete symbol.

Hmm... I guess in practice it'd be marginally more often useful if we
undo this, but that's just a wild guess.

I think you forgot:

   10. We don't know if the variable was `boundp` before it was turned
       into an alias, so maybe setting it to `Qunbound` is not the right
       way to "undo the defvaralias".

But yeah, I wouldn't worry about it either.

> +DEFUN ("internal-delete-indirect-variable", Finternal_delete_indirect_variable, Sinternal_delete_indirect_variable,
> +       1, 1, 0,
> +       doc: /* Undeclare SYMBOL as variable alias, then unbind it.
> +If SYMBOL is not a variable alias, unbind it like `makunbound' does.
> +Return SYMBOL.  */)
> +  (register Lisp_Object symbol)
> +{
> +  CHECK_SYMBOL (symbol);
> +  if (SYMBOL_CONSTANT_P (symbol))
> +    xsignal1 (Qsetting_constant, symbol);
> +  else if (XSYMBOL (symbol)->u.s.redirect == SYMBOL_VARALIAS)
> +    XSYMBOL (symbol)->u.s.redirect = SYMBOL_PLAINVAL;
> +  Fset (symbol, Qunbound);
> +  return symbol;
> +}

I think I'd signal an error if SYMBOL is not a variable alias (and then
you can get rid of the `SYMBOL_CONSTANT_P` test).



        Stefan

Message #35 received at 76748 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Jens Schmidt <jschmidt4gnu <at> vodafonemail.de>
Cc: monnier <at> iro.umontreal.ca, 76748 <at> debbugs.gnu.org
Subject: Re: bug#76748: 31.0.50; `unload-feature' unbinds NEW-ALIAS and
 BASE-VARIABLE of variable alias
Date: Sat, 15 Mar 2025 11:04:37 +0200

> Date: Fri, 14 Mar 2025 23:14:05 +0100
> Cc: 76748 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>
> From: Jens Schmidt <jschmidt4gnu <at> vodafonemail.de>
> 
> +DEFUN ("internal-delete-indirect-variable", Finternal_delete_indirect_variable, Sinternal_delete_indirect_variable,
> +       1, 1, 0,
> +       doc: /* Undeclare SYMBOL as variable alias, then unbind it.
> +If SYMBOL is not a variable alias, unbind it like `makunbound' does.
> +Return SYMBOL.  */)

Please say "Internal use only" in the doc string.

Thanks.

Message #38 received at 76748 <at> debbugs.gnu.org (full text, mbox):

From: Jens Schmidt <jschmidt4gnu <at> vodafonemail.de>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 76748 <at> debbugs.gnu.org
Subject: Re: bug#76748: 31.0.50; `unload-feature' unbinds NEW-ALIAS and
 BASE-VARIABLE of variable alias
Date: Sat, 15 Mar 2025 17:57:25 +0100

Thanks for your review.  I'll implement your recommendations (and
Eli's), but here is one more general question, which came to me
only now:  What's the general purpose of `unload-history'?

If I understand the Elisp manual ((elisp) Unloading) correctly, the
main intention of unloading a library is to reclaim memory:

  You can discard the functions and variables loaded by a library
  to reclaim memory for other Lisp objects.

Plus `unload-history' currently does not really try to be overly
thorough in its cleanup: Docstrings of variables survive the
cleanup, for example, and so do faces.

So another, less invasive option to fix this bug might be to just
skip variable aliases in `unload-history' and not call `makunbound'
on them.

WDYT?

Message #41 received at 76748 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Jens Schmidt <jschmidt4gnu <at> vodafonemail.de>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 76748 <at> debbugs.gnu.org
Subject: Re: bug#76748: 31.0.50; `unload-feature' unbinds NEW-ALIAS and
 BASE-VARIABLE of variable alias
Date: Sat, 15 Mar 2025 15:13:37 -0400

> Thanks for your review.  I'll implement your recommendations (and
> Eli's), but here is one more general question, which came to me
> only now:  What's the general purpose of `unload-history'?

Good question.  I don't know.  I never use it.
The times I've heard people mention it, they tended to use it so as to
be able to unload an old version of a package and then load a newer
version in its place without having to restart Emacs.
And I got to hear about it because, well, that doesn't work
reliably.

> So another, less invasive option to fix this bug might be to just
> skip variable aliases in `unload-history' and not call `makunbound'
> on them.

That would be the poor man's choice, but given you already wrote the
code to do it better, I wouldn't make that choice.


        Stefan

Message #44 received at 76748 <at> debbugs.gnu.org (full text, mbox):

From: Jens Schmidt <jschmidt4gnu <at> vodafonemail.de>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 76748 <at> debbugs.gnu.org
Subject: Re: bug#76748: 31.0.50; `unload-feature' unbinds NEW-ALIAS and
 BASE-VARIABLE of variable alias
Date: Sat, 15 Mar 2025 22:50:34 +0100

[Message part 1 (text/plain, inline)]

On 2025-03-15  20:13, Stefan Monnier wrote:

> That would be the poor man's choice, but given you already wrote the
> code to do it better, I wouldn't make that choice.

Ok, kept the other choice, implemented your and Eli's feedback,
added tests, both for the new function and for unloading a feature
that defines a variable alias.

Please see the attached patch.

Thanks

[0001-Correctly-unload-variable-aliases.patch (text/x-patch, attachment)]

Message #49 received at 76748-done <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Jens Schmidt <jschmidt4gnu <at> vodafonemail.de>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 76748-done <at> debbugs.gnu.org
Subject: Re: bug#76748: 31.0.50; `unload-feature' unbinds NEW-ALIAS and
 BASE-VARIABLE of variable alias
Date: Sun, 16 Mar 2025 00:12:09 -0400

> Please see the attached patch.

Thanks, pushed to `master` closing,


        Stefan

Message #52 received at 76748 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: jschmidt4gnu <at> vodafonemail.de, 76748 <at> debbugs.gnu.org
Subject: Re: bug#76748: 31.0.50; `unload-feature' unbinds NEW-ALIAS and
 BASE-VARIABLE of variable alias
Date: Sun, 16 Mar 2025 09:04:34 +0200

> From: Stefan Monnier <monnier <at> iro.umontreal.ca>
> Cc: Eli Zaretskii <eliz <at> gnu.org>,  76748-done <at> debbugs.gnu.org
> Date: Sun, 16 Mar 2025 00:12:09 -0400
> 
> > Please see the attached patch.
> 
> Thanks, pushed to `master` closing,

I think you forgot to push.

Message #55 received at 76748 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: jschmidt4gnu <at> vodafonemail.de, 76748 <at> debbugs.gnu.org
Subject: Re: bug#76748: 31.0.50; `unload-feature' unbinds NEW-ALIAS and
 BASE-VARIABLE of variable alias
Date: Sun, 16 Mar 2025 12:53:01 -0400

> I think you forgot to push.

I like the way you think,


        Stefan

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.