GNU bug report logs - #38317
Buffer-local variables don't work as history for read-from-minibuffer

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 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.

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

From: Federico Tedin <federicotedin <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: Buffer-local variables don't work as history for read-from-minibuffer
Date: Thu, 21 Nov 2019 22:30:29 +0100

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

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

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Federico Tedin <federicotedin <at> gmail.com>
Cc: 38317 <at> debbugs.gnu.org
Subject: Re: bug#38317: Buffer-local variables don't work as history for
 read-from-minibuffer
Date: Fri, 22 Nov 2019 14:33:51 +0100

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

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

From: Michael Heerdegen <michael_heerdegen <at> web.de>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: 38317 <at> debbugs.gnu.org, Federico Tedin <federicotedin <at> gmail.com>
Subject: Re: bug#38317: Buffer-local variables don't work as history for
 read-from-minibuffer
Date: Fri, 22 Nov 2019 16:23:49 +0100

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.

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

From: martin rudalics <rudalics <at> gmx.at>
To: Lars Ingebrigtsen <larsi <at> gnus.org>,
 Federico Tedin <federicotedin <at> gmail.com>
Cc: 38317 <at> debbugs.gnu.org
Subject: Re: bug#38317: Buffer-local variables don't work as history for
 read-from-minibuffer
Date: Fri, 22 Nov 2019 17:24:22 +0100

> 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

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

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: martin rudalics <rudalics <at> gmx.at>
Cc: 38317 <at> debbugs.gnu.org, Federico Tedin <federicotedin <at> gmail.com>
Subject: Re: bug#38317: Buffer-local variables don't work as history for
 read-from-minibuffer
Date: Sat, 23 Nov 2019 12:54:38 +0100

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

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

From: Federico Tedin <federicotedin <at> gmail.com>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: martin rudalics <rudalics <at> gmx.at>, 38317 <at> debbugs.gnu.org
Subject: Re: bug#38317: Buffer-local variables don't work as history for
 read-from-minibuffer
Date: Sat, 23 Nov 2019 21:36:10 +0100

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.

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

From: Federico Tedin <federicotedin <at> gmail.com>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: martin rudalics <rudalics <at> gmx.at>, 38317 <at> debbugs.gnu.org
Subject: Re: bug#38317: Buffer-local variables don't work as history for
 read-from-minibuffer
Date: Sun, 24 Nov 2019 00:12:15 +0100

[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)]

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

From: Federico Tedin <federicotedin <at> gmail.com>
To: 38317 <at> debbugs.gnu.org
Cc: martin rudalics <rudalics <at> gmx.at>, Lars Ingebrigtsen <larsi <at> gnus.org>
Subject: Re: bug#38317: Buffer-local variables don't work as history for
 read-from-minibuffer
Date: Tue, 26 Nov 2019 22:54:29 +0100

[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)]

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

From: Robert Pluim <rpluim <at> gmail.com>
To: Federico Tedin <federicotedin <at> gmail.com>
Cc: Lars Ingebrigtsen <larsi <at> gnus.org>, 38317 <at> debbugs.gnu.org
Subject: Re: bug#38317: Buffer-local variables don't work as history for
 read-from-minibuffer
Date: Wed, 27 Nov 2019 09:14:13 +0100

>>>>> 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

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

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Federico Tedin <federicotedin <at> gmail.com>
Cc: martin rudalics <rudalics <at> gmx.at>, 38317 <at> debbugs.gnu.org
Subject: Re: bug#38317: Buffer-local variables don't work as history for
 read-from-minibuffer
Date: Wed, 27 Nov 2019 12:53:23 +0100

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

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

From: Drew Adams <drew.adams <at> oracle.com>
To: Robert Pluim <rpluim <at> gmail.com>, Federico Tedin <federicotedin <at> gmail.com>
Cc: Lars Ingebrigtsen <larsi <at> gnus.org>, 38317 <at> debbugs.gnu.org
Subject: RE: bug#38317: Buffer-local variables don't work as history for
 read-from-minibuffer
Date: Wed, 27 Nov 2019 07:24:46 -0800 (PST)

