Re: emacsclient/server finished, documentation, raising frames

["Juanma Barranquero" <lekktu@gmail.com>]

On 11/7/06, Stefan Monnier <monnier@iro.umontreal.ca> wrote:

> Obviously, my suggestion is one that aims to reduce the code complexity at
> the cost of a slightly reduced choice for the user.

Executing a function in `server-window' is the least complex code in
`server-switch-buffer'; the burden of checking weird situations is on
the user. I would rather understand if you were proposing to remove
the other options.

> So the question is: for what would you "use a function for `server-window'"?

As I've said: to create dedicated frames for emacsclient-sent files,
different of the frames I use normally. That does not depend on the
name or the major-mode of the user; just on the origin. I would also
use it perhaps to set local variables on these buffers (like
read-only, etc.), but that could perhaps be done with
`server-switch-hook'.

> Would display-buffer-function work as well?

Probably. But I don't see the advantage. I suppose you're going to say
that `display-buffer-function' is more general, but that also means
that if I want something different from normal buffers for buffers
that come from emacsclient, I'm gonna be forced to move the complexity
of checking from the `server-window' function to the
`display-buffer-function'...

> Rather something like introducing
> a variable "pop-to-same-window" or something equivalent where the
> "same-window" is decided by the call site rather than the buffer name.

Choosing windows and frames can be complex, and the optima are quite
different from one user to another. If you have an idea for
pop-to-same-window or other option(s) that does not take away
flexibility, I'm certainly not opposed.

                    /L/e/k/t/u