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

Previous Next

Package: emacs;

Reported by: Andreas Röhler <andreas.roehler <at> easy-emacs.de>

Date: Wed, 22 May 2024 13:54:01 UTC

Severity: normal

Found in version 30.0.50

Done: Andrea Corallo <acorallo <at> gnu.org>

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

From: help-debbugs <at> gnu.org (GNU bug Tracking System)
To: Andrea Corallo <acorallo <at> gnu.org>
Cc: tracker <at> debbugs.gnu.org
Subject: bug#71117: closed (30.0.50; output of describe-function)
Date: Wed, 29 May 2024 16:05:02 +0000
[Message part 1 (text/plain, inline)]
Your message dated Wed, 29 May 2024 12:04:18 -0400
with message-id <yp15xuwtxj1.fsf <at> fencepost.gnu.org>
and subject line Re: bug#71117: 30.0.50; output of describe-function
has caused the debbugs.gnu.org bug report #71117,
regarding 30.0.50; output of describe-function
to be marked as done.

(If you believe you have received this mail in error, please contact
help-debbugs <at> gnu.org.)


-- 
71117: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=71117
GNU Bug Tracking System
Contact help-debbugs <at> gnu.org with problems
[Message part 2 (message/rfc822, inline)]
From: Andreas Röhler <andreas.roehler <at> easy-emacs.de>
To: bug-gnu-emacs <at> gnu.org
Subject: 30.0.50; output of describe-function
Date: Wed, 22 May 2024 15:53:07 +0200
Hi,

often use ‘C-h f’, i.e. ‘describe-function’, in order to jump onto the 
source code.

Which is done afterwards by a command calling ‘(switch-to-buffer 
(other-buffer))’ followed by TAB, RET.

With recent Emacs, calling for example ‘C-h f list RET’, appears

"list is a ‘primitive-function’ in ‘C source code’".

Now the first active button is ‘primitive-function’, which is rather 
basic and seldom of interest. So I have to tab twice - and by habit 
often get the first, wrong one...

May it be possible to switch the button, like:

"list is defined in ‘C source code’, a ‘primitive-function’".

---

Thanks,
Andreas

GNU Emacs 30.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.33, 
cairo version 1.16.0) of 2024-05-21



[Message part 3 (message/rfc822, inline)]
From: Andrea Corallo <acorallo <at> gnu.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 71117-done <at> debbugs.gnu.org, andreas.roehler <at> easy-emacs.de,
 kevin.legouguec <at> gmail.com
Subject: Re: bug#71117: 30.0.50; output of describe-function
Date: Wed, 29 May 2024 12:04:18 -0400
Eli Zaretskii <eliz <at> gnu.org> writes:

>> 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.

I feel I'm improving! 😀

>> 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.

Noted

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

Thanks.

I'm closing this then, happy to reopen if necessary.

  Andrea


This bug report was last modified 358 days ago.

Previous Next


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