GNU bug report logs -
#38317
Buffer-local variables don't work as history for read-from-minibuffer
Previous Next
Reported by: Federico Tedin <federicotedin <at> gmail.com>
Date: Thu, 21 Nov 2019 21:31:02 UTC
Severity: normal
Tags: fixed
Fixed in version 27.1
Done: Lars Ingebrigtsen <larsi <at> gnus.org>
Bug is archived. No further changes may be made.
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 38317 in the body.
You can then email your comments to 38317 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#38317
; Package
emacs
.
(Thu, 21 Nov 2019 21:31:03 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Federico Tedin <federicotedin <at> gmail.com>
:
New bug report received and forwarded. Copy sent to
bug-gnu-emacs <at> gnu.org
.
(Thu, 21 Nov 2019 21:31:03 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
I was recently trying to modify `goto-line' so that it uses a
buffer-local variable as input history for the minibuffer (so that line
numbers don't get mixed up with other inputted values, and each buffer
has its own input history) (see: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=38282).
First, I modified `read-number' and added a new HIST parameter. Then I
just forwarded that value to `read-from-minibuffer'.
Then, in simple.el, I added a new buffer-local variable
`goto-line--hist' and passed it to `read-number' in `goto-line'. I also
added I call to `add-to-history` to record the value read. All of this
did not work as expected: the input history for all buffers was shared
for all uses of `goto-line'. Inspecting `goto-line--hist' with M-:
showed the correct list of values, however.
The shortest way I've found of reproducing the problem is:
(defvar-local local-hist nil)
(defun my-command ()
(interactive)
(add-to-history 'local-hist (read-from-minibuffer "> " nil nil nil 'local-hist)))
In this case, the variable `local-hist' will end up containing all the
inputted values (per buffer), but trying to use M-p or M-n to step
through the input history after invoking `my-command' will not work ("no
preceding item"). So to summarize, `read-from-minibuffer' doesn't seem
to work correctly when HIST is buffer-local.
Related: https://emacs.stackexchange.com/questions/53892/buffer-local-input-history-for-read-from-minibuffer/53898#53898
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#38317
; Package
emacs
.
(Fri, 22 Nov 2019 13:35:03 GMT)
Full text and
rfc822 format available.
Message #8 received at 38317 <at> debbugs.gnu.org (full text, mbox):
Federico Tedin <federicotedin <at> gmail.com> writes:
> In this case, the variable `local-hist' will end up containing all the
> inputted values (per buffer), but trying to use M-p or M-n to step
> through the input history after invoking `my-command' will not work ("no
> preceding item"). So to summarize, `read-from-minibuffer' doesn't seem
> to work correctly when HIST is buffer-local.
Looking at the code in read_minibuf, it does seem to access the
buffer-local value of the HIST variable, but my guess is that the buffer
it's looking at is the minibuffer? And the variable isn't buffer-local
there.
There doesn't seem to be any way to tell read_minibuf what buffer it
should be looking at to get at the buffer-local value?
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#38317
; Package
emacs
.
(Fri, 22 Nov 2019 15:25:03 GMT)
Full text and
rfc822 format available.
Message #11 received at 38317 <at> debbugs.gnu.org (full text, mbox):
Lars Ingebrigtsen <larsi <at> gnus.org> writes:
> Looking at the code in read_minibuf, it does seem to access the
> buffer-local value of the HIST variable, but my guess is that the buffer
> it's looking at is the minibuffer? And the variable isn't buffer-local
> there.
The problem is M-p: this command is called with the minibuffer current.
The helper `goto-history-element' calls (symbol-value
minibuffer-history-variable) and that returns the binding of the
variable in the minibuffer. Adding to the buffer local history already
works as expected OTOH, so the behavior is inconsistent.
Dunno if there are more inconsistencies to expect when trying to fix
M-p. My personal point of view is that when we can make it work without
risking breakage of anything else it would be nice to fix this.
Michael.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#38317
; Package
emacs
.
(Fri, 22 Nov 2019 16:25:02 GMT)
Full text and
rfc822 format available.
Message #14 received at 38317 <at> debbugs.gnu.org (full text, mbox):
> There doesn't seem to be any way to tell read_minibuf what buffer it
> should be looking at to get at the buffer-local value?
The one from the buffer of 'minibuffer-selected-window'?
martin
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#38317
; Package
emacs
.
(Sat, 23 Nov 2019 11:55:01 GMT)
Full text and
rfc822 format available.
Message #17 received at 38317 <at> debbugs.gnu.org (full text, mbox):
martin rudalics <rudalics <at> gmx.at> writes:
>> There doesn't seem to be any way to tell read_minibuf what buffer it
>> should be looking at to get at the buffer-local value?
>
> The one from the buffer of 'minibuffer-selected-window'?
Unconditionally looking at that buffer wouldn't work, I think? Because
you may genuinely have a buffer-local version of the variable in the
minibuffer? Or is that unlikely?
I guess that's quite unlikely.
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#38317
; Package
emacs
.
(Sat, 23 Nov 2019 20:39:06 GMT)
Full text and
rfc822 format available.
Message #20 received at 38317 <at> debbugs.gnu.org (full text, mbox):
I've been looking into the problem, what I found so far is:
`read-from-minibuffer' works normally if HIST is not buffer-local.
If HIST is buffer-local, then the history variable doesn't seem to be
updated correctly after returning (so using M-p and M-n doesn't do
anything).
My test was:
(setq test-history nil)
(make-variable-buffer-local 'test-history)
(read-from-minibuffer "" nil nil nil 'test-history)
After running that and inputting "hello", I checked:
(buffer-local-value 'test-history (current-buffer)) ;; -> nil
(buffer-local-value 'test-history (get-buffer " *Minibuf-0*")) ;; -> nil
(buffer-local-value 'test-history (get-buffer " *Minibuf-1*")) ;; -> nil
So although `read_minibuf' does call `add-to-history' before returning
(and after setting the current buffer to be the minibuffer's), my input
wasn't added to any list (that I know of). This is strange, since
`add-to-history' seemed to work correctly with buffer-local variables
when I tested it separately. I would've expected the new history item to
be added to one of the minibuffer's `test-history' local variable.
So I think the first step would be to make `read_minibuf' add the new
history item into the right place when HIST is buffer-local.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#38317
; Package
emacs
.
(Sat, 23 Nov 2019 23:15:02 GMT)
Full text and
rfc822 format available.
Message #23 received at 38317 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
> So although `read_minibuf' does call `add-to-history' before returning
> (and after setting the current buffer to be the minibuffer's), my input
> wasn't added to any list (that I know of). This is strange, since
> `add-to-history' seemed to work correctly with buffer-local variables
> when I tested it separately. I would've expected the new history item to
> be added to one of the minibuffer's `test-history' local variable.
>
> So I think the first step would be to make `read_minibuf' add the new
> history item into the right place when HIST is buffer-local.
Turns out `get_minibuffer' sets the minibuffer's buffer mode to
`minibuffer-inactive-mode', which resets the minibuffer's local
variables (though not 100% sure about this). I think the history items
were being added to the minibuffer's local version of the variable, and
then being deleted by that.
I created a small patch that sets back the original buffer at the end of
`read_minibuf', so that the history item is added in the right
place. Then, I modified `goto-history-element' as Michael suggested, so
that the function reads the buffer-local version of the variable, but
not the minibuffer's (and updated `minibuffer-history-isearch-wrap' just
in case as well). With this, M-p and M-n works again.
I'm attaching a draft patch in case anyone wants to provide some
feedback. Thanks!
- Fede
[minibuf.diff (text/x-diff, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#38317
; Package
emacs
.
(Tue, 26 Nov 2019 21:55:01 GMT)
Full text and
rfc822 format available.
Message #26 received at 38317 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
> I'm attaching a draft patch in case anyone wants to provide some
> feedback. Thanks!
I'm now attaching a final version of my patch.
I've tested the following commands with it, using `read-from-minibuffer'
with a buffer-local HIST:
- previous-history-element (M-p)
- next-history-element (M-n)
- previous-matching-history-element (M-r)
- next-matching-history-element (M-s)
- isearch-forward (C-s)
- isearch-backward (C-r)
They've all worked correctly and used only the buffer's local history
value.
Thanks!
[minibuffer.patch (text/x-diff, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#38317
; Package
emacs
.
(Wed, 27 Nov 2019 08:15:01 GMT)
Full text and
rfc822 format available.
Message #29 received at 38317 <at> debbugs.gnu.org (full text, mbox):
>>>>> On Tue, 26 Nov 2019 22:54:29 +0100, Federico Tedin <federicotedin <at> gmail.com> said:
>> I'm attaching a draft patch in case anyone wants to provide some
>> feedback. Thanks!
Federico> I'm now attaching a final version of my patch.
Federico> I've tested the following commands with it, using `read-from-minibuffer'
Federico> with a buffer-local HIST:
Federico> - previous-history-element (M-p)
Federico> - next-history-element (M-n)
Federico> - previous-matching-history-element (M-r)
Federico> - next-matching-history-element (M-s)
Federico> - isearch-forward (C-s)
Federico> - isearch-backward (C-r)
Federico> They've all worked correctly and used only the buffer's local history
Federico> value.
Federico> Thanks!
Federico> From 496fbc75e02e016d50d3e1a21154e4da844a1140 Mon Sep 17 00:00:00 2001
Federico> From: Federico Tedin <federicotedin <at> gmail.com>
Federico> Date: Tue, 26 Nov 2019 22:39:34 +0100
Federico> Subject: [PATCH 1/1] Make HIST arg of read-from-minibuffer work with
Federico> buffer-local vars
Federico> * lisp/simple.el (minibuffer-history-values): New function, should be
Federico> used to access the minibuffer input history variable when the
Federico> minibuffer might be active. If the variable is buffer-local, the
Federico> previous buffer's value will be used.
2 spaces after '.' (here and elsewhere).
Federico> (goto-history-element): Use the new function to access the minibuffer
Federico> history.
Federico> (minibuffer-history-isearch-wrap): Use the new function to access the
Federico> minibuffer history.
Federico> * src/minibuf.c (read_minibuf): Switch to previous buffer temporarily
Federico> before updating history list (Bug#38317).
Federico> * etc/NEWS: Announce changes.
Federico> ---
Federico> etc/NEWS | 6 ++++++
Federico> lisp/simple.el | 18 +++++++++++++-----
Federico> src/minibuf.c | 17 +++++++++++++++--
Federico> 3 files changed, 34 insertions(+), 7 deletions(-)
Federico> diff --git a/etc/NEWS b/etc/NEWS
Federico> index d3331daf17..9dbf36ae40 100644
Federico> --- a/etc/NEWS
Federico> +++ b/etc/NEWS
Federico> @@ -518,6 +518,12 @@ Note that this key binding will not work on MS-Windows systems if
Federico> key binding with an upper case letter - if you can type it, you can
Federico> bind it.
Federico> +---
Federico> +** 'read-from-minibuffer' now works with buffer-local history variables
'.' at end of sentence.
Federico> +The HIST argument of 'read-from-minibuffer' now works correctly with
Federico> +buffer-local variables. This means that different buffers can have
Federico> +their own separated input history list if desired.
Federico> +
Federico>
Federico> * Editing Changes in Emacs 27.1
Federico> diff --git a/lisp/simple.el b/lisp/simple.el
Federico> index 2aac557154..0b1d7b73ab 100644
Federico> --- a/lisp/simple.el
Federico> +++ b/lisp/simple.el
Federico> @@ -2041,7 +2041,7 @@ previous-matching-history-element
Federico> (null minibuffer-text-before-history))
Federico> (setq minibuffer-text-before-history
Federico> (minibuffer-contents-no-properties)))
Federico> - (let ((history (symbol-value minibuffer-history-variable))
Federico> + (let ((history (minibuffer-history-values))
Federico> (case-fold-search
Federico> (if (isearch-no-upper-case-p regexp t) ; assume isearch.el is dumped
Federico> ;; On some systems, ignore case for file names.
Federico> @@ -2141,6 +2141,14 @@ minibuffer-default-add-completions
Federico> (append def all)
Federico> (cons def (delete def all)))))
Federico> +(defun minibuffer-history-values ()
Federico> + "Return the minibuffer input history values.
Federico> +If `minibuffer-history-variable' points to a buffer-local variable and
Federico> +the minibuffer is active, return the buffer-local value for the buffer
Federico> +selected in the window returned by
Federico> `minibuffer-selected-window'."
This is a true description of what the code does, but perhaps not
clear to users. How about:
"for the buffer selected when the minibuffer was activated."
Robert
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#38317
; Package
emacs
.
(Wed, 27 Nov 2019 11:54:02 GMT)
Full text and
rfc822 format available.
Message #32 received at 38317 <at> debbugs.gnu.org (full text, mbox):
Federico Tedin <federicotedin <at> gmail.com> writes:
> I've tested the following commands with it, using `read-from-minibuffer'
> with a buffer-local HIST:
>
> - previous-history-element (M-p)
> - next-history-element (M-n)
> - previous-matching-history-element (M-r)
> - next-matching-history-element (M-s)
> - isearch-forward (C-s)
> - isearch-backward (C-r)
>
> They've all worked correctly and used only the buffer's local history
> value.
I haven't tested the code, but it makes sense to me. I do wonder
whether there are any instances of the variables that are local to the
minibuffer... but I guess that's unlikely?
> +** 'read-from-minibuffer' now works with buffer-local history variables
> +The HIST argument of 'read-from-minibuffer' now works correctly with
> +buffer-local variables. This means that different buffers can have
> +their own separated input history list if desired.
This should probably be documented in the manual, too?
The patch otherwise looks good to me.
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#38317
; Package
emacs
.
(Wed, 27 Nov 2019 15:25:01 GMT)
Full text and
rfc822 format available.
Message #35 received at 38317 <at> debbugs.gnu.org (full text, mbox):
> "for the buffer selected when the minibuffer was activated."
A buffer isn't "selected"; it's "current".
In Emacs jargon, windows and frames are selected;
buffers are made current.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#38317
; Package
emacs
.
(Wed, 27 Nov 2019 15:29:02 GMT)
Full text and
rfc822 format available.
Message #38 received at 38317 <at> debbugs.gnu.org (full text, mbox):
>>>>> On Wed, 27 Nov 2019 07:24:46 -0800 (PST), Drew Adams <drew.adams <at> oracle.com> said:
>> "for the buffer selected when the minibuffer was activated."
Drew> A buffer isn't "selected"; it's "current".
Drew> In Emacs jargon, windows and frames are selected;
Drew> buffers are made current.
Sure, that works as well.
Robert
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#38317
; Package
emacs
.
(Wed, 27 Nov 2019 18:51:02 GMT)
Full text and
rfc822 format available.
Message #41 received at 38317 <at> debbugs.gnu.org (full text, mbox):
> I haven't tested the code, but it makes sense to me. I do wonder
> whether there are any instances of the variables that are local to the
> minibuffer... but I guess that's unlikely?
I agree that it would be unlikely. I am not sure what the use-case for
having a history local to the minibuffer itself would be. It makes much
more sense for the history to be global or to be determined by the
context i.e. the current buffer (like I want to do with `goto-line').
>> +** 'read-from-minibuffer' now works with buffer-local history variables
>> +The HIST argument of 'read-from-minibuffer' now works correctly with
>> +buffer-local variables. This means that different buffers can have
>> +their own separated input history list if desired.
>
> This should probably be documented in the manual, too?
>
> The patch otherwise looks good to me.
Thanks. In what part of the manual would you document this? I was
thinking of either in:
1) The "Minibuffer History" section (but it doesn't mention the actual
HIST variable anywhere in there, though, and never mentions any specific
minibuffer-reading function)
2) In "Reading Text Strings with the Minibuffer", in the entry for
`read-from-minibuffer' (right before the link to "Minibuffer
History"). Maybe if we add it there users can then infer that other
minibuffer commands with a HIST argument also accept buffer-local
values.
Should I update the docstring for `read-from-minibuffer' as well? I
would like to add two things: that the value can be buffer-local, and
that the newly read item will be added to the history list. IMO this
wasn't clear enough so I ended up calling `add-to-history' myself, which
was redundant since `read_minibuf' does that already.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#38317
; Package
emacs
.
(Wed, 27 Nov 2019 19:25:01 GMT)
Full text and
rfc822 format available.
Message #44 received at 38317 <at> debbugs.gnu.org (full text, mbox):
> From: Federico Tedin <federicotedin <at> gmail.com>
> Date: Wed, 27 Nov 2019 19:50:00 +0100
> Cc: 38317 <at> debbugs.gnu.org
>
> Thanks. In what part of the manual would you document this? I was
> thinking of either in:
>
> 1) The "Minibuffer History" section (but it doesn't mention the actual
> HIST variable anywhere in there, though, and never mentions any specific
> minibuffer-reading function)
That section does mention the history variables, and even includes a
list of them. So I'm not sure why you say it doesn't.
> Should I update the docstring for `read-from-minibuffer' as well? I
> would like to add two things: that the value can be buffer-local, and
> that the newly read item will be added to the history list.
That it adds to the history is worth mentioning, but the fact that it
can be buffer-local we don't normally say explicitly, because it's
expected to "just work".
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#38317
; Package
emacs
.
(Wed, 27 Nov 2019 21:05:01 GMT)
Full text and
rfc822 format available.
Message #47 received at 38317 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
> That section does mention the history variables, and even includes a
> list of them. So I'm not sure why you say it doesn't.
You're right, I was looking at the Emacs manual instead of the Elisp
manual (the sections have the same title). I can see that the Elisp manual is
more specific about the history list variable. I could mention the
possibility of using a buffer-local variable there.
> That it adds to the history is worth mentioning, but the fact that it
> can be buffer-local we don't normally say explicitly, because it's
> expected to "just work".
Ok, thanks.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#38317
; Package
emacs
.
(Wed, 27 Nov 2019 21:56:02 GMT)
Full text and
rfc822 format available.
Message #50 received at 38317 <at> debbugs.gnu.org (full text, mbox):
> I'm now attaching a final version of my patch.
>
> I've tested the following commands with it, using `read-from-minibuffer'
> with a buffer-local HIST:
>
> - previous-history-element (M-p)
> - next-history-element (M-n)
> - previous-matching-history-element (M-r)
> - next-matching-history-element (M-s)
> - isearch-forward (C-s)
> - isearch-backward (C-r)
Thanks, only one question about the function name:
> +(defun minibuffer-history-values ()
> + "Return the minibuffer input history values.
Why "values" in the plural form? This looks like a multivalued function.
It would be more clear with a singular "value".
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#38317
; Package
emacs
.
(Thu, 28 Nov 2019 12:06:02 GMT)
Full text and
rfc822 format available.
Message #53 received at 38317 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
I'm now attaching a new patch with feedback corrections from everyone in
the thread (threads?).
[minibuffer.patch (text/x-diff, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#38317
; Package
emacs
.
(Fri, 29 Nov 2019 05:23:02 GMT)
Full text and
rfc822 format available.
Message #56 received at 38317 <at> debbugs.gnu.org (full text, mbox):
[[[ To any NSA and FBI agents reading my email: please consider ]]]
[[[ whether defending the US Constitution against all enemies, ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]
> You're right, I was looking at the Emacs manual instead of the Elisp
> manual (the sections have the same title). I can see that the Elisp manual is
> more specific about the history list variable. I could mention the
> possibility of using a buffer-local variable there.
Since the two sections have the same name, would it be helpful to give
the Emacs Manual section a cross reference to the Elisp Manual section?
Perhaps, "See also the section of the same name, @xref{...}."
--
Dr Richard Stallman
Founder, Free Software Foundation (https://gnu.org, https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#38317
; Package
emacs
.
(Fri, 29 Nov 2019 10:22:02 GMT)
Full text and
rfc822 format available.
Message #59 received at 38317 <at> debbugs.gnu.org (full text, mbox):
> From: Richard Stallman <rms <at> gnu.org>
> Cc: eliz <at> gnu.org, larsi <at> gnus.org, 38317 <at> debbugs.gnu.org
> Date: Fri, 29 Nov 2019 00:22:21 -0500
>
> Since the two sections have the same name, would it be helpful to give
> the Emacs Manual section a cross reference to the Elisp Manual section?
> Perhaps, "See also the section of the same name, @xref{...}."
They have identical names, but discuss radically different subjects.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#38317
; Package
emacs
.
(Fri, 29 Nov 2019 17:03:02 GMT)
Full text and
rfc822 format available.
Message #62 received at 38317 <at> debbugs.gnu.org (full text, mbox):
>> Since the two sections have the same name, would it be helpful to give
>> the Emacs Manual section a cross reference to the Elisp Manual section?
>> Perhaps, "See also the section of the same name, @xref{...}."
>
> They have identical names, but discuss radically different subjects.
Would the following titles make sense?
emacs/Minibuffer History -> emacs/Minibuffer History Variable[s]
elisp/Minibuffer History -> elisp/Navigating the Minibuffer History
elisp/Minibuffer History -> elisp/Minibuffer History Commands
Obviously it's an unimportant thing to change, but I think it would help
users searching for "emacs minibuffer history" on the Internet.
- Fede
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#38317
; Package
emacs
.
(Sun, 01 Dec 2019 06:00:02 GMT)
Full text and
rfc822 format available.
Message #65 received at 38317 <at> debbugs.gnu.org (full text, mbox):
[[[ To any NSA and FBI agents reading my email: please consider ]]]
[[[ whether defending the US Constitution against all enemies, ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]
> Since the two sections have the same name, would it be helpful to give
> the Emacs Manual section a cross reference to the Elisp Manual section?
> Perhaps, "See also the section of the same name, @xref{...}."
Someone responded that the two sections are not about the same topic.
It may nonetheless be useful to make each one mention the other
in a notice to prevent this kind of confusion.
--
Dr Richard Stallman
Founder, Free Software Foundation (https://gnu.org, https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#38317
; Package
emacs
.
(Thu, 05 Dec 2019 09:32:02 GMT)
Full text and
rfc822 format available.
Message #68 received at 38317 <at> debbugs.gnu.org (full text, mbox):
Federico Tedin <federicotedin <at> gmail.com> writes:
> I'm now attaching a new patch with feedback corrections from everyone in
> the thread (threads?).
Looks good to me, and after some cursory testing I've applied this to
Emacs 27.
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
Added tag(s) fixed.
Request was from
Lars Ingebrigtsen <larsi <at> gnus.org>
to
control <at> debbugs.gnu.org
.
(Thu, 05 Dec 2019 09:32:03 GMT)
Full text and
rfc822 format available.
bug marked as fixed in version 27.1, send any further explanations to
38317 <at> debbugs.gnu.org and Federico Tedin <federicotedin <at> gmail.com>
Request was from
Lars Ingebrigtsen <larsi <at> gnus.org>
to
control <at> debbugs.gnu.org
.
(Thu, 05 Dec 2019 09:32:03 GMT)
Full text and
rfc822 format available.
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org
.
(Thu, 02 Jan 2020 12:24:04 GMT)
Full text and
rfc822 format available.
This bug report was last modified 5 years and 166 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.