GNU bug report logs - #60381
[PATCH] Preserve Window Position with Proced

Previous Next

Package: emacs;

Reported by: Laurence Warne <laurencewarne <at> gmail.com>

Date: Wed, 28 Dec 2022 15:56:02 UTC

Severity: normal

Tags: patch

Done: Eli Zaretskii <eliz <at> gnu.org>

Bug is archived. No further changes may be made.

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 60381 in the body.
You can then email your comments to 60381 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

View this report as an mbox folder, status mbox, maintainer mbox


Report forwarded to bug-gnu-emacs <at> gnu.org:
bug#60381; Package emacs. (Wed, 28 Dec 2022 15:56:02 GMT) Full text and rfc822 format available.

Acknowledgement sent to Laurence Warne <laurencewarne <at> gmail.com>:
New bug report received and forwarded. Copy sent to bug-gnu-emacs <at> gnu.org. (Wed, 28 Dec 2022 15:56:02 GMT) Full text and rfc822 format available.

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

From: Laurence Warne <laurencewarne <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: [PATCH] Preserve Window Position with Proced
Date: Wed, 28 Dec 2022 15:55:20 +0000
[Message part 1 (text/plain, inline)]
Hi,

This patch fixes a minor issue with proced buffers.  Previously, the window
position would be set to the start of the buffer when a proced buffer was
updated and it was not displayed in the selected window.  To reproduce:

(require 'proced)
(setq-default proceed-auto-update-flag t)
(M-x proced)

Move down to the next process, then change to a different window, and wait
a bit.  You should see the point in the proced buffer move back to the
beginning of the buffer. A similar issue occurs when the proced buffer is
not displayed in any window.

This patch addresses this by setting the window point (if applicable)
whenever a proced buffer is updated, and the second issue by not updating a
proced buffer if it is not displayed in any window.

I tried to add a test for this, but for example this:

(ert-deftest proced-update-preserves-point-test ()
  (proced--within-buffer
   'medium
   'user
   (proced--move-to-column "PID")
   (let ((point (window-point))
         (window (split-window)))
     (select-window window)
     (bury-buffer)
     (with-current-buffer "*Proced*"
       (proced-update t t))
     (switch-to-buffer "*Proced*")
     (should (= point (window-point))))))

passes even without this patch (though if I step through it with
edebug-defun it fails as expected).

Thanks, Laurence
[Message part 2 (text/html, inline)]
[0001-Preserve-the-window-position-with-proced.patch (text/x-patch, attachment)]

Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#60381; Package emacs. (Wed, 28 Dec 2022 17:15:02 GMT) Full text and rfc822 format available.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Laurence Warne <laurencewarne <at> gmail.com>
Cc: 60381 <at> debbugs.gnu.org
Subject: Re: bug#60381: [PATCH] Preserve Window Position with Proced
Date: Wed, 28 Dec 2022 19:14:29 +0200
> From: Laurence Warne <laurencewarne <at> gmail.com>
> Date: Wed, 28 Dec 2022 15:55:20 +0000
> 
> This patch addresses this by setting the window point (if applicable) whenever a proced buffer is updated,
> and the second issue by not updating a proced buffer if it is not displayed in any window.

I don't think I like the solution for the second issue, since it is a
backward-incompatible change.  It is not at all obvious that not
updating a proced buffer which isn't shown in a window is TRT.

Why cannot we simply save and restore point across updates?  If the
old value of point ends up in a slightly different position (because
many processes have died, for example), that is not a disaster.

Alternatively, record the process on whose line point was before the
update, and try to find the same process after update.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#60381; Package emacs. (Wed, 28 Dec 2022 20:31:02 GMT) Full text and rfc822 format available.

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

From: Laurence Warne <laurencewarne <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 60381 <at> debbugs.gnu.org
Subject: Re: bug#60381: [PATCH] Preserve Window Position with Proced
Date: Wed, 28 Dec 2022 20:30:41 +0000
[Message part 1 (text/plain, inline)]
> I don't think I like the solution for the second issue, since it is a
> backward-incompatible change.  It is not at all obvious that not
> updating a proced buffer which isn't shown in a window is TRT.

Fair enough, I'll revert this and try and think of another solution.

> Alternatively, record the process on whose line point was before the
> update, and try to find the same process after update.

I believe this is currently what proced-update tries to do, it works as
expected when an update occurs and the buffer is displayed in the selected
window (so if the process your point is on moves down a row, the point will
follow), but when the buffer is not displayed in the selected window, I
find the point is always reset to the beginning of the buffer regardless of
the process which was under point prior to the update.  In the end of
proced-update, the patch sets all the window points to the new buffer point
(recently set by proced-update to reflect the position of the new process),
similar to what append-to-buffer does, if that makes sense.
[Message part 2 (text/html, inline)]

Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#60381; Package emacs. (Thu, 29 Dec 2022 06:09:02 GMT) Full text and rfc822 format available.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Laurence Warne <laurencewarne <at> gmail.com>
Cc: 60381 <at> debbugs.gnu.org
Subject: Re: bug#60381: [PATCH] Preserve Window Position with Proced
Date: Thu, 29 Dec 2022 08:09:01 +0200
> From: Laurence Warne <laurencewarne <at> gmail.com>
> Date: Wed, 28 Dec 2022 20:30:41 +0000
> Cc: 60381 <at> debbugs.gnu.org
> 
> > Alternatively, record the process on whose line point was before the
> > update, and try to find the same process after update.
> 
> I believe this is currently what proced-update tries to do, it works as expected when an update occurs and
> the buffer is displayed in the selected window (so if the process your point is on moves down a row, the
> point will follow), but when the buffer is not displayed in the selected window, I find the point is always reset
> to the beginning of the buffer regardless of the process which was under point prior to the update.

This sounds like some kind of bug, or perhaps we have some knob to
control this behavior.  So I think you should investigate why the
difference between selected and non-select windows, and why a buffer
that is not displayed behaves like that.  When you find the reason(s),
we could discuss possible solutions.  The solutions you describe (both
of them, actually) sound like workarounds to me: we let Emacs do
whatever nonsensical thing it does, and the correct the results.  It
is better to find a way of avoiding the wrong behavior in the first
place.

Btw, the variable switch-to-buffer-preserve-window-point may have
something to do with at least some of the behaviors you see.

Thanks.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#60381; Package emacs. (Thu, 29 Dec 2022 12:53:02 GMT) Full text and rfc822 format available.

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

From: Laurence Warne <laurencewarne <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 60381 <at> debbugs.gnu.org
Subject: Re: bug#60381: [PATCH] Preserve Window Position with Proced
Date: Thu, 29 Dec 2022 12:52:20 +0000
[Message part 1 (text/plain, inline)]
I've logged the buffer and window point at certain lines (most important is
before/after erase-buffer on line 1911) in a few run throughs of
proced-update, first when the selected window displays a proced buffer:

