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: Mon, 28 Sep 2009 18:46:51 -0400 Message-ID: References: <4ABE54F9.7090107@online.de> <4ABF1DED.6050906@online.de> <4AC05C9A.2010802@online.de> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1254178031 29494 80.91.229.12 (28 Sep 2009 22:47:11 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 28 Sep 2009 22:47:11 +0000 (UTC) Cc: emacs-devel@gnu.org, "Eric M. Ludlam" , XEmacs-Beta@xemacs.org To: Andreas Roehler Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Sep 29 00:47:04 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 1MsOzn-0000E6-WF for ged-emacs-devel@m.gmane.org; Tue, 29 Sep 2009 00:47:04 +0200 Original-Received: from localhost ([127.0.0.1]:53110 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MsOzn-0003iu-4u for ged-emacs-devel@m.gmane.org; Mon, 28 Sep 2009 18:47:03 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MsOzi-0003if-5Z for emacs-devel@gnu.org; Mon, 28 Sep 2009 18:46:58 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MsOzd-0003gg-I7 for emacs-devel@gnu.org; Mon, 28 Sep 2009 18:46:57 -0400 Original-Received: from [199.232.76.173] (port=45652 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MsOzd-0003gU-0k for emacs-devel@gnu.org; Mon, 28 Sep 2009 18:46:53 -0400 Original-Received: from ironport2-out.teksavvy.com ([206.248.154.183]:20776 helo=ironport2-out.pppoe.ca) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MsOzc-0000Fm-Mz for emacs-devel@gnu.org; Mon, 28 Sep 2009 18:46:52 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAEvZwEpFxIo//2dsb2JhbACBUdVqhB4Fh30 X-IronPort-AV: E=Sophos;i="4.44,469,1249272000"; d="scan'208";a="46757893" Original-Received: from 69-196-138-63.dsl.teksavvy.com (HELO pastel.home) ([69.196.138.63]) by ironport2-out.pppoe.ca with ESMTP; 28 Sep 2009 18:46:52 -0400 Original-Received: by pastel.home (Postfix, from userid 20848) id C53BB80C4; Mon, 28 Sep 2009 18:46:51 -0400 (EDT) In-Reply-To: <4AC05C9A.2010802@online.de> (Andreas Roehler's message of "Mon, 28 Sep 2009 08:50:02 +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:115754 gmane.emacs.xemacs.beta:30615 Archived-At: >> 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. Maybe it should, maybe it shouuldn't. My point is that it currently does whereas in your patch it doesn't, so that's an incompatibility. That doesn't mean it's a problem, just a place that requires careful attention. > 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. end-of-defun's docstring says "With argument, do it that many times", so if a major mode uses it for other purposes, it's abusing it. It would probably be better in such a case to just define a new command and remap keys to that new command. >>> 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. Who says? > This setting reintroduces all the mess, > beginning/end-of-defun-function are invented for. I do not know what you're referring to. >>> 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 Why would such a concept matter here? emacs-lisp-mode should not be treated specially. >>> 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. It's definitely meant to be buffer-local. That doesn't mean there shouldn't be a meaningful default for those buffers which don't want to bother to set it themselves. Stefan