goto-line-history should not be buffer local.

goto-line-history should not be buffer local.

[Alan Mackenzie]

Hello, Emacs.

Why is goto-line-history buffer local?  This seems to me to be a step
backwards, for precisely the reason that making search history buffer
local would be a bad thing.  This was a recent change, at the end of
January.

In my personal use, I sometimes type M-g M-g in the wrong buffer, which
disrupts my flow of thought in that buffer.  That's unavoidable.  But
now I have the additional inconvenience of having to type in that line
number in full a second time, having gone to the proper buffer.  That's
not good.

Also I frequently want to go to the same line repeatedly in the same
file.  I mean here file, not buffer.  I kill the buffer and reload from
"disk" to ensure that caches are cleared, and suchlike, during testing.
Here, again, I've got to remember that line number and type it in again
in full.  That's not good either.

Indeed, I'm not sure whether having a buffer local history is better
than having no history at all.  Who wants to go to the same line
repeatedly in the same buffer?  OK, others may do, but I don't see the
compelling need.

So, could we have this history variable made global again, please?

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: goto-line-history should not be buffer local.

[Óscar Fuentes]

Alan Mackenzie <acm@muc.de> writes:

> Why is goto-line-history buffer local?  This seems to me to be a step
> backwards, for precisely the reason that making search history buffer
> local would be a bad thing.  This was a recent change, at the end of
> January.

It's a bit older:

commit 7c5d6a2afc6c23a7fff8456f506ee2aa2d37a3b9
Author: Federico Tedin
Date:   Tue Dec 24 17:38:19 2019 +0100

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

Re: goto-line-history should not be buffer local.

[Richard Copley]

Alan Mackenzie <acm@muc.de> writes:

> Why is goto-line-history buffer local?  This seems to me to be a step
> backwards, for precisely the reason that making search history buffer
> local would be a bad thing.

I agree. I've been locally patching out that part of the commit since
a few months after it was introduced, which was at the end of 2019, as
Óscar points out.

Re: goto-line-history should not be buffer local.

[martin rudalics]

 >> Why is goto-line-history buffer local?  This seems to me to be a step
 >> backwards, for precisely the reason that making search history buffer
 >> local would be a bad thing.
 >
 > I agree. I've been locally patching out that part of the commit since
 > a few months after it was introduced, which was at the end of 2019, as
 > Óscar points out.

Then this feature should be made optional.

martin

Re: goto-line-history should not be buffer local.

[Alan Mackenzie]

Hello, Martin.

On Mon, Feb 15, 2021 at 09:17:18 +0100, martin rudalics wrote:
>  >> Why is goto-line-history buffer local?  This seems to me to be a step
>  >> backwards, for precisely the reason that making search history buffer
>  >> local would be a bad thing.

>  > I agree. I've been locally patching out that part of the commit since
>  > a few months after it was introduced, which was at the end of 2019, as
>  > Óscar points out.

> Then this feature should be made optional.

How about this (plus a NEWS entry and some amendments to the Emacs manual)?



diff --git a/lisp/simple.el b/lisp/simple.el
index 0c5bcb6672..b2b559ed13 100644
--- a/lisp/simple.el
+++ b/lisp/simple.el
@@ -1274,7 +1274,19 @@ mark-whole-buffer
 \f
 ;; Counting lines, one way or another.
 
-(defvar-local goto-line-history nil
+(defcustom goto-line-history-local nil
+  "If this option is nil, `goto-line-history' is shared between all buffers.
+if it is non-nil, each buffer has its own value of this history list.
+
+Note that on changing from non-nil to nil, the former contents of
+`goto-line-history' for each buffer are discarded on use of
+`goto-line' in that buffer."
+  :group 'editing
+  :type 'boolean
+  :safe #'booleanp
+  :version "28.1")
+
+(defvar goto-line-history nil
   "History of values entered with `goto-line'.")
 
 (defun goto-line-read-args (&optional relative)
@@ -1292,6 +1304,11 @@ goto-line-read-args
             (if buffer
                 (concat " in " (buffer-name buffer))
               "")))
+      ;; Has the buffer locality of `goto-line-history' changed?
+      (cond ((and goto-line-history-local (not (local-variable-p 'goto-line-history)))
+             (make-local-variable 'goto-line-history))
+            ((and (not goto-line-history-local) (local-variable-p 'goto-line-history))
+             (kill-local-variable 'goto-line-history)))
       ;; Read the argument, offering that number (if any) as default.
       (list (read-number (format "Goto%s line%s: "
                                  (if (buffer-narrowed-p)


Anybody have any objections to this?

> martin

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: goto-line-history should not be buffer local.

[Lars Ingebrigtsen]

Alan Mackenzie <acm@muc.de> writes:

> How about this (plus a NEWS entry and some amendments to the Emacs manual)?

Sounds good to me.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: goto-line-history should not be buffer local.

[Juri Linkov]

> -(defvar-local goto-line-history nil
> +(defcustom goto-line-history-local nil
> +  "If this option is nil, `goto-line-history' is shared between all buffers.
> +if it is non-nil, each buffer has its own value of this history list.
> +
> +Note that on changing from non-nil to nil, the former contents of
> +`goto-line-history' for each buffer are discarded on use of
> +`goto-line' in that buffer."
> +  :group 'editing
> +  :type 'boolean
> +  :safe #'booleanp
> +  :version "28.1")
>
> Anybody have any objections to this?

