bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#33532: 26.1; set-window-configuration does not restore display start


From: martin rudalics
Subject: bug#33532: 26.1; set-window-configuration does not restore display start
Date: Tue, 04 Dec 2018 09:33:14 +0100

> 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: fileio.diff
Description: Text document


reply via email to

[Prev in Thread] Current Thread [Next in Thread]