* bug#34776: 27.0.50; Some questions about choose-completion-string-functions
@ 2019-03-06 23:05 Eric Abrahamsen
[not found] ` <handler.34776.B.155191354931988.ack@debbugs.gnu.org>
0 siblings, 1 reply; 17+ messages in thread
From: Eric Abrahamsen @ 2019-03-06 23:05 UTC (permalink / raw)
To: 34776
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
^ permalink raw reply [flat|nested] 17+ messages in thread
* bug#34776: Acknowledgement (27.0.50; Some questions about choose-completion-string-functions)
[not found] ` <handler.34776.B.155191354931988.ack@debbugs.gnu.org>
@ 2019-03-09 0:05 ` Eric Abrahamsen
2019-03-09 2:07 ` Glenn Morris
0 siblings, 1 reply; 17+ messages in thread
From: Eric Abrahamsen @ 2019-03-09 0:05 UTC (permalink / raw)
To: 34776
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...?
^ permalink raw reply [flat|nested] 17+ messages in thread
* bug#34776: Acknowledgement (27.0.50; Some questions about choose-completion-string-functions)
2019-03-09 0:05 ` bug#34776: Acknowledgement (27.0.50; Some questions about choose-completion-string-functions) Eric Abrahamsen
@ 2019-03-09 2:07 ` Glenn Morris
2019-03-13 16:51 ` Eric Abrahamsen
0 siblings, 1 reply; 17+ messages in thread
From: Glenn Morris @ 2019-03-09 2:07 UTC (permalink / raw)
To: Eric Abrahamsen; +Cc: 34776
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.
^ permalink raw reply [flat|nested] 17+ messages in thread
* bug#34776: Acknowledgement (27.0.50; Some questions about choose-completion-string-functions)
2019-03-09 2:07 ` Glenn Morris
@ 2019-03-13 16:51 ` Eric Abrahamsen
2019-04-10 0:03 ` Noam Postavsky
0 siblings, 1 reply; 17+ messages in thread
From: Eric Abrahamsen @ 2019-03-13 16:51 UTC (permalink / raw)
To: Glenn Morris; +Cc: 34776
[-- Attachment #1: Type: text/plain, Size: 862 bytes --]
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
[-- Attachment #2: patch.txt --]
[-- Type: text/plain, Size: 589 bytes --]
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.
+
If a function in the list returns non-nil, that function is supposed
to have inserted the CHOICE in the BUFFER, and possibly exited
the minibuffer; no further functions will be called.
^ permalink raw reply related [flat|nested] 17+ messages in thread
* bug#34776: Acknowledgement (27.0.50; Some questions about choose-completion-string-functions)
2019-03-13 16:51 ` Eric Abrahamsen
@ 2019-04-10 0:03 ` Noam Postavsky
2019-04-10 3:16 ` Eric Abrahamsen
2019-04-10 3:29 ` Glenn Morris
0 siblings, 2 replies; 17+ messages in thread
From: Noam Postavsky @ 2019-04-10 0:03 UTC (permalink / raw)
To: Eric Abrahamsen; +Cc: 34776
Eric Abrahamsen <eric@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.
^ permalink raw reply [flat|nested] 17+ messages in thread
* bug#34776: Acknowledgement (27.0.50; Some questions about choose-completion-string-functions)
2019-04-10 0:03 ` Noam Postavsky
@ 2019-04-10 3:16 ` Eric Abrahamsen
2019-04-10 3:29 ` Glenn Morris
1 sibling, 0 replies; 17+ messages in thread
From: Eric Abrahamsen @ 2019-04-10 3:16 UTC (permalink / raw)
To: 34776; +Cc: 34776-done
Noam Postavsky <npostavs@gmail.com> writes:
> Eric Abrahamsen <eric@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
^ permalink raw reply [flat|nested] 17+ messages in thread
* bug#34776: Acknowledgement (27.0.50; Some questions about choose-completion-string-functions)
2019-04-10 0:03 ` Noam Postavsky
2019-04-10 3:16 ` Eric Abrahamsen
@ 2019-04-10 3:29 ` Glenn Morris
2019-04-10 4:33 ` Eli Zaretskii
1 sibling, 1 reply; 17+ messages in thread
From: Glenn Morris @ 2019-04-10 3:29 UTC (permalink / raw)
To: Noam Postavsky; +Cc: Eric Abrahamsen, 34776
> 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.
^ permalink raw reply [flat|nested] 17+ messages in thread
* bug#34776: Acknowledgement (27.0.50; Some questions about choose-completion-string-functions)
2019-04-10 3:29 ` Glenn Morris
@ 2019-04-10 4:33 ` Eli Zaretskii
2019-04-10 6:35 ` Eric Abrahamsen
2019-04-10 8:05 ` Andreas Schwab
0 siblings, 2 replies; 17+ messages in thread
From: Eli Zaretskii @ 2019-04-10 4:33 UTC (permalink / raw)
To: 34776, rgm, npostavs; +Cc: eric
On April 10, 2019 6:29:10 AM GMT+03:00, Glenn Morris <rgm@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.
^ permalink raw reply [flat|nested] 17+ messages in thread
* bug#34776: Acknowledgement (27.0.50; Some questions about choose-completion-string-functions)
2019-04-10 4:33 ` Eli Zaretskii
@ 2019-04-10 6:35 ` Eric Abrahamsen
2019-04-10 7:01 ` Eli Zaretskii
2019-04-10 8:05 ` Andreas Schwab
1 sibling, 1 reply; 17+ messages in thread
From: Eric Abrahamsen @ 2019-04-10 6:35 UTC (permalink / raw)
To: 34776
Eli Zaretskii <eliz@gnu.org> writes:
> On April 10, 2019 6:29:10 AM GMT+03:00, Glenn Morris <rgm@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.
^ permalink raw reply [flat|nested] 17+ messages in thread
* bug#34776: Acknowledgement (27.0.50; Some questions about choose-completion-string-functions)
2019-04-10 6:35 ` Eric Abrahamsen
@ 2019-04-10 7:01 ` Eli Zaretskii
2019-04-10 7:22 ` Eric Abrahamsen
0 siblings, 1 reply; 17+ messages in thread
From: Eli Zaretskii @ 2019-04-10 7:01 UTC (permalink / raw)
To: 34776, eric
On April 10, 2019 9:35:47 AM GMT+03:00, Eric Abrahamsen <eric@ericabrahamsen.net> wrote:
> Eli Zaretskii <eliz@gnu.org> writes:
>
> > On April 10, 2019 6:29:10 AM GMT+03:00, Glenn Morris <rgm@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.
^ permalink raw reply [flat|nested] 17+ messages in thread
* bug#34776: Acknowledgement (27.0.50; Some questions about choose-completion-string-functions)
2019-04-10 7:01 ` Eli Zaretskii
@ 2019-04-10 7:22 ` Eric Abrahamsen
2019-04-10 7:29 ` Eric Abrahamsen
2019-04-10 8:24 ` Eli Zaretskii
0 siblings, 2 replies; 17+ messages in thread
From: Eric Abrahamsen @ 2019-04-10 7:22 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 34776
Eli Zaretskii <eliz@gnu.org> writes:
> On April 10, 2019 9:35:47 AM GMT+03:00, Eric Abrahamsen <eric@ericabrahamsen.net> wrote:
>> Eli Zaretskii <eliz@gnu.org> writes:
>>
>> > On April 10, 2019 6:29:10 AM GMT+03:00, Glenn Morris <rgm@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.
^ permalink raw reply [flat|nested] 17+ messages in thread
* bug#34776: Acknowledgement (27.0.50; Some questions about choose-completion-string-functions)
2019-04-10 7:22 ` Eric Abrahamsen
@ 2019-04-10 7:29 ` Eric Abrahamsen
2019-04-10 8:24 ` Eli Zaretskii
1 sibling, 0 replies; 17+ messages in thread
From: Eric Abrahamsen @ 2019-04-10 7:29 UTC (permalink / raw)
To: 34776
Eric Abrahamsen <eric@ericabrahamsen.net> writes:
> Eli Zaretskii <eliz@gnu.org> writes:
>
>> On April 10, 2019 9:35:47 AM GMT+03:00, Eric Abrahamsen <eric@ericabrahamsen.net> wrote:
>>> Eli Zaretskii <eliz@gnu.org> writes:
>>>
>>> > On April 10, 2019 6:29:10 AM GMT+03:00, Glenn Morris <rgm@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.
^ permalink raw reply [flat|nested] 17+ messages in thread
* bug#34776: Acknowledgement (27.0.50; Some questions about choose-completion-string-functions)
2019-04-10 4:33 ` Eli Zaretskii
2019-04-10 6:35 ` Eric Abrahamsen
@ 2019-04-10 8:05 ` Andreas Schwab
2019-04-10 8:22 ` Eli Zaretskii
1 sibling, 1 reply; 17+ messages in thread
From: Andreas Schwab @ 2019-04-10 8:05 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: eric, 34776, npostavs
On Apr 10 2019, Eli Zaretskii <eliz@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@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."
^ permalink raw reply [flat|nested] 17+ messages in thread
* bug#34776: Acknowledgement (27.0.50; Some questions about choose-completion-string-functions)
2019-04-10 8:05 ` Andreas Schwab
@ 2019-04-10 8:22 ` Eli Zaretskii
2019-04-10 8:39 ` Andreas Schwab
0 siblings, 1 reply; 17+ messages in thread
From: Eli Zaretskii @ 2019-04-10 8:22 UTC (permalink / raw)
To: Andreas Schwab; +Cc: eric, 34776, npostavs
On April 10, 2019 11:05:02 AM GMT+03:00, Andreas Schwab <schwab@suse.de> wrote:
> On Apr 10 2019, Eli Zaretskii <eliz@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.
^ permalink raw reply [flat|nested] 17+ messages in thread
* bug#34776: Acknowledgement (27.0.50; Some questions about choose-completion-string-functions)
2019-04-10 7:22 ` Eric Abrahamsen
2019-04-10 7:29 ` Eric Abrahamsen
@ 2019-04-10 8:24 ` Eli Zaretskii
1 sibling, 0 replies; 17+ messages in thread
From: Eli Zaretskii @ 2019-04-10 8:24 UTC (permalink / raw)
To: Eric Abrahamsen; +Cc: 34776
On April 10, 2019 10:22:14 AM GMT+03:00, Eric Abrahamsen <eric@ericabrahamsen.net> wrote:
> Eli Zaretskii <eliz@gnu.org> writes:
>
> > On April 10, 2019 9:35:47 AM GMT+03:00, Eric Abrahamsen
> <eric@ericabrahamsen.net> wrote:
> >> Eli Zaretskii <eliz@gnu.org> writes:
> >>
> >> > On April 10, 2019 6:29:10 AM GMT+03:00, Glenn Morris
> <rgm@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.
^ permalink raw reply [flat|nested] 17+ messages in thread
* bug#34776: Acknowledgement (27.0.50; Some questions about choose-completion-string-functions)
2019-04-10 8:22 ` Eli Zaretskii
@ 2019-04-10 8:39 ` Andreas Schwab
2019-04-10 8:48 ` Eli Zaretskii
0 siblings, 1 reply; 17+ messages in thread
From: Andreas Schwab @ 2019-04-10 8:39 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: eric, 34776, npostavs
On Apr 10 2019, Eli Zaretskii <eliz@gnu.org> wrote:
> On April 10, 2019 11:05:02 AM GMT+03:00, Andreas Schwab <schwab@suse.de> wrote:
>> On Apr 10 2019, Eli Zaretskii <eliz@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@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."
^ permalink raw reply [flat|nested] 17+ messages in thread
* bug#34776: Acknowledgement (27.0.50; Some questions about choose-completion-string-functions)
2019-04-10 8:39 ` Andreas Schwab
@ 2019-04-10 8:48 ` Eli Zaretskii
0 siblings, 0 replies; 17+ messages in thread
From: Eli Zaretskii @ 2019-04-10 8:48 UTC (permalink / raw)
To: Andreas Schwab; +Cc: eric, 34776, npostavs
On April 10, 2019 11:39:55 AM GMT+03:00, Andreas Schwab <schwab@suse.de> wrote:
> On Apr 10 2019, Eli Zaretskii <eliz@gnu.org> wrote:
>
> > On April 10, 2019 11:05:02 AM GMT+03:00, Andreas Schwab
> <schwab@suse.de> wrote:
> >> On Apr 10 2019, Eli Zaretskii <eliz@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.
^ permalink raw reply [flat|nested] 17+ messages in thread
end of thread, other threads:[~2019-04-10 8:48 UTC | newest]
Thread overview: 17+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-03-06 23:05 bug#34776: 27.0.50; Some questions about choose-completion-string-functions Eric Abrahamsen
[not found] ` <handler.34776.B.155191354931988.ack@debbugs.gnu.org>
2019-03-09 0:05 ` bug#34776: Acknowledgement (27.0.50; Some questions about choose-completion-string-functions) Eric Abrahamsen
2019-03-09 2:07 ` Glenn Morris
2019-03-13 16:51 ` Eric Abrahamsen
2019-04-10 0:03 ` Noam Postavsky
2019-04-10 3:16 ` Eric Abrahamsen
2019-04-10 3:29 ` Glenn Morris
2019-04-10 4:33 ` Eli Zaretskii
2019-04-10 6:35 ` Eric Abrahamsen
2019-04-10 7:01 ` Eli Zaretskii
2019-04-10 7:22 ` Eric Abrahamsen
2019-04-10 7:29 ` Eric Abrahamsen
2019-04-10 8:24 ` Eli Zaretskii
2019-04-10 8:05 ` Andreas Schwab
2019-04-10 8:22 ` Eli Zaretskii
2019-04-10 8:39 ` Andreas Schwab
2019-04-10 8:48 ` Eli Zaretskii
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).