before update: window point: 20121, buffer point: 20121
after goto-char min: window point: 1, buffer point: 1
before erase buffer: window point: 1, buffer point: 1
after erase buffer: window point: 1, buffer point: 1
after update: window point: 20121, buffer point: 20121

So this is expected since buffer point always mirrors window point for the
selected window's displayed buffer.  Next, when the selected window doesn't
display a proced buffer, but there does exist a window displaying a proced
buffer (the window point logged corresponds to the window point of the
window containing the proced buffer):

before update: window point: 20235, buffer point: 20235
after goto-char min: window point: 20235, buffer point: 1
before erase buffer: window point: 20235, buffer point: 1
after erase buffer: window point: 1, buffer point: 1
after update: window point: 1, buffer point: 20235

So my understanding is since the selected window does not display a proced
buffer, the window point is not updated in line with the buffer point, but
the erase-buffer call sets the window point to start of the buffer, and so
this is not updated in line with the buffer point in the subsequent
insertion of processes.

The last case (the second issue) where no window shows a proced buffer is
similar to the previous, but erase buffer instead appears to set pos for
the proced buffer's value in (window-prev-buffers) if it's the case a
window has shown a proced buffer previously.
[Message part 2 (text/html, inline)]

Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#60381; Package emacs. (Thu, 29 Dec 2022 14:10:02 GMT) Full text and rfc822 format available.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Laurence Warne <laurencewarne <at> gmail.com>
Cc: 60381 <at> debbugs.gnu.org
Subject: Re: bug#60381: [PATCH] Preserve Window Position with Proced
Date: Thu, 29 Dec 2022 16:09:30 +0200
> From: Laurence Warne <laurencewarne <at> gmail.com>
> Date: Thu, 29 Dec 2022 12:52:20 +0000
> Cc: 60381 <at> debbugs.gnu.org
> 
> before update: window point: 20235, buffer point: 20235
> after goto-char min: window point: 20235, buffer point: 1
> before erase buffer: window point: 20235, buffer point: 1
> after erase buffer: window point: 1, buffer point: 1
> after update: window point: 1, buffer point: 20235
> 
> So my understanding is since the selected window does not display a proced buffer, the window point is not
> updated in line with the buffer point, but the erase-buffer call sets the window point to start of the buffer, and
> so this is not updated in line with the buffer point in the subsequent insertion of processes.

