Useless change in lisp.el?

Useless change in lisp.el?

[Andreas Röhler]

I doubt if the change seen in

[Emacs-diffs] Changes to emacs/lisp/emacs-lisp/lisp.el,v

Changes by:Stefan Monnier <monnier>07/11/22 22:12:22

is valid. It don't add any functionality AFAIS.

As arguments given for it are wrong AFAIU, it might
lead to confusion.

+++ lisp/emacs-lisp/lisp.el22 Nov 2007 22:12:20 -00001.81
@@ -175,9 +175,10 @@
if defining `defun-prompt-regexp' is not sufficient to handle the mode's
needs.

-The function (of no args) should go to the line on which the current
-defun starts, and return non-nil, or should return nil if it can't
-find the beginning.")
+The function takes the same argument as `beginning-of-defun' and should
+behave similarly, returning non-nil if it found the beginning of a defun.
+Ideally it should move to a point right before an open-paren which encloses
+the body of the defun.")

As `beginning-of-defun-function' expressivly is
introduced for all possible function definitions, it
makes no sence to require or even to mention an open
paren. Other languages are completely free to design
function definitions. Emacs should be able to follow
them without specifying things no one may know at this
time.

Too I pointed just these days at the fact,
`beginning-of-defun' will be understood as
top-level-form here rather than strictly a
function-beginning.


(defun beginning-of-defun (&optional arg)
 "Move backward to the beginning of a defun.
@@ -218,12 +219,22 @@
 (unless arg (setq arg 1))
 (cond
  (beginning-of-defun-function
+  (condition-case nil
+    (funcall beginning-of-defun-function arg)
+   ;; We used to define beginning-of-defun-function as taking no argument
+   ;; but that makes it impossible to implement correct forward motion:
+   ;; we used to use end-of-defun for that, but it's not supposed to do
+   ;; the same thing (it moves to the end of a defun not to the beginning
+   ;; of the next).

That's not the case. As `beginning-of-defun-function'
together with `end-of-defun-function' are freely to
design, progmodes could do that at their will. See BTW
`she-beg-end.el' in source-list. Adding an `arg'
here don't touch that question.

+   ;; In case the beginning-of-defun-function uses the old calling
+   ;; convention, fallback on the old implementation.
+   (wrong-number-of-arguments
  (if (> arg 0)
(dotimes (i arg)
 (funcall beginning-of-defun-function))
   ;; Better not call end-of-defun-function directly, in case
   ;; it's not defined.
-   (end-of-defun (- arg))))
+     (end-of-defun (- arg))))))

Here an unnecessary complication comes in together with a provision for just 
that complication.

In the result we have may have two instances aiming the
same arg and extra need to look, where the argument is
set.
 
Thanks

Andreas Röhler

Re: Useless change in lisp.el?

[Stefan Monnier]

> -The function (of no args) should go to the line on which the current
> -defun starts, and return non-nil, or should return nil if it can't
> -find the beginning.")
> +The function takes the same argument as `beginning-of-defun' and should
> +behave similarly, returning non-nil if it found the beginning of a defun.
> +Ideally it should move to a point right before an open-paren which encloses
> +the body of the defun.")

> As `beginning-of-defun-function' expressivly is
> introduced for all possible function definitions, it
> makes no sence to require or even to mention an open
> paren.

Sure it does: end-of-defun does basically
"(progn (beginning-of-defun-raw) (forward-sexp)", so if
beginning-of-defun-function stops right before an "open paren",
end-of-defun will do the right thing.  Otherwise, the programmer will
have to supply his own end-of-defun-function.  Note that since
forward-sexp can be customized with forward-sexp-function, the notion of
"open paren" may include things like "begin...end".

[ Yes, I know end-of-defun currently doesn't always use forward-sexp,
  I'm working on fixing that.  ]

If you see how to improve the doc to make this more clear, patches
are welcome.

> Other languages are completely free to design function
> definitions. Emacs should be able to follow them without specifying
> things no one may know at this time.

Indeed.  I did not write that the function *must* do it, just that it
should ideally do that.

> Too I pointed just these days at the fact, `beginning-of-defun' will
> be understood as top-level-form here rather than strictly
> a function-beginning.

Agreed.  I tried to keep this in mind when writing the above text, but
again, if you see a way to make it more clear, go for it.

> +   ;; we used to use end-of-defun for that, but it's not supposed to do
> +   ;; the same thing (it moves to the end of a defun not to the beginning
> +   ;; of the next).

> That's not the case.

Yes it is: try it in elisp-mode (with enough empty lines between defuns
that the difference caqn be noticed, of course).

> As `beginning-of-defun-function' together with `end-of-defun-function'
> are freely to design, progmodes could do that at their will.

No: end-of-defun can't know that it's called by beginning-of-defun.


        Stefan

Re: Useless change in lisp.el?

[Andreas Röhler]

Am Montag, 26. November 2007 16:09 schrieben Sie:
> > -The function (of no args) should go to the line on which the current
> > -defun starts, and return non-nil, or should return nil if it can't
> > -find the beginning.")
> > +The function takes the same argument as `beginning-of-defun' and should
> > +behave similarly, returning non-nil if it found the beginning of a
> > defun. +Ideally it should move to a point right before an open-paren
> > which encloses +the body of the defun.")
> >
> > As `beginning-of-defun-function' expressivly is
> > introduced for all possible function definitions, it
> > makes no sence to require or even to mention an open
> > paren.
>
> Sure it does: end-of-defun does basically
> "(progn (beginning-of-defun-raw) (forward-sexp)", so if
> beginning-of-defun-function stops right before an "open paren",
> end-of-defun will do the right thing.  Otherwise, the programmer will
> have to supply his own end-of-defun-function.


I read here

  (and (beginning-of-defun-raw arg)
       (progn (beginning-of-line) t)))

