Why is `C-M-x' only for top-level defuns?

Why is `C-M-x' only for top-level defuns?

[Drew Adams]

There is likely a good reason for this, but I'll still pose the question, to
learn.

Why not let `C-M-x' re-evaluate a "defun" (defcustom, defface, etc.) that is not
necessarily at top level?  E.g., with point on, say, `defface' in this sexp, why
shouldn't `C-M-x' redefine the face?

(when twillig-&-the-tithy-toves-do-tyre-&-timble-in-the-twabe
  (defface ...))

Currently, in order to make `C-M-x' work for such a "defun" I temporarily move
its first line to column 1 and then hit `C-M-x'.  Seems like a silly workaround,
but I don't know of a better one.  Am I missing something?

Re: Why is `C-M-x' only for top-level defuns?

[Thien-Thi Nguyen]

() "Drew Adams" <drew.adams@oracle.com>
() Wed, 11 Jan 2012 09:06:24 -0800

   There is likely a good reason for this, but I'll still pose the question,
   to learn.

   Why not let `C-M-x' re-evaluate a "defun" (defcustom, defface, etc.) that
   is not necessarily at top level?  E.g., with point on, say, `defface' in
   this sexp, why shouldn't `C-M-x' redefine the face?

   (when twillig-&-the-tithy-toves-do-tyre-&-timble-in-the-twabe
     (defface ...))

   Currently, in order to make `C-M-x' work for such a "defun" I temporarily
   move its first line to column 1 and then hit `C-M-x'.  Seems like a silly
   workaround, but I don't know of a better one.  Am I missing something?

In the example above, the outermost form is a conditional expression,
and the definition is internal.  What if you have:

 (when CONDITION
   (deffoo NAME (if CONDITION
                    (defbar NAME VALUE)
                  (defbaz NAME VALUE))))

?  Then, getting ‘C-M-x’ to Do What You Mean when point is "inside
somewhere" is challenged by the multiple definitions.  Better to move
point to some place and be explicit.  That's what ‘C-x C-e’ is for.

That's the deriving answer.  The authoritarian answer is that "defun"
has a specific meaning (form w/ open-paren in column 0).  The cavalier
answer is that "maybe someone already asked this on help-gnu-emacs
one or two decades ago, hint hint".  [insert long-nosed mockup, here :-]

RE: Why is `C-M-x' only for top-level defuns?

[Drew Adams]

>  (when CONDITION
>    (deffoo NAME (if CONDITION
>                     (defbar NAME VALUE)
>                   (defbaz NAME VALUE))))
> 
> Then, getting 'C-M-x' to Do What You Mean when point is "inside
> somewhere" is challenged by the multiple definitions.  Better to move
> point to some place and be explicit.  That's what 'C-x C-e' is for.

1. I haven't thought about redesigning it.  There might indeed be other things
to consider.

2. Offhand, I'd say why not let `C-M-x' always act on the innermost defface,
defcustom etc. containing point?  That would be clear to users and presumably
straightforward to implement.

3. That would mean that if you wanted to eval a top-level sexp containing a def*
you would need to place point outside the def*.  In this I agree with you that
"it is better to move point somewhere and be explicit."  Put point inside the
form you want and outside any subform you do not want.

4. That's _not_ what `C-x C-e' is for, AFAIK.  It does not re-eval an existing
face's definition etc.  AFAIK, the only way to get re-eval a defface etc. after
changing its code is to use `C-M-x'.

> That's the deriving answer.  The authoritarian answer is that "defun"
> has a specific meaning (form w/ open-paren in column 0).

Well, yes.  For some purposes (e.g. `beginning-of-defun') that makes sense.  But
does that column limitation make sense also for `C-M-x'?  That's the question.

("Top-level" defun is really not the same thing as having its open paren in
column 0.  I'm glad that by default the actual criterion used is column 0 and
not truly top-level.  If that were not the case then the workaround of
temporarily moving a non top-level defface to column 0 and hitting `C-M-x' would
not work.)

