Re: Recent read-face patch breaks `M-x customize-face'

[Roland Winkler]

On Sat Apr 6 2013 Stefan Monnier wrote:
> > Removing this magic from read-face-name would require in turn that
> > commands such as make-face-bold call face-at-point for a reasonable
> > value of DEFAULT. In my humble opinion, this appears to be the
> > cleanest solution.
> 
> I think the for sake of backward compatibility, it is best to just
> preserve the kludge.

The command customize-face is actually more subtle than I had
realized previously. It calls read-face-name with DEFAULT being
"all faces". But read-face-name used to ignore and override this
value when there was a "face at point". So the value of DEFAULT was
really   (or (face-at-point) "all faces").  From a user perspective,
this behavior is certainly quite reasonable. But for the old
implementation it was crucial that read-face-name would replace
"all faces" by (face-at-point).  This overriding of the value of
DEFAULT was rather weird behavior and I'd like to avoid this if
somehow possible.

Backward compatibilty should not break existing code. But under this
umbrella it must be possible to modify and improve the code.

So backward compatiblity requires that the arg DEFAULT of
read-face-name may be a list of faces (as the docstring says). But a
symbol (representing a single face) or a string (which may represent
a single face, a comma-separated list of faces, or some "bogus face"
such as "all faces") should be accepted, too. But as long as the prompt
of read-face-name tells the user the actual value of DEFAULT, this
will not break anybody's existing code. - Did I overlook something here?

Roland