where `beginning-of-line' would be the part in
question.  As `beginning-of-line' comes after
customized `beginning-of-defun-function' it must not be
the right thing. But that's another question.

Should you not cling to much to that disputed change
and no one else defends it, I would appreciate much 
seeing it reverted.

Andreas Röhler

> Note that since 
> forward-sexp can be customized with forward-sexp-function, the notion of
> "open paren" may include things like "begin...end".
>
> [ Yes, I know end-of-defun currently doesn't always use forward-sexp,
>   I'm working on fixing that.  ]
>
> If you see how to improve the doc to make this more clear, patches
> are welcome.
>
> > Other languages are completely free to design function
> > definitions. Emacs should be able to follow them without specifying
> > things no one may know at this time.
>
> Indeed.  I did not write that the function *must* do it, just that it
> should ideally do that.
>
> > Too I pointed just these days at the fact, `beginning-of-defun' will
> > be understood as top-level-form here rather than strictly
> > a function-beginning.
>
> Agreed.  I tried to keep this in mind when writing the above text, but
> again, if you see a way to make it more clear, go for it.
>
> > +   ;; we used to use end-of-defun for that, but it's not supposed to do
> > +   ;; the same thing (it moves to the end of a defun not to the
> > beginning +   ;; of the next).
> >
> > That's not the case.
>
> Yes it is: try it in elisp-mode (with enough empty lines between defuns
> that the difference caqn be noticed, of course).
>
> > As `beginning-of-defun-function' together with `end-of-defun-function'
> > are freely to design, progmodes could do that at their will.
>
> No: end-of-defun can't know that it's called by beginning-of-defun.
>
>
>         Stefan

Re: Useless change in lisp.el?

[Andreas Röhler]

Am Montag, 26. November 2007 19:14 schrieb Andreas Röhler:
> Am Montag, 26. November 2007 16:09 schrieben Sie:
> > > -The function (of no args) should go to the line on which the current
> > > -defun starts, and return non-nil, or should return nil if it can't
> > > -find the beginning.")
> > > +The function takes the same argument as `beginning-of-defun' and
> > > should +behave similarly, returning non-nil if it found the beginning
> > > of a defun. +Ideally it should move to a point right before an
> > > open-paren which encloses +the body of the defun.")
> > >
> > > As `beginning-of-defun-function' expressivly is
> > > introduced for all possible function definitions, it
> > > makes no sence to require or even to mention an open
> > > paren.
> >
> > Sure it does: end-of-defun does basically
> > "(progn (beginning-of-defun-raw) (forward-sexp)", so if
> > beginning-of-defun-function stops right before an "open paren",
> > end-of-defun will do the right thing.  Otherwise, the programmer will
> > have to supply his own end-of-defun-function.
>
> I read here
>
>   (and (beginning-of-defun-raw arg)
>        (progn (beginning-of-line) t)))
>
No,just see I missed your point in this question.

Anyway, it doesn't change the original case.

Andreas 

Re: Useless change in lisp.el?

[Stefan Monnier]

> Should you not cling to much to that disputed change
> and no one else defends it, I would appreciate much
> seeing it reverted.

Rather than argue abuot the change itself, just give us some use
case where the new behavior is problematic.


        Stefan

Re: Useless change in lisp.el?

[Andreas Röhler]

Am Montag, 26. November 2007 20:26 schrieb Stefan Monnier:
> > Should you not cling to much to that disputed change
> > and no one else defends it, I would appreciate much
> > seeing it reverted.
>
> Rather than argue abuot the change itself, just give us some use
> case where the new behavior is problematic.
>

Can't see any new behaviour with this change, that's
it.  AFAIU you introduced more lines of code and provision
for possible bugs not to fear before.

 ;; In case the beginning-of-defun-function uses the old calling
      ;; convention, fallback on the old implementation.
      (wrong-number-of-arguments
       (if (> arg 0)
           (dotimes (i arg)
             (funcall beginning-of-defun-function))
         ;; Better not call end-of-defun-function directly, in case
         ;; it's not defined.
         (end-of-defun (- arg))))))


Now you have the old implementation, called if
`(wrong-number-of-arguments'--what wasn't at the table
before--new implementation and the default as always:
Three instead of two items to watch.

If you want Emacs as extendable, it matters, how
the code is written. If you introduce things without
valid reason--that's my view still--it will be less readable,
people need more time to dig through.

Andreas Röhler