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

[martin rudalics]

> 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