window.el modify current emacs23 behavior of anything.

window.el modify current emacs23 behavior of anything.

[Thierry Volpiatto]

Hi all.

point doesn't move when trying to switch to a buffer at an other
position than the current one, when starting with `anything-samewindow'
enabled.
This is working fine in emacs23 but not here in last trunk.
Would be great to have same behavior as emacs23.

Martin, maybe you could have a look at this and give a try:

http://tinyurl.com/4xlrvf9

Thanks.

-- 
A+ Thierry
Get my Gnupg key:
gpg --keyserver pgp.mit.edu --recv-keys 59F29997 

Re: window.el modify current emacs23 behavior of anything.

[Thierry Volpiatto]

Thierry Volpiatto <thierry.volpiatto@gmail.com> writes:

> Hi all.
>
> point doesn't move when trying to switch to a buffer at an other
> position than the current one, when starting with `anything-samewindow'
> enabled.
> This is working fine in emacs23 but not here in last trunk.
> Would be great to have same behavior as emacs23.
>
> Martin, maybe you could have a look at this and give a try:
>
> http://tinyurl.com/4xlrvf9
>
> Thanks.

Using
(sit-for 0.1)
after bury-buffer in anything-cleanup seem to fix this problem, but it
is not very nice...

-- 
A+ Thierry
Get my Gnupg key:
gpg --keyserver pgp.mit.edu --recv-keys 59F29997 

Re: window.el modify current emacs23 behavior of anything.

[Thierry Volpiatto]

Thierry Volpiatto <thierry.volpiatto@gmail.com> writes:

> Thierry Volpiatto <thierry.volpiatto@gmail.com> writes:
>
>> Hi all.
>>
>> point doesn't move when trying to switch to a buffer at an other
>> position than the current one, when starting with `anything-samewindow'
>> enabled.
>> This is working fine in emacs23 but not here in last trunk.
>> Would be great to have same behavior as emacs23.
>>
>> Martin, maybe you could have a look at this and give a try:
>>
>> http://tinyurl.com/4xlrvf9
>>
>> Thanks.
>
> Using
> (sit-for 0.1)
> after bury-buffer in anything-cleanup seem to fix this problem, but it
> is not very nice...

And also:
(bury-buffer-internal (get-buffer anything-buffer))
is working.
So it seem the problem comes from bury-buffer.

-- 
A+ Thierry
Get my Gnupg key:
gpg --keyserver pgp.mit.edu --recv-keys 59F29997 

Re: window.el modify current emacs23 behavior of anything.

[Eli Zaretskii]

> From: Thierry Volpiatto <thierry.volpiatto@gmail.com>
> Date: Mon, 12 Sep 2011 08:38:29 +0200
> 
> Using
> (sit-for 0.1)
> after bury-buffer in anything-cleanup seem to fix this problem

What about `(sit-for 0)'?

Re: window.el modify current emacs23 behavior of anything.

[Thierry Volpiatto]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Thierry Volpiatto <thierry.volpiatto@gmail.com>
>> Date: Mon, 12 Sep 2011 08:38:29 +0200
>> 
>> Using
>> (sit-for 0.1)
>> after bury-buffer in anything-cleanup seem to fix this problem
>
> What about `(sit-for 0)'?
Same effect as 0.1

Another workaround is calling bury-buffer with arg in this case,

(if anything-samewindow (bury-buffer (current-buffer)) (bury-buffer))

but then when using different frame or dedicated window, anything-buffer
is not deleted.

-- 
A+ Thierry
Get my Gnupg key:
gpg --keyserver pgp.mit.edu --recv-keys 59F29997 

Re: window.el modify current emacs23 behavior of anything.

[martin rudalics]

 > point doesn't move when trying to switch to a buffer at an other
 > position than the current one, when starting with `anything-samewindow'
 > enabled.
 > This is working fine in emacs23 but not here in last trunk.
 > Would be great to have same behavior as emacs23.
 >
 > Martin, maybe you could have a look at this and give a try:
 >
 > http://tinyurl.com/4xlrvf9

