bug#33458: 27.0.50; dired loses position when reverted from outside place

bug#33458: 27.0.50; dired loses position when reverted from outside place

[v88m]

If dired buffer reverted from outside it, cursor jumps to begin of the
buffer once this buffer becomes current again.

How to reproduce:

0. emacs -Q

1. Open some directory, say "DIR-A" in dired.

2. Move cursor to subdirectory, say "DIR-B", M-: (point) ;=> e.g. 225.

3. Dive into subdirectory "DIR-B".

4. Let's check position: M-: (with-current-buffer "DIR-A" (point)) ;=> 225, so cursor in the right place.

5. Revert original buffer: M-: (with-current-buffer "DIR-A" (dired-revert))

6. Check position again: M-: (with-current-buffer "DIR-A" (point)) ;=> 225, seems right here...

7. Switch back from the buffer with "DIR-B" to the buffer with "DIR-A".

8. Position lost! M-: (point) ;=> 1, but 225 expected.

The issue very spunky if auto-revert-mode is used.

Can't reproduce this issue with regular buffer, so it seems dired-specific.

In GNU Emacs 27.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.22.29)
 of 2018-11-21 built on pinball
Repository revision: e01d030723aef2f90a2fc53a0b5251f29df94527
Repository branch: master
Windowing system distributor 'The X.Org Foundation', version 11.0.11905000
System Description: Gentoo/Linux

Recent messages:
For information about GNU Emacs and the GNU system, type C-h C-a.
nil
Configured using:
 'configure --prefix=/usr --host=x86_64-pc-linux-gnu
 --mandir=/usr/share/man --infodir=/usr/share/info --datadir=/usr/share
 --sysconfdir=/etc --localstatedir=/var/lib --disable-silent-rules
 --docdir=/usr/share/doc/emacs-vcs-27.0.9999
 --htmldir=/usr/share/doc/emacs-vcs-27.0.9999/html --libdir=/usr/lib64
 --program-suffix=-emacs-27-vcs --infodir=/usr/share/info/emacs-27-vcs
 --localstatedir=/var
 --enable-locallisppath=/etc/emacs:/usr/share/emacs/site-lisp
 --without-compress-install --without-hesiod --without-pop
 --with-file-notification=inotify --enable-acl --with-dbus
 --without-modules --without-gameuser --with-gpm --without-json
 --without-kerberos --without-kerberos5 --with-lcms2 --without-xml2
 --without-mailutils --without-selinux --with-gnutls
 --without-libsystemd --with-threads --without-wide-int --with-zlib
 --with-sound=alsa --with-x --without-ns --with-gconf --with-libgmp
 --without-gsettings --without-toolkit-scroll-bars --with-gif
 --with-jpeg --with-png --with-rsvg --with-tiff --with-xpm
 --with-imagemagick --without-xft --without-cairo --without-libotf
 --without-m17n-flt --with-x-toolkit=gtk3 --without-xwidgets
 --build=x86_64-pc-linux-gnu 'CFLAGS=-O2 -march=native' CPPFLAGS=
 'LDFLAGS=-Wl,-O1 -Wl,--as-needed''

Configured features:
XPM JPEG TIFF GIF PNG RSVG IMAGEMAGICK SOUND GPM DBUS GCONF GLIB NOTIFY
INOTIFY ACL GNUTLS ZLIB GTK3 X11 XDBE XIM THREADS LCMS2 GMP

Important settings:
  value of $LC_ALL: 
  value of $LC_COLLATE: C
  value of $LC_CTYPE: ru_RU.UTF-8
  value of $LC_MESSAGES: en_US.UTF-8
  value of $LC_NUMERIC: en_US.UTF-8
  value of $LC_TIME: en_US.UTF-8
  value of $LANG: ru_RU.UTF-8
  value of $XMODIFIERS: @im=fcitx
  locale-coding-system: utf-8-unix

Major mode: Dired by name

Minor modes in effect:
  tooltip-mode: t
  global-eldoc-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  buffer-read-only: t
  line-number-mode: t
  transient-mark-mode: t

Load-path shadows:
None found.

Features:
(shadow sort mail-extr emacsbug message rmc puny seq byte-opt gv
bytecomp byte-compile cconv format-spec rfc822 mml mml-sec
password-cache epa derived epg epg-config gnus-util rmail rmail-loaddefs
time-date mm-decode mm-bodies mm-encode mail-parse rfc2231 mailabbrev
gmm-utils mailheader sendmail rfc2047 rfc2045 ietf-drums mm-util
mail-prsvr mail-utils help-fns radix-tree cl-print debug backtrace
help-mode easymenu find-func cl-loaddefs cl-lib dired dired-loaddefs
linum elec-pair mule-util cyril-util tooltip eldoc electric uniquify
ediff-hook vc-hooks lisp-float-type mwheel term/x-win x-win
term/common-win x-dnd tool-bar dnd fontset image regexp-opt fringe
tabulated-list replace newcomment text-mode elisp-mode lisp-mode
prog-mode register page menu-bar rfn-eshadow isearch timer select
scroll-bar mouse jit-lock font-lock syntax facemenu font-core
term/tty-colors frame cl-generic cham georgian utf-8-lang misc-lang
vietnamese tibetan thai tai-viet lao korean japanese eucjp-ms cp51932
hebrew greek romanian slovak czech european ethiopic indian cyrillic
chinese composite charscript charprop case-table epa-hook jka-cmpr-hook
help simple abbrev obarray minibuffer cl-preloaded nadvice loaddefs
button faces cus-face macroexp files text-properties overlay sha1 md5
base64 format env code-pages mule custom widget hashtable-print-readable
backquote threads dbusbind inotify lcms2 dynamic-setting move-toolbar
gtk x-toolkit x multi-tty make-network-process emacs)

Memory information:
((conses 16 106382 7985)
 (symbols 48 20662 1)
 (strings 32 30146 2249)
 (string-bytes 1 804766)
 (vectors 16 15988)
 (vector-slots 8 521603 19532)
 (floats 8 51 206)
 (intervals 56 1248 14)
 (buffers 992 17))

-- 
WBR, Yuri

bug#33458: 27.0.50; dired loses position when reverted from outside place

[Stephen Berman]

On Wed, 21 Nov 2018 23:40:09 +0300 v88m@posteo.net wrote:

> If dired buffer reverted from outside it, cursor jumps to begin of the
> buffer once this buffer becomes current again.
>
> How to reproduce:
>
> 0. emacs -Q
>
> 1. Open some directory, say "DIR-A" in dired.
>
> 2. Move cursor to subdirectory, say "DIR-B", M-: (point) ;=> e.g. 225.
>
> 3. Dive into subdirectory "DIR-B".
>
> 4. Let's check position: M-: (with-current-buffer "DIR-A" (point)) ;=>
> 225, so cursor in the right place.
>
> 5. Revert original buffer: M-: (with-current-buffer "DIR-A" (dired-revert))
>
> 6. Check position again: M-: (with-current-buffer "DIR-A" (point)) ;=>
> 225, seems right here...
>
> 7. Switch back from the buffer with "DIR-B" to the buffer with "DIR-A".
>
> 8. Position lost! M-: (point) ;=> 1, but 225 expected.
>
> The issue very spunky if auto-revert-mode is used.
>
> Can't reproduce this issue with regular buffer, so it seems dired-specific.

I assume you used `C-x b' (switch-to-buffer) to switch back.  If so,
this happens because dired-revert erases and then repopulates the buffer
it's called on, which relocates the markers used by switch-to-buffer to
find window-point when switch-to-buffer-preserve-window-point is t,
which is it by default since Emacs 26.  If you set that variable to nil,
point will be where you expected after `C-x b'.  Alternatively, if you
use `C-x d' (i.e. M-x dired) to return to the DIR-A buffer, point will
be where you expected (even if switch-to-buffer-preserve-window-point is
t).  See bug#27243,
https://lists.gnu.org/archive/html/bug-gnu-emacs/2017-06/msg00147.html

Steve Berman

bug#33458: 27.0.50; dired loses position when reverted from outside place

[v88m]

Thanks,

On Wed, Nov 21 2018, Stephen Berman wrote:

> I assume you used `C-x b' (switch-to-buffer) to switch back.

No, just close DIR-B buffer or do M-: (previous-buffer).

> If so, this happens because dired-revert erases and then repopulates
> the buffer it's called on, which relocates the markers used by
> switch-to-buffer to find window-point when
> switch-to-buffer-preserve-window-point is t, which is it by default
> since Emacs 26.  If you set that variable to nil, point will be where
> you expected after `C-x b'.

Now it works for `C-x b' but not for M-: (previous-buffer) of closing
DIR-B buffer. Point still lost.

> Alternatively, if you use `C-x d' (i.e. M-x dired) to return to the
> DIR-A buffer, point will be where you expected (even if
> switch-to-buffer-preserve-window-point is t).

Yes, it does, but more consistent behavior needed.

> See bug#27243,
> https://lists.gnu.org/archive/html/bug-gnu-emacs/2017-06/msg00147.html

Good explanation, but your patches seems outdated and doesn't work for
me either.

-- 
WBR, Yuri

bug#33458: 27.0.50; dired loses position when reverted from outside place

[Stephen Berman]

On Thu, 22 Nov 2018 12:07:04 +0300 v88m@posteo.net wrote:

> Thanks,
>
> On Wed, Nov 21 2018, Stephen Berman wrote:
>
>> I assume you used `C-x b' (switch-to-buffer) to switch back.
>
> No, just close DIR-B buffer or do M-: (previous-buffer).

