GNU bug report logs - #34776
27.0.50; Some questions about choose-completion-string-functions

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 34776 in the body.
You can then email your comments to 34776 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: Eric Abrahamsen <eric <at> ericabrahamsen.net>
To: bug-gnu-emacs <at> gnu.org
Subject: 27.0.50; Some questions about choose-completion-string-functions
Date: Wed, 06 Mar 2019 15:05:29 -0800

I'm trying to use `choose-completion-string-functions' to do some
"stuff" after the user finishes a completion, and have two questions:

1. The docstring of this variable says it is called with three
   arguments, but in fact it's called with four: the fourth is passed as
   nil, and is only there for backward compatibility, apparently. But
   still, you can't use a function that only accepts three args. I can
   provide a patch for the docstring if this is correct.
2. The code in `choose-completion-string' behaves as though the above
   variable is buffer local, but it is never declared to be so. I'm not
   sure if this is a bug (ie, we should be using `defvar-local'), or
   whether I should be adding functions here using the (local 'SYMBOL)
   convention of `add-function'. If that's the case, that's probably
   also a docstring bug, as we should warn users that they'll want to
   specify a local variable.

WDYT?

Eric

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

From: Eric Abrahamsen <eric <at> ericabrahamsen.net>
To: 34776 <at> debbugs.gnu.org
Subject: Re: bug#34776: Acknowledgement (27.0.50;
 Some questions about choose-completion-string-functions)
Date: Fri, 08 Mar 2019 16:05:16 -0800

Actually it looks like I was wrong about using add-function with
choose-completion-string-functions, it's just a plain list you stick
functions into. I think it has to be an error not to declare it
buffer-local... I've worked around this with `make-local-variable', but
I'm halfway sure this should be a defvar-local...?

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

From: Glenn Morris <rgm <at> gnu.org>
To: Eric Abrahamsen <eric <at> ericabrahamsen.net>
Cc: 34776 <at> debbugs.gnu.org
Subject: Re: bug#34776: Acknowledgement (27.0.50;
 Some questions about choose-completion-string-functions)
Date: Fri, 08 Mar 2019 21:07:32 -0500

Eric Abrahamsen wrote:

> Actually it looks like I was wrong about using add-function with
> choose-completion-string-functions, it's just a plain list you stick
> functions into. I think it has to be an error not to declare it
> buffer-local... I've worked around this with `make-local-variable', but
> I'm halfway sure this should be a defvar-local...?

The two uses in the Emacs code-base use add-hook without LOCAL.
completing-read-multiple and ido-common-initialization.

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

From: Eric Abrahamsen <eric <at> ericabrahamsen.net>
To: Glenn Morris <rgm <at> gnu.org>
Cc: 34776 <at> debbugs.gnu.org
Subject: Re: bug#34776: Acknowledgement (27.0.50;
 Some questions about choose-completion-string-functions)
Date: Wed, 13 Mar 2019 09:51:11 -0700

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

On 03/08/19 21:07 PM, Glenn Morris wrote:
> Eric Abrahamsen wrote:
>
>> Actually it looks like I was wrong about using add-function with
>> choose-completion-string-functions, it's just a plain list you stick
>> functions into. I think it has to be an error not to declare it
>> buffer-local... I've worked around this with `make-local-variable', but
>> I'm halfway sure this should be a defvar-local...?
>
> The two uses in the Emacs code-base use add-hook without LOCAL.
> completing-read-multiple and ido-common-initialization.

You're right, I was misinterpreting the code and comments as saying the
functions should be buffer local, when it just meant they *could* be
buffer local. I'll use add-hook with LOCAL.

So never mind! But I'd still like to add something like the attached, as
functions following the current docstring will raise an error.

Eric

[patch.txt (text/plain, attachment)]

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

From: Noam Postavsky <npostavs <at> gmail.com>
To: Eric Abrahamsen <eric <at> ericabrahamsen.net>
Cc: Glenn Morris <rgm <at> gnu.org>, 34776 <at> debbugs.gnu.org
Subject: Re: bug#34776: Acknowledgement (27.0.50;
 Some questions about choose-completion-string-functions)
Date: Tue, 09 Apr 2019 20:03:17 -0400

Eric Abrahamsen <eric <at> ericabrahamsen.net> writes:

> So never mind! But I'd still like to add something like the attached, as
> functions following the current docstring will raise an error.
>
> Eric
>
> diff --git a/lisp/simple.el b/lisp/simple.el
> index d4ae5ebb1f..0274bdb459 100644
> --- a/lisp/simple.el
> +++ b/lisp/simple.el
> @@ -8188,6 +8188,9 @@ choose-completion-string-functions
>  BUFFER - the buffer in which the choice should be inserted,
>  BASE-POSITION - where to insert the completion.
>  
> +Functions should also accept and ignore a potential fourth
> +argument, passed for backwards compatibility.
> +

Looks good to me.  And it can go to emacs-26 since it's a doc fix.

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

From: Eric Abrahamsen <eric <at> ericabrahamsen.net>
To: 34776 <at> debbugs.gnu.org 
Cc: 34776-done <at> debbugs.gnu.org
Subject: Re: bug#34776: Acknowledgement (27.0.50;
 Some questions about choose-completion-string-functions)
Date: Tue, 09 Apr 2019 20:16:36 -0700

Noam Postavsky <npostavs <at> gmail.com> writes:

> Eric Abrahamsen <eric <at> ericabrahamsen.net> writes:
>
>> So never mind! But I'd still like to add something like the attached, as
>> functions following the current docstring will raise an error.
>>
>> Eric
>>
>> diff --git a/lisp/simple.el b/lisp/simple.el
>> index d4ae5ebb1f..0274bdb459 100644
>> --- a/lisp/simple.el
>> +++ b/lisp/simple.el
>> @@ -8188,6 +8188,9 @@ choose-completion-string-functions
>>  BUFFER - the buffer in which the choice should be inserted,
>>  BASE-POSITION - where to insert the completion.
>>  
>> +Functions should also accept and ignore a potential fourth
>> +argument, passed for backwards compatibility.
>> +
>
> Looks good to me.  And it can go to emacs-26 since it's a doc fix.

Done, thanks.

Welcome back!

E

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

From: Glenn Morris <rgm <at> gnu.org>
To: Noam Postavsky <npostavs <at> gmail.com>
Cc: Eric Abrahamsen <eric <at> ericabrahamsen.net>, 34776 <at> debbugs.gnu.org
Subject: Re: bug#34776: Acknowledgement (27.0.50;
 Some questions about choose-completion-string-functions)
Date: Tue, 09 Apr 2019 23:29:10 -0400

> And it can go to emacs-26 since it's a doc fix.

The RC said Emacs 26.2 was to be released March 27...
Part of making a release is for people to stop changing that branch.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: bug-gnu-emacs <at> gnu.org, Glenn Morris <rgm <at> gnu.org>,
 Noam Postavsky <npostavs <at> gmail.com>
Cc: Eric Abrahamsen <eric <at> ericabrahamsen.net>, 34776 <at> debbugs.gnu.org
Subject: Re: bug#34776: Acknowledgement (27.0.50;
 Some questions about choose-completion-string-functions)
Date: Wed, 10 Apr 2019 07:33:14 +0300

On April 10, 2019 6:29:10 AM GMT+03:00, Glenn Morris <rgm <at> gnu.org> wrote:
> 
> > And it can go to emacs-26 since it's a doc fix.
> 
> The RC said Emacs 26.2 was to be released March 27...
> Part of making a release is for people to stop changing that branch.

Unfortunately, that ship has sailed, since within an hour of RC release a new commit was pushed to the release branch, and another one a week later, without asking.  So now the RC tarball will not be able to be renamed anyway, and the rationale for withholding doc changes is null and void.

"Best laid plans" and all that.

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

From: Eric Abrahamsen <eric <at> ericabrahamsen.net>
To: bug-gnu-emacs <at> gnu.org
Subject: Re: bug#34776: Acknowledgement (27.0.50;
 Some questions about choose-completion-string-functions)
Date: Tue, 09 Apr 2019 23:35:47 -0700

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

> On April 10, 2019 6:29:10 AM GMT+03:00, Glenn Morris <rgm <at> gnu.org> wrote:
>> 
>> > And it can go to emacs-26 since it's a doc fix.
>> 
>> The RC said Emacs 26.2 was to be released March 27...
>> Part of making a release is for people to stop changing that branch.
>
> Unfortunately, that ship has sailed, since within an hour of RC
> release a new commit was pushed to the release branch, and another one
> a week later, without asking. So now the RC tarball will not be able
> to be renamed anyway, and the rationale for withholding doc changes is
> null and void.
>
> "Best laid plans" and all that.

