GNU bug report logs - #38282
26.3; goto-line should not share input history with other commands

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 38282 in the body.
You can then email your comments to 38282 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: 26.3; goto-line should not share input history with other commands
Date: Tue, 19 Nov 2019 22:48:40 +0100

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.

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

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Federico Tedin <federicotedin <at> gmail.com>
Cc: 38282 <at> debbugs.gnu.org
Subject: Re: bug#38282: 26.3; goto-line should not share input history with
 other commands
Date: Thu, 21 Nov 2019 14:51:18 +0100

Federico Tedin <federicotedin <at> 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

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

From: Robert Pluim <rpluim <at> gmail.com>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: 38282 <at> debbugs.gnu.org, Federico Tedin <federicotedin <at> gmail.com>
Subject: Re: bug#38282: 26.3; goto-line should not share input history with
 other commands
Date: Thu, 21 Nov 2019 15:41:44 +0100

>>>>> On Thu, 21 Nov 2019 14:51:18 +0100, Lars Ingebrigtsen <larsi <at> gnus.org> said:

    Lars> Federico Tedin <federicotedin <at> 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

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

From: Michael Albinus <michael.albinus <at> gmx.de>
To: Robert Pluim <rpluim <at> gmail.com>
Cc: Lars Ingebrigtsen <larsi <at> gnus.org>, 38282 <at> debbugs.gnu.org,
 Federico Tedin <federicotedin <at> gmail.com>
Subject: Re: bug#38282: 26.3; goto-line should not share input history with
 other commands
Date: Thu, 21 Nov 2019 16:20:47 +0100

Robert Pluim <rpluim <at> 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.

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

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Michael Albinus <michael.albinus <at> gmx.de>
Cc: Robert Pluim <rpluim <at> gmail.com>, 38282 <at> debbugs.gnu.org,
 Federico Tedin <federicotedin <at> gmail.com>
Subject: Re: bug#38282: 26.3; goto-line should not share input history with
 other commands
Date: Thu, 21 Nov 2019 18:51:27 +0100

Michael Albinus <michael.albinus <at> gmx.de> writes:

> Robert Pluim <rpluim <at> 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

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

From: Federico Tedin <federicotedin <at> gmail.com>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: 38282 <at> debbugs.gnu.org, Robert Pluim <rpluim <at> gmail.com>,
 Michael Albinus <michael.albinus <at> gmx.de>
Subject: Re: bug#38282: 26.3;
 goto-line should not share input history with other commands
Date: Thu, 21 Nov 2019 19:43:32 +0100

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

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

From: Federico Tedin <federicotedin <at> gmail.com>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: Michael Albinus <michael.albinus <at> gmx.de>, Robert Pluim <rpluim <at> gmail.com>,
 38282 <at> debbugs.gnu.org
Subject: Re: bug#38282: 26.3;
 goto-line should not share input history with other commands
Date: Thu, 21 Nov 2019 23:06:14 +0100

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

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

[goto-line.patch (text/x-diff, attachment)]

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Federico Tedin <federicotedin <at> gmail.com>
Cc: michael.albinus <at> gmx.de, larsi <at> gnus.org, 38282 <at> debbugs.gnu.org,
 rpluim <at> gmail.com
Subject: Re: bug#38282: 26.3;
 goto-line should not share input history with other commands
Date: Fri, 22 Nov 2019 09:35:55 +0200

> From: Federico Tedin <federicotedin <at> gmail.com>
> Date: Thu, 21 Nov 2019 23:06:14 +0100
> Cc: 38282 <at> debbugs.gnu.org, Robert Pluim <rpluim <at> gmail.com>,
>  Michael Albinus <michael.albinus <at> 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".

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

From: Michael Albinus <michael.albinus <at> gmx.de>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: Robert Pluim <rpluim <at> gmail.com>, 38282 <at> debbugs.gnu.org,
 Federico Tedin <federicotedin <at> gmail.com>
Subject: Re: bug#38282: 26.3; goto-line should not share input history with
 other commands
Date: Fri, 22 Nov 2019 08:57:52 +0100

Lars Ingebrigtsen <larsi <at> 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.

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

From: Robert Pluim <rpluim <at> gmail.com>
To: Michael Albinus <michael.albinus <at> gmx.de>
Cc: Lars Ingebrigtsen <larsi <at> gnus.org>, 38282 <at> debbugs.gnu.org,
 Federico Tedin <federicotedin <at> gmail.com>
Subject: Re: bug#38282: 26.3; goto-line should not share input history with
 other commands
Date: Fri, 22 Nov 2019 09:40:26 +0100

>>>>> On Fri, 22 Nov 2019 08:57:52 +0100, Michael Albinus <michael.albinus <at> gmx.de> said:

    Michael> Lars Ingebrigtsen <larsi <at> 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

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

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Federico Tedin <federicotedin <at> gmail.com>
Cc: Michael Albinus <michael.albinus <at> gmx.de>, Robert Pluim <rpluim <at> gmail.com>,
 38282 <at> debbugs.gnu.org
Subject: Re: bug#38282: 26.3; goto-line should not share input history with
 other commands
Date: Fri, 22 Nov 2019 13:09:06 +0100

Federico Tedin <federicotedin <at> 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

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

From: Federico Tedin <federicotedin <at> gmail.com>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: 38282 <at> debbugs.gnu.org
Subject: Re: bug#38282: 26.3;
 goto-line should not share input history with other commands
Date: Sat, 23 Nov 2019 18:05:32 +0100

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

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

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Federico Tedin <federicotedin <at> gmail.com>
Cc: 38282 <at> debbugs.gnu.org
Subject: Re: bug#38282: 26.3; goto-line should not share input history with
 other commands
Date: Wed, 27 Nov 2019 12:48:08 +0100

Federico Tedin <federicotedin <at> 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

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

From: Federico Tedin <federicotedin <at> gmail.com>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: 38282 <at> debbugs.gnu.org
Subject: Re: bug#38282: 26.3;
 goto-line should not share input history with other commands
Date: Fri, 06 Dec 2019 23:14:15 +0100

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

> 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

[goto-line.patch (text/x-diff, attachment)]

Message #47 received at 38282 <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, 38282 <at> debbugs.gnu.org
Subject: Re: bug#38282: 26.3;
 goto-line should not share input history with other commands
Date: Sat, 14 Dec 2019 13:44:50 +0200

> From: Federico Tedin <federicotedin <at> gmail.com>
> Date: Fri, 06 Dec 2019 23:14:15 +0100
> Cc: 38282 <at> 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.

Message #50 received at 38282 <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, 38282 <at> debbugs.gnu.org
Subject: Re: bug#38282: 26.3;
 goto-line should not share input history with other commands
Date: Tue, 17 Dec 2019 22:19:44 +0100

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

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

[goto-line.patch (text/x-diff, attachment)]

Message #53 received at 38282 <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>, 38282 <at> debbugs.gnu.org
Subject: Re: bug#38282: 26.3; goto-line should not share input history with
 other commands
Date: Tue, 24 Dec 2019 17:39:34 +0100

Federico Tedin <federicotedin <at> 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

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

From: Federico Tedin <federicotedin <at> gmail.com>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: 38282 <at> debbugs.gnu.org
Subject: Re: bug#38282: 26.3; goto-line should not share input history with
 other commands
Date: Wed, 25 Dec 2019 00:21:54 +0100

> 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

Previous Next

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