From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Andreas =?iso-8859-1?q?R=F6hler?= Newsgroups: gmane.emacs.devel Subject: Re: Useless change in lisp.el? Date: Mon, 26 Nov 2007 19:14:34 +0100 Message-ID: <200711261914.34853.andreas.roehler@online.de> References: <200711251755.50891.andreas.roehler@online.de> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1196101107 29212 80.91.229.12 (26 Nov 2007 18:18:27 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 26 Nov 2007 18:18:27 +0000 (UTC) Cc: emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Nov 26 19:18:35 2007 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 1IwiXS-00019V-Pp for ged-emacs-devel@m.gmane.org; Mon, 26 Nov 2007 19:18:35 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1IwiXD-00018A-O6 for ged-emacs-devel@m.gmane.org; Mon, 26 Nov 2007 13:18:19 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1IwiXA-00017v-Dy for emacs-devel@gnu.org; Mon, 26 Nov 2007 13:18:16 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1IwiX6-00016H-HQ for emacs-devel@gnu.org; Mon, 26 Nov 2007 13:18:15 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1IwiX6-00015w-8f for emacs-devel@gnu.org; Mon, 26 Nov 2007 13:18:12 -0500 Original-Received: from moutng.kundenserver.de ([212.227.126.188]) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1IwiX5-0000Hn-PK for emacs-devel@gnu.org; Mon, 26 Nov 2007 13:18:12 -0500 Original-Received: from noname (p54BE91FC.dip0.t-ipconnect.de [84.190.145.252]) by mrelayeu.kundenserver.de (node=mrelayeu0) with ESMTP (Nemesis) id 0MKwh2-1IwiX03AUy-0003Jk; Mon, 26 Nov 2007 19:18:07 +0100 User-Agent: KMail/1.9.5 In-Reply-To: Content-Disposition: inline X-Provags-ID: V01U2FsdGVkX1+GgmfvxWk7ld5YdOpPgYY31uFRtScOyfaU0nX wVLka8fNYSurwJzwqgXqsERVBbuFdYtOhWwuVYCeCPGJETfDo2 3Fof91qgm4D/VU28gMG6Q== X-detected-kernel: by monty-python.gnu.org: Linux 2.6? (barebone, rare!) 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:84155 Archived-At: Am Montag, 26. November 2007 16:09 schrieben Sie: > > -The function (of no args) should go to the line on which the current > > -defun starts, and return non-nil, or should return nil if it can't > > -find the beginning.") > > +The function takes the same argument as `beginning-of-defun' and should > > +behave similarly, returning non-nil if it found the beginning of a > > defun. +Ideally it should move to a point right before an open-paren > > which encloses +the body of the defun.") > > > > As `beginning-of-defun-function' expressivly is > > introduced for all possible function definitions, it > > makes no sence to require or even to mention an open > > paren. > > Sure it does: end-of-defun does basically > "(progn (beginning-of-defun-raw) (forward-sexp)", so if > beginning-of-defun-function stops right before an "open paren", > end-of-defun will do the right thing. Otherwise, the programmer will > have to supply his own end-of-defun-function. I read here (and (beginning-of-defun-raw arg) (progn (beginning-of-line) t))) where `beginning-of-line' would be the part in question. As `beginning-of-line' comes after customized `beginning-of-defun-function' it must not be the right thing. But that's another question. Should you not cling to much to that disputed change and no one else defends it, I would appreciate much=20 seeing it reverted. Andreas R=F6hler > Note that since=20 > forward-sexp can be customized with forward-sexp-function, the notion of > "open paren" may include things like "begin...end". > > [ Yes, I know end-of-defun currently doesn't always use forward-sexp, > I'm working on fixing that. ] > > If you see how to improve the doc to make this more clear, patches > are welcome. > > > Other languages are completely free to design function > > definitions. Emacs should be able to follow them without specifying > > things no one may know at this time. > > Indeed. I did not write that the function *must* do it, just that it > should ideally do that. > > > Too I pointed just these days at the fact, `beginning-of-defun' will > > be understood as top-level-form here rather than strictly > > a function-beginning. > > Agreed. I tried to keep this in mind when writing the above text, but > again, if you see a way to make it more clear, go for it. > > > + ;; we used to use end-of-defun for that, but it's not supposed to do > > + ;; the same thing (it moves to the end of a defun not to the > > beginning + ;; of the next). > > > > That's not the case. > > Yes it is: try it in elisp-mode (with enough empty lines between defuns > that the difference caqn be noticed, of course). > > > As `beginning-of-defun-function' together with `end-of-defun-function' > > are freely to design, progmodes could do that at their will. > > No: end-of-defun can't know that it's called by beginning-of-defun. > > > Stefan