bug#17111: 24.3.50; server: C-x # inconsistent and barely documented

[Michael Heerdegen]

Hello,

the doc of server-edit (bound to C-x #) says:

| Switch to next server editing buffer; say "Done" for current buffer.

It doesn't tell how this switching is done, and how it can be
configured.  There seem to be several variables that influence the
behavior, e.g. `server-kill-new-buffers' or `server-raise-frame'.
These, and maybe others, must be mentioned.

But even with the default settings, the behavior is so wild and
inconsistent that I can't even guess how this is supposed to work.  Here
are some examples, they all start with emacs -Q, M-x server-start, and
an xterm on the desktop I use to call emacsclient.  So, at the beginning
I always have an xterm and one Emacs frame showing *scratch*.


Example 1:  In xterm I enter

     emacsclient -c /path/to/file

A new frame showing FILE pops up.  I close the other Emacs frame
(showing scratch).  After editing FILE, I hit C-x #.  I get an error:

server-delete-client: Attempt to delete the sole visible or iconified
frame

This error does always happen if you have only one frame with one window
showing a client buffer.


Example 2a: I open two files from xterm:

    emacsclient -c /path/to/file1
    emacsclient -c /path/to/file2

The frame showing FILE2 has input focus.  I hit C-x #.  The frame is
killed, and the frame showing FILE1 gets focus.  Ok.

Example 2b: The same as in a, but now, after calling

   emacsclient -c /path/to/file1

I "work" a bit in Emacs and create a new frame.  Then I enter

   emacsclient -c /path/to/file2

in xterm.  Once again, the frame showing FILE2 has input focus.  I edit
it and hit C-x #.  This time, Emacs loses input focus, now the xterm is
raised.  Strange.


Example 3: I start with emacsclient -c /path/to/file (only one file
involved this time).  I need to view it in dired, I hit C-x d RET.  I
select the other frame showing *scratch*, do some stuff, and there hit
C-x #.  I get the message

   No server buffers remain to edit

That is obviously wrong.


Comments:

- this is all quite the same when using a daemon Emacs

- in examples 2a,b, setting `server-raise-frame' to nil makes the
  behavior more consistent: the xterm has always focus

- Note that Emacs is clearly involved in giving its frames input focus.
  When `server-raise-frame' is t, `server-switch-buffer' can call
  `select-frame-set-input-focus'.  So, any window manager can't be the
  cause of the different behavior in 2a,b - because it's Emacs that in
  one case selects another frame, and doesn't do so in the other case.

- The example 3 misbehavior happens because `server-switch-buffer' checks
  this:

    (when (or (not (process-get proc 'frame))
              (eq (process-get proc 'frame) (selected-frame)))
        (setq next-buffer (car (process-get proc 'buffers))))

which is not fulfilled if (process-get proc 'frame) returns a frame,
regardless of whether this frame (still) displays any client buffer or
not.

- the problem in example 1 is probably easy to fix


I don't want to call anything here a bug too loudly, because I don't
know which behavior was intended, and it's hard to guess without any
doc.  But server.el is probably one of the things most newbies try first
with Emacs, so it would be a good advertisement if C-x # would be better
documented and the behavior would be consistent.


Thanks,

Michael.



In GNU Emacs 24.3.50.1 (x86_64-unknown-linux-gnu, GTK+ Version 3.10.7)
 of 2014-03-25 on drachen
Windowing system distributor `The X.Org Foundation', version 11.0.11500000
System Description:     Debian GNU/Linux testing (jessie)

Important settings:
  value of $LC_ALL: de_DE.utf8
  value of $LC_COLLATE: C
  value of $LC_TIME: C
  value of $LANG: de_DE.utf8
  locale-coding-system: utf-8-unix

Major mode: Emacs-Lisp