Ah, ok, didn't think of those.

>> If so, this happens because dired-revert erases and then repopulates
>> the buffer it's called on, which relocates the markers used by
>> switch-to-buffer to find window-point when
>> switch-to-buffer-preserve-window-point is t, which is it by default
>> since Emacs 26.  If you set that variable to nil, point will be where
>> you expected after `C-x b'.
>
> Now it works for `C-x b' but not for M-: (previous-buffer) of closing
> DIR-B buffer. Point still lost.

Hmm...

>> Alternatively, if you use `C-x d' (i.e. M-x dired) to return to the
>> DIR-A buffer, point will be where you expected (even if
>> switch-to-buffer-preserve-window-point is t).
>
> Yes, it does, but more consistent behavior needed.

I agree.

>> See bug#27243,
>> https://lists.gnu.org/archive/html/bug-gnu-emacs/2017-06/msg00147.html
>
> Good explanation, but your patches seems outdated and doesn't work for
> me either.

It seems it's necessary to go back and look at the issue again, taking
your cases into account.  I don't have time to do that now, but will try
to when I can; maybe someone else will find a fix sooner.

Steve Berman

bug#33458: 27.0.50; dired loses position when reverted from outside place

[martin rudalics]

 >> I assume you used `C-x b' (switch-to-buffer) to switch back.
 >
 > No, just close DIR-B buffer or do M-: (previous-buffer).
 >
 >> If so, this happens because dired-revert erases and then repopulates
 >> the buffer it's called on, which relocates the markers used by
 >> switch-to-buffer to find window-point when
 >> switch-to-buffer-preserve-window-point is t, which is it by default
 >> since Emacs 26.  If you set that variable to nil, point will be where
 >> you expected after `C-x b'.
 >
 > Now it works for `C-x b' but not for M-: (previous-buffer) of closing
 > DIR-B buffer. Point still lost.

I don't understand well what you want to do here.  But please note
that C-x <left> does not "close" any buffer - it's purpose is to,
maybe only temporarily, show the buffer previously shown in the window
from where you invoke the command.  When invoked with a mouse click it
does not even select that window.  And it tries to show that buffer
with start and point position as shown last in that window.

martin

bug#33458: 27.0.50; dired loses position when reverted from outside place

[v88m]

On Fri, Nov 23 2018, martin rudalics wrote:

>  > Now it works for `C-x b' but not for M-: (previous-buffer) of closing
>  > DIR-B buffer. Point still lost.
>
> I don't understand well what you want to do here.

Typo. Should be:

M-: (previous-buffer) OR closing DIR-B buffer.

Note: "closing" is `kill-buffer' or `bury-buffer'.

-- 
WBR, Yuri

bug#33458: 27.0.50; dired loses position when reverted from outside place

[martin rudalics]

 > Typo. Should be:
 >
 > M-: (previous-buffer) OR closing DIR-B buffer.
 >
 > Note: "closing" is `kill-buffer' or `bury-buffer'.

Aha.  So after your

   4. Let's check position: M-: (with-current-buffer "DIR-A" (point)) ;=> 225, so cursor in the right place.

evaluate

M-: (window-prev-buffers)

You should find your DIR-A together with two markers, the second of
them should be 225.  Correct?  Now do your

   5. Revert original buffer: M-: (with-current-buffer "DIR-A" (dired-revert))

and evaluate

M-: (window-prev-buffers)

again.  The second marker will be at 1 because reverting DIR-A just
nuked it.

The only solution I can think of is to have 'dired-restore-positions'
scan 'window-prev-buffers' for each window and if it finds the buffer
that was reverted there, update the associated point position to the
position of the buffer's point it calculated itself.  If you want to
give it a try I can tell you everything you need to know.

A more generic solution might be wanted for other auto-revert clients
as well.  But that's more hairy and not of much use for dired anyway.

martin

bug#33458: 27.0.50; dired loses position when reverted from outside place

[v88m]

On Fri, Nov 23 2018, martin rudalics wrote:

>    4. Let's check position: M-: (with-current-buffer "DIR-A" (point)) ;=> 225, so cursor in the right place.
>
> evaluate
>
> M-: (window-prev-buffers)
>
> You should find your DIR-A together with two markers, the second of
> them should be 225.  Correct?  Now do your

Right.

>    5. Revert original buffer: M-: (with-current-buffer "DIR-A" (dired-revert))
>
> and evaluate
>
> M-: (window-prev-buffers)
>
> again.  The second marker will be at 1 because reverting DIR-A just
> nuked it.

Indeed.

> The only solution I can think of is to have 'dired-restore-positions'
> scan 'window-prev-buffers' for each window and if it finds the buffer
> that was reverted there, update the associated point position to the
> position of the buffer's point it calculated itself.  If you want to
> give it a try I can tell you everything you need to know.

Thank you! Currently I need some time to conceive this info.

-- 
WBR, Yuri

bug#33458: 27.0.50; dired loses position when reverted from outside place

[Juri Linkov]

> The only solution I can think of is to have 'dired-restore-positions'
> scan 'window-prev-buffers' for each window and if it finds the buffer
> that was reverted there, update the associated point position to the
> position of the buffer's point it calculated itself.  If you want to
> give it a try I can tell you everything you need to know.

I have the same problem with reverting Dired buffers that later
are restored from window states and window configurations.

Moreover, a similar problem is also an obstacle in bug#32536,
please see a detailed explanation I posted now there where
the reverted Man buffer invalidates markers in the Occur buffer.

> A more generic solution might be wanted for other auto-revert clients
> as well.  But that's more hairy and not of much use for dired anyway.

Is it possible to fix all these problems by not resetting markers to the
beginning of the reverted buffer, but allowing markers to keep their
previous positions in reverted buffers?  Or maybe reverting functions
should be more smart to restore markers using remembered context,
like e.g. bookmarks do.

bug#33458: 27.0.50; dired loses position when reverted from outside place

[martin rudalics]

 >> A more generic solution might be wanted for other auto-revert clients
 >> as well.  But that's more hairy and not of much use for dired anyway.
 >
 > Is it possible to fix all these problems by not resetting markers to the
 > beginning of the reverted buffer, but allowing markers to keep their
 > previous positions in reverted buffers?

It might work often.  But in the cases whehre it does not work it will
cause so much confusion that we won't get through with it.  AFAICT
even the current point restoring mechanism bows out when characters
are added/removed at the beginning of the buffer.

 > Or maybe reverting functions
 > should be more smart to restore markers using remembered context,
 > like e.g. bookmarks do.

Indeed.  Although doing that incorrectly might be even more annoying.
Always think of two identical text passages and a reverting function
move a marker from one to the other.  IIUC, this can only be avoided
by scanning the entire text for identical passages and never revert a
marker when one is found.

martin

bug#33458: 27.0.50; dired loses position when reverted from outside place

[Juri Linkov]

>>> A more generic solution might be wanted for other auto-revert clients
>>> as well.  But that's more hairy and not of much use for dired anyway.
>>
>> Is it possible to fix all these problems by not resetting markers to the
>> beginning of the reverted buffer, but allowing markers to keep their
>> previous positions in reverted buffers?
>
> It might work often.  But in the cases where it does not work it will
> cause so much confusion that we won't get through with it.  AFAICT
> even the current point restoring mechanism bows out when characters
> are added/removed at the beginning of the buffer.

Maybe marker-position should allow to call a function?
For example, like 'isearch-push-state-function' remembers
an additional state as a lambda, and when an old state is
restored, a pop-fun lambda is called.  The function that
restores the buffer in the window could be the same.

bug#33458: 27.0.50; dired loses position when reverted from outside place

[martin rudalics]

 > Maybe marker-position should allow to call a function?
 > For example, like 'isearch-push-state-function' remembers
 > an additional state as a lambda, and when an old state is
 > restored, a pop-fun lambda is called.  The function that
 > restores the buffer in the window could be the same.

The problem we face here is almost exclusively restricted to reverting
buffers and 'marker-position' is too heavily used as to be affected by
that.  Now, if we talk about dired buffers only, they have a very
helpful restriction that invariably permeates all file systems: The
file names in a directory must be unique.  So if a marker is on the
line of a file name it can quite easily return to that name after
reversal (provided the file still exists).  A similar argument should
hold for non-file visiting buffers like Buffer List buffers.  Finally,
in quite a number of cases 'auto-revert-tail-mode' should take care of
markers in the unchanged initial part of a file.  Do we have many
other auto-reverted buffers?

martin

bug#33458: 27.0.50; dired loses position when reverted from outside place

[Juri Linkov]

