[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: end-of-defun is fubsr.
From: |
Stefan Monnier |
Subject: |
Re: end-of-defun is fubsr. |
Date: |
Tue, 03 Feb 2009 12:13:19 -0500 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/23.0.60 (gnu/linux) |
>> > It's occurred to me that my "CVS" version wasn't actually clean. Sorry
>> > for not checking this first. I've downloaded a fresh copy of the CVS,
>> > and I'm building it at the moment.
>> Built. Yes, I get the same thing as you, now. Sorry for messing you
>> around. I'll look into it.
> end-of-defun (in .../lisp/emacs-lisp/lisp.el) is buggy, at least when an
> end-of-defun-function has been defined:
> (i) After calling end-of-defun-function, e-o-d takes it upon itself to
> advance an arbitrary amount of whitespace/comments. This is what you
> (Miles) were complaining about.
It should only move from "right after the closing }" to BOL 7.
Not "an arbitrary amount of whitespace". Of course, there might be
a bug, but my guess is that your end-of-defun-function jumpts to BOL
7 rather than right after the brace. So the problem is a disagreement
between the two.
> (ii) When point is BETWEEN two C functions (more precisely JUST AFTER
> the end of the previous function), C-M-e doesn't move over the next
> function. This is because it gets its knickers in a twist, first
> calling BOD-raw, then EOD-function, trying to check if its succeeded
> yet, etc. ......... This is crazy!
This might be linked to the above problem. For Elisp it seems to
work correctly.
> This mechanism is entirely unsuited to CC Mode.
> c-\(beginning\|end\)-of-defun have a very high setup (determining
> whether point is within a function's block, or header, etc.) and tear
> down (locating the start of a function's header) time, but is lightening
> fast zipping through brace blocks in between. This high setup/teardown
> time has been the cause of several "it's too slow" bugs (e.g. for C-x 4
> a) in the last few years.
> The current implementation of end-of-defun is essentially calling
> c-end-of-defun AND c-beginning-of-defun in a loop, sometimes calling
> them twice in each iteration. This is slow for large ARG. It's crazy!
> To see this, go into buffer.c, and do
> C-u 106 C-M-e
> . On my box, this takes 20s. By contrast, C-u 106 C-M-a takes about
> 0.5s.
I don't consider "C-u 106 C-M-e" as a common operation.
> Also, the semantics of end-of-defun-function have been completely
> changed (specifically, in lisp.el v1.82, 2007-11-26) so that it now has
> only a coincidental connection with what its name suggests.
Huh? It hasn't completely changed. Some details have changed to make
it easier to implement a simple end-of-defun-function, while making sure
that end-of-defun behaves consistently.
It was mostly a matter of fixing end-of-defun which was completely broken when
passed negative arguments.
> 1/- end-of-defun-function should be restored to its prior semantics, and
> additionally be passed the ARG argument in the same way as BOD-function.
Not sure about restoring the previous semantics. But I could agree to
the additional ARG argument, which could even let it "take over" (so
beginning-of-defun-raw is not called in that case).
> 3/- end-of-defun should be restructured along the lines of
> beginning-of-defun.
I don't think that's a good idea. The main reason is to deal with
languages that allow nested functions.
Stefan
- Re: end-of-defun acts weirdly in c-mode; also, mark-defun in c-mode, (continued)
- Re: end-of-defun acts weirdly in c-mode; also, mark-defun in c-mode, Miles Bader, 2009/02/03
- Re: end-of-defun acts weirdly in c-mode; also, mark-defun in c-mode, Alan Mackenzie, 2009/02/03
- Re: end-of-defun acts weirdly in c-mode; also, mark-defun in c-mode, Alan Mackenzie, 2009/02/03
- end-of-defun is fubsr. [Was: end-of-defun acts weirdly in c-mode], Alan Mackenzie, 2009/02/03
- Re: end-of-defun is fubsr. [Was: end-of-defun acts weirdly in c-mode], Juanma Barranquero, 2009/02/03
- Re: end-of-defun is fubsr. [Was: end-of-defun acts weirdly in c-mode], Alan Mackenzie, 2009/02/03
- Re: end-of-defun is fubsr., Chong Yidong, 2009/02/03
- Re: end-of-defun is fubsr., Andreas Roehler, 2009/02/03
- Re: end-of-defun is fubsr., Alan Mackenzie, 2009/02/04
- Re: end-of-defun is fubsr., Andreas Roehler, 2009/02/04
- Re: end-of-defun is fubsr.,
Stefan Monnier <=
- Re: end-of-defun is fubsr., Alan Mackenzie, 2009/02/03
- Re: end-of-defun is fubsr., Stefan Monnier, 2009/02/03
- Re: end-of-defun is fubsr., Alan Mackenzie, 2009/02/03
- Re: end-of-defun is fubsr., Stefan Monnier, 2009/02/03
- Re: end-of-defun is fubsr., Alan Mackenzie, 2009/02/04
- Re: end-of-defun is fubsr., Stefan Monnier, 2009/02/04
- Re: end-of-defun is fubsr., Alan Mackenzie, 2009/02/04
- Re: end-of-defun is fubsr., Andreas Roehler, 2009/02/05
- Re: end-of-defun is fubsr., Stefan Monnier, 2009/02/12
- Re: end-of-defun is fubsr., Alan Mackenzie, 2009/02/13