From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel,gmane.emacs.xemacs.beta Subject: Re: simplifying beginning-of-defun Date: Sun, 27 Sep 2009 18:52:25 -0400 Message-ID: References: <4ABE54F9.7090107@online.de> <4ABF3DCB.3060602@online.de> <1254050248.6168.30.camel@projectile.siege-engine.com> <1254082041.6168.65.camel@projectile.siege-engine.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1254091965 20370 80.91.229.12 (27 Sep 2009 22:52:45 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 27 Sep 2009 22:52:45 +0000 (UTC) Cc: emacs-devel@gnu.org, Andreas Roehler , XEmacs-Beta@xemacs.org To: eric@siege-engine.com Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Sep 28 00:52:38 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 1Ms2bc-000670-QC for ged-emacs-devel@m.gmane.org; Mon, 28 Sep 2009 00:52:37 +0200 Original-Received: from localhost ([127.0.0.1]:38893 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Ms2bc-0007sR-D6 for ged-emacs-devel@m.gmane.org; Sun, 27 Sep 2009 18:52:36 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Ms2bY-0007sC-I5 for emacs-devel@gnu.org; Sun, 27 Sep 2009 18:52:32 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Ms2bT-0007s0-LY for emacs-devel@gnu.org; Sun, 27 Sep 2009 18:52:32 -0400 Original-Received: from [199.232.76.173] (port=53100 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Ms2bT-0007rx-Cj for emacs-devel@gnu.org; Sun, 27 Sep 2009 18:52:27 -0400 Original-Received: from ironport2-out.teksavvy.com ([206.248.154.181]:8025 helo=ironport2-out.pppoe.ca) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1Ms2bS-0006FJ-Tu for emacs-devel@gnu.org; Sun, 27 Sep 2009 18:52:27 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvIEAPeIv0pFxIo//2dsb2JhbACBUNBXhB4Fh30 X-IronPort-AV: E=Sophos;i="4.44,461,1249272000"; d="scan'208";a="46678998" Original-Received: from 69-196-138-63.dsl.teksavvy.com (HELO pastel.home) ([69.196.138.63]) by ironport2-out.pppoe.ca with ESMTP; 27 Sep 2009 18:52:25 -0400 Original-Received: by pastel.home (Postfix, from userid 20848) id 9241880C4; Sun, 27 Sep 2009 18:52:25 -0400 (EDT) In-Reply-To: <1254082041.6168.65.camel@projectile.siege-engine.com> (Eric M. Ludlam's message of "Sun, 27 Sep 2009 16:07:21 -0400") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1.50 (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:115700 gmane.emacs.xemacs.beta:30592 Archived-At: >> 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. Yes, this area is sufficiently messy (and different between versions and flavors of Emacs) that only the main entry point is ever used. > 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 I can't think of a reason why #3 wouldn't want to be affected by #4. Note that for #2, it's not just the interactive form, since it also affects #3 (e.g. mark-defun, send-defun-to-inferior-process, younameit, ...). > 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. Yes, it appears that some major-mode that set beginning-of-defun-function also call beginning-of-defun, so there's a chance that one of those calls actually is wrong and should call the major-mode's code rather than going through beginning-of-defun-function. It's OK: such bugs need to be fixed, it's not CEDET's responsibility if the major mode breaks in this case. >> 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. [...] > 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. What about programs that want to use CEDET but that also want to work when CEDET is not available? They would most likely want to use beginning-of-defun. Stefan