From: Stefan Monnier <monnier@iro.umontreal.ca>
To: Alan Mackenzie <acm@muc.de>
Cc: emacs-devel@gnu.org, Röhler <andreas.roehler@online.de>,
"Miles Bader" <miles@gnu.org>
Subject: Re: end-of-defun is fubsr.
Date: Wed, 04 Feb 2009 09:29:20 -0500 [thread overview]
Message-ID: <jwv63jqqopi.fsf-monnier+emacs@gnu.org> (raw)
In-Reply-To: <20090204133728.GB1049@muc.de> (Alan Mackenzie's message of "Wed, 4 Feb 2009 13:37:28 +0000")
>> > Visit src/buffer.c, goto L313 which contains the closing brace of
>> > DEFUN Fget_file_buffer, put point AFTER the "}". Or put point on the
>> > next line (L314). In either case C-M-e leaves point at BOL315.
>> Oh, so we just disagree about what is the correct behavior. As far as
>> I'm concerned, if C-M-e gets you to BOL315, that means that the end of
>> the function is BOL315, which implies that EOL313 is inside the
>> function, so it's correct for C-M-e to just move to BOL315.
> WADR, this is sophistry. Correct behaviour is to go to the end of the
> defun. In C, this is the closing }. It CAN'T be anywhere else. Take a
> straw poll of 100 C hackers and ask them. It's the place where a
> compiler would give an error message if you chop off the buffer before
> it.
> The doc string for `end-of-defun' is crystal clear here: "Move forward to
> next end of defun".
There are 2 issues:
- Should M-C-e from within that function jump to BOL315 or to EOL313?
- given that it jumps to BOL315, should C-M-e from EOL313 also jump to
BOL315 or to the end of the next function?
My reply only concerned the second question, whereas your above argument
seems to apply to the first.
>> > If one were to define a variable end-of-defun-RAW-function, which is
>> > defined to leave point just after the last bit of the function,
>> That's what end-of-defun-function should do, indeed.
> I would agree. I detest sloppy definitions, but EOD-function has been
> sloppily defined for years. I think we should accept that EOD-functions
> in existing modes DON'T all go to this ideal point, but themselves
> correct for WS.
>> > perhaps that would work, but it would break existing 3rd party code.
>> Like which code?
> Well, in my first page of 50 in a google search for
> "end-of-defun-function", I came up with these, all of which set
> end-of-defun-function:
I know such functions exist, but which ones of these are (would be) broken?
> A user option c-recognize-k&r would be the way to go, I suppose. It
> would be trivially easy to implement and would improve the performance of
> C Mode. I was thinking more of purging the K&R declarations from the
> Emacs source code. Perhaps for Emacs 24? This surely would be a forward
> step now, even if it wouldn't have been in 1990.
No need to purge them before removing C-mode support for them.
AFAIK they were not supported by Emacs-21's C-mode either (at least in
the sense that BOD/EOD always did the right thing for them).
>> If that can solve the performance issues, I'm all for it. After all,
>> Emacs-21 didn't get it right and I haven't heard significant complains
>> about it. It's not like Emacs is always expected to understand every
>> little bit of a language's syntax anyway.
> Well, we could get philosophical about this. I think that every little
> glitch which "isn't quite right" detracts from quality, and if there are
> enough such glitches, the user's impression will be of general low
> quality.
If you want to go there, you need to use the corresponding tools:
e.g. a real parser.
> Let me repeat that: THIS CHANGE WILL CAUSE EXISTING CODE TO BREAK WITH
> FUTURE IMPLEMENTATIONS OF end-of-defun-function.
Potential breakage comes with *any* change. So I'm not interested
in it. Show me actual breakage.
> It isn't slow for ARG=1, except for some ill-conditioned files (perhaps
> src/lisp.h).
regex.c is pretty painful as well.
> Somebody other than me will care about ARG > 1. She'll care a lot when
> Emacs 23 hangs for 5, 10, 20, 50 seconds. People who will use C-M-e to
> move large distances over files, for example. In Emacs-22, this is fast
> - the speed is essentially independent of ARG. Why should we slap them
> in the face when we release Emacs-23?
Check Emacs-22's code again: it also calls EOD-function ARG times.
So we're still talking just a constant factor. The fact that you don't
know that indicates that it's clearly not a big issue.
Mind you, I do agree that it might be good to solve this "ARG times
slow". I just don't think it's high on the list of things to fix.
> It won't work when point is outside a defun. And a combination of (BOD)
> and (EOD) isn't capable of reliably determining if point is outside a
> defun.
Why wouldn't it work to compare the starting position with the position
after BOD+EOD?
Stefan
next prev parent reply other threads:[~2009-02-04 14:29 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 [this message]
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=jwv63jqqopi.fsf-monnier+emacs@gnu.org \
--to=monnier@iro.umontreal.ca \
--cc=acm@muc.de \
--cc=andreas.roehler@online.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.