bug#16038: 24.3; latest change to with-help-window makes temp-buffer-browse useless

[martin rudalics <rudalics@gmx.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