>> Maybe marker-position should allow to call a function?
>> For example, like 'isearch-push-state-function' remembers
>> an additional state as a lambda, and when an old state is
>> restored, a pop-fun lambda is called.  The function that
>> restores the buffer in the window could be the same.
>
> The problem we face here is almost exclusively restricted to reverting
> buffers and 'marker-position' is too heavily used as to be affected by
> that.  Now, if we talk about dired buffers only, they have a very
> helpful restriction that invariably permeates all file systems: The
> file names in a directory must be unique.  So if a marker is on the
> line of a file name it can quite easily return to that name after
> reversal (provided the file still exists).  A similar argument should
> hold for non-file visiting buffers like Buffer List buffers.  Finally,
> in quite a number of cases 'auto-revert-tail-mode' should take care of
> markers in the unchanged initial part of a file.

While 'isearch-push-state-function' could be used for example to save
and restore window start positions on returning to previous search hits:

(setq isearch-push-state-function
      (lambda ()
        `(lambda (cmd)
           (when isearch-success
             (set-window-start nil ,(window-start))))))

wouldn't it be possible to use something like this to
restore Dired point from the saved dired-filename.

And in non-dired buffers maybe at least when a window is restored from
the window configuration or from the window state, then simply restore
window point from the saved point when the saved point-marker is
invalidated (its value is 1).  Currently window-state-get when not used
with the WRITABLE arg, saves only point-marker, but maybe should save
both: point and point-marker, for the case when point-marker invalidates
after the buffer is reverted.

> Do we have many other auto-reverted buffers?

See for example how point is preserved in an intelligent way at the end
of revert-buffer-insert-file-contents--default-function that uses
insert-file-contents to preserve some marker positions.

bug#33458: 27.0.50; dired loses position when reverted from outside place

[martin rudalics]

 > While 'isearch-push-state-function' could be used for example to save
 > and restore window start positions on returning to previous search hits:
 >
 > (setq isearch-push-state-function
 >        (lambda ()
 >          `(lambda (cmd)
 >             (when isearch-success
 >               (set-window-start nil ,(window-start))))))
 >
 > wouldn't it be possible to use something like this to
 > restore Dired point from the saved dired-filename.

As I mentioned earlier, dired is special because file names are
unique.  We just have to code it.

 > And in non-dired buffers maybe at least when a window is restored from
 > the window configuration or from the window state, then simply restore
 > window point from the saved point when the saved point-marker is
 > invalidated (its value is 1).  Currently window-state-get when not used
 > with the WRITABLE arg, saves only point-marker, but maybe should save
 > both: point and point-marker, for the case when point-marker invalidates
 > after the buffer is reverted.

I still think that going to a wrong position in the middle of the
buffer occasionally is worse then predictably going to point-min.

 > See for example how point is preserved in an intelligent way at the end
 > of revert-buffer-insert-file-contents--default-function that uses
 > insert-file-contents to preserve some marker positions.

You mean the 'restore_window_points' mechanism?  Then we would have to
make its information available in Lisp.  Certainly worthwhile.

martin

bug#33458: 27.0.50; dired loses position when reverted from outside place

[Juri Linkov]

>> See for example how point is preserved in an intelligent way at the end
>> of revert-buffer-insert-file-contents--default-function that uses
>> insert-file-contents to preserve some marker positions.
>
> You mean the 'restore_window_points' mechanism?  Then we would have to
> make its information available in Lisp.  Certainly worthwhile.

I understand better now where is the root of the problem.
The same problem exists for example in vc-annotate.
I wasted too much time waiting while each vc-annotate invocation
finishes its long-running process and sets the window point.
Usually when running a long-running process, I can switch to another
buffer in the window with the buffer where process is not yet finished,
or switch to another window configuration/state to do other work,
but I can't hide the annotation window because then it will fail
to set window point to the line corresponding to the source file.
So I have to do nothing, just wait when it finishes.
Is it possible to fix this annoyance?  In vc-annotate this problem
is explained as:

       ;; Ideally, we'd rather not move point if the user has already
       ;; moved it elsewhere, but really point here is not the position
       ;; of the user's cursor :-(
       (when current-line           ;(and (bobp))
         (goto-char (point-min))
         (forward-line (1- current-line))
         (setq vc-sentinel-movepoint (point)))

and in vc--process-sentinel:

          ;; But sometimes the sentinels really want to move point.
          (when vc-sentinel-movepoint
	    (let ((win (get-buffer-window (current-buffer) 0)))
	      (if (not win)
		  (goto-char vc-sentinel-movepoint)
		(with-selected-window win
		  (goto-char vc-sentinel-movepoint)))))

so when the buffer is not displayed in a window, it calls
`(goto-char vc-sentinel-movepoint)'.

The main question: why the result of setting point with goto-char
is ignored when the buffer's display is restored in a window?

Maybe we should introduce a new buffer-local variable with a name like
window-point, to set it like (setq window-point vc-sentinel-movepoint)
or in dired-revert like (setq window-point dired-point)
Then window functions that display the buffer in a window should
obey this variable and set the window point to the requested value.

bug#33458: 27.0.50; dired loses position when reverted from outside place

[Eli Zaretskii]

> From: Juri Linkov <juri@linkov.net>
> Date: Thu, 29 Nov 2018 01:45:20 +0200
> Cc: Stephen Berman <stephen.berman@gmx.net>, 33458@debbugs.gnu.org,
> 	v88m@posteo.net
> 
> The main question: why the result of setting point with goto-char
> is ignored when the buffer's display is restored in a window?

Because switch-to-buffer-preserve-window-point is non-nil?

bug#33458: 27.0.50; dired loses position when reverted from outside place

[Juri Linkov]

>> The main question: why the result of setting point with goto-char
>> is ignored when the buffer's display is restored in a window?
>
> Because switch-to-buffer-preserve-window-point is non-nil?

Setting switch-to-buffer-preserve-window-point to nil really helps,
but only in the case of switching buffers with 'C-x b'.  It doesn't
help when the buffer is displayed with any other command such as
'C-x <C-left>' (previous-buffer) or with set-window-configuration
or window-state-put, etc.

bug#33458: 27.0.50; dired loses position when reverted from outside place

[v88m]

On Fri, Nov 30 2018, Juri Linkov wrote:

> Setting switch-to-buffer-preserve-window-point to nil really helps,
> but only in the case of switching buffers with 'C-x b'.  It doesn't
> help when the buffer is displayed with any other command such as
> 'C-x <C-left>' (previous-buffer) or with set-window-configuration
> or window-state-put, etc.

According to documentation in some cases this variable is ignored. It
seems we faced those.

-- 
WBR, Yuri

bug#33458: 27.0.50; dired loses position when reverted from outside place

[Juri Linkov]

>> Setting switch-to-buffer-preserve-window-point to nil really helps,
>> but only in the case of switching buffers with 'C-x b'.  It doesn't
>> help when the buffer is displayed with any other command such as
>> 'C-x <C-left>' (previous-buffer) or with set-window-configuration
>> or window-state-put, etc.
>
> According to documentation in some cases this variable is ignored. It
> seems we faced those.

Thanks for the reference to switch-to-buffer-preserve-window-point.
I see that we have to add more ignored cases: pop-to-buffer-same-window.

bug#33458: 27.0.50; dired loses position when reverted from outside place

[martin rudalics]

 > Setting switch-to-buffer-preserve-window-point to nil really helps,
 > but only in the case of switching buffers with 'C-x b'.  It doesn't
 > help when the buffer is displayed with any other command such as
 > 'C-x <C-left>' (previous-buffer) or with set-window-configuration
 > or window-state-put, etc.

The earlier mentioned 'set-window-point-from-point' (better maybe
'window-point-from-point') could make specific or even all uses of
'window-point' use the buffer's point instead.

martin

bug#33458: 27.0.50; dired loses position when reverted from outside place

[martin rudalics]

 > The main question: why the result of setting point with goto-char
 > is ignored when the buffer's display is restored in a window?

Because it uses a marker position that was reset and not restored when
reverting the buffer.  We'd have to assess how reverting a buffer
affects window start and point positions when the buffer is displayed
in several windows with different such positions.  If that mechanism
works satisfactorily (and I think it does), it would be nice to extend
it to the lists of windows' previous buffer start and point markers as
you suggested earlier.  Provided it's not too expensive.

 > Maybe we should introduce a new buffer-local variable with a name like
 > window-point, to set it like (setq window-point vc-sentinel-movepoint)
 > or in dired-revert like (setq window-point dired-point)
 > Then window functions that display the buffer in a window should
 > obey this variable and set the window point to the requested value.

The buffer's point is OK.  So we could introduce a variable, say
'set-window-point-from-point', and set this to t when reverting a
buffer reveals that 'get-buffer-window' is nil.  Redisplaying the
buffer would then always go to the buffer's point instead of some
position stored in the window's list of previous buffers.

I'm not sure when to reset this mechanism though.  The first time we
display the buffer again?  Then switching to that buffer in another
window later would suffer from the initial problem.  Keep it for every
other window until it has seen the buffer again?  How would we do
that?

Finally note that this does not fix the dired problem.  There we want
the cursor go to the line showing the file where point previously was
in that window.

martin

bug#33458: 27.0.50; dired loses position when reverted from outside place

[Juri Linkov]

> The buffer's point is OK.  So we could introduce a variable, say
> 'set-window-point-from-point', and set this to t when reverting a
> buffer reveals that 'get-buffer-window' is nil.  Redisplaying the
> buffer would then always go to the buffer's point instead of some
> position stored in the window's list of previous buffers.
>
> I'm not sure when to reset this mechanism though.  The first time we
> display the buffer again?  Then switching to that buffer in another
> window later would suffer from the initial problem.  Keep it for every
> other window until it has seen the buffer again?  How would we do
> that?

Maybe until point is moved to another position either by the user or
by any other code that doesn't set 'set-window-point-from-point' again.

> Finally note that this does not fix the dired problem.  There we want
> the cursor go to the line showing the file where point previously was
> in that window.

Maybe for dired store meta-information such as dired-filename
in window parameters.  Then when a dired buffer is restored in a window,
and dired-revert moved point-marker to the beginning of the dired buffer,
move point to the file from the window parameter.

bug#33458: 27.0.50; dired loses position when reverted from outside place

[v88m]

On Fri, Nov 30 2018, Juri Linkov wrote:

> Maybe for dired store meta-information such as dired-filename
> in window parameters.  Then when a dired buffer is restored in a window,
> and dired-revert moved point-marker to the beginning of the dired buffer,
> move point to the file from the window parameter.

What if file referenced by such `dired-filename' was deleted? It is
desirable to move to next or prev. filename but not to stay in the
beginning of the dired buffer.