This sounds like a job for a git hook. I pay fairly close attention to
emacs.devel for someone who isn't an Emacs dev, and apparently I missed
this billboard.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: bug-gnu-emacs <at> gnu.org, Eric Abrahamsen <eric <at> ericabrahamsen.net>,
 34776 <at> debbugs.gnu.org
Subject: Re: bug#34776: Acknowledgement (27.0.50;
 Some questions about choose-completion-string-functions)
Date: Wed, 10 Apr 2019 10:01:04 +0300

On April 10, 2019 9:35:47 AM GMT+03:00, Eric Abrahamsen <eric <at> ericabrahamsen.net> wrote:
> Eli Zaretskii <eliz <at> gnu.org> writes:
> 
> > On April 10, 2019 6:29:10 AM GMT+03:00, Glenn Morris <rgm <at> gnu.org>
> wrote:
> >> 
> >> > And it can go to emacs-26 since it's a doc fix.
> >> 
> >> The RC said Emacs 26.2 was to be released March 27...
> >> Part of making a release is for people to stop changing that
> branch.
> >
> > Unfortunately, that ship has sailed, since within an hour of RC
> > release a new commit was pushed to the release branch, and another
> one
> > a week later, without asking. So now the RC tarball will not be able
> > to be renamed anyway, and the rationale for withholding doc changes
> is
> > null and void.
> >
> > "Best laid plans" and all that.
> 
> This sounds like a job for a git hook. I pay fairly close attention to
> emacs.devel for someone who isn't an Emacs dev, and apparently I
> missed
> this billboard.

Not sure which billboard jou think you missed, but in general, I don't see here any problem for which a commit hook would be a good solution.  The existing hooks are already annoying enough, and are too easy to bypass to be reliable.

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

From: Eric Abrahamsen <eric <at> ericabrahamsen.net>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 34776 <at> debbugs.gnu.org
Subject: Re: bug#34776: Acknowledgement (27.0.50;
 Some questions about choose-completion-string-functions)
Date: Wed, 10 Apr 2019 00:22:14 -0700

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

> On April 10, 2019 9:35:47 AM GMT+03:00, Eric Abrahamsen <eric <at> ericabrahamsen.net> wrote:
>> Eli Zaretskii <eliz <at> gnu.org> writes:
>> 
>> > On April 10, 2019 6:29:10 AM GMT+03:00, Glenn Morris <rgm <at> gnu.org>
>> wrote:
>> >> 
>> >> > And it can go to emacs-26 since it's a doc fix.
>> >> 
>> >> The RC said Emacs 26.2 was to be released March 27...
>> >> Part of making a release is for people to stop changing that
>> branch.
>> >
>> > Unfortunately, that ship has sailed, since within an hour of RC
>> > release a new commit was pushed to the release branch, and another
>> one
>> > a week later, without asking. So now the RC tarball will not be able
>> > to be renamed anyway, and the rationale for withholding doc changes
>> is
>> > null and void.
>> >
>> > "Best laid plans" and all that.
>> 
>> This sounds like a job for a git hook. I pay fairly close attention to
>> emacs.devel for someone who isn't an Emacs dev, and apparently I
>> missed
>> this billboard.
>
> Not sure which billboard jou think you missed, but in general, I don't
> see here any problem for which a commit hook would be a good solution.
> The existing hooks are already annoying enough, and are too easy to
> bypass to be reliable.

What I meant was: if 200 people have the ability to push to the repo,
but 50 of them aren't checking the mailing lists regularly, then you
call a halt to an RC, that's 50 people who don't know they shouldn't
push. It seems like a lot more work to chase after those 50 than to
close the gate and reject pushes to that particular release.

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

From: Eric Abrahamsen <eric <at> ericabrahamsen.net>
To: bug-gnu-emacs <at> gnu.org
Subject: Re: bug#34776: Acknowledgement (27.0.50;
 Some questions about choose-completion-string-functions)
Date: Wed, 10 Apr 2019 00:29:13 -0700

Eric Abrahamsen <eric <at> ericabrahamsen.net> writes:

