From: Stefan Monnier <monnier@IRO.UMontreal.CA>
To: Alan Mackenzie <acm@muc.de>
Cc: Miles Bader <miles@gnu.org>, emacs-devel@gnu.org
Subject: Re: end-of-defun is fubsr.
Date: Tue, 03 Feb 2009 15:50:36 -0500 [thread overview]
Message-ID: <jwvy6wnqnfw.fsf-monnier+emacs@gnu.org> (raw)
In-Reply-To: <20090203185812.GH1396@muc.de> (Alan Mackenzie's message of "Tue, 3 Feb 2009 18:58:12 +0000")
>> 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
next prev parent reply other threads:[~2009-02-03 20:50 UTC|newest]
Thread overview: 42+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-02-02 8:13 end-of-defun acts weirdly in c-mode; also, mark-defun in c-mode Miles Bader
2009-02-02 20:27 ` Alan Mackenzie
2009-02-02 22:46 ` Stefan Monnier
2009-02-03 9:17 ` Miles Bader
2009-02-03 10:50 ` Alan Mackenzie
2009-02-03 11:23 ` Miles Bader
2009-02-03 11:35 ` Miles Bader
2009-02-03 12:29 ` Alan Mackenzie
2009-02-03 13:00 ` Alan Mackenzie
2009-02-03 16:09 ` end-of-defun is fubsr. [Was: end-of-defun acts weirdly in c-mode] Alan Mackenzie
2009-02-03 15:56 ` Juanma Barranquero
2009-02-03 16:34 ` end-of-defun is fubsr Chong Yidong
2009-02-03 17:18 ` Andreas Roehler
2009-02-04 11:33 ` Alan Mackenzie
2009-02-04 14:54 ` Andreas Roehler
2009-02-03 16:40 ` end-of-defun is fubsr. [Was: end-of-defun acts weirdly in c-mode] Alan Mackenzie
2009-02-03 17:13 ` end-of-defun is fubsr Stefan Monnier
2009-02-03 18:58 ` Alan Mackenzie
2009-02-03 20:50 ` Stefan Monnier [this message]
2009-02-04 0:14 ` Alan Mackenzie
2009-02-04 2:21 ` Stefan Monnier
2009-02-04 13:37 ` Alan Mackenzie
2009-02-04 14:29 ` Stefan Monnier
2009-02-04 15:44 ` Alan Mackenzie
2009-02-05 10:37 ` Andreas Roehler
2009-02-12 21:35 ` Stefan Monnier
2009-02-13 11:08 ` Alan Mackenzie
2009-02-13 14:31 ` Stefan Monnier
2009-02-13 16:42 ` Alan Mackenzie
2009-02-13 17:06 ` Stefan Monnier
2009-02-13 18:57 ` Alan Mackenzie
2009-02-14 4:22 ` Stefan Monnier
2009-02-14 18:00 ` Alan Mackenzie
2009-02-14 21:16 ` Stefan Monnier
2009-02-14 23:25 ` Alan Mackenzie
2009-02-15 0:57 ` Miles Bader
2009-02-15 19:26 ` Stefan Monnier
2009-02-15 22:00 ` Alan Mackenzie
2009-02-05 11:44 ` Problems C Mode has with src/regex.c [was: end-of-defun is fubsr.] Alan Mackenzie
2009-02-05 21:50 ` end-of-defun acts weirdly in c-mode Alan Mackenzie
2009-02-06 1:03 ` Glenn Morris
2009-02-06 12:23 ` Alan Mackenzie
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=jwvy6wnqnfw.fsf-monnier+emacs@gnu.org \
--to=monnier@iro.umontreal.ca \
--cc=acm@muc.de \
--cc=emacs-devel@gnu.org \
--cc=miles@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.