bug#17109: 24.4.50; REGRESSION: `with-output-to-temp-buffer' is broken

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

> > In a build as recent as this one there was no such problem:
> 
> See bug#16038 on why with-output-to-temp-buffer is no longer 
> associated with help mode.  You can use any major mode.

It should still be associated with help mode.  That's how you
preserve its behavior.  If you want to give it additional,
alternative, optional behavior then add that, but do not change
the default behavior.  It has been "associated with help mode"
for 30 years.  That's what it does.  That's what it's for (yes,
in spite of its poor name).

Please revert this incompatible change.

From your own post to the #16038 thread: "We are trying to
consolidate the features of the two macros into one
so no feature is lost."
^^^^^^^^^^^^^^^^^^^^^

Well bug #17109 shows that you've changed
`with-output-to-temp-buffer' in an incompatible way, which
contradicts your claim of not losing its behavior.

If you want new, incompatible behavior, come up with a
different, new macro.  Why screw `with-output-to-temp-buffer'?
There is no reason to change its behavior - ESPECIALLY if you
want to eventually make it obsolete.

This just gets worse and worse.  Emacs has already added
`with-help-window'.  Fine.  Add another one if you need it.
But why must you mess with existing behavior like this?

Create as many new functions and macros as you like, but do you
need to be introducing incompatible behavior changes like this to
existing functions & macros?

Martin said: "`with-help-window' does some things differently
which I could not put into `with-output-to-temp-buffer' due to
compatibility issues."

And so what has now happened to this precious
`with-output-to-temp-buffer' compatibility?  Out the window!

You persisted: "The more interesting question is is it possible
to merge these two macros?"  That is not "the more interesting
question".  Just misguided.

In the #16038 thread, I said, "Incorporate whatever you feel
you need to into `with-output-to-temp-buffer', as long as
"no feature is lost" from it."  And now it is broken.

What should have happened, to start with, is to fix bug #8368.

And you have still NOT deprecated `with-output-to-temp-buffer'.
As I said in the #16038 thread:

  If `with-output-to-temp-buffer' is deprecated, we should
  learn in the NEWS that this is the case AND what it is
  replaced by. IOW, tell users how to update their code.
  Likewise for the misnamed hooks etc.

  Instead, at least so far, NEWS has only this: 

    *** New macro `with-temp-buffer-window', similar to
    `with-output-to-temp-buffer'.

And I said:

  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.

And:

  What `with-output-to-temp-buffer' patterns map to what
  `with-temp-buffer-window' patterns?   What about the various
  hooks?

So you feel fine just breaking the behavior of
`with-output-to-temp-buffer' and not deprecating it.  And not
telling users how to get the equivalent of the old behavior,
IOW how to fix their code that you've now broken by changing
what `with-output-to-temp-buffer' does.

This is madness.  Leave `with-output-to-temp-buffer' alone.
Use new code however you like.  But don't gratuitously break
the old code that you want to eventually make obsolete.

Can you imagine if a company did that to paying customers
with existing code?  Emacs users don't pay you for their
software, but that shouldn't make you feel free to screw
them and just make gratuitous changes willy nilly.