From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Alan Mackenzie Newsgroups: gmane.emacs.devel Subject: Re: end-of-defun is fubsr. Date: Wed, 4 Feb 2009 15:44:27 +0000 Message-ID: <20090204154427.GD1049@muc.de> References: <20090203122906.GC1396@muc.de> <20090203130028.GD1396@muc.de> <20090203160941.GE1396@muc.de> <20090203185812.GH1396@muc.de> <20090204001445.GI1396@muc.de> <20090204133728.GB1049@muc.de> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1233762007 4392 80.91.229.12 (4 Feb 2009 15:40:07 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 4 Feb 2009 15:40:07 +0000 (UTC) Cc: emacs-devel@gnu.org, Andreas =?iso-8859-1?Q?R=F6hler?= , Miles Bader To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Feb 04 16:41:21 2009 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1LUjsM-0004As-Ix for ged-emacs-devel@m.gmane.org; Wed, 04 Feb 2009 16:41:19 +0100 Original-Received: from localhost ([127.0.0.1]:58419 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LUjr3-0001mp-LE for ged-emacs-devel@m.gmane.org; Wed, 04 Feb 2009 10:39:57 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LUjcO-0000f6-6N for emacs-devel@gnu.org; Wed, 04 Feb 2009 10:24:48 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LUjcL-0000dD-Rp for emacs-devel@gnu.org; Wed, 04 Feb 2009 10:24:47 -0500 Original-Received: from [199.232.76.173] (port=57338 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LUjcL-0000d4-JE for emacs-devel@gnu.org; Wed, 04 Feb 2009 10:24:45 -0500 Original-Received: from colin.muc.de ([193.149.48.1]:2169 helo=mail.muc.de) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1LUjcK-0006Ka-Ur for emacs-devel@gnu.org; Wed, 04 Feb 2009 10:24:45 -0500 Original-Received: (qmail 50362 invoked by uid 3782); 4 Feb 2009 15:24:42 -0000 Original-Received: from acm.muc.de (pD9E5372B.dip.t-dialin.net [217.229.55.43]) by colin2.muc.de (tmda-ofmipd) with ESMTP; Wed, 04 Feb 2009 16:24:40 +0100 Original-Received: (qmail 5179 invoked by uid 1000); 4 Feb 2009 15:44:27 -0000 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.9i X-Delivery-Agent: TMDA/1.1.5 (Fettercairn) X-Primary-Address: acm@muc.de X-detected-operating-system: by monty-python.gnu.org: FreeBSD 4.6-4.9 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:108737 Archived-At: Hi, Stefan, On Wed, Feb 04, 2009 at 09:29:20AM -0500, Stefan Monnier wrote: > >> > 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? Either EOL313 or BOL314 (was your "315" a typo?). It would be nice to be definite here, but history necessitates vagueness. > - given that it jumps to BOL315, should C-M-e from EOL313 also jump to > BOL315 or to the end of the next function? EOL313 is AT the end of the defun. C-M-e move to the NEXT EOD, therefore it MUST jump to L331/332. From a pragmatic point of view, what hacker wouldn't be aggravated by C-M-e taking him from EOL313 to BOL314? > 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? Haven't a clue, and can't be bothered to investigate. It's a fair assumption that several or many would be broken. I think the onus is on the person advocating the change to show that things are OK, rather than for opponents to show that things will definitely break. > > 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. I do want to go there, and without a real parser. Therefore I can only approach closely. > > 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. That's sophistry again, Stefan. It's true that any change risks breakage. But with most changes we make, we take care to minimise the risk of breakage. This particular change positively provokes it. And fixing any such breakage will be boring tedious drudgery, regardless of whether one of us, or J. Random Hacker has to do it. > > It isn't slow for ARG=1, except for some ill-conditioned files (perhaps > > src/lisp.h). > regex.c is pretty painful as well. OK. I'll look at that. > > 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. Sorry, you're wrong, at least as far as CC Mode is concerned. ;-) In cc-mode.el appears this: ;; (April 2006): RMS has now approved these commands as defaults. (unless (memq 'argumentative-bod-function c-emacs-features) (define-key c-mode-base-map "\e\C-a" 'c-beginning-of-defun) (define-key c-mode-base-map "\e\C-e" 'c-end-of-defun)) In Emacs-22, C-M-[ae] were bound directly to the CC Mode functions. In Emacs-23, the unless clause prevents this. Would you object if I restored these CC Mode bindings in Emacs 23? That's not a rhetorical question. Then we'd both get what we want, more or less. Except that this matter would stay unresolved, and raise its ugly head yet again some time in the future. I'm thoroughly sick of it, and I expect you are too. > 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. I regard it as already fixed. I fixed it, at the cost of a vast amount of refactoring and many, many evenings' hacking in 2006. I protest most strongly at losing the fruits of that work, even if only for the EOD case. Should I just restore the C-M-[ae] bindings in c-mode-base-map? > > 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? Because the sloppiness of the general EOD-function will have left point at some random position in the WS between defun-0 and defun-1. If you start somewhere in that WS, BOD+EOD will also leave you somewhere in that WS, so comparing those positions gives at best heuristic information. To get firm information, you'd have to start doing things like c-backward-syntactic-ws and see if you end up before where EOD put you. You can't rely on checking for a paren/brace/bracket, because not all languages use them (shell script, haskell, ?pascal for example). Even (BOD) (BOD -1) isn't necessarily any good, since beginning-of-defun-function might well be implemented to go to the textually nearest defun regardless of nesting level. Martin Stjernholm suggested this algorithm for CC Mode a while back - it's a good suggestion. > Stefan -- Alan Mackenzie (Nuremberg, Germany).