emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: new text property


From: Hrvoje Niksic
Subject: Re: new text property
Date: Tue, 11 Jun 2002 22:40:56 +0200
User-agent: Gnus/5.090006 (Oort Gnus v0.06) XEmacs/21.4 (Common Lisp, i686-pc-linux)

Colin Walters <address@hidden> writes:

> On Tue, 2002-06-11 at 07:40, Hrvoje Niksic wrote:
>
>> Other highlighting mechanims have speed issues as well.  For example,
>> Gnus prefers not to highlight huge messages because that would take
>> too long.  If I controled that with `M-x font-lock-mode' (which would
>> buy me nothing in turns of convenience; Gnus has variables to
>> fine-tune its highlighting), 
>
> It would be convenient because it is the same interface that one uses to
> enable and disable fontification in many prominent Emacs modes;

But in my view, that convenience does not outweigh the need for
consistency.  Respecting `M-x font-lock-mode', but not any other
font-lock variable, is quite inconsistent.

>> I would expect things like `font-lock-maximum-size' to keep
>> working.
>
> Why?

Because I `M-x font-lock-mode' worked just fine.  Because `C-h f
font-lock-mode' claims it does.

> There is no slowdown when using `font-lock-face'.

I never claimed that, sorry if that was unclear.  Read the whole of my
paragraph, which you broke down in two pieces.  It's all about
consistency between `M-x font-lock-mode' and the rest of the
font-lock-* setup (where font-lock-maximum-size is but one element),
which would be broken.

>> Plus, font-lock-maximum-decoration is not only about speed.  Some
>> people don't *like* too much decoration.
>
> Well, that's a hard problem to solve.

Exactly.  That's one more reason why I think it's not a good idea to
merge font-lock and other highlighting on the surface.

Again, I don't have strong feelings about this.  If many users request
this feature, I will not veto its inclusion.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]