From: Daniel McClanahan <danieldmcclanahan@gmail.com>
To: Lars Magne Ingebrigtsen <larsi@gnus.org>
Cc: emacs-devel@gnu.org
Subject: Re: "Staying in the same place"
Date: Mon, 4 Apr 2016 02:28:04 -0500 [thread overview]
Message-ID: <CALuGEhL+HN2w8ZzV1erwDc6PJStm+d4CyrrA_Nhe66jx-fthDg@mail.gmail.com> (raw)
In-Reply-To: <m3inzx6h2c.fsf@gnus.org>
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
>
next prev parent reply other threads:[~2016-04-04 7:28 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-04-04 5:40 "Staying in the same place" Lars Magne Ingebrigtsen
2016-04-04 6:09 ` Lars Magne Ingebrigtsen
2016-04-04 7:28 ` Daniel McClanahan [this message]
2016-04-04 12:51 ` Stefan Monnier
2016-04-04 18:19 ` Lars Magne Ingebrigtsen
2016-04-04 18:36 ` Stefan Monnier
2016-04-04 18:42 ` Lars Magne Ingebrigtsen
2016-04-04 19:25 ` Karl Fogel
2016-04-04 19:43 ` Lars Magne Ingebrigtsen
2016-04-04 19:49 ` Karl Fogel
2016-04-04 19:52 ` Lars Magne Ingebrigtsen
2016-04-04 23:21 ` John Wiegley
2016-04-05 0:36 ` Drew Adams
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=CALuGEhL+HN2w8ZzV1erwDc6PJStm+d4CyrrA_Nhe66jx-fthDg@mail.gmail.com \
--to=danieldmcclanahan@gmail.com \
--cc=emacs-devel@gnu.org \
--cc=larsi@gnus.org \
/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).