emacs-devel
[Top][All Lists]
Advanced

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

Re: CC Mode 5.31.3


From: Alan Mackenzie
Subject: Re: CC Mode 5.31.3
Date: Fri, 24 Feb 2006 22:04:03 +0000 (GMT)


On Fri, 24 Feb 2006, Sean O'Rourke wrote:

>Alan Mackenzie <address@hidden> writes:
>> As agreed with RMS, C-M-[ae] should be be bound to
>> c-\(beginning\|end\)-of-defun by default, rather than the standard
>> commands \(beginning\|end\)-of-defun.  These two CC Mode commands could
>> do with some optimisation, but this seems optional rather than necessary.
>> This is still to do.  However, it is trivial, involving only drudge work,
>> mostly in the manual.  It should be there in 5.31.4.

>Have you thought instead of mode-locally setting
>{beginning,end}-of-defun-function?  This way, other commands like
>mark-defun that operate on functions automatically pick up the
>language-specific versions.

\(beginning\|end\)-of-defun-function can't get a prefix argument.  In
Emacs 22, this is mitigated by calling the function in a loop.  However,
in other (X)Emacsen, the numeric argument is simply discarded, so to use
[be]-o-d-f would mean testing for the existence of this loop, then
binding key sequences one of two ways.  It's doable, but it's hassle.

The other problem is that the opportunity for optimisation would go out
the window: c-beginning-of-defun essentially moves back to the outermost
brace (very rapid operation) then gropes backwards to the start of the
function header (slow operation involving lengthy analysis).  The easiest
optimisation with (c-beginning-of-defun 10) involves skipping back 10
brace blocks and only then finding the start of the header.

C-M-h isn't a problem in CC Mode, because it's bound to c-mark-function.
However, if mark-defun is called from a lisp function, that would be a
problem.  Hmmm.  Surely I should be setting
\(beginning\|end\)-of-defun-function AS WELL AS (not instead of) binding
C-M-[aeh]?

>I have been using this setting for
>about a year without any problems after making the attached
>trivial patch, which prevents infinite recursion when
>beginning-of-defun-function itself calls beginning-of-defun.

Hee hee!  Good point.  I think your patch should be installed right now.

Index: lisp.el
===================================================================
RCS file: /cvsroot/emacs/emacs/lisp/emacs-lisp/lisp.el,v
retrieving revision 1.74
diff -p -u -w -u -r1.74 lisp.el
--- lisp.el     6 Feb 2006 12:20:06 -0000       1.74
+++ lisp.el     24 Feb 2006 18:44:26 -0000
@@ -210,12 +210,14 @@ If variable `beginning-of-defun-function
 is called as a function to find the defun's beginning."
   (interactive "p")
   (if beginning-of-defun-function
+      (let ((bodf beginning-of-defun-function)
+            (beginning-of-defun-function nil))
       (if (> (setq arg (or arg 1)) 0)
          (dotimes (i arg)
-           (funcall beginning-of-defun-function))
+              (funcall bodf))
        ;; Better not call end-of-defun-function directly, in case
        ;; it's not defined.
-       (end-of-defun (- arg)))
+            (end-of-defun (- arg))))
     (and arg (< arg 0) (not (eobp)) (forward-char 1))
     (and (re-search-backward (if defun-prompt-regexp
                                 (concat (if 
open-paren-in-column-0-is-defun-start
@@ -255,12 +257,14 @@ is called as a function to find the defu
       (push-mark))
   (if (or (null arg) (= arg 0)) (setq arg 1))
   (if end-of-defun-function
+      (let ((eodf end-of-defun-function)
+            (end-of-defun-function nil))
       (if (> arg 0)
          (dotimes (i arg)
-           (funcall end-of-defun-function))
+              (funcall eodf))
        ;; Better not call beginning-of-defun-function
        ;; directly, in case it's not defined.
-       (beginning-of-defun (- arg)))
+            (beginning-of-defun (- arg))))
     (let ((first t))
       (while (and (> arg 0) (< (point) (point-max)))
        (let ((pos (point)))

-- 
Alan Mackenzie (Munich, Germany)






reply via email to

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