From: Alan Mackenzie <acm@muc.de>
To: Stefan Monnier <monnier@iro.umontreal.ca>
Cc: emacs-devel@gnu.org, Röhler <andreas.roehler@online.de>,
"Miles Bader" <miles@gnu.org>
Subject: Re: end-of-defun is fubsr.
Date: Sat, 14 Feb 2009 18:00:30 +0000 [thread overview]
Message-ID: <20090214180030.GA4679@muc.de> (raw)
In-Reply-To: <jwv1vu11wpw.fsf-monnier+emacs@gnu.org>
On Fri, Feb 13, 2009 at 11:22:48PM -0500, Stefan Monnier wrote:
> > ! This should move point to the next end of defun
> I don't think it's quite true. It should really be "the end of the
> defun at point". There might be a nearer EOD in a nested function.
Yes, there might be, and this might be the appropriate EOD. (See
below.)
OK: Maybe it should be
This should move point to the \"next\" end of defun
, where "next" is to be interpreted appropriately for the nesting
strategy in use by the major mode. For example, consider this fragment
of C++:
1 namespace baz
2 {
3 int bar = 666;
4 // <==== Do C-M-e here.
5 int foo ()
6 {
7 return bar ;
8 }
9
......
42 }
43
Suppose in C++ Mode, the strategy for C-M-[ae] with nested defuns is "go
to the lexically next one, regardless of nesting depth" (which was
Martin Stjernholm's suggestion a few years back, and it's a good one).
Then starting at L4, C-M-e should go to L9. However, (BOD-raw) will go
to L1, and "end of the defun at point" will be L43. Whoops!
"Next"'s meaning should be at the discretion of the major mode author.
> > ! and return t on success, nil on failure.
> I don't think the return result is ever used as of now. So I'd rather
> not document such a thing.
Emacs 22 and 21 end-of-defun return end-of-defun's result as
EOD-function's own return value, even if it wasn't documented. We
shouldn't change this, surely?
> > ! It should not move further forward into any whitespace or
> > ! onto the next line.
> I used slightly different wording.
I don't see the previous wording specifying this at all.
> > ! It is called with no argument.
> > ! The function can assume that point is at the beginning of a defun
> > ! body or before the first defun in the buffer.")
> I prefer to keep the reference to BOD-raw, which makes this starting
> position much more precise.
Ah, OK. But it shouldn't give the impression that the function may be
called ONLY after calling BOD-raw, and a bit less brusque than saying
"RTFS!!".
> > Another thing: in an elisp buffer, if (point-min) is in the middle of a
> > defun, C-M-e takes point to the next but one EOD. CC Mode is just as
> > bad. ;-)
> > Should end-of-defun perhaps widen the buffer around its machinations?
> Widening is not a good option, no. Rather we may want to consider what
> should happen if a file starts in the middle of a defun.
> I am not going to lose too much sleep over this.
Nah, maybe not! Anybody doing C-M-e can just get annoyed, he set the
narrrowing himself, and anybody using EOD in a program ought to widen
the buffer himself before manipulating it.
How about this, then:?
#########################################################################
(defvar end-of-defun-function #'forward-sexp
"Function for `end-of-defun' to call.
This should move point to the \"next\" end of defun. It should
not move further forward into any whitespace or onto the next
line.
It is called with no argument. Its return value will become the
return value of `end-of-defun' when called from it.
The function can assume that point is at a position where
`beginning-of-defun-raw' could have left it, typically at the
beginning of a defun body or before the first defun in the
buffer.")
#########################################################################
> Stefan
--
Alan.
next prev parent reply other threads:[~2009-02-14 18:00 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
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 [this message]
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=20090214180030.GA4679@muc.de \
--to=acm@muc.de \
--cc=andreas.roehler@online.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.