Why cannot proced update point when the window is not the selected
one?

> The last case (the second issue) where no window shows a proced buffer is similar to the previous, but
> erase buffer instead appears to set pos for the proced buffer's value in (window-prev-buffers) if it's the case
> a window has shown a proced buffer previously.

Same question here.

And I don't think I understand how the above explains why searching
for the same process also fails.  That should be independent of
whether the buffer is displayed in the selected window or in any
window.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#60381; Package emacs. (Thu, 29 Dec 2022 17:38:01 GMT) Full text and rfc822 format available.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Laurence Warne <laurencewarne <at> gmail.com>
Cc: 60381 <at> debbugs.gnu.org
Subject: Re: bug#60381: [PATCH] Preserve Window Position with Proced
Date: Thu, 29 Dec 2022 19:37:21 +0200
[Why private email?]

> From: Laurence Warne <laurencewarne <at> gmail.com>
> Date: Thu, 29 Dec 2022 17:07:42 +0000
> 
> > Why cannot proced update point when the window is not the selected
> > one?
> 
> Say window A is displaying a proced buffer and is not selected.  Unless my understanding from
> https://www.gnu.org/software/emacs/manual/html_node/elisp/Window-Point.html is wrong, whenever
> proced-update uses goto-char, it would not update the window point in window A, but erase-buffer would, by
> setting the window point of A to the beginning of the buffer.

You need to use set-window-point in that case, yes.  But if the buffer
is not displayed, there should be no problem, and at most you will
have to set the local value of switch-to-buffer-preserve-window-point
to nil in proced buffers.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#60381; Package emacs. (Thu, 05 Jan 2023 16:01:02 GMT) Full text and rfc822 format available.

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

From: Laurence Warne <laurencewarne <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 60381 <at> debbugs.gnu.org
Subject: Re: bug#60381: [PATCH] Preserve Window Position with Proced
Date: Thu, 5 Jan 2023 15:59:57 +0000
[Message part 1 (text/plain, inline)]
Hi,

Minor update, whilst working on the first case, I've come across some
strange behaviour which causes the window position to be reset to
(point-min) in some circumstances.  To reproduce this with a more minimal
setup than proced-update (I've also asked here:
https://emacs.stackexchange.com/questions/75165/window-point-reset-after-update
):

