bug#69391: 30.0.50; `enable-command' doesn't permanently enable `help-fns-edit-variable'

bug#69391: 30.0.50; `enable-command' doesn't permanently enable `help-fns-edit-variable'

[Martin Marshall]

Description:

When initially calling `help-fns-edit-variable', the disabled command
pop-up appears.  There's a prompt to enable the command, and pressing
"y" does so for the current session.  Thereafter, a second message
appears in the minibuffer advising to press "y" again to enable the
command in future sessions.  However, this does not have the described
effect.

Pressing "y" adds "(put 'help-fns-edit-variable 'disabled nil)" to the
end of `user-init-file'.  However, after restarting Emacs, attempting to
invoke the command again brings up the same "disabled command" pop-up.

Recreating:

1.  Create directory for testing,
    cd; mkdir emacs-test-disabled-cmds; cd emacs-test-disabled-cmds
2.  "touch init.el"
3.  "emacs --init-directory . &"
4.  "C-x b *scratch* RET"
5.  "(setopt help-enable-variable-value-editing t) C-x C-e"
6.  "C-h v electric-pair-mode RET"
7.  "C-x o" then move cursor to the `nil' value shown
8.  Press "e" to edit the variable value, a disabled-command pop-up
    appears.
9.  Press "y" to "enable the command".
10. Press "y" again to enable it "for future editing sessions also".
11. Press "C-c C-c" to exit the variable-editing buffer.
12. Go back to the *Help* buffer and try to edit the variable again,
    there is no pop-up, because the command has been enabled for this
    session.
13. Press "C-x C-c" to exit Emacs.
14. "cat init.el" confirms that the init file does contain
    "(put 'help-fns-edit-variable 'disabled nil)"
15. But when you repeat steps 3 through 8, you find that the disabled
    command pop-up still appears.

Probable diagnosis:

It looks like most of Emacs's disabled commands are either set disabled
in libraries that load before the init-file, or they are disabled via
autoload cookies, like this one:

    ;;;###autoload (put 'dired-find-alternate-file 'disabled t)

But that's not the case for `help-fns-edit-variable' (and a few others,
which I located using ripgrep).  So when "help-fns.el" loads, it
re-disables the command that was supposed to have been enabled by the
call to `put' that Emacs added to the init file.

List of commands where this seems to be the case:

Command                            Library   Comments*
=======                            =======   ========
help-fns-edit-variable             help-fns
erc-remove-text-properties-region  erc
secrets-mode                       secrets   "doesn't make sense to call it interactively."
Info-edit                          info-edit "Editing Info nodes by hand is not recommended.
                                              This feature will be removed in future."

\* I've only confirmed the problem with respect to
`help-fns-edit-variable'.  Also, regarding `secrets-mode' and
`Info-edit', comments found in their respective packages may indicate
"feature-not-a-bug" for those two.

To enable any of these commands permanently, the user would have to
either load the library earlier in the init file, or surround the `put'
call with a call to `eval-after-load'.

System Information:

In GNU Emacs 30.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version
 3.24.38, cairo version 1.16.0) of 2024-02-25 built on vader
Repository revision: e02c4a864f02787f0e194c9e8a6d4ab0b18ca39f
Repository branch: master
System Description: Debian GNU/Linux 12 (bookworm)

Configured using:
 'configure --with-pgtk --with-native-compilation=aot
 --without-compress-install --with-tree-sitter --with-imagemagick'

Configured features:
CAIRO DBUS FREETYPE GIF GLIB GMP GNUTLS GPM GSETTINGS HARFBUZZ
IMAGEMAGICK JPEG JSON LCMS2 LIBOTF LIBSELINUX LIBSYSTEMD LIBXML2 MODULES
NATIVE_COMP NOTIFY INOTIFY PDUMPER PGTK PNG RSVG SECCOMP SOUND SQLITE3
THREADS TIFF TOOLKIT_SCROLL_BARS TREE_SITTER WEBP XIM GTK3 ZLIB

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

-- 
Best regards,
Martin Marshall

bug#69391: 30.0.50; `enable-command' doesn't permanently enable `help-fns-edit-variable'

[Eli Zaretskii]

> From: Martin Marshall <law@martinmarshall.com>
> Date: Sun, 25 Feb 2024 12:44:01 -0500
> 
> Description:
> 
> When initially calling `help-fns-edit-variable', the disabled command
> pop-up appears.  There's a prompt to enable the command, and pressing
> "y" does so for the current session.  Thereafter, a second message
> appears in the minibuffer advising to press "y" again to enable the
> command in future sessions.  However, this does not have the described
> effect.
> 
> Pressing "y" adds "(put 'help-fns-edit-variable 'disabled nil)" to the
> end of `user-init-file'.  However, after restarting Emacs, attempting to
> invoke the command again brings up the same "disabled command" pop-up.
> 
> Recreating:
> 
> 1.  Create directory for testing,
>     cd; mkdir emacs-test-disabled-cmds; cd emacs-test-disabled-cmds
> 2.  "touch init.el"
> 3.  "emacs --init-directory . &"
> 4.  "C-x b *scratch* RET"
> 5.  "(setopt help-enable-variable-value-editing t) C-x C-e"
> 6.  "C-h v electric-pair-mode RET"
> 7.  "C-x o" then move cursor to the `nil' value shown
> 8.  Press "e" to edit the variable value, a disabled-command pop-up
>     appears.
> 9.  Press "y" to "enable the command".
> 10. Press "y" again to enable it "for future editing sessions also".
> 11. Press "C-c C-c" to exit the variable-editing buffer.
> 12. Go back to the *Help* buffer and try to edit the variable again,
>     there is no pop-up, because the command has been enabled for this
>     session.
> 13. Press "C-x C-c" to exit Emacs.
> 14. "cat init.el" confirms that the init file does contain
>     "(put 'help-fns-edit-variable 'disabled nil)"
> 15. But when you repeat steps 3 through 8, you find that the disabled
>     command pop-up still appears.
> 
> Probable diagnosis:
> 
> It looks like most of Emacs's disabled commands are either set disabled
> in libraries that load before the init-file, or they are disabled via
> autoload cookies, like this one:
> 
>     ;;;###autoload (put 'dired-find-alternate-file 'disabled t)
> 
> But that's not the case for `help-fns-edit-variable' (and a few others,
> which I located using ripgrep).  So when "help-fns.el" loads, it
> re-disables the command that was supposed to have been enabled by the
> call to `put' that Emacs added to the init file.

Thanks for the analysis.

Stefan, is there a better way than convert the form we have in
help-fns.el:

   (put 'help-fns-edit-variable 'disabled t)

into an autoload comment, like we do, e.g., with
dired-find-alternate-file?

bug#69391: 30.0.50; `enable-command' doesn't permanently enable `help-fns-edit-variable'

[Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors]

> Stefan, is there a better way than convert the form we have in
> help-fns.el:
>
>    (put 'help-fns-edit-variable 'disabled t)
>
> into an autoload comment, like we do, e.g., with
> dired-find-alternate-file?

If we want to allow third party packages to use that `disabled`
functionality, maybe we should instead change the code that inserts
the

    (put 'help-fns-edit-variable 'disabled nil)

E.g. we could try to make it insert

    (with-eval-after-load 'help-fns
      (put 'help-fns-edit-variable 'disabled nil))

tho I suspect this will happen too late for autoloaded functions.
Or we could make it do

    (put 'help-fns-edit-variable 'disabled-override t)

and change the code that checks `disabled` accordingly.


        Stefan