GNU bug report logs - #79469
31.0.50; Ungrammatical sentence from describe-function

Previous Next

Full log

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

From: Stephen Berman <stephen.berman <at> gmx.net>
To: Joost Kremers <joostkremers <at> fastmail.fm>
Cc: "Stephen Berman via Bug reports for GNU Emacs, the Swiss army knife of
 text editors" <bug-gnu-emacs <at> gnu.org>, 79469 <at> debbugs.gnu.org,
 Eli Zaretskii <eliz <at> gnu.org>
Subject: Re: bug#79469: 31.0.50; Ungrammatical sentence from describe-function
Date: Fri, 19 Sep 2025 01:01:29 +0200

On Fri, 19 Sep 2025 00:46:53 +0200 Joost Kremers <joostkremers <at> fastmail.fm> wrote:

> On Thu, Sep 18 2025, Stephen Berman via "Bug reports for GNU Emacs, the Swiss
> army knife of text editors" wrote:
>> On Thu, 18 Sep 2025 19:55:24 +0300 Eli Zaretskii <eliz <at> gnu.org> wrote:
>>
>>>> Date: Thu, 18 Sep 2025 18:41:16 +0200
>>>> From:  Stephen Berman via "Bug reports for GNU Emacs,
>>>>  the Swiss army knife of text editors" <bug-gnu-emacs <at> gnu.org>
>>>> 
>>>> Calling `describe-function' on a noninteractive non-byte-compiled
>>>> function produces an ungrammatical sentence in the *Help* buffer:
>>>> 
>>>> 0. emacs -Q
>>>> 1. Load a non-byte-compiled file that contains a noninteractive function
>>>>    definition, e.g. edt-user.el from the Emacs "etc" directory.
>>>> 2. Call `describe-function' on a noninteractive function from that file,
>>>>    e.g. `C-h f edt-setup-user-bindings RET'.
>>>> ==> The *Help* buffer now begins with this sentence:
>>>> 
>>>> edt-setup-user-bindings is a interpreted-function in
>>>> ‘~/src/emacs/emacs-master/etc/edt-user.el’.
>>>> 
>>>> It should say "...is an interpreted-function...".
>>>> 
>>>> Here are three possible fixes:
>>>
>>> Thanks.
>>>
>>> I think this splits hair, but if we want to do that, let's do it
>>> right: instead of hard-coding specific words, implement a function
>>> that produces "a" or "an" depending on the following word.  Because
>>> tomorrow someone will add yet another function qualifier, and what
>>> will we do then? add one more hard-coded phrase?
>>
>> How's this?
>
>> +                    (concat (if (string-match-p "\\`[aeiou]" (symbol-name type))
>
> Potentially problematic, because not every word that starts with "u" gets
> "an". And sometimes words starting with "h" also need "an".

Yes, that's why I wrote in my OP: "While all three are ad hoc fixes, I
think the undoubted complexity of a more general fix is unjustified
here, because (unless I've overlooked something) `interpreted-function'
is the only function type symbol returned by `cl-type-of' in
`help-fns-function-description-header' that results in the problem
(since it begins with a vowel)."

Steve Berman

Previous Next

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