BTW, does option `open-paren-in-column-0-is-defun-start' work?  I cannot see any
difference if I set it to nil.  What's a good recipe to show what it does?  I
was expecting that with a nil value `C-M-x' etc. would actually require a
defface etc. to be top-level in the buffer, not just starting in column 0, in
order for it to be redefined.

> The cavalier answer is that "maybe someone already asked this
> on help-gnu-emacs one or two decades ago, hint hint".  [insert
> long-nosed mockup, here :-]

Dunno what you mean.  Did I ask that decades ago?  Could be.  What was the
answer? ;-)

Re: Why is `C-M-x' only for top-level defuns?

[Juri Linkov]

> (when twillig-&-the-tithy-toves-do-tyre-&-timble-in-the-twabe
>   (defface ...))
>
> Currently, in order to make `C-M-x' work for such a "defun" I temporarily move
> its first line to column 1 and then hit `C-M-x'.  Seems like a silly workaround,
> but I don't know of a better one.

Without editing the buffer, you could narrow to the inner expression
with e.g. `C-M-SPC C-x n n' and use `C-M-x'.

But then you might ask why `C-x n d' (`narrow-to-defun') narrows to the
top-level expression, and not to the innermost defface, defcustom etc. ;-)

RE: Why is `C-M-x' only for top-level defuns?

[Drew Adams]

> > (when twillig-&-the-tithy-toves-do-tyre-&-timble-in-the-twabe
> >   (defface ...))
> >
> > Currently, in order to make `C-M-x' work for such a "defun" 
> > I temporarily move its first line to column 1 and then hit `C-M-x'.
> > Seems like a silly workaround, but I don't know of a better one.
> 
> Without editing the buffer, you could narrow to the inner expression
> with e.g. `C-M-SPC C-x n n' and use `C-M-x'.

Sure, but that's about as long as the other workaround, especially considering
following it with `C-x n w'.

I don't mind using a workaround if there's a good reason why `C-M-x' does what
it does and it shouldn't be changed.

> But then you might ask why `C-x n d' (`narrow-to-defun') 
> narrows to the top-level expression, and not to the innermost defface, 
> defcustom etc. ;-)

No, but I suppose it too could be asked.

My question is whether we really want `C-M-x' to do what it does instead of just
pick up the innermost def* containing point.

And why it does the former.  If there's a good reason, I'd like to know it.

Re: Why is `C-M-x' only for top-level defuns?

[Stefan Monnier]

> My question is whether we really want `C-M-x' to do what it does
> instead of just pick up the innermost def* containing point.

One problem is to define what is "the innermost def* containing point".
I suspect it's difficult to formally define it in a way that always
corresponds to the intuitive meaning.


        Stefan

Re: Why is `C-M-x' only for top-level defuns?

[Daniel Colascione]

[-- Attachment #1: Type: text/plain, Size: 480 bytes --]

On 1/11/12 5:27 PM, Stefan Monnier wrote:
>> My question is whether we really want `C-M-x' to do what it does
>> instead of just pick up the innermost def* containing point.
> 
> One problem is to define what is "the innermost def* containing point".
> I suspect it's difficult to formally define it in a way that always
> corresponds to the intuitive meaning.

Right. Consider:

(unless (featurep 'deffoo)
  (defmacro deffoo (bar)
    `(defun ,bar () POINT)))




[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 235 bytes --]