(defun example ()
  (interactive)
  (let* ((buf (get-buffer-create "*Example*"))
         (w-points (mapcar (lambda (win)
                             `(,win . ,(window-point win)))
                           (get-buffer-window-list buf))))
    (with-current-buffer buf
      (let ((buf-point (point)))
        (erase-buffer)
        (insert "line1\nline2\nline3\nline4\nline5")
        (goto-char buf-point)
        (mapc (lambda (wp) (set-window-point (car wp) (cdr wp))) w-points)))
    (message "Ran update")))

(setq example-timer (run-at-time t 5 #'example))

Now with a configuration of two windows, switch to the example buffer in
one of them, and move down a few lines. Switch to the other window, you
should see the window point stay the same after every update.

If you then invoke M-x, wait for an update to occur, and then cancel the
invocation using C-g, then you should see the point in the window
displaying the example buffer go back to the start of the window. I've
created a video here:
https://user-images.githubusercontent.com/17688577/210167335-f7a4d50f-dbaf-4ffc-b1e0-38c5612ed2e3.mp4.
I'm a bit confused by this, any pointers would be greatly appreciated.
On the upside, I've managed to put together a test which won't pass without
the patch.

In terms of the difference between this patch and the original, the new
patch maintains the window point for all windows which display a proced
buffer.  The original just set the window point for one, as a consequence
all windows displaying the proced buffer in question would have their point
set to the most recently visited window displaying the buffer.   I've had
to extract out some logic from proced-update to separate functions, and so
this patch is a bit more invasive.

Thanks, Laurence
[Message part 2 (text/html, inline)]
[0001-Preserve-the-window-position-with-proced.patch (text/x-patch, attachment)]

Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#60381; Package emacs. (Sat, 07 Jan 2023 09:29:01 GMT) Full text and rfc822 format available.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Laurence Warne <laurencewarne <at> gmail.com>
Cc: 60381 <at> debbugs.gnu.org
Subject: Re: bug#60381: [PATCH] Preserve Window Position with Proced
Date: Sat, 07 Jan 2023 11:28:38 +0200
> From: Laurence Warne <laurencewarne <at> gmail.com>
> Date: Thu, 5 Jan 2023 15:59:57 +0000
> Cc: 60381 <at> debbugs.gnu.org
> 
> Minor update, whilst working on the first case, I've come across some strange behaviour which causes the
> window position to be reset to (point-min) in some circumstances.  To reproduce this with a more minimal
> setup than proced-update (I've also asked here:
> https://emacs.stackexchange.com/questions/75165/window-point-reset-after-update):

It is not easy to understand the convoluted example, but did you try
to see whether switch-to-buffer-preserve-window-point has any effect
on the behavior you consider strange?




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#60381; Package emacs. (Sat, 07 Jan 2023 11:59:01 GMT) Full text and rfc822 format available.

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

From: Laurence Warne <laurencewarne <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 60381 <at> debbugs.gnu.org
Subject: Re: bug#60381: [PATCH] Preserve Window Position with Proced
Date: Sat, 7 Jan 2023 11:58:28 +0000
[Message part 1 (text/plain, inline)]
> It is not easy to understand the convoluted example, but did you try
> to see whether switch-to-buffer-preserve-window-point has any effect
> on the behavior you consider strange?

After some more debugging, I found setting read-minibuffer-restore-windows
to nil gave the desired behaviour.

From the doc for read-minibuffer-restore-windows : "Non-nil means restore
window configurations on exit from minibuffer."  I guess this includes
window points as well - so this is expected behaviour in that changes to
the window configuration as a result of a timer run whilst the minibuffer
is active are reverted?
[Message part 2 (text/html, inline)]

Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#60381; Package emacs. (Sat, 07 Jan 2023 13:28:01 GMT) Full text and rfc822 format available.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Laurence Warne <laurencewarne <at> gmail.com>
Cc: 60381 <at> debbugs.gnu.org
Subject: Re: bug#60381: [PATCH] Preserve Window Position with Proced
Date: Sat, 07 Jan 2023 15:28:09 +0200
> From: Laurence Warne <laurencewarne <at> gmail.com>
> Date: Sat, 7 Jan 2023 11:58:28 +0000
> Cc: 60381 <at> debbugs.gnu.org
> 
> After some more debugging, I found setting read-minibuffer-restore-windows to nil gave the desired
> behaviour.
> 
> From the doc for read-minibuffer-restore-windows : "Non-nil means restore window configurations on exit
> from minibuffer."  I guess this includes window points as well - so this is expected behaviour in that changes
> to the window configuration as a result of a timer run whilst the minibuffer is active are reverted?

Yes, this is the expected behavior in that case.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#60381; Package emacs. (Sat, 07 Jan 2023 17:24:01 GMT) Full text and rfc822 format available.

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

From: Laurence Warne <laurencewarne <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 60381 <at> debbugs.gnu.org
Subject: Re: bug#60381: [PATCH] Preserve Window Position with Proced
Date: Sat, 7 Jan 2023 17:23:36 +0000
[Message part 1 (text/plain, inline)]
Cool, I think I've now fixed the second issue (preserving the position in
proced buffers which are not displayed in any window) using your suggestion
of setting switch-to-buffer-preserve-window-point locally to nil in proced
buffers.  I've attached a new patch, the same as the previous one but with
one line change for the above.
[Message part 2 (text/html, inline)]
[0001-Preserve-the-window-position-with-proced.patch (text/x-patch, attachment)]

Reply sent to Eli Zaretskii <eliz <at> gnu.org>:
You have taken responsibility. (Sat, 14 Jan 2023 08:42:01 GMT) Full text and rfc822 format available.

Notification sent to Laurence Warne <laurencewarne <at> gmail.com>:
bug acknowledged by developer. (Sat, 14 Jan 2023 08:42:01 GMT) Full text and rfc822 format available.

Message #43 received at 60381-done <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Laurence Warne <laurencewarne <at> gmail.com>
Cc: 60381-done <at> debbugs.gnu.org
Subject: Re: bug#60381: [PATCH] Preserve Window Position with Proced
Date: Sat, 14 Jan 2023 10:40:58 +0200
> From: Laurence Warne <laurencewarne <at> gmail.com>
> Date: Sat, 7 Jan 2023 17:23:36 +0000
> Cc: 60381 <at> debbugs.gnu.org
> 
> Cool, I think I've now fixed the second issue (preserving the position in proced buffers which are not
> displayed in any window) using your suggestion of setting switch-to-buffer-preserve-window-point locally to
> nil in proced buffers.  I've attached a new patch, the same as the previous one but with one line change for
> the above.

Thanks, installed, and closing the bug.




bug archived. Request was from Debbugs Internal Request <help-debbugs <at> gnu.org> to internal_control <at> debbugs.gnu.org. (Sat, 11 Feb 2023 12:24:12 GMT) Full text and rfc822 format available.

This bug report was last modified 1 year and 45 days ago.

Previous Next


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