From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: end-of-defun is fubsr. Date: Wed, 04 Feb 2009 09:29:20 -0500 Message-ID: References: <20090203105035.GB1396@muc.de> <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 1233759725 28015 80.91.229.12 (4 Feb 2009 15:02:05 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 4 Feb 2009 15:02:05 +0000 (UTC) Cc: Andreas, emacs-devel@gnu.org, =?iso-8859-1?Q?R=F6hler?= , Miles Bader To: Alan Mackenzie Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Feb 04 16:03:17 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 1LUjHT-0004aQ-Jq for ged-emacs-devel@m.gmane.org; Wed, 04 Feb 2009 16:03:11 +0100 Original-Received: from localhost ([127.0.0.1]:45413 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LUjGA-0007g5-FT for ged-emacs-devel@m.gmane.org; Wed, 04 Feb 2009 10:01:50 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LUikm-0002UH-EP for emacs-devel@gnu.org; Wed, 04 Feb 2009 09:29:24 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LUikk-0002U5-T3 for emacs-devel@gnu.org; Wed, 04 Feb 2009 09:29:24 -0500 Original-Received: from [199.232.76.173] (port=54600 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LUikk-0002U2-Qj for emacs-devel@gnu.org; Wed, 04 Feb 2009 09:29:22 -0500 Original-Received: from ironport2-out.teksavvy.com ([206.248.154.182]:10829) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1LUikj-0006jE-Ca; Wed, 04 Feb 2009 09:29:21 -0500 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqIEAL80iUnO+J73/2dsb2JhbACBbs44hBYGgn8 X-IronPort-AV: E=Sophos;i="4.37,379,1231131600"; d="scan'208";a="33307389" Original-Received: from 206-248-158-247.dsl.teksavvy.com (HELO pastel.home) ([206.248.158.247]) by ironport2-out.teksavvy.com with ESMTP; 04 Feb 2009 09:29:20 -0500 Original-Received: by pastel.home (Postfix, from userid 20848) id 5E08C8296; Wed, 4 Feb 2009 09:29:20 -0500 (EST) In-Reply-To: <20090204133728.GB1049@muc.de> (Alan Mackenzie's message of "Wed, 4 Feb 2009 13:37:28 +0000") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.60 (gnu/linux) X-detected-operating-system: by monty-python.gnu.org: Genre and OS details not recognized. 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:108735 Archived-At: >> > 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