Re: kill ring menu

[Miles Bader]

Colin Walters <address@hidden> writes:
> And finally, this is a situation where we have a user-interface win
> (consistency of interface to enabling/disabling fontification) over
> resource consumption (loading of font-lock.el).  I think that as a
> general principle, the former should win over the latter. 

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.

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.

> Using font-lock from the start is a win for other reasons, too.  Suppose
> that Occur mode was changed so you could actually edit the buffer, and
> changes would be reflected in the original buffer.  If the user typed
> additional matches for the search string into the *Occur* buffer, we
> would expect them to be made bold, too.  This is possible in a clean way
> if we use a dynamic font-lock 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.  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.

-Miles
-- 
Fast, small, soon; pick any 2.