"Staying in the same place"

"Staying in the same place"

[Lars Magne Ingebrigtsen]

There's a lot of modes in Emacs that don't reflect a physical file, but
has only generated content (for some values of "generated").  Many of
these implement a version of "revert", usually bound to the `g' key,
which basically do an `erase-buffer' and then generate the buffer anew.

And then you have to implement some way of "staying in the same place".

Which is a pretty fuzzy, do-what-I-mean kind of thing, because the data
may have changed.  The size of the buffer usually has, and the line you
were on may have disappeared.

I think it would be nice if Emacs had a general function for "try to
stay in the same place", but I don't know whether that's realistic.  For
instance, dired notes both the point and the file name you're at, and
first tries to go to the file in question, or if the file is gone, it...
uhm...  Goes to the point and then goes to the file on that line?
Something.

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.

(The reason I'm thinking about this is that I was thinking about what
would be necessary to make `g' in compilation buffers remain in "the
same place".  Which is useful when you're trying to weed out compilation
warnings.)

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: "Staying in the same place"

[Lars Magne Ingebrigtsen]

Lars Magne Ingebrigtsen <larsi@gnus.org> 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

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 <larsi@gnus.org> wrote:
> Lars Magne Ingebrigtsen <larsi@gnus.org> 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
>

Re: "Staying in the same place"

[Stefan Monnier]

> There's a lot of modes in Emacs that don't reflect a physical file, but
> has only generated content (for some values of "generated").  Many of
> these implement a version of "revert", usually bound to the `g' key,
> which basically do an `erase-buffer' and then generate the buffer anew.

I think it'd good to think of such solutions in the context of bookmarks
as well.

IOW, I think ideally, there should be a special-mode-revert-buffer
function (which special-mode sets as the default value of
revert-buffer-function), which basically just does a "get bookmark data,
then go back to that bookmark".

I don't think it can be done with the current bookmark data, tho.
IIRC there were 2 main reasons:
- You need to be able to distinguish the case "go back to bookmark in
  a new buffer" and "go back to bookmark in the current buffer".
- You probably want to distinguish between the case where you want to
  revert/refresh, and the case where it's OK to just jump to some
  spot in some existing buffer.

Last time I looked at it, I also figured that it'd be nice if the
help-xref-* could use the same infrastructure.

> And then you have to implement some way of "staying in the same place".

Bookmarks do that part acceptably, I think.

> (The reason I'm thinking about this is that I was thinking about what
> would be necessary to make `g' in compilation buffers remain in "the
> same place".  Which is useful when you're trying to weed out compilation
> warnings.)

Oohh.. that's yet another step up in complexity since in that case you
can't "go back" right away, you first have to wait for the process to
send enough data.
But yes, that would be great (I'd particularly appreciate it in
*vc-diff*).


        Stefan

Re: "Staying in the same place"

[Lars Magne Ingebrigtsen]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> I think it'd good to think of such solutions in the context of bookmarks
> as well.

Hm...  interesting...

I know next to nothing about Emacs bookmarking.  How are bookmarks
stored (for special mode buffers)?

> I don't think it can be done with the current bookmark data, tho.
> IIRC there were 2 main reasons:
> - You need to be able to distinguish the case "go back to bookmark in
>   a new buffer" and "go back to bookmark in the current buffer".
> - You probably want to distinguish between the case where you want to
>   revert/refresh, and the case where it's OK to just jump to some
>   spot in some existing buffer.

I'm trying to envision how this would work from a UX point of view.
Let's say you're trying to do some "-Wall" cleanups in emacs/src, and
you've gotten halfway down the list of things you're able to clean up,
so you set a bookmark there.  Then the next time you compile something
in that directory, then point moves to around that point?  

