[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 15:50:36 -0500 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/23.0.60 (gnu/linux) |
>> It should only move from "right after the closing }" to BOL 7.
>> Not "an arbitrary amount of whitespace". Of course, there might be
> Sorry, yes, I was wrong. It moves at most one line forward.
Yes, the code should be fixed to only move one line forward if it's
necessary (i.e. if we're not yet at a line beginning).
>> This might be linked to the above problem. For Elisp it seems to
>> work correctly.
I don't see this problem (actually in my tests, it seems to work fine
in C mode as well). Can you provide a test case.
> The problem is that end-of-defun calls beginning-of-defun-raw at each
> iteration (over ARG). It thus discards the information as to whether
> point began in a defun or between 2 defuns.
I don't think so. Quite the opposite: it uses BOD and EOD to figure out
whether we started inside a defun or between two defuns.
Unless by "the problem" you're talking about the performance problem, in
which case I understand that each time we call BOD (except for the first
call), we know that we're "outside" of a defun (unless there's nesting,
of course) but we don't tell that to BOD which may have to redo the work
of figuring it out.
> What's bugging the Hades out of me is that I've put a LOT of effort into
> optimising c-\(beginning\|end\)-of-defun, and that's being rendered
> completely useless, at least for C-M-e, by an inept way of calling these
> functions. Several bug reports which made this work necessary came
> directly from Emacs Developers (for example, C-x 4 a taking a minute to
> run, or hassle with potential K&R regions taking just as long).
None of the above invloved EOD as far as I can tell. These all do
a single call to BOD.
> Surely there's nobody here who isn't sick and fed up with this defun
> movement business? Surely to goodness, after 25 years, we should be able
> to do major-mode specific defun movement as a matter of course?
Yes, it worked fine and fast in Emacs-21. I wasn't the one who insisted
that we should scan the whole buffer just in order to make sure that
we're not bumping into the super-rare case of K&R declaration.
I'd *much* rather that C-mode's BOD gets it wrong every blue moon,
rather than the current "let's parse the whole damn thing".
On my 800MHz machine, C-mode is often borderline unusable nowadays.
And it's not the fault of end-of-defun.
> It's changed from "move to next end of function" to "move to the end of
> the function at whose beginning we now are",
Right. As you may notice, the second is a subset of the first (with
a few caveats for nested functions, of course, but that shouldn't matter
for C-mode), so if your implementation works for the first, it should
work for the second as well. It's called backward compatibility.
> and its default value is `forward-sexp'. `c-end-of-defun' was a good
> fit for the variable as it formerly was, but is now
> severely suboptimal.
At most by a factor of 2. I.e. if it's slow now, it sure wasn't
zippy before.
>> 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).
> :-) Let's do it!
I knew you'd like it.
>> > 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.
> Don't follow - In the upcoming CC Mode 5.32 code (in the CVS repository
> at SourceForge), C-M-[ae] works just fine for C++ defuns nested inside
> classes/namespaces and so on. The mechanism is entirely within CC Mode.
Yes, but I maintain Emacs, not CC-mode, so I care to move the
functionality to the generic code so that all modes (not just CC-modes)
benefit.
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, 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, 2009/02/03
- Re: end-of-defun is fubsr., Alan Mackenzie, 2009/02/03
- 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/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
- Re: end-of-defun is fubsr., Stefan Monnier, 2009/02/13
- Re: end-of-defun is fubsr., Alan Mackenzie, 2009/02/13