From: Alan Mackenzie <acm@muc.de>
To: Miles Bader <miles@gnu.org>, Stefan Monnier <monnier@iro.umontreal.ca>
Cc: emacs-devel@gnu.org
Subject: end-of-defun is fubsr. [Was: end-of-defun acts weirdly in c-mode]
Date: Tue, 3 Feb 2009 16:09:42 +0000 [thread overview]
Message-ID: <20090203160941.GE1396@muc.de> (raw)
In-Reply-To: <20090203130028.GD1396@muc.de>
[bug-cc-mode@gnu.org removed from the Cc:.]
Hi, Miles and Stefan!
On Tue, Feb 03, 2009 at 01:00:28PM +0000, Alan Mackenzie wrote:
> On Tue, Feb 03, 2009 at 12:29:06PM +0000, Alan Mackenzie wrote:
> > 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.
(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 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.
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.
It is IMAO a Bad Thing that \(beginning\|end\)-of-defun-function don't
have the same meaning modulo direction of travel.
I propose the following changes:
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.
2/- \(beginning\|end\)-of-defun-function should be trusted to do their
jobs. These jobs should be defined to include moving to the next blank
line, to BOL, or over comments, and suchlike, as appropriate to the
major mode. \(beginning\|end\)-of-defun should not tamper with the
position at all.
3/- end-of-defun should be restructured along the lines of
beginning-of-defun.
Alternatively, as a quick kludge, C-M-[ae] should be bound again to
c-\(beginning\|end\)-of-defun so as to make them work properly again.
--
Alan Mackenzie (Nuremberg, Germany).
next prev parent reply other threads:[~2009-02-03 16:09 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 ` Alan Mackenzie [this message]
2009-02-03 15:56 ` end-of-defun is fubsr. [Was: end-of-defun acts weirdly in c-mode] 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
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=20090203160941.GE1396@muc.de \
--to=acm@muc.de \
--cc=emacs-devel@gnu.org \
--cc=miles@gnu.org \
--cc=monnier@iro.umontreal.ca \
/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.