emacs-devel
[Top][All Lists]
Advanced

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

Useless change in lisp.el?


From: Andreas Röhler
Subject: Useless change in lisp.el?
Date: Sun, 25 Nov 2007 17:55:50 +0100
User-agent: KMail/1.9.5

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




reply via email to

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