Re: end-of-defun is fubsr.

[Stefan Monnier]

>> 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