> Eli Zaretskii <eliz <at> gnu.org> writes:
>
>> On April 10, 2019 9:35:47 AM GMT+03:00, Eric Abrahamsen <eric <at> ericabrahamsen.net> wrote:
>>> Eli Zaretskii <eliz <at> gnu.org> writes:
>>>
>>> > On April 10, 2019 6:29:10 AM GMT+03:00, Glenn Morris <rgm <at> gnu.org>
>>> wrote:
>>> >>
>>> >> > And it can go to emacs-26 since it's a doc fix.
>>> >>
>>> >> The RC said Emacs 26.2 was to be released March 27...
>>> >> Part of making a release is for people to stop changing that
>>> branch.
>>> >
>>> > Unfortunately, that ship has sailed, since within an hour of RC
>>> > release a new commit was pushed to the release branch, and another
>>> one
>>> > a week later, without asking. So now the RC tarball will not be able
>>> > to be renamed anyway, and the rationale for withholding doc changes
>>> is
>>> > null and void.
>>> >
>>> > "Best laid plans" and all that.
>>>
>>> This sounds like a job for a git hook. I pay fairly close attention to
>>> emacs.devel for someone who isn't an Emacs dev, and apparently I
>>> missed
>>> this billboard.
>>
>> Not sure which billboard jou think you missed, but in general, I don't
>> see here any problem for which a commit hook would be a good solution.
>> The existing hooks are already annoying enough, and are too easy to
>> bypass to be reliable.
>
> What I meant was: if 200 people have the ability to push to the repo,
> but 50 of them aren't checking the mailing lists regularly, then you
> call a halt to an RC, that's 50 people who don't know they shouldn't
> push. It seems like a lot more work to chase after those 50 than to
> close the gate and reject pushes to that particular release.

I keep hitting C-c C-s (message-send) instead of C-x C-s (which would
save a draft), which I hope will explain my slightly rude tone here.

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

From: Andreas Schwab <schwab <at> suse.de>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: eric <at> ericabrahamsen.net, rgm <at> gnu.org, 34776 <at> debbugs.gnu.org,
 npostavs <at> gmail.com
Subject: Re: bug#34776: Acknowledgement (27.0.50;
 Some questions about choose-completion-string-functions)
Date: Wed, 10 Apr 2019 10:05:02 +0200

On Apr 10 2019, Eli Zaretskii <eliz <at> gnu.org> wrote:

> Unfortunately, that ship has sailed, since within an hour of RC release a new commit was pushed to the release branch, and another one a week later, without asking.  So now the RC tarball will not be able to be renamed anyway, and the rationale for withholding doc changes is null and void.

Why not?  Just tag the last commit that is contained in the rc release.

Andreas.

-- 
Andreas Schwab, SUSE Labs, schwab <at> suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Andreas Schwab <schwab <at> suse.de>
Cc: eric <at> ericabrahamsen.net, rgm <at> gnu.org, 34776 <at> debbugs.gnu.org,
 npostavs <at> gmail.com
Subject: Re: bug#34776: Acknowledgement (27.0.50;
 Some questions about choose-completion-string-functions)
Date: Wed, 10 Apr 2019 11:22:44 +0300

On April 10, 2019 11:05:02 AM GMT+03:00, Andreas Schwab <schwab <at> suse.de> wrote:
> On Apr 10 2019, Eli Zaretskii <eliz <at> gnu.org> wrote:
> 
> > Unfortunately, that ship has sailed, since within an hour of RC
> release a new commit was pushed to the release branch, and another one
> a week later, without asking.  So now the RC tarball will not be able
> to be renamed anyway, and the rationale for withholding doc changes is
> null and void.
> 
> Why not?  Just tag the last commit that is contained in the rc
> release.
> 
> Andreas.

The RC contains several uncommitted changes.  Hopefully won't happen in the future.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Eric Abrahamsen <eric <at> ericabrahamsen.net>
Cc: 34776 <at> debbugs.gnu.org
Subject: Re: bug#34776: Acknowledgement (27.0.50;
 Some questions about choose-completion-string-functions)
Date: Wed, 10 Apr 2019 11:24:41 +0300

