From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Drew Adams" Newsgroups: gmane.emacs.bugs Subject: bug#8368: 24.0.50; "temp" means "help" - rename or at least document Date: Wed, 2 May 2012 07:19:25 -0700 Message-ID: <37DC1189281D4B009CC215D5C3A3B632@us.oracle.com> References: <4F9BA96C.8070005@gmx.at> <4573CB93BA8F47DD922007A8C8CF3EB3@us.oracle.com> <4F9D1AB8.5090302@gmx.at> <2F5D2C7A2A6D44A3B25C5891EFEF7DF0@us.oracle.com> <4F9E5E08.4030400@gmx.at> <4F9F9A19.30402@gmx.at> <44E8D30016CC4FBBBD986DD8F8FE5BC6@us.oracle.com> <4FA1011A.2070300@gmx.at> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Trace: dough.gmane.org 1335968446 20341 80.91.229.3 (2 May 2012 14:20:46 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Wed, 2 May 2012 14:20:46 +0000 (UTC) Cc: 'Lars Magne Ingebrigtsen' , 8368@debbugs.gnu.org, rms@gnu.org To: "'martin rudalics'" Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Wed May 02 16:20:42 2012 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 1SPaQ5-0007vQ-Uo for geb-bug-gnu-emacs@m.gmane.org; Wed, 02 May 2012 16:20:42 +0200 Original-Received: from localhost ([::1]:48427 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SPaQ5-0003jJ-AB for geb-bug-gnu-emacs@m.gmane.org; Wed, 02 May 2012 10:20:41 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:60882) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SPaPv-0003gF-SK for bug-gnu-emacs@gnu.org; Wed, 02 May 2012 10:20:38 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SPaPt-0006eZ-Bd for bug-gnu-emacs@gnu.org; Wed, 02 May 2012 10:20:31 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:32823) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SPaPt-0006eP-7l for bug-gnu-emacs@gnu.org; Wed, 02 May 2012 10:20:29 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.72) (envelope-from ) id 1SPaRN-0004UB-KX for bug-gnu-emacs@gnu.org; Wed, 02 May 2012 10:22:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: "Drew Adams" Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 02 May 2012 14:22:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 8368 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 8368-submit@debbugs.gnu.org id=B8368.133596847917189 (code B ref 8368); Wed, 02 May 2012 14:22:01 +0000 Original-Received: (at 8368) by debbugs.gnu.org; 2 May 2012 14:21:19 +0000 Original-Received: from localhost ([127.0.0.1]:33857 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SPaQg-0004TC-Bu for submit@debbugs.gnu.org; Wed, 02 May 2012 10:21:19 -0400 Original-Received: from rcsinet15.oracle.com ([148.87.113.117]:30118) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SPaQd-0004Sz-7H for 8368@debbugs.gnu.org; Wed, 02 May 2012 10:21:16 -0400 Original-Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q42EJZUp019988 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 2 May 2012 14:19:35 GMT Original-Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q42EJXAo020006 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 2 May 2012 14:19:33 GMT Original-Received: from abhmt106.oracle.com (abhmt106.oracle.com [141.146.116.58]) by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q42EJX74004492; Wed, 2 May 2012 09:19:33 -0500 Original-Received: from dradamslap1 (/10.159.218.251) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 02 May 2012 07:19:32 -0700 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <4FA1011A.2070300@gmx.at> Thread-Index: Ac0oR5t8pCm1EZeFQnWjE5rqXZaWkgAI+qjQ X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 X-Source-IP: acsinet21.oracle.com [141.146.126.237] X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 2) 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:59705 Archived-At: > > I thought both what you proposed and what I proposed > > addressed this: rename (alias) and deprecate the old, > > misleading names. Seems like we're going 'round > > in circles now. I thought we (you & I & Stefan, at least) > > had already agreed on a reasonable solution. > > > > And I was pretty clear that the names are not what is > > most important to me. ^^^^ > > What matters most is to have a macro that does only the > > non-help stuff, separate from the macro that does also > > the help stuff. > > Can you tell me what you mean here? In the first paragraph > you say that you want to rename Just a proposal. If we have two macros, one for help stuff and one for only displaying etc but with nothing specific to help-mode, that would be good. If, in addition, the name of the help-mode specific one could have "help" in it, so much the better. One way to get the naming right is to defalias any name that will be inappropriate in the end to a new, more appropriate name (e.g. `...-help-...'). Deprecation does not mean immediate desupport, and it might not ever imply desupport. It means that what is deprecated _might_ be desupported at some time in the future. So users of the old name are not impacted. It's just a heads-up to users. They are forewarned that they might want to update the name sooner rather than later. But they _need not_ do so until desupport happens, if it ever does. The new, preferred name is what will be documented and increasingly used for new code etc. And even earlier I said: >> Probably we will need to leave the original name for the >> current behavior, but if it could be aliased to something >> with "help" in the name, and then the >> original name deprecated, that would be better. > and in the second paragraph you say that the names > are not important to you. No. Names are always important. What I said was that getting good names is not _as important_ as separating out the help-specific stuff, e.g., having two separate macros. Names are not the "most" important thing. And even earlier I said: >> Whether we have one or more different macros to distinguish >> temporary from help displays does not matter much to me. >> Likewise, the names of the macros or whatever are not what >> is most important (to me). >> >> Obviously, if possible, I would prefer that the names >> reflect the meaning/behavior - so, e.g. "temp" in >> one name and, say, "help" in the other. And maybe it >> makes sense to derive the help mode from the temp mode >> - dunno. > What I proposed boils down to write (at least) two new > macros: One which sets up `help-mode' and one which does not. And I agreed. And I said, "I don't really want to argue about the solution so much as report the problem and ask for a solution." > The question (for me) is whether the former should call the > lat[t]er and which hooks these should run (if at all). See above. I'm sure I'm OK with whatever you decide. As I said earlier: >> Whatever you decide will I'm sure be better than the >> hard-coded take-it-or-leave-it situation we have now. > The `with-output-to-temp-buffer' macro would stay in > place until we can safely tell that it doesn't have any more callers. Sounds good to me. My only proposal in that regard was to create an alias with a better name (e.g. `...-help-...'), and deprecate `with-output-to-temp-buffer' to encourage use of the new name. Am I still not clear enough? In sum, please go for it. I'm OK with what you propose to do.