bug#19217: 25.0.50; `C-M-x' (`eval-defun') on a `defface' that is not top-level

[Drew Adams]

> > It is not uncommon to have a `defface' inside a condition such as
> > (when (> emacs-major-version 23)...).
> 
> Obviously, I'm blindsided by looking mostly at bundled Elisp code,
> but to get an idea of how common it might be, could you explain why
> you'd want to wrap it in that way?

I just did - when the defface (e.g. the given face itself) makes
sense only for certain Emacs versions.  It doesn't matter how
common it is - it is common enough.  There is no reason users should
not have a simple way to redefine a defface, defvar, or defcustom,
at top level or not.

This should not need to be justified by showing how commonly it is
needed.  Obviously this is only a nice-to-have; we've been getting
along without it for decades.  So what?

The current limitation to top-level is for what reason?  For users?
I'm guessing that the only answer is that this limitation simplifies
the *implementation*, not that it simplifies things for users.
30 years later, we ought to be able to do a little better (for users).

I suggested a simple improvement that can be made easily - let users
do it at least when point is on the defface etc. symbol.  That's a
limitation, but it at least gives you some way to easily redefine the
critter.

The point is that there is currently *no* way for a user to do it.
It's not about making things super general.  Just give us some easy
way to do it.  Let's not let the search for something ideal become
the enemy of making a simple improvement.

> > How about letting users redefine a `defface' with `C-M-x' even in
> > this case?
> 
> I think I'd welcome a patch which fixes this well enough
> (including in the case of C-u C-M-x).

I don't have a patch.  I too welcome a simple improvement here. 

> The current way C-M-x handled defvar/defface is hackish and ugly.

I assume you're talking about the implementation and not the way
users interact with Emacs using it.  The current user interaction
is simple and useful.

> Extending this hack to code wrapped in a conditional test would
> not be welcome.

Sounds like we're in for a few more decades of the same.

> But replacing the hack with something a bit more generic would
> be nice.

Provided we don't lose other functionality or convenience.
"Beware the generic rewrite improvement."  This should not be
a big deal.