unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Stefan Monnier <monnier@IRO.UMontreal.CA>
To: Eli Zaretskii <eliz@gnu.org>
Cc: acm@muc.de, emacs-devel@gnu.org
Subject: Re: Is there something like `on-display-functions'?
Date: Fri, 29 Jan 2010 13:08:22 -0500	[thread overview]
Message-ID: <jwvaavwlrkr.fsf-monnier+emacs@gnu.org> (raw)
In-Reply-To: <83zl3xs2ec.fsf@gnu.org> (Eli Zaretskii's message of "Fri, 29 Jan 2010 11:09:47 +0200")

>> >> > Note that the JIT Lock function that gets invoked via
>> >> > fontification-functions always starts from the beginning of the line
>> >> > to which the position it was invoked with belongs.  So it is already
>> >> > doing something similar, albeit for different reasons.
>> >> That used to be the case, but now this region-extension has been moved
>> >> to font-lock (where it belongs).
>> > The effect is the same.
>> Not quite: there are other users of jit-lock than font-lock (mostly
>> glasses-mode, but Alan might become the third user, linum could be
>> another user, ...).
> My point was that the Lisp function which is invoked via this
> mechanism can do its work in any position it finds fit, not
> necessarily the position passed to it by the display engine.

Right, but for efficiency reason, we'd like to make sure it does its job
at a place that's useful.  With a single fontification-function, the
`fontified' text property provides this information very precisely.

>> This assumption is currently not true.  Recording which part is already
>> handled and which part is not yet handled is usually done either by the
>> `fontified' property (if you use fontification-functions) or somehow by
>> `jit-lock'.
> That ``somehow'' is what I meant when I mentioned that the function
> could record where it left off in some variable.

jit-lock uses the `fontified' text property for that, and then forces
all its clients to fontify (at least) the same part of the buffer, which
is what fontification-functions can't do because it only provides the
`start' but not the `end' argument.

>> If such a problem of efficiency needs to be solved, we could indeed
>> probably hack it up via some such variable, tho it would be mighty ugly,
>> since the function wouldn't necessarily know what happened between the
>> last time it was called and the current time, so it would need to
>> somehow figure out whether "nothing happened and I can just return" or
>> whether in the contrary the buffer has been modified and the
>> fontification that was computed last time needs to be refreshed.
> Anything that's needed for such a decision except the position and the
> buffer or window id?

MODIFF, probably.

>> > Fine with me.  But I do think we may wish to have some more general
>> > redisplay-hook feature, that isn't tailored to fontification.
>> Not sure what you're thinking of.
> I was thinking about a hook that does not depend on the `fontified'
> property.

What would it depend on and what info would it provide to its functions?

>> I'd be interested in a before-redisplay-hook
> Why ``before''?  There isn't much a Lisp code can do to affect
> redisplay, if it is called _by_ redisplay.

Just like fontification-functions, it can affect the faces, the color,
... everything.  See my examples of reveal-mode and cursor color.

> I'd say calling the hook when redisplay is done is more useful.

That's an alternative, indeed, tho I'm not sure what it could be used
for (I do see that it could receive extra info such as which part of
which buffer needed redisply and things like that, but again, no
use-case springs to mind).


        Stefan




  reply	other threads:[~2010-01-29 18:08 UTC|newest]

Thread overview: 41+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-01-27 13:57 Is there something like `on-display-functions'? Alan Mackenzie
2010-01-27 13:53 ` Lennart Borgman
2010-01-27 14:55   ` Alan Mackenzie
2010-01-27 15:11   ` Stefan Monnier
2010-01-27 15:37     ` Alan Mackenzie
2010-01-27 17:44       ` Eli Zaretskii
2010-01-27 19:24         ` Stefan Monnier
2010-01-27 20:08           ` Eli Zaretskii
2010-01-27 21:04             ` Stefan Monnier
2010-01-28  6:49               ` Eli Zaretskii
2010-01-28 19:37                 ` Stefan Monnier
2010-01-28 20:53                   ` Eli Zaretskii
2010-01-28 23:12                     ` Stefan Monnier
2010-01-29  9:09                       ` Eli Zaretskii
2010-01-29 18:08                         ` Stefan Monnier [this message]
2010-01-28  6:55               ` Eli Zaretskii
2010-01-28 10:38                 ` Alan Mackenzie
2010-01-28 12:54                   ` Eli Zaretskii
2010-01-28 14:47                     ` Alan Mackenzie
2010-01-28 19:18                       ` Eli Zaretskii
2010-01-29 13:09                         ` Alan Mackenzie
2010-01-28 19:37                   ` Stefan Monnier
2010-01-29 13:17                     ` Alan Mackenzie
2010-01-29 18:13                       ` Stefan Monnier
2010-01-29 19:17                         ` Alan Mackenzie
2010-01-30 21:02                           ` Stefan Monnier
2010-01-27 17:55       ` Eli Zaretskii
2010-01-28 10:27         ` Alan Mackenzie
2010-01-28 11:30       ` Doc patch for `fontification-functions': [was: Is there something like `on-display-functions'?] Alan Mackenzie
2010-01-28 15:34         ` Doc patch for `fontification-functions': Chong Yidong
2010-01-28 16:40           ` Alan Mackenzie
2010-01-28 18:38         ` Doc patch for `fontification-functions': [was: Is there something like `on-display-functions'?] Eli Zaretskii
2010-01-28 19:44         ` Doc patch for `fontification-functions': Stefan Monnier
2010-01-27 14:16 ` Is there something like `on-display-functions'? alin.s
2010-01-27 14:27 ` David Kastrup
2010-01-27 15:20   ` Alan Mackenzie
2010-01-27 16:31   ` Stephen J. Turnbull
2010-01-27 14:59 ` Davis Herring
2010-01-28  1:41 ` Daniel Colascione
2010-01-28 10:14   ` Alan Mackenzie
2010-01-28 19:39     ` Stefan Monnier

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=jwvaavwlrkr.fsf-monnier+emacs@gnu.org \
    --to=monnier@iro.umontreal.ca \
    --cc=acm@muc.de \
    --cc=eliz@gnu.org \
    --cc=emacs-devel@gnu.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).