>> (The reason I'm thinking about this is that I was thinking about what
>> would be necessary to make `g' in compilation buffers remain in "the
>> same place".  Which is useful when you're trying to weed out compilation
>> warnings.)
>
> Oohh.. that's yet another step up in complexity since in that case you
> can't "go back" right away, you first have to wait for the process to
> send enough data.

Yes, it's an added wrinkle, but I think it should be possible to
handle.  I made a first stab at it in the recently reverted `r'/`l'
code, and it seemed to be kinda nice, even if the implementation wasn't
very general.

> But yes, that would be great (I'd particularly appreciate it in
> *vc-diff*).

Indeed, staying in the "same place" in *vc-diff* would be very nice.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: "Staying in the same place"

[Stefan Monnier]

>> I think it'd good to think of such solutions in the context of bookmarks
>> as well.
> Hm...  interesting...
> I know next to nothing about Emacs bookmarking.  How are bookmarks
> stored (for special mode buffers)?

For the current discussion the part that saves bookmarks is
not important.

The important part is that you can build a "bookmark object" which should
contain enough data to reproduce the current buffer&position.

> I'm trying to envision how this would work from a UX point of view.
> Let's say you're trying to do some "-Wall" cleanups in emacs/src, and
> you've gotten halfway down the list of things you're able to clean up,
> so you set a bookmark there.  Then the next time you compile something
> in that directory, then point moves to around that point?  

You might be able to do that, but what I was proposing was not to let
users use the bookmark functionality, but simply to have a default
special-mode-revert-buffer function which would do something along
the lines of:

    (defun special-mode-revert-function ()
      (let ((here (funcall bookmark-make-record-function)))
        (erase-buffer)
        (bookmark-goback here)))


-- Stefan

Re: "Staying in the same place"

[Lars Magne Ingebrigtsen]

Stefan Monnier <monnier@IRO.UMontreal.CA> writes:

> The important part is that you can build a "bookmark object" which should
> contain enough data to reproduce the current buffer&position.

Yes, but would that work they way I sketched out in the second message
in this thread?  I.e., the mode would supply a function that would
provide a list of (say) 20 places to look for a place that's "the same"?

> You might be able to do that, but what I was proposing was not to let
> users use the bookmark functionality, but simply to have a default
> special-mode-revert-buffer function which would do something along
> the lines of:
>
>     (defun special-mode-revert-function ()
>       (let ((here (funcall bookmark-make-record-function)))
>         (erase-buffer)
>         (bookmark-goback here)))

Aha, I see.  Yes, that sounds very nice.  As long as the bookmark
functionality is sufficiently flexible about the `here' it's willing to
accept..

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: "Staying in the same place"

[Karl Fogel]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:
>Stefan Monnier <monnier@IRO.UMontreal.CA> writes:
>
>> The important part is that you can build a "bookmark object" which should
>> contain enough data to reproduce the current buffer&position.
>
>Yes, but would that work they way I sketched out in the second message
>in this thread?  I.e., the mode would supply a function that would
>provide a list of (say) 20 places to look for a place that's "the same"?

Yes, see below...

>> You might be able to do that, but what I was proposing was not to let
>> users use the bookmark functionality, but simply to have a default
>> special-mode-revert-buffer function which would do something along
>> the lines of:
>>
>>     (defun special-mode-revert-function ()
>>       (let ((here (funcall bookmark-make-record-function)))
>>         (erase-buffer)
>>         (bookmark-goback here)))
>
>Aha, I see.  Yes, that sounds very nice.  As long as the bookmark
>functionality is sufficiently flexible about the `here' it's willing to
>accept..

So, stepping back a moment:

First, bookmark has the idea of a fuzzily-recorded place -- a position (in a buffer of text) that is somehow "the same" as it used to be, even though some things about the text have changed.  Obviously, if the text changes too much, the concept of "the same place" becomes meaningless, and bookmark can't recover the position.

Second, bookmark already has a mechanism for delegating that notion of a fuzzily-recorded position to other modes (e.g., to Info mode).

And Stefan has pointed out that what you're proposing is essentially what bookmark already does.  Maybe that idea of recording a position fuzzily should be abstracted out, and then bookmark would use the new abstraction too, or maybe this new function should just use bookmark's existing code (which, in turn, already hooks into mode-specific code in some cases, and could do more of that).

In any case, though, should the new thing be defined as a macro?  That seems like the more natural way, at least IMHO.  Something like:

(defmacro fuzzy-save-excursion (&rest body)
   record-the-position-fuzzily-using-mode-specific-code
   run-the-body
   restore-the-fuzzily-recorded-position
)

Or maybe:

(defmacro fuzzy-save-excursion (save-func restore-func &rest body)
   record-the-position-fuzzily-with-save-func
   run-the-body
   restore-using-restored-func
)

?

Best regards,
-Karl

Re: "Staying in the same place"

[Lars Magne Ingebrigtsen]

Karl Fogel <kfogel@red-bean.com> writes:

> And Stefan has pointed out that what you're proposing is essentially
> what bookmark already does.  Maybe that idea of recording a position
> fuzzily should be abstracted out, and then bookmark would use the new
> abstraction too, or maybe this new function should just use bookmark's
> existing code (which, in turn, already hooks into mode-specific code
> in some cases, and could do more of that).

Ah, I didn't know that about bookmarks.  Sounds like all the mechanisms
we need are in place, so we just need to start using them throughout the
various modes.  But perhaps provide easier-to-understand interfaces
like:

> In any case, though, should the new thing be defined as a macro?  That
> seems like the more natural way, at least IMHO.  Something like:
>
> (defmacro fuzzy-save-excursion (&rest body)
>    record-the-position-fuzzily-using-mode-specific-code
>    run-the-body
>    restore-the-fuzzily-recorded-position
> )

Yes, I think having a macro for this would be very handy and encourage
usage of this stuff.  However, the restore-the-fuzzily-recorded-position
thing should also be available in a handy fashion for when we're doing
asynchronous fuzzy point restoration (with diff mode and compilation
mode, for instance).

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: "Staying in the same place"

[Karl Fogel]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:
>> (defmacro fuzzy-save-excursion (&rest body)
>>    record-the-position-fuzzily-using-mode-specific-code
>>    run-the-body
>>    restore-the-fuzzily-recorded-position
>> )
>
>Yes, I think having a macro for this would be very handy and encourage
>usage of this stuff.  However, the restore-the-fuzzily-recorded-position
>thing should also be available in a handy fashion for when we're doing
>asynchronous fuzzy point restoration (with diff mode and compilation
>mode, for instance).

Yes, absolutely.  A "fuzzily recorded position" should be a first-class object that can be passed around like any value.  There can be a macro that generates and consumes such objects entirely internally to the macro, but the objects can also be generated explicitly in code and consumed later.

Re: "Staying in the same place"

[Lars Magne Ingebrigtsen]

Karl Fogel <kfogel@red-bean.com> writes:

> Yes, absolutely.  A "fuzzily recorded position" should be a
> first-class object that can be passed around like any value.  There
> can be a macro that generates and consumes such objects entirely
> internally to the macro, but the objects can also be generated
> explicitly in code and consumed later.

This sounds great to me.  :-)

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: "Staying in the same place"

