emacs-devel
[Top][All Lists]
Advanced

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

Re: Buffer-local faces


From: Kim F. Storm
Subject: Re: Buffer-local faces
Date: 04 May 2004 10:40:05 +0200
User-agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3.50

Miles Bader <address@hidden> writes:

> On Tue, May 04, 2004 at 11:18:21AM +0200, David Kastrup wrote:
> > I am uncomfortable about the whole change.  And the reason has to do
> > with the feature freeze.  Now you may argue that the change is not so
> > intrusive as to be likely to trigger new bugs, but that's beside the
> > point.
>
> I said nothing about the feature freeze.  I did not post my patch to `sneak
> in under the wire' of the freeze, I posted it because I (1) happened to have
> been working on it, and (2) came up with something nice.

Again, feature freeze means that people should switch attention away
from developing new features -- but that doesn't exclude that we
can add things (for a short period) that people have already been
working on before the freeze.

If those new features are useful (and the changes are not too
intrusive), I would prefer to get them into 21.5 rather than wait for
22.x to come out (history shows that major emacs releases don't happen
everyday :-| )

I think Miles' approach is quite elegant, as it solves a real problem
in a simple and IMO clean way.  There may be cases that are not
handled by this approach, but it is still a whole lot better than
having no approach at all.

And even if we find a better or more general approach later on, I
believe it can co-exist with Miles' code, as that code works on a
pretty low level (implementation-wise).

Of course, there may be things that don't work with Miles' patch (fringe
faces may be one case -- haven't checked), but it could be fixed during
pretest if deemed necessary.

I would love to have this feature.

> I don't think it's a kludge at all, it's an elegant way of leveraging emacs'
> very flexible variable mechanism to achieve the goal -- not only is it almost
> trivial to implement, but it would seem to fit very well with the way emacs
> modes work.

I don't think it is a kludge either.

>
> Perhaps xemacs has a better way of doing it, I don't know -- I'm afraid I'm
> not familiar with xemacs in recent years.

As a true GNU emacs evangelist, I've never been familiar with xemacs...

--
Kim F. Storm <address@hidden> http://www.cua.dk





reply via email to

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