Re: [Emacs-trunk-diffs] Changes to emacs/etc/NEWS

Re: [Emacs-trunk-diffs] Changes to emacs/etc/NEWS

[Richard Stallman]

    ** An unconditional face specification in defface (one where the DISPLAY part
    is just t) applies to all cases and does not override subsequent entries.

This feature does not seem cleanly designed to me.  The first slot in
the spec is supposed to be a condition, and t as a condition has a
very clear meaning in Lisp.  To use t for any other meaning seems very
wrong.

It also seems that this change wasn't fully implemented,
because the code in cus-edit.el that interprets face specs
doesn't know about it.

I think we should replace this with a clean feature before
releasing it.  Here's one idea for a clean feature:

t as the condition means "or else", as it used to, as
people would expect.  nil as the condition means "default",
attributes to be shared by all the conditions.

It should not be very hard to implement this in faces.el instead of
the current code.  However, it needs to be implemented also in
cus-edit.el, which is harder, and in the Lisp manual.
Also, someone needs to check all 500-odd deffaces, but that
probably needs to be done anyway, and most of them will take
only a few seconds to see there's no issue.

Can you or someone please undertake to do this?

Re: [Emacs-trunk-diffs] Changes to emacs/etc/NEWS

[Stefan Monnier]

> t as the condition means "or else", as it used to, as
> people would expect.  nil as the condition means "default",
> attributes to be shared by all the conditions.

I don't find the merged behavior we have right now unclean at all:
The `t' simply means: "default from now on".

If it's in the last position, the "default from now on" degenerates of
course into "else" and if it's in the first position it degenerates into
"default for all".

In contrast your proposal of nil would mean "default even for those things
written before".
Furthermore by splitting the thing into t and nil you'll not only make the
code bigger, but you'll also lose flexibility since it won't be possible to
specify a default for a subset of the face spec.


        Stefan

Re: [Emacs-trunk-diffs] Changes to emacs/etc/NEWS

[Richard Stallman]

    I don't find the merged behavior we have right now unclean at all:
    The `t' simply means: "default from now on".

That is quite unusual, for Emacs Lisp, and is certainly not what
t should mean.

    In contrast your proposal of nil would mean "default even for those things
    written before".

Right; the ordering of a default definition and a specific definition
that inherits from that default should not make any difference.

    Furthermore by splitting the thing into t and nil you'll not only make the
    code bigger,

A small amount of implementation code more or less is a minor issue
when the question is one of making things clear to users.

	       , but you'll also lose flexibility since it won't be possible to
    specify a default for a subset of the face spec.

How much is that flexibility worth, in practice?
Which cases use it?

Re: [Emacs-trunk-diffs] Changes to emacs/etc/NEWS

[Stefan Monnier]

>     I don't find the merged behavior we have right now unclean at all:
>     The `t' simply means: "default from now on".

> That is quite unusual, for Emacs Lisp, and is certainly not what
> t should mean.

Obviously one can't argue about taste.

> 	       , but you'll also lose flexibility since it won't be possible to
>     specify a default for a subset of the face spec.

> How much is that flexibility worth, in practice?
> Which cases use it?

Well, to me when you replace 1 simple concept with 2 less powerful ones,
those two concepts need to significantly simpler in order to make up for the
conceptual cost of having 2 concepts rather than just one (and losing a bit
of generality at the same time).

In the present case I just don't even find any of your two "else" and
"default" concepts to be noticeably simpler than mine.

But it's your code,


        Stefan

Re: [Emacs-trunk-diffs] Changes to emacs/etc/NEWS

[Kim F. Storm]

Stefan Monnier <monnier@iro.umontreal.ca> writes:


> Well, to me when you replace 1 simple concept with 2 less powerful ones,
> those two concepts need to significantly simpler in order to make up for the
> conceptual cost of having 2 concepts rather than just one (and losing a bit
> of generality at the same time).
>
> In the present case I just don't even find any of your two "else" and
> "default" concepts to be noticeably simpler than mine.

>
> But it's your code,
>

I suggest we replace `t' with `default' to satisfy Richard, leaving
both nil and t free for future "enhancements" in case someone wants to
spend time on it.

BTW, is this interpretation of `t' new in 21.4 ?

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

Re: [Emacs-trunk-diffs] Changes to emacs/etc/NEWS

[Stefan Monnier]

> BTW, is this interpretation of `t' new in 21.4 ?

Yes.  In Emacs-21.3 `t' only makes sense for the last entry since everything
after it is ignored.


        Stefan

Re: [Emacs-trunk-diffs] Changes to emacs/etc/NEWS

[Richard Stallman]

    > 	       , but you'll also lose flexibility since it won't be possible to
    >     specify a default for a subset of the face spec.

    > How much is that flexibility worth, in practice?
    > Which cases use it?

    Well, to me when you replace 1 simple concept with 2 less powerful ones,

On grounds of principle, it is clear what is better.  Making defface
follow the general practice of the rest of Lisp is more important than
making it more powerful to write defface specs in a terser way.

When I read that statement about flexibility, I thought you were
making a practical argument that real defspecs would be more complex
and harder to read.  Can you show me a real practical loss from this
change?