[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#17678: 24.4.50; Feature Request -- calculate new `window-start` & `w
From: |
Stefan Monnier |
Subject: |
bug#17678: 24.4.50; Feature Request -- calculate new `window-start` & `window-end` before visual redisplay |
Date: |
Wed, 11 Jun 2014 14:00:39 -0400 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/24.4.50 (gnu/linux) |
> In a stackoverflow thread regarding this issue, @Stefan suggested that
> I take a look at the `jit-lock-register`. After combing through the
> code in `jit-lock.el` and trying some experiments, I believe that
> `jit-lock.el` is more suited to a situation when buffer *modification*
> occurs -- it is also suited for situations where one may wish to
> incrementially act upon an entire buffer in small chunks at a time to
> increase efficiency of avaialble resources.
Indeed, jit-lock is designed for features that depend on the buffer's
*contents* but not on things like the value of `point'.
> I believe that the solution may be to have a `sneak-preview-redisplay`
> whereby the *new* `window-start` and *new* `window-end` could be
> correctly calculated without the visual buffer actually
> being redisplayed.
Of course, there's a circularity problem, here: if you need window-start
(you can already compute window-end without an actual redisplay) in
order to then install things like text-properties properties and
overlays that affect the display, then those added properties may end up
requiring changing window-start again (because they end up pushing point
outside of the window and require a scroll).
This said, the request is reasonable, and seems related to the needs of
follow-mode as well.
IIUC your particular use case (drawing crosshairs to show where the
cursor is located) is one where what you really need is to know when
window-start changes (just like follow-mode).
So, a good feature might be one that runs a hook when redisplay decides
that window-start needs to be reset (i.e. that point moved out of the
window and we need to scroll).
Stefan
- bug#17678: 24.4.50; Feature Request -- calculate new `window-start` & `window-end` before visual redisplay, Keith David Bershatsky, 2014/06/03
- bug#17678: 24.4.50; Feature Request -- calculate new `window-start` & `window-end` before visual redisplay,
Stefan Monnier <=
- bug#17678: 24.4.50; Feature Request -- calculate new `window-start` & `window-end` before visual redisplay, Eli Zaretskii, 2014/06/11
- bug#17678: 24.4.50; Feature Request -- calculate new `window-start` & `window-end` before visual redisplay, Stefan Monnier, 2014/06/11
- bug#17678: 24.4.50; Feature Request -- calculate new `window-start` & `window-end` before visual redisplay, Eli Zaretskii, 2014/06/12
- bug#17678: 24.4.50; Feature Request -- calculate new `window-start` & `window-end` before visual redisplay, Stefan Monnier, 2014/06/12
- bug#17678: 24.4.50; Feature Request -- calculate new `window-start` & `window-end` before visual redisplay, Eli Zaretskii, 2014/06/13
- bug#17678: 24.4.50; Feature Request -- calculate new `window-start` & `window-end` before visual redisplay, Stefan Monnier, 2014/06/13
- bug#17678: 24.4.50; Feature Request -- calculate new `window-start` & `window-end` before visual redisplay, Eli Zaretskii, 2014/06/13
- bug#17678: 24.4.50; Feature Request -- calculate new `window-start` & `window-end` before visual redisplay, Stefan Monnier, 2014/06/13
- bug#17678: 24.4.50; Feature Request -- calculate new `window-start` & `window-end` before visual redisplay, Eli Zaretskii, 2014/06/13
- bug#17678: 24.4.50; Feature Request -- calculate new `window-start` & `window-end` before visual redisplay, Stefan Monnier, 2014/06/13