Is this fallout from the end-of-defun changes?

Is this fallout from the end-of-defun changes?

[Juanma Barranquero]

;;; bug.el ;;;
(defun function1 ()
  nil)

(defun function2 ()
  nil)
;;; end ;;;

Doing

  emacs -Q bug.el --eval "(progn (forward-list) (eval-defun nil))"

With 22.3              => function1
With the pretest       => function1
With the current trunk => function2

I'll file a bug report as soon as Stefan confirms that it is one (it
should, it's quite weird to be on a line of function1 and get
function2 evalled).

    Juanma

Re: Is this fallout from the end-of-defun changes?

[Stefan Monnier]

> I'll file a bug report as soon as Stefan confirms that it is one (it
> should, it's quite weird to be on a line of function1 and get
> function2 evalled).

Yes, it's a bug, of course.  I believe I've fixed it,


        Stefan

Re: Is this fallout from the end-of-defun changes?

[Juanma Barranquero]

On Thu, Feb 19, 2009 at 17:55, Stefan Monnier <monnier@iro.umontreal.ca> wrote:

> I believe I've fixed it,

Yes, thanks.

    Juanma

Re: Is this fallout from the end-of-defun changes?

[Alan Mackenzie]

Hi, Juanma,

On Thu, Feb 19, 2009 at 11:01:04AM +0100, Juanma Barranquero wrote:
> ;;; bug.el ;;;
> (defun function1 ()
>   nil)
> 
> (defun function2 ()
>   nil)
> ;;; end ;;;

> Doing

>   emacs -Q bug.el --eval "(progn (forward-list) (eval-defun nil))"

> With 22.3              => function1
> With the pretest       => function1
> With the current trunk => function2

> I'll file a bug report as soon as Stefan confirms that it is one (it
> should, it's quite weird to be on a line of function1 and get
> function2 evalled).

It appears to be a bug fix - eval-defun now does what the doc string
says (evaluate the function surrounding point, or the one after point).

For point outside a defun, the behaviour in Emacs 22 was somewhat
heuristic - compile the previous defun if point is on the same line as
that defun's closing paren, else compile the following defun, if any,
else the previous defun.  I think this is reasonable behaviour  ;-)

>     Juanma

-- 
Alan Mackenzie (Nuernberg).

Re: Is this fallout from the end-of-defun changes?

[Juanma Barranquero]

On Thu, Feb 19, 2009 at 20:57, Alan Mackenzie <acm@muc.de> wrote:

> For point outside a defun, the behaviour in Emacs 22 was somewhat
> heuristic - compile the previous defun if point is on the same line as
> that defun's closing paren, else compile the following defun, if any,
> else the previous defun.  I think this is reasonable behaviour  ;-)

I'm not sure whether you find reasonable the behavior of Emacs 22, or
the one I reported. I think the behavior in 22 is much more intuitive.

The point is moot, though, as Stefan has already fixed the issue.

    Juanma

Re: Is this fallout from the end-of-defun changes?

[Tobias C. Rittweiler]

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

>> I'll file a bug report as soon as Stefan confirms that it is one (it
>> should, it's quite weird to be on a line of function1 and get
>> function2 evalled).
>
> Yes, it's a bug, of course.  I believe I've fixed it,

That does not seem to be fixed properly:

  1

  2; point here, then C-M-x

  (defun foo () 42)

This evaluates `foo'.

GNU Emacs 23.0.91.1 (i686-pc-linux-gnu, GTK+ Version 2.12.9) of
2009-02-27 on thaleron

  -T.

Re: Is this fallout from the end-of-defun changes?

[Tobias C. Rittweiler]

"Tobias C. Rittweiler" <tcr@freebits.de> writes:

> Stefan Monnier <monnier@iro.umontreal.ca> writes:
>
> > > I'll file a bug report as soon as Stefan confirms that it is one (it
> > > should, it's quite weird to be on a line of function1 and get
> > > function2 evalled).
> >
> > Yes, it's a bug, of course.  I believe I've fixed it,
>
> That does not seem to be fixed properly:
>
>   1
>
>   2; point here, then C-M-x
>
>   (defun foo () 42)
>
> This evaluates `foo'.
>
> GNU Emacs 23.0.91.1 (i686-pc-linux-gnu, GTK+ Version 2.12.9) of
> 2009-02-27 on thaleron

This does not seem to be fixed yet. Should I report this as an Emacs bug
explicitly? It's a regression, and I'd like to see this fixed before the
release. (I do use C-M-x on variable names.)

Thanks!

  -T.

Re: Is this fallout from the end-of-defun changes?

[Stefan Monnier]

>>> I'll file a bug report as soon as Stefan confirms that it is one (it
>>> should, it's quite weird to be on a line of function1 and get
>>> function2 evalled).
>> Yes, it's a bug, of course.  I believe I've fixed it,
> That does not seem to be fixed properly:

>   1

>   2; point here, then C-M-x

>   (defun foo () 42)

> This evaluates `foo'.

Yes, same as in Emacs-22.
C-M-x presumes you're evaluating a "defun", not just a constant number.


        Stefan

Re: Is this fallout from the end-of-defun changes?

[Tobias C. Rittweiler]

Stefan Monnier <monnier@IRO.UMontreal.CA> writes:

> > That does not seem to be fixed properly:
> >
> >   1
> > 
> >   2; point here, then C-M-x
> >
> >   (defun foo () 42)
> >
> > This evaluates `foo'.
>
> Yes, same as in Emacs-22.
> C-M-x presumes you're evaluating a "defun", not just a constant number.

Please excuse me that I called this a regression then. I was tricked
that C-M-x on 1 _does_ evaluate the 1---both on 23.0.91.2 and 23.0.60.1,
but not on 22.1.1. So the behaviour did change somewhat, just not the
way I thought it was supposed to change. :-)

  -T.