-- 
WBR, Yuri

bug#33458: 27.0.50; dired loses position when reverted from outside place

[martin rudalics]

 >> Maybe for dired store meta-information such as dired-filename
 >> in window parameters.  Then when a dired buffer is restored in a window,
 >> and dired-revert moved point-marker to the beginning of the dired buffer,
 >> move point to the file from the window parameter.
 >
 > What if file referenced by such `dired-filename' was deleted? It is
 > desirable to move to next or prev. filename but not to stay in the
 > beginning of the dired buffer.

These others may have been deleted as well so I think that remaining
at the beginning of the dired buffer is more predictable here.  Note
also that the next or previous filename may depend on the order in
which filenames are shown - what if reverting changed that order?

martin

bug#33458: 27.0.50; dired loses position when reverted from outside place

[martin rudalics]

 >> The buffer's point is OK.  So we could introduce a variable, say
 >> 'set-window-point-from-point', and set this to t when reverting a
 >> buffer reveals that 'get-buffer-window' is nil.  Redisplaying the
 >> buffer would then always go to the buffer's point instead of some
 >> position stored in the window's list of previous buffers.
 >>
 >> I'm not sure when to reset this mechanism though.  The first time we
 >> display the buffer again?  Then switching to that buffer in another
 >> window later would suffer from the initial problem.  Keep it for every
 >> other window until it has seen the buffer again?  How would we do
 >> that?
 >
 > Maybe until point is moved to another position either by the user or
 > by any other code that doesn't set 'set-window-point-from-point' again.

I'm not sure how to avoid defeating the idea behind 'window-point' -
showing the same buffer at different positions simultaneously.

 >> Finally note that this does not fix the dired problem.  There we want
 >> the cursor go to the line showing the file where point previously was
 >> in that window.
 >
 > Maybe for dired store meta-information such as dired-filename
 > in window parameters.  Then when a dired buffer is restored in a window,
 > and dired-revert moved point-marker to the beginning of the dired buffer,
 > move point to the file from the window parameter.

Interesting idea.  The parameter could also include the name of the
file at 'window-start' and try to restore that position as well.
Still we'd have to access each window's list of previous and next
buffers and store the parameter only if the buffer appears in any of
these lists (not to talk about window configurations stored somewhere
else).  And we would have to remove the parameter whenever the buffer
gets killed.

martin

bug#33458: 27.0.50; dired loses position when reverted from outside place

[Juri Linkov]

>>> The buffer's point is OK.  So we could introduce a variable, say
>>> 'set-window-point-from-point', and set this to t when reverting a
>>> buffer reveals that 'get-buffer-window' is nil.  Redisplaying the
>>> buffer would then always go to the buffer's point instead of some
>>> position stored in the window's list of previous buffers.
>>>
>>> I'm not sure when to reset this mechanism though.  The first time we
>>> display the buffer again?  Then switching to that buffer in another
>>> window later would suffer from the initial problem.  Keep it for every
>>> other window until it has seen the buffer again?  How would we do
>>> that?
>>
>> Maybe until point is moved to another position either by the user or
>> by any other code that doesn't set 'set-window-point-from-point' again.
>
> I'm not sure how to avoid defeating the idea behind 'window-point' -
> showing the same buffer at different positions simultaneously.

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.

>>> Finally note that this does not fix the dired problem.  There we want
>>> the cursor go to the line showing the file where point previously was
>>> in that window.
>>
>> Maybe for dired store meta-information such as dired-filename
>> in window parameters.  Then when a dired buffer is restored in a window,
>> and dired-revert moved point-marker to the beginning of the dired buffer,
>> move point to the file from the window parameter.
>
> Interesting idea.  The parameter could also include the name of the
> file at 'window-start' and try to restore that position as well.
> Still we'd have to access each window's list of previous and next
> buffers and store the parameter only if the buffer appears in any of
> these lists (not to talk about window configurations stored somewhere
> else).  And we would have to remove the parameter whenever the buffer
> gets killed.

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")))

bug#33458: 27.0.50; dired loses position when reverted from outside place

[martin rudalics]

 > 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

bug#33458: 27.0.50; dired loses position when reverted from outside place

[martin rudalics]

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

 > If dired buffer reverted from outside it, cursor jumps to begin of the
 > buffer once this buffer becomes current again.
 >
 > How to reproduce:
 >
 > 0. emacs -Q
 >
 > 1. Open some directory, say "DIR-A" in dired.
 >
 > 2. Move cursor to subdirectory, say "DIR-B", M-: (point) ;=> e.g. 225.
 >
 > 3. Dive into subdirectory "DIR-B".
 >
 > 4. Let's check position: M-: (with-current-buffer "DIR-A" (point)) ;=> 225, so cursor in the right place.
 >
 > 5. Revert original buffer: M-: (with-current-buffer "DIR-A" (dired-revert))
 >
 > 6. Check position again: M-: (with-current-buffer "DIR-A" (point)) ;=> 225, seems right here...
 >
 > 7. Switch back from the buffer with "DIR-B" to the buffer with "DIR-A".
 >
 > 8. Position lost! M-: (point) ;=> 1, but 225 expected.
 >
 > The issue very spunky if auto-revert-mode is used.
 >
 > Can't reproduce this issue with regular buffer, so it seems dired-specific.

The attached patch should fix this problem and the other ones with
'dired' that have been cited in this context.  Please try it.

Thanks, martin

[-- Attachment #2: dired.diffs --]
[-- Type: text/plain, Size: 2668 bytes --]

diff --git a/lisp/dired.el b/lisp/dired.el
index cbd85fe..e5dc862 100644
--- a/lisp/dired.el
+++ b/lisp/dired.el
@@ -1478,12 +1478,36 @@ dired-save-positions
                (list w
 		     (dired-get-filename nil t)
                      (line-number-at-pos (window-point w)))))
-	   (get-buffer-window-list nil 0 t))))
+	   (get-buffer-window-list nil 0 t))
+   ;; For each window that showed the current buffer before, scan its
+   ;; list of previous buffers.  For each association thus found save
+   ;; a triple <point, name, line> where 'point' is that window's
+   ;; window-point marker stored in the window's list of previous
+   ;; buffers, 'name' is the filename at the position of 'point' and
+   ;; 'line' is the line number at the position of 'point'.
+   (let ((buffer (current-buffer))
+         prevs)
+     (walk-windows
+      (lambda (window)
+        (let ((prev (assq buffer (window-prev-buffers window))))
+          (when prev
+            (with-current-buffer buffer
+              (save-excursion
+                (goto-char (nth 2 prev))
+                (setq prevs
+                      (cons
+                       (list (nth 2 prev)
+                             (dired-get-filename nil t)
+                             (line-number-at-pos (point)))
+                       prevs)))))))
+      'nomini t)
+     prevs)))
 
 (defun dired-restore-positions (positions)
   "Restore POSITIONS saved with `dired-save-positions'."
   (let* ((buf-file-pos (nth 0 positions))
-	 (buffer (nth 0 buf-file-pos)))
+	 (buffer (nth 0 buf-file-pos))
+         (prevs (nth 2 positions)))
     (unless (and (nth 1 buf-file-pos)
 		 (dired-goto-file (nth 1 buf-file-pos)))
       (goto-char (point-min))
@@ -1497,7 +1521,21 @@ dired-restore-positions
 		       (dired-goto-file (nth 1 win-file-pos)))
             (goto-char (point-min))
 	    (forward-line (1- (nth 2 win-file-pos)))
