[Top][All Lists]

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

Re: Elisp manual: Note that created faces cannot be removed.

From: Alan Mackenzie
Subject: Re: Elisp manual: Note that created faces cannot be removed.
Date: Mon, 22 Jul 2019 15:18:48 +0000
User-agent: Mutt/1.10.1 (2018-07-13)

Hello, Eli.

On Mon, Jul 22, 2019 at 17:33:40 +0300, Eli Zaretskii wrote:
> > Date: Mon, 22 Jul 2019 10:02:09 +0000
> > Cc: address@hidden, Noam Postavsky <address@hidden>
> > From: Alan Mackenzie <address@hidden>

> > Sorry to go on about this (trivial) point, but I'm not happy about my
> > proposed text any more.  With the mechanism pointed out by Noam, it
> > clearly _is_ possible to undefine a face, but it's unsafe.

> > So, using "undefine" rather than "remove" (suggested to me by private
> > email), and inserting the word "safely", I now propose this:

> > diff --git a/doc/lispref/display.texi b/doc/lispref/display.texi
> > index 276d60b21a..4ae0bba723 100644
> > --- a/doc/lispref/display.texi
> > +++ b/doc/lispref/display.texi
> > @@ -2476,6 +2476,10 @@ Defining Faces
> >  usual procedure is to define a face with @code{defface}, and then use
> >  its name directly.

> > +@cindex face (non-removability of)
> > +Note that once you have defined a face (usually with @code{defface}),
> > +you cannot later undefine this face safely, except by restarting Emacs.

> That's fine with me, but unlike you, I don't really see a difference:
> for the reader of the ELisp manual "cannot undefine safely" and
> "cannot remove" are identical for all practical purposes.  Moreover,
> "undefine a face" is not really well-defined.

Well, I've just committed the change.  Maybe there's only a slight
difference between "cannot remove" and "cannot undefine safely", but
there actually is a difference - the latter is closer to the truth.

"undefine a face" might not be well-defined, but since we can't do it
anyway (at least, not safely), that surely doesn't matter too much.
Stefan has suggested we hack such a facility, but ...  Well somebody
would have to do it, and the benefit of it would not be great.

Anyway, I think we've talked around this enough already, so let's just
close the conversation.  :-)

Alan Mackenzie (Nuremberg, Germany).

reply via email to

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