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,gmane.emacs.python-mode Subject: Re: simplifying beginning-of-defun Date: Sun, 27 Sep 2009 14:40:56 -0400 Message-ID: References: <4ABE54F9.7090107@online.de> <4ABF1DED.6050906@online.de> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1254076877 10789 80.91.229.12 (27 Sep 2009 18:41:17 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 27 Sep 2009 18:41:17 +0000 (UTC) Cc: XEmacs-Beta@xemacs.org, python-mode@python.org, emacs-devel@gnu.org To: Andreas Roehler Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Sep 27 20:41:10 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 1MrygF-0003GI-TB for ged-emacs-devel@m.gmane.org; Sun, 27 Sep 2009 20:41:08 +0200 Original-Received: from localhost ([127.0.0.1]:42138 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MrygF-0006s5-D3 for ged-emacs-devel@m.gmane.org; Sun, 27 Sep 2009 14:41:07 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MrygB-0006rw-4P for emacs-devel@gnu.org; Sun, 27 Sep 2009 14:41:03 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Mryg6-0006ri-Rk for emacs-devel@gnu.org; Sun, 27 Sep 2009 14:41:02 -0400 Original-Received: from [199.232.76.173] (port=60617 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Mryg6-0006re-Ik for emacs-devel@gnu.org; Sun, 27 Sep 2009 14:40:58 -0400 Original-Received: from ironport2-out.teksavvy.com ([206.248.154.181]:24394 helo=ironport2-out.pppoe.ca) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1Mryg6-0007Kz-1M for emacs-devel@gnu.org; Sun, 27 Sep 2009 14:40:58 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AtUEAF5Ov0pFpYq6/2dsb2JhbACBUdByhB4Fh30 X-IronPort-AV: E=Sophos;i="4.44,461,1249272000"; d="scan'208";a="46673865" Original-Received: from 69-165-138-186.dsl.teksavvy.com (HELO pastel.home) ([69.165.138.186]) by ironport2-out.pppoe.ca with ESMTP; 27 Sep 2009 14:40:57 -0400 Original-Received: by pastel.home (Postfix, from userid 20848) id A4AB280C4; Sun, 27 Sep 2009 14:40:56 -0400 (EDT) In-Reply-To: <4ABF1DED.6050906@online.de> (Andreas Roehler's message of "Sun, 27 Sep 2009 10:10:21 +0200") 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:115694 gmane.emacs.xemacs.beta:30587 gmane.emacs.python-mode:322 Archived-At: >>> simplifying forms as below should ease maintenance and speed up execution. >> To what extent does it preserve compatibility? > Don't see anything incompatible for the moment. I actually mentionned obvious incompatibilities in the email to which you reply. > With `beginning-of-defun-function', > `end-of-defun-function' python-mode for example > https://launchpad.net/python-mode > may set its own function and M-x beginning-of-defun then > will work still - which is not the case presently and my point of > depart here. I do not understand the above paragraph. >> Apparently it makes beginning-of-defun-raw ignore >> beginning-of-defun-function, and it calls end-of-defun-function with one >> argument contrary to the current situation where it's called without >> any argument. > An argument is useful here: as a repeat or specifier. I was pointing out incompatibilities. Also the current way end-of-defun-function is defined, it does not need a repeat because it only jumps from the beginning of a defun to its end (i.e. it doesn't do the same as end-of-defun). >> Which performance problem is it trying to solve? > All which useless code execution causes. > Regard the lines of code saved that way to have an approximation. This is much too general: OT1H it's not true (larger code is not necessarily slower), OTOH (and more importantly) it doesn't help me understand which specific performance problem this is aiming to address. > open-paren-in-column-0-is-defun-start is purely redundant, as the > regexp may specify that - and indeed does already(?) its just that > what I read with "^\\s(" Again, please move this discussion to a separate thread. > Mentioned code of a end-of-defun-function in lisp.el is a bug. > Suggest to cancel it. I do not know which code nor which bug you talking about. Your code? Emacs's code? > Let the -raw functions do everything needed for emacs-lisp. AFAICT, that's already the way it's designed (that's why it doesn't set the mark, for example). > Funcalls of beginning-of-defun-function, end-of-defun-function should > be reserved for progmodes. I have no idea what you mean by "progmodes". > BTW if mode-specific, probably it should be introduced as a local var > from the very beginning? I'm not sure I understand. Are you suggesting we (make-varible-buffer-local 'beginning-of-defun-function)? Stefan