unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
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");

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