From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Andreas Roehler Newsgroups: gmane.emacs.devel,gmane.emacs.xemacs.beta Subject: Re: simplifying beginning-of-defun Date: Mon, 28 Sep 2009 08:50:02 +0200 Message-ID: <4AC05C9A.2010802@online.de> References: <4ABE54F9.7090107@online.de> <4ABF1DED.6050906@online.de> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1254120705 8212 80.91.229.12 (28 Sep 2009 06:51:45 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 28 Sep 2009 06:51:45 +0000 (UTC) Cc: emacs-devel@gnu.org, "Eric M. Ludlam" , XEmacs-Beta@xemacs.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Sep 28 08:51:37 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 1MsA5A-0000gE-Ma for ged-emacs-devel@m.gmane.org; Mon, 28 Sep 2009 08:51:36 +0200 Original-Received: from localhost ([127.0.0.1]:38530 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MsA5A-0008LR-23 for ged-emacs-devel@m.gmane.org; Mon, 28 Sep 2009 02:51:36 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MsA53-0008Ix-SV for emacs-devel@gnu.org; Mon, 28 Sep 2009 02:51:29 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MsA4z-0008Fb-KL for emacs-devel@gnu.org; Mon, 28 Sep 2009 02:51:29 -0400 Original-Received: from [199.232.76.173] (port=59416 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MsA4z-0008FR-ER for emacs-devel@gnu.org; Mon, 28 Sep 2009 02:51:25 -0400 Original-Received: from moutng.kundenserver.de ([212.227.126.187]:63227) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MsA4y-0007eK-KP for emacs-devel@gnu.org; Mon, 28 Sep 2009 02:51:25 -0400 Original-Received: from [192.168.178.27] (p54BE992A.dip0.t-ipconnect.de [84.190.153.42]) by mrelayeu.kundenserver.de (node=mreu1) with ESMTP (Nemesis) id 0LqY9V-1MNl8Q3gCP-00e8zk; Mon, 28 Sep 2009 08:51:14 +0200 User-Agent: Thunderbird 2.0.0.19 (X11/20081227) In-Reply-To: X-Provags-ID: V01U2FsdGVkX1+7t+29zPvQqKhEzF69J8xyUYIzFqo1W9zbGvv 6KBM/k+DcLwUB1W5jhzLVbvKrbFeaI+5uvLADXdDCeRI98bG7B 6xl3yiCQQZU6cFGQ04y5AyY1oszVhOY 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:115712 gmane.emacs.xemacs.beta:30597 Archived-At: Stefan Monnier wrote: >>>> 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. Can't see any. If you write >>> Apparently it makes beginning-of-defun-raw ignore >>> beginning-of-defun-function, it should do exactly that IMHO. Beginning-of-defun-function was already called by beginning-of-defun in my scheme - if necessary. 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). > Why not let modes say what they want and need? An argument must not mean a repeat BTW. In python-mode is a selection to deliver too. >>> 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? from GNU lisp.el. "(defvar end-of-defun-function (lambda () ...." Giving it a value here, it will be called. Which is to avoid, as only languages-modes should set and use it. This setting reintroduces all the mess, beginning/end-of-defun-function are invented for. > >> 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". Modes of other programming languages than emacs-lisp > >> 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)? > Yes, that's the question. I.e it should be mode-specific, in any case not global. Andreas > > Stefan > > >