GNU bug report logs -
#33871
27.0.50; Revert Dired window saved in window configuration
Previous Next
Reported by: Juri Linkov <juri <at> linkov.net>
Date: Tue, 25 Dec 2018 21:43:01 UTC
Severity: minor
Found in version 27.0.50
Fixed in version 30.0.50
Done: Juri Linkov <juri <at> linkov.net>
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 33871 in the body.
You can then email your comments to 33871 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#33871; Package
emacs.
(Tue, 25 Dec 2018 21:43:01 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Juri Linkov <juri <at> linkov.net>:
New bug report received and forwarded. Copy sent to
bug-gnu-emacs <at> gnu.org.
(Tue, 25 Dec 2018 21:43:02 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
Try to eval in emacs -Q in *scratch*:
(progn (dired "/tmp") (dired-next-line 1)
(split-window) (other-window 1)
(dired "/tmp") (dired-next-line 2)
(let ((w-c (current-window-configuration))
(p-m (point-marker)))
(view-emacs-todo) (delete-other-windows)
(with-current-buffer (get-buffer "tmp")
(revert-buffer))
(set-window-configuration w-c)
(goto-char p-m)))
Result:
- point in the selected Dired window moves to point-min
- point in the non-selected Dired window moves to point-max
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#33871; Package
emacs.
(Wed, 26 Dec 2018 09:44:01 GMT)
Full text and
rfc822 format available.
Message #8 received at 33871 <at> debbugs.gnu.org (full text, mbox):
> Try to eval in emacs -Q in *scratch*:
>
> (progn (dired "/tmp") (dired-next-line 1)
> (split-window) (other-window 1)
> (dired "/tmp") (dired-next-line 2)
> (let ((w-c (current-window-configuration))
> (p-m (point-marker)))
> (view-emacs-todo) (delete-other-windows)
> (with-current-buffer (get-buffer "tmp")
> (revert-buffer))
> (set-window-configuration w-c)
> (goto-char p-m)))
>
> Result:
> - point in the selected Dired window moves to point-min
> - point in the non-selected Dired window moves to point-max
You're obfuscating the underlying behavior with the 'dired-next-line'
and 'goto-char' calls but the final points are different without that.
Without your explicit moves, `dired' moves to the first file name in
the lower directory here. So 'dired-move-to-filename' was called when
reverting the buffer and the 'set-window-configuration' "restores" the
lower window's point from the buffer's point because that window is
the selected one. To confirm, try with the upper window selected
instead.
martin
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#33871; Package
emacs.
(Thu, 27 Dec 2018 00:16:02 GMT)
Full text and
rfc822 format available.
Message #11 received at 33871 <at> debbugs.gnu.org (full text, mbox):
>> Try to eval in emacs -Q in *scratch*:
>>
>> (progn (dired "/tmp") (dired-next-line 1)
>> (split-window) (other-window 1)
>> (dired "/tmp") (dired-next-line 2)
>> (let ((w-c (current-window-configuration))
>> (p-m (point-marker)))
>> (view-emacs-todo) (delete-other-windows)
>> (with-current-buffer (get-buffer "tmp")
>> (revert-buffer))
>> (set-window-configuration w-c)
>> (goto-char p-m)))
>>
>> Result:
>> - point in the selected Dired window moves to point-min
>> - point in the non-selected Dired window moves to point-max
>
> You're obfuscating the underlying behavior with the 'dired-next-line'
> and 'goto-char' calls but the final points are different without that.
>
> Without your explicit moves, `dired' moves to the first file name in
> the lower directory here. So 'dired-move-to-filename' was called when
> reverting the buffer and the 'set-window-configuration' "restores" the
> lower window's point from the buffer's point because that window is
> the selected one.
I see that without `goto-char' it moves to the first file name in the
selected window. I don't understand how 'set-window-configuration' restores
the selected window's point.
> To confirm, try with the upper window selected instead.
Here is when the upper window is selected, but still it moves to (point-max)
in non-selected window:
(progn (dired "/tmp")
(dired-other-window "/tmp") (other-window 1)
(let ((w-c (current-window-configuration))
(p-m (point-marker)))
(view-emacs-todo) (delete-other-windows)
(with-current-buffer (get-buffer "tmp")
(revert-buffer))
(set-window-configuration w-c)))
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#33871; Package
emacs.
(Thu, 27 Dec 2018 09:38:03 GMT)
Full text and
rfc822 format available.
Message #14 received at 33871 <at> debbugs.gnu.org (full text, mbox):
> I see that without `goto-char' it moves to the first file name in the
> selected window.
I see the same here. In the selected window only, though.
> I don't understand how 'set-window-configuration' restores
> the selected window's point.
From the buffer's point as established by the revert function of dired
for buffers not displayed anywhere.
>> To confirm, try with the upper window selected instead.
>
> Here is when the upper window is selected, but still it moves to (point-max)
> in non-selected window:
>
> (progn (dired "/tmp")
> (dired-other-window "/tmp") (other-window 1)
> (let ((w-c (current-window-configuration))
> (p-m (point-marker)))
> (view-emacs-todo) (delete-other-windows)
> (with-current-buffer (get-buffer "tmp")
> (revert-buffer))
> (set-window-configuration w-c)))
In every non-selected window. Try with as many windows as you want.
Only the selected window is handled separately.
martin
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#33871; Package
emacs.
(Thu, 27 Dec 2018 21:46:02 GMT)
Full text and
rfc822 format available.
Message #17 received at 33871 <at> debbugs.gnu.org (full text, mbox):
>> I see that without `goto-char' it moves to the first file name in the
>> selected window.
>
> I see the same here. In the selected window only, though.
>
>> I don't understand how 'set-window-configuration' restores
>> the selected window's point.
>
> From the buffer's point as established by the revert function of dired
> for buffers not displayed anywhere.
So the revert function doesn't use markers? Maybe then
set-window-configuration should not use markers too?
>>> To confirm, try with the upper window selected instead.
>>
>> Here is when the upper window is selected, but still it moves to (point-max)
>> in non-selected window:
>>
>> (progn (dired "/tmp")
>> (dired-other-window "/tmp") (other-window 1)
>> (let ((w-c (current-window-configuration))
>> (p-m (point-marker)))
>> (view-emacs-todo) (delete-other-windows)
>> (with-current-buffer (get-buffer "tmp")
>> (revert-buffer))
>> (set-window-configuration w-c)))
>
> In every non-selected window. Try with as many windows as you want.
> Only the selected window is handled separately.
A bug?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#33871; Package
emacs.
(Fri, 28 Dec 2018 08:35:02 GMT)
Full text and
rfc822 format available.
Message #20 received at 33871 <at> debbugs.gnu.org (full text, mbox):
> So the revert function doesn't use markers? Maybe then
> set-window-configuration should not use markers too?
'dired-revert' is spcecial. There's nothing we can conclude from it.
>>> Here is when the upper window is selected, but still it moves to (point-max)
>>> in non-selected window:
>>>
>>> (progn (dired "/tmp")
>>> (dired-other-window "/tmp") (other-window 1)
>>> (let ((w-c (current-window-configuration))
>>> (p-m (point-marker)))
>>> (view-emacs-todo) (delete-other-windows)
>>> (with-current-buffer (get-buffer "tmp")
>>> (revert-buffer))
>>> (set-window-configuration w-c)))
>>
>> In every non-selected window. Try with as many windows as you want.
>> Only the selected window is handled separately.
>
> A bug?
As I suggested earlier we can use the position of the buffer's point
in every window regardless of whether it currently shows the buffer or
we later switch to the buffer in it. But this is not what we usually
want when using multiple windows: We usually want them to show
different portions of the same buffer.
martin
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#33871; Package
emacs.
(Sat, 29 Dec 2018 11:27:02 GMT)
Full text and
rfc822 format available.
Message #23 received at submit <at> debbugs.gnu.org (full text, mbox):
martin rudalics <rudalics <at> gmx.at> writes:
> As I suggested earlier we can use the position of the buffer's point
> in every window regardless of whether it currently shows the buffer or
> we later switch to the buffer in it. But this is not what we usually
> want when using multiple windows: We usually want them to show
> different portions of the same buffer.
In the cases I faced, I found it a drawback that the current buffer is
treated differently than the others by current-window-configuration:
Suppose it did not make such an exception. Then it would be quite easy
to manually implement exceptional behaviour for the current buffer. But
the converse is not so easy: It is harder to manually obtain the desired
behaviour if we *want* the current buffer to be treated like the others,
when the function already treats it differently. If it didn't, then a
simple save-excursion, or a similar mechanisms, around restoring the
window configuration could ostensibly restore the state for all buffers
except the current one, resulting in the same behaviour that we get now.
At least that was my impression when using window configurations.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#33871; Package
emacs.
(Sat, 29 Dec 2018 18:20:01 GMT)
Full text and
rfc822 format available.
Message #26 received at 33871 <at> debbugs.gnu.org (full text, mbox):
> In the cases I faced, I found it a drawback that the current buffer is
> treated differently than the others by current-window-configuration:
I'm not sure what precisely you mean here. 'save-window-excursion'
saves and restores the current buffer so that the restored state
replicates the saved state as closely as possible. Hence, the buffer
current when the old configuration was saved should be also current
after the old configuration has been restored, regardless of whether
it is the buffer assigned to any of the selected windows.
If you allude to the
As a special exception, the window
configuration does not record the value of point in the selected window
for the current buffer.
then this behavior is provided for historical reasons AFAICT. Most
applications using a window excursion probably did not like the cursor
jump back to the old location.
> Suppose it did not make such an exception. Then it would be quite easy
> to manually implement exceptional behaviour for the current buffer. But
> the converse is not so easy: It is harder to manually obtain the desired
> behaviour if we *want* the current buffer to be treated like the others,
> when the function already treats it differently. If it didn't, then a
> simple save-excursion, or a similar mechanisms, around restoring the
> window configuration could ostensibly restore the state for all buffers
> except the current one, resulting in the same behaviour that we get now.
> At least that was my impression when using window configurations.
It depends on what you want to handle manually. Note that if you do
not save any additional information separately, a window configuration
by itself does not give you any clue as to which buffer was current or
which window was selected at the time it was saved.
What we could do is to give 'set-window-configuration' an additional
argument which, for example, would allow to restore the selected
window's point to its saved position.
martin
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#33871; Package
emacs.
(Sat, 29 Dec 2018 23:25:02 GMT)
Full text and
rfc822 format available.
Message #29 received at 33871 <at> debbugs.gnu.org (full text, mbox):
>> So the revert function doesn't use markers? Maybe then
>> set-window-configuration should not use markers too?
>
> 'dired-revert' is special. There's nothing we can conclude from it.
image-revert is another special, as indicated by bug#33631
>>>> Here is when the upper window is selected, but still it moves to (point-max)
>>>> in non-selected window:
>>>>
>>>> (progn (dired "/tmp")
>>>> (dired-other-window "/tmp") (other-window 1)
>>>> (let ((w-c (current-window-configuration))
>>>> (p-m (point-marker)))
>>>> (view-emacs-todo) (delete-other-windows)
>>>> (with-current-buffer (get-buffer "tmp")
>>>> (revert-buffer))
>>>> (set-window-configuration w-c)))
>>>
>>> In every non-selected window. Try with as many windows as you want.
>>> Only the selected window is handled separately.
>>
>> A bug?
Do you know why it currently moves point to the end of the buffer
in non-selected windows. I don't understand what causes this behavior.
> As I suggested earlier we can use the position of the buffer's point
> in every window regardless of whether it currently shows the buffer or
> we later switch to the buffer in it. But this is not what we usually
> want when using multiple windows: We usually want them to show
> different portions of the same buffer.
Yes, better to keep every window's own point. Since usually I save
the selected window's point along with the window configuration, in e.g.
((window-configuration-1 selected-window-point)
(window-configuration-2 selected-window-point)
...)
this could be extended to save a mapping of all windows points, e.g.
((window-configuration-1 ((window-a point-a) (window-b point-b) ...))
(window-configuration-2 ...)
...)
But it's not a general solution. A general solution would be to save
such metadata in the window configuration itself.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#33871; Package
emacs.
(Sun, 30 Dec 2018 09:54:02 GMT)
Full text and
rfc822 format available.
Message #32 received at 33871 <at> debbugs.gnu.org (full text, mbox):
> image-revert is another special, as indicated by bug#33631
But there the position of point or that of its window has no impact, I
presume.
> Do you know why it currently moves point to the end of the buffer
> in non-selected windows. I don't understand what causes this behavior.
I nowlooked into it. It's a bug caused by
XMARKER (p->pointm)->insertion_type
= !NILP (buffer_local_value /* Don't signal error if void. */
(Qwindow_point_insertion_type, w->contents));
and the value of
buffer_local_value (Qwindow_point_insertion_type, w->contents)
is unbound and not nil. I have to fix that.
>> As I suggested earlier we can use the position of the buffer's point
>> in every window regardless of whether it currently shows the buffer or
>> we later switch to the buffer in it. But this is not what we usually
>> want when using multiple windows: We usually want them to show
>> different portions of the same buffer.
>
> Yes, better to keep every window's own point. Since usually I save
> the selected window's point along with the window configuration,
As number or as marker?
> in e.g.
>
> ((window-configuration-1 selected-window-point)
> (window-configuration-2 selected-window-point)
> ...)
>
> this could be extended to save a mapping of all windows points, e.g.
>
> ((window-configuration-1 ((window-a point-a) (window-b point-b) ...))
> (window-configuration-2 ...)
> ...)
>
>
> But it's not a general solution. A general solution would be to save
> such metadata in the window configuration itself.
But a configuration saves the point of each window, for the selected
one it stores the point of that window's buffer. Is it just because
you want to be able to retrieve those values? Or what am I missing?
martin
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#33871; Package
emacs.
(Sun, 30 Dec 2018 14:58:02 GMT)
Full text and
rfc822 format available.
Message #35 received at 33871 <at> debbugs.gnu.org (full text, mbox):
> I nowlooked into it. It's a bug caused by
>
> XMARKER (p->pointm)->insertion_type
> = !NILP (buffer_local_value /* Don't signal error if void. */
> (Qwindow_point_insertion_type, w->contents));
>
> and the value of
>
> buffer_local_value (Qwindow_point_insertion_type, w->contents)
>
> is unbound and not nil. I have to fix that.
I tried to fix that on master now. Please have a look.
Thanks, martin
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#33871; Package
emacs.
(Sun, 30 Dec 2018 21:32:01 GMT)
Full text and
rfc822 format available.
Message #38 received at 33871 <at> debbugs.gnu.org (full text, mbox):
>> image-revert is another special, as indicated by bug#33631
>
> But there the position of point or that of its window has no impact, I
> presume.
Yes, but there image-revert needs to know window dimensions
when the buffer is not displayed in a window - a situation
similar to dired-revert when buffer's windows are in a window
configuration.
>> Do you know why it currently moves point to the end of the buffer
>> in non-selected windows. I don't understand what causes this behavior.
>
> I nowlooked into it. It's a bug caused by
>
> XMARKER (p->pointm)->insertion_type
> = !NILP (buffer_local_value /* Don't signal error if void. */
> (Qwindow_point_insertion_type, w->contents));
>
> and the value of
>
> buffer_local_value (Qwindow_point_insertion_type, w->contents)
>
> is unbound and not nil. I have to fix that.
> I tried to fix that on master now. Please have a look.
Thanks, I confirm it's fixed.
>>> As I suggested earlier we can use the position of the buffer's point
>>> in every window regardless of whether it currently shows the buffer or
>>> we later switch to the buffer in it. But this is not what we usually
>>> want when using multiple windows: We usually want them to show
>>> different portions of the same buffer.
>>
>> Yes, better to keep every window's own point. Since usually I save
>> the selected window's point along with the window configuration,
>
> As number or as marker?
As marker. But I guess due to marker invalidation after reverting
better to use numbers, or even better to get metadata depending
on major mode, e.g. in case of Dired - dired-filename.
>> in e.g.
>>
>> ((window-configuration-1 selected-window-point)
>> (window-configuration-2 selected-window-point)
>> ...)
>>
>> this could be extended to save a mapping of all windows points, e.g.
>>
>> ((window-configuration-1 ((window-a point-a) (window-b point-b) ...))
>> (window-configuration-2 ...)
>> ...)
>>
>>
>> But it's not a general solution. A general solution would be to save
>> such metadata in the window configuration itself.
>
> But a configuration saves the point of each window, for the selected
> one it stores the point of that window's buffer. Is it just because
> you want to be able to retrieve those values? Or what am I missing?
It seems a configuration saves the point as marker, not as number, so it
invalidates on reverting. It would be better if such stored metadata also
includes dired-filenames, or even a lambda that could move point to saved
filenames in Dired buffers.
((window-configuration-1 ((dired-window-1 . `(lambda () (dired-goto-file ,(dired-get-filename))))))
(window-configuration-2 ...)
...)
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#33871; Package
emacs.
(Sat, 12 Feb 2022 08:46:01 GMT)
Full text and
rfc822 format available.
Message #41 received at 33871 <at> debbugs.gnu.org (full text, mbox):
Juri Linkov <juri <at> linkov.net> writes:
> Try to eval in emacs -Q in *scratch*:
>
> (progn (dired "/tmp") (dired-next-line 1)
> (split-window) (other-window 1)
> (dired "/tmp") (dired-next-line 2)
> (let ((w-c (current-window-configuration))
> (p-m (point-marker)))
> (view-emacs-todo) (delete-other-windows)
> (with-current-buffer (get-buffer "tmp")
> (revert-buffer))
> (set-window-configuration w-c)
> (goto-char p-m)))
>
> Result:
> - point in the selected Dired window moves to point-min
> - point in the non-selected Dired window moves to point-max
I tried this in Emacs 29, and point was point-min in both windows. But
I'm not sure where point should end up after this code, really 😀, so is
this working as expected now?
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#33871; Package
emacs.
(Sun, 13 Feb 2022 18:46:01 GMT)
Full text and
rfc822 format available.
Message #44 received at 33871 <at> debbugs.gnu.org (full text, mbox):
>> (progn (dired "/tmp") (dired-next-line 1)
>> (split-window) (other-window 1)
>> (dired "/tmp") (dired-next-line 2)
>> (let ((w-c (current-window-configuration))
>> (p-m (point-marker)))
>> (view-emacs-todo) (delete-other-windows)
>> (with-current-buffer (get-buffer "tmp")
>> (revert-buffer))
>> (set-window-configuration w-c)
>> (goto-char p-m)))
>>
>> Result:
>> - point in the selected Dired window moves to point-min
>> - point in the non-selected Dired window moves to point-max
>
> I tried this in Emacs 29, and point was point-min in both windows. But
> I'm not sure where point should end up after this code, really 😀, so is
> this working as expected now?
It should end up where it was initially, i.e. on file names in Dired.
But this can achieved only by implementing context-aware markers,
such as used by the package saveplace.el, e.g.:
((window-configuration-1
((dired-window-1 . `(lambda () (dired-goto-file ,(dired-get-filename))))))
(window-configuration-2 ...)
...)
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#33871; Package
emacs.
(Mon, 14 Feb 2022 09:14:01 GMT)
Full text and
rfc822 format available.
Message #47 received at 33871 <at> debbugs.gnu.org (full text, mbox):
> It should end up where it was initially, i.e. on file names in Dired.
> But this can achieved only by implementing context-aware markers,
> such as used by the package saveplace.el, e.g.:
>
> ((window-configuration-1
> ((dired-window-1 . `(lambda () (dired-goto-file ,(dired-get-filename))))))
> (window-configuration-2 ...)
> ...)
Reverting a directory in a window could remember the name of the file
shown at the corresponding line and the offset of 'window-point' on that
line and also the entire contents of the old directory until revert
completes. As soon as the new contents of the directory have been
established, dired would search the remembered name and position point
at the remembered offset accordingly. If it does not find that name, it
would have to compare the contents of the old and current contents of
the directory and use some heuristics to position point appropriately.
martin
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#33871; Package
emacs.
(Mon, 14 Feb 2022 18:17:01 GMT)
Full text and
rfc822 format available.
Message #50 received at 33871 <at> debbugs.gnu.org (full text, mbox):
>> It should end up where it was initially, i.e. on file names in Dired.
>> But this can achieved only by implementing context-aware markers,
>> such as used by the package saveplace.el, e.g.:
>>
>> ((window-configuration-1
>> ((dired-window-1 . `(lambda () (dired-goto-file ,(dired-get-filename))))))
>> (window-configuration-2 ...)
>> ...)
>
> Reverting a directory in a window could remember the name of the file
> shown at the corresponding line and the offset of 'window-point' on that
> line and also the entire contents of the old directory until revert
> completes. As soon as the new contents of the directory have been
> established, dired would search the remembered name and position point
> at the remembered offset accordingly. If it does not find that name, it
> would have to compare the contents of the old and current contents of
> the directory and use some heuristics to position point appropriately.
You meant remembering the file name and window-point in a buffer-local variable?
Then it should be an alist with all windows of the same Dired buffer, e.g.
(setq-local dired-positions
'((#<window 1 on dired> dired-file-1 window-point-1)
(#<window 2 on dired> dired-file-2 window-point-2)
...))
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#33871; Package
emacs.
(Mon, 14 Feb 2022 18:37:01 GMT)
Full text and
rfc822 format available.
Message #53 received at 33871 <at> debbugs.gnu.org (full text, mbox):
> You meant remembering the file name and window-point in a buffer-local variable?
> Then it should be an alist with all windows of the same Dired buffer, e.g.
>
> (setq-local dired-positions
> '((#<window 1 on dired> dired-file-1 window-point-1)
> (#<window 2 on dired> dired-file-2 window-point-2)
> ...))
Or a window parameter of each dired window. Note that the third item
would be just the offset of 'window-point' from its line beginning
position. 'window-point' itself is completely useless here.
martin
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#33871; Package
emacs.
(Tue, 15 Feb 2022 19:31:02 GMT)
Full text and
rfc822 format available.
Message #56 received at 33871 <at> debbugs.gnu.org (full text, mbox):
>> You meant remembering the file name and window-point in a buffer-local variable?
>> Then it should be an alist with all windows of the same Dired buffer, e.g.
>>
>> (setq-local dired-positions
>> '((#<window 1 on dired> dired-file-1 window-point-1)
>> (#<window 2 on dired> dired-file-2 window-point-2)
>> ...))
>
> Or a window parameter of each dired window.
In case of a window parameter wouldn't the situation be inverted,
so it will use an alist too, but where keys are all dired buffers
displayed in that window from the prev-buffers list:
(set-window-parameter window 'dired-positions
'((#<buffer *dired-1*> dired-file-1 window-point-1)
(#<buffer *dired-2*> dired-file-2 window-point-2)
...))
> Note that the third item
> would be just the offset of 'window-point' from its line beginning
> position. 'window-point' itself is completely useless here.
Maybe 'window-start' would be more useful?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#33871; Package
emacs.
(Wed, 16 Feb 2022 08:51:01 GMT)
Full text and
rfc822 format available.
Message #59 received at 33871 <at> debbugs.gnu.org (full text, mbox):
> In case of a window parameter wouldn't the situation be inverted,
> so it will use an alist too, but where keys are all dired buffers
> displayed in that window from the prev-buffers list:
>
> (set-window-parameter window 'dired-positions
> '((#<buffer *dired-1*> dired-file-1 window-point-1)
> (#<buffer *dired-2*> dired-file-2 window-point-2)
> ...))
Something like that. But I still fail to see what these lines are
supposed to accomplish in your scenario:
(set-window-configuration w-c)
(goto-char p-m)))
What is it 'dired-restore-positions' does not handle here? IIUC your
lines mangle everything it has done.
martin
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#33871; Package
emacs.
(Wed, 16 Feb 2022 18:45:02 GMT)
Full text and
rfc822 format available.
Message #62 received at 33871 <at> debbugs.gnu.org (full text, mbox):
>> (set-window-parameter window 'dired-positions
>> '((#<buffer *dired-1*> dired-file-1 window-point-1)
>> (#<buffer *dired-2*> dired-file-2 window-point-2)
>> ...))
>
> Something like that. But I still fail to see what these lines are
> supposed to accomplish in your scenario:
>
> (set-window-configuration w-c)
> (goto-char p-m)))
>
> What is it 'dired-restore-positions' does not handle here? IIUC your
> lines mangle everything it has done.
Instead of (goto-char p-m), after (set-window-configuration w-c)
something like this should be performed:
(dired-goto-file (car (cdr (assoc (current-buffer)
(window-parameter nil 'dired-positions)))))
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#33871; Package
emacs.
(Thu, 17 Feb 2022 10:07:02 GMT)
Full text and
rfc822 format available.
Message #65 received at 33871 <at> debbugs.gnu.org (full text, mbox):
> Instead of (goto-char p-m), after (set-window-configuration w-c)
> something like this should be performed:
>
> (dired-goto-file (car (cdr (assoc (current-buffer)
> (window-parameter nil 'dired-positions)))))
Once more: Your scenario is
(progn (dired "/tmp") (dired-next-line 1)
(split-window) (other-window 1)
(dired "/tmp") (dired-next-line 2)
(let ((w-c (current-window-configuration))
(p-m (point-marker)))
(view-emacs-todo) (delete-other-windows)
(with-current-buffer (get-buffer "tmp")
(revert-buffer))
(set-window-configuration w-c)
(goto-char p-m)))
But this cannot work with dired buffers because they are reverted in a
special way that does not care about 'window-point' and the like. This
means that the value of 'point-marker' you saved in p-m has become just
meaningless after the 'revert-buffer' call.
Basically, this is a hard problem we'll probably never be able to solve
satisfactorily.
We could handle 'window-point' separately when saving and restoring
window configurations and the window's buffer is a dired buffer. For
example, 'dired-revert' could call a function 'window-revert-timestamp'
to store the current time of the revert operation for this window and
'current-window-configuration' (and 'window-state-get') would store
their current time stamp in the configuration (or state). Then
'set-window-configuration' (and 'window-state-put') could check whether
a window's revert time stamp is larger than the time stamp stored in the
configuration and not set point for that window when the revert time
stamp is later. Is it worth the hassle?
martin
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#33871; Package
emacs.
(Thu, 17 Feb 2022 17:49:02 GMT)
Full text and
rfc822 format available.
Message #68 received at 33871 <at> debbugs.gnu.org (full text, mbox):
>> Instead of (goto-char p-m), after (set-window-configuration w-c)
>> something like this should be performed:
>>
>> (dired-goto-file (car (cdr (assoc (current-buffer)
>> (window-parameter nil 'dired-positions)))))
>
> Once more: Your scenario is
>
> (progn (dired "/tmp") (dired-next-line 1)
> (split-window) (other-window 1)
> (dired "/tmp") (dired-next-line 2)
> (let ((w-c (current-window-configuration))
> (p-m (point-marker)))
> (view-emacs-todo) (delete-other-windows)
> (with-current-buffer (get-buffer "tmp")
> (revert-buffer))
> (set-window-configuration w-c)
> (goto-char p-m)))
>
> But this cannot work with dired buffers because they are reverted in a
> special way that does not care about 'window-point' and the like. This
> means that the value of 'point-marker' you saved in p-m has become just
> meaningless after the 'revert-buffer' call.
>
> Basically, this is a hard problem we'll probably never be able to solve
> satisfactorily.
But this works fine:
(progn (dired "/tmp") (dired-next-line 1)
(split-window) (other-window 1)
(dired "/tmp") (dired-next-line 2)
(walk-windows
(lambda (w)
(set-window-parameter
w 'dired-positions
(list (with-selected-window w
(dired-get-filename nil t))
(window-start w)
(window-point w)))))
(let ((w-c (current-window-configuration)))
(view-emacs-todo) (delete-other-windows)
(with-current-buffer (get-buffer "tmp")
(revert-buffer))
(set-window-configuration w-c)
(walk-windows
(lambda (w)
(let ((pos (window-parameter w 'dired-positions)))
(when pos
(with-selected-window w
(dired-goto-file (nth 0 pos)))
(set-window-start w (nth 1 pos))
(set-window-point w (nth 2 pos))))))))
> We could handle 'window-point' separately when saving and restoring
> window configurations and the window's buffer is a dired buffer. For
> example, 'dired-revert' could call a function 'window-revert-timestamp'
> to store the current time of the revert operation for this window and
> 'current-window-configuration' (and 'window-state-get') would store
> their current time stamp in the configuration (or state). Then
> 'set-window-configuration' (and 'window-state-put') could check whether
> a window's revert time stamp is larger than the time stamp stored in the
> configuration and not set point for that window when the revert time
> stamp is later. Is it worth the hassle?
I think it's not worth the hassle. The above solution is simpler.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#33871; Package
emacs.
(Sat, 19 Feb 2022 09:38:01 GMT)
Full text and
rfc822 format available.
Message #71 received at 33871 <at> debbugs.gnu.org (full text, mbox):
> (when pos
> (with-selected-window w
> (dired-goto-file (nth 0 pos)))
> (set-window-start w (nth 1 pos))
> (set-window-point w (nth 2 pos))))))))
Shouldn't you call 'dired-goto-file' last here? Otherwise, wouldn't
'set-window-point' override it?
And how would you handle the general case where a directory gets
reverted in between saving and restoring a window configuration? If you
don't want to use timestamps, saving and restoring window configurations
would have to provide some special hooks and data structures for storing
such extra information.
martin
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#33871; Package
emacs.
(Sat, 19 Feb 2022 17:09:01 GMT)
Full text and
rfc822 format available.
Message #74 received at 33871 <at> debbugs.gnu.org (full text, mbox):
>> (when pos
>> (with-selected-window w
>> (dired-goto-file (nth 0 pos)))
>> (set-window-start w (nth 1 pos))
>> (set-window-point w (nth 2 pos))))))))
>
> Shouldn't you call 'dired-goto-file' last here? Otherwise, wouldn't
> 'set-window-point' override it?
Then probably 'set-window-point' is not needed.
> And how would you handle the general case where a directory gets
> reverted in between saving and restoring a window configuration? If you
> don't want to use timestamps, saving and restoring window configurations
> would have to provide some special hooks and data structures for storing
> such extra information.
I don't understand the problem. 'dired-goto-file' can go to the file
even after a directory gets reverted.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#33871; Package
emacs.
(Sat, 19 Feb 2022 17:23:02 GMT)
Full text and
rfc822 format available.
Message #77 received at 33871 <at> debbugs.gnu.org (full text, mbox):
> I don't understand the problem. 'dired-goto-file' can go to the file
> even after a directory gets reverted.
How would 'save-window-excursion' handle the case of a dired buffer that
gets reverted while its FORMS are run?
martin
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#33871; Package
emacs.
(Sun, 20 Feb 2022 18:59:01 GMT)
Full text and
rfc822 format available.
Message #80 received at 33871 <at> debbugs.gnu.org (full text, mbox):
>> I don't understand the problem. 'dired-goto-file' can go to the file
>> even after a directory gets reverted.
>
> How would 'save-window-excursion' handle the case of a dired buffer that
> gets reverted while its FORMS are run?
'dired-goto-file' will restore dired-positions after 'save-window-excursion'.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#33871; Package
emacs.
(Mon, 21 Feb 2022 09:08:01 GMT)
Full text and
rfc822 format available.
Message #83 received at 33871 <at> debbugs.gnu.org (full text, mbox):
>> How would 'save-window-excursion' handle the case of a dired buffer that
>> gets reverted while its FORMS are run?
>
> 'dired-goto-file' will restore dired-positions after 'save-window-excursion'.
Who calculated those dired-positions and who calls 'dired-goto-file' to
restore them?
martin
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#33871; Package
emacs.
(Tue, 22 Feb 2022 17:29:01 GMT)
Full text and
rfc822 format available.
Message #86 received at 33871 <at> debbugs.gnu.org (full text, mbox):
>>> How would 'save-window-excursion' handle the case of a dired buffer that
>>> gets reverted while its FORMS are run?
>>
>> 'dired-goto-file' will restore dired-positions after 'save-window-excursion'.
>
> Who calculated those dired-positions and who calls 'dired-goto-file' to
> restore them?
Like in bug#54038 (about having access to windows in window configurations),
the problem is that there is no way to update and even peek inside
a window configuration. In bug#54038 the cleanup function can't tell
if a window is still live in a window configuration.
And here 'dired-revert' can't update windows saved in a window configuration.
'dired-save-positions' goes to great lengths to employ get-buffer-window-list,
and walk-windows with window-prev-buffers to update the Dired buffer
even in window-prev-buffers. And 'dired-restore-positions' with the
same number of lines tries to restore all prev-buffers.
But still 'dired-revert' fails to update the Dired buffer in
window configurations saved in tabs, or in winner.el, or
in 'C-x r w' (window-configuration-to-register), etc.
A possible solution would be to add two hooks:
1. hook before finishing 'current-window-configuration' that will add all
windows to some variable that the cleanup function could check in bug#54038.
This is like 'dired-save-positions'.
2. hook after calling 'set-window-configuration' that will restore
previous positions. This is like 'dired-restore-positions' that
uses 'dired-goto-file'.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#33871; Package
emacs.
(Wed, 23 Feb 2022 09:32:02 GMT)
Full text and
rfc822 format available.
Message #89 received at 33871 <at> debbugs.gnu.org (full text, mbox):
> Like in bug#54038 (about having access to windows in window configurations),
> the problem is that there is no way to update and even peek inside
> a window configuration. In bug#54038 the cleanup function can't tell
> if a window is still live in a window configuration.
We might be able to provide such a function but can you tell me why you
would need it and how you would use it?
> And here 'dired-revert' can't update windows saved in a window configuration.
Updating window configurations can be hairy. We have no function for
testing the validity of a configuration - we simply rely on the fact
that it is a 1-to-1 copy of original sizes and parent-child
relationships. For example: When we resize a window we check the new
sizes of all windows on that frame before storing them. When we restore
a window configuration, we simply store back the old sizes and then
maybe try to resize the windows if the frame size changed in between.
> 'dired-save-positions' goes to great lengths to employ get-buffer-window-list,
> and walk-windows with window-prev-buffers to update the Dired buffer
> even in window-prev-buffers. And 'dired-restore-positions' with the
> same number of lines tries to restore all prev-buffers.
>
> But still 'dired-revert' fails to update the Dired buffer in
> window configurations saved in tabs, or in winner.el, or
> in 'C-x r w' (window-configuration-to-register), etc.
As a first step we could try to do that for window states.
> A possible solution would be to add two hooks:
>
> 1. hook before finishing 'current-window-configuration' that will add all
> windows to some variable that the cleanup function could check in bug#54038.
> This is like 'dired-save-positions'.
We can easily add such a hook - an abnormal, buffer local one probably
that would be set by dired whenever it shows a directory in a window and
could get as argument the frame and/or the window(s) and probably the
return value of 'current-window-configuration' so dired can match it
with later invocations of 'set-window-configuration'.
> 2. hook after calling 'set-window-configuration' that will restore
> previous positions. This is like 'dired-restore-positions' that
> uses 'dired-goto-file'.
We can do that in a similar fashion. But: Updating your "variable" when
dired does something (like copying, deleting or renaming files) would
still have to be synchronized with the position of, for example,
'window-point' in that window when the window is still live at the time
'set-window-configuration' is called. So we might need yet another hook
called at the beginning of 'set-window-configuration' that allows dired
to check whether the window stored in your variable is live, take the
position of point from there if it is and keep it in the second hook.
(Note in this context: We traditionally say in the Elisp manual that "As
a special exception, the window configuration does not record the value
of point in the selected window for the current buffer." which is not
precise IIUC. It does record the value but 'set-window-configuration'
does not or not necessarily restore it.)
martin
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#33871; Package
emacs.
(Wed, 23 Feb 2022 18:07:01 GMT)
Full text and
rfc822 format available.
Message #92 received at 33871 <at> debbugs.gnu.org (full text, mbox):
>> But still 'dired-revert' fails to update the Dired buffer in
>> window configurations saved in tabs, or in winner.el, or
>> in 'C-x r w' (window-configuration-to-register), etc.
>
> As a first step we could try to do that for window states.
But window states don't contain pointers to windows.
So it's impossible to find e.g. '(selected-window)'
in a window state returned by '(window-state-get)'.
> (Note in this context: We traditionally say in the Elisp manual that "As
> a special exception, the window configuration does not record the value
> of point in the selected window for the current buffer." which is not
> precise IIUC. It does record the value but 'set-window-configuration'
> does not or not necessarily restore it.)
Then we could save additional context information the same way as
currently this special exceptional value of point is saved, e.g.
in 'tab-bar--tab':
(wc . ,(current-window-configuration))
(wc-point . ,(point-marker))
where 'point-marker' is saved separately from 'current-window-configuration'.
And then it's restored in 'tab-bar-select-tab':
;; set-window-configuration does not restore the value of
;; point in the current buffer, so restore it separately.
(when (and (markerp wc-point)
(marker-buffer wc-point)
;; FIXME: After dired-revert, marker relocates to 1.
;; window-configuration restores point to global point
;; in this dired buffer, not to its window point,
;; but this is slightly better than 1.
;; Maybe better to save dired-filename in each window?
(not (eq 1 (marker-position wc-point))))
(goto-char wc-point))
Please note that this bug report is related to FIXME above.
So a possible solution is also to save more context information
like dired-filename, and then restore it using dired-goto-file.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#33871; Package
emacs.
(Thu, 24 Feb 2022 09:20:03 GMT)
Full text and
rfc822 format available.
Message #95 received at 33871 <at> debbugs.gnu.org (full text, mbox):
> But window states don't contain pointers to windows.
> So it's impossible to find e.g. '(selected-window)'
> in a window state returned by '(window-state-get)'.
But you can easily write a function to inspect a window state.
> Then we could save additional context information the same way as
> currently this special exceptional value of point is saved, e.g.
> in 'tab-bar--tab':
>
> (wc . ,(current-window-configuration))
> (wc-point . ,(point-marker))
>
> where 'point-marker' is saved separately from 'current-window-configuration'.
> And then it's restored in 'tab-bar-select-tab':
>
> ;; set-window-configuration does not restore the value of
> ;; point in the current buffer, so restore it separately.
> (when (and (markerp wc-point)
> (marker-buffer wc-point)
> ;; FIXME: After dired-revert, marker relocates to 1.
> ;; window-configuration restores point to global point
> ;; in this dired buffer, not to its window point,
> ;; but this is slightly better than 1.
> ;; Maybe better to save dired-filename in each window?
> (not (eq 1 (marker-position wc-point))))
> (goto-char wc-point))
>
> Please note that this bug report is related to FIXME above.
>
> So a possible solution is also to save more context information
> like dired-filename, and then restore it using dired-goto-file.
We obviously then should strive for a solution that stores any kind of
information via a hook in an alist of entries, one for each window in a
buffer local way, and one global entry for the frame itself.
martin
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#33871; Package
emacs.
(Fri, 16 Feb 2024 07:41:02 GMT)
Full text and
rfc822 format available.
Message #98 received at 33871 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
>> ;; set-window-configuration does not restore the value of
>> ;; point in the current buffer, so restore it separately.
>> (when (and (markerp wc-point)
>> (marker-buffer wc-point)
>> ;; FIXME: After dired-revert, marker relocates to 1.
>> ;; window-configuration restores point to global point
>> ;; in this dired buffer, not to its window point,
>> ;; but this is slightly better than 1.
>> ;; Maybe better to save dired-filename in each window?
>> (not (eq 1 (marker-position wc-point))))
>> (goto-char wc-point))
>>
>> Please note that this bug report is related to FIXME above.
>>
>> So a possible solution is also to save more context information
>> like dired-filename, and then restore it using dired-goto-file.
>
> We obviously then should strive for a solution that stores any kind of
> information via a hook in an alist of entries, one for each window in a
> buffer local way, and one global entry for the frame itself.
Here is the patch that stores any kind of information via a hook,
one for each window in a buffer local way.
Currently only dired positions for the revert case are supported.
But also I tried to save context of any buffer in a bookmark way,
and this works nicely, and correctly restores old positions even
from window states from the desktop:
#+begin_src emacs-lisp
;; Like ‘bookmark-make-record-default’:
(setq-default window-set-context-function
(lambda ()
`((front-context-string
. ,(buffer-substring-no-properties
(point) (min (+ (point) 16) (point-max))))
(rear-context-string
. ,(buffer-substring-no-properties
(point) (max (- (point) 16) (point-min)))))))
;; Like ‘bookmark-default-handler’:
(setq-default window-use-context-function
(lambda (context)
(when (search-forward (alist-get 'front-context-string context)
(point-max) t)
(goto-char (match-beginning 0)))
(when (search-backward (alist-get 'rear-context-string context)
(point-min) t)
(goto-char (match-end 0)))))
#+end_src
[window-context-function.patch (text/x-diff, inline)]
diff --git a/lisp/tab-bar.el b/lisp/tab-bar.el
index 3e1d8278b04..fc1b20287d3 100644
--- a/lisp/tab-bar.el
+++ b/lisp/tab-bar.el
@@ -1283,6 +1283,10 @@ frameset-filter-tabs
(push '(tabs . frameset-filter-tabs) frameset-filter-alist)
+(defvar window-set-context-function nil)
+(defvar window-use-context-function nil)
+(add-to-list 'window-persistent-parameters '(context . writable))
+
(defun tab-bar--tab (&optional frame)
"Make a new tab data structure that can be added to tabs on the FRAME."
(let* ((tab (tab-bar--current-tab-find nil frame))
@@ -1292,6 +1296,14 @@ tab-bar--tab
frame 'buffer-list)))
(bbl (seq-filter #'buffer-live-p (frame-parameter
frame 'buried-buffer-list))))
+ (walk-windows
+ (lambda (w)
+ (with-selected-window w
+ (when (functionp window-set-context-function)
+ (when-let ((context (funcall window-set-context-function)))
+ (set-window-parameter w 'context (cons (buffer-name) context))))))
+ 'nomini)
+
`(tab
(name . ,(if tab-explicit-name
(alist-get 'name tab)
@@ -1479,6 +1491,15 @@ tab-bar-select-tab
(select-window (get-mru-window)))
(window-state-put ws nil 'safe)))
+ (walk-windows
+ (lambda (w)
+ (with-selected-window w
+ (when-let ((context (window-parameter w 'context)))
+ (when (and (functionp window-use-context-function)
+ (equal (buffer-name) (car context)))
+ (funcall window-use-context-function (cdr context))))))
+ 'nomini)
+
;; Select the minibuffer when it was active before switching tabs
(when (and minibuffer-was-active (active-minibuffer-window))
(select-window (active-minibuffer-window)))
diff --git a/lisp/dired.el b/lisp/dired.el
index 9e3b888df14..df50f37df7b 100644
--- a/lisp/dired.el
+++ b/lisp/dired.el
@@ -2743,6 +2745,12 @@ dired-mode
'(dired-font-lock-keywords t nil nil beginning-of-line))
(setq-local desktop-save-buffer 'dired-desktop-buffer-misc-data)
(setq-local grep-read-files-function #'dired-grep-read-files)
+ (setq-local window-set-context-function
+ (lambda ()
+ `((dired-filename . ,(dired-get-filename nil t)))))
+ (setq-local window-use-context-function
+ (lambda (context)
+ (dired-goto-file (alist-get 'dired-filename context))))
(setq dired-switches-alist nil)
(hack-dir-local-variables-non-file-buffer) ; before sorting
(dired-sort-other dired-actual-switches t)
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#33871; Package
emacs.
(Fri, 16 Feb 2024 09:42:02 GMT)
Full text and
rfc822 format available.
Message #101 received at 33871 <at> debbugs.gnu.org (full text, mbox):
> Here is the patch that stores any kind of information via a hook,
> one for each window in a buffer local way.
>
> Currently only dired positions for the revert case are supported.
> But also I tried to save context of any buffer in a bookmark way,
> and this works nicely, and correctly restores old positions even
> from window states from the desktop:
Note that
+ (with-selected-window w
+ (when (functionp window-set-context-function)
and
+ (with-selected-window w
+ (when-let ((context (window-parameter w 'context)))
would set up a precedence case for the future use of
'window-set-context-function'. Are you sure that you always want to
select the window in question here or would it suffice to pass the
window as argument to the context function?
martin
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#33871; Package
emacs.
(Sun, 18 Feb 2024 07:49:01 GMT)
Full text and
rfc822 format available.
Message #104 received at 33871 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
> + (with-selected-window w
> + (when (functionp window-set-context-function)
>
> and
>
> + (with-selected-window w
> + (when-let ((context (window-parameter w 'context)))
>
> would set up a precedence case for the future use of
> 'window-set-context-function'. Are you sure that you always want to
> select the window in question here or would it suffice to pass the
> window as argument to the context function?
Ok, let's add the WINDOW argument. This means that most hooks
will need to call 'with-selected-window' explicitly. But maybe
there will be hooks that don't need to select a window.
So here how a bookmark-like default context could look.
I'm still not sure whether it's a good idea to enable this
by default.
#+begin_src emacs-lisp
;; Like ‘bookmark-make-record-default’
(setq-default window-set-context-function
(lambda (w)
(with-selected-window w
`((front-context-string
. ,(buffer-substring-no-properties
(point) (min (+ (point) 16) (point-max))))
(rear-context-string
. ,(buffer-substring-no-properties
(point) (max (- (point) 16) (point-min))))))))
;; Like ‘bookmark-default-handler’
(setq-default window-use-context-function
(lambda (w context)
(with-selected-window w
(when-let ((f (alist-get 'front-context-string context)))
(search-forward f (point-max) t)
(goto-char (match-beginning 0)))
(when-let ((r (alist-get 'rear-context-string context)))
(search-backward r (point-min) t)
(goto-char (match-end 0))))))
#+end_src
And here is the patch that at least handles the dired revert.
[window-context-function.patch (text/x-diff, inline)]
diff --git a/lisp/dired.el b/lisp/dired.el
index 9e3b888df14..dd397eb5c46 100644
--- a/lisp/dired.el
+++ b/lisp/dired.el
@@ -2743,6 +2745,19 @@ dired-mode
'(dired-font-lock-keywords t nil nil beginning-of-line))
(setq-local desktop-save-buffer 'dired-desktop-buffer-misc-data)
(setq-local grep-read-files-function #'dired-grep-read-files)
+ (setq-local window-set-context-function
+ (lambda (w)
+ (with-selected-window w
+ (if-let ((f (dired-get-filename nil t)))
+ `((dired-filename . ,f))
+ `((position . ,(point)))))))
+ (setq-local window-use-context-function
+ (lambda (w context)
+ (with-selected-window w
+ (if-let ((f (alist-get 'dired-filename context)))
+ (dired-goto-file f)
+ (when-let ((p (alist-get 'position context)))
+ (goto-char p))))))
(setq dired-switches-alist nil)
(hack-dir-local-variables-non-file-buffer) ; before sorting
(dired-sort-other dired-actual-switches t)
diff --git a/lisp/tab-bar.el b/lisp/tab-bar.el
index 3e1d8278b04..7718262acbb 100644
--- a/lisp/tab-bar.el
+++ b/lisp/tab-bar.el
@@ -1283,6 +1283,10 @@ frameset-filter-tabs
(push '(tabs . frameset-filter-tabs) frameset-filter-alist)
+(defvar window-set-context-function nil)
+(defvar window-use-context-function nil)
+(add-to-list 'window-persistent-parameters '(context . writable))
+
(defun tab-bar--tab (&optional frame)
"Make a new tab data structure that can be added to tabs on the FRAME."
(let* ((tab (tab-bar--current-tab-find nil frame))
@@ -1292,6 +1296,14 @@ tab-bar--tab
frame 'buffer-list)))
(bbl (seq-filter #'buffer-live-p (frame-parameter
frame 'buried-buffer-list))))
+ (walk-windows
+ (lambda (w)
+ (when-let (((functionp window-set-context-function))
+ (context (funcall window-set-context-function w)))
+ (set-window-parameter
+ w 'context (cons (buffer-name (window-buffer w)) context))))
+ 'nomini)
+
`(tab
(name . ,(if tab-explicit-name
(alist-get 'name tab)
@@ -1479,6 +1491,14 @@ tab-bar-select-tab
(select-window (get-mru-window)))
(window-state-put ws nil 'safe)))
+ (walk-windows
+ (lambda (w)
+ (when-let (((functionp window-use-context-function))
+ (context (window-parameter w 'context))
+ ((equal (buffer-name (window-buffer w)) (car context))))
+ (funcall window-use-context-function w (cdr context))))
+ 'nomini)
+
;; Select the minibuffer when it was active before switching tabs
(when (and minibuffer-was-active (active-minibuffer-window))
(select-window (active-minibuffer-window)))
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#33871; Package
emacs.
(Mon, 19 Feb 2024 09:44:02 GMT)
Full text and
rfc822 format available.
Message #107 received at 33871 <at> debbugs.gnu.org (full text, mbox):
> Ok, let's add the WINDOW argument. This means that most hooks
> will need to call 'with-selected-window' explicitly. But maybe
> there will be hooks that don't need to select a window.
(setq-default window-set-context-function
(lambda (w)
(let ((point (window-point w)))
(with-current-buffer (window-buffer w)
`((front-context-string
. ,(buffer-substring-no-properties
point (min (+ point 16) (point-max))))
(rear-context-string
. ,(buffer-substring-no-properties
point (max (- point 16) (point-min)))))))))
should suffice to make 'buffer-substring-no-properties' work. Note that
if you select the window beforehand, 'selected-window' will not return a
meaningful value in the body of the function called. This is a problem
of many "hooks" like 'mode-line-format' or 'window-configuration-hook'.
The comfort you get comes at the price of a lack of generality.
martin
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#33871; Package
emacs.
(Tue, 20 Feb 2024 08:00:02 GMT)
Full text and
rfc822 format available.
Message #110 received at 33871 <at> debbugs.gnu.org (full text, mbox):
>> Ok, let's add the WINDOW argument. This means that most hooks
>> will need to call 'with-selected-window' explicitly. But maybe
>> there will be hooks that don't need to select a window.
>
> (setq-default window-set-context-function
> (lambda (w)
> (let ((point (window-point w)))
> (with-current-buffer (window-buffer w)
> `((front-context-string
> . ,(buffer-substring-no-properties
> point (min (+ point 16) (point-max))))
> (rear-context-string
> . ,(buffer-substring-no-properties
> point (max (- point 16) (point-min)))))))))
>
> should suffice to make 'buffer-substring-no-properties' work. Note that
> if you select the window beforehand, 'selected-window' will not return a
> meaningful value in the body of the function called. This is a problem
> of many "hooks" like 'mode-line-format' or 'window-configuration-hook'.
> The comfort you get comes at the price of a lack of generality.
Thanks. Is it possible to avoid 'with-selected-window' in other hooks?
Maybe something like this:
(setq-default window-use-context-function
(lambda (w context)
(let ((point (window-point w)))
(with-current-buffer (window-buffer w)
(goto-char point)
(when-let ((f (alist-get 'front-context-string context)))
(search-forward f (point-max) t)
(goto-char (match-beginning 0)))
(when-let ((r (alist-get 'rear-context-string context)))
(search-backward r (point-min) t)
(goto-char (match-end 0)))
(setq point (point)))
(set-window-point w point))))
and for Dired:
diff --git a/lisp/dired.el b/lisp/dired.el
index 9e3b888df14..fc8da1635f9 100644
--- a/lisp/dired.el
+++ b/lisp/dired.el
@@ -2743,6 +2745,24 @@ dired-mode
'(dired-font-lock-keywords t nil nil beginning-of-line))
(setq-local desktop-save-buffer 'dired-desktop-buffer-misc-data)
(setq-local grep-read-files-function #'dired-grep-read-files)
+ (setq-local window-set-context-function
+ (lambda (w)
+ (let ((point (window-point w)))
+ (with-current-buffer (window-buffer w)
+ (goto-char point)
+ (if-let ((f (dired-get-filename nil t)))
+ `((dired-filename . ,f))
+ `((position . ,(point))))))))
+ (setq-local window-use-context-function
+ (lambda (w context)
+ (let ((point (window-point w)))
+ (with-current-buffer (window-buffer w)
+ (if-let ((f (alist-get 'dired-filename context)))
+ (dired-goto-file f)
+ (when-let ((p (alist-get 'position context)))
+ (goto-char p)))
+ (setq point (point)))
+ (set-window-point w point))))
(setq dired-switches-alist nil)
(hack-dir-local-variables-non-file-buffer) ; before sorting
(dired-sort-other dired-actual-switches t)
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#33871; Package
emacs.
(Wed, 21 Feb 2024 09:06:01 GMT)
Full text and
rfc822 format available.
Message #113 received at 33871 <at> debbugs.gnu.org (full text, mbox):
> Thanks. Is it possible to avoid 'with-selected-window' in other hooks?
> Maybe something like this:
>
> (setq-default window-use-context-function
> (lambda (w context)
> (let ((point (window-point w)))
> (with-current-buffer (window-buffer w)
I suppose that in the general case you need a
(save-excursion
from here
> (goto-char point)
> (when-let ((f (alist-get 'front-context-string context)))
> (search-forward f (point-max) t)
> (goto-char (match-beginning 0)))
> (when-let ((r (alist-get 'rear-context-string context)))
> (search-backward r (point-min) t)
> (goto-char (match-end 0)))
> (setq point (point)))
till here
)
> (set-window-point w point))))
Probably something similar is needed for dired, for example to handle
the case where its buffer is simultaneously shown in two windows with
their points on different lines.
martin
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#33871; Package
emacs.
(Wed, 21 Feb 2024 17:40:03 GMT)
Full text and
rfc822 format available.
Message #116 received at 33871 <at> debbugs.gnu.org (full text, mbox):
>> (setq-default window-use-context-function
>> (lambda (w context)
>> (let ((point (window-point w)))
>> (with-current-buffer (window-buffer w)
>
> I suppose that in the general case you need a
>
> (save-excursion
Thanks. I just noticed this is broken in two windows case,
and your suggestion fixed it.
> Probably something similar is needed for dired, for example to handle
> the case where its buffer is simultaneously shown in two windows with
> their points on different lines.
So here is the same for dired:
diff --git a/lisp/dired.el b/lisp/dired.el
index 9e3b888df14..0510db1c409 100644
--- a/lisp/dired.el
+++ b/lisp/dired.el
@@ -2743,6 +2745,26 @@ dired-mode
'(dired-font-lock-keywords t nil nil beginning-of-line))
(setq-local desktop-save-buffer 'dired-desktop-buffer-misc-data)
(setq-local grep-read-files-function #'dired-grep-read-files)
+ (setq-local window-set-context-function
+ (lambda (w)
+ (let ((point (window-point w)))
+ (with-current-buffer (window-buffer w)
+ (save-excursion
+ (goto-char point)
+ (if-let ((f (dired-get-filename nil t)))
+ `((dired-filename . ,f))
+ `((position . ,(point)))))))))
+ (setq-local window-use-context-function
+ (lambda (w context)
+ (let ((point (window-point w)))
+ (with-current-buffer (window-buffer w)
+ (save-excursion
+ (if-let ((f (alist-get 'dired-filename context)))
+ (dired-goto-file f)
+ (when-let ((p (alist-get 'position context)))
+ (goto-char p)))
+ (setq point (point))))
+ (set-window-point w point))))
(setq dired-switches-alist nil)
(hack-dir-local-variables-non-file-buffer) ; before sorting
(dired-sort-other dired-actual-switches t)
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#33871; Package
emacs.
(Wed, 20 Mar 2024 17:32:01 GMT)
Full text and
rfc822 format available.
Message #119 received at 33871 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
> Probably something similar is needed for dired, for example to handle
> the case where its buffer is simultaneously shown in two windows with
> their points on different lines.
Avoiding select-window removed simplicity and now requires
adding more handling and more testing. But finally
everything works correctly. Please review the new patch:
[tab-bar-select-restore-context.patch (text/x-diff, inline)]
diff --git a/lisp/dired.el b/lisp/dired.el
index 9e3b888df14..cb2fc97d0ae 100644
--- a/lisp/dired.el
+++ b/lisp/dired.el
@@ -2743,6 +2745,24 @@ dired-mode
'(dired-font-lock-keywords t nil nil beginning-of-line))
(setq-local desktop-save-buffer 'dired-desktop-buffer-misc-data)
(setq-local grep-read-files-function #'dired-grep-read-files)
+ (setq-local window-set-context-function
+ (lambda (w)
+ (let ((point (window-point w)))
+ (save-excursion
+ (goto-char point)
+ (if-let ((f (dired-get-filename nil t)))
+ `((dired-filename . ,f))
+ `((position . ,(point))))))))
+ (setq-local window-use-context-function
+ (lambda (w context)
+ (let ((point (window-point w)))
+ (save-excursion
+ (if-let ((f (alist-get 'dired-filename context)))
+ (dired-goto-file f)
+ (when-let ((p (alist-get 'position context)))
+ (goto-char p)))
+ (setq point (point)))
+ (set-window-point w point))))
(setq dired-switches-alist nil)
(hack-dir-local-variables-non-file-buffer) ; before sorting
(dired-sort-other dired-actual-switches t)
diff --git a/lisp/tab-bar.el b/lisp/tab-bar.el
index fa22500a04e..af2658d60a3 100644
--- a/lisp/tab-bar.el
+++ b/lisp/tab-bar.el
@@ -1283,6 +1294,36 @@ frameset-filter-tabs
(push '(tabs . frameset-filter-tabs) frameset-filter-alist)
+(defun window-set-context-default-function (w)
+ "Set context to the front/rear strings."
+ (when buffer-file-name
+ (let ((point (window-point w)))
+ `((front-context-string
+ . ,(buffer-substring-no-properties
+ point (min (+ point 16) (point-max))))
+ (rear-context-string
+ . ,(buffer-substring-no-properties
+ point (max (- point 16) (point-min))))))))
+
+(defun window-use-context-default-function (w context)
+ "Restore context by the front/rear strings."
+ (let ((point (window-point w)))
+ (save-excursion
+ (goto-char point)
+ (when-let ((f (alist-get 'front-context-string context))
+ ((search-forward f (point-max) t)))
+ (goto-char (match-beginning 0))
+ (when-let ((r (alist-get 'rear-context-string context))
+ ((search-backward r (point-min) t)))
+ (goto-char (match-end 0))
+ (setq point (point)))))
+ (set-window-point w point)))
+
+(defvar window-set-context-function 'window-set-context-default-function)
+(defvar window-use-context-function 'window-use-context-default-function)
+
+(add-to-list 'window-persistent-parameters '(context . writable))
+
(defun tab-bar--tab (&optional frame)
"Make a new tab data structure that can be added to tabs on the FRAME."
(let* ((tab (tab-bar--current-tab-find nil frame))
@@ -1292,6 +1333,15 @@ tab-bar--tab
frame 'buffer-list)))
(bbl (seq-filter #'buffer-live-p (frame-parameter
frame 'buried-buffer-list))))
+ (when tab-bar-select-restore-context
+ (walk-windows
+ (lambda (w)
+ (with-current-buffer (window-buffer w)
+ (when-let (((functionp window-set-context-function))
+ (context (funcall window-set-context-function w)))
+ (set-window-parameter w 'context (cons (buffer-name) context)))))
+ 'nomini))
+
`(tab
(name . ,(if tab-explicit-name
(alist-get 'name tab)
@@ -1442,6 +1492,12 @@ tab-bar-select-restore-windows
(setq buffer-read-only t)
(set-window-buffer window new-buffer))))))
+(defcustom tab-bar-select-restore-context t
+ "Non-nil to restore context of the restored tab."
+ :type 'boolean
+ :group 'tab-bar
+ :version "30.1")
+
(defvar tab-bar-minibuffer-restore-tab nil
"Tab number for `tab-bar-minibuffer-restore-tab'.")
@@ -1539,6 +1595,17 @@ tab-bar-select-tab
(select-window (get-mru-window)))
(window-state-put ws nil 'safe)))
+ (when tab-bar-select-restore-context
+ (walk-windows
+ (lambda (w)
+ (with-current-buffer (window-buffer w)
+ (when-let (((functionp window-use-context-function))
+ (context (window-parameter w 'context))
+ ((equal (buffer-name) (car context))))
+ (funcall window-use-context-function w (cdr context))
+ (set-window-parameter w 'context nil))))
+ 'nomini))
+
;; Select the minibuffer when it was active before switching tabs
(when (and minibuffer-was-active (active-minibuffer-window))
(select-window (active-minibuffer-window)))
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#33871; Package
emacs.
(Thu, 21 Mar 2024 09:22:02 GMT)
Full text and
rfc822 format available.
Message #122 received at 33871 <at> debbugs.gnu.org (full text, mbox):
> Avoiding select-window removed simplicity and now requires
> adding more handling and more testing. But finally
> everything works correctly. Please review the new patch:
Can you please provide me with a complete scenario the old code got
wrong? I'm rather confused by the number of different bugs we've been
trying to solve here. IIUC the original Bug#33871 is still unsolved.
Bug#33532 as well. What about Bug#68235 and Bug#69093? And Bug#12253?
Thanks, martin
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#33871; Package
emacs.
(Thu, 21 Mar 2024 18:03:02 GMT)
Full text and
rfc822 format available.
Message #125 received at 33871 <at> debbugs.gnu.org (full text, mbox):
>> Avoiding select-window removed simplicity and now requires
>> adding more handling and more testing. But finally
>> everything works correctly. Please review the new patch:
>
> Can you please provide me with a complete scenario the old code got
> wrong? I'm rather confused by the number of different bugs we've been
> trying to solve here.
There are two scenarios that this patch will fix:
1. switching tabs with the same reverted Dired buffer
For example,
a. create two windows with the same Dired buffer (e.g. split-window)
b. clone the tab with 'C-x t n'
c. revert Dired buffer with 'g'
d. switch back to the previous tab
e. observe that point in the non-selected Dired window
relocates to the top of the buffer
f. in Emacs 30 point is relocated also in the selected window
2. second scenario for file buffers:
a. visit a file buffer
b. clone the tab with 'C-x t n'
c. edit the same file buffer before the previous point
d. save the desktop (that turns markers into integers)
e. restart Emacs and load the desktop
f. optionally edit the same buffer again
g. switch back to the previous tab
h. due to integer positions point is restored in a random place
The patch uses the context functions to restore the right position.
> IIUC the original Bug#33871 is still unsolved.
The proposed patch will close bug#33871.
> Bug#33532 as well.
Bug#33532 could be closed as well due to new context functions.
> What about Bug#68235 and Bug#69093?
Bug#68235 is closed, but the patch will solve the issue
mentioned in https://debbugs.gnu.org/68235#79
starting with the words:
"BTW, there is another problem when the same buffer is displayed
in two tabs/window-configurations."
Bug#69093 is completely fixed.
> And Bug#12253?
Bug#12253 is unrelated, but thanks for reminder,
it should be addressed later as well.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#33871; Package
emacs.
(Fri, 22 Mar 2024 09:28:02 GMT)
Full text and
rfc822 format available.
Message #128 received at 33871 <at> debbugs.gnu.org (full text, mbox):
> There are two scenarios that this patch will fix:
I reconstructed the buggy behaviors and checked that the patch fixes
them.
>> IIUC the original Bug#33871 is still unsolved.
>
> The proposed patch will close bug#33871.
Can you amend the original scenario you posted there in a way that one
can see how your patch can be used to fix it. That's where I stumbled
initially because I didn't know what to do.
>> Bug#33532 as well.
>
> Bug#33532 could be closed as well due to new context functions.
>
>> What about Bug#68235 and Bug#69093?
>
> Bug#68235 is closed, but the patch will solve the issue
> mentioned in https://debbugs.gnu.org/68235#79
> starting with the words:
> "BTW, there is another problem when the same buffer is displayed
> in two tabs/window-configurations."
>
> Bug#69093 is completely fixed.
Is there any place where we should amend the documentation for these?
Which are the cases where the context function will fail to work?
>> And Bug#12253?
>
> Bug#12253 is unrelated, but thanks for reminder,
> it should be addressed later as well.
If there's anything I can or should do, please tell me.
Thanks, martin
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#33871; Package
emacs.
(Fri, 22 Mar 2024 16:20:01 GMT)
Full text and
rfc822 format available.
Message #131 received at 33871 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
>> There are two scenarios that this patch will fix:
>
> I reconstructed the buggy behaviors and checked that the patch fixes
> them.
Thanks for confirming.
>>> IIUC the original Bug#33871 is still unsolved.
>>
>> The proposed patch will close bug#33871.
>
> Can you amend the original scenario you posted there in a way that one
> can see how your patch can be used to fix it. That's where I stumbled
> initially because I didn't know what to do.
The original scenario was:
(progn (dired "/tmp") (dired-next-line 1)
(split-window) (other-window 1)
(dired "/tmp") (dired-next-line 2)
(let ((w-c (current-window-configuration))
(p-m (point-marker)))
(view-emacs-todo) (delete-other-windows)
(with-current-buffer (get-buffer "tmp")
(revert-buffer))
(set-window-configuration w-c)
(goto-char p-m)))
Ok, let's add new code to separate functions
'window-set-context' and 'window-use-context'.
Below is the patch with these new functions.
Maybe they could be moved from tab-bar.el to window.el?
Then the amended scenario will be:
(progn (dired "/tmp") (dired-next-line 1)
(split-window) (other-window 1)
(dired "/tmp") (dired-next-line 2)
(window-set-context)
(let ((w-c (current-window-configuration))
(p-m (point-marker)))
(view-emacs-todo) (delete-other-windows)
(with-current-buffer (get-buffer "tmp")
(revert-buffer))
(set-window-configuration w-c)
(window-use-context)))
>>> Bug#33532 as well.
>>
>> Bug#33532 could be closed as well due to new context functions.
>>
>>> What about Bug#68235 and Bug#69093?
>>
>> Bug#68235 is closed, but the patch will solve the issue
>> mentioned in https://debbugs.gnu.org/68235#79
>> starting with the words:
>> "BTW, there is another problem when the same buffer is displayed
>> in two tabs/window-configurations."
>>
>> Bug#69093 is completely fixed.
>
> Is there any place where we should amend the documentation for these?
If code is ok, I could update the documentation.
> Which are the cases where the context function will fail to work?
I'm not aware of any such cases.
[tab-bar-select-restore-context-2.patch (text/x-diff, inline)]
diff --git a/lisp/dired.el b/lisp/dired.el
index 9e3b888df14..cb2fc97d0ae 100644
--- a/lisp/dired.el
+++ b/lisp/dired.el
@@ -2743,6 +2745,24 @@ dired-mode
'(dired-font-lock-keywords t nil nil beginning-of-line))
(setq-local desktop-save-buffer 'dired-desktop-buffer-misc-data)
(setq-local grep-read-files-function #'dired-grep-read-files)
+ (setq-local window-set-context-function
+ (lambda (w)
+ (let ((point (window-point w)))
+ (save-excursion
+ (goto-char point)
+ (if-let ((f (dired-get-filename nil t)))
+ `((dired-filename . ,f))
+ `((position . ,(point))))))))
+ (setq-local window-use-context-function
+ (lambda (w context)
+ (let ((point (window-point w)))
+ (save-excursion
+ (if-let ((f (alist-get 'dired-filename context)))
+ (dired-goto-file f)
+ (when-let ((p (alist-get 'position context)))
+ (goto-char p)))
+ (setq point (point)))
+ (set-window-point w point))))
(setq dired-switches-alist nil)
(hack-dir-local-variables-non-file-buffer) ; before sorting
(dired-sort-other dired-actual-switches t)
diff --git a/lisp/tab-bar.el b/lisp/tab-bar.el
index fa22500a04e..528c85f45d6 100644
--- a/lisp/tab-bar.el
+++ b/lisp/tab-bar.el
@@ -1283,6 +1283,58 @@ frameset-filter-tabs
(push '(tabs . frameset-filter-tabs) frameset-filter-alist)
+(defun window-set-context-default-function (w)
+ "Set context to the front/rear strings."
+ (when buffer-file-name
+ (let ((point (window-point w)))
+ `((front-context-string
+ . ,(buffer-substring-no-properties
+ point (min (+ point 16) (point-max))))
+ (rear-context-string
+ . ,(buffer-substring-no-properties
+ point (max (- point 16) (point-min))))))))
+
+(defun window-use-context-default-function (w context)
+ "Restore context by the front/rear strings."
+ (let ((point (window-point w)))
+ (save-excursion
+ (goto-char point)
+ (when-let ((f (alist-get 'front-context-string context))
+ ((search-forward f (point-max) t)))
+ (goto-char (match-beginning 0))
+ (when-let ((r (alist-get 'rear-context-string context))
+ ((search-backward r (point-min) t)))
+ (goto-char (match-end 0))
+ (unless (eq point (point))
+ (warn "!!! %S -> %S r=%S f=%S" point (point) r f))
+ (setq point (point)))))
+ (set-window-point w point)))
+
+(defvar window-set-context-function 'window-set-context-default-function)
+(defvar window-use-context-function 'window-use-context-default-function)
+
+(add-to-list 'window-persistent-parameters '(context . writable))
+
+(defun window-set-context ()
+ (walk-windows
+ (lambda (w)
+ (with-current-buffer (window-buffer w)
+ (when-let (((functionp window-set-context-function))
+ (context (funcall window-set-context-function w)))
+ (set-window-parameter w 'context (cons (buffer-name) context)))))
+ 'nomini))
+
+(defun window-use-context ()
+ (walk-windows
+ (lambda (w)
+ (with-current-buffer (window-buffer w)
+ (when-let (((functionp window-use-context-function))
+ (context (window-parameter w 'context))
+ ((equal (buffer-name) (car context))))
+ (funcall window-use-context-function w (cdr context))
+ (set-window-parameter w 'context nil))))
+ 'nomini))
+
(defun tab-bar--tab (&optional frame)
"Make a new tab data structure that can be added to tabs on the FRAME."
(let* ((tab (tab-bar--current-tab-find nil frame))
@@ -1292,6 +1344,9 @@ tab-bar--tab
frame 'buffer-list)))
(bbl (seq-filter #'buffer-live-p (frame-parameter
frame 'buried-buffer-list))))
+ (when tab-bar-select-restore-context
+ (window-set-context))
+
`(tab
(name . ,(if tab-explicit-name
(alist-get 'name tab)
@@ -1442,6 +1497,12 @@ tab-bar-select-restore-windows
(setq buffer-read-only t)
(set-window-buffer window new-buffer))))))
+(defcustom tab-bar-select-restore-context t
+ "Non-nil to restore context of the restored tab."
+ :type 'boolean
+ :group 'tab-bar
+ :version "30.1")
+
(defvar tab-bar-minibuffer-restore-tab nil
"Tab number for `tab-bar-minibuffer-restore-tab'.")
@@ -1539,6 +1600,9 @@ tab-bar-select-tab
(select-window (get-mru-window)))
(window-state-put ws nil 'safe)))
+ (when tab-bar-select-restore-context
+ (window-use-context))
+
;; Select the minibuffer when it was active before switching tabs
(when (and minibuffer-was-active (active-minibuffer-window))
(select-window (active-minibuffer-window)))
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#33871; Package
emacs.
(Sat, 23 Mar 2024 09:21:02 GMT)
Full text and
rfc822 format available.
Message #134 received at 33871 <at> debbugs.gnu.org (full text, mbox):
> Ok, let's add new code to separate functions
> 'window-set-context' and 'window-use-context'.
> Below is the patch with these new functions.
> Maybe they could be moved from tab-bar.el to window.el?
I think you should do that. Maybe 'window-restore-set-context' and
'window-restore-use-context' would be more indicative names.
Note that when a buffer is killed, the values of its local variables may
be lost. I don't know whether this is an issue here. Alternatively, we
could have 'set_window_buffer' set the 'context' window parameter from
the buffer-local value which would, however, mean that whenever one
changes the buffer-local value, one would have to simultaneously update
the parameters in all windows showing that buffer. Something that could
be done with the help of an advice, though...
martin
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#33871; Package
emacs.
(Sat, 23 Mar 2024 18:42:01 GMT)
Full text and
rfc822 format available.
Message #137 received at 33871 <at> debbugs.gnu.org (full text, mbox):
>> Ok, let's add new code to separate functions
>> 'window-set-context' and 'window-use-context'.
>> Below is the patch with these new functions.
>> Maybe they could be moved from tab-bar.el to window.el?
>
> I think you should do that.
OTOH, tab-bar.el is preloaded as well, so no problem to leave this
in tab-bar.el, since window.el is too large already.
> Maybe 'window-restore-set-context' and 'window-restore-use-context'
> would be more indicative names.
The name 'window-restore-set-context' looks quite self-contradictory.
If your intention was to use a unique prefix, then maybe we could use the
prefix 'window-context' like in 'window-context-set', 'window-context-use'.
> Note that when a buffer is killed, the values of its local variables may
> be lost. I don't know whether this is an issue here. Alternatively, we
> could have 'set_window_buffer' set the 'context' window parameter from
> the buffer-local value which would, however, mean that whenever one
> changes the buffer-local value, one would have to simultaneously update
> the parameters in all windows showing that buffer. Something that could
> be done with the help of an advice, though...
This doesn't look like an issue here because the context is stored
in a window parameter. And when the buffer is killed, there is no need
to restore a context in the killed buffer.
The format of the window parameter
'(BUFFER-NAME . ((dired-filename . FILENAME)))
uses BUFFER-NAME to check whether the buffer was killed,
and when the current window's buffer doesn't match BUFFER-NAME,
then do nothing.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#33871; Package
emacs.
(Sun, 24 Mar 2024 09:56:01 GMT)
Full text and
rfc822 format available.
Message #140 received at 33871 <at> debbugs.gnu.org (full text, mbox):
> OTOH, tab-bar.el is preloaded as well, so no problem to leave this
> in tab-bar.el, since window.el is too large already.
Then I would give them a 'tab-bar-' prefix.
>> Maybe 'window-restore-set-context' and 'window-restore-use-context'
>> would be more indicative names.
>
> The name 'window-restore-set-context' looks quite self-contradictory.
> If your intention was to use a unique prefix, then maybe we could use the
> prefix 'window-context' like in 'window-context-set', 'window-context-use'.
I'd say the context of a window are the other windows of the same frame.
>> Note that when a buffer is killed, the values of its local variables may
>> be lost. I don't know whether this is an issue here. Alternatively, we
>> could have 'set_window_buffer' set the 'context' window parameter from
>> the buffer-local value which would, however, mean that whenever one
>> changes the buffer-local value, one would have to simultaneously update
>> the parameters in all windows showing that buffer. Something that could
>> be done with the help of an advice, though...
>
> This doesn't look like an issue here because the context is stored
> in a window parameter.
IIUC the context is stored but not the function to restore the position
from the context.
> And when the buffer is killed, there is no need
> to restore a context in the killed buffer.
If you don't intend to restore the context from the file the buffer was
visiting. Are you sure you don't want to do that?
> The format of the window parameter
>
> '(BUFFER-NAME . ((dired-filename . FILENAME)))
>
> uses BUFFER-NAME to check whether the buffer was killed,
> and when the current window's buffer doesn't match BUFFER-NAME,
> then do nothing.
What do you do when you want to restore a configuration from a tab, that
configuration contains a window whose buffer was killed but whose file
still exists and you wanted to revisit that file in the window with its
previous point? Ignore any context for that window?
martin
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#33871; Package
emacs.
(Sun, 24 Mar 2024 17:22:02 GMT)
Full text and
rfc822 format available.
Message #143 received at 33871 <at> debbugs.gnu.org (full text, mbox):
>> OTOH, tab-bar.el is preloaded as well, so no problem to leave this
>> in tab-bar.el, since window.el is too large already.
>
> Then I would give them a 'tab-bar-' prefix.
I agree that if they remain in tab-bar.el they should have a 'tab-bar-' prefix.
But OTOH, such prefix doesn't look right to use for hooks in dired-mode,
because this is a general window functionality, not directly related to tabs.
Maybe still would be better to add this to window.el?
Then to not change the size of window.el, we could remove
some existing lines that don't belong to window.el.
For example, these defcustoms have no place in window.el:
(defcustom display-comint-buffer-action
(defcustom display-tex-shell-buffer-action
Ok, I will create a separate bug report to remove them.
>>> Maybe 'window-restore-set-context' and 'window-restore-use-context'
>>> would be more indicative names.
>>
>> The name 'window-restore-set-context' looks quite self-contradictory.
>> If your intention was to use a unique prefix, then maybe we could use the
>> prefix 'window-context' like in 'window-context-set', 'window-context-use'.
>
> I'd say the context of a window are the other windows of the same frame.
This was meant to denote a context inside a window.
Then maybe a better prefix would be 'window-point-context'?
>>> Note that when a buffer is killed, the values of its local variables may
>>> be lost. I don't know whether this is an issue here. Alternatively, we
>>> could have 'set_window_buffer' set the 'context' window parameter from
>>> the buffer-local value which would, however, mean that whenever one
>>> changes the buffer-local value, one would have to simultaneously update
>>> the parameters in all windows showing that buffer. Something that could
>>> be done with the help of an advice, though...
>>
>> This doesn't look like an issue here because the context is stored
>> in a window parameter.
>
> IIUC the context is stored but not the function to restore the position
> from the context.
Indeed, there was an idea to store a function that restores point, but
this might be problematic when saving such a function to the desktop file.
Therefore, the patch has two separate functions to save and restore context
as mere strings and numbers.
>> And when the buffer is killed, there is no need
>> to restore a context in the killed buffer.
>
> If you don't intend to restore the context from the file the buffer was
> visiting. Are you sure you don't want to do that?
After the buffer was killed? This doesn't seems necessary.
>> The format of the window parameter
>>
>> '(BUFFER-NAME . ((dired-filename . FILENAME)))
>>
>> uses BUFFER-NAME to check whether the buffer was killed,
>> and when the current window's buffer doesn't match BUFFER-NAME,
>> then do nothing.
>
> What do you do when you want to restore a configuration from a tab, that
> configuration contains a window whose buffer was killed but whose file
> still exists and you wanted to revisit that file in the window with its
> previous point? Ignore any context for that window?
I think such cases are very rare.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#33871; Package
emacs.
(Mon, 25 Mar 2024 15:59:02 GMT)
Full text and
rfc822 format available.
Message #146 received at 33871 <at> debbugs.gnu.org (full text, mbox):
> This was meant to denote a context inside a window.
> Then maybe a better prefix would be 'window-point-context'?
Do we want to restrict this to 'point'? What about start or end
positions?
>> IIUC the context is stored but not the function to restore the position
>> from the context.
>
> Indeed, there was an idea to store a function that restores point, but
> this might be problematic when saving such a function to the desktop file.
How comes?
> Therefore, the patch has two separate functions to save and restore context
> as mere strings and numbers.
>>> And when the buffer is killed, there is no need
>>> to restore a context in the killed buffer.
>>
>> If you don't intend to restore the context from the file the buffer was
>> visiting. Are you sure you don't want to do that?
>
> After the buffer was killed? This doesn't seems necessary.
Then why did we provide a facility to restore the point and start of a
window via 'window-restore-killed-buffer-windows'?
martin
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#33871; Package
emacs.
(Mon, 25 Mar 2024 17:21:02 GMT)
Full text and
rfc822 format available.
Message #149 received at 33871 <at> debbugs.gnu.org (full text, mbox):
>> This was meant to denote a context inside a window.
>> Then maybe a better prefix would be 'window-point-context'?
>
> Do we want to restrict this to 'point'? What about start or end
> positions?
It's impossible to keep window-start and window-end intact
when text in the buffer changes.
>>> IIUC the context is stored but not the function to restore the position
>>> from the context.
>>
>> Indeed, there was an idea to store a function that restores point, but
>> this might be problematic when saving such a function to the desktop file.
>
> How comes?
Because a function is not writable.
>> Therefore, the patch has two separate functions to save and restore context
>> as mere strings and numbers.
>
>>>> And when the buffer is killed, there is no need
>>>> to restore a context in the killed buffer.
>>>
>>> If you don't intend to restore the context from the file the buffer was
>>> visiting. Are you sure you don't want to do that?
>>
>> After the buffer was killed? This doesn't seems necessary.
>
> Then why did we provide a facility to restore the point and start of a
> window via 'window-restore-killed-buffer-windows'?
'window-restore-killed-buffer-windows' already restores
point and start of a window, so there is no problem.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#33871; Package
emacs.
(Tue, 26 Mar 2024 14:05:02 GMT)
Full text and
rfc822 format available.
Message #152 received at 33871 <at> debbugs.gnu.org (full text, mbox):
> It's impossible to keep window-start and window-end intact
> when text in the buffer changes.
It would depend on the change.
> Because a function is not writable.
A function name is.
> 'window-restore-killed-buffer-windows' already restores
> point and start of a window, so there is no problem.
OK. I won't insist.
martin
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#33871; Package
emacs.
(Thu, 28 Mar 2024 07:58:02 GMT)
Full text and
rfc822 format available.
Message #155 received at 33871 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
>> 'window-restore-killed-buffer-windows' already restores
>> point and start of a window, so there is no problem.
>
> OK. I won't insist.
So now here is the final patch:
[window-point-context.patch (text/x-diff, inline)]
diff --git a/lisp/window.el b/lisp/window.el
index df55a7ca673..1ec45027f4c 100644
--- a/lisp/window.el
+++ b/lisp/window.el
@@ -10834,6 +10872,77 @@ window--adjust-process-windows
(set-process-window-size process (cdr size) (car size))))))))))
(add-hook 'window-configuration-change-hook 'window--adjust-process-windows)
+
+
+;;; Window point context
+
+(defun window-point-context-set ()
+ "Set context near the window point.
+Call `window-point-context-set-function' to get the context near the window
+point of every window on the frame. This function is called with the
+window argument. During the call the current buffer is set to the window
+buffer, but its window is not selected. It's expected that the called
+function will use the window point to return a data structure that will
+help later to find the same location again. After the call remember the
+returned context in the window parameter `context'."
+ (walk-windows
+ (lambda (w)
+ (with-current-buffer (window-buffer w)
+ (when-let (((functionp window-point-context-set-function))
+ (context (funcall window-point-context-set-function w)))
+ (set-window-parameter w 'context (cons (buffer-name) context)))))
+ 'nomini))
+
+(defun window-point-context-use ()
+ "Use context to relocate the window point.
+Call `window-point-context-use-function' to move the window point according
+to the previously saved context. For every window on the frame this
+function is called with two agreements: the window and the context data
+structure saved by `window-point-context-set-function' in the window
+parameter `context'. During the call the current buffer is set to the
+window buffer, but its window is not selected. It's expected that the
+called function will set the window point to the location found by using
+the provided context."
+ (walk-windows
+ (lambda (w)
+ (with-current-buffer (window-buffer w)
+ (when-let (((functionp window-point-context-use-function))
+ (context (window-parameter w 'context))
+ ((equal (buffer-name) (car context))))
+ (funcall window-point-context-use-function w (cdr context))
+ (set-window-parameter w 'context nil))))
+ 'nomini))
+
+(add-to-list 'window-persistent-parameters '(context . writable))
+
+(defun window-point-context-set-default-function (w)
+ "Set context of file buffers to the front and rear strings."
+ (when buffer-file-name
+ (let ((point (window-point w)))
+ `((front-context-string
+ . ,(buffer-substring-no-properties
+ point (min (+ point 16) (point-max))))
+ (rear-context-string
+ . ,(buffer-substring-no-properties
+ point (max (- point 16) (point-min))))))))
+
+(defun window-point-context-use-default-function (w context)
+ "Restore context of file buffers by the front and rear strings."
+ (let ((point (window-point w)))
+ (save-excursion
+ (goto-char point)
+ (when-let ((f (alist-get 'front-context-string context))
+ ((search-forward f (point-max) t)))
+ (goto-char (match-beginning 0))
+ (when-let ((r (alist-get 'rear-context-string context))
+ ((search-backward r (point-min) t)))
+ (goto-char (match-end 0))
+ (setq point (point)))))
+ (set-window-point w point)))
+
+(defvar window-point-context-set-function 'window-point-context-set-default-function)
+(defvar window-point-context-use-function 'window-point-context-use-default-function)
+
;; Some of these are in tutorial--default-keys, so update that if you
;; change these.
diff --git a/lisp/dired.el b/lisp/dired.el
index 9e3b888df14..3eb4351c93e 100644
--- a/lisp/dired.el
+++ b/lisp/dired.el
@@ -2743,6 +2745,24 @@ dired-mode
'(dired-font-lock-keywords t nil nil beginning-of-line))
(setq-local desktop-save-buffer 'dired-desktop-buffer-misc-data)
(setq-local grep-read-files-function #'dired-grep-read-files)
+ (setq-local window-point-context-set-function
+ (lambda (w)
+ (let ((point (window-point w)))
+ (save-excursion
+ (goto-char point)
+ (if-let ((f (dired-get-filename nil t)))
+ `((dired-filename . ,f))
+ `((position . ,(point))))))))
+ (setq-local window-point-context-use-function
+ (lambda (w context)
+ (let ((point (window-point w)))
+ (save-excursion
+ (if-let ((f (alist-get 'dired-filename context)))
+ (dired-goto-file f)
+ (when-let ((p (alist-get 'position context)))
+ (goto-char p)))
+ (setq point (point)))
+ (set-window-point w point))))
(setq dired-switches-alist nil)
(hack-dir-local-variables-non-file-buffer) ; before sorting
(dired-sort-other dired-actual-switches t)
diff --git a/lisp/tab-bar.el b/lisp/tab-bar.el
index fa22500a04e..ca0c92e903f 100644
--- a/lisp/tab-bar.el
+++ b/lisp/tab-bar.el
@@ -1292,6 +1292,9 @@ tab-bar--tab
frame 'buffer-list)))
(bbl (seq-filter #'buffer-live-p (frame-parameter
frame 'buried-buffer-list))))
+ (when tab-bar-select-restore-context
+ (window-point-context-set))
+
`(tab
(name . ,(if tab-explicit-name
(alist-get 'name tab)
@@ -1442,6 +1445,12 @@ tab-bar-select-restore-windows
(setq buffer-read-only t)
(set-window-buffer window new-buffer))))))
+(defcustom tab-bar-select-restore-context t
+ "Non-nil to restore context of the selected tab."
+ :type 'boolean
+ :group 'tab-bar
+ :version "30.1")
+
(defvar tab-bar-minibuffer-restore-tab nil
"Tab number for `tab-bar-minibuffer-restore-tab'.")
@@ -1539,6 +1548,9 @@ tab-bar-select-tab
(select-window (get-mru-window)))
(window-state-put ws nil 'safe)))
+ (when tab-bar-select-restore-context
+ (window-point-context-use))
+
;; Select the minibuffer when it was active before switching tabs
(when (and minibuffer-was-active (active-minibuffer-window))
(select-window (active-minibuffer-window)))
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#33871; Package
emacs.
(Thu, 28 Mar 2024 09:19:02 GMT)
Full text and
rfc822 format available.
Message #158 received at 33871 <at> debbugs.gnu.org (full text, mbox):
> So now here is the final patch:
For 'window-point-context-set' I'd rather write something like:
Call function specified by `window-point-context-set-function' for every
live window on the selected frame with that window as sole argument and
that window's buffer current. The function called is supposed to return
a context of the window's point that can be later used as argument for
`window-point-context-use'. Remember the returned context in the window
parameter `context'.
+function is called with two agreements: the window and the context data
^^^^^^^^^^
I still don't get why you use 'with-current-buffer' here. IIUC usually
a buffer does not have 'window-point-context-set-function' set and so a
simple
(buffer-local-value 'window-point-context-set-function (window-buffer w))
should suffice.
martin
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#33871; Package
emacs.
(Thu, 28 Mar 2024 18:06:02 GMT)
Full text and
rfc822 format available.
Message #161 received at 33871 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
>> So now here is the final patch:
>
> For 'window-point-context-set' I'd rather write something like:
>
> Call function specified by `window-point-context-set-function' for every
> live window on the selected frame with that window as sole argument and
> that window's buffer current. The function called is supposed to return
> a context of the window's point that can be later used as argument for
> `window-point-context-use'. Remember the returned context in the window
> parameter `context'.
Thanks for the suggestion, this is added in a new patch.
> I still don't get why you use 'with-current-buffer' here. IIUC usually
> a buffer does not have 'window-point-context-set-function' set and so a
> simple
>
> (buffer-local-value 'window-point-context-set-function (window-buffer w))
>
> should suffice.
Ok, let's use buffer-local-value:
[window-point-context.patch (text/x-diff, inline)]
diff --git a/lisp/window.el b/lisp/window.el
index df55a7ca673..3998f869855 100644
--- a/lisp/window.el
+++ b/lisp/window.el
@@ -10834,6 +10878,78 @@ window--adjust-process-windows
(set-process-window-size process (cdr size) (car size))))))))))
(add-hook 'window-configuration-change-hook 'window--adjust-process-windows)
+
+
+;;; Window point context
+
+(defun window-point-context-set ()
+ "Set context near the window point.
+Call function specified by `window-point-context-set-function' for every
+live window on the selected frame with that window as sole argument.
+The function called is supposed to return a context of the window's point
+that can be later used as argument for `window-point-context-use-function'.
+Remember the returned context in the window parameter `context'."
+ (walk-windows
+ (lambda (w)
+ (when-let ((fn (buffer-local-value 'window-point-context-set-function
+ (window-buffer w)))
+ ((functionp fn))
+ (context (funcall fn w)))
+ (set-window-parameter w 'context (cons (buffer-name) context))))
+ 'nomini))
+
+(defun window-point-context-use ()
+ "Use context to relocate the window point.
+Call function specified by `window-point-context-use-function' to move the
+window point according to the previously saved context. For every live
+window on the selected frame this function is called with two arguments:
+the window and the context data structure saved by
+`window-point-context-set-function' in the window parameter `context'.
+The function called is supposed to set the window point to the location
+found by the provided context."
+ (walk-windows
+ (lambda (w)
+ (when-let ((fn (buffer-local-value 'window-point-context-use-function
+ (window-buffer w)))
+ ((functionp fn))
+ (context (window-parameter w 'context))
+ ((equal (buffer-name) (car context))))
+ (funcall fn w (cdr context))
+ (set-window-parameter w 'context nil)))
+ 'nomini))
+
+(add-to-list 'window-persistent-parameters '(context . writable))
+
+(defun window-point-context-set-default-function (w)
+ "Set context of file buffers to the front and rear strings."
+ (with-current-buffer (window-buffer w)
+ (when buffer-file-name
+ (let ((point (window-point w)))
+ `((front-context-string
+ . ,(buffer-substring-no-properties
+ point (min (+ point 16) (point-max))))
+ (rear-context-string
+ . ,(buffer-substring-no-properties
+ point (max (- point 16) (point-min)))))))))
+
+(defun window-point-context-use-default-function (w context)
+ "Restore context of file buffers by the front and rear strings."
+ (with-current-buffer (window-buffer w)
+ (let ((point (window-point w)))
+ (save-excursion
+ (goto-char point)
+ (when-let ((f (alist-get 'front-context-string context))
+ ((search-forward f (point-max) t)))
+ (goto-char (match-beginning 0))
+ (when-let ((r (alist-get 'rear-context-string context))
+ ((search-backward r (point-min) t)))
+ (goto-char (match-end 0))
+ (setq point (point)))))
+ (set-window-point w point))))
+
+(defvar window-point-context-set-function 'window-point-context-set-default-function)
+(defvar window-point-context-use-function 'window-point-context-use-default-function)
+
;; Some of these are in tutorial--default-keys, so update that if you
;; change these.
diff --git a/lisp/dired.el b/lisp/dired.el
index 9e3b888df14..0c73ae31e96 100644
--- a/lisp/dired.el
+++ b/lisp/dired.el
@@ -2743,6 +2745,26 @@ dired-mode
'(dired-font-lock-keywords t nil nil beginning-of-line))
(setq-local desktop-save-buffer 'dired-desktop-buffer-misc-data)
(setq-local grep-read-files-function #'dired-grep-read-files)
+ (setq-local window-point-context-set-function
+ (lambda (w)
+ (with-current-buffer (window-buffer w)
+ (let ((point (window-point w)))
+ (save-excursion
+ (goto-char point)
+ (if-let ((f (dired-get-filename nil t)))
+ `((dired-filename . ,f))
+ `((position . ,(point)))))))))
+ (setq-local window-point-context-use-function
+ (lambda (w context)
+ (with-current-buffer (window-buffer w)
+ (let ((point (window-point w)))
+ (save-excursion
+ (if-let ((f (alist-get 'dired-filename context)))
+ (dired-goto-file f)
+ (when-let ((p (alist-get 'position context)))
+ (goto-char p)))
+ (setq point (point)))
+ (set-window-point w point)))))
(setq dired-switches-alist nil)
(hack-dir-local-variables-non-file-buffer) ; before sorting
(dired-sort-other dired-actual-switches t)
diff --git a/lisp/tab-bar.el b/lisp/tab-bar.el
index fa22500a04e..95bf3f9bc81 100644
--- a/lisp/tab-bar.el
+++ b/lisp/tab-bar.el
@@ -1292,6 +1292,9 @@ tab-bar--tab
frame 'buffer-list)))
(bbl (seq-filter #'buffer-live-p (frame-parameter
frame 'buried-buffer-list))))
+ (when tab-bar-select-restore-context
+ (window-point-context-set))
+
`(tab
(name . ,(if tab-explicit-name
(alist-get 'name tab)
@@ -1442,6 +1445,16 @@ tab-bar-select-restore-windows
(setq buffer-read-only t)
(set-window-buffer window new-buffer))))))
+(defcustom tab-bar-select-restore-context t
+ "Non-nil to restore previous context in every window of the selected tab.
+This will try to find the same position in the buffer where point was
+before switching away from this tab. After selecting this tab again,
+point will be moved to its previous place in the buffer even when
+buffer was modified."
+ :type 'boolean
+ :group 'tab-bar
+ :version "30.1")
+
(defvar tab-bar-minibuffer-restore-tab nil
"Tab number for `tab-bar-minibuffer-restore-tab'.")
@@ -1539,6 +1552,9 @@ tab-bar-select-tab
(select-window (get-mru-window)))
(window-state-put ws nil 'safe)))
+ (when tab-bar-select-restore-context
+ (window-point-context-use))
+
;; Select the minibuffer when it was active before switching tabs
(when (and minibuffer-was-active (active-minibuffer-window))
(select-window (active-minibuffer-window)))
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#33871; Package
emacs.
(Fri, 29 Mar 2024 08:46:01 GMT)
Full text and
rfc822 format available.
Message #164 received at 33871 <at> debbugs.gnu.org (full text, mbox):
> + "Non-nil to restore previous context in every window of the selected tab.
I'd write
"If this is non-nil, try to restore window points from their contexts.
and say what a context is next.
> +This will try to find the same position in the buffer where point was
> +before switching away from this tab. After selecting this tab again,
Why "again"?
> +point will be moved to its previous place in the buffer even when
> +buffer was modified."
"it" or "the buffer".
martin
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#33871; Package
emacs.
(Fri, 29 Mar 2024 16:36:01 GMT)
Full text and
rfc822 format available.
Message #167 received at 33871 <at> debbugs.gnu.org (full text, mbox):
>> + "Non-nil to restore previous context in every window of the selected tab.
>
> I'd write
>
> "If this is non-nil, try to restore window points from their contexts.
>
> and say what a context is next.
>
>> +This will try to find the same position in the buffer where point was
>> +before switching away from this tab. After selecting this tab again,
>
> Why "again"?
>
>> +point will be moved to its previous place in the buffer even when
>> +buffer was modified."
>
> "it" or "the buffer".
Thanks for the suggestions, here is the updated docstring:
diff --git a/lisp/tab-bar.el b/lisp/tab-bar.el
index c51600e6c6c..009dc6eed0c 100644
--- a/lisp/tab-bar.el
+++ b/lisp/tab-bar.el
@@ -1442,6 +1445,16 @@ tab-bar-select-restore-windows
(setq buffer-read-only t)
(set-window-buffer window new-buffer))))))
+(defcustom tab-bar-select-restore-context t
+ "If this is non-nil, try to restore window points from their contexts.
+This will try to find the same position in the buffer where point was
+before switching away from this tab. After selecting this tab,
+point will be moved to its previous place in the buffer even when
+the buffer was modified."
+ :type 'boolean
+ :group 'tab-bar
+ :version "30.1")
+
(defvar tab-bar-minibuffer-restore-tab nil
"Tab number for `tab-bar-minibuffer-restore-tab'.")
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#33871; Package
emacs.
(Sat, 30 Mar 2024 09:37:02 GMT)
Full text and
rfc822 format available.
Message #170 received at 33871 <at> debbugs.gnu.org (full text, mbox):
> + "If this is non-nil, try to restore window points from their contexts.
> +This will try to find the same position in the buffer where point was
> +before switching away from this tab. After selecting this tab,
> +point will be moved to its previous place in the buffer even when
> +the buffer was modified."
"this window's point" instead of "point" and "position" instead of
"place" would be more precise.
martin
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#33871; Package
emacs.
(Sat, 30 Mar 2024 18:25:02 GMT)
Full text and
rfc822 format available.
Message #173 received at 33871 <at> debbugs.gnu.org (full text, mbox):
>> + "If this is non-nil, try to restore window points from their contexts.
>> +This will try to find the same position in the buffer where point was
>> +before switching away from this tab. After selecting this tab,
>> +point will be moved to its previous place in the buffer even when
>> +the buffer was modified."
>
> "this window's point" instead of "point" and "position" instead of
> "place" would be more precise.
Ok:
(defcustom tab-bar-select-restore-context t
"If this is non-nil, try to restore window points from their contexts.
This will try to find the same position in every window where point was
before switching away from this tab. After selecting this tab,
point in every window will be moved to its previous position
in the buffer even when the buffer was modified."
:type 'boolean
:group 'tab-bar
:version "30.1")
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#33871; Package
emacs.
(Tue, 02 Apr 2024 17:23:02 GMT)
Full text and
rfc822 format available.
Message #176 received at 33871 <at> debbugs.gnu.org (full text, mbox):
close 33871 30.0.50
thanks
>> "this window's point" instead of "point" and "position" instead of
>> "place" would be more precise.
>
> Ok:
>
> (defcustom tab-bar-select-restore-context t
> "If this is non-nil, try to restore window points from their contexts.
> This will try to find the same position in every window where point was
> before switching away from this tab. After selecting this tab,
> point in every window will be moved to its previous position
> in the buffer even when the buffer was modified."
> :type 'boolean
> :group 'tab-bar
> :version "30.1")
So pushed now and closed. Thanks for the help!
bug marked as fixed in version 30.0.50, send any further explanations to
33871 <at> debbugs.gnu.org and Juri Linkov <juri <at> linkov.net>
Request was from
Juri Linkov <juri <at> linkov.net>
to
control <at> debbugs.gnu.org.
(Tue, 02 Apr 2024 17:23:02 GMT)
Full text and
rfc822 format available.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#33871; Package
emacs.
(Tue, 09 Apr 2024 06:46:04 GMT)
Full text and
rfc822 format available.
Message #181 received at 33871 <at> debbugs.gnu.org (full text, mbox):
> Note that
>
> + (with-selected-window w
> + (when (functionp window-set-context-function)
>
> and
>
> + (with-selected-window w
> + (when-let ((context (window-parameter w 'context)))
>
> would set up a precedence case for the future use of
> 'window-set-context-function'. Are you sure that you always want to
> select the window in question here or would it suffice to pass the
> window as argument to the context function?
With 'with-selected-window' the code was so simple: just one call
'with-selected-window' and no special handling needed. But
without 'with-selected-window' the code became more complicated
and error-prone. I just found another place that needed to use
the window's buffer, and fixed it. I don't know maybe
'with-selected-window' was not too bad? Or it has other problems?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#33871; Package
emacs.
(Tue, 09 Apr 2024 09:06:01 GMT)
Full text and
rfc822 format available.
Message #184 received at 33871 <at> debbugs.gnu.org (full text, mbox):
> With 'with-selected-window' the code was so simple: just one call
> 'with-selected-window' and no special handling needed. But
> without 'with-selected-window' the code became more complicated
> and error-prone. I just found another place that needed to use
> the window's buffer, and fixed it. I don't know maybe
> 'with-selected-window' was not too bad? Or it has other problems?
In my experience 'with-selected-window' is bad because any functions its
body calls cannot tell whether the selected window is the "real selected
window" and its buffer the "real current buffer" at that time. A
typical example is 'mode-line-format': users who wanted to paint the
mode line of the selected window in some special way could not do that
because they could not tell whether that window was the real selected
one. If such issues are of no concern, use 'with-selected-window'.
martin
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org.
(Tue, 07 May 2024 11:24:10 GMT)
Full text and
rfc822 format available.
This bug report was last modified 1 year and 70 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.