I tried but couldn't repeat it here.  Do I need the latest sources of
anything?  Mine are from end of June.

martin

Re: window.el modify current emacs23 behavior of anything.

[Thierry Volpiatto]

martin rudalics <rudalics@gmx.at> writes:

>> point doesn't move when trying to switch to a buffer at an other
>> position than the current one, when starting with `anything-samewindow'
>> enabled.
>> This is working fine in emacs23 but not here in last trunk.
>> Would be great to have same behavior as emacs23.
>>
>> Martin, maybe you could have a look at this and give a try:
>>
>> http://tinyurl.com/4xlrvf9
>
> I tried but couldn't repeat it here.  Do I need the latest sources of
> anything?  Mine are from end of June.
Yes please, use the last sources, i did a lot of changes since june.

-- 
A+ Thierry
Get my Gnupg key:
gpg --keyserver pgp.mit.edu --recv-keys 59F29997 

Re: window.el modify current emacs23 behavior of anything.

[martin rudalics]

> point doesn't move when trying to switch to a buffer at an other
> position than the current one, when starting with `anything-samewindow'
> enabled.
> This is working fine in emacs23 but not here in last trunk.
> Would be great to have same behavior as emacs23.

Hopefully behaves as in emacs23 now.  Please try again.

martin

Re: window.el modify current emacs23 behavior of anything.

[Thierry Volpiatto]

martin rudalics <rudalics@gmx.at> writes:

>> point doesn't move when trying to switch to a buffer at an other
>> position than the current one, when starting with `anything-samewindow'
>> enabled.
>> This is working fine in emacs23 but not here in last trunk.
>> Would be great to have same behavior as emacs23.
>
> Hopefully behaves as in emacs23 now.  Please try again.
Thanks Martin, i will not be able to try until next week.
I will tell you then.

-- 
A+ Thierry
Get my Gnupg key:
gpg --keyserver pgp.mit.edu --recv-keys 59F29997 

Re: window.el modify current emacs23 behavior of anything.

[Thierry Volpiatto]

martin rudalics <rudalics@gmx.at> writes:

>> point doesn't move when trying to switch to a buffer at an other
>> position than the current one, when starting with `anything-samewindow'
>> enabled.
>> This is working fine in emacs23 but not here in last trunk.
>> Would be great to have same behavior as emacs23.
>
> Hopefully behaves as in emacs23 now.  Please try again.

I could get an internet connection and pull Emacs today.
Nothing have changed, the bug is always here.
The problem is the call of `bury-buffer' in `anything-cleanup'.
`bury-buffer' called with arg works as expected (It's why it was working
in your old anything of June), but fail when called with no arg.
I need to call it with no arg to be sure anything-buffer is removed from
it's window in some other use cases (e.g a dedicated window in another
frame).

So writing something like:

(if anything-samewindow (bury-buffer anything-window) (bury-buffer))

Fix this issue but create annoyances in other cases.

The best for me would be to use:

(bury-buffer)

This works as expected in Emacs23 in all use cases.

-- 
A+ Thierry
Get my Gnupg key:
gpg --keyserver pgp.mit.edu --recv-keys 59F29997 

Re: window.el modify current emacs23 behavior of anything.

[martin rudalics]

 > `bury-buffer' called with arg works as expected (It's why it was working
 > in your old anything of June), but fail when called with no arg.

What does that mean "fails when called with no arg".  What did you
expect it to do and what does it do instead?

martin

Re: window.el modify current emacs23 behavior of anything.

[Thierry Volpiatto]

martin rudalics <rudalics@gmx.at> writes:

>> `bury-buffer' called with arg works as expected (It's why it was working
>> in your old anything of June), but fail when called with no arg.
>
> What does that mean "fails when called with no arg".  What did you
> expect it to do and what does it do instead?

When `bury-buffer' is called, normally the anything-buffer is removed
from window and the action function move the position to the desired
position in the `anything-current-buffer' (generaly, it can be another
buffer), in this case the action is ibuffer.  See the thread on anything
mailing list.

Actually with the Emacs24 trunk, when `bury-buffer' is called with no
arg:

