GNU bug report logs - #54071
fix incompatible arity change help-fns

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 54071 in the body.
You can then email your comments to 54071 AT debbugs.gnu.org in the normal way.

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

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

From: Ben Schw <benjamin.schwerdtner <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: fix incompatible arity change help-fns
Date: Sun, 20 Feb 2022 16:58:28 +0100

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

Tags: patch


See commit message


In GNU Emacs 29.0.50 (build 3, x86_64-pc-linux-gnu, GTK+ Version 3.24.31,
cairo version 1.17.4)
 of 2022-02-19 built on benj-pc
Repository revision: e015dc77f5e38d52bb0b328c764c8186c8c9bf73
Repository branch: master
Windowing system distributor 'The X.Org Foundation', version 11.0.12101003
System Description: Manjaro Linux

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

[Message part 2 (text/html, inline)]

[0001-help-fns.el-help-fns-autoloaded-p-do-not-brake-calle.patch (text/x-patch, attachment)]

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Ben Schw <benjamin.schwerdtner <at> gmail.com>
Cc: 54071 <at> debbugs.gnu.org
Subject: Re: bug#54071: fix incompatible arity change help-fns
Date: Sun, 20 Feb 2022 18:26:55 +0200

> From: Ben Schw <benjamin.schwerdtner <at> gmail.com>
> Date: Sun, 20 Feb 2022 16:58:28 +0100
> 
> A recent change changed the arity of this function, braking
> callers that pass 2 arguments.
> 
> This function was called from the excellent package helpful.el
> which throws a lisp error now

How come an internal function is called outside Emacs?

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

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: Ben Schw <benjamin.schwerdtner <at> gmail.com>, 54071 <at> debbugs.gnu.org
Subject: Re: bug#54071: fix incompatible arity change help-fns
Date: Sun, 20 Feb 2022 19:29:05 +0100

Eli Zaretskii <eliz <at> gnu.org> writes:

>> A recent change changed the arity of this function, braking
>> callers that pass 2 arguments.
>> 
>> This function was called from the excellent package helpful.el
>> which throws a lisp error now
>
> How come an internal function is called outside Emacs?

Yes, I think this is a bug that should be reported to the helpful.el
maintainer(s).  Internal Emacs functions will change signatures (or
cease to exist) without warning, so they shouldn't be used by external
packages.

So I don't think there's anything to be done here in Emacs, and I'm
therefore closing this bug report.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

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

From: Drew Adams <drew.adams <at> oracle.com>
To: Eli Zaretskii <eliz <at> gnu.org>, Ben Schw <benjamin.schwerdtner <at> gmail.com>
Cc: "54071 <at> debbugs.gnu.org" <54071 <at> debbugs.gnu.org>
Subject: RE: [External] : bug#54071: fix incompatible arity change help-fns
Date: Sun, 20 Feb 2022 22:26:41 +0000

> How come an internal function is called outside Emacs?

Perhaps because it's useful?  Why does it need
to be considered only for "inside" Emacs?

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

From: Po Lu <luangruo <at> yahoo.com>
To: Drew Adams <drew.adams <at> oracle.com>
Cc: Ben Schw <benjamin.schwerdtner <at> gmail.com>, Eli Zaretskii <eliz <at> gnu.org>,
 "54071 <at> debbugs.gnu.org" <54071 <at> debbugs.gnu.org>
Subject: Re: bug#54071: fix incompatible arity change help-fns
Date: Mon, 21 Feb 2022 17:59:10 +0800

Drew Adams <drew.adams <at> oracle.com> writes:

> Perhaps because it's useful?  Why does it need
> to be considered only for "inside" Emacs?

I'm usually not the first person to be enthusiastic about breaking
changes, but not changing internal functions because they are useful
leads to madness.

If it is indeed useful, then a public interface should be created
instead.

Previous Next

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