From: martin rudalics <rudalics@gmx.at>
To: Juri Linkov <juri@jurta.org>
Cc: 33532@debbugs.gnu.org, Markus Triska <triska@metalevel.at>
Subject: bug#33532: 26.1; set-window-configuration does not restore display start
Date: Tue, 04 Dec 2018 09:33:14 +0100 [thread overview]
Message-ID: <5C063BCA.3090301@gmx.at> (raw)
In-Reply-To: <87a7lmqkry.fsf@mail.linkov.net>
[-- Attachment #1: Type: text/plain, Size: 1785 bytes --]
> What do you think about implementing the same behavior for
> markers like it's implemented by 'comint-move-point-for-output'?
> I.e. the same way as 'comint-move-point-for-output' moves point
> to the end of the output, after erasing the buffer markers could
> move their positions towards their previous valid position until
> there is enough reverted text that they reach the old position.
>
> This is straightforward to implement. I see print.c has a question
> in the comments:
>
> case PVEC_MARKER:
> print_c_string ("#<marker ", printcharfun);
> /* Do you think this is necessary? */
> if (XMARKER (obj)->insertion_type != 0)
> print_c_string ("(moves after insertion) ", printcharfun);
>
> I think this is necessary. And this 'insertion_type' could also
> move after insertion until it reaches its old position in the
> reverted buffer.
'auto-revert-tail-mode' already has
(when buffer-file-name
(setq eob (eobp))
(walk-windows
(lambda (window)
(and (eq (window-buffer window) buffer)
(= (window-point window) (point-max))
(push window eoblist)))
'no-mini t))
plus
(when buffer-file-name
(when eob (goto-char (point-max)))
(dolist (window eoblist)
(set-window-point window (point-max)))))
without changing the markers' point insertion types. We can easily
extend that to handle a window's previous buffers' points. But
changing the insertion type of markers is far too delicate with all
the implications Eli cited. We should avoid that wherever possible.
BTW, the last patch I sent was needlessly complicated - a window's
next buffers don't have any markers. I attach a better one.
martin
[-- Attachment #2: fileio.diff --]
[-- Type: text/plain, Size: 3814 bytes --]
diff --git a/src/fileio.c b/src/fileio.c
index d979571..b3fdc60 100644
--- a/src/fileio.c
+++ b/src/fileio.c
@@ -3513,23 +3513,59 @@ CONTEXT should be a list (USER ROLE TYPE RANGE), where the list
static Lisp_Object
get_window_points_and_markers (void)
{
+ Lisp_Object buffer = Fcurrent_buffer ();
Lisp_Object pt_marker = Fpoint_marker ();
- Lisp_Object windows
- = call3 (Qget_buffer_window_list, Fcurrent_buffer (), Qnil, Qt);
- Lisp_Object window_markers = windows;
- /* Window markers (and point) are handled specially: rather than move to
- just before or just after the modified text, we try to keep the
- markers at the same distance (bug#19161).
- In general, this is wrong, but for window-markers, this should be harmless
- and is convenient for the end user when most of the file is unmodified,
- except for a few minor details near the beginning and near the end. */
+ Lisp_Object windows = window_list ();
+ Lisp_Object window;
+ Lisp_Object window_markers = Qnil;
+ /* Window markers (and point) are handled specially: rather than
+ move to just before or just after the modified text, we try to
+ keep the markers at the same distance (bug#19161).
+
+ In general, this is wrong, but for window markers, this should be
+ harmless and is convenient for the end user when most of the file
+ is unmodified, except for a few minor details near the beginning
+ and near the end.
+
+ Window point markers now include the window point markers from
+ the lists of each live window's previous buffers. */
for (; CONSP (windows); windows = XCDR (windows))
- if (WINDOWP (XCAR (windows)))
+ if (WINDOW_LIVE_P (window = XCAR (windows)))
{
- Lisp_Object window_marker = XWINDOW (XCAR (windows))->pointm;
- XSETCAR (windows,
- Fcons (window_marker, Fmarker_position (window_marker)));
+ struct window *w = XWINDOW (window);
+ Lisp_Object prev_buffers = w->prev_buffers;
+
+ /* Look at window's buffer first. */
+ if (EQ (WINDOW_BUFFER (w), buffer))
+ {
+ Lisp_Object window_marker = XWINDOW (XCAR (windows))->pointm;
+
+ window_markers =
+ Fcons (Fcons (window_marker, Fmarker_position (window_marker)),
+ window_markers);
+
+ /* Skip the list of previous buffers. */
+ continue;
+ }
+
+ /* Scan window's previous buffers. */
+ for (; CONSP (prev_buffers); prev_buffers = XCDR (prev_buffers))
+ if (CONSP (XCAR (prev_buffers)))
+ {
+ Lisp_Object triple = XCAR (prev_buffers);
+
+ if (EQ (XCAR (triple), buffer))
+ {
+ Lisp_Object prev_marker = Fnth (make_fixnum (2), triple);
+
+ window_markers =
+ Fcons (Fcons (prev_marker, Fmarker_position (prev_marker)),
+ window_markers);
+ break;
+ }
+ }
}
+
return Fcons (Fcons (pt_marker, Fpoint ()), window_markers);
}
@@ -3543,6 +3579,7 @@ CONTEXT should be a list (USER ROLE TYPE RANGE), where the list
Lisp_Object car = XCAR (window_markers);
Lisp_Object marker = XCAR (car);
Lisp_Object oldpos = XCDR (car);
+
if (MARKERP (marker) && FIXNUMP (oldpos)
&& XFIXNUM (oldpos) > same_at_start
&& XFIXNUM (oldpos) < same_at_end)
@@ -3552,6 +3589,7 @@ CONTEXT should be a list (USER ROLE TYPE RANGE), where the list
double growth = newsize / (double)oldsize;
ptrdiff_t newpos
= same_at_start + growth * (XFIXNUM (oldpos) - same_at_start);
+
Fset_marker (marker, make_fixnum (newpos), Qnil);
}
}
@@ -6285,7 +6323,6 @@ current when building the annotations (i.e., at least once), with that
DEFSYM (Qdelete_directory, "delete-directory");
DEFSYM (Qsubstitute_env_in_file_name, "substitute-env-in-file-name");
- DEFSYM (Qget_buffer_window_list, "get-buffer-window-list");
DEFSYM (Qstdin, "stdin");
DEFSYM (Qstdout, "stdout");
next prev parent reply other threads:[~2018-12-04 8:33 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-11-27 22:11 bug#33532: 26.1; set-window-configuration does not restore display start Markus Triska
2018-11-28 6:41 ` Eli Zaretskii
2018-11-28 17:13 ` Markus Triska
2018-11-28 17:41 ` Eli Zaretskii
2018-11-28 17:58 ` Markus Triska
2018-11-28 18:29 ` Eli Zaretskii
2018-11-29 8:31 ` martin rudalics
2018-11-29 18:09 ` Markus Triska
2018-11-29 19:11 ` martin rudalics
2018-11-30 16:58 ` Markus Triska
2018-11-30 17:47 ` martin rudalics
2018-12-01 22:52 ` Juri Linkov
2018-12-02 8:34 ` martin rudalics
2018-12-03 0:52 ` Juri Linkov
2018-12-03 7:45 ` martin rudalics
2018-12-03 22:59 ` Juri Linkov
2018-12-04 6:41 ` Eli Zaretskii
2018-12-04 21:44 ` Juri Linkov
2018-12-04 8:33 ` martin rudalics [this message]
2018-12-04 21:47 ` Juri Linkov
2018-12-05 9:16 ` martin rudalics
2018-12-06 0:09 ` Juri Linkov
2018-12-06 9:09 ` martin rudalics
2018-12-06 23:38 ` Juri Linkov
2018-12-25 21:49 ` Juri Linkov
2018-11-30 19:20 ` Eli Zaretskii
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
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5C063BCA.3090301@gmx.at \
--to=rudalics@gmx.at \
--cc=33532@debbugs.gnu.org \
--cc=juri@jurta.org \
--cc=triska@metalevel.at \
/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 public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).