[John Wiegley]

>>>>> Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> Karl Fogel <kfogel@red-bean.com> writes:
>> Yes, absolutely.  A "fuzzily recorded position" should be a
>> first-class object that can be passed around like any value.  There
>> can be a macro that generates and consumes such objects entirely
>> internally to the macro, but the objects can also be generated
>> explicitly in code and consumed later.

> This sounds great to me.  :-)

I like this as well.  Basically, a "fuzzy position" is three things:

    Some internal value, potentially unique to each mode
    A method to return such a value based on point
    A method to restore point based on such a value

Seeing this as an abstract data type, the default would be:

    #<marker>, point-marker, goto-char

But each mode would have the opportunity to override with another
implementation. Also, these objects might be persistable in some cases, such
as with bookmarks (though maybe not always).

We'd also need to either extend save-excursion to be aware of this, or define
a new helper form to do the saving/restoring based on this fuzzy definition.

-- 
John Wiegley                  GPG fingerprint = 4710 CF98 AF9B 327B B80F
http://newartisans.com                          60E1 46C4 BD1A 7AC1 4BA2

RE: "Staying in the same place"

[Drew Adams]

> Basically, a "fuzzy position" is three things:
> 
>     Some internal value, potentially unique to each mode
>     A method to return such a value based on point
>     A method to restore point based on such a value
> 
> Seeing this as an abstract data type, the default would be:
> 
>     #<marker>, point-marker, goto-char

Actually, the default for a bookmark is:

1. A general context, such as a file or buffer (e.g. an absolute
   file name or a buffer name).

2. A position within that context (e.g. a buffer position).

3. Some context text immediately after the position.

4. Some context text immediately before the position.

5. A handler function that accepts the bookmark as argument
   and returns point to the place that was bookmarked.

The default handler goes first to the recorded position.
It then searches forward for the after-position context text.
It then searches backward for the before-position context text.

The point is to try to accommodate changes to the file or buffer
text, i.e., to return to the most appropriate place that can be
found.

Special kinds of bookmarks (Info, Dired, `man', etc.) use special
handler functions.