(bury-buffer)
the action doesn't move the point to the desired place.

When doing (always in anything-cleanup):

(bury-buffer) (sit-for 0.1)

or

(bury-buffer anything-buffer)

It is working fine.


-- 
A+ Thierry
Get my Gnupg key:
gpg --keyserver pgp.mit.edu --recv-keys 59F29997 

Re: window.el modify current emacs23 behavior of anything.

[martin rudalics]

 >> What does that mean "fails when called with no arg".  What did you
 >> expect it to do and what does it do instead?
 >
 > When `bury-buffer' is called, normally the anything-buffer is removed
 > from window and the action function move the position to the desired
 > position in the `anything-current-buffer' (generaly, it can be another
 > buffer), in this case the action is ibuffer.

What is an "action function" and what is the "desired position" in the
`anything-current-buffer'?  I suppose `bury-buffer' does restore the old
position the buffer shown instead of the buried buffer had in that
window before the buried buffer was shown.  So the sequence is
apparently

(1) Window W shows buffer B with window-start S and window-point P.

(2) In W you show buffer BB instead.

(3) You bury buffer BB.  `bury-buffer' now shows buffer B again with
     window-point P and, if possible, window-start S.

But for some reason after (3) you want to show B with another
`window-point' position.  Is that analysis correct?

martin

Re: window.el modify current emacs23 behavior of anything.

[Thierry Volpiatto]

martin rudalics <rudalics@gmx.at> writes:

>>> What does that mean "fails when called with no arg".  What did you
>>> expect it to do and what does it do instead?
>>
>> When `bury-buffer' is called, normally the anything-buffer is removed
>> from window and the action function move the position to the desired
>> position in the `anything-current-buffer' (generaly, it can be another
>> buffer), in this case the action is ibuffer.
>
> What is an "action function" and what is the "desired position" in the
> `anything-current-buffer'?  I suppose `bury-buffer' does restore the old
> position the buffer shown instead of the buried buffer had in that
> window before the buried buffer was shown.  So the sequence is
> apparently
>
> (1) Window W shows buffer B with window-start S and window-point P.
>
> (2) In W you show buffer BB instead.
>
> (3) You bury buffer BB.  `bury-buffer' now shows buffer B again with
>     window-point P and, if possible, window-start S.
>
> But for some reason after (3) you want to show B with another
> `window-point' position.  Is that analysis correct?

Yes that is correct.

The action function is the function that jump to another position than
the initial one in buffer B.
Where buffer B is `anything-current-buffer' and BB is `anything-buffer'

To reproduce with anything from any .el file:

M-: (setq anything-samewindow t)
M-x anything-imenu
Jump to any position far of your initial one in this buffer.

-- 
A+ Thierry
Get my Gnupg key:
gpg --keyserver pgp.mit.edu --recv-keys 59F29997 

Re: window.el modify current emacs23 behavior of anything.

[martin rudalics]

 >> (1) Window W shows buffer B with window-start S and window-point P.
 >>
 >> (2) In W you show buffer BB instead.
 >>
 >> (3) You bury buffer BB.  `bury-buffer' now shows buffer B again with
 >>     window-point P and, if possible, window-start S.
 >>
 >> But for some reason after (3) you want to show B with another
 >> `window-point' position.  Is that analysis correct?
 >
 > Yes that is correct.
 >
 > The action function is the function that jump to another position than
 > the initial one in buffer B.

What is "the initial position in buffer B"?  The one of `point'?

 > Where buffer B is `anything-current-buffer' and BB is `anything-buffer'

So apparently the window of `anything-buffer' is selected, you bury
`anything-buffer', and `bury-buffer' shows `anything-current-buffer'
instead with a `window-point' you don't like.  What does the action
function do next?

martin

Re: window.el modify current emacs23 behavior of anything.