> "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.

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

From: Robert Pluim <rpluim <at> gmail.com>
To: Drew Adams <drew.adams <at> oracle.com>
Cc: Lars Ingebrigtsen <larsi <at> gnus.org>, 38317 <at> debbugs.gnu.org,
 Federico Tedin <federicotedin <at> gmail.com>
Subject: Re: bug#38317: Buffer-local variables don't work as history for
 read-from-minibuffer
Date: Wed, 27 Nov 2019 16:28:09 +0100

>>>>> 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

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

From: Federico Tedin <federicotedin <at> gmail.com>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: martin rudalics <rudalics <at> gmx.at>, 38317 <at> debbugs.gnu.org
Subject: Re: bug#38317: Buffer-local variables don't work as history for
 read-from-minibuffer
Date: Wed, 27 Nov 2019 19:50:00 +0100

> 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.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Federico Tedin <federicotedin <at> gmail.com>
Cc: larsi <at> gnus.org, 38317 <at> debbugs.gnu.org
Subject: Re: bug#38317: Buffer-local variables don't work as history for
 read-from-minibuffer
Date: Wed, 27 Nov 2019 21:25:00 +0200

> 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".

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

From: Federico Tedin <federicotedin <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: larsi <at> gnus.org, 38317 <at> debbugs.gnu.org
Subject: Re: bug#38317: Buffer-local variables don't work as history for
 read-from-minibuffer
Date: Wed, 27 Nov 2019 22:04:31 +0100

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.

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

From: Juri Linkov <juri <at> linkov.net>
To: Federico Tedin <federicotedin <at> gmail.com>
Cc: Lars Ingebrigtsen <larsi <at> gnus.org>, 38317 <at> debbugs.gnu.org
Subject: Re: bug#38317: Buffer-local variables don't work as history for
 read-from-minibuffer
Date: Wed, 27 Nov 2019 23:19:11 +0200

> 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".

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

From: Federico Tedin <federicotedin <at> gmail.com>
To: 38317 <at> debbugs.gnu.org
Cc: larsi <at> gnus.org, Eli Zaretskii <eliz <at> gnu.org>
Subject: Re: bug#38317: Buffer-local variables don't work as history for
 read-from-minibuffer
Date: Thu, 28 Nov 2019 13:05:40 +0100

[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)]

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

From: Richard Stallman <rms <at> gnu.org>
To: Federico Tedin <federicotedin <at> gmail.com>
Cc: eliz <at> gnu.org, 38317 <at> debbugs.gnu.org, larsi <at> gnus.org
Subject: Re: bug#38317: Buffer-local variables don't work as history for
 read-from-minibuffer
Date: Fri, 29 Nov 2019 00:22:21 -0500

[[[ 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)

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: rms <at> gnu.org
Cc: larsi <at> gnus.org, 38317 <at> debbugs.gnu.org, federicotedin <at> gmail.com
Subject: Re: bug#38317: Buffer-local variables don't work as history for
 read-from-minibuffer
Date: Fri, 29 Nov 2019 12:21:44 +0200

> 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.

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

From: Federico Tedin <federicotedin <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: larsi <at> gnus.org, 38317 <at> debbugs.gnu.org, rms <at> gnu.org
Subject: Re: bug#38317: Buffer-local variables don't work as history for
 read-from-minibuffer
Date: Fri, 29 Nov 2019 18:02:23 +0100

>> 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

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

From: Richard Stallman <rms <at> gnu.org>
To: federicotedin <at> gmail.com, 38317 <at> debbugs.gnu.org, larsi <at> gnus.org
Subject: Re: bug#38317: Buffer-local variables don't work as history for
 read-from-minibuffer
Date: Sun, 01 Dec 2019 00:59:39 -0500

[[[ 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)

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

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Federico Tedin <federicotedin <at> gmail.com>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 38317 <at> debbugs.gnu.org
Subject: Re: bug#38317: Buffer-local variables don't work as history for
 read-from-minibuffer
Date: Thu, 05 Dec 2019 10:31:15 +0100

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

Previous Next

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