emacsclient/server finished, documentation, raising frames

emacsclient/server finished, documentation, raising frames

[Juanma Barranquero]

Except for the little question discussed below, all work on
emacsclient/server is now complete. No changes will be commited by me
unless something breaks. In the next few days I expect to commit
patches to documentation (FAQ and the Emacs manual), though I hope
somebody will check it afterwards: my writing skills in English are
horrible.

[All the following is Windows-specific; please skip it if you're not
interested.]

I've just checked in a patch to emacsclient that allows it to bring
Emacs to front just before passing it a file. "Allows" is the
operative word: Emacs won't be the foreground app unless it does
something to be, that is, call `raise-frame'.

As I see it, there are four ways to do it:

 1) Modify `server-switch-buffer' to raise the frame. Hairy.
`server-switch-buffer' already does quite a lot of things to try to
determine the right buffer/window/frame (and in some cases it already
calls `raise-frame'), so I don't think it is wise to mess with it.

  2) Modify `server-process-filter' to call `raise-frame' just after
calling `server-switch-buffer' and before running the
`server-switch-hook'. Easy. On the other hand, I'm not sure we want to
always raise the frame, after all (or even, what is the *right* frame
to raise, on multi-frame setups).

 3) Add `raise-frame' to `server-switch-hook' (which could be done
conditionally, just on Windows). Easier still; same problems that
previous way.

  4) Do nothing, and document the issue, so users can just do 3) on
their .emacs. Easiest of all; OTOH, I'm a bit reluctant because
server/emacsclient should work "right" just out of the box.

I'm partial to 3), i.e., adding `raise-frame' to `server-switch-hook'
on Windows, which works well with the default value of
`server-window'.

Now, the real question: could people with non-nil `server-window', or
multi-frame setups, try adding `raise-frame' to `server-switch-hook'
and see whether it works as expected? My setup is strictly one-frame,
so I don't know really what to expect from emacsclient/server on
multi-frame configurations.

Thanks,
                    /L/e/k/t/u

Re: emacsclient/server finished, documentation, raising frames

[Jason Rumney]

Juanma Barranquero wrote:
> [All the following is Windows-specific; please skip it if you're not
> interested.]
>
> I've just checked in a patch to emacsclient that allows it to bring
> Emacs to front just before passing it a file. "Allows" is the
> operative word: Emacs won't be the foreground app unless it does
> something to be, that is, call `raise-frame'.
Is this really Windows specific? It doesn't seem like it should be, as 
it is a user preference whether Emacs should jump to the front when 
emacsclient is used. Currently the frame is raised whenever Emacs was 
iconified, and there doesn't seem to be a user option to control this. 
Personally I think there should be a user option that controls whether 
Emacs is raised, whether iconified or not.

> 1) Modify `server-switch-buffer' to raise the frame. Hairy.
> `server-switch-buffer' already does quite a lot of things to try to
> determine the right buffer/window/frame (and in some cases it already
> calls `raise-frame'), so I don't think it is wise to mess with it.
I think this is the best place for it though, as this code has knowledge 
about which frame needs to be raised.

Re: emacsclient/server finished, documentation, raising frames

[Stefan Monnier]

> Is this really Windows specific? It doesn't seem like it should be, as it
> is a user preference whether Emacs should jump to the front when
> emacsclient is used.  Currently the frame is raised whenever Emacs was
> iconified, and there doesn't seem to be a user option to control this.
> Personally I think there should be a user option that controls whether
> Emacs is raised, whether iconified or not.

