goto-char doesn't stick

goto-char doesn't stick

[Elias Mårtenson]

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

I have been trying to figure out why M-. in SLIME sometimes doesn't move
point to the correct location in the file, and I discovered the following
strange behaviour:

Assuming the cursor is at some random position in buffer "z", The SLIME
code essentially does the following to move the cursor to a given location:

    (progn
      (set-buffer "z")
      (goto-char LOCATION))

When I do this, point doesn't move. Or rather, it does move, but after the
conclusion of the ‘progn’ form, the cursor returns to its original
location. This is what causes the SLIME navigation functions to not work
correctly.

Has this behaviour changed recently? I haven't seen anyone else complain
about this, but then again, I usually run Emacs compiled from git master,
so it may be that this has changed in newer versions.

Regards,
Elas

[-- Attachment #2: Type: text/html, Size: 1038 bytes --]

Re: goto-char doesn't stick

[Andreas Schwab]

On Jun 14 2017, Elias Mårtenson <lokedhs@gmail.com> wrote:

> Assuming the cursor is at some random position in buffer "z", The SLIME
> code essentially does the following to move the cursor to a given location:
>
>     (progn
>       (set-buffer "z")
>       (goto-char LOCATION))

You should put that inside save-excursion.

Andreas.

-- 
Andreas Schwab, SUSE Labs, schwab@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."

Re: goto-char doesn't stick

[Elias Mårtenson]

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

On 14 June 2017 at 17:48, Andreas Schwab <schwab@suse.de> wrote:

> On Jun 14 2017, Elias Mårtenson <lokedhs@gmail.com> wrote:
>
> > Assuming the cursor is at some random position in buffer "z", The SLIME
> > code essentially does the following to move the cursor to a given
> location:
> >
> >     (progn
> >       (set-buffer "z")
> >       (goto-char LOCATION))
>
> You should put that inside save-excursion.
>

How will that help? I want the code to move point, and the problem is that
it does not move. ‘save-excursion’ simply ensures that point will not move.

Regards,
Elias

[-- Attachment #2: Type: text/html, Size: 1070 bytes --]

Re: goto-char doesn't stick

[Peder O. Klingenberg]

On Wed, Jun 14 2017 at 17:45, Elias Mårtenson wrote:

> Has this behaviour changed recently? I haven't seen anyone else complain
> about this, but then again, I usually run Emacs compiled from git master,
> so it may be that this has changed in newer versions.

I see this as well.  Like you, I am running master, though usually
outdated.  This has been annoying for at least a few months, but not
annoying enough for me to investigate.  I haven't reported a bug as I
don't know if it belongs with emacs or slime.

...Peder...
-- 
I wish a new life awaited _me_ in some off-world colony.

Re: goto-char doesn't stick

[Noam Postavsky]

On Wed, Jun 14, 2017 at 5:45 AM, Elias Mårtenson <lokedhs@gmail.com> wrote:
>
>     (progn
>       (set-buffer "z")
>       (goto-char LOCATION))
>
> When I do this, point doesn't move. Or rather, it does move, but after the
> conclusion of the ‘progn’ form, the cursor returns to its original location.

Is the buffer "z" visible? You probably need to set-window-point too.

Re: goto-char doesn't stick

[Andreas Schwab]

On Jun 14 2017, Elias Mårtenson <lokedhs@gmail.com> wrote:

> How will that help? I want the code to move point, and the problem is that
> it does not move. ‘save-excursion’ simply ensures that point will not move.

But you are changing buffers.

Andreas.

-- 
Andreas Schwab, SUSE Labs, schwab@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."

Re: goto-char doesn't stick

[Elias Mårtenson]

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

On 14 June 2017 at 18:26, Noam Postavsky <npostavs@users.sourceforge.net>
wrote:

> On Wed, Jun 14, 2017 at 5:45 AM, Elias Mårtenson <lokedhs@gmail.com>
> wrote:
> >
> >     (progn
> >       (set-buffer "z")
> >       (goto-char LOCATION))
> >
> > When I do this, point doesn't move. Or rather, it does move, but after
> the
> > conclusion of the ‘progn’ form, the cursor returns to its original
> location.
>
> Is the buffer "z" visible? You probably need to set-window-point too.
>

The same behaviour is seen regardless of whether the buffer is visible or
not.

It's easy to reproduce:

Just create a buffer "z", fill it with some text and place point in a
random position. Then open ‘ielm’ and type:

    (progn (set-buffer "z") (goto-char (point-min)))

Then switch to buffer "z" and observe that point is still in its original
position.

[-- Attachment #2: Type: text/html, Size: 1622 bytes --]

Re: goto-char doesn't stick

[Elias Mårtenson]

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

On 14 June 2017 at 18:29, Andreas Schwab <schwab@suse.de> wrote:

> On Jun 14 2017, Elias Mårtenson <lokedhs@gmail.com> wrote:
>
> > How will that help? I want the code to move point, and the problem is
> that
> > it does not move. ‘save-excursion’ simply ensures that point will not
> move.
>
> But you are changing buffers.


Correct. I want to change the position of point in a different buffer.

If what I am seeing is correct behaviour, what is the correct way to move
point in some buffer. Or more formally, how would you implement a function
‘goto-char-in-buffer (BUFFER POSITION) ’?

Regards,
Elias

[-- Attachment #2: Type: text/html, Size: 1085 bytes --]

Re: goto-char doesn't stick

[Yuri Khan]

On Wed, Jun 14, 2017 at 5:32 PM, Elias Mårtenson <lokedhs@gmail.com> wrote:

> Correct. I want to change the position of point in a different buffer.

There is no such thing as “position of point in a different buffer”.

Or, rather, there is, but there is not one. For every window that is
showing the buffer, there is that window’s own position of point. But
if a buffer is not shown in any buffer, then it still has one position
of point.

Therefore, if you are trying to change the position of point in a
different buffer that is shown in a window, do it by selecting that
window, not by switching to that buffer in your window.

Re: goto-char doesn't stick

[Elias Mårtenson]

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

On 14 Jun 2017 13:01, "Yuri Khan" <yuri.v.khan@gmail.com> wrote:

On Wed, Jun 14, 2017 at 5:32 PM, Elias Mårtenson <lokedhs@gmail.com> wrote:

> Correct. I want to change the position of point in a different buffer.

There is no such thing as “position of point in a different buffer”.

Or, rather, there is, but there is not one. For every window that is
showing the buffer, there is that window’s own position of point. But
if a buffer is not shown in any buffer, then it still has one position
of point.

Therefore, if you are trying to change the position of point in a
different buffer that is shown in a window, do it by selecting that
window, not by switching to that buffer in your window.


Point taken, but this clearly worked at some time in the past, since SLIME
does it, and assumes that it will work.

The way SLIME implements navigation is that it uses the mechanism outlined
above and later switches to the buffer (using pop-to-buffer or some other
mechanism depending on various parameters that I haven't fully figured
out). At some point in the past, this worked, and I'd like to know why it
stopped working.

If the current behaviour is correct, then I need to figure out how to fix
SLIME so I can send them a patch.

Regards,
Elias

[-- Attachment #2: Type: text/html, Size: 2052 bytes --]

Re: goto-char doesn't stick

[Eli Zaretskii]

On June 14, 2017 12:45:15 PM GMT+03:00, "Elias Mårtenson" <lokedhs@gmail.com> wrote:
>I have been trying to figure out why M-. in SLIME sometimes doesn't
>move
>point to the correct location in the file, and I discovered the
>following
>strange behaviour:
>
>Assuming the cursor is at some random position in buffer "z", The SLIME
>code essentially does the following to move the cursor to a given
>location:
>
>    (progn
>      (set-buffer "z")
>      (goto-char LOCATION))
>
>When I do this, point doesn't move. Or rather, it does move, but after
>the
>conclusion of the ‘progn’ form, the cursor returns to its original
>location. This is what causes the SLIME navigation functions to not
>work
>correctly.
>
>Has this behaviour changed recently? I haven't seen anyone else
>complain
>about this, but then again, I usually run Emacs compiled from git
>master,
>so it may be that this has changed in newer versions.
>
>Regards,
>Elas

It's a feature, new in Emacs 26.  If you don't like it, turn off
switch-to-buffer-preserve-window-point.
Perhaps we should have a let-bindable variable to momentsrily disable this.

Re: goto-char doesn't stick

[Elias Mårtenson]

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

On 14 Jun 2017 13:14, "Eli Zaretskii" <eliz@gnu.org> wrote:


It's a feature, new in Emacs 26.  If you don't like it, turn off
switch-to-buffer-preserve-window-point.
Perhaps we should have a let-bindable variable to momentsrily disable this.


Thanks. I think a variable for this would be great. That would make the
SLIME fix reasonably small.

Regards,
Elias

[-- Attachment #2: Type: text/html, Size: 858 bytes --]

RE: goto-char doesn't stick

[Drew Adams]

> >      (set-buffer "z")
> >      (goto-char LOCATION))
> >
> >When I do this, point doesn't move. Or rather, it does move, but after
> >the conclusion of the ‘progn’ form, the cursor returns to its original
> >location...
> >
> >Has this behaviour changed recently?
> 
> It's a feature, new in Emacs 26.  If you don't like it, turn off
> switch-to-buffer-preserve-window-point.

Interesting.  But why was the default behavior changed to this
new behavior possibility?

Re: goto-char doesn't stick

[Eli Zaretskii]

> From: Elias Mårtenson <lokedhs@gmail.com>
> Date: Wed, 14 Jun 2017 19:16:42 +0800
> Cc: emacs-devel <emacs-devel@gnu.org>
> 
>  It's a feature, new in Emacs 26. If you don't like it, turn off
>  switch-to-buffer-preserve-window-point.
>  Perhaps we should have a let-bindable variable to momentsrily disable this.
> 
> Thanks. I think a variable for this would be great. That would make the SLIME fix reasonably small. 

Actually, I think a let-binding would be only rarely useful, since in
most similar cases point is restored after all your forms already
returned, and Emacs is restoring the window's buffer to its previous
value as part of its main loop.

Instead, I think you can prevent point from being restored as in your
use case by filtering the offending buffer from the window's
prev-buffers list, by using window-prev-buffers and
set-window-prev-buffers as part of the Lisp code which moves point in
that buffer.

Re: goto-char doesn't stick

[Eli Zaretskii]

> Date: Wed, 14 Jun 2017 07:05:39 -0700 (PDT)
> From: Drew Adams <drew.adams@oracle.com>
> 
> > It's a feature, new in Emacs 26.  If you don't like it, turn off
> > switch-to-buffer-preserve-window-point.
> 
> Interesting.  But why was the default behavior changed to this
> new behavior possibility?

Because the new default makes much more sense in interactive sessions,
especially when you have the same buffer displayed in multiple
windows.

Re: goto-char doesn't stick

[Elias Mårtenson]

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

On 14 Jun 2017 16:33, "Eli Zaretskii" <eliz@gnu.org> wrote:

> From: Elias Mårtenson <lokedhs@gmail.com>
> Date: Wed, 14 Jun 2017 19:16:42 +0800
> Cc: emacs-devel <emacs-devel@gnu.org>
>
>  It's a feature, new in Emacs 26. If you don't like it, turn off
>  switch-to-buffer-preserve-window-point.
>  Perhaps we should have a let-bindable variable to momentsrily disable
this.
>
> Thanks. I think a variable for this would be great. That would make the
SLIME fix reasonably small.

Actually, I think a let-binding would be only rarely useful, since in
most similar cases point is restored after all your forms already
returned, and Emacs is restoring the window's buffer to its previous
value as part of its main loop.

Instead, I think you can prevent point from being restored as in your
use case by filtering the offending buffer from the window's
prev-buffers list, by using window-prev-buffers and
set-window-prev-buffers as part of the Lisp code which moves point in
that buffer.


Thanks. I'll look at this in a few hours when I get back to the computer.

However, based on what you told me, it seems as though I need to change
some buffer-wide or window-wide setting. Is this correct, or did I
misunderstand?

Ideally, the SLIME fix should not have any impact outside the function in
question.

Regards,
Elias

[-- Attachment #2: Type: text/html, Size: 2225 bytes --]

Re: goto-char doesn't stick

[Eli Zaretskii]

> From: Elias Mårtenson <lokedhs@gmail.com>
> Date: Wed, 14 Jun 2017 22:59:18 +0800
> Cc: emacs-devel <emacs-devel@gnu.org>
> 
> However, based on what you told me, it seems as though I need to change some buffer-wide or window-wide
> setting. Is this correct, or did I misunderstand? 

It's not a setting, it's a data structure maintained internally by
Emacs.

> Ideally, the SLIME fix should not have any impact outside the function in question. 

Sorry, I don't understand what that means in practice, probably
because I don't use SLIME.  Maybe you could describe the issue and its
context in more detail.

Re: goto-char doesn't stick

[Alex]

Elias Mårtenson <lokedhs@gmail.com> writes:

> On 14 Jun 2017 16:33, "Eli Zaretskii" <eliz@gnu.org> wrote:
>
>  > From: Elias Mårtenson <lokedhs@gmail.com>
>  > Date: Wed, 14 Jun 2017 19:16:42 +0800
>  > Cc: emacs-devel <emacs-devel@gnu.org>
>  >
>  >  It's a feature, new in Emacs 26. If you don't like it, turn off
>  >  switch-to-buffer-preserve-window-point.
>  >  Perhaps we should have a let-bindable variable to momentsrily disable this.
>  >
>  > Thanks. I think a variable for this would be great. That would make the SLIME fix reasonably small.
>
>  Actually, I think a let-binding would be only rarely useful, since in
>  most similar cases point is restored after all your forms already
>  returned, and Emacs is restoring the window's buffer to its previous
>  value as part of its main loop.
>
>  Instead, I think you can prevent point from being restored as in your
>  use case by filtering the offending buffer from the window's
>  prev-buffers list, by using window-prev-buffers and
>  set-window-prev-buffers as part of the Lisp code which moves point in
>  that buffer.
>
> Thanks. I'll look at this in a few hours when I get back to the computer. 
>
> However, based on what you told me, it seems as though I need to change some buffer-wide or window-wide setting. Is this correct, or did I misunderstand? 
>
> Ideally, the SLIME fix should not have any impact outside the function in question. 
>
> Regards, 
> Elias 

Have you tried let-binding switch-to-buffer-preserve-window-point to nil
around the switch-to-buffer call in slime-pop-to-location? It worked for me.

Re: goto-char doesn't stick

[Stefan Monnier]

>> (progn
>> (set-buffer "z")
>> (goto-char LOCATION))
[...]
> It's a feature, new in Emacs 26.  If you don't like it, turn off
> switch-to-buffer-preserve-window-point.

Really?  Why would set-buffer+goto-char be affected by a variable named
switch-to-buffer-* ?

To me it sounds like Noam is right: Elias just needs to set-window-point
instead of goto-char (or additionally to, if he needs goto-char for some
other reason).


        Stefan

Re: goto-char doesn't stick

[Noam Postavsky]

On Thu, Jun 15, 2017 at 2:59 AM, Stefan Monnier
<monnier@iro.umontreal.ca> wrote:
>>> (progn
>>> (set-buffer "z")
>>> (goto-char LOCATION))
> [...]
>> It's a feature, new in Emacs 26.  If you don't like it, turn off
>> switch-to-buffer-preserve-window-point.
>
> Really?  Why would set-buffer+goto-char be affected by a variable named
> switch-to-buffer-* ?

The switch-to-buffer-preserve-window-point affects point when you
switch to buffer "z" later.

> To me it sounds like Noam is right: Elias just needs to set-window-point
> instead of goto-char (or additionally to, if he needs goto-char for some
> other reason).

No, I verified that it happens when "z" is not displayed in any window.

Maybe we should provide set-preserved-window-point? Or
set-user-visible-point which would set all of point, window-point, and
preserved window-point (although I'm not sure how to deal with the
multi-window case cleanly)?

Re: goto-char doesn't stick

[martin rudalics]

 > Maybe we should provide set-preserved-window-point? Or
 > set-user-visible-point which would set all of point, window-point, and
 > preserved window-point (although I'm not sure how to deal with the
 > multi-window case cleanly)?

This bug is yet another consequence of using ‘switch-to-buffer’ in Elisp
code.  Years back I failed miserably curing that, see

http://lists.gnu.org/archive/html/emacs-devel/2011-07/msg00306.html

and

http://lists.gnu.org/archive/html/emacs-devel/2011-09/msg00020.html

My advice is the same as ever: Always use ‘pop-to-buffer-same-window’
in Elisp code instead.

Masochistically yours, martin

Re: goto-char doesn't stick

[Stefan Monnier]

>>>> (progn
>>>> (set-buffer "z")
>>>> (goto-char LOCATION))
>> [...]
>>> It's a feature, new in Emacs 26.  If you don't like it, turn off
>>> switch-to-buffer-preserve-window-point.
>> Really?  Why would set-buffer+goto-char be affected by a variable named
>> switch-to-buffer-* ?
> The switch-to-buffer-preserve-window-point affects point when you
> switch to buffer "z" later.

I don't understand the scenario you have in mind.  If I do

    M-: (with-current-buffer "z" (goto-char (1+ (point))) (point))

repeatedly, when "z" is not displayed, I see an increasing sequence, so
the value of point is correctly preserved.

> No, I verified that it happens when "z" is not displayed in any window.

I wonder what's the difference between your test and mine.


        Stefan

Re: goto-char doesn't stick

[Eli Zaretskii]

> From: Stefan Monnier <monnier@IRO.UMontreal.CA>
> Date: Thu, 15 Jun 2017 09:24:15 -0400
> Cc: Emacs developers <emacs-devel@gnu.org>
> 
> >>>> (progn
> >>>> (set-buffer "z")
> >>>> (goto-char LOCATION))
> >> [...]
> >>> It's a feature, new in Emacs 26.  If you don't like it, turn off
> >>> switch-to-buffer-preserve-window-point.
> >> Really?  Why would set-buffer+goto-char be affected by a variable named
> >> switch-to-buffer-* ?
> > The switch-to-buffer-preserve-window-point affects point when you
> > switch to buffer "z" later.
> 
> I don't understand the scenario you have in mind.  If I do
> 
>     M-: (with-current-buffer "z" (goto-char (1+ (point))) (point))
> 
> repeatedly, when "z" is not displayed, I see an increasing sequence, so
> the value of point is correctly preserved.

Of course.

> > No, I verified that it happens when "z" is not displayed in any window.
> 
> I wonder what's the difference between your test and mine.

You need to switch to "z" so that it is displayed in a window,
e.g. with "C-x b".  switch-to-buffer-preserve-window-point does its
thing at that time.

IOW, "goto-char doesn't stick" is based n an illusion, created by
making "z" the current buffer in the window, after running the snippet
above.

Re: goto-char doesn't stick

[Eli Zaretskii]

> From: Noam Postavsky <npostavs@users.sourceforge.net>
> Date: Thu, 15 Jun 2017 07:37:01 -0400
> Cc: Emacs developers <emacs-devel@gnu.org>
> 
> > Really?  Why would set-buffer+goto-char be affected by a variable named
> > switch-to-buffer-* ?
> 
> The switch-to-buffer-preserve-window-point affects point when you
> switch to buffer "z" later.

Right.

> Maybe we should provide set-preserved-window-point? Or
> set-user-visible-point which would set all of point, window-point, and
> preserved window-point (although I'm not sure how to deal with the
> multi-window case cleanly)?

How would set-preserved-window-point set all of those variables, and
at what time?  And how will it be different from turning off
switch-to-buffer-preserve-window-point while switching to the
offending buffer?

Re: goto-char doesn't stick

[Stefan Monnier]

> You need to switch to "z" so that it is displayed in a window,
> e.g. with "C-x b".  switch-to-buffer-preserve-window-point does its
> thing at that time.

Ah, so the OP wants to affect the future window-point?

I don't think there's ever been a reliable way to do that, short of
having your own variable `my-planned-cursor-position` (probably
a marker), moving it by hand, and then passing it to set-window-point
manually after displaying the buffer.


        Stefan

Re: goto-char doesn't stick

[Eli Zaretskii]

> From: Stefan Monnier <monnier@IRO.UMontreal.CA>
> Cc: npostavs@users.sourceforge.net, emacs-devel@gnu.org
> Date: Thu, 15 Jun 2017 13:11:13 -0400
> 
> > You need to switch to "z" so that it is displayed in a window,
> > e.g. with "C-x b".  switch-to-buffer-preserve-window-point does its
> > thing at that time.
> 
> Ah, so the OP wants to affect the future window-point?

Something like that, yeah.

> I don't think there's ever been a reliable way to do that

Right, I think it used to work only in very simple situations, and
definitely not when the same buffer is displayed at different
positions in several windows.

Re: goto-char doesn't stick

[Elias Mårtenson]

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

On 16 June 2017 at 02:25, Eli Zaretskii <eliz@gnu.org> wrote:

>
> Right, I think it used to work only in very simple situations, and
> definitely not when the same buffer is displayed at different
> positions in several windows.
>

Am I to assume that this is not something that is expected to work
reliably? In that case SLIME needs to be changed in a more significant way
than I had expected. For reference, I reported this on the SLIME bug
tracker: https://github.com/slime/slime/issues/391

[-- Attachment #2: Type: text/html, Size: 914 bytes --]

Re: goto-char doesn't stick

[Eli Zaretskii]

> From: Elias Mårtenson <lokedhs@gmail.com>
> Date: Fri, 16 Jun 2017 03:10:28 +0800
> Cc: Stefan Monnier <monnier@iro.umontreal.ca>, emacs-devel <emacs-devel@gnu.org>, 
> 	Noam Postavsky <npostavs@users.sourceforge.net>
> 
>  Right, I think it used to work only in very simple situations, and
>  definitely not when the same buffer is displayed at different
>  positions in several windows.
> 
> Am I to assume that this is not something that is expected to work reliably?

It's hard to answer without knowing what "this" is.  If you mean code
that first moves point in an undisplayed buffer and then switches to
that buffer in the selected window expecting to see point in the
location to which it was moved, then no, you cannot expect this to
work reliably.  (Previously, this would AFAIR luckily work only if you
didn't have the same buffer shown in any other window.)

> In that case SLIME needs to be changed in a more significant way
> than I had expected. For reference, I reported this on the SLIME bug
> tracker: https://github.com/slime/slime/issues/391

I think the solution you suggest there is the right one, it should
have been taken long ago.

Re: goto-char doesn't stick

[martin rudalics]

 >> I don't think there's ever been a reliable way to do that
 >
 > Right, I think it used to work only in very simple situations, and
 > definitely not when the same buffer is displayed at different
 > positions in several windows.

‘goto-char’ followed by ‘set-window-buffer’ is a reliable way to do that
regardless in how many windows the buffer is shown.

martin

Re: goto-char doesn't stick

[Stefan Monnier]

> ‘goto-char’ followed by ‘set-window-buffer’ is a reliable way to do that
> regardless in how many windows the buffer is shown.

Indeed.  And if you swap the two you even get to choose to use any other
function to display the buffer.


        Stefan