From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: martin rudalics Newsgroups: gmane.emacs.bugs Subject: bug#16038: 24.3; latest change to with-help-window makes temp-buffer-browse useless Date: Sat, 25 Jan 2014 10:21:13 +0100 Message-ID: <52E38209.6080506@gmx.at> References: <52D14E9F.5030001@gmx.at> <52D16627.4080604@gmx.at> <52D2661A.4000105@gmx.at> <90f208e1-9ab5-4b8c-9e4c-2dddf8c1868b@default> <52E28AAF.2030803@gmx.at> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1390641737 31021 80.91.229.3 (25 Jan 2014 09:22:17 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 25 Jan 2014 09:22:17 +0000 (UTC) Cc: Leo Liu , 16038@debbugs.gnu.org To: Drew Adams Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sat Jan 25 10:22:23 2014 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 1W6zRX-0004tr-6Z for geb-bug-gnu-emacs@m.gmane.org; Sat, 25 Jan 2014 10:22:23 +0100 Original-Received: from localhost ([::1]:50445 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W6zRW-0008QQ-Pq for geb-bug-gnu-emacs@m.gmane.org; Sat, 25 Jan 2014 04:22:22 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:39388) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W6zRM-0008Q8-Ia for bug-gnu-emacs@gnu.org; Sat, 25 Jan 2014 04:22:19 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1W6zRD-0002qo-1C for bug-gnu-emacs@gnu.org; Sat, 25 Jan 2014 04:22:12 -0500 Original-Received: from debbugs.gnu.org ([140.186.70.43]:49292) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W6zRC-0002qi-Te for bug-gnu-emacs@gnu.org; Sat, 25 Jan 2014 04:22:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1W6zRC-0001Dl-I8 for bug-gnu-emacs@gnu.org; Sat, 25 Jan 2014 04:22:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: martin rudalics Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 25 Jan 2014 09:22:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 16038 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 16038-submit@debbugs.gnu.org id=B16038.13906416824642 (code B ref 16038); Sat, 25 Jan 2014 09:22:02 +0000 Original-Received: (at 16038) by debbugs.gnu.org; 25 Jan 2014 09:21:22 +0000 Original-Received: from localhost ([127.0.0.1]:35078 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1W6zQY-0001Co-1c for submit@debbugs.gnu.org; Sat, 25 Jan 2014 04:21:22 -0500 Original-Received: from mout.gmx.net ([212.227.15.15]:59306) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1W6zQV-0001Cc-6j for 16038@debbugs.gnu.org; Sat, 25 Jan 2014 04:21:20 -0500 Original-Received: from [62.47.32.79] ([62.47.32.79]) by mail.gmx.com (mrgmx001) with ESMTPSA (Nemesis) id 0LwrwO-1VDzAj1YAC-016S3d for <16038@debbugs.gnu.org>; Sat, 25 Jan 2014 10:21:17 +0100 In-Reply-To: X-Provags-ID: V03:K0:2lKrasJMKvWlQxt9dXAIPdp9GJxaepXQrzlj99VVKjoI1gbHh2q tVNgV4y4ejWVwxIfVQcj8lRR9TwKZhiCQ2LBwcQqRDbFJZ/y0vUp+rszlX3CAR557QXhIuS 2CfNnru77K4vCxOj9EEiwUfU8o+y3uOPhxJKav5mpremNynOsquZpd0j5WCfEu+iJB6GFR1 u+gbXvyt9vwaeiQseVQZA== 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:83972 Archived-At: > Yes, 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. > (I think that's part of what you suggest.) And create a new name > for the temp-without-the-help-stuff case. > > If you read the whole thread for bug #8368 then you will understand. > Is the current discussion about fixing bug #8368? If you fix that > problem as requested, great. > > I'm all in favor of what was requested in bug #8368. The name of > `with-output-to-temp-buffer' is not good. That macro has been abused > for a long time by stuffing help-related stuff into it. > > That does not mean that we shouldn't have a macro that does what > `with-output-to-temp-buffer' does. And as noted above, users should > be encouraged, over time, to use the new, "help"-related name. > > If you have a complete fix for bug #8368, fine - please go for it. > That is not what I think I am seeing in the bug #16038 thread. > > Fixing bug #8368 includes not only renaming `with-output-to-temp-buffer' > to something like `with-output-to-help-buffer' - AND fixing its doc > to reflect what it really does - it is about help, but ALSO doing > the same for any other `*-temp-*' things that really are `-*help*-' > things. > > And, in particular, ALSO create real temporary-buffer facilities, > including a real `with-output-to-temp-buffer' (but renamed, to > avoid confusion), unencumbered by help-related stuff. > > IOW, fix the names and doc of the misnamed `*-temp-*' things to > reflect the fact that they are about help. AND create real > temporary-buffer things that are unrelated to help. > > I stressed the bit about creating real temporary-buffer things: > > The point of the last part is that there is a need for creating > and using temporary buffers. That should never have been co-opted > for help, but now that it is we should fix it properly: (a) call > a spade a spade and (b) create new macros for really dealing with > temporary buffers. > > And a year later... > > Can we please move forward on fixing this bug? > There is lots of stuff in a "temp" buffer now that has nothing to > do with a temporary buffer. All of the special help link and > navigation commands should be reserved for a help mode that is > _derived_ from a (minimal) temporary buffer mode. > > And later... > > 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. > > And this, especially pertinent to the current discussion: > > 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. > > Can you explain how bug #16038 relates to bug #8368? Is the latter > being fixed by the fix by the fix for the former? > > Yes, I would like to see bug #8368 fixed. And I notice that some > of what was pointed out in the #8368 report seems to be rediscovered > now for bug #16038. #8368 is still a bug, AFAIK. Maybe you should try to fix this problem: > But I have no code that uses `with-temp-buffer-window'. martin