-	    (dired-move-to-filename)))))))
+	    (dired-move-to-filename)))))
+    (when prevs
+      (with-current-buffer buffer
+        (save-excursion
+          (dolist (prev prevs)
+            (let ((point (nth 0 prev)))
+              ;; Sanity check of the point marker.
+              (when (and (markerp point)
+                         (eq (marker-buffer point) buffer))
+                (unless (and (nth 0 prev)
+                             (dired-goto-file (nth 1 prev)))
+                  (goto-char (point-min))
+	          (forward-line (1- (nth 2 prev))))
+	        (dired-move-to-filename)
+                (move-marker point (point) buffer)))))))))
 
 (defun dired-remember-marks (beg end)
   "Return alist of files and their marks, from BEG to END."

bug#33458: 27.0.50; dired loses position when reverted from outside place

[v88m]

On Tue, Dec 04 2018, martin rudalics wrote:

> The attached patch should fix this problem and the other ones with
> 'dired' that have been cited in this context.  Please try it.

It seems work for me. Thanks!

-- 
WBR, Yuri

bug#33458: 27.0.50; dired loses position when reverted from outside place

[martin rudalics]

 >> The attached patch should fix this problem and the other ones with
 >> 'dired' that have been cited in this context.  Please try it.
 >
 > It seems work for me. Thanks!

OK.  If there are no problems I'll install it in few days.  Maybe I
will handle any 'quit-restore' parameter present in a similar way.

martin

bug#33458: 27.0.50; dired loses position when reverted from outside place

[martin rudalics]

fixed 33458 27.1
quit

 > OK.  If there are no problems I'll install it in few days.

Now installed on master.  Bug closed.

 > Maybe I
 > will handle any 'quit-restore' parameter present in a similar way.

Maybe I'll do that when we know how to handle dired buffers in window
configurations and states.

Thanks, martin

bug#33458: 27.0.50; dired loses position when reverted from outside place

[Juri Linkov]

>> OK.  If there are no problems I'll install it in few days.
>
> Now installed on master.  Bug closed.
>
>> Maybe I
>> will handle any 'quit-restore' parameter present in a similar way.
>
> Maybe I'll do that when we know how to handle dired buffers in window
> configurations and states.

Unfortunately, now Dired fails to visit a directory:

Debugger entered--Lisp error: (wrong-type-argument stringp nil)
  file-name-absolute-p(nil)
  dired-goto-file(nil)
  dired-restore-positions(((#<buffer /tmp/> nil 3) nil ((#<marker at 1 in /tmp/> nil 3))))
  dired-revert(nil nil)
  revert-buffer()
  dired-internal-noselect("/tmp/" nil)
  dired-noselect("/tmp/" nil)
  dired("/tmp/")
  dired-jump(nil nil)
  funcall-interactively(dired-jump nil nil)
  call-interactively(dired-jump nil nil)
  command-execute(dired-jump)

Maybe this happens when a reverted directory window is restored
from a window configuration, so point-marker is at 1,
and (dired-get-filename nil t) returns nil in `dired-save-positions'.

bug#33458: 27.0.50; dired loses position when reverted from outside place

[martin rudalics]

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

 > Unfortunately, now Dired fails to visit a directory:
 >
 > Debugger entered--Lisp error: (wrong-type-argument stringp nil)
 >    file-name-absolute-p(nil)
 >    dired-goto-file(nil)
 >    dired-restore-positions(((#<buffer /tmp/> nil 3) nil ((#<marker at 1 in /tmp/> nil 3))))
 >    dired-revert(nil nil)
 >    revert-buffer()
 >    dired-internal-noselect("/tmp/" nil)
 >    dired-noselect("/tmp/" nil)
 >    dired("/tmp/")
 >    dired-jump(nil nil)
 >    funcall-interactively(dired-jump nil nil)
 >    call-interactively(dired-jump nil nil)
 >    command-execute(dired-jump)
 >
 > Maybe this happens when a reverted directory window is restored
 > from a window configuration, so point-marker is at 1,
 > and (dired-get-filename nil t) returns nil in `dired-save-positions'.

Looks like a silly typo.  Please try the attached patch.  If it does
not help, please provide me a simple scenario to reproduce the bug.

Thanks, martin

[-- Attachment #2: dired.el.diff --]
[-- Type: text/plain, Size: 564 bytes --]

diff --git a/lisp/dired.el b/lisp/dired.el
index e5dc862..72725dc 100644
--- a/lisp/dired.el
+++ b/lisp/dired.el
@@ -1530,7 +1530,7 @@ dired-restore-positions
               ;; Sanity check of the point marker.
               (when (and (markerp point)
                          (eq (marker-buffer point) buffer))
-                (unless (and (nth 0 prev)
+                (unless (and (nth 1 prev)
                              (dired-goto-file (nth 1 prev)))
                   (goto-char (point-min))
 	          (forward-line (1- (nth 2 prev))))

bug#33458: 27.0.50; dired loses position when reverted from outside place

[Juri Linkov]

> Please try the attached patch.  If it does not help, please provide me
> a simple scenario to reproduce the bug.

Thanks, it doesn't signal an error.

Do you have more ideas how to do the same for window configurations/states?

bug#33458: 27.0.50; dired loses position when reverted from outside place

[martin rudalics]

 >> Please try the attached patch.  If it does not help, please provide me
 >> a simple scenario to reproduce the bug.
 >
 > Thanks, it doesn't signal an error.

Pushed to master.

 > Do you have more ideas how to do the same for window configurations/states?

Not really.  Unless we are willing to maintain these on separate lists
that can be accessed by the window code.  WOW, which price would we be
willing to pay for that?

martin

bug#33458: 27.0.50; dired loses position when reverted from outside place

[Juri Linkov]

>> Do you have more ideas how to do the same for window configurations/states?
>
> Not really.  Unless we are willing to maintain these on separate lists
> that can be accessed by the window code.  WOW, which price would we be
> willing to pay for that?

I think we should run a hook when a buffer appears in the window,
either by e.g. 'C-x <left>' (previous-buffer) or by 'window-state-put',
then a buffer-local hook in Dired will move its point to the right file.

bug#33458: 27.0.50; dired loses position when reverted from outside place

[martin rudalics]

 > I think we should run a hook when a buffer appears in the window,
 > either by e.g. 'C-x <left>' (previous-buffer) or by 'window-state-put',
 > then a buffer-local hook in Dired will move its point to the right file.

The problem with 'dired' is that we have to make any amendments at the
time the buffer is reverted.  It's already too late when switching to
the buffer afterwards.

The only thing we can do at the time of switching to a buffer is to go
to the buffer's point (which should work when the buffer was displayed
only in one window before).

martin

bug#33458: 27.0.50; dired loses position when reverted from outside place

[Juri Linkov]

>> I think we should run a hook when a buffer appears in the window,
>> either by e.g. 'C-x <left>' (previous-buffer) or by 'window-state-put',
>> then a buffer-local hook in Dired will move its point to the right file.
>
> The problem with 'dired' is that we have to make any amendments at the
> time the buffer is reverted.  It's already too late when switching to
> the buffer afterwards.
>
> The only thing we can do at the time of switching to a buffer is to go
> to the buffer's point (which should work when the buffer was displayed
> only in one window before).

For example, saveplace.el uses dired-initial-position-hook to set
Dired buffer's point initially to a remembered dired-filename.

A switch-to-buffer hook could do the same to move point to a dired-filename
previously displayed in that window, by getting the filename from e.g.
a buffer-local mapping from windows to filenames.

bug#33458: 27.0.50; dired loses position when reverted from outside place

[martin rudalics]

 > For example, saveplace.el uses dired-initial-position-hook to set
 > Dired buffer's point initially to a remembered dired-filename.
 >
 > A switch-to-buffer hook could do the same to move point to a dired-filename
 > previously displayed in that window, by getting the filename from e.g.
 > a buffer-local mapping from windows to filenames.

The downside of such an approach is that any buffer-local reference to
a window will assure that the window object cannot be reclaimed by the
collector as long as the buffer is live, even when the window is not
stored in a configuration any more.  Not that I consider this a great
downside though.

martin

bug#33458: 27.0.50; dired loses position when reverted from outside place

[martin rudalics]

 > The downside of such an approach is that any buffer-local reference to
 > a window will assure that the window object cannot be reclaimed by the
 > collector as long as the buffer is live, even when the window is not
 > stored in a configuration any more.  Not that I consider this a great
 > downside though.

Reconsidering ...

Imagine a scenario where a user (1) displays a buffer in new window,
(2) switches in that window to another buffer and (3) deletes that
window for good.  When and how would the buffer-local reference
created in (2) be removed?

It can't be done in (3) since a window configuration stored somewhere
might still need it.  But if there is no such configuration, it should
be eventually removed since otherwise such references may pile up and
inhibit reclamation of all associated window objects.  Unfortunately,
there's no way to find out if such a configuration exists.  Obviously,
when the buffer gets eventually killed, its local variables get killed
too and the reference will vanish.  But in a long session many buffers
may be kept around for a long time and every time the above scenario
repeats itself a new reference will be added.

The only way to solve this dilemma I can see is using the collector.
For this, any reference created in a step like (2) would have to be
considered weak, that is, would not be be marked from the buffer-local
list.  When the collector sweeps buffers, it would have to perform an
extra check on that list: If the corresponding window was not marked
so far, it would be considered definitely dead, the reference get
removed from that list and the window be reclaimed in the subsequent
vector sweep.

As if things were not already complicated enough, any access to that
list (needed when reverting a buffer to update the point position for
every window showing the buffer in the past) would then have to be
atomic (not allocating) to avoid that the collector reclaims a window
under the feet of such an update operation.

Finally, this would not help wrt window states because these do not
care about window objects in the first place.  So I think that
implementing a scheme based on buffer-local window references is
hardly feasible.

Admittedly, GC should do something similar when sweeping window
configurations since these may still hold references to killed buffer
objects and thus prevent their reclamation.  But that would be fairly
simple since a buffer that has been killed will remain killed forever.
OTOH, a window that has been deleted may remain in a zombie-like state
until the last configuration referencing it has been removed.

martin

bug#33458: 27.0.50; dired loses position when reverted from outside place

[Juri Linkov]

> Imagine a scenario where a user (1) displays a buffer in new window,
> (2) switches in that window to another buffer and (3) deletes that
> window for good.  When and how would the buffer-local reference
> created in (2) be removed?

Another question: When should the buffer-local reference be added?

Every time when point is moved to a new file?  Too frequent calls especially
in cases of e.g. pressing and holding the spacebar to move thru the file list.

Or when current-window-configuration is saved to a variable/register
or window-state-get is called?  I don't know what hook is possible
to use at that moment besides advices.

bug#33458: 27.0.50; dired loses position when reverted from outside place

[martin rudalics]

 >> Imagine a scenario where a user (1) displays a buffer in new window,
 >> (2) switches in that window to another buffer and (3) deletes that
 >> window for good.  When and how would the buffer-local reference
 >> created in (2) be removed?
 >
 > Another question: When should the buffer-local reference be added?
 >
 > Every time when point is moved to a new file?  Too frequent calls especially
 > in cases of e.g. pressing and holding the spacebar to move thru the file list.
 >
 > Or when current-window-configuration is saved to a variable/register
 > or window-state-get is called?  I don't know what hook is possible
 > to use at that moment besides advices.

I'm not sure whether my scenario above was entirely clear.  The
"buffer-local reference" I was talking about would be a buffer-local
list whose cars are all the windows (including dead ones) that showed
the buffer before.  When reverting a buffer, we would traverse that
list, and for every window in that list (including dead windows) look
up the buffer reference in that window's previous buffers, calculate
the new window point position from the old position and store back the
new position as marker in situ there.

For dired, for example, one would go to the old position, look at what
file is displayed there, remember the name of that file, revert the
buffer and in the reverted buffer search for the file name and store
an appropriate position as new window point for that window (including
windows still dead).  For other buffers we would use the default
'revert-buffer' function and have it do whatever it does now for live
windows showing the buffer.

In either case, reverting proper would be oblivious to whether any
window point it transforms is that of a live or dead window.  Still
this is nothing for the faint-hearted because the only surgery we
allowed on dead windows so far was to resurrect them in a restored
window configuration.

So the answer to your question "When should the buffer-local reference
be added?" is the earlier alluded to "in (2) when we unshow that
buffer in a window".  And the problem we have to solve is when to
remove such a reference because the referenced window is really dead
and no more referenced by any saved window configuration.

Note: We alternatively could store the position information from
windows' lists of previous buffers as buffer-local lists.  This would
make reverting slightly simpler and switching to a window's previous
or next buffer a bit more complicated.  But we would still have to
find out whether any window referenced that way from a buffer is still
referenced from a saved window configuration.

martin

bug#33458: 27.0.50; dired loses position when reverted from outside place

[Juri Linkov]

>>> Imagine a scenario where a user (1) displays a buffer in new window,
>>> (2) switches in that window to another buffer and (3) deletes that
>>> window for good.  When and how would the buffer-local reference
>>> created in (2) be removed?
>>
>> Another question: When should the buffer-local reference be added?
>>
>> Every time when point is moved to a new file?  Too frequent calls especially
>> in cases of e.g. pressing and holding the spacebar to move thru the file list.
>>
>> Or when current-window-configuration is saved to a variable/register
>> or window-state-get is called?  I don't know what hook is possible
>> to use at that moment besides advices.
>
> I'm not sure whether my scenario above was entirely clear.  The
> "buffer-local reference" I was talking about would be a buffer-local
> list whose cars are all the windows (including dead ones) that showed
> the buffer before.  When reverting a buffer, we would traverse that
> list, and for every window in that list (including dead windows) look
> up the buffer reference in that window's previous buffers, calculate
> the new window point position from the old position and store back the
> new position as marker in situ there.

Is it really possible to get a window from the window-configuration
that is currently not displayed and change its window-point, e.g.
to get window reference from the buffer-local list, select with
with-selected-window and call set-window-point?  I never tried such thing.

> So the answer to your question "When should the buffer-local reference
> be added?" is the earlier alluded to "in (2) when we unshow that
> buffer in a window".  And the problem we have to solve is when to
> remove such a reference because the referenced window is really dead
> and no more referenced by any saved window configuration.

It's clear from you explanation what harm is from zombie windows.
But it's interesting to know is it possible to catch the moment
when we unshow that buffer in a window?

bug#33458: 27.0.50; dired loses position when reverted from outside place

[martin rudalics]

 > Is it really possible to get a window from the window-configuration
 > that is currently not displayed and change its window-point, e.g.
 > to get window reference from the buffer-local list, select with
 > with-selected-window and call set-window-point?  I never tried such thing.

The window object is fully available, just its buffer (aka contents)
slot is nil.  We cannot select it and setting any geometry related
things might cause problems.  But I see no problems changing its point
or its buffer (the latter being temporarily in the combination_limit
slot).  So the problem is not how to get the window from the
configuration but how to get the configuration in the first place.

 > It's clear from you explanation what harm is from zombie windows.
 > But it's interesting to know is it possible to catch the moment
 > when we unshow that buffer in a window?

In a zombie window?  We simply don't unshow a buffer in it because
there is no way to see a zombie window unless it gets restored via
'set-window-configuration'.  This means that 'kill-buffer' will leave
the buffer in any zombie window until all references to configurations
referencing it are removed and the window gets no more marked.
Neither replace_buffer_in_windows nor replace_buffer_in_windows_safely
can see zombie windows.

martin

bug#33458: 27.0.50; dired loses position when reverted from outside place

[Juri Linkov]

>> Is it really possible to get a window from the window-configuration
>> that is currently not displayed and change its window-point, e.g.
>> to get window reference from the buffer-local list, select with
>> with-selected-window and call set-window-point?  I never tried such thing.
>
> The window object is fully available, just its buffer (aka contents)
> slot is nil.  We cannot select it and setting any geometry related
> things might cause problems.  But I see no problems changing its point
> or its buffer (the latter being temporarily in the combination_limit
> slot).  So the problem is not how to get the window from the
> configuration but how to get the configuration in the first place.

I have a related question: before killing a buffer I want to check
if that buffer is still used in a saved window-configuration/state,
i.e. it could be restored later and displayed after restoring from the
window configuration/state.  Do you know is such thing possible at all?

bug#33458: 27.0.50; dired loses position when reverted from outside place

[martin rudalics]

 > I have a related question: before killing a buffer I want to check
 > if that buffer is still used in a saved window-configuration/state,
 > i.e. it could be restored later and displayed after restoring from the
 > window configuration/state.  Do you know is such thing possible at all?

It should be possible for a specific configuration or state (just that
the latter only use buffer names).  But in general, we don't have the
handles to get hold of all saved window-configurations/states.

martin

bug#33458: 27.0.50; dired loses position when reverted from outside place

[Juri Linkov]

>> I have a related question: before killing a buffer I want to check
>> if that buffer is still used in a saved window-configuration/state,
>> i.e. it could be restored later and displayed after restoring from the
>> window configuration/state.  Do you know is such thing possible at all?
>
> It should be possible for a specific configuration or state (just that
> the latter only use buffer names).  But in general, we don't have the
> handles to get hold of all saved window-configurations/states.

But if we have a list of saved window-configurations/states, is this
possible without restoring each saved configuration/state?

bug#33458: 27.0.50; dired loses position when reverted from outside place

[martin rudalics]

 >> It should be possible for a specific configuration or state (just that
 >> the latter only use buffer names).  But in general, we don't have the
 >> handles to get hold of all saved window-configurations/states.
 >
 > But if we have a list of saved window-configurations/states, is this
 > possible without restoring each saved configuration/state?

No.  But we can provide a function like 'buffers-in-dead-windows' that
takes a configuration (or a list of configurations) as argument and
returns a list of dead windows that whould show that buffer if they
were restored.

martin

bug#33458: 27.0.50; dired loses position when reverted from outside place

[martin rudalics]

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

 > No.  But we can provide a function like 'buffers-in-dead-windows' that
 > takes a configuration (or a list of configurations) as argument and
 > returns a list of dead windows that whould show that buffer if they
 > were restored.

I called it 'buffer-windows-from-configuration'.  Please have a look.

martin

[-- Attachment #2: buffer-windows-from-configuration.diff --]
[-- Type: text/plain, Size: 1880 bytes --]

diff --git a/src/window.c b/src/window.c
index 8297022..f6804d7 100644
--- a/src/window.c
+++ b/src/window.c
@@ -7076,6 +7076,40 @@ struct saved_window
 }
 
 
+DEFUN ("buffer-windows-from-configuration", Fbuffer_windows_from_configuration,
+       Sbuffer_windows_from_configuration, 2, 2, 0,
+       doc: /* Return list of windows showing BUFFER in CONFIGURATION.
+The return value is a list of triples <window, start, point> for each
+window showing BUFFER in CONFIGURATION.  Window is the window showing
+buffer, start its start position and point its window point.  */)
+     (Lisp_Object buffer, Lisp_Object configuration)
+{
+  register struct save_window_data *data;
+  struct Lisp_Vector *saved_windows;
+  Lisp_Object value = Qnil;
+  struct saved_window *p;
+  ptrdiff_t k;
+
+  CHECK_BUFFER (buffer);
+
+  if (!BUFFER_LIVE_P (XBUFFER (buffer)))
+    error ("Not a live buffer");
+
+  CHECK_WINDOW_CONFIGURATION (configuration);
+
+  data = (struct save_window_data *) XVECTOR (configuration);
+  saved_windows = XVECTOR (data->saved_windows);
+
+  for (k = 0; k < saved_windows->header.size; k++)
+    {
+      p = SAVED_WINDOW_N (saved_windows, k);
+      if (BUFFERP (p->buffer) && EQ (p->buffer, buffer))
+	value = Fcons (list3 (p->window, p->start, p->pointm), value);
+    }
+
+  return value;
+}
+
 /* If WINDOW is an internal window, recursively delete all child windows
    reachable via the next and contents slots of WINDOW.  Otherwise setup
    WINDOW to not show any buffer.  */
@@ -8270,6 +8304,7 @@ this value for parameters without read syntax (like windows or frames).
   defsubr (&Swindow_configuration_p);
   defsubr (&Swindow_configuration_frame);
   defsubr (&Sset_window_configuration);
+  defsubr (&Sbuffer_windows_from_configuration);
   defsubr (&Scurrent_window_configuration);
   defsubr (&Sset_window_margins);
   defsubr (&Swindow_margins);

bug#33458: 27.0.50; dired loses position when reverted from outside place

[Juri Linkov]

>> No.  But we can provide a function like 'buffers-in-dead-windows' that
>> takes a configuration (or a list of configurations) as argument and
>> returns a list of dead windows that whould show that buffer if they
>> were restored.
>
> I called it 'buffer-windows-from-configuration'.  Please have a look.

Thanks, but I expected it to be more configurable, i.e. to also look 
at prev/next-buffers in a saved configuration when needed, etc.

This could be achieved with a complete export of the saved
configuration to a Lisp structure.

If you think this is too big task, then a simpler solution is
just to create such metadata structure before the configuration
is saved, and save it along with the configuration.  I already do
this by saving a writable window state parallelly with saving
a window configuration.  What I mean that in a package that
saves window configurations, maintain such a list:

((window-configuration-1 writable-window-state-1 metadata-1)
 (window-configuration-2 writable-window-state-2 metadata-2)
 ...)

where metadata could contain a list of buffers from windows
and from prev/next buffers, and everything else required by
application logic.

bug#33458: 27.0.50; dired loses position when reverted from outside place

[martin rudalics]

 > Thanks, but I expected it to be more configurable, i.e. to also look
 > at prev/next-buffers in a saved configuration when needed, etc.

We can easily do that.  But note that a window's previous and next
buffers are stored in the window itself (where, if the window is live,
they can change at any time) and not in the window copy stored in the
configuration.  So there are two solutions to your request: Have
'buffer-windows-from-configuration' return pointers to those two lists
or have say 'window-prev-buffers' accept dead windows as arguments?

 > This could be achieved with a complete export of the saved
 > configuration to a Lisp structure.

It's a bit tedious to code but can be certainly done.  But I suppose
that what might then interest you just as well is to transform window
states into window configurations ;-)

Also, the function as I wrote it could be easily complemented by a
function say 'set-window-buffer-in-configuration' where for an
argument WINDOW you could perform some surgery in the configuration
like setting its buffer (when it gets killed) or its point or start
position (when its buffer gets reverted).

 > If you think this is too big task, then a simpler solution is
 > just to create such metadata structure before the configuration
 > is saved, and save it along with the configuration.  I already do
 > this by saving a writable window state parallelly with saving
 > a window configuration.  What I mean that in a package that
 > saves window configurations, maintain such a list:
 >
 > ((window-configuration-1 writable-window-state-1 metadata-1)
 >   (window-configuration-2 writable-window-state-2 metadata-2)
 >   ...)
 >
 > where metadata could contain a list of buffers from windows
 > and from prev/next buffers, and everything else required by
 > application logic.

The problem with this is that states you save this way get outdated
wrt their corresponding configurations: In particular, after
(un-)showing a few more buffers in the corresponding frame, the
configuration will be aware of these changes (because they are stored
in the lists of previous and next buffers of the live windows) while
your saved states won't.

Finally, we probably want to do some of the things on your wish list
automatically for all configurations referenced by some particular
list like say 'registered-window-configurations'.  So maybe we should
think about such a structure and how to maintain it now.

martin

bug#33458: 27.0.50; dired loses position when reverted from outside place

[Juri Linkov]

>> Thanks, but I expected it to be more configurable, i.e. to also look
>> at prev/next-buffers in a saved configuration when needed, etc.
>
> We can easily do that.  But note that a window's previous and next
> buffers are stored in the window itself (where, if the window is live,
> they can change at any time) and not in the window copy stored in the
> configuration.

Oh, I see now why this case fails:

(let ((_ (view-emacs-todo))
      (w-c (current-window-configuration)))
  (view-emacs-news)
  (set-window-configuration w-c)
  (previous-buffer))

I expected it not to change prev/next buffers of the window
saved in the window configuration, so the expectation for the
last call to 'previous-buffer' was to return from the TODO buffer
to the original buffer *scratch*.  But since the NEWS buffer
meddled with the same window, this is not the case.

This is why any code that saves window configurations has to care
about creating a new window after the current-window-configuration
call (thus removing the window saved in the window configuration),
like I fixed now in https://gitlab.com/link0ff/emacs-wincows/commit/226cf229

>> This could be achieved with a complete export of the saved
>> configuration to a Lisp structure.
>
> It's a bit tedious to code but can be certainly done.  But I suppose
> that what might then interest you just as well is to transform window
> states into window configurations ;-)

Indeed, this would simplify many things.

bug#33458: 27.0.50; dired loses position when reverted from outside place

[martin rudalics]

 > Oh, I see now why this case fails:
 >
 > (let ((_ (view-emacs-todo))
 >        (w-c (current-window-configuration)))
 >    (view-emacs-news)
 >    (set-window-configuration w-c)
 >    (previous-buffer))
 >
 > I expected it not to change prev/next buffers of the window
 > saved in the window configuration, so the expectation for the
 > last call to 'previous-buffer' was to return from the TODO buffer
 > to the original buffer *scratch*.  But since the NEWS buffer
 > meddled with the same window, this is not the case.

A window configuration is a state, a snapshot at some given instant of
time.  A window's previous buffers are a history, a sequence of statse
over a certain period of time.  What you want to do is freeze history.
We could do that by making a copy of all windows' previous and next
buffers, storing those lists in separate variables and restoring them
from there.

But note that any such change might mess up the partial ordering of
events on your system.  The relative positions of buffers in a frame's
buffer list would be incongruent with their positions in the buffer
lists of that frame's windows.  A new buffer you switched to while the
present configuration was saved and not yet restored would appear in
its frame's buffer list but not in that of any of the frame's windows.
This would imply that all windows of the frame were created after the
buffer was shown.

So I think you should first reconsider any such behavior.  Eliding
things from history "as if they never happened" is often a bad thing
(although I wish Emacs' 'undo' could do that occasionally).  And if we
wanted to implement it we would have to make it customizable.  Hence
any package would have to cater for both ways of seeing the history of
buffers in a window.

 > This is why any code that saves window configurations has to care
 > about creating a new window after the current-window-configuration
 > call (thus removing the window saved in the window configuration),
 > like I fixed now in https://gitlab.com/link0ff/emacs-wincows/commit/226cf229

Restoring the window configuration would remove the window.  What else
would you want to do with it?

BTW, window parameters have to be made persistent in order to make
them replace current ones when restoring a window configuration.

martin

bug#33458: 27.0.50; dired loses position when reverted from outside place

[Juri Linkov]

> Restoring the window configuration would remove the window.  What else
> would you want to do with it?

A new window could be stored in another window configuration before
restoring a previous window configuration.  The main point is that
packages have to be careful to not share windows between different
window configurations.

bug#33458: 27.0.50; dired loses position when reverted from outside place

[martin rudalics]

 > A new window could be stored in another window configuration before
 > restoring a previous window configuration.  The main point is that
 > packages have to be careful to not share windows between different
 > window configurations.

Hmm...  Could you elaborate?

martin

bug#33458: 27.0.50; dired loses position when reverted from outside place

[Lars Ingebrigtsen]

martin rudalics <rudalics@gmx.at> writes:

>> A new window could be stored in another window configuration before
>> restoring a previous window configuration.  The main point is that
>> packages have to be careful to not share windows between different
>> window configurations.
>
> Hmm...  Could you elaborate?

I've just skimmed this thread, but it seems like the bug that was
reported was fixed here, but then the discussion went on to other
slightly related issues.  Is there more to be done in this bug report,
or should it be closed?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#33458: 27.0.50; dired loses position when reverted from outside place

[Juri Linkov]

> I've just skimmed this thread, but it seems like the bug that was
> reported was fixed here, but then the discussion went on to other
> slightly related issues.  Is there more to be done in this bug report,
> or should it be closed?

If the original reported bug was fixed, then please close this report.

bug#33458: 27.0.50; dired loses position when reverted from outside place

[Lars Ingebrigtsen]

Juri Linkov <juri@linkov.net> writes:

>> I've just skimmed this thread, but it seems like the bug that was
>> reported was fixed here, but then the discussion went on to other
>> slightly related issues.  Is there more to be done in this bug report,
>> or should it be closed?
>
> If the original reported bug was fixed, then please close this report.

It looked like that to me, but it was a really long thread, and I may
have missed something.

Anyway, I've now closed the bug report; if there's anything further to
be done here, please reopen.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#33458: 27.0.50; dired loses position when reverted from outside place

[v88m]

Playing with patched dired.el I can see error message in some cases
while buffer creating, deleting and selecting:

"wrong-type-argument stringp nil"

Quickfix:

--- /usr/share/emacs/27.0.50/lisp/dired.el      2018-12-12 10:46:49.000000000 +0300
+++ /tmp/dired.el       2018-12-13 09:52:24.102587567 +0300
@@ -1531,7 +1531,8 @@
               (when (and (markerp point)
                          (eq (marker-buffer point) buffer))
                 (unless (and (nth 1 prev)
-                             (dired-goto-file (nth 1 prev)))
+                             (ignore-errors
+                               (dired-goto-file (nth 1 prev))))
                   (goto-char (point-min))
                  (forward-line (1- (nth 2 prev))))
                (dired-move-to-filename)

May be we need same treatment for other `dired-goto-file' lines or make
more general check for `prev's structure?

On Tue, Dec 04 2018, martin rudalics wrote:

> diff --git a/lisp/dired.el b/lisp/dired.el
> index cbd85fe..e5dc862 100644
> --- a/lisp/dired.el
> +++ b/lisp/dired.el
> @@ -1478,12 +1478,36 @@ dired-save-positions
>                 (list w
>  		     (dired-get-filename nil t)
>                       (line-number-at-pos (window-point w)))))
> -	   (get-buffer-window-list nil 0 t))))
> +	   (get-buffer-window-list nil 0 t))
> +   ;; For each window that showed the current buffer before, scan its
> +   ;; list of previous buffers.  For each association thus found save
> +   ;; a triple <point, name, line> where 'point' is that window's
> +   ;; window-point marker stored in the window's list of previous
> +   ;; buffers, 'name' is the filename at the position of 'point' and
> +   ;; 'line' is the line number at the position of 'point'.
> +   (let ((buffer (current-buffer))
> +         prevs)
> +     (walk-windows
> +      (lambda (window)
> +        (let ((prev (assq buffer (window-prev-buffers window))))
> +          (when prev
> +            (with-current-buffer buffer
> +              (save-excursion
> +                (goto-char (nth 2 prev))
> +                (setq prevs
> +                      (cons
> +                       (list (nth 2 prev)
> +                             (dired-get-filename nil t)
> +                             (line-number-at-pos (point)))
> +                       prevs)))))))
> +      'nomini t)
> +     prevs)))
>  
>  (defun dired-restore-positions (positions)
>    "Restore POSITIONS saved with `dired-save-positions'."
>    (let* ((buf-file-pos (nth 0 positions))
> -	 (buffer (nth 0 buf-file-pos)))
> +	 (buffer (nth 0 buf-file-pos))
> +         (prevs (nth 2 positions)))
>      (unless (and (nth 1 buf-file-pos)
>  		 (dired-goto-file (nth 1 buf-file-pos)))
>        (goto-char (point-min))
> @@ -1497,7 +1521,21 @@ dired-restore-positions
>  		       (dired-goto-file (nth 1 win-file-pos)))
>              (goto-char (point-min))
>  	    (forward-line (1- (nth 2 win-file-pos)))
> -	    (dired-move-to-filename)))))))
> +	    (dired-move-to-filename)))))
> +    (when prevs
> +      (with-current-buffer buffer
> +        (save-excursion
> +          (dolist (prev prevs)
> +            (let ((point (nth 0 prev)))
> +              ;; Sanity check of the point marker.
> +              (when (and (markerp point)
> +                         (eq (marker-buffer point) buffer))
> +                (unless (and (nth 0 prev)
> +                             (dired-goto-file (nth 1 prev)))
> +                  (goto-char (point-min))
> +	          (forward-line (1- (nth 2 prev))))
> +	        (dired-move-to-filename)
> +                (move-marker point (point) buffer)))))))))
>  
>  (defun dired-remember-marks (beg end)
>    "Return alist of files and their marks, from BEG to END."

-- 
WBR, Yuri

bug#33458: 27.0.50; dired loses position when reverted from outside place

[martin rudalics]

 > Playing with patched dired.el I can see error message in some cases
 > while buffer creating, deleting and selecting:
 >
 > "wrong-type-argument stringp nil"

Are you sure you've seen this happening _after_ my last fix two days
ago?  Because if 'dired-goto-file' _now_ chokes on (nth 1 prev) this
should be due to any other value but nil.

 > +                             (ignore-errors
 > +                               (dired-goto-file (nth 1 prev))))