[Thierry Volpiatto]

martin rudalics <rudalics@gmx.at> writes:

>>> (1) Window W shows buffer B with window-start S and window-point P.
>>>
>>> (2) In W you show buffer BB instead.
>>>
>>> (3) You bury buffer BB.  `bury-buffer' now shows buffer B again with
>>>     window-point P and, if possible, window-start S.
>>>
>>> But for some reason after (3) you want to show B with another
>>> `window-point' position.  Is that analysis correct?
>>
>> Yes that is correct.
>>
>> The action function is the function that jump to another position than
>> the initial one in buffer B.
>
> What is "the initial position in buffer B"?  The one of `point'?
Yes the one of `point'.

>> Where buffer B is `anything-current-buffer' and BB is `anything-buffer'
>
> So apparently the window of `anything-buffer' is selected, you bury
> `anything-buffer', and `bury-buffer' shows `anything-current-buffer'
> instead with a `window-point' you don't like.  What does the action
> function do next?
The `anything-buffer' disapear from window, the
`anything-current-buffer' is shown with the original position of `point'
and the action function should jump to another position. 

IIRC i had same problem before with `anything-current-position', i fixed
with the optional arg NOFORCE of `set-window-start'.
It was this time to restore an initial position in
`anything-current-buffer'.
Again a `sit-for' call before was also working.

Starting from Wednesday, i will be at home and in a better position to
debug this.

-- 
A+ Thierry
Get my Gnupg key:
gpg --keyserver pgp.mit.edu --recv-keys 59F29997 

Re: window.el modify current emacs23 behavior of anything.

[Stefan Monnier]

> The `anything-buffer' disapear from window, the
> `anything-current-buffer' is shown with the original position of
> `point' and the action function should jump to another position.

So, IIUC this problem appears in a content where only one window is
involved, and the point movements are always applied to the
(window-buffer (selected-window)), is that right?

I hope it's not, in which case it can be explained by the usual issue
that moving point won't affect window-point if the current-buffer is not
(window-buffer (selected-window)).


        Stefan

Re: window.el modify current emacs23 behavior of anything.

[martin rudalics]

 > So, IIUC this problem appears in a content where only one window is
 > involved, and the point movements are always applied to the
 > (window-buffer (selected-window)), is that right?
 >
 > I hope it's not, in which case it can be explained by the usual issue
 > that moving point won't affect window-point if the current-buffer is not
 > (window-buffer (selected-window)).

When `bury-buffer' restores the buffer previously shown in the selected
window, it also restores that buffer's `window-start' and `window-point'
position in the window.  If the window is selected, this implicitly
moves the buffer's point to the window's point.  This means that if the
restored buffer's point was changed before calling `bury-buffer', that
position is lost.

I don't know whether this is the cause of Thierry's problem.  If it is,
and people think it is the wrong thing to do in this case, I can make
`bury-buffer' (and `replace-buffer-in-windows') call `other-buffer' as
before.  Alternatively, I could try to not restore `window-start' and
`window-point' if the restored buffer does not appear on another window.
But I'm not sure how intuitive such a change would be.

martin

Re: window.el modify current emacs23 behavior of anything.

[Stefan Monnier]

> When `bury-buffer' restores the buffer previously shown in the selected
> window, it also restores that buffer's `window-start' and `window-point'
> position in the window.  If the window is selected, this implicitly
> moves the buffer's point to the window's point.  This means that if the
> restored buffer's point was changed before calling `bury-buffer', that
> position is lost.

Oh, I see the problem:

Try M-: (progn (set-window-start (selected-window) (point)) (goto-char (point-min)))

and you'll see the that set-window-point wins even though it's run
before the goto-char.

That's why a sit-for works around the problem: it causes the
set-window-start to be "executed", letting the subsequent goto-char do
its job.

So maybe the right fix is to remove the call to set-window-start.


        Stefan

Re: window.el modify current emacs23 behavior of anything.

[Thierry Volpiatto]

Stefan Monnier <monnier@IRO.UMontreal.CA> writes:

