From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Eric M. Ludlam" Newsgroups: gmane.emacs.devel,gmane.emacs.xemacs.beta Subject: Re: simplifying beginning-of-defun Date: Sun, 27 Sep 2009 16:07:21 -0400 Message-ID: <1254082041.6168.65.camel@projectile.siege-engine.com> References: <4ABE54F9.7090107@online.de> <4ABF3DCB.3060602@online.de> <1254050248.6168.30.camel@projectile.siege-engine.com> Reply-To: eric@siege-engine.com NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1254082052 29299 80.91.229.12 (27 Sep 2009 20:07:32 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 27 Sep 2009 20:07:32 +0000 (UTC) Cc: emacs-devel@gnu.org, Andreas Roehler , XEmacs-Beta@xemacs.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Sep 27 22:07:24 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 1Ms01k-0000zv-IL for ged-emacs-devel@m.gmane.org; Sun, 27 Sep 2009 22:07:24 +0200 Original-Received: from localhost ([127.0.0.1]:47447 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Ms01j-00066m-GI for ged-emacs-devel@m.gmane.org; Sun, 27 Sep 2009 16:07:23 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Ms01e-00066W-51 for emacs-devel@gnu.org; Sun, 27 Sep 2009 16:07:18 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Ms01Z-00066J-Lv for emacs-devel@gnu.org; Sun, 27 Sep 2009 16:07:17 -0400 Original-Received: from [199.232.76.173] (port=48794 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Ms01Z-00066G-JZ for emacs-devel@gnu.org; Sun, 27 Sep 2009 16:07:13 -0400 Original-Received: from static-71-184-83-10.bstnma.fios.verizon.net ([71.184.83.10]:53257 helo=projectile.siege-engine.com) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1Ms01Z-000273-3E for emacs-devel@gnu.org; Sun, 27 Sep 2009 16:07:13 -0400 Original-Received: from projectile.siege-engine.com (localhost [127.0.0.1]) by projectile.siege-engine.com (8.14.3/8.14.3/Debian-6) with ESMTP id n8RK7Mxx022860; Sun, 27 Sep 2009 16:07:22 -0400 Original-Received: (from zappo@localhost) by projectile.siege-engine.com (8.14.3/8.14.3/Submit) id n8RK7L1q022859; Sun, 27 Sep 2009 16:07:21 -0400 X-Authentication-Warning: projectile.siege-engine.com: zappo set sender to eric@siege-engine.com using -f In-Reply-To: X-Mailer: Evolution 2.26.1 X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 3) 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:115698 gmane.emacs.xemacs.beta:30591 Archived-At: On Sun, 2009-09-27 at 14:53 -0400, Stefan Monnier wrote: > > I agree with the basic mechanics of what Andreas is providing here, not > > any specific feature change involved in the patch. If there were some > > function like the -raw functions he proposed that program modes would > > use if they wanted exactly that behavior, and a separate interactive > > function, then that opens the door for improvements on the interactive > > function. > > We already have beginning-of-defun and beginning-of-defun-raw exactly > for these kinds of reasons. Ok. I didn't research before responding. ;) I just now grepped around, and no programs use beginning-of-defun-raw, but they do use beginning-of-defun, and some use MODE-beginning-of-defun. > > This comes up specifically with CEDET, where I can use parser > > information to do a real `beginning-of-defun' for langauges whos defuns > > don't happen to start with a ( in the first column. From an interactive > > point of view, a total win. > > So you mean you'd want both beginning-of-defun-raw-function and > beginning-of-defun-function (additionally to (define-key map [remap > beginning-of-defun] ...), of course)? > I'd have to think about it. I think there are these variants: * A program wants the default behavior * A major mode wants to change the interactive form * A program wants use the major-mode behavior * A third tool (ie - cedet) wants to change the interactive forms without breaking the above three, and without modifying the global map > > From a programs point of view, this would mean disaster if all their > > code was expecting the cursor to show up on some opening {, and not on > > the text actually starting the defun. For modes like cc-mode that > > write their own correct `beginning-of-defun', they would use that > > internally anyway, so no loss. > > So you mean we should provide a default-beginning-of-defun which is not > subject to any *-function fiddling and change some of the calls to > beginning-of-defun to use that function instead, so they're more robust > in cases where something like CEDET sets beginning-of-defun-function? > That makes sense, yet. That is one solution, though I'm not sure about the beginning-of-defun-function setting, as the major mode may expect the function to be set as done in the major-mode. > > Right now, the feature I describe in CEDET/Semantic is done with advice > > and various if statements making sure not to do the modification in > > non-interactive cases. The code is in senator.el. > > I think that interactive/noninteractive is not the right distinction > (there are non-interactive cases which would also benefit from using an > improved implementation). It's probably the best (conservative) > solution you could use, because the right solution requires more changes > to other packages. Exactly. By way of example, the `set-mark' function has doc that specifically says not to use it in programs, and suggests some other function to use. Thus, someone could add advice to `set-mark' or `set-mark-command' to add some glitz, but programs remain safe from the change. I think of CEDET as being able to 'glitz' up functions like beginning-of-defun by making them accurate. Programs that actually want to use CEDET to get the more accurate behavior will not use 'beginning-of-defun' at all. They would instead get the current tag at point, from which the location of the start/end of the tag is readily available, along with a bunch of other info. Tweaking beginning-of-defun is only useful as a way of giving the user a better experience. Other packages that use beginning-of-defun as a function currently work as is, so we don't want to change the behavior for those uses. If those packages want the new behavior, there are plenty of APIs in CEDET/Semantic to do what they want at their leisure. Eric