On April 10, 2019 10:22:14 AM GMT+03:00, Eric Abrahamsen <eric <at> ericabrahamsen.net> wrote:
> Eli Zaretskii <eliz <at> gnu.org> writes:
> 
> > On April 10, 2019 9:35:47 AM GMT+03:00, Eric Abrahamsen
> <eric <at> ericabrahamsen.net> wrote:
> >> Eli Zaretskii <eliz <at> gnu.org> writes:
> >> 
> >> > On April 10, 2019 6:29:10 AM GMT+03:00, Glenn Morris
> <rgm <at> gnu.org>
> >> wrote:
> >> >> 
> >> >> > And it can go to emacs-26 since it's a doc fix.
> >> >> 
> >> >> The RC said Emacs 26.2 was to be released March 27...
> >> >> Part of making a release is for people to stop changing that
> >> branch.
> >> >
> >> > Unfortunately, that ship has sailed, since within an hour of RC
> >> > release a new commit was pushed to the release branch, and
> another
> >> one
> >> > a week later, without asking. So now the RC tarball will not be
> able
> >> > to be renamed anyway, and the rationale for withholding doc
> changes
> >> is
> >> > null and void.
> >> >
> >> > "Best laid plans" and all that.
> >> 
> >> This sounds like a job for a git hook. I pay fairly close attention
> to
> >> emacs.devel for someone who isn't an Emacs dev, and apparently I
> >> missed
> >> this billboard.
> >
> > Not sure which billboard jou think you missed, but in general, I
> don't
> > see here any problem for which a commit hook would be a good
> solution.
> > The existing hooks are already annoying enough, and are too easy to
> > bypass to be reliable.
> 
> What I meant was: if 200 people have the ability to push to the repo,
> but 50 of them aren't checking the mailing lists regularly, then you
> call a halt to an RC, that's 50 people who don't know they shouldn't
> push. It seems like a lot more work to chase after those 50 than to
> close the gate and reject pushes to that particular release.

There's no need to check the mailing list, this stuff is in CONTRIBUTE.  That's why I never called for any halts.

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

From: Andreas Schwab <schwab <at> suse.de>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: eric <at> ericabrahamsen.net, 34776 <at> debbugs.gnu.org, npostavs <at> gmail.com
Subject: Re: bug#34776: Acknowledgement (27.0.50;
 Some questions about choose-completion-string-functions)
Date: Wed, 10 Apr 2019 10:39:55 +0200

On Apr 10 2019, Eli Zaretskii <eliz <at> gnu.org> wrote:

> On April 10, 2019 11:05:02 AM GMT+03:00, Andreas Schwab <schwab <at> suse.de> wrote:
>> On Apr 10 2019, Eli Zaretskii <eliz <at> gnu.org> wrote:
>> 
>> > Unfortunately, that ship has sailed, since within an hour of RC
>> release a new commit was pushed to the release branch, and another one
>> a week later, without asking.  So now the RC tarball will not be able
>> to be renamed anyway, and the rationale for withholding doc changes is
>> null and void.
>> 
>> Why not?  Just tag the last commit that is contained in the rc
>> release.
>> 
>> Andreas.
>
> The RC contains several uncommitted changes.  Hopefully won't happen in the future.

That isn't a problem either.  They can be put on a local branch, into
which upstream is merged after the tag.

Andreas.

-- 
Andreas Schwab, SUSE Labs, schwab <at> suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Andreas Schwab <schwab <at> suse.de>
Cc: eric <at> ericabrahamsen.net, 34776 <at> debbugs.gnu.org, npostavs <at> gmail.com
Subject: Re: bug#34776: Acknowledgement (27.0.50;
 Some questions about choose-completion-string-functions)
Date: Wed, 10 Apr 2019 11:48:27 +0300

On April 10, 2019 11:39:55 AM GMT+03:00, Andreas Schwab <schwab <at> suse.de> wrote:
> On Apr 10 2019, Eli Zaretskii <eliz <at> gnu.org> wrote:
> 
> > On April 10, 2019 11:05:02 AM GMT+03:00, Andreas Schwab
> <schwab <at> suse.de> wrote:
> >> On Apr 10 2019, Eli Zaretskii <eliz <at> gnu.org> wrote:
> >> 
> >> > Unfortunately, that ship has sailed, since within an hour of RC
> >> release a new commit was pushed to the release branch, and another
> one
> >> a week later, without asking.  So now the RC tarball will not be
> able
> >> to be renamed anyway, and the rationale for withholding doc changes
> is
> >> null and void.
> >> 
> >> Why not?  Just tag the last commit that is contained in the rc
> >> release.
> >> 
> >> Andreas.
> >
> > The RC contains several uncommitted changes.  Hopefully won't happen
> in the future.
> 
> That isn't a problem either.  They can be put on a local branch, into
> which upstream is merged after the tag.
> 
> Andreas.

I decided it wasn't worth the hassle of releasing 26.2 from a side branch.

Previous Next

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