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

classic Classic list List threaded Threaded
15 messages Options
Reply | Threaded
Open this post in threaded view
|

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

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



Reply | Threaded
Open this post in threaded view
|

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

Lars Ingebrigtsen
Federico Tedin <[hidden email]> 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



Reply | Threaded
Open this post in threaded view
|

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

Robert Pluim
>>>>> On Thu, 21 Nov 2019 14:51:18 +0100, Lars Ingebrigtsen <[hidden email]> said:

    Lars> Federico Tedin <[hidden email]> 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



Reply | Threaded
Open this post in threaded view
|

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

Michael Albinus
Robert Pluim <[hidden email]> 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.



Reply | Threaded
Open this post in threaded view
|

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

Lars Ingebrigtsen
Michael Albinus <[hidden email]> writes:

> Robert Pluim <[hidden email]> 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



Reply | Threaded
Open this post in threaded view
|

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

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



Reply | Threaded
Open this post in threaded view
|

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

Federico Tedin
> 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 (2K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

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

Eli Zaretskii
> From: Federico Tedin <[hidden email]>
> Date: Thu, 21 Nov 2019 23:06:14 +0100
> Cc: [hidden email], Robert Pluim <[hidden email]>,
>  Michael Albinus <[hidden email]>
>
> 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".



Reply | Threaded
Open this post in threaded view
|

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

Michael Albinus
In reply to this post by Lars Ingebrigtsen
Lars Ingebrigtsen <[hidden email]> 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.



Reply | Threaded
Open this post in threaded view
|

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

Robert Pluim
>>>>> On Fri, 22 Nov 2019 08:57:52 +0100, Michael Albinus <[hidden email]> said:

    Michael> Lars Ingebrigtsen <[hidden email]> 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



Reply | Threaded
Open this post in threaded view
|

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

Lars Ingebrigtsen
In reply to this post by Federico Tedin
Federico Tedin <[hidden email]> 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



Reply | Threaded
Open this post in threaded view
|

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

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



Reply | Threaded
Open this post in threaded view
|

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

Lars Ingebrigtsen
Federico Tedin <[hidden email]> 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



Reply | Threaded
Open this post in threaded view
|

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

Federico Tedin
> 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 (2K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

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

Eli Zaretskii
> From: Federico Tedin <[hidden email]>
> Date: Fri, 06 Dec 2019 23:14:15 +0100
> Cc: [hidden email]
>
> > 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.