If you still see an error now we can do that.  It should never harm.
But for the moment I'm mostly curious whether you can still see the
"wrong-type-argument stringp nil" message.

 > May be we need same treatment for other `dired-goto-file' lines or make
 > more general check for `prev's structure?

All these are heuristics based on the idea that in most cases a file
is still present after reverting its directory's list of files.  Yet,
'dired-goto-file' should not choke on a file name previously produced
by 'dired-get-filename'.

Thanks, martin

bug#33458: 27.0.50; dired loses position when reverted from outside place

[v88m]

On Thu, Dec 13 2018, martin rudalics wrote:

> Are you sure you've seen this happening _after_ my last fix two days
> ago?

My fault, I worked with original patch.

> Because if 'dired-goto-file' _now_ chokes on (nth 1 prev) this
> should be due to any other value but nil.

Sure.

>  > +                             (ignore-errors
>  > +                               (dired-goto-file (nth 1 prev))))

So not needed anymore.

> If you still see an error now we can do that.  It should never harm.
> But for the moment I'm mostly curious whether you can still see the
> "wrong-type-argument stringp nil" message.

It seems OK now, with your last fix.

Sorry for false alarm!

-- 
WBR, Yuri

bug#33458: 27.0.50; dired loses position when reverted from outside place

[martin rudalics]

 > It seems OK now, with your last fix.

