From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Andreas Roehler Newsgroups: gmane.emacs.python-mode,gmane.emacs.devel,gmane.emacs.xemacs.beta Subject: Re: simplifying beginning-of-defun Date: Sun, 27 Sep 2009 10:10:21 +0200 Message-ID: <4ABF1DED.6050906@online.de> References: <4ABE54F9.7090107@online.de> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1254039124 16610 80.91.229.12 (27 Sep 2009 08:12:04 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 27 Sep 2009 08:12:04 +0000 (UTC) Cc: emacs-devel@gnu.org, python-mode@python.org, XEmacs-Beta@xemacs.org To: Stefan Monnier Original-X-From: python-mode-bounces+gcpp-python-mode=m.gmane.org@python.org Sun Sep 27 10:11:56 2009 Return-path: Envelope-to: gcpp-python-mode@m.gmane.org Original-Received: from mail.python.org ([82.94.164.166]) by lo.gmane.org with esmtp (Exim 4.50) id 1MrorM-0004Ah-Db for gcpp-python-mode@m.gmane.org; Sun, 27 Sep 2009 10:11:56 +0200 Original-Received: from albatross.python.org (localhost.localdomain [127.0.0.1]) by mail.python.org (Postfix) with ESMTP id 3A30CE917 for ; Sun, 27 Sep 2009 10:11:56 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=python.org; s=200901; t=1254039116; bh=ZMthC70y4Vj94+mLWZ6nLNe9pddq1yqRDP1oNQBYwIA=; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To:Cc: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Type:Content-Transfer-Encoding:Sender; b=RZ4PWGXyF/bYT6cQU5v6L8LMBOLM6kE33nSEeeTqp4ONL5NaobDwcqExURKVGMBd3 4E501+++0pPpNhqAE3oABQ8Ko3NL90128UJh/z2lxY+9k2bDIPepfjA2HrSmmFQdyw FtIwQpOKKkZL9VF2vSS179wPbBDcWSiknDYtFfzE= Original-Received: from albatross.python.org (localhost.localdomain [127.0.0.1]) by mail.python.org (Postfix) with ESMTP id 941F5E1B4 for ; Sun, 27 Sep 2009 10:11:52 +0200 (CEST) X-Spam-Status: OK 0.005 X-Spam-Evidence: '*H*': 0.99; '*S*': 0.00; 'acceptable': 0.03; 'bug': 0.04; 'bugs': 0.05; 'implement': 0.05; 'argument': 0.07; 'understood': 0.07; 'wrote:': 0.08; 'already.': 0.09; 'argument.': 0.09; 'back,': 0.09; 'behavior,': 0.09; 'ignoring': 0.09; 'moment.': 0.09; 'sets': 0.09; 'solving': 0.09; 'function': 0.12; 'header:In-Reply-To:1': 0.14; '(eval': 0.16; '0))': 0.16; '1))': 0.16; '1)))': 0.16; 'accompany': 0.16; 'arg': 0.16; 'backward': 0.16; 'execution.': 0.16; 'function.': 0.16; 'incompatible': 0.16; 'indeed': 0.16; 'otoh': 0.16; 'paradigm': 0.16; 'received:192.168.178': 0.16; 'received:212.227.126.187': 0.16; 'regexp': 0.16; 'rid': 0.16; 'skip:` 20': 0.16; 'stefan': 0.16; 'url:launchpad': 0.16; 'useless': 0.16; 'example': 0.17; 'clearly': 0.19; "didn't": 0.21; 'discussions': 0.22; 'difference': 0.22; 'problem': 0.23; 'cc:addr:python.org': 0.24; 'anything': 0.25; 'p Original-Received: from localhost.localdomain (HELO mail.python.org) (127.0.0.1) by albatross.python.org with SMTP; 27 Sep 2009 10:11:52 +0200 Original-Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.187]) by mail.python.org (Postfix) with ESMTP for ; Sun, 27 Sep 2009 10:11:52 +0200 (CEST) Original-Received: from [192.168.178.27] (p54BE8E94.dip0.t-ipconnect.de [84.190.142.148]) by mrelayeu.kundenserver.de (node=mreu0) with ESMTP (Nemesis) id 0LdZnq-1M9RTi38de-00j1BW; Sun, 27 Sep 2009 10:11:34 +0200 User-Agent: Thunderbird 2.0.0.19 (X11/20081227) In-Reply-To: X-Provags-ID: V01U2FsdGVkX19oy1jaw+2TpIcnAKdAwiUtdAtxYicbGNaqiz0 w75H8+UkRIFjqt1JaM4/msHHNAKE9RQhvJ9jQieNjbw9z1bp6m WaawNwov2ebksyt+3UkiEbZjr1yL8f4 X-BeenThere: python-mode@python.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: For issues concerning python-mode for X/Emacs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: python-mode-bounces+gcpp-python-mode=m.gmane.org@python.org Errors-To: python-mode-bounces+gcpp-python-mode=m.gmane.org@python.org Xref: news.gmane.org gmane.emacs.python-mode:320 gmane.emacs.devel:115684 gmane.emacs.xemacs.beta:30583 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. OTOH it will take some feasible bugs from progmodes. It underlines a paradigm change, which was introduced with var `beginning-of-defun-function' already. These facility departs from all-at-once solutions, which have been likely creating a bug in the back, while solving one in the forehead. 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. > > 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. So your code wouldn't be acceptable as is since it would > likely break several packages. > > 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. > > The main difference I see between your beginning-of-defun and Emacs's > one is that yours doesn't try to handle the case where > beginning-of-defun-function, defun-prompt-regexp, and > open-paren-in-column-0-is-defun-start and all nil. This case was added > fairly recently (Emacs-22, IIRC) after a long discussion. Gladly to see, discussions here seldom turn out that badly. :) 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(" I do not like > this extra case at all, actually, but if you're trying to get rid of it, > please make it a separate thread. > > In other words, if you send new code just to simplify the existing one, > than make sure the incompatibilities Mentioned code of a end-of-defun-function in lisp.el is a bug. Suggest to cancel it. Let the -raw functions do everything needed for emacs-lisp. Funcalls of beginning-of-defun-function, end-of-defun-function should be reserved for progmodes. BTW if mode-specific, probably it should be introduced as a local var from the very beginning? are clearly understood and > "minor". Otherwise, better focus on the proposal for the change in > behavior, and then accompany that with a patch showing how you suggest > to implement this change. > > > Stefan > Found a bug still in end-of-defun. Changed code below: ;; GNU's lisp.el ;; unhappily sets this var globally, ignoring its use for progmodes (when (featurep 'emacs) (setq end-of-defun-function nil)) (setq defun-searchform '(if defun-prompt-regexp (concat "^\\s(\\|" "\\(" defun-prompt-regexp "\\)\\s(") "^\\s(")) (defun beginning-of-defun (&optional arg) "Move backward to the beginning of a functions definition. " (interactive "P") (or arg (setq arg 1)) (if beginning-of-defun-function (funcall beginning-of-defun-function arg) (beginning-of-defun-raw arg))) (defun beginning-of-defun-raw (&optional arg) "Called if progmodes didn't set beginning-of-defun-function. " (when (re-search-backward (eval defun-searchform) nil 'move (or arg 1)) (goto-char (match-beginning 0)))) (defun end-of-defun (&optional arg) "Move backward to the end of a function. " (interactive "P") (or arg (setq arg 1)) (if end-of-defun-function (funcall end-of-defun-function arg) (end-of-defun-raw arg))) (defun end-of-defun-raw (&optional arg) "Called if progmodes didn't set end-of-defun-function. " (skip-chars-forward " \t\r\n\f") (when (looking-at (eval defun-searchform)) (forward-char -1)) (when (re-search-forward (eval defun-searchform) nil t arg) (goto-char (match-beginning 0)) (forward-sexp 1))) ;;;;;;;;;;;