* bug#38282: 26.3; goto-line should not share input history with other commands
@ 2019-11-19 21:48 Federico Tedin
2019-11-21 13:51 ` Lars Ingebrigtsen
0 siblings, 1 reply; 18+ messages in thread
From: Federico Tedin @ 2019-11-19 21:48 UTC (permalink / raw)
To: 38282
Severity: wishlist
When using goto-line (M-g M-g), I usually tend to jump to lines which I
have jumped to in the past. Because goto-line shares input history with
other commands (like `read-from-minibuffer'), sometimes these numbers
get buried among strings that I have entered for other commands. I think
it would make sense to give goto-line a separate input history to make
finding past lines easier.
^ permalink raw reply [flat|nested] 18+ messages in thread
* bug#38282: 26.3; goto-line should not share input history with other commands
2019-11-19 21:48 bug#38282: 26.3; goto-line should not share input history with other commands Federico Tedin
@ 2019-11-21 13:51 ` Lars Ingebrigtsen
2019-11-21 14:41 ` Robert Pluim
0 siblings, 1 reply; 18+ messages in thread
From: Lars Ingebrigtsen @ 2019-11-21 13:51 UTC (permalink / raw)
To: Federico Tedin; +Cc: 38282
Federico Tedin <federicotedin@gmail.com> writes:
> When using goto-line (M-g M-g), I usually tend to jump to lines which I
> have jumped to in the past. Because goto-line shares input history with
> other commands (like `read-from-minibuffer'), sometimes these numbers
> get buried among strings that I have entered for other commands. I think
> it would make sense to give goto-line a separate input history to make
> finding past lines easier.
Yes, the Emacs behaviour here has annoyed me, too.
`goto-line' basically just calls `read-number' (which calls
`read-from-minibuffer' with the "default" nil history) -- I wonder
whether it would make sense to have a separate history for `read-number'
so that all numbers that are read share a history? Or is that too
drastic?
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
^ permalink raw reply [flat|nested] 18+ messages in thread
* bug#38282: 26.3; goto-line should not share input history with other commands
2019-11-21 13:51 ` Lars Ingebrigtsen
@ 2019-11-21 14:41 ` Robert Pluim
2019-11-21 15:20 ` Michael Albinus
0 siblings, 1 reply; 18+ messages in thread
From: Robert Pluim @ 2019-11-21 14:41 UTC (permalink / raw)
To: Lars Ingebrigtsen; +Cc: 38282, Federico Tedin
>>>>> On Thu, 21 Nov 2019 14:51:18 +0100, Lars Ingebrigtsen <larsi@gnus.org> said:
Lars> Federico Tedin <federicotedin@gmail.com> writes:
>> When using goto-line (M-g M-g), I usually tend to jump to lines which I
>> have jumped to in the past. Because goto-line shares input history with
>> other commands (like `read-from-minibuffer'), sometimes these numbers
>> get buried among strings that I have entered for other commands. I think
>> it would make sense to give goto-line a separate input history to make
>> finding past lines easier.
Lars> Yes, the Emacs behaviour here has annoyed me, too.
Lars> `goto-line' basically just calls `read-number' (which calls
Lars> `read-from-minibuffer' with the "default" nil history) -- I wonder
Lars> whether it would make sense to have a separate history for `read-number'
Lars> so that all numbers that are read share a history? Or is that too
Lars> drastic?
If debbugs-gnu-bugs et al uses read-number, Iʼm all in favour.
Robert
^ permalink raw reply [flat|nested] 18+ messages in thread
* bug#38282: 26.3; goto-line should not share input history with other commands
2019-11-21 14:41 ` Robert Pluim
@ 2019-11-21 15:20 ` Michael Albinus
2019-11-21 17:51 ` Lars Ingebrigtsen
0 siblings, 1 reply; 18+ messages in thread
From: Michael Albinus @ 2019-11-21 15:20 UTC (permalink / raw)
To: Robert Pluim; +Cc: Lars Ingebrigtsen, 38282, Federico Tedin
Robert Pluim <rpluim@gmail.com> writes:
> If debbugs-gnu-bugs et al uses read-number, Iʼm all in favour.
If you could marry read-number and completing-read-multiple - patches
welcome :-)
(Maybe it is sufficient to tweak HIST in the completing-read-multiple call).
> Robert
Best regards, Michael.
^ permalink raw reply [flat|nested] 18+ messages in thread
* bug#38282: 26.3; goto-line should not share input history with other commands
2019-11-21 15:20 ` Michael Albinus
@ 2019-11-21 17:51 ` Lars Ingebrigtsen
2019-11-21 18:43 ` Federico Tedin
2019-11-22 7:57 ` Michael Albinus
0 siblings, 2 replies; 18+ messages in thread
From: Lars Ingebrigtsen @ 2019-11-21 17:51 UTC (permalink / raw)
To: Michael Albinus; +Cc: Robert Pluim, 38282, Federico Tedin
Michael Albinus <michael.albinus@gmx.de> writes:
> Robert Pluim <rpluim@gmail.com> writes:
>
>> If debbugs-gnu-bugs et al uses read-number, Iʼm all in favour.
>
> If you could marry read-number and completing-read-multiple - patches
> welcome :-)
Hm. I've never looked at completing-read-multiple before (I didn't know
that it existed), but I don't see the connection?
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
^ permalink raw reply [flat|nested] 18+ messages in thread
* bug#38282: 26.3; goto-line should not share input history with other commands
2019-11-21 17:51 ` Lars Ingebrigtsen
@ 2019-11-21 18:43 ` Federico Tedin
2019-11-21 22:06 ` Federico Tedin
2019-11-22 7:57 ` Michael Albinus
1 sibling, 1 reply; 18+ messages in thread
From: Federico Tedin @ 2019-11-21 18:43 UTC (permalink / raw)
To: Lars Ingebrigtsen; +Cc: Michael Albinus, Robert Pluim, 38282
> Yes, the Emacs behaviour here has annoyed me, too.
> `goto-line' basically just calls `read-number' (which calls
> `read-from-minibuffer' with the "default" nil history) -- I wonder
> whether it would make sense to have a separate history for `read-number'
> so that all numbers that are read share a history? Or is that too
> drastic?
I started working on this yesterday! My initial plan was to have a
separate history for `read-number', and then I thought that it might be
even better to have the history be buffer-local as well; because line
numbers from one buffer don't really make sense on another.
After I tried some stuff I came across a problem and posted it on the
Emacs SO:
https://emacs.stackexchange.com/questions/53892/buffer-local-input-history-for-read-from-minibuffer
It seems like `read-from-minibuffer' doesn't like having its HIST
parameter be buffer-local (but I may have misunderstood the problem).
I'm going to look into it more on depth these days.
^ permalink raw reply [flat|nested] 18+ messages in thread
* bug#38282: 26.3; goto-line should not share input history with other commands
2019-11-21 18:43 ` Federico Tedin
@ 2019-11-21 22:06 ` Federico Tedin
2019-11-22 7:35 ` Eli Zaretskii
2019-11-22 12:09 ` Lars Ingebrigtsen
0 siblings, 2 replies; 18+ messages in thread
From: Federico Tedin @ 2019-11-21 22:06 UTC (permalink / raw)
To: Lars Ingebrigtsen; +Cc: 38282, Robert Pluim, Michael Albinus
[-- Attachment #1: Type: text/plain, Size: 472 bytes --]
> It seems like `read-from-minibuffer' doesn't like having its HIST
> parameter be buffer-local (but I may have misunderstood the problem).
> I'm going to look into it more on depth these days.
Here's my first attempt at implementing this - I managed to get around
the `read-from-minibuffer' problem with some help from the Emacs
StackOverflow (but created a separate bug report for it:
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=38317). I'm attaching a
small patch.
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: patch --]
[-- Type: text/x-diff, Size: 2882 bytes --]
From 3994fa53d0cf210e7f109dc2059ee78a96215547 Mon Sep 17 00:00:00 2001
From: Federico Tedin <federicotedin@gmail.com>
Date: Thu, 21 Nov 2019 23:01:23 +0100
Subject: [PATCH 1/1] Make input history buffer-local for 'goto-line'
* lisp/simple.el (goto-line-history): New buffer-local variable which
holds the input history for 'goto-line'.
(goto-line): Use the new variable as input history (Bug#38282).
* etc/NEWS: Announce changes.
---
etc/NEWS | 5 +++++
lisp/simple.el | 19 +++++++++++++++++--
2 files changed, 22 insertions(+), 2 deletions(-)
diff --git a/etc/NEWS b/etc/NEWS
index 7a51106add..0bbb40dfa2 100644
--- a/etc/NEWS
+++ b/etc/NEWS
@@ -589,6 +589,11 @@ If the region is active, the command joins all the lines in the
region. When there's no active region, the command works on the
current and the previous or the next line, as before.
+---
+** 'goto-line' now keeps a separate input history for each buffer.
+Additionally, the line number input history will be kept separate from
+the input history for other commands.
+
\f
* Changes in Specialized Modes and Packages in Emacs 27.1
diff --git a/lisp/simple.el b/lisp/simple.el
index c61ccd511c..dd8e8a291a 100644
--- a/lisp/simple.el
+++ b/lisp/simple.el
@@ -1212,6 +1212,11 @@ mark-whole-buffer
;; Counting lines, one way or another.
+(defvar goto-line-history nil
+ "Input history for `goto-line'.")
+
+(make-variable-buffer-local 'goto-line-history)
+
(defun goto-line (line &optional buffer)
"Go to LINE, counting from line 1 at beginning of buffer.
If called interactively, a numeric prefix argument specifies
@@ -1253,7 +1258,14 @@ goto-line
(buffer-prompt
(if buffer
(concat " in " (buffer-name buffer))
- "")))
+ ""))
+ ;; It would be better to use `goto-line-history' as a HIST
+ ;; parameter to `read-from-minibuffer' (through
+ ;; `read-number'), but using buffer-local variables
+ ;; doesn't work for that purpose. (Bug#38317)
+ (minibuffer-history
+ (buffer-local-value 'goto-line-history (or buffer
+ (current-buffer)))))
;; Read the argument, offering that number (if any) as default.
(list (read-number (format "Goto line%s: " buffer-prompt)
(list default (line-number-at-pos)))
@@ -1271,7 +1283,10 @@ goto-line
(goto-char (point-min))
(if (eq selective-display t)
(re-search-forward "[\n\C-m]" nil 'end (1- line))
- (forward-line (1- line)))))
+ (forward-line (1- line))))
+ ;; Save the line number in the input history list.
+ (with-current-buffer (or buffer (current-buffer))
+ (add-to-history 'goto-line-history (int-to-string line))))
(defun count-words-region (start end &optional arg)
"Count the number of words in the region.
--
2.17.1
^ permalink raw reply related [flat|nested] 18+ messages in thread
* bug#38282: 26.3; goto-line should not share input history with other commands
2019-11-21 22:06 ` Federico Tedin
@ 2019-11-22 7:35 ` Eli Zaretskii
2019-11-22 12:09 ` Lars Ingebrigtsen
1 sibling, 0 replies; 18+ messages in thread
From: Eli Zaretskii @ 2019-11-22 7:35 UTC (permalink / raw)
To: Federico Tedin; +Cc: 38282, larsi, michael.albinus, rpluim
> From: Federico Tedin <federicotedin@gmail.com>
> Date: Thu, 21 Nov 2019 23:06:14 +0100
> Cc: 38282@debbugs.gnu.org, Robert Pluim <rpluim@gmail.com>,
> Michael Albinus <michael.albinus@gmx.de>
>
> Here's my first attempt at implementing this - I managed to get around
> the `read-from-minibuffer' problem with some help from the Emacs
> StackOverflow (but created a separate bug report for it:
> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=38317). I'm attaching a
> small patch.
Thanks, but please also update the ELisp manual, where the history
variables are documented in "Minibuffer History".
^ permalink raw reply [flat|nested] 18+ messages in thread
* bug#38282: 26.3; goto-line should not share input history with other commands
2019-11-21 17:51 ` Lars Ingebrigtsen
2019-11-21 18:43 ` Federico Tedin
@ 2019-11-22 7:57 ` Michael Albinus
2019-11-22 8:40 ` Robert Pluim
1 sibling, 1 reply; 18+ messages in thread
From: Michael Albinus @ 2019-11-22 7:57 UTC (permalink / raw)
To: Lars Ingebrigtsen; +Cc: Robert Pluim, 38282, Federico Tedin
Lars Ingebrigtsen <larsi@gnus.org> writes:
>>> If debbugs-gnu-bugs et al uses read-number, Iʼm all in favour.
>>
>> If you could marry read-number and completing-read-multiple - patches
>> welcome :-)
>
> Hm. I've never looked at completing-read-multiple before (I didn't know
> that it existed), but I don't see the connection?
debbugs-gnu-bugs uses completing-read-multiple, Robert has asked to use
read-number there. That's why I've mentioned it.
Best regards, Michael.
^ permalink raw reply [flat|nested] 18+ messages in thread
* bug#38282: 26.3; goto-line should not share input history with other commands
2019-11-22 7:57 ` Michael Albinus
@ 2019-11-22 8:40 ` Robert Pluim
0 siblings, 0 replies; 18+ messages in thread
From: Robert Pluim @ 2019-11-22 8:40 UTC (permalink / raw)
To: Michael Albinus; +Cc: Lars Ingebrigtsen, 38282, Federico Tedin
>>>>> On Fri, 22 Nov 2019 08:57:52 +0100, Michael Albinus <michael.albinus@gmx.de> said:
Michael> Lars Ingebrigtsen <larsi@gnus.org> writes:
>>>> If debbugs-gnu-bugs et al uses read-number, Iʼm all in favour.
>>>
>>> If you could marry read-number and completing-read-multiple - patches
>>> welcome :-)
>>
>> Hm. I've never looked at completing-read-multiple before (I didn't know
>> that it existed), but I don't see the connection?
Michael> debbugs-gnu-bugs uses completing-read-multiple, Robert has asked to use
Michael> read-number there. That's why I've mentioned it.
Well, I assumed it did. But it doesnʼt.
Robert
^ permalink raw reply [flat|nested] 18+ messages in thread
* bug#38282: 26.3; goto-line should not share input history with other commands
2019-11-21 22:06 ` Federico Tedin
2019-11-22 7:35 ` Eli Zaretskii
@ 2019-11-22 12:09 ` Lars Ingebrigtsen
2019-11-23 17:05 ` Federico Tedin
1 sibling, 1 reply; 18+ messages in thread
From: Lars Ingebrigtsen @ 2019-11-22 12:09 UTC (permalink / raw)
To: Federico Tedin; +Cc: 38282, Robert Pluim, Michael Albinus
Federico Tedin <federicotedin@gmail.com> writes:
> + ;; It would be better to use `goto-line-history' as a HIST
> + ;; parameter to `read-from-minibuffer' (through
> + ;; `read-number'), but using buffer-local variables
> + ;; doesn't work for that purpose. (Bug#38317)
> + (minibuffer-history
> + (buffer-local-value 'goto-line-history (or buffer
> + (current-buffer)))))
I think a per-buffer history for goto-line makes sense, but I was also
wondering whether read-number should have its own separate history, too.
This would, I think, not interoperate well with that (that is, if
`read-number' passes a different variable to read-from-minibuffer than
nil).
So I think a better solution would be to fix the problem with
buffer-local variables not working in read-from-minibuffer first, and
then we could extend read-number with a history parameter instead of
hacking around the problem this way.
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
^ permalink raw reply [flat|nested] 18+ messages in thread
* bug#38282: 26.3; goto-line should not share input history with other commands
2019-11-22 12:09 ` Lars Ingebrigtsen
@ 2019-11-23 17:05 ` Federico Tedin
2019-11-27 11:48 ` Lars Ingebrigtsen
0 siblings, 1 reply; 18+ messages in thread
From: Federico Tedin @ 2019-11-23 17:05 UTC (permalink / raw)
To: Lars Ingebrigtsen; +Cc: 38282
> I think a per-buffer history for goto-line makes sense, but I was also
> wondering whether read-number should have its own separate history, too.
>
> This would, I think, not interoperate well with that (that is, if
> `read-number' passes a different variable to read-from-minibuffer than
> nil).
>
> So I think a better solution would be to fix the problem with
> buffer-local variables not working in read-from-minibuffer first, and
> then we could extend read-number with a history parameter instead of
> hacking around the problem this way.
No problem, I'll take a shot at solving the `read-from-minubuffer'
issue first.
After that's done, and after adding the HIST parameter to `read-number',
what should happen if `read-number' is called with HIST as nil? Should
it use its own history variable? (Which probably won't be buffer-local,
I imagine)
^ permalink raw reply [flat|nested] 18+ messages in thread
* bug#38282: 26.3; goto-line should not share input history with other commands
2019-11-23 17:05 ` Federico Tedin
@ 2019-11-27 11:48 ` Lars Ingebrigtsen
2019-12-06 22:14 ` Federico Tedin
0 siblings, 1 reply; 18+ messages in thread
From: Lars Ingebrigtsen @ 2019-11-27 11:48 UTC (permalink / raw)
To: Federico Tedin; +Cc: 38282
Federico Tedin <federicotedin@gmail.com> writes:
> After that's done, and after adding the HIST parameter to `read-number',
> what should happen if `read-number' is called with HIST as nil? Should
> it use its own history variable? (Which probably won't be buffer-local,
> I imagine)
I think it makes sense for read-number to use its own history variable,
but it should not be buffer local. Most inputs are not naturally buffer
local.
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
^ permalink raw reply [flat|nested] 18+ messages in thread
* bug#38282: 26.3; goto-line should not share input history with other commands
2019-11-27 11:48 ` Lars Ingebrigtsen
@ 2019-12-06 22:14 ` Federico Tedin
2019-12-14 11:44 ` Eli Zaretskii
0 siblings, 1 reply; 18+ messages in thread
From: Federico Tedin @ 2019-12-06 22:14 UTC (permalink / raw)
To: Lars Ingebrigtsen; +Cc: 38282
[-- Attachment #1: Type: text/plain, Size: 316 bytes --]
> I think it makes sense for read-number to use its own history variable,
> but it should not be buffer local. Most inputs are not naturally buffer
> local.
No problem - I've added an input history variable for `read-number', and
a buffer-local one for `goto-line'. I'm attaching a patch with my
changes.
- Fede
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: patch --]
[-- Type: text/x-diff, Size: 2720 bytes --]
From 249ccb59be23d94018a01b4f8b1577356732d1da Mon Sep 17 00:00:00 2001
From: Federico Tedin <federicotedin@gmail.com>
Date: Fri, 6 Dec 2019 23:07:27 +0100
Subject: [PATCH 1/1] Make goto-line keep a separate input history per buffer
* lisp/simple.el (goto-line-history): New history variable.
(goto-line): Use new (buffer-local) variable as input history.
* lisp/subr.el (read-number-history): New history variable.
(read-number): Use the new variable as default input history.
---
lisp/simple.el | 7 ++++++-
lisp/subr.el | 9 +++++++--
2 files changed, 13 insertions(+), 3 deletions(-)
diff --git a/lisp/simple.el b/lisp/simple.el
index 67ddab3d34..c14718de1c 100644
--- a/lisp/simple.el
+++ b/lisp/simple.el
@@ -1212,6 +1212,10 @@ mark-whole-buffer
;; Counting lines, one way or another.
+(defvar goto-line-history nil
+ "History of values entered with `goto-line'.")
+(make-variable-buffer-local 'goto-line-history)
+
(defun goto-line (line &optional buffer)
"Go to LINE, counting from line 1 at beginning of buffer.
If called interactively, a numeric prefix argument specifies
@@ -1256,7 +1260,8 @@ goto-line
"")))
;; Read the argument, offering that number (if any) as default.
(list (read-number (format "Goto line%s: " buffer-prompt)
- (list default (line-number-at-pos)))
+ (list default (line-number-at-pos))
+ 'goto-line-history)
buffer))))
;; Switch to the desired buffer, one way or another.
(if buffer
diff --git a/lisp/subr.el b/lisp/subr.el
index de7d919abf..8f7a9128fa 100644
--- a/lisp/subr.el
+++ b/lisp/subr.el
@@ -2518,10 +2518,15 @@ read-passwd
;; And of course, don't keep the sensitive data around.
(erase-buffer))))))))
-(defun read-number (prompt &optional default)
+(defvar read-number-history nil
+ "The default history for the `read-number' function.")
+
+(defun read-number (prompt &optional default hist)
"Read a numeric value in the minibuffer, prompting with PROMPT.
DEFAULT specifies a default value to return if the user just types RET.
The value of DEFAULT is inserted into PROMPT.
+HIST specifies a history list variable. See `read-from-minibuffer'
+for details of the HIST argument.
This function is used by the `interactive' code letter `n'."
(let ((n nil)
(default1 (if (consp default) (car default) default)))
@@ -2535,7 +2540,7 @@ read-number
(while
(progn
(let ((str (read-from-minibuffer
- prompt nil nil nil nil
+ prompt nil nil nil (or hist 'read-number-history)
(when default
(if (consp default)
(mapcar 'number-to-string (delq nil default))
--
2.17.1
^ permalink raw reply related [flat|nested] 18+ messages in thread
* bug#38282: 26.3; goto-line should not share input history with other commands
2019-12-06 22:14 ` Federico Tedin
@ 2019-12-14 11:44 ` Eli Zaretskii
2019-12-17 21:19 ` Federico Tedin
0 siblings, 1 reply; 18+ messages in thread
From: Eli Zaretskii @ 2019-12-14 11:44 UTC (permalink / raw)
To: Federico Tedin; +Cc: larsi, 38282
> From: Federico Tedin <federicotedin@gmail.com>
> Date: Fri, 06 Dec 2019 23:14:15 +0100
> Cc: 38282@debbugs.gnu.org
>
> > I think it makes sense for read-number to use its own history variable,
> > but it should not be buffer local. Most inputs are not naturally buffer
> > local.
>
> No problem - I've added an input history variable for `read-number', and
> a buffer-local one for `goto-line'. I'm attaching a patch with my
> changes.
Thanks, I think this variable should be mentioned in the ELisp manual
(in the "Minibuffer History" node) and in NEWS.
^ permalink raw reply [flat|nested] 18+ messages in thread
* bug#38282: 26.3; goto-line should not share input history with other commands
2019-12-14 11:44 ` Eli Zaretskii
@ 2019-12-17 21:19 ` Federico Tedin
2019-12-24 16:39 ` Lars Ingebrigtsen
0 siblings, 1 reply; 18+ messages in thread
From: Federico Tedin @ 2019-12-17 21:19 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: larsi, 38282
[-- Attachment #1: Type: text/plain, Size: 273 bytes --]
> Thanks, I think this variable should be mentioned in the ELisp manual
> (in the "Minibuffer History" node) and in NEWS.
Sorry, forgot to do that. I've now documented both new variables (the
one for `read-number' and the one for `goto-line'). I'm attaching a new
patch.
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: patch --]
[-- Type: text/x-diff, Size: 4406 bytes --]
From 67e2d243473c52c1b52102203cf069dbed4165cc Mon Sep 17 00:00:00 2001
From: Federico Tedin <federicotedin@gmail.com>
Date: Tue, 17 Dec 2019 22:13:55 +0100
Subject: [PATCH 1/1] Make goto-line keep a separate input history per buffer
* lisp/simple.el (goto-line-history): New history variable.
(goto-line): Use new (buffer-local) variable as input
history (Bug#38282).
* lisp/subr.el (read-number-history): New history variable.
(read-number): Use the new variable as default input history.
* doc/lispref/minibuf.texi (Minibuffer History): Document
read-number-history and goto-line-history variables.
* etc/NEWS: Announce changes.
---
doc/lispref/minibuf.texi | 9 +++++++++
etc/NEWS | 11 +++++++++++
lisp/simple.el | 7 ++++++-
lisp/subr.el | 9 +++++++--
4 files changed, 33 insertions(+), 3 deletions(-)
diff --git a/doc/lispref/minibuf.texi b/doc/lispref/minibuf.texi
index dde30ce67f..2c2ef9747b 100644
--- a/doc/lispref/minibuf.texi
+++ b/doc/lispref/minibuf.texi
@@ -645,6 +645,15 @@ Minibuffer History
@code{read-variable}.
@end defvar
+@defvar read-number-history
+A history list for numbers read by @code{read-number}.
+@end defvar
+
+@defvar goto-line-history
+A history list for arguments to @code{goto-line}. This variable is
+buffer local.
+@end defvar
+
@c Less common: coding-system-history, input-method-history,
@c command-history, grep-history, grep-find-history,
@c read-envvar-name-history, setenv-history, yes-or-no-p-history.
diff --git a/etc/NEWS b/etc/NEWS
index cf4e705a52..dc17445757 100644
--- a/etc/NEWS
+++ b/etc/NEWS
@@ -533,6 +533,17 @@ 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.
++++
+** 'read-number' now has its own history variable.
+Additionally, the function now accepts a HIST argument which can be
+used to specify a custom history variable.
+
++++
+** Input history for 'goto-line' is now local to every buffer.
+Each buffer will keep a separate history of line numbers used with
+'goto-line'. This should help making faster the process of finding
+line numbers that were previously jumped to.
+
\f
* Editing Changes in Emacs 27.1
diff --git a/lisp/simple.el b/lisp/simple.el
index 6d5030073b..6219986da0 100644
--- a/lisp/simple.el
+++ b/lisp/simple.el
@@ -1212,6 +1212,10 @@ mark-whole-buffer
;; Counting lines, one way or another.
+(defvar goto-line-history nil
+ "History of values entered with `goto-line'.")
+(make-variable-buffer-local 'goto-line-history)
+
(defun goto-line (line &optional buffer)
"Go to LINE, counting from line 1 at beginning of buffer.
If called interactively, a numeric prefix argument specifies
@@ -1256,7 +1260,8 @@ goto-line
"")))
;; Read the argument, offering that number (if any) as default.
(list (read-number (format "Goto line%s: " buffer-prompt)
- (list default (line-number-at-pos)))
+ (list default (line-number-at-pos))
+ 'goto-line-history)
buffer))))
;; Switch to the desired buffer, one way or another.
(if buffer
diff --git a/lisp/subr.el b/lisp/subr.el
index ed55853bb2..f5b7c98f50 100644
--- a/lisp/subr.el
+++ b/lisp/subr.el
@@ -2518,10 +2518,15 @@ read-passwd
;; And of course, don't keep the sensitive data around.
(erase-buffer))))))))
-(defun read-number (prompt &optional default)
+(defvar read-number-history nil
+ "The default history for the `read-number' function.")
+
+(defun read-number (prompt &optional default hist)
"Read a numeric value in the minibuffer, prompting with PROMPT.
DEFAULT specifies a default value to return if the user just types RET.
The value of DEFAULT is inserted into PROMPT.
+HIST specifies a history list variable. See `read-from-minibuffer'
+for details of the HIST argument.
This function is used by the `interactive' code letter `n'."
(let ((n nil)
(default1 (if (consp default) (car default) default)))
@@ -2535,7 +2540,7 @@ read-number
(while
(progn
(let ((str (read-from-minibuffer
- prompt nil nil nil nil
+ prompt nil nil nil (or hist 'read-number-history)
(when default
(if (consp default)
(mapcar 'number-to-string (delq nil default))
--
2.17.1
^ permalink raw reply related [flat|nested] 18+ messages in thread
* bug#38282: 26.3; goto-line should not share input history with other commands
2019-12-17 21:19 ` Federico Tedin
@ 2019-12-24 16:39 ` Lars Ingebrigtsen
2019-12-24 23:21 ` Federico Tedin
0 siblings, 1 reply; 18+ messages in thread
From: Lars Ingebrigtsen @ 2019-12-24 16:39 UTC (permalink / raw)
To: Federico Tedin; +Cc: 38282
Federico Tedin <federicotedin@gmail.com> writes:
> Sorry, forgot to do that. I've now documented both new variables (the
> one for `read-number' and the one for `goto-line'). I'm attaching a new
> patch.
Thanks; I've now applied this to Emacs 28. (Only bug fixes are going
into Emacs 27 now, and as this is a new feature, it'll have to wait
until the next release cycle.)
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
^ permalink raw reply [flat|nested] 18+ messages in thread
* bug#38282: 26.3; goto-line should not share input history with other commands
2019-12-24 16:39 ` Lars Ingebrigtsen
@ 2019-12-24 23:21 ` Federico Tedin
0 siblings, 0 replies; 18+ messages in thread
From: Federico Tedin @ 2019-12-24 23:21 UTC (permalink / raw)
To: Lars Ingebrigtsen; +Cc: 38282
> Thanks; I've now applied this to Emacs 28. (Only bug fixes are going
> into Emacs 27 now, and as this is a new feature, it'll have to wait
> until the next release cycle.)
Thanks! And merry Xmas.
- Fede
^ permalink raw reply [flat|nested] 18+ messages in thread
end of thread, other threads:[~2019-12-24 23:21 UTC | newest]
Thread overview: 18+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2019-11-19 21:48 bug#38282: 26.3; goto-line should not share input history with other commands Federico Tedin
2019-11-21 13:51 ` Lars Ingebrigtsen
2019-11-21 14:41 ` Robert Pluim
2019-11-21 15:20 ` Michael Albinus
2019-11-21 17:51 ` Lars Ingebrigtsen
2019-11-21 18:43 ` Federico Tedin
2019-11-21 22:06 ` Federico Tedin
2019-11-22 7:35 ` Eli Zaretskii
2019-11-22 12:09 ` Lars Ingebrigtsen
2019-11-23 17:05 ` Federico Tedin
2019-11-27 11:48 ` Lars Ingebrigtsen
2019-12-06 22:14 ` Federico Tedin
2019-12-14 11:44 ` Eli Zaretskii
2019-12-17 21:19 ` Federico Tedin
2019-12-24 16:39 ` Lars Ingebrigtsen
2019-12-24 23:21 ` Federico Tedin
2019-11-22 7:57 ` Michael Albinus
2019-11-22 8:40 ` Robert Pluim
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).