Re: "Staying in the same place"

[Daniel McClanahan]

I know for markdown-mode on MELPA, I added a "live-preview" feature which
displays the rendered markdown file alongside in an eww (or other) buffer as the
user edits, and I wanted to make any windows displaying that buffer have the
idea of "not moving." I played around a bit with some ideas and thought of
recording the scroll and window-point for all windows displaying the buffer, and
the visual lines between the scroll and point, and then restored the scroll,
window-point, and visual line difference for each window when the buffer was
regenerated. I also had a special case for when the window-point was equal to
point-min or point-max, in which case I just scrolled the buffer all the way
down or up.

This isn't likely to apply to a lot of other modes, but it's just a thought
about what other information might be useful if you wanted to implement
something like this.

On Mon, Apr 4, 2016 at 1:09 AM, Lars Magne Ingebrigtsen <address@hidden> wrote:
> Lars Magne Ingebrigtsen <address@hidden> writes:
>
>> I wonder if anybody has thought about the issue in a more general way --
>> by providing a mechanism to save (perhaps a lot) of context, and then
>> trying to go back to the same context again after regenerating the
>> buffer, in a ... fuzzy way.
>
> Thinking about this a bit more, I think it's difficult to see a way to
> do this generally without support from each mode.  However:
>
> In general, if the buffer reflects things that don't really change a
> lot, just recording the current line (and the next and previous ten
> lines, say), would DWIM.
>
> For buffers where there is a strong "identity" (say, file names in dired
> and bug numbers in debbugs mode), the mode could provide a way to give
> those identities to `revert-buffer' (and a way to restore point).
>
> Take compilation modes, for instance.  Let's say there's a variable
> `revert-buffer-context-function'.  The mode would return a list of error
> points...
>
> make -k
>   CC       vm-limit.o
>   CC       dispnew.o
>   CC       frame.o
> frame.c: In function 'x_set_frame_parameters':
> frame.c:3296:25: warning: 'height' may be used uninitialized in this function 
> [-Wmaybe-uninitialized]
> frame.c:3296:25: warning: 'width' may be used uninitialized in this function 
> [-Wmaybe-uninitialized]
>   CC       scroll.o
>   CC       xdisp.o
> xdisp.c: In function 'move_it_in_display_line_to':
> xdisp.c:8556:13: warning: 'closest_pos' may be used uninitialized in this 
> function [-Wmaybe-uninitialized]
> xdisp.c: In function 'display_line':
> xdisp.c:20348:8: warning: 'max_bpos' may be used uninitialized in this 
> function [-Wmaybe-uninitialized]
>  ...
>
> The list would perhaps be '("^frame.c:3296:" "^xdisp.c:8556:" ...).
> `revert-buffer' would then basically do
>
> (let ((context (funcall revert-buffer-context-function)))
>   (funcall revert-buffer-function)
>   (revert-buffer-restore-point context))
>
> which would use those regexps to put point somewhere DWIM-ey.  And there
> could be a `revert-buffer-restore-point-function' variable, too, if the
> mode needs a more specialised way to use the context.
>
> Of course, the this specific example, this wouldn't work, since
> compilation is asynchronous, but the compilation mode could just use the
> context itself from the filter.  Or the sentinel.  Or something.
>
> Hm...
>
> But I think this approach might work for many modes...  perhaps...
>
> --
> (domestic pets only, the antidote for overdose, milk.)
>    bloggy blog: http://lars.ingebrigtsen.no
>