GNU bug report logs - #33532
26.1; set-window-configuration does not restore display start

Previous Next

Full log

Message #61 received at 33532 <at> debbugs.gnu.org (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: Juri Linkov <juri <at> jurta.org>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 33532 <at> debbugs.gnu.org,
 Markus Triska <triska <at> metalevel.at>
Subject: Re: bug#33532: 26.1; set-window-configuration does not restore display
 start
Date: Tue, 04 Dec 2018 09:33:14 +0100

[Message part 1 (text/plain, inline)]

> 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

[fileio.diff (text/plain, attachment)]

Previous Next

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