[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: kill ring menu
From: |
Colin Walters |
Subject: |
Re: kill ring menu |
Date: |
06 May 2002 23:55:34 -0400 |
On Mon, 2002-05-06 at 21:35, Miles Bader wrote:
> You're assuming such `consistency' is a win. Usually consistency is,
> but several people have said on this thread that they _like_ the current
> `inconsistency.' The rules people follow are not always as simple as
> you might wish. Perhaps in this case people see a distinction between
> fontifying existing `text files' (like program source) and buffers that
> are created by emacs to display some information.
I think that distinction is arbitrary; I don't see it at all.
Especially when one considers that these "special" buffers could quite
legitimately later be extended to be real modes; in that case, are we
going to tell our users, "Oh, you have to set `foo-mode-fontification'
to be non-nil to get special highlighting"? I don't think so; it's
better to make the *interface* via font-lock from the start.
> In any case, if it's _really_ desirable to have the single concept of
> font-locking control all fontification in buffers (and obviously this is
> not clear), then it still seems a bit silly to have font-lock following
> non-face properties in the buffer; you could just as easily arrange for
> the font-lock `user interface' (e.g., toggling font-lock mode) to be
> separate from the font-lock `mechanism' (the part that adds face
> properties), and have whatever ad-hoc fontification code you wish follow
> the dictates of the former without using the latter.
This is *exactly* the way things already work. font-lock in this case
just calls the `font-lock-fontify-region' function to do the
fontification. Thus, font-lock becomes the "user interface", as you
say, and the mode author implements the mechanism.
> This is only true if you use `real' font-locking -- e.g., regexps that
> match the buffer text -- instead of making font-lock follow text
> properties to do its locking.
And why is the former "real" font-locking? Fontification based on
regular expressions is unreliable when we are dealing with a non-regular
language. This is why (or at least I think a major reason why) the
maintainers of font-lock added the ability for the major mode author to
perform fontification themselves.
> You could have _both_ of course, but that
> seems silly; if you really want to dynamically update user added text,
> you may as well just use traditional font-locking from the start.
By "traditional" you mean "based on regexps"? Again, regexp-based
font-lock is not reliable. I personally will always try to avoid
regexp-based fontification in modes I write. And implementing your own
`font-lock-fontify-region' function doesn't mean it has to search for
existing text properties; you can perform arbitrary computation.
But this is a digression. Again, my point is very simple: I think we
should move towards making M-x font-lock-mode, as much as possible, the
standard *interface* for enabling and disabling fontification. Whether
or not is based on regexps is irrelevant.
One other important point; if resource consumption is an issue, we could
quite easily split font-lock.el into font-lock-core.el and font-lock.el,
or whatever.
Re: kill ring menu, Richard Stallman, 2002/05/05
- Re: kill ring menu, Colin Walters, 2002/05/06
- Re: kill ring menu, Miles Bader, 2002/05/06
- Re: kill ring menu, Colin Walters, 2002/05/06
- Re: kill ring menu, Miles Bader, 2002/05/06
- Re: kill ring menu,
Colin Walters <=
- Re: kill ring menu, Miles Bader, 2002/05/07
- Re: kill ring menu, Richard Stallman, 2002/05/07
- Re: kill ring menu, Colin Walters, 2002/05/07
- Re: kill ring menu, Miles Bader, 2002/05/07
- Re: kill ring menu, Colin Walters, 2002/05/08
- Re: kill ring menu, Miles Bader, 2002/05/08
- Re: kill ring menu, Colin Walters, 2002/05/08
- Re: kill ring menu, Miles Bader, 2002/05/08
- Re: kill ring menu, Colin Walters, 2002/05/08
- Re: kill ring menu, Stefan Monnier, 2002/05/08