bug#17247: 24.4.50; end-of-defun bug in elisp

[Andreas Röhler]

On 20.05.2014 06:01, Dmitry Gutov wrote:
> Andreas Röhler <andreas.roehler@easy-emacs.de> writes:
>
> > May confirm that for 24.3.90.1-pretest
> >
> > Looks like line 407
> >
> >          (beginning-of-defun-raw (- arg))
> >
> > must read
> >
> >   (beginning-of-defun-raw (abs arg))
> >
> > because it's already decided at that point going backward, so the arg must be positiv for 
> > a "beginning-..."
> > function.
>
> `arg' is negative in that clause, so (abs arg) is the same as (- arg).
> Haven't you tried your suggestion?

Just had a look into the code, my mistake, sorry.

> Anyway, the patch below seems to work fine.
 Not sure what the purpose of
> `end-of-line' was there.

AFAIU the purpose is to make sure the beginning of current defun is fetched, 
not the previous one, i.e. protect for cases, point is at the beginning of 
defun.
From there some doubts... untested :)

> === modified file 'lisp/emacs-lisp/lisp.el'
> --- lisp/emacs-lisp/lisp.el     2014-02-26 02:31:27 +0000
> +++ lisp/emacs-lisp/lisp.el     2014-05-20 03:58:27 +0000
> @@ -373,7 +373,7 @@
>         (push-mark))
>     (if (or (null arg) (= arg 0)) (setq arg 1))
>     (let ((pos (point))
> -        (beg (progn (end-of-line 1) (beginning-of-defun-raw 1) (point))))
> +        (beg (progn (beginning-of-defun-raw 1) (point))))
>       (funcall end-of-defun-function)
>       ;; When comparing point against pos, we want to consider that if
>       ;; point was right after the end of the function, it's still

IMHO that end-of-defun section  is over-engineered, thus bug-sourcing.

For example the common design-logic when taking numeric arguments: with positiv 
go forward, with negativ backward, resp. negate assumed direction.

This seems broken internally by (funcall end-of-defun-function), which doesn't 
care for arguments.

While later on with (cond ((> arg 0)... it takes places as to expect, but has 
to deal with the effects by previous funcall.