all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: "Drew Adams" <drew.adams@oracle.com>
To: "'Chong Yidong'" <cyd@stupidchicken.com>,
	"'Juanma Barranquero'" <lekktu@gmail.com>
Cc: 'Emacs developers' <emacs-devel@gnu.org>
Subject: RE: [Emacs-diffs] /srv/bzr/emacs/trunk r103854: Reimplementlist-processes in Lisp.
Date: Thu, 7 Apr 2011 10:00:47 -0700	[thread overview]
Message-ID: <3020B91746414BA38A14779DD133543B@us.oracle.com> (raw)
In-Reply-To: <87ipuqf3xe.fsf@stupidchicken.com>

> > > http://debbugs.gnu.org/cgi/bugreport.cgi?bug=8368
> >
> > Thanks, I had forgotten that report.
> >
> > I basically agree with the first part, i.e., that it's a mistake to
> > assume any relationship between temporary and help.
> 
> Now that we have with-help-window (added by Martin Rudalics 
> in 2007), it makes sense to put help-mode-setup and
> help-mode-finish there, rather than applying them to all
> with-output-to-temp-buffer calls.
>
> Some uses of temp_output_buffer_setup in the C code may need 
> to be fixed to call help-mode-* explicitly, but that should be easy.
> 
> As for temp-buffer-setup-hook itself, maybe we should deprecate it.

Please be careful in this regard.  The use of help stuff for "temporary" buffers
is now quite old.  Lots of code out there expects it.

As I mentioned in the bug #8368 report, I'd suggest just aliasing to rename
`*-temp-*' to `*-help-*', and then creating a separate, _real_ temporary buffer
functionality that would not involve anything help- or completion-related.

IOW, just call things as they really are, but don't change or get rid of any
functionality.  From that moment on, users would see and use `*-help-*' where
they used to use `*-temp-*', and any old code with `*-temp-*' references would
still work the same.  The new, real temporary-buffer stuff would have a
different name (e.g. `*-temporary-*') so there would be no ambiguity or
conflict.

Deprecating the hook would be unwise, IMO.  It is used by 3rd-party code, if not
by vanilla Emacs code.  It should simply be renamed to `help-buffer-setup-hook'
and be run exactly as it is today (in the renamed `with-output-to-temp-buffer',
aka `with-output-to-help-buffer').  No changes in functionality.  No surprises.
Just make the names and the doc make better sense from now on.

> (The name is confusing, since with-temp-buffer does not run it when
> setting up the buffer.)

(I think you meant `with-output-to-temp-buffer'?)

Depends what you mean by "setting up".  It is run just after erasing the buffer.
Seems like pretty much the moment of buffer setup, to me.

> AFAICT, anything you put in the hook can be accomplished
> equivalently using the with-output-to-temp-buffer body

Hooks can be bound (dynamically), changing code behavior.  Sure, you can put a
function variable into the body, to get a similar effect, but that's essentially
using a hook!

Anyway, what you say is true of lots of hooks: given access to the body they can
be done without.  There's nothing wrong with keeping this hook.  And it is no
doubt used in 3rd-party code.

> (one difference is that the hook is run before rebinding 
> standard-output, but probably no one needs this).
> So, with help-mode-setup moved out into
> with-help-window, we can dispense with this hook.

Why move it to something that has to do with a window (display)?  Why move it
anywhere?  The only real problem (see the bug report) is the possible confusion
over naming.

> As for list-* commands not obeying temp-buffer-resize-mode, how about
> adding a display-buffer-hook, renaming temp-buffer-resize-mode to
> display-buffer-resize-mode (and moving it from help.el to window.el),
> and making that mode act on all uses of display-buffer-hook?  Then we
> can probably either deprecate temp-buffer-show-hook or make 
> it an alias for display-buffer-hook.

I don't see why you're thinking of doing all of this.  What is the problem
(problems?) you are trying to solve by this manoeuver?




  reply	other threads:[~2011-04-07 17:00 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <E1Q7a6k-0006uE-Q0@colonialone.fsf.org>
2011-04-06 22:35 ` [Emacs-diffs] /srv/bzr/emacs/trunk r103854: Reimplement list-processes in Lisp Juanma Barranquero
2011-04-07  0:38   ` Chong Yidong
2011-04-07  0:57     ` Juanma Barranquero
2011-04-07  2:00     ` [Emacs-diffs] /srv/bzr/emacs/trunk r103854: Reimplementlist-processes " Drew Adams
2011-04-07 10:09       ` Juanma Barranquero
2011-04-07 15:59         ` Chong Yidong
2011-04-07 17:00           ` Drew Adams [this message]
2011-04-07 19:08             ` Chong Yidong
2011-04-08  7:25               ` martin rudalics
2011-04-08 11:03                 ` Juanma Barranquero
2011-04-08 12:26                   ` martin rudalics
2011-04-08  7:25           ` martin rudalics

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

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

  git send-email \
    --in-reply-to=3020B91746414BA38A14779DD133543B@us.oracle.com \
    --to=drew.adams@oracle.com \
    --cc=cyd@stupidchicken.com \
    --cc=emacs-devel@gnu.org \
    --cc=lekktu@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 external index

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

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.