GNU bug report logs - #33458
27.0.50; dired loses position when reverted from outside place

Previous Next

Full log

View this message in rfc822 format

From: martin rudalics <rudalics <at> gmx.at>
To: Juri Linkov <juri <at> linkov.net>
Cc: Stephen Berman <stephen.berman <at> gmx.net>, 33458 <at> debbugs.gnu.org, v88m <at> posteo.net
Subject: bug#33458: 27.0.50; dired loses position when reverted from outside place
Date: Sun, 02 Dec 2018 09:33:57 +0100

> Code that sets 'window-point-from-point' could decide how
> 'window-point-from-point' should be used, e.g. if it sets
> a value 'all-windows' it affects all windows, if 'once'
> then reset after first use, etc.

The mechanism must be robust, in a sense.  We have two possibilities
when reverting a buffer:

(1) Trace the buffer markers we find in each window's list of previous
and next buffers via get_window_points_and_markers and update them via
restore_window_points.  This would slow down reverting to some extent
and not handle markers stored away in window cofigurations.

(2) Associate window point markers with some sort of time stamp and
compare that stamp against a buffer's stamp which is increased each
time the buffer gets reverted.  If a window point marker shall be
restored and its stamp is out-dated wrt that of the buffer,
automatically use the buffer's point instead and leave the window
start position to what is needed to get its point on-screen.

So far, I think we should adopt a hybrid strategy.  Handle a window's
previous and next buffers using the first approach.  Handle window
point markers stored in configurations using the second one.

> Then better idea: add a buffer-local variable with an alist
> mapping windows to dired-filenames or any other metadata:
>
> '((#<window 1> . (dired-filename . "file1"))
>    (#<window 2> . (dired-filename . "file2")))

Alternatively, we could replace the point/start markers in a window's
previous and next buffers with these file names but this would mean
that every time we switch to a buffer we'd have to check whether what
we stored there is a marker or something else.  OTOH some automatism
must check whether and how your alist mapping exists and resolve it in
some way.  Maybe a buffer-local 'switch-to-prev-buffer-function'
(consulted during switching) and/or a 'save-window-markers-function'
(consulted during saving) would suffice.

martin

Previous Next

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