Re: kill ring menu

[Colin Walters <walters@gnu.org>]

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.