From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Daniel Koning Newsgroups: gmane.emacs.bugs Subject: bug#6130: 23.1; artist-mode spray-can malfunction Date: Fri, 23 Jan 2015 15:52:54 -0600 Message-ID: References: <8dd014e7478827e94e3a8fe5b2b948e0@lysator.liu.se> <54BA6A0A.4080408@gmx.at> <54BB8375.9000506@gmx.at> <54BFD9D9.70708@gmx.at> <54C1402D.1000100@gmx.at> <54C205D0.3000607@gmx.at> <83mw59u91v.fsf@gnu.org> <54C27CD2.1040402@gmx.at> <83ppa5rxxo.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1422050061 28963 80.91.229.3 (23 Jan 2015 21:54:21 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 23 Jan 2015 21:54:21 +0000 (UTC) Cc: 6130@debbugs.gnu.org, busk@lysator.liu.se To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Fri Jan 23 22:54:20 2015 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1YEmBA-0005hV-Ap for geb-bug-gnu-emacs@m.gmane.org; Fri, 23 Jan 2015 22:54:12 +0100 Original-Received: from localhost ([::1]:33286 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YEmB9-0005nT-JU for geb-bug-gnu-emacs@m.gmane.org; Fri, 23 Jan 2015 16:54:11 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:54320) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YEmB5-0005nG-K6 for bug-gnu-emacs@gnu.org; Fri, 23 Jan 2015 16:54:08 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YEmB0-0003L2-Je for bug-gnu-emacs@gnu.org; Fri, 23 Jan 2015 16:54:07 -0500 Original-Received: from debbugs.gnu.org ([140.186.70.43]:35955) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YEmB0-0003Ky-GR for bug-gnu-emacs@gnu.org; Fri, 23 Jan 2015 16:54:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1YEmB0-0007Hl-Ap for bug-gnu-emacs@gnu.org; Fri, 23 Jan 2015 16:54:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Daniel Koning Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 23 Jan 2015 21:54:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 6130 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 6130-submit@debbugs.gnu.org id=B6130.142204999527943 (code B ref 6130); Fri, 23 Jan 2015 21:54:02 +0000 Original-Received: (at 6130) by debbugs.gnu.org; 23 Jan 2015 21:53:15 +0000 Original-Received: from localhost ([127.0.0.1]:54647 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YEmAE-0007Gc-SV for submit@debbugs.gnu.org; Fri, 23 Jan 2015 16:53:15 -0500 Original-Received: from sender1.zohomail.com ([74.201.84.155]:30252) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YEmAB-0007GR-Mp for 6130@debbugs.gnu.org; Fri, 23 Jan 2015 16:53:12 -0500 Original-Received: from cornelius (99-181-53-37.lightspeed.rcsntx.sbcglobal.net [99.181.53.37]) by mx.zohomail.com with SMTPS id 1422049976580434.68227131099684; Fri, 23 Jan 2015 13:52:56 -0800 (PST) In-Reply-To: <83ppa5rxxo.fsf@gnu.org> (Eli Zaretskii's message of "Fri, 23 Jan 2015 23:26:11 +0200") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (darwin) X-ZohoMailClient: External X-Zoho-Virus-Status: 2 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 140.186.70.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:98658 Archived-At: Eli Zaretskii writes: > We do that all the time. For example: > > (display-graphic-p &optional DISPLAY) > > Return non-nil if DISPLAY is a graphic display. > [...] > DISPLAY can be a display name, a frame, or nil (meaning the selected > frame's display). >From a user perspective, there is a crucial distinction between these two examples of ambiguous naming. When an argument is called DISPLAY even though it can be other things besides a display, the function still works in every case that its name and its arguments' names suggest that it should work. But when the return value is called WINDOW when it might not be one, then it becomes a source of potential error merely to rely on the function to behave as its name suggests. Sure, you can write documentation to warn users about the pitfall, but misleading naming conventions are one of the factors that cause people to write mistaken documentation. (Cf. the documentation of `posn-window' until a few days ago!) > In polymorphic interfaces, the alternative is to say > DISPLAY-OR-FRAME-OR-... which is too tedious. If that's the main problem with assigning accurate names in polymorphic contexts -- that the names end up too long when you include every possible type -- how about defining a supertype which includes (in this case) both windows and frames? That may seem cumbersome, but realize that this is effectively what is already happening, insofar as "window" is being coerced into serving as metonymy for the entire class of mouse-position containers. Daniel