From: Drew Adams <drew.adams@oracle.com>
To: martin rudalics <rudalics@gmx.at>
Cc: Leo Liu <sdl.web@gmail.com>, 16038@debbugs.gnu.org
Subject: bug#16038: 24.3; latest change to with-help-window makes temp-buffer-browse useless
Date: Fri, 24 Jan 2014 08:29:19 -0800 (PST) [thread overview]
Message-ID: <b68469e9-d905-4b38-aa18-252c077258c6@default> (raw)
In-Reply-To: <52E28AAF.2030803@gmx.at>
> The same author wrote in http://debbugs.gnu.org/cgi/bugreport.cgi?bug=8368
>
> 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.
>
> martin, who couldn't resist
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.
next prev parent reply other threads:[~2014-01-24 16:29 UTC|newest]
Thread overview: 39+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-12-03 14:34 bug#16038: 24.3; latest change to with-help-window makes temp-buffer-browse useless Leo Liu
2014-01-11 14:01 ` martin rudalics
2014-01-11 14:32 ` Leo Liu
2014-01-11 15:41 ` martin rudalics
2014-01-11 16:31 ` Leo Liu
2014-01-12 9:53 ` martin rudalics
2014-01-14 0:23 ` Leo Liu
2014-01-14 1:47 ` Stefan Monnier
2014-01-14 4:42 ` Leo Liu
2014-01-14 21:38 ` Stefan Monnier
2014-01-14 21:55 ` Drew Adams
2014-01-14 23:46 ` Leo Liu
2014-01-22 2:14 ` Leo Liu
2014-01-22 3:02 ` Stefan Monnier
2014-01-22 3:32 ` Leo Liu
2014-01-22 13:44 ` Stefan Monnier
2014-01-23 10:03 ` Leo Liu
2014-01-23 17:48 ` Drew Adams
2014-01-24 7:30 ` Leo Liu
2014-01-24 15:06 ` Drew Adams
2014-01-24 15:45 ` martin rudalics
2014-01-24 16:29 ` Drew Adams [this message]
2014-01-25 9:21 ` martin rudalics
2014-01-25 16:34 ` Drew Adams
2014-01-25 16:48 ` martin rudalics
2014-01-25 17:33 ` Drew Adams
2014-01-25 18:25 ` martin rudalics
2014-01-25 20:19 ` Drew Adams
2014-01-26 11:24 ` martin rudalics
2014-01-26 17:52 ` Drew Adams
2014-01-27 8:21 ` martin rudalics
2014-01-27 15:14 ` Drew Adams
2014-01-22 3:07 ` Glenn Morris
2014-07-08 1:54 ` Glenn Morris
2014-07-08 2:04 ` Glenn Morris
2014-07-08 5:59 ` Glenn Morris
2014-07-08 13:57 ` Drew Adams
2014-07-08 22:24 ` Leo Liu
2014-07-10 7:20 ` Glenn Morris
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=b68469e9-d905-4b38-aa18-252c077258c6@default \
--to=drew.adams@oracle.com \
--cc=16038@debbugs.gnu.org \
--cc=rudalics@gmx.at \
--cc=sdl.web@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.