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: return values Date: Fri, 13 Nov 2009 11:56:40 +0100 Message-ID: <4AFD3B68.1010507@online.de> References: <4AF94183.5020400@online.de> <20091110131021.GB1385@muc.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 1258109881 26978 80.91.229.12 (13 Nov 2009 10:58:01 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 13 Nov 2009 10:58:01 +0000 (UTC) Cc: XEmacs-Beta@xemacs.org, emacs-devel@gnu.org To: Alan Mackenzie Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Nov 13 11:57:54 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 1N8tqi-0005dh-ES for ged-emacs-devel@m.gmane.org; Fri, 13 Nov 2009 11:57:52 +0100 Original-Received: from localhost ([127.0.0.1]:58657 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1N8tqh-0000jP-W0 for ged-emacs-devel@m.gmane.org; Fri, 13 Nov 2009 05:57:52 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1N8tqY-0000hC-Kv for emacs-devel@gnu.org; Fri, 13 Nov 2009 05:57:42 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1N8tqT-0000b7-T5 for emacs-devel@gnu.org; Fri, 13 Nov 2009 05:57:41 -0500 Original-Received: from [199.232.76.173] (port=60738 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1N8tqT-0000ay-PZ for emacs-devel@gnu.org; Fri, 13 Nov 2009 05:57:37 -0500 Original-Received: from moutng.kundenserver.de ([212.227.17.10]:60861) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1N8tqT-0000ts-1p for emacs-devel@gnu.org; Fri, 13 Nov 2009 05:57:37 -0500 Original-Received: from [192.168.178.27] (p54BEB39B.dip0.t-ipconnect.de [84.190.179.155]) by mrelayeu.kundenserver.de (node=mrbap2) with ESMTP (Nemesis) id 0MWgo7-1McBNO42yB-00Y0YE; Fri, 13 Nov 2009 11:57:34 +0100 User-Agent: Thunderbird 2.0.0.19 (X11/20081227) In-Reply-To: <20091110131021.GB1385@muc.de> X-Provags-ID: V01U2FsdGVkX1/rExh6/SBOxOQhQCATIzRy18U8tROZxAourpL jBm5QzFZaXNkX4yoSBB2rGHTDaAdP/AAG9OfOeRqnqXNUliJO6 IUrRbeZLAEN00En0ucj1Zr9XhoHXGQatEEblPGL+xc= 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:116939 gmane.emacs.xemacs.beta:31262 Archived-At: Alan Mackenzie wrote: > Hi, Andreas! > > On Tue, Nov 10, 2009 at 11:33:39AM +0100, Andreas Roehler wrote: > >> Hi, > >> IMHO it might be helpful, if classes of functions have a regular return >> value. > >> For example functions which move point should return point. > > Here, it's probably more accurate to say "would have been a good idea", > since some users of the current functions will use the current return > values, even if only relying on the fact that they're always nil. > >> `goto-char' does it presently, beginning/end-of-defun not. > > Indeed. > >> Also I suggest mentioning the return value in docstring. > > I am in favour of mentioning the return value of EVERY function, even > when (or _especially_ when :-) it's only a sentence like "The return > value is of no significance". ... Hi Alan, what about not to have just one return value hard-coded, but let it being choosed via optional return-flags? Let's consider the case of `forward-comment' employed inside a `delete-comments-in-region' function. First `forward-comment' must move. If a comment-section is reached, function must determine its borders in order to delete. Now this second operations basically is redundant, as `forward-comment' determined borders already, otherwise it couldn't know about nested comments. A forward-comment is already able to deliver beg, end --separately or as a list-- and the comment itself as a string. So instead of executing two consecutive functions to determine, forward-comment could take a flag: For example b - return beginning e - return end l - return beginning and end as a list s - return found item as a string Cheers Andreas -- https://code.launchpad.net/s-x-emacs-werkstatt/ http://bazaar.launchpad.net/~a-roehler/python-mode/python-mode.el/