emacs-devel
[Top][All Lists]
Advanced

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

Re: Some question about display-buffer action functions


From: martin rudalics
Subject: Re: Some question about display-buffer action functions
Date: Sun, 29 Jan 2012 18:32:15 +0100

> It seems straightforward to use display-buffer-alist for that, so I
> add "*SQL*" and "*Python*" to that variable, with an AF of
> jb-inferior.
>
> Now, in an ideal world, after calling (pop-to-buffer BUFFER) for one
> of these buffers, the process would be:
>
>  - jb-inferior is called, looks for INF; if found and alive, use it,
> and return INF; else return nil.
>  - If nil, another, non-custom AF (likely
> display-buffer-pop-up-window) will take care of selecting/creating the
> appropriate window and returning it.

Basically that's what side windows should eventually do.  In your case
the INF window would be the bottom side window with slot number zero.
It's either reused or created and weakly dedicated so it's not reused by
other buffer display functions.

>  - Then, call jb-setup for the window selected.
>
> which is quite modular and elegant. But there's no way to call
> jb-setup after selecting the window, at least not easily. I can think
> of a few answers, but they start ugly and go down from there:
>
> - Invoke pop-to-buffer (or display-buffer) from inside a custom
> function, like this:
>
>   (defun my-create-inferior-buffer-and-window (my-buffer)
>     (pop-to-buffer my-buffer)
>     (jb-setup (get-buffer-window my-buffer)))

How is `my-create-inferior-buffer-and-window' different from
`jb-inferior' (apart from the missing ALIST argument)?  Also, wouldn't
`pop-to-buffer' (indirectly, via `display-buffer-alist') call
`my-create-inferior-buffer-and-window' again?

>  which will work in this particular case, but it's not a generic
> answer in cases where display-buffer and friends are called from code
> not under my control.

I'm not sure I understand what you mean here: Shouldn't the setup of
_any_ buffer appearing in INF be under your control via `jb-setup'?

> - Modify jb-inferior to always return a window, either finding INF or
> spliting SUP, so it can run jb-setup before returning INF. This works
> and it's easy, but it just kills modularity and elegance, and forces
> jb-inferior to do a poor job of duplicating the work of the standard
> AFs.

Do you mean that jb-inferior cannot call `display-buffer-pop-up-window'
or that it's clumsy to do that?

> - Use window hooks (window-scroll-functions,
> window-size-change-functions or window-configuration-change-hook),
> which is not nice because the correspondence buffer<->window, known
> while running display-buffer, is lost and has to be recomputed; and
> additionally, these hooks run for every window created or buffer
> displayed, which is wasted work.

Neither of these hooks is appropriate here.

> - Or use a custom split-window-preferred-function. Most horrible
> because it would destroy abstraction.

Indeed.

> One possible answer would be having a
> display-buffer-(after-)functions, which would get passed the buffer
> and window after the window has been selected.

It should be passed just the window after `set-window-buffer' since then
the buffer can be easily derived from the window.  BTW `display-buffer'
doesn't necessarily select the window.

> (A -before-hook seems
> less useful, and can be simulated with an AF which runs the code
> you're interested and always return nil). Another one would be to have
> a hook entry for the action alist (after-selecting-window-function or
> somesuch) that would be run by the (custom and non-custom) AFs as the
> last thing done upon selecting a window, just before returning it.

It should probably be a `display-buffer-hook'.  But note that a hook
always requires people knowing how to write the corresponding function.
What about people who want to accomplish the necessary functionality via
the customization interface?

> 2)  Is there any way to set up the quit-window parameter of a window
> so quit-window just always deletes the window? In the case above, when
> I'm in INF and type quit-window I always want to destroy the window.
> Even if INF was assigned to *Python* and then *SQL*, quit-window
> should not go back to *Python*. Currently I'm forced to do
>
> (defun jb-bury-interact (&optional finish)
>   "Bury inferior interactive buffer.
> If FINISH, terminate inferior process."
>   (interactive "P")
>   (unless (one-window-p t)
>     (when finish (comint-send-eof))
>     (bury-buffer)
>     (window--delete nil t)))

Calling (display-buffer-record-window 'window window buffer) from within
`jb-inferior' should do that.

> 3) It would be nice to make writing custom AFs simpler. Currently I'm
> just ignoring the inhibit-same-window and reusable-frames actions in
> my AFs (not to mention display-buffer-reuse-frames and pop-up-frames)
> because it is a PITA to wrap your head around them...

I'm by no means against a `display-buffer-hook'.  But first I'd like to
know why `display-buffer-alist' together with the ALIST argument cannot
be used to do that without calling a hook function.  That is, why can't
you do something like

(defun jb-inferior (buffer alist)
  (let ((window (window-with-parameter 'inferior-only)))
    (if window
        (set-window-buffer window buffer)
      (setq window (display-buffer-pop-up-window buffer alist)))
    (display-buffer-record-window 'window window buffer)
    (jb-setup window)
    window))

martin



reply via email to

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