emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [Emacs-diffs] /srv/bzr/emacs/trunk r103854: Reimplementlist-processe


From: Drew Adams
Subject: RE: [Emacs-diffs] /srv/bzr/emacs/trunk r103854: Reimplementlist-processes in Lisp.
Date: Thu, 7 Apr 2011 10:00:47 -0700

> > > 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 via email to

[Prev in Thread] Current Thread [Next in Thread]