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: Tue, 03 Feb 2009 21:21:02 -0500 Message-ID: References: <20090202202703.GB11077@muc.de> <20090203105035.GB1396@muc.de> <20090203122906.GC1396@muc.de> <20090203130028.GD1396@muc.de> <20090203160941.GE1396@muc.de> <20090203185812.GH1396@muc.de> <20090204001445.GI1396@muc.de> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1233714097 1450 80.91.229.12 (4 Feb 2009 02:21:37 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 4 Feb 2009 02:21:37 +0000 (UTC) Cc: Miles Bader , emacs-devel@gnu.org To: Alan Mackenzie Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Feb 04 03:22:51 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 1LUXPe-0003J8-Kh for ged-emacs-devel@m.gmane.org; Wed, 04 Feb 2009 03:22:50 +0100 Original-Received: from localhost ([127.0.0.1]:55094 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LUXOL-0001rl-SF for ged-emacs-devel@m.gmane.org; Tue, 03 Feb 2009 21:21:29 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LUXOG-0001rC-CY for emacs-devel@gnu.org; Tue, 03 Feb 2009 21:21:24 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LUXOE-0001r0-TR for emacs-devel@gnu.org; Tue, 03 Feb 2009 21:21:24 -0500 Original-Received: from [199.232.76.173] (port=50326 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LUXOE-0001qv-MD for emacs-devel@gnu.org; Tue, 03 Feb 2009 21:21:22 -0500 Original-Received: from ironport2-out.teksavvy.com ([206.248.154.182]:49234) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1LUXOB-0004xn-4Q; Tue, 03 Feb 2009 21:21:19 -0500 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag0FANOKiEnO+J73/2dsb2JhbACBbs1+hBQGgnc X-IronPort-AV: E=Sophos;i="4.37,375,1231131600"; d="scan'208";a="33292642" Original-Received: from 206-248-158-247.dsl.teksavvy.com (HELO pastel.home) ([206.248.158.247]) by ironport2-out.teksavvy.com with ESMTP; 03 Feb 2009 21:21:02 -0500 Original-Received: by pastel.home (Postfix, from userid 20848) id 8538E8296; Tue, 3 Feb 2009 21:21:02 -0500 (EST) In-Reply-To: <20090204001445.GI1396@muc.de> (Alan Mackenzie's message of "Wed, 4 Feb 2009 00:14:45 +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:108710 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. > 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. > perhaps that would work, but it would break existing 3rd party code. Like which code? >> Unless by "the problem" you're talking about the performance problem, in >> which case I understand that each time we call BOD (except for the first >> call), we know that we're "outside" of a defun (unless there's nesting, >> of course) but we don't tell that to BOD which may have to redo the work >> of figuring it out. > WILL have to do the work. No: in most cases, beginning-of-defun-raw just uses a simple regexp and doesn't try to determine its position in the syntax tree before doing its job. This is pretty much how C-mode's beginning-of-defun worked in Emacs-21 and incidentally it worked (for the cases I care about) much better than the current code. > Now, I wonder, who could that have been? ;-) Oh, how I'd love just to > get rid of these stupid K&R declarations, which NOBODY uses at all > nowadays, except on >20 year old code bases. ;-) Why don't we flush > them out of Emacs C source? (No, you don't have to answer.) Feel free to remove support for those things in C-mode. 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. >> > It's changed from "move to next end of function" to "move to the end of >> > the function at whose beginning we now are", >> Right. As you may notice, the second is a subset of the first (with >> a few caveats for nested functions, of course, but that shouldn't matter >> for C-mode), so if your implementation works for the first, it should >> work for the second as well. It's called backward compatibility. > c-end-of-defun's functionality "needs" to stay the same to support other > Emacsen. For Emacs-23's EOD-function, It would barely need to be more > than > (search-forward-regexp "{") > (backward-char) > (foward-sexp) Yes, simplicity of implementation of EOD-function was indeed an important motivation in my code changes. >> > and its default value is `forward-sexp'. `c-end-of-defun' was a good >> > fit for the variable as it formerly was, but is now >> > severely suboptimal. >> At most by a factor of 2. I.e. if it's slow now, it sure wasn't >> zippy before. > By a factor a great deal more than 2, highly dependent on ARG. The only case I care about for now is when ARG=1. As long as this case is slow, there's no point complaining that end-of-defun makes it too slow for ARG=106. >> >> Not sure about restoring the previous semantics. But I could agree to >> >> the additional ARG argument, which could even let it "take over" (so >> >> beginning-of-defun-raw is not called in that case). >> > :-) Let's do it! >> I knew you'd like it. > :-) I'm still wondering whether we couldn't just turn end-of-defun into a simple variant of (BOD-raw N) (funcall EOD-function) > OK. I think I can see what you're saying, now. Were you thinking of any > (non CC Mode) languages in particular? Did this ever get discussed on > emacs-devel? I might well have been asleep at the time. No, I don't remember discussing it much. It did come out of a discussion where it became apparent that end-of-defun was broken (especially when called with negative args). Stefan