[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Andreas Röhler
Subject: bug#17247: 24.4.50; end-of-defun bug in elisp
Date: Tue, 20 May 2014 09:59:05 +0200
User-agent: Mozilla/5.0 (X11; Linux i686; rv:24.0) Gecko/20100101 Icedove/24.5.0

On 20.05.2014 06:01, Dmitry Gutov wrote:
Andreas Röhler <address@hidden> writes:

May confirm that for

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-..."

`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 
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 @@
    (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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]