From: martin rudalics <rudalics@gmx.at>
To: Juri Linkov <juri@linkov.net>
Cc: Stephen Berman <stephen.berman@gmx.net>,
33458@debbugs.gnu.org, v88m@posteo.net
Subject: bug#33458: 27.0.50; dired loses position when reverted from outside place
Date: Wed, 28 Nov 2018 09:35:00 +0100 [thread overview]
Message-ID: <5BFE5334.3080502@gmx.at> (raw)
In-Reply-To: <87zhtudq0i.fsf@mail.linkov.net>
> 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
next prev parent reply other threads:[~2018-11-28 8:35 UTC|newest]
Thread overview: 65+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-11-21 20:40 bug#33458: 27.0.50; dired loses position when reverted from outside place v88m
2018-11-21 22:33 ` Stephen Berman
2018-11-22 9:07 ` v88m
2018-11-22 9:38 ` Stephen Berman
2018-11-23 7:41 ` martin rudalics
2018-11-23 15:40 ` v88m
2018-11-23 19:03 ` martin rudalics
2018-11-23 19:55 ` v88m
2018-11-25 20:45 ` Juri Linkov
2018-11-26 9:32 ` martin rudalics
2018-11-27 0:09 ` Juri Linkov
2018-11-27 8:08 ` martin rudalics
2018-11-28 0:06 ` Juri Linkov
2018-11-28 8:35 ` martin rudalics [this message]
2018-11-28 23:45 ` Juri Linkov
2018-11-29 7:41 ` Eli Zaretskii
2018-11-29 22:33 ` Juri Linkov
2018-11-30 7:05 ` v88m
2018-12-01 22:33 ` Juri Linkov
2018-11-30 8:21 ` martin rudalics
2018-11-29 8:31 ` martin rudalics
2018-11-29 22:46 ` Juri Linkov
2018-11-30 7:10 ` v88m
2018-11-30 8:22 ` martin rudalics
2018-11-30 8:21 ` martin rudalics
2018-12-01 22:30 ` Juri Linkov
2018-12-02 8:33 ` martin rudalics
2018-12-04 8:33 ` martin rudalics
2018-12-04 14:41 ` v88m
2018-12-05 9:17 ` martin rudalics
2018-12-08 9:41 ` martin rudalics
2018-12-10 0:10 ` Juri Linkov
2018-12-10 7:58 ` martin rudalics
2018-12-10 23:59 ` Juri Linkov
2018-12-11 8:34 ` martin rudalics
2018-12-12 0:40 ` Juri Linkov
2018-12-12 8:32 ` martin rudalics
2018-12-12 23:29 ` Juri Linkov
2018-12-13 9:02 ` martin rudalics
2018-12-14 9:33 ` martin rudalics
2018-12-16 23:49 ` Juri Linkov
2018-12-17 8:06 ` martin rudalics
2018-12-18 0:25 ` Juri Linkov
2018-12-18 8:28 ` martin rudalics
2018-12-21 0:59 ` Juri Linkov
2018-12-21 9:15 ` martin rudalics
2018-12-22 23:36 ` Juri Linkov
2018-12-23 9:40 ` martin rudalics
2018-12-23 19:06 ` martin rudalics
2018-12-23 23:47 ` Juri Linkov
2018-12-24 8:15 ` martin rudalics
2018-12-25 21:25 ` Juri Linkov
2018-12-26 9:42 ` martin rudalics
2018-12-27 0:29 ` Juri Linkov
2018-12-27 9:37 ` martin rudalics
2020-08-22 14:49 ` Lars Ingebrigtsen
2020-08-23 18:42 ` Juri Linkov
2020-08-24 13:15 ` Lars Ingebrigtsen
2018-12-13 7:39 ` v88m
2018-12-13 9:02 ` martin rudalics
2018-12-13 9:35 ` v88m
2018-12-13 10:10 ` martin rudalics
2018-12-14 8:25 ` v88m
2018-12-14 9:34 ` martin rudalics
2018-12-14 10:01 ` v88m
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5BFE5334.3080502@gmx.at \
--to=rudalics@gmx.at \
--cc=33458@debbugs.gnu.org \
--cc=juri@linkov.net \
--cc=stephen.berman@gmx.net \
--cc=v88m@posteo.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.