The question is also whether it should be triggered only when calling
`emacsclient' or also when using C-x # to switch to the next client buffer
(both call server-switch-buffer).
For what it's worth, I think we should remove server-window and change
server-switch-buffer to always use pop-to-buffer (i.e. get the same
behavior as when one set server-window to pop-to-buffer).


        Stefan

Re: emacsclient/server finished, documentation, raising frames

[Kim F. Storm]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> For what it's worth, I think we should remove server-window and change
> server-switch-buffer to always use pop-to-buffer (i.e. get the same
> behavior as when one set server-window to pop-to-buffer).

I agree.

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: emacsclient/server finished, documentation, raising frames

[Juanma Barranquero]

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

> The question is also whether it should be triggered only when calling
> `emacsclient' or also when using C-x # to switch to the next client buffer
> (both call server-switch-buffer).

When you use C-x # Emacs already has the focus. The problem I'm
discussing is that, out of the box, Emacs won't get the focus when
sent a file to edit from emacsclient (which will usually be a CMD
window on the foreground).

> For what it's worth, I think we should remove server-window and change
> server-switch-buffer to always use pop-to-buffer (i.e. get the same
> behavior as when one set server-window to pop-to-buffer).

Why? You're removing choices, and the one you prefer, I dislike: I
don't like pop-to-buffer's behavior of preferring another window (I
want server.el to put the buffer into the selected window); and
pop-to-buffer does not do any raise-frame, so the original problem I'm
discussing is still there.

                    /L/e/k/t/u

Re: emacsclient/server finished, documentation, raising frames

[Andreas Schwab]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> For what it's worth, I think we should remove server-window and change
> server-switch-buffer to always use pop-to-buffer (i.e. get the same
> behavior as when one set server-window to pop-to-buffer).

How can you make emacsclient pop up a new frame without server-window?

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: emacsclient/server finished, documentation, raising frames

[Jason Rumney]

Stefan Monnier wrote:
> The question is also whether it should be triggered only when calling
> `emacsclient' or also when using C-x # to switch to the next client buffer
> (both call server-switch-buffer).
>   
They don't seem to be similar cases. When emacsclient requests a file to 
be loaded, Emacs is unlikely to be on the top of the frame stacks, but 
it is likely that the user wants to immediately work with the file they 
have loaded (assuming emacsclient was called in response to user 
activity). But in the case of C-x #, Emacs is already the focused 
application, so we shouldn't be calling raise-frame unless the buffer 
being switched to is in a different frame than the currently selected frame.

Re: emacsclient/server finished, documentation, raising frames

[Kim F. Storm]

"Juanma Barranquero" <lekktu@gmail.com> writes:

>> For what it's worth, I think we should remove server-window and change
>> server-switch-buffer to always use pop-to-buffer (i.e. get the same
>> behavior as when one set server-window to pop-to-buffer).
>
> Why? You're removing choices, and the one you prefer, I dislike: I
> don't like pop-to-buffer's behavior of preferring another window (I
> want server.el to put the buffer into the selected window); and
> pop-to-buffer does not do any raise-frame, so the original problem I'm
> discussing is still there.

You would have to configure pop-to-buffer via same-window-regexps

But I tend to agree (and disagree with my previous agreement) that
keeping the server-window variable is simpler for most users.

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: emacsclient/server finished, documentation, raising frames

[Juanma Barranquero]

On 11/7/06, Jason Rumney <jasonr@gnu.org> wrote:

> I think this is the best place for it though, as this code has knowledge
> about which frame needs to be raised.

Not if `server-window' is a user function, I think.

-- 
                    /L/e/k/t/u

Re: emacsclient/server finished, documentation, raising frames

[Stefan Monnier]