This is not an objection, just sharing a tip that to make
Isearch history buffer-local like it's in web browsers,
where each web page tab uses own local search history,
is possible with a small code snippet:

  (make-variable-buffer-local 'search-ring)
  (make-variable-buffer-local 'regexp-search-ring)

OTOH, with using defcustom it's easier to customize this, indeed.

Re: goto-line-history should not be buffer local.

[Alan Mackenzie]

Hello, Juri.

On Tue, Feb 16, 2021 at 19:13:36 +0200, Juri Linkov wrote:
> > -(defvar-local goto-line-history nil
> > +(defcustom goto-line-history-local nil
> > +  "If this option is nil, `goto-line-history' is shared between all buffers.
> > +if it is non-nil, each buffer has its own value of this history list.
> > +
> > +Note that on changing from non-nil to nil, the former contents of
> > +`goto-line-history' for each buffer are discarded on use of
> > +`goto-line' in that buffer."
> > +  :group 'editing
> > +  :type 'boolean
> > +  :safe #'booleanp
> > +  :version "28.1")

> > Anybody have any objections to this?

> This is not an objection, just sharing a tip that to make
> Isearch history buffer-local like it's in web browsers,
> where each web page tab uses own local search history,
> is possible with a small code snippet:

>   (make-variable-buffer-local 'search-ring)
>   (make-variable-buffer-local 'regexp-search-ring)

> OTOH, with using defcustom it's easier to customize this, indeed.

The point about the approach I've taken is that once a variable has
undergone make-variable-buffer-local, it cannot be changed back to a
non-local variable, except by restarting Emacs (I'm not sure whether or
not this is a design bug).  So I've avoided the use of that primitive.

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: goto-line-history should not be buffer local.

[Matt Armstrong]

Alan Mackenzie <acm@muc.de> writes:

> Hello, Juri.
>
> On Tue, Feb 16, 2021 at 19:13:36 +0200, Juri Linkov wrote:
>> > -(defvar-local goto-line-history nil
>> > +(defcustom goto-line-history-local nil
>> > +  "If this option is nil, `goto-line-history' is shared between all buffers.
>> > +if it is non-nil, each buffer has its own value of this history list.
>> > +
>> > +Note that on changing from non-nil to nil, the former contents of
>> > +`goto-line-history' for each buffer are discarded on use of
>> > +`goto-line' in that buffer."
>> > +  :group 'editing
>> > +  :type 'boolean
>> > +  :safe #'booleanp
>> > +  :version "28.1")
>
>> > Anybody have any objections to this?
>
>> This is not an objection, just sharing a tip that to make
>> Isearch history buffer-local like it's in web browsers,
>> where each web page tab uses own local search history,
>> is possible with a small code snippet:
>
>>   (make-variable-buffer-local 'search-ring)
>>   (make-variable-buffer-local 'regexp-search-ring)
>
>> OTOH, with using defcustom it's easier to customize this, indeed.
>
> The point about the approach I've taken is that once a variable has
> undergone make-variable-buffer-local, it cannot be changed back to a
> non-local variable, except by restarting Emacs (I'm not sure whether or
> not this is a design bug).  So I've avoided the use of that primitive.

Why the option at all?  Why not just make the history global?

I'm not strongly opposed, but I also don't think "make an option for it"
is always the right thing.

Who are the people who would set the option back to buffer local
history?

Note: the feature hasn't escaped to a stable release yet, so no strong
need for an option for backward compatibility reasons.

This is the strongest statement in favor of buffer locality I found:

https://lists.gnu.org/r/bug-gnu-emacs/2019-11/msg01580.html:
> 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.

"it might be better".  We've now got people who actively found it
annoying.

FYI we've got a similar, not yet fixed, bug about goto-char's history:
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=6980.  I'd say both should
work a similar way, but I'm unconvinced that every such case needs an
option covering a local vs. global choice.

Re: goto-line-history should not be buffer local.

[Lars Ingebrigtsen]

Matt Armstrong <matt@rfc20.org> writes:

> Who are the people who would set the option back to buffer local
> history?

*hand*

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: goto-line-history should not be buffer local.

[Rolf Ade]

Matt Armstrong <matt@rfc20.org> writes:
>
> Who are the people who would set the option back to buffer local
> history?

I will do. (Would prefer it's the default.)

What meaning have a certain line number from one buffer in another
buffer?

Re: goto-line-history should not be buffer local.

[Alan Mackenzie]

Hello, Rolf.

On Thu, Feb 18, 2021 at 01:26:56 +0100, Rolf Ade wrote:

> Matt Armstrong <matt@rfc20.org> writes:

> > Who are the people who would set the option back to buffer local
> > history?

> I will do. (Would prefer it's the default.)

> What meaning have a certain line number from one buffer in another
> buffer?

When, for example, you accidentally run goto-line in the wrong buffer.
When you switch to the buffer you wanted, you don't want to have to type
in the whole line number again.

When you have several versions of the same file, which happens in SW
development, you may want to goto-line to the same position in a
different version, in a different buffer.

A third case, which is what got on my nerves last weekend, is when you
are repeatedly killing a buffer and loading the same file again, so as
to clear caches, and so on.  You want to go to the same place at each
new loading, so as to do testing.

I'm curious as to why somebody would want buffer local goto-line
history.  How often does one repeat the same goto-line in the same
buffer, and how does a buffer local history help?

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: goto-line-history should not be buffer local.

[Kévin Le Gouguec]

Alan Mackenzie <acm@muc.de> writes:

> A third case, which is what got on my nerves last weekend, is when you
> are repeatedly killing a buffer and loading the same file again, so as
> to clear caches, and so on.  You want to go to the same place at each
> new loading, so as to do testing.

Out of curiosity, in this specific case, wouldn't revert-buffer (now
conveniently bound to C-x x g) accomplish the same thing?  (Clear
caches, while preserving the buffer-local history)

(Not suggesting that this invalidates your use-cases; just trying to
make sure I understand this one)

> I'm curious as to why somebody would want buffer local goto-line
> history.  How often does one repeat the same goto-line in the same
> buffer, and how does a buffer local history help?

🤷 I guess someone could use that buffer-local history as a manually
curated version of the mark ring?

Re: goto-line-history should not be buffer local.

[Rolf Ade]

Hello Alan,

Alan Mackenzie <acm@muc.de> writes:
> On Thu, Feb 18, 2021 at 01:26:56 +0100, Rolf Ade wrote:
>> Matt Armstrong <matt@rfc20.org> writes:
>
>> > Who are the people who would set the option back to buffer local
>> > history?
>
>> I will do. (Would prefer it's the default.)
>
>> What meaning have a certain line number from one buffer in another
>> buffer?
>
> When, for example, you accidentally run goto-line in the wrong buffer.
> When you switch to the buffer you wanted, you don't want to have to type
> in the whole line number again.
>
> When you have several versions of the same file, which happens in SW
> development, you may want to goto-line to the same position in a
> different version, in a different buffer.
>
> A third case, which is what got on my nerves last weekend, is when you
> are repeatedly killing a buffer and loading the same file again, so as
> to clear caches, and so on.  You want to go to the same place at each
> new loading, so as to do testing.

Thanks for explaning. I didn't thought about those cases but see now
why you are glad about a global goto-line history for them.

> I'm curious as to why somebody would want buffer local goto-line
> history.  How often does one repeat the same goto-line in the same
> buffer, and how does a buffer local history help?

When I valgrind an app I get line nummers from the output of the memory
debugger. Often the stack trace spread over several source files. While
looking around in the relevant files I would be glad for a local
goto-line history.

Re: goto-line-history should not be buffer local.

[Philip Kaludercic]

[-- Attachment #1: Type: text/plain, Size: 506 bytes --]

Rolf Ade <rolf@pointsman.de> writes:

> Matt Armstrong <matt@rfc20.org> writes:
>>
>> Who are the people who would set the option back to buffer local
>> history?
>
> I will do. (Would prefer it's the default.)

Seconding this.

> What meaning have a certain line number from one buffer in another
> buffer?

One argument was that you might accidentally type M-g M-g in the wrong
buffer, and would want to easily switch the buffer and repeat the last
goto-line request.

-- 
	Philip K.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 686 bytes --]

Re: goto-line-history should not be buffer local.

[Andreas Schwab]

On Feb 18 2021, Rolf Ade wrote:

> What meaning have a certain line number from one buffer in another
> buffer?

Line numbers are not buffer local, they are file local.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."

Re: goto-line-history should not be buffer local.

[Stefan Monnier]

> The point about the approach I've taken is that once a variable has
> undergone make-variable-buffer-local, it cannot be changed back to a
> non-local variable, except by restarting Emacs.

In some cases, you can unintern the symbol, but yes, it's basically
impossible :-(

> (I'm not sure whether or not this is a design bug)

I think it's just a feature noone bothered to implement.
I don't think it would require any change to the existing code.


        Stefan