unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
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

  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).