>> The question is also whether it should be triggered only when calling
>> `emacsclient' or also when using C-x # to switch to the next client buffer
>> (both call server-switch-buffer).

> When you use C-x # Emacs already has the focus.  The problem I'm
> discussing is that, out of the box, Emacs won't get the focus when
> sent a file to edit from emacsclient (which will usually be a CMD
> window on the foreground).

I understand that.  But a change in server-switch-buffer will affect both
cases, so we have to take it into account.

>> For what it's worth, I think we should remove server-window and change
>> server-switch-buffer to always use pop-to-buffer (i.e. get the same
>> behavior as when one set server-window to pop-to-buffer).

> Why? You're removing choices, and the one you prefer, I dislike: I
> don't like pop-to-buffer's behavior of preferring another window (I
> want server.el to put the buffer into the selected window); and
> pop-to-buffer does not do any raise-frame, so the original problem I'm
> discussing is still there.

I take your objection to mean that you agree with my proposition, at the
condition that we improve pop-to-buffer's configurability.  I would agree
with you, then,


        Stefan

Re: emacsclient/server finished, documentation, raising frames

[Stefan Monnier]

>> For what it's worth, I think we should remove server-window and change
>> server-switch-buffer to always use pop-to-buffer (i.e. get the same
>> behavior as when one set server-window to pop-to-buffer).
> How can you make emacsclient pop up a new frame without server-window?

I don't understand the question: how do you currently do it with
server-window?  I do it by setting server-window to pop-to-buffer and then
setting pop-up-frames to t.


        Stefan

Re: emacsclient/server finished, documentation, raising frames

[Andreas Schwab]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> I don't understand the question: how do you currently do it with
> server-window?

By defining it to a function that creates a new frame.

>  I do it by setting server-window to pop-to-buffer and then
> setting pop-up-frames to t.

This definitely I don't want.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: emacsclient/server finished, documentation, raising frames

[Juanma Barranquero]

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

> I understand that.  But a change in server-switch-buffer will affect both
> cases, so we have to take it into account.

Yes. Still, Jason's right, I think, that it is the place to modify if
we add a user option to raise the frame (raising the frame, I note,
was the point of this thread :)

> I take your objection to mean that you agree with my proposition, at the
> condition that we improve pop-to-buffer's configurability.

No. I can perfectly imagine using a function for `server-window'. And
I don't want to mess with `same-window-regexps' and friends just to be
able to edit a file with emacsclient.

                    /L/e/k/t/u

Re: emacsclient/server finished, documentation, raising frames

[Juanma Barranquero]

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

> I don't understand the question: how do you currently do it with
> server-window?  I do it by setting server-window to pop-to-buffer and then
> setting pop-up-frames to t.

That's because (I pressume that) you use and like pop-up-frames. But
if you generally use just one frame, and want another for stuff sent
from emacsclient, you can use `server-window': either pre-create a
frame, iconize it, and set server-window to it, or use a server-window
function to create the frame on demand.

-- 
                    /L/e/k/t/u

Re: emacsclient/server finished, documentation, raising frames

[Stefan Monnier]

>> I take your objection to mean that you agree with my proposition, at the
>> condition that we improve pop-to-buffer's configurability.

> No.  I can perfectly imagine using a function for `server-window'.

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

So the question is: for what would you "use a function for `server-window'"?
Would display-buffer-function work as well?

> And I don't want to mess with `same-window-regexps' and friends just to be
> able to edit a file with emacsclient.

I said "improve pop-to-buffer's configurability" specifically because using
same-window-regexps is not a solution.  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.


        Stefan

Re: emacsclient/server finished, documentation, raising frames

[Juanma Barranquero]

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

Re: emacsclient/server finished, documentation, raising frames

[Juanma Barranquero]

[-- Attachment #1: Type: text/plain, Size: 1452 bytes --]

Discussion has stagnated, but still something should be done.

So this is a little patch to implement what Jason proposed: an option
to choose whether server.el raises the frame or not when switching to
a buffer.

The patch does *not* try to raise the frame in two situations:

  - In the weird "No server buffers remain to edit" case (which, if I
understand the code correctly, only happens as a result of a user
interaction, and not by calling emacsclient, so focus is not an
issue).^(1)

  - When `server-window' is a function. It is trivial to raise the
frame also in this situation (just moving the `(when
server-raise-window ...)' out of the enclosing `if'), but I feel that
it is better this way. If the user wants to raise the frame, he can do
it easily in his function, and if not, doing it ourselves would only
cause him trouble.^(2)

