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

[Drew Adams]

> 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.