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

[Drew Adams <drew.adams@oracle.com>]

>  > And just what problem is that?  You say there is a problem to
>  > fix in my code.  What is the problem?
> 
> The one from http://debbugs.gnu.org/cgi/bugreport.cgi?bug=8368#32.

That demo example was not from my code, as you know.  It
demonstrates bug #8368, showing why it needs to be fixed.
And it is still pertinent, AFAIK.

>  > (And what is the fix you have in mind?)

And the fix is?

>  >>  > If bug #8368 is now fixed, great: What code to replace
>  >>  > with what code, concretely?
>  >>
>  >> Your code that uses `with-output-to-temp-buffer'.
>  >
>  > Why should that be replaced?  And if it should, just what
>  > should it to be replaced with?
> 
> With `with-temp-buffer-window'.

How so?  Is it a one-one replacement?  What about the hooks?

If `with-temp-buffer-window' is supposed to be the replacement for
`with-output-to-temp-buffer' then that needs to be stated clearly
in the NEWS.

Including a spec of what the replacement should be for different
`with-output-to-temp-buffer' input patterns (formal parameters).
And including hook use (correspondences).  With any significant
differences and limitations pointed out.

That is how to help users transition from the old to the new.
I imagine that you are well aware of that, but it's perhaps
better not to guess.

Consider by contrast this NEWS entry, which helps users
understand how to use `cl-flet' by pointing out how it differs
from (Emacs Lisp) `flet':

  *** `cl-flet' is not like `flet' (which is deprecated).
  Instead it obeys the behavior of Common-Lisp's `flet'.
  In particular, in cl-flet function definitions are lexically
  scoped, whereas in flet the scoping is dynamic.

>  > That is part of deprecating something:
>  > tell users what they should change to what in existing
>  > code.  E.g.,
>  > (old-foo this that) ==>
>  >   (new-bar something-else that 42 (1- this))
>  > or whatever.
> 
> I don't propose to deprecate something.

It seems to me that that is part of what bug #16038, and this
discussion, are about.  It is also part of what bug #8368 is
about.

You ask us to reread #8368, to guess how your new macro responds
to that bug.  That bug speaks specifically about deprecating
`with-output-to-temp-buffer'.

And in that context the deprecation would involve a simple
renaming (one-one).

> I offer a solution to a problem.

What is the solution, beyond chanting the mantra
`with-temp-buffer-window'?  What `with-output-to-temp-buffer'
patterns map to what `with-temp-buffer-window' patterns?
What about the various hooks?

>  >> Maybe Leo would have started to do that if you had not
>  >> interfered.  I suggest you apologize and consult with him
>  >> on how to proceed on this matter.
>
>  > Suggest all you want, if it makes you feel better.  But I
>  > do not feel that I interfered in any way.  Nor do I think
>  > I have anything to apologize for.
> 
> Then better don't ask for suggestions.

No one asked for ad hominem, off-the-wall "suggestions".

Of course, you elided your actual suggestion (restored here),
as well as what I said about it (restored here), giving the
impression that it might have actually been a helpful, technical
suggestion that I objected to when I said, "Suggest all you want".