unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Drew Adams <drew.adams@oracle.com>
To: Leo Liu <sdl.web@gmail.com>, emacs-devel@gnu.org
Subject: RE: with-output-to-temp-buffer and help-mode
Date: Fri, 25 Jul 2014 08:34:22 -0700 (PDT)	[thread overview]
Message-ID: <f78b49b9-09e8-4ae1-9576-ba7a36624aa5@default> (raw)
In-Reply-To: <m3egx96c59.fsf@gmail.com>

> > So I think this should just be reverted.
> 
> See Martin's comment in
> http://debbugs.gnu.org/cgi/bugreport.cgi?bug=16038#14, there seems to be
> problems either way.

No, the solution should have been simple.
http://debbugs.gnu.org/cgi/bugreport.cgi?bug=16038#71

Better yet, read the whole thread, and the thread of the original
bug report (from me) that Martin referred to.

> Note also temp-buffer-setup-hook is part of the public hooks of
> with-output-to-temp-buffer so the macro makes no guarantee it will be in
> Help mode. I.e. it is permissible for a user to have (add-hook
> 'temp-buffer-setup-hook 'fancy-help-mode t)
> 
> The more important reason is we have variants of those macros and it is
> time to consolidate them. I'll find time to do that. Sorry just came
> back from a break and it has been very busy lately. But I'll get to it
> soon.

Please don't.

The last go-round of such "consolidation" is how we got into the
current mess.  Please see my original report of the problem and my
suggestion for fixing it.  You can start with the URL above.

The solution to the (minor) problem that "temp" was really about
"help" and there was nothing for temporary buffers *without*
help-mode should have been (as originally suggested) to:
(1) rename the "temp" macro (`with-output-to-temp-buffer') while
keeping the old name as an alias AND (2) create a new macro that
really is for temporary buffers (without any help-mode stuff).

What we got instead was a new macro for help (good) and a blind
removal of the help-mode stuff from the existing "temp" macro (bad!).

That requires every existing use of `with-output-to-temp-buffer' to
be revisited and adjusted to use the new help macro (or not, rarely)
instead.

Worse: For code that needs to work with multiple Emacs versions, it
also means adding an ugly workaround or two.  Something like this,
for instance, substituting it for (existing occurrences of the old)
`with-output-to-temp-buffer':

(defmacro my-kludgy-with-help-window (buffer &rest body)
  "`with-help-window', if available; else `with-output-to-temp-buffer'."
  (if (fboundp 'with-help-window)
      `(with-help-window ,buffer ,@body)
    `(with-output-to-temp-buffer ,buffer ,@body)))

Of course, wholesale replacement by such a macro would not deal
directly or correctly with existing occurrences of
`with-output-to-temp-buffer' where there was accompanying code that 
removed/inhibited the help-mode stuff (i.e., that tried to treat it
as really just a temporary buffer).

Whatever the workaround, each occurrence of `with-output-to-temp-buffer'
really needs to be checked to see what TRT to do is.

It's hard for me to believe that (a) things were "fixed" the way
they were and (b) that it has taken so long for someone besides me
to speak up about DTRT (thank you, Glenn).

FWIW: I have great respect for Martin's work.  This time, for
whatever reasons, and whatever combination of fixers was responsible
for the state we're in now, things have not turned out so well.

To me, the right solution is still the same: (a) revert the changes
to `with-output-to-temp-buffer' and (b) keep the changes to the
Emacs code that use the fine new macro (`with-help-window').

In addition, to address the original problem I reported, (c) create
a new macro with `temp' in the name, which does no help-mode stuff -
it would do essentially what the current (i.e., changed)
`with-output-to-temp-buffer' does, and (d) alias
`with-output-to-temp-buffer' to `with-help-window' and deprecate
`with-output-to-temp-buffer'.

The change for the last paragraph, (c) and (d), is *not* urgent.
It is essentially a nice-to-have, to end up with "temp" meaning
only temporary (not also help) and "help" meaning help.

But (a) and (b) should be done now (before Emacs 24.4), to bring
some sanity back.  Those of us who have already adjusted our code
to fit the new mess will just have to unadjust it.



  reply	other threads:[~2014-07-25 15:34 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-07-25  8:15 with-output-to-temp-buffer and help-mode Glenn Morris
2014-07-25  9:06 ` Leo Liu
2014-07-25 15:34   ` Drew Adams [this message]
2014-07-25 18:12     ` Leo Liu
2014-07-25 19:06       ` Drew Adams
2014-07-26  1:10         ` Stephen J. Turnbull
2014-07-26  9:00           ` martin rudalics
2014-07-26  1:30       ` Glenn Morris
2014-07-26  1:39   ` Glenn Morris
2014-07-26  3:33     ` Thien-Thi Nguyen
2014-08-05  8:35     ` Glenn Morris
2014-08-06 16:54       ` Stefan Monnier
2014-08-07  3:30         ` Leo Liu
2014-07-25 15:13 ` Drew Adams

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=f78b49b9-09e8-4ae1-9576-ba7a36624aa5@default \
    --to=drew.adams@oracle.com \
    --cc=emacs-devel@gnu.org \
    --cc=sdl.web@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).