>> When `bury-buffer' restores the buffer previously shown in the selected
>> window, it also restores that buffer's `window-start' and `window-point'
>> position in the window.  If the window is selected, this implicitly
>> moves the buffer's point to the window's point.  This means that if the
>> restored buffer's point was changed before calling `bury-buffer', that
>> position is lost.
>
> Oh, I see the problem:
>
> Try M-: (progn (set-window-start (selected-window) (point)) (goto-char (point-min)))
>
> and you'll see the that set-window-point wins even though it's run
> before the goto-char.
>
> That's why a sit-for works around the problem: it causes the
> set-window-start to be "executed", letting the subsequent goto-char do
> its job.
>
> So maybe the right fix is to remove the call to set-window-start.

Using the NOFORCE arg of `set-window-start' seem to fix problem in
anything, but don't know if it can create problems in other places:

#+BEGIN_SRC lisp

(defun set-window-buffer-start-and-point (window buffer &optional start point)
  "Set WINDOW's buffer to BUFFER.
Optional argument START non-nil means set WINDOW's start position
to START.  Optional argument POINT non-nil means set WINDOW's
point to POINT.  If WINDOW is selected this also sets BUFFER's
`point' to POINT.  If WINDOW is selected and the buffer it showed
before was current this also makes BUFFER the current buffer."
  (let ((selected (eq window (selected-window)))
	(current (eq (window-buffer window) (current-buffer))))
    (set-window-buffer window buffer)
    (when (and selected current)
      (set-buffer buffer))
    (when start
      (set-window-start window start t)) ;; Use noforce arg.
    (when point
      (if selected
	  (with-current-buffer buffer
	    (goto-char point))
	(set-window-point window point)))))

#+END_SRC

`set-window-buffer-start-and-point' is called by
`switch-to-prev-buffer' which is called by `bury-buffer'.


-- 
A+ Thierry
Get my Gnupg key:
gpg --keyserver pgp.mit.edu --recv-keys 59F29997 

Re: window.el modify current emacs23 behavior of anything.

[martin rudalics]

 >> So maybe the right fix is to remove the call to set-window-start.
 >
 > Using the NOFORCE arg of `set-window-start' seem to fix problem in
 > anything, but don't know if it can create problems in other places:

On the contrary.  It should fix problems in other places.  I always
thought of `set-window-start' having a FORCE argument.

Thanks, martin

Re: window.el modify current emacs23 behavior of anything.

[martin rudalics]

 > Try M-: (progn (set-window-start (selected-window) (point)) (goto-char (point-min)))
 >
 > and you'll see the that set-window-point

... you mean `set-window-start' here I suppose ...

 > wins even though it's run
 > before the goto-char.
 >
 > That's why a sit-for works around the problem: it causes the
 > set-window-start to be "executed", letting the subsequent goto-char do
 > its job.

Indeed.  Thanks for the explanation :-)

 > So maybe the right fix is to remove the call to set-window-start.

I did as Thierry suggested: Call `set-window-start' with NOFORCE
non-nil.

martin

Re: window.el modify current emacs23 behavior of anything.

[Stefan Monnier]

>> Try M-: (progn (set-window-start (selected-window) (point)) (goto-char (point-min)))
>> and you'll see the that set-window-point
> ... you mean `set-window-start' here I suppose ...

Indeed.

>> So maybe the right fix is to remove the call to set-window-start.
> I did as Thierry suggested: Call `set-window-start' with NOFORCE
> non-nil.

Even better, yes, I had forgotten about this little option,


        Stefan

Re: window.el modify current emacs23 behavior of anything.

[Dmitry Gutov]

(Original reporter here)

martin rudalics <address@hidden> writes:
 > Hopefully behaves as in emacs23 now.  Please try again.

I'm still seeing the problem, tested revision 105782.

 > I tried but couldn't repeat it here.

Have you tried the exact scenario I described?

If the target point is close enough to the current point, it works for 
me, too.

Regards,
Dmitry.