bug#2379: [PATCH?] lisp.el: beginning-of-defun

bug#2379: [PATCH?] lisp.el: beginning-of-defun

[Aaron S. Hawley]

There's some strange programming style in `beginning-of-defun-raw' for
Emacs 22.2, perhaps this is what was meant by the use of this `progn'
syntax?

--- lisp.el	18 Feb 2009 20:56:29 -0500	1.79.2.3
+++ lisp.el	18 Feb 2009 21:07:49 -0500	
@@ -234,7 +234,7 @@
 					 "\\(?:" defun-prompt-regexp "\\)\\s(")
 			       "^\\s(")
 			     nil 'move arg)
-	 (progn (goto-char (1- (match-end 0)))) t))
+	 (progn (goto-char (1- (match-end 0))) t)))

    ;; If open-paren-in-column-0-is-defun-start and defun-prompt-regexp
    ;; are both nil, column 0 has no significance - so scan forward

If not, then this is what it probably should be:

--- lisp.el	18 Feb 2009 20:56:29 -0500	1.79.2.3
+++ lisp.el	18 Feb 2009 21:10:21 -0500	
@@ -234,7 +234,7 @@
 					 "\\(?:" defun-prompt-regexp "\\)\\s(")
 			       "^\\s(")
 			     nil 'move arg)
-	 (progn (goto-char (1- (match-end 0)))) t))
+	 (goto-char (1- (match-end 0)))))

    ;; If open-paren-in-column-0-is-defun-start and defun-prompt-regexp
    ;; are both nil, column 0 has no significance - so scan forward

Then, once that is figured out, why doesn't `beginning-of-defun'
manage zero arguments like many of the movement commands do?  Running
C-0 C-M-a seems to run `beginning-of-line' regardless.  That's an easy
fix with this patch:

--- lisp.el	18 Feb 2009 20:56:29 -0500	1.79.2.3
+++ lisp.el	18 Feb 2009 21:25:05 -0500	
@@ -204,7 +204,7 @@
       (and transient-mark-mode mark-active)
       (push-mark))
   (and (beginning-of-defun-raw arg)
-       (progn (beginning-of-line) t)))
+       (progn (if (and (integerp arg) (/= arg 0)) (beginning-of-line)) t)))

 (defun beginning-of-defun-raw (&optional arg)
   "Move point to the character that starts a defun.

But then, `beginning-of-defun-raw' seems to run (forward-char -1).
That requires this patch.


--- lisp.el	18 Feb 2009 20:56:29 -0500	1.79.2.3
+++ lisp.el	18 Feb 2009 21:28:22 -0500	
@@ -234,7 +234,7 @@
 					 "\\(?:" defun-prompt-regexp "\\)\\s(")
 			       "^\\s(")
 			     nil 'move arg)
-	 (progn (goto-char (1- (match-end 0)))) t))
+	 (progn (or (zerop arg) (goto-char (1- (match-end 0))))) t))

    ;; If open-paren-in-column-0-is-defun-start and defun-prompt-regexp
    ;; are both nil, column 0 has no significance - so scan forward

That's my best look at the situation.

Support for a zero argument in these functions is important for
situations where you want to be programmatic with
`beginning-of-defun',   Can this be fixed?

Thanks,
/a

bug#2379: [PATCH?] lisp.el: beginning-of-defun

[Stefan Monnier]

> There's some strange programming style in `beginning-of-defun-raw' for
> Emacs 22.2, perhaps this is what was meant by the use of this `progn'
> syntax?

> -	 (progn (goto-char (1- (match-end 0)))) t))
> +	 (progn (goto-char (1- (match-end 0))) t)))

I think that was the intention.  Note that it turns out that the two
forms are equivalent in this context (because goto-char never returns
nil).

> Then, once that is figured out, why doesn't `beginning-of-defun'
> manage zero arguments like many of the movement commands do?

I'd rather not touch its behavior for 0.  Basically, it should never be
called with a 0 argument (see below).

> Support for a zero argument in these functions is important for
> situations where you want to be programmatic with
> `beginning-of-defun',   Can this be fixed?

AFAICT, proper support for 0 would require a serious rethink of BOD's
semantics: currently if you're inside defun number N, then (BOD i) moves
to (N-(i-1)) is i is positive and to (N-i) if i is negative.  I.e. it
moves to N if i=1 and to N+1 if i=-1, so where should 0 move to: there
is no other defun between those two.


        Stefan

bug#2379: [PATCH?] lisp.el: beginning-of-defun

[Aaron S. Hawley]

Hey Stefan.  Thanks for the reply.

>> -      (progn (goto-char (1- (match-end 0)))) t))
>> +      (progn (goto-char (1- (match-end 0))) t)))
>
> I think that was the intention.  Note that it turns out that the two
> forms are equivalent in this context (because goto-char never returns
> nil).

Yes, I had noticed sloppy programming got lucky.

> AFAICT, proper support for 0 would require a serious rethink of BOD's
> semantics: currently if you're inside defun number N, then (BOD i) moves
> to (N-(i-1)) is i is positive and to (N-i) if i is negative.  I.e. it
> moves to N if i=1 and to N+1 if i=-1, so where should 0 move to: there
> is no other defun between those two.

Fair enough.

I notice that C-0 M-x end-of-defun is the same as just regular M-x
end-of-defun.  Also, It's worth citing beginning-of-line's behavior
here, since it departs by moving in the oppisite direction --  N-1+i.

Anyway, I'm just surprised this critical code for Lisp support is this sloppy.

Cheers,
/a

bug#2379: [PATCH?] lisp.el: beginning-of-defun

[Stefan Monnier]

>> AFAICT, proper support for 0 would require a serious rethink of BOD's
>> semantics: currently if you're inside defun number N, then (BOD i) moves
>> to (N-(i-1)) is i is positive and to (N-i) if i is negative.  I.e. it
>> moves to N if i=1 and to N+1 if i=-1, so where should 0 move to: there
>> is no other defun between those two.

> Fair enough.

> I notice that C-0 M-x end-of-defun is the same as just regular M-x
> end-of-defun.

Yes, I also noticed it when I rewrite end-of-defun, but just as is the
case for BOD, making it to "TRT" for 0 would require more significant
changes I think.  So I figured I may as well preserve the old broken
behavior rather than change it to some other broken behavior.

> Also, It's worth citing beginning-of-line's behavior
> here, since it departs by moving in the opposite direction --  N-1+i.
> Anyway, I'm just surprised this critical code for Lisp support is
> this sloppy.

We're all surprised.  But remember: Emacs is mostly made up of
"sloppy" code.  And there's a good reaon for that: it's often very
difficult to figure out what is "the right behavior", so the first
implementations just do an approximate job, which gets somewhat refined
over time, but backward compatibility means that it often can't be
refined to the point of being correct.


        Stefan