Thanks for confirming.  If you see any further problems, please inform
us immediately.

martin

bug#33458: 27.0.50; dired loses position when reverted from outside place

[v88m]

Something new:

Error in post-command-hook (dired--revert): (file-missing "Setting current directory" "No such file or directory" "~/MY-DIR/")

(Note: ~/MY-DIR/ was deleted, couple of another actions (dirs creation,
deletion) take place before this error occurred).

I use `post-command-hook' for my `dired--revert', it just
conditional wrapper for `dired-revert':

(defun dired--revert ()
  (when (and (eq major-mode 'dired-mode)
             (memq this-command '(previous-buffer
                                  next-buffer
                                  kill-buffer
                                  quit-window
                                  bury-buffer
                                  other-buffer
                                  switch-to-buffer
                                  dired-up-directory
                                  switch-to-buffer-other-window
                                  switch-to-buffer-other-frame
                                  helm-maybe-exit-minibuffer)))
    (dired-revert)))

Currently `dired--revert' is autoremoved from
`post-command-hook', so it (and `dired-revert' per se) is the culprit.

-- 
WBR, Yuri

bug#33458: 27.0.50; dired loses position when reverted from outside place

[martin rudalics]

 > Something new:
 >
 > Error in post-command-hook (dired--revert): (file-missing "Setting current directory" "No such file or directory" "~/MY-DIR/")
 >
 > (Note: ~/MY-DIR/ was deleted, couple of another actions (dirs creation,
 > deletion) take place before this error occurred).
 >
 > I use `post-command-hook' for my `dired--revert', it just
 > conditional wrapper for `dired-revert':
 >
 > (defun dired--revert ()
 >    (when (and (eq major-mode 'dired-mode)
 >               (memq this-command '(previous-buffer
 >                                    next-buffer
 >                                    kill-buffer
 >                                    quit-window
 >                                    bury-buffer
 >                                    other-buffer
 >                                    switch-to-buffer
 >                                    dired-up-directory
 >                                    switch-to-buffer-other-window
 >                                    switch-to-buffer-other-frame
 >                                    helm-maybe-exit-minibuffer)))
 >      (dired-revert)))
 >
 > Currently `dired--revert' is autoremoved from
 > `post-command-hook', so it (and `dired-revert' per se) is the culprit.

What's new about this?  When I'm in a dired buffer, delete the
directory it shows and then do M-: (dired-revert) I get a similar
error here.

martin

bug#33458: 27.0.50; dired loses position when reverted from outside place

[v88m]

On Fri, Dec 14 2018, martin rudalics wrote:

> What's new about this?  When I'm in a dired buffer, delete the
> directory it shows and then do M-: (dired-revert) I get a similar
> error here.

You're right, I miss something. Will add some checks to my prog. Thank
you!

-- 
WBR, Yuri