* bug#17111: 24.3.50; server: C-x # inconsistent and barely documented
@ 2014-03-26 23:47 Michael Heerdegen
2014-03-27 14:31 ` Stefan Monnier
0 siblings, 1 reply; 2+ messages in thread
From: Michael Heerdegen @ 2014-03-26 23:47 UTC (permalink / raw)
To: 17111
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
^ permalink raw reply [flat|nested] 2+ messages in thread
* bug#17111: 24.3.50; server: C-x # inconsistent and barely documented
2014-03-26 23:47 bug#17111: 24.3.50; server: C-x # inconsistent and barely documented Michael Heerdegen
@ 2014-03-27 14:31 ` Stefan Monnier
0 siblings, 0 replies; 2+ messages in thread
From: Stefan Monnier @ 2014-03-27 14:31 UTC (permalink / raw)
To: Michael Heerdegen; +Cc: 17111
> 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.
IIUC the behavior was "designed" without taking into account the many
different use cases (e.g. it was designed in a single-frame context), so
there is probably no such thing as a "behavior [that] was intended" for
those cases you mention.
> 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.
I think C-x # deserves a good rethink/redesign, yes.
Stefan
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2014-03-27 14:31 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2014-03-26 23:47 bug#17111: 24.3.50; server: C-x # inconsistent and barely documented Michael Heerdegen
2014-03-27 14:31 ` Stefan Monnier
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.