RE: Why is `C-M-x' only for top-level defuns?

[Drew Adams]

> >> My question is whether we really want `C-M-x' to do what it does
> >> instead of just pick up the innermost def* containing point.
> > 
> > One problem is to define what is "the innermost def* 
> > containing point".  I suspect it's difficult to formally
> > define it in a way that always corresponds to the intuitive
> > meaning.
> 
> Right. Consider:
> (unless (featurep 'deffoo)
>   (defmacro deffoo (bar)
>     `(defun ,bar () POINT)))

I did not literally mean "def*".  I was trying to abbreviate the definitions
that are treated specially by `C-M-x' (as opposed to, say, `C-x C-e').

I was thinking, in particular, of defface, defvar, and defcustom.  Perhaps there
are additional forms for which `C-M-x' does something special (redefines)
currently, but those are the ones I'm aware of and was thinking of.

But not defun or defmacro, because `C-M-x' does nothing special for them.  They
are always redefined whenever they are re-evaluated in any manner.  Not so,
defface, defvar, and defcustom.

For defface, defvar, and defcustom, AFAIK, only `C-M-x' redefines the face or
variable - `C-x C-e' or `eval-region' does not.  The idea is to get this special
redefining behavior of `C-M-x' without a workaround when the defining form does
not happen to start in column 0.

As for code that generates code (as in your example, but with the `defun' form
replaced by a `defface' form), I wouldn't have a problem with `C-M-x' trying to
evaluate and redefine it, if that's what the users asked for.  That would in
some cases raise an error (e.g. embedded `,' or `,@'), but that's not a problem,
IMO.  The user would be in control (it's on demand, the user positions point,
etc.).

It does not really need to be the key sequence `C-M-x' that provides this
feature, if there is some good reason why what `C-M-x' does now is preferred
(still asking that question - no answer so far).  My thought is that it would be
convenient to have some key for this; that's all.

Stefan might be right that it would be difficult to get right - dunno.  Off the
top of my head, however, I'd guess that just going `uplist' from point till
finding `defface', `defcustom', or `defvar' as the car might be good enough.

That doesn't mean that all such contexts would necessarily be valid face or var
definitions.  But again, this is interactive and visible.  The user would be in
control, asking for it with point where it is etc.  You would get what you ask
for.

Re: Why is `C-M-x' only for top-level defuns?

[Stefan Monnier]

> Stefan might be right that it would be difficult to get right - dunno.
> Off the top of my head, however, I'd guess that just going `uplist'
> from point till finding `defface', `defcustom', or `defvar' as the car
> might be good enough.

C-M-x differs from C-x C-e in two aspects:
1- it "guesses" which sexp is meant.
2- it handles defface/defvar/defcustom specially.
IIUC you're only worried about the first partt o the extent that it
prevents you from getting to the second.  I.e. what you're after is
a way to get (2) of C-M-x for sexps where (1) currently fails.

I'm not very much in fa vor of trying to make (1) smarter because it
will make it less uniform.  So we could maybe provide a new command
half-way between C-x C-e and C-M-x, or maybe change (1) so that it uses
the region if active.


        Stefan

Re: Why is `C-M-x' only for top-level defuns?

[Daniel Colascione]

[-- Attachment #1: Type: text/plain, Size: 1148 bytes --]

On 1/11/12 8:05 PM, Stefan Monnier wrote:
>> Stefan might be right that it would be difficult to get right - dunno.
>> Off the top of my head, however, I'd guess that just going `uplist'
>> from point till finding `defface', `defcustom', or `defvar' as the car
>> might be good enough.
> 
> C-M-x differs from C-x C-e in two aspects:
> 1- it "guesses" which sexp is meant.
> 2- it handles defface/defvar/defcustom specially.
> IIUC you're only worried about the first partt o the extent that it
> prevents you from getting to the second.  I.e. what you're after is
> a way to get (2) of C-M-x for sexps where (1) currently fails.

What about replacing 2 with something like this? (Untested)

=== modified file 'src/eval.c'
--- src/eval.c	2011-12-04 15:46:07 +0000
+++ src/eval.c	2012-01-12 04:12:30 +0000
@@ -827,7 +827,7 @@
 		   SDATA (SYMBOL_NAME (sym)));
 	}

-      if (NILP (tem))
+      if (NILP (tem) || EQ (Vthis_command, Qeval_defun))
 	Fset_default (sym, eval_sub (Fcar (tail)));
       else
 	{ /* Check if there is really a global binding rather than just a let

and similarly for defface and defcustom.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 235 bytes --]

Why is `C-M-x' only for top-level defuns?

[Stephen J. Turnbull]

Drew Adams writes:

 > Why not let `C-M-x' re-evaluate a "defun" (defcustom, defface,
 > etc.) that is not necessarily at top level?  E.g., with point on,
 > say, `defface' in this sexp, why shouldn't `C-M-x' redefine the
 > face?

I don't see any reason in the `when' you're talking about, but in many
cases such forms will refer to let-bound variables and the like, and
the results there could be rather confusing.

Re: Why is `C-M-x' only for top-level defuns?

[Thierry Volpiatto]

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

>> Stefan might be right that it would be difficult to get right - dunno.
>> Off the top of my head, however, I'd guess that just going `uplist'
>> from point till finding `defface', `defcustom', or `defvar' as the car
>> might be good enough.
>
> C-M-x differs from C-x C-e in two aspects:
> 1- it "guesses" which sexp is meant.
> 2- it handles defface/defvar/defcustom specially.
> IIUC you're only worried about the first partt o the extent that it
> prevents you from getting to the second.  I.e. what you're after is
> a way to get (2) of C-M-x for sexps where (1) currently fails.
>
> I'm not very much in fa vor of trying to make (1) smarter because it
> will make it less uniform.  So we could maybe provide a new command
> half-way between C-x C-e and C-M-x, or maybe change (1) so that it uses
> the region if active.

With anything, you can put point in any sexp of a block an eval it.
If needed you can edit it in minibuffer to provide a result.
Here cursor is on the let sexp and i hit `C-u C-:' and then edit it to
have a value for 'a' and 'b'.

(defun foo (a b)
  -!-(let ((c (+ a b)))
    (+ a b c)))

http://tinyurl.com/739svnv

-- 
  Thierry
Get my Gnupg key:
gpg --keyserver pgp.mit.edu --recv-keys 59F29997 

Re: Why is `C-M-x' only for top-level defuns?

[Juri Linkov]

> I'm not very much in favor of trying to make (1) smarter because it
> will make it less uniform.  So we could maybe provide a new command
> half-way between C-x C-e and C-M-x, or maybe change (1) so that it uses
> the region if active.

(if (use-region-p) (eval-region (region-beginning) (region-end)) ...)
in `eval-defun' (`C-M-x') would be a nice addition since `eval-region'
has no own keybinding.

RE: Why is `C-M-x' only for top-level defuns?

[Drew Adams]

> > Off the top of my head, however, I'd guess that just going `uplist'
> > from point till finding `defface', `defcustom', or `defvar' 
> > as the car might be good enough.
> 
> C-M-x differs from C-x C-e in two aspects:
> 1- it "guesses" which sexp is meant.
> 2- it handles defface/defvar/defcustom specially.
> IIUC you're only worried about the first partt o the extent that it
> prevents you from getting to the second.  I.e. what you're after is
> a way to get (2) of C-M-x for sexps where (1) currently fails.
> 
> I'm not very much in fa vor of trying to make (1) smarter because it
> will make it less uniform.  So we could maybe provide a new command
> half-way between C-x C-e and C-M-x, or maybe change (1) so 
> that it uses the region if active.

Yes, on all accounts.  You understood correctly, and I agree that this could be
on a different key.

Needing to activate a region doesn't sound to me like a great way to distinguish
the behaviors.  But I'm probably OK with any way of providing the feature.

Another possibility could be to respect different prefix args in different ways
(edebug vs this feature).  But the simplest solution is likely having a separate
command/key.

RE: Why is `C-M-x' only for top-level defuns?

[Drew Adams]

> > I'm not very much in favor of trying to make (1) smarter because it
> > will make it less uniform.  So we could maybe provide a new command
> > half-way between C-x C-e and C-M-x, or maybe change (1) so 
> > that it uses the region if active.
> 
> (if (use-region-p) (eval-region (region-beginning) (region-end)) ...)
> in `eval-defun' (`C-M-x') would be a nice addition since `eval-region'
> has no own keybinding.

Again, this is not about `eval-region', which _does not redefine_ a face or var
that is already defined.  It's about the special behavior provided by
`eval-defun' which does redefine.

And I'm interested in a redefining command/key, not making the user activate the
region around a sub-sexp before asking for redefinition.  A command/key can find
the innermost defface etc. surrounding point without any need for the user to
first select it as the region.

RE: Why is `C-M-x' only for top-level defuns?

[Drew Adams]

>  > Why not let `C-M-x' re-evaluate a "defun" (defcustom, defface,
>  > etc.) that is not necessarily at top level?  E.g., with point on,
>  > say, `defface' in this sexp, why shouldn't `C-M-x' redefine the
>  > face?
> 
> I don't see any reason in the `when' you're talking about, but in many
> cases such forms will refer to let-bound variables and the like, and
> the results there could be rather confusing.

I already addressed that:

>> I wouldn't have a problem with `C-M-x' trying to evaluate
>> and redefine it, if that's what the users asked for. That
>> would in some cases raise an error (e.g. embedded `,' or `,@'),

or a variable let-bound outside, or any number of other things that depend on an
outer context...

>> but that's not a problem, IMO.  The user would be in control
>> (it's on demand, the user positions point, etc.).

and

>> That doesn't mean that all such contexts would necessarily be 
>> valid face or var definitions.  But again, this is interactive
>> and visible.  The user would be in control, asking for it with
>> point where it is etc.  You would get what you ask for. 

We can disagree.  I don't think it would be a problem.

RE: Why is `C-M-x' only for top-level defuns?

[Drew Adams]

> With anything, you can put point in any sexp of a block an eval it.
> If needed you can edit it in minibuffer to provide a result.
> Here cursor is on the let sexp and i hit `C-u C-:' and then edit it to
> have a value for 'a' and 'b'.
> 
> (defun foo (a b)
>   -!-(let ((c (+ a b))) (+ a b c)))

See my earlier message and my reply to Stephen T.

1. The question is not about whether there are handy ways to edit a
subexpression and evaluate it.  It's about hitting a key to redefine a face or
var, regardless of where the face or var definition is (column 0 or not). 

Mere evaluation does not _redefine_ a face or var - it does nothing to a
defface, defcustom, or defvar if the face or var has already been defined.

2. Wrt someone trying to eval (with or without redefinition) a sexp that is
incomplete because it depends on stuff outside it (e.g., `a', `b' in your
example), sure, you could edit to could complete it.

But typically for an incomplete defface, defcustom, or defvar form, the best
behavior is to let Emacs complain (error).  Typically, asking for its
eval/redefinition just represents user error.

Anyway, the question I raised is not how we might simplify editing for
evaluating a subform.  It's about having a key that redefines faces and
variables.

RE: Why is `C-M-x' only for top-level defuns?

[Drew Adams]

> Another possibility could be to respect different prefix args 
> in different ways (edebug vs this feature).  But the simplest
> solution is likely having a separate command/key.

1. It just occurred to me that edebug instrumentation is only for functions, and
the redefinition feature I'm talking about is only for faces and vars.

So presumably there would be no need to distinguish different kinds of prefix
args.  We could let a prefix arg mean to either redefine the innermost face/var
definition containing point, if any, or instrument the column-0 defun (what it
does now).

In the not-so-common context of a def(face|custom|var) that is inside a defun
that you want to instrument for edebug, the behavior of a prefix arg would
differ depending on the position of point.  Whether that case is common enough
to warrant requiring different prefix-arg values to distinguish the two, I don't
know (I doubt it).

2. Another possibility: let `C-M-x' inside a def(face|custom|var) always
redefine it (i.e., without a prefix arg).  That would mean that to make `C-M-x'
eval a sexp starting in column 0, point would need to be outside any sub-sexp
that is a def(face|custom|var).


(But I repeat that I'm OK with having a separate command/key for this, not
`C-M-x'.)

RE: Why is `C-M-x' only for top-level defuns?

[Stephen J. Turnbull]

Drew Adams writes:

 > I already addressed that:
 > 
 > >> I wouldn't have a problem with `C-M-x' trying to evaluate
 > >> and redefine it, if that's what the users asked for. That
 > >> would in some cases raise an error (e.g. embedded `,' or `,@'),
 > 
 > or a variable let-bound outside, or any number of other things that depend on an
 > outer context...
 > 
 > >> but that's not a problem, IMO.  The user would be in control
 > >> (it's on demand, the user positions point, etc.).

Well, when I say "confusing" I have in mind situations where the let
binding shadows something global.  Not that a big deal but like Stefan
I'm not a fan of making these functions too smart.

I also don't reevaluate deffaces very often; if I'm going to change a
face, I generally do it in customize (specifically for reset-to-default
which is what I would be most likely to use the facility for) or
through direct set-face-* calls.  When I'm done fiddling, it's no big
deal to change the defface itself.

I'm not saying there's anything wrong with changing the defface,
whatever works for you is fine.  Just that from my point of view it's
probably a YAGNI for most people, so why make it so smart?  Of course
you can argue that the other way (ie, "well, so why not?!"), but I
suspect that won't get past Stefan's mild opposition.

Re: Why is `C-M-x' only for top-level defuns?

[Dave Abrahams]

on Thu Jan 12 2012, "Drew Adams" <drew.adams-AT-oracle.com> wrote:

>> Another possibility could be to respect different prefix args 
>> in different ways (edebug vs this feature).  But the simplest
>> solution is likely having a separate command/key.
>
> 1. It just occurred to me that edebug instrumentation is only for functions, and
> the redefinition feature I'm talking about is only for faces and vars.
>
> So presumably there would be no need to distinguish different kinds of prefix
> args.  We could let a prefix arg mean to either redefine the innermost face/var
> definition containing point, if any, or instrument the column-0 defun (what it
> does now).
>
> In the not-so-common context of a def(face|custom|var) that is inside a defun
> that you want to instrument for edebug, the behavior of a prefix arg would
> differ depending on the position of point.  Whether that case is common enough
> to warrant requiring different prefix-arg values to distinguish the two, I don't
> know (I doubt it).
>
> 2. Another possibility: let `C-M-x' inside a def(face|custom|var) always
> redefine it (i.e., without a prefix arg).  That would mean that to make `C-M-x'
> eval a sexp starting in column 0, point would need to be outside any sub-sexp
> that is a def(face|custom|var).
>
> (But I repeat that I'm OK with having a separate command/key for this, not
> `C-M-x'.)

I just wanna say: I've always wanted the behavior Drew is proposing (for
edebug-defun, eval-defun, and xxx-defun in general) and despite the fact
that I should know better by now, I am surprised every time these
functions go all the way to the outermost sexp.

-- 
Dave Abrahams
BoostPro Computing
http://www.boostpro.com

Re: Why is `C-M-x' only for top-level defuns?

[Dave Abrahams]

on Thu Jan 12 2012, "Stephen J. Turnbull" <stephen-AT-xemacs.org> wrote:

> Drew Adams writes:
>
>  > I already addressed that:
>  > 
>  > >> I wouldn't have a problem with `C-M-x' trying to evaluate
>  > >> and redefine it, if that's what the users asked for. That
>  > >> would in some cases raise an error (e.g. embedded `,' or `,@'),
>  > 
>  > or a variable let-bound outside, or any number of other things that depend on an
>  > outer context...
>  > 
>  > >> but that's not a problem, IMO.  The user would be in control
>  > >> (it's on demand, the user positions point, etc.).
>
> Well, when I say "confusing" I have in mind situations where the let
> binding shadows something global.  Not that a big deal but like Stefan
> I'm not a fan of making these functions too smart.

In terms of surprise and consistency, I think we're far better off with
the other behavior.  I'm thinking of:

(let ((...))
   (load-library "xxx")) ; <--- defuns in here are don't see the bindings.


-- 
Dave Abrahams
BoostPro Computing
http://www.boostpro.com