GNU bug report logs - #71117
30.0.50; output of describe-function

Previous Next

Full log

View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: Andrea Corallo <acorallo <at> gnu.org>
Cc: 71117 <at> debbugs.gnu.org, andreas.roehler <at> easy-emacs.de, kevin.legouguec <at> gmail.com
Subject: bug#71117: 30.0.50; output of describe-function
Date: Wed, 29 May 2024 18:54:39 +0300

> From: Andrea Corallo <acorallo <at> gnu.org>
> Cc: kevin.legouguec <at> gmail.com,  71117 <at> debbugs.gnu.org,
>   andreas.roehler <at> easy-emacs.de
> Date: Wed, 29 May 2024 11:17:39 -0400
> 
> Eli Zaretskii <eliz <at> gnu.org> writes:
> 
> >> From: Andrea Corallo <acorallo <at> gnu.org>
> >> Cc: Eli Zaretskii <eliz <at> gnu.org>,  71117 <at> debbugs.gnu.org,
> >>   andreas.roehler <at> easy-emacs.de
> >> Date: Tue, 28 May 2024 18:25:05 -0400
> >> 
> >> Kévin Le Gouguec <kevin.legouguec <at> gmail.com> writes:
> >> 
> >> > Thinking of e.g. 'C-h 4' (for the "other-window" connotation) or 'C-h H'
> >> > (for "current _H_elp buffer"); help-find-source would then be bound to
> >> > 'C-h 4 s', for example.
> >> >
> >> > (info-other-window currently hogs 'C-h 4 i' unfortunately… though
> >> > nowadays 'C-x 4 4 i' also works, and 'C-x 4 i' is currently free 🤔
> >> >
> >> > 'C-x 4 h' is also free to use as a prefix, but maybe a bit of a
> >> > fingerful)
> >> >
> >> > Don't give too much weight to my ramblings; I find 'C-h z' a bit
> >> > cryptic, but I don't know that my alternatives are better.
> >> 
> >> I think those are actually good points, 'C-h z' is not very nice and
> >> 'C-h 4 s' would be probably easier to remember as 's' has the same
> >> meaning in the *Help* buffer it-self.
> >
> > I don't want to rebind "C-h 4 i", but "C-h 4 s" or "C-h 4 RET" should
> > be good.
> >
> > This also needs an update in NEWS and the manual.
> 
> Okay done, please have a look as usual.

LGTM, thanks.

> Also, we have a warning now on master because lisp/ldefs-boot.el needs
> to be regenerated.  I did run admin/update_autogen but the diff is a
> little bigger then I expected (is not only related to the introduced
> function).  Should I commit this? Do we have another way to regenerate
> ldefs-boot.el we typically use?

I never use admin/update_autogen, I just regenerate loaddefs.el (as in
"make -C lisp autoloads-force") and the do what make-tarball.txt says:

  5.  Copy lisp/loaddefs.el to lisp/ldefs-boot.el.  After copying, edit
      ldefs-boot.el to add

      ;; no-byte-compile: t

      to its file-local variables section, otherwise make-dist will
      complain.

And I just did that, so we should be okay for a while.

Previous Next

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