Does anyone oppose to installing this patch and settling the issue for
now? We can always redesign `server-window' and `server-switch-buffer'
after the release, if needed.

                          /L/e/k/t/u


^(1) BTW, I'd like to know the use case that makes this happen. I've
had to trick Emacs into killing a server-edited buffer without
server.el knowing about it to be able to trigger this part of the
code.

^(2) Counterargument: if the user has a `server-window' function and
doesn't want server.el raising the frame, he can set
`server-raise-frame' to nil. So one way or the other is fine by me.

[-- Attachment #2: server.patch --]
[-- Type: application/octet-stream, Size: 2058 bytes --]

Index: lisp/ChangeLog
===================================================================
RCS file: /cvsroot/emacs/emacs/lisp/ChangeLog,v
retrieving revision 1.10278
diff -u -2 -r1.10278 ChangeLog
--- lisp/ChangeLog	8 Nov 2006 19:22:33 -0000	1.10278
+++ lisp/ChangeLog	9 Nov 2006 01:18:27 -0000
@@ -1,2 +1,7 @@
+2006-11-09  Juanma Barranquero  <lekktu@gmail.com>
+
+	* server.el (server-raise-frame): New option.
+	(server-switch-buffer): Use it.
+
 2006-11-08  Alan Mackenzie  <acm@muc.de>
 
Index: lisp/server.el
===================================================================
RCS file: /cvsroot/emacs/emacs/lisp/server.el,v
retrieving revision 1.120
diff -u -2 -r1.120 server.el
--- lisp/server.el	7 Nov 2006 10:42:52 -0000	1.120
+++ lisp/server.el	9 Nov 2006 01:18:03 -0000
@@ -113,4 +113,10 @@
 (put 'server-auth-dir 'risky-local-variable t)
 
+(defcustom server-raise-frame t
+  "*If non-nil, raise frame when switching to a buffer."
+  :group 'server
+  :type 'boolean
+  :version "22.1")
+
 (defcustom server-visit-hook nil
   "*Hook run when visiting a file for the Emacs server."
@@ -703,9 +709,7 @@
 	  (if (and win (not server-window))
 	      ;; The buffer is already displayed: just reuse the window.
-	      (let ((frame (window-frame win)))
-		(when (eq (frame-visible-p frame) 'icon)
-		  (raise-frame frame))
-		(select-window win)
-		(set-buffer next-buffer))
+              (progn
+                (select-window win)
+                (set-buffer next-buffer))
 	    ;; Otherwise, let's find an appropriate window.
 	    (cond ((and (windowp server-window)
@@ -731,5 +735,8 @@
 	      ;; After all the above, we might still have ended up with
 	      ;; a minibuffer/dedicated-window (if there's no other).
-	      (error (pop-to-buffer next-buffer)))))))))
+	      (error (pop-to-buffer next-buffer))))
+          (when server-raise-frame
+            (select-frame-set-input-focus (window-frame (selected-window))))
+          )))))
 
 (define-key ctl-x-map "#" 'server-edit)

[-- Attachment #3: Type: text/plain, Size: 142 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel

Re: emacsclient/server finished, documentation, raising frames

[Juanma Barranquero]

A curious little problem: using emacsclient on a file with a local
variables section displays the "*local variables*" buffer and
prompt... but does not raise the frame, even with my patch, because
this is happening on the call to `find-file-noselect' (in
`server-visit-files'), way before getting to `server-switch-buffer'.

`hack-local-variables-confirm' could be made to always raise the frame
(there's no much point in asking the user if the user doesn't see the
prompt, and in non-emacsclient-related cases the user is already
interacting with the frame). Or we could simply add a hook to that
function (run before the prompt) and use it from server.el.

                    /L/e/k/t/u

Re: emacsclient/server finished, documentation, raising frames

[Lennart Borgman]

Juanma Barranquero wrote:
> A curious little problem: using emacsclient on a file with a local
> variables section displays the "*local variables*" buffer and
> prompt... but does not raise the frame, even with my patch, because
> this is happening on the call to `find-file-noselect' (in
> `server-visit-files'), way before getting to `server-switch-buffer'.
>
> `hack-local-variables-confirm' could be made to always raise the frame
> (there's no much point in asking the user if the user doesn't see the
> prompt, and in non-emacsclient-related cases the user is already
> interacting with the frame). Or we could simply add a hook to that
> function (run before the prompt) and use it from server.el.
>
>                    /L/e/k/t/u

Could this not be made more general? The crucial thing is the question. 
Maybe a variable that controls whether a frame is raised when a user 
response to a question is required?

Re: emacsclient/server finished, documentation, raising frames

[Juanma Barranquero]

On 11/10/06, Lennart Borgman <lennart.borgman.073@student.lu.se> wrote:

> Could this not be made more general? The crucial thing is the question.

You're right. The same thing would happen, for example, if Emacs wants
to revert a buffer.

> Maybe a variable that controls whether a frame is raised when a user
> response to a question is required?

Good question.

These cases are triggered by server.el, but do not depend on it. It's
a general question whether we want (conditionally) to raise frames
asking for specific interaction from the user.

                    /L/e/k/t/u

Re: emacsclient/server finished, documentation, raising frames

[Juanma Barranquero]

On 11/9/06, Juanma Barranquero <lekktu@gmail.com> wrote:

> The patch does *not* try to raise the frame in two situations:
[...]
>   - When `server-window' is a function. [...] ^(2)
> ^(2) Counterargument: if the user has a `server-window' function and
> doesn't want server.el raising the frame, he can set
> `server-raise-frame' to nil.

I've installed the patch to server.el. I was convinced by my own
counter-argument, so I've changed it and now it also raises the frame
when `server-window' is a function.

                    /L/e/k/t/u

Re: emacsclient/server finished, documentation, raising frames

[Richard Stallman]

    Could this not be made more general? The crucial thing is the question. 
    Maybe a variable that controls whether a frame is raised when a user 
    response to a question is required?

That is such a good idea that it was done years ago
with the variable minibuffer-auto-raise.

Why isn't that feature doing the job for these questions?

Re: emacsclient/server finished, documentation, raising frames

[Lennart Borgman]

Richard Stallman wrote:
>     Could this not be made more general? The crucial thing is the question. 
>     Maybe a variable that controls whether a frame is raised when a user 
>     response to a question is required?
>
> That is such a good idea that it was done years ago
> with the variable minibuffer-auto-raise.
>
> Why isn't that feature doing the job for these questions?
>   

Maybe because the default value is nil? Or maybe because it does not 
distinguish between focus and raise? In some situations (=ediff) this 
seems important.

Re: emacsclient/server finished, documentation, raising frames

[Juanma Barranquero]

On 11/11/06, Richard Stallman <rms@gnu.org> wrote:

> That is such a good idea that it was done years ago
> with the variable minibuffer-auto-raise.

:)

> Why isn't that feature doing the job for these questions?

Mainly because I didn't know about it.  I've now installed a patch to
bind `minibuffer-auto-raise' to the value of `server-raise-frame'
while visiting or reverting a buffer in server.el.

Thanks,

                    /L/e/k/t/u

Re: emacsclient/server finished, documentation, raising frames

[Richard Stallman]

    Mainly because I didn't know about it.  I've now installed a patch to
    bind `minibuffer-auto-raise' to the value of `server-raise-frame'
    while visiting or reverting a buffer in server.el.

It should probably bind it to (or minibuffer-auto-raise server-raise-frame).

Re: emacsclient/server finished, documentation, raising frames

[Juanma Barranquero]

On 11/12/06, Richard Stallman <rms@gnu.org> wrote:

> It should probably bind it to (or minibuffer-auto-raise server-raise-frame).

Yes, I thought so just after committing the patch :(

                    /L/e/k/t/u