Re: end-of-defun is fubsr.

[Stefan Monnier]

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