From: Stefan Monnier <monnier@iro.umontreal.ca>
To: Joe Wells <jbw@macs.hw.ac.uk>
Cc: rms@gnu.org, Markus Triska <markus.triska@gmx.at>, emacs-devel@gnu.org
Subject: Re: something like linum.el ought to be added
Date: Fri, 14 Sep 2007 13:20:20 -0400 [thread overview]
Message-ID: <jwv8x79rx3h.fsf-monnier+emacs@gnu.org> (raw)
In-Reply-To: <86k5qtjka0.fsf@macs.hw.ac.uk> (Joe Wells's message of "Fri\, 14 Sep 2007 17\:15\:19 +0100")
> Some comments on the idea of relying on fontification-functions:
> I think linum.el should work even if the user has font-locking turned
> off, so it shouldn't depend on jit-lock.el (unless jit-lock can be
> used without turning font-locking on?). Anyway, the whole
> font-locking subsystem is also quite hard to understand, so it seems
> unwise to me to get linum.el tied up in that complexity. And
> font-locking is oriented toward fontifying the entire buffer
> eventually while with line numbering you probably only want to keep
> active overlays for the displayed region.
You may want to take another look at jit-lock-register. Or glasses-mode for
that matter (the only other user of jit-lock currently besides font-lock).
But yes: jit-lock is oriented towards fontifying the whole buffer, which is
not what linum.el wants to do (and actually glasses-mode would probably
rather be like linum.el).
> And it seems it would be hard for fontification-functions will work
> well with linum.el as a separate user from jit-lock.el, because they
> would both be competing for control of the same fontified property.
> So, for example, if stealth background fontification fontified some
> region, it would (I think?) place a non-nil value on the fontified
> property of that region, and then when that region was displayed by
> scrolling there would be nothing to trigger the line numbering.
Yes, that's the problem I hinted at which makes it pretty much impossible to
use multiple functions on fontification-functions.
So I think it's fine for linum.el to use something else, but I do think it's
a good opportunity also to revisit this jit-lock and fontification-functions
business to try and come up with a good solution.
Maybe a solution is to change jit-lock by having it distinguish between
clients that would rather keep everything fontified (full clients) and those
that would rather only keep the displayed part fontified (light clients).
Then add a jit-lock-clear-unused thingy that would go and flush all the
non-displayed data of the light clients and then set fontified to nil (so
that jit-lock gets to know when those need to be prepared for display), but
also set jit-lock-fontified to t (so that jit-lock knows that this was
already fontified w.r.t full clients, so only light clients need to be
called).
Stefan
next prev parent reply other threads:[~2007-09-14 17:20 UTC|newest]
Thread overview: 46+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-09-09 10:04 something like linum.el ought to be added Joe Wells
2007-09-09 10:43 ` Leo
2007-09-10 16:53 ` Richard Stallman
2007-09-10 17:34 ` Markus Triska
2007-09-10 20:00 ` David Kastrup
2007-09-11 18:15 ` Markus Triska
2007-09-11 20:27 ` Davis Herring
2007-09-11 21:24 ` Markus Triska
2007-09-12 8:47 ` Richard Stallman
2007-09-12 9:14 ` Joe Wells
2007-09-12 9:21 ` David Kastrup
2007-09-12 18:52 ` Richard Stallman
2007-09-13 17:06 ` Markus Triska
2007-09-14 13:59 ` Stefan Monnier
2007-09-14 16:15 ` Joe Wells
2007-09-14 17:20 ` Stefan Monnier [this message]
[not found] ` <m1bqajgpc8.fsf_-_@gmx.at>
2007-10-28 18:46 ` motivation for recent bug reports on overlays and properties like before-string, display, after-string, and face (was: linum.el and display properties) Joe Wells
2007-09-15 2:09 ` something like linum.el ought to be added Richard Stallman
2007-09-14 15:04 ` brianjiang
2007-09-14 15:56 ` Markus Triska
2007-09-15 14:46 ` Juanma Barranquero
2007-09-15 16:12 ` Markus Triska
2007-09-15 16:54 ` Juanma Barranquero
2007-09-11 20:30 ` Richard Stallman
2007-09-11 20:31 ` Richard Stallman
2007-09-11 23:48 ` Markus Triska
2007-09-12 9:19 ` martin rudalics
2007-09-12 11:17 ` Markus Triska
2007-09-12 12:09 ` martin rudalics
2007-09-12 12:55 ` Markus Triska
2007-09-15 14:24 ` Juanma Barranquero
2007-09-15 16:01 ` Markus Triska
2007-09-15 16:14 ` Juanma Barranquero
2007-09-16 5:34 ` Richard Stallman
2007-09-16 15:57 ` Markus Triska
2007-09-17 3:58 ` Richard Stallman
2007-09-16 23:04 ` Stefan Monnier
2007-09-17 3:58 ` Richard Stallman
2007-09-17 5:12 ` brianjiang
2007-09-17 13:49 ` Stefan Monnier
2007-09-17 13:17 ` Stefan Monnier
2007-09-17 22:24 ` Richard Stallman
2007-09-18 0:49 ` Stefan Monnier
2007-09-18 3:30 ` Richard Stallman
2007-09-18 14:31 ` Stefan Monnier
2007-09-11 7:08 ` martin rudalics
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=jwv8x79rx3h.fsf-monnier+emacs@gnu.org \
--to=monnier@iro.umontreal.ca \
--cc=emacs-devel@gnu.org \
--cc=jbw@macs.hw.ac.uk \
--cc=markus.triska@gmx.at \
--cc=rms@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).