GNU logs - #17111, boring messages

Message sent to bug-gnu-emacs@HIDDEN:

Subject: bug#17111: 24.3.50; server: C-x # inconsistent and barely documented
Resent-From: Michael Heerdegen <michael_heerdegen@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Wed, 26 Mar 2014 23:48:02 +0000
Resent-Message-ID: <handler.17111.B.139587768129217 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
To: 17111 <at> debbugs.gnu.org
From: Michael Heerdegen <michael_heerdegen@HIDDEN>
Date: Thu, 27 Mar 2014 00:47:08 +0100
Message-ID: <8761n0wmir.fsf@HIDDEN>
MIME-Version: 1.0
Content-Type: text/plain
Precedence: list
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>

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

Message sent:

Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Mailer: MIME-tools 5.503 (Entity 5.503)
Content-Type: text/plain; charset=utf-8
X-Loop: help-debbugs@HIDDEN
From: help-debbugs@HIDDEN (GNU bug Tracking System)
To: Michael Heerdegen <michael_heerdegen@HIDDEN>
Subject: bug#17111: Acknowledgement (24.3.50; server: C-x # inconsistent
 and barely documented)
Message-ID: <handler.17111.B.139587768129217.ack <at> debbugs.gnu.org>
References: <8761n0wmir.fsf@HIDDEN>
X-Gnu-PR-Message: ack 17111
X-Gnu-PR-Package: emacs
Reply-To: 17111 <at> debbugs.gnu.org
Date: Wed, 26 Mar 2014 23:48:02 +0000

Thank you for filing a new bug report with debbugs.gnu.org.

This is an automatically generated reply to let you know your message
has been received.

Your message is being forwarded to the package maintainers and other
interested parties for their attention; they will reply in due course.

Your message has been sent to the package maintainer(s):
 bug-gnu-emacs@HIDDEN

If you wish to submit further information on this problem, please
send it to 17111 <at> debbugs.gnu.org.

Please do not send mail to help-debbugs@HIDDEN unless you wish
to report a problem with the Bug-tracking system.

--=20
17111: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=3D17111
GNU Bug Tracking System
Contact help-debbugs@HIDDEN with problems

Message sent to bug-gnu-emacs@HIDDEN:

Subject: bug#17111: 24.3.50; server: C-x # inconsistent and barely documented
Resent-From: Stefan Monnier <monnier@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Thu, 27 Mar 2014 14:32:01 +0000
Resent-Message-ID: <handler.17111.B17111.139593069831830 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
To: Michael Heerdegen <michael_heerdegen@HIDDEN>
Cc: 17111 <at> debbugs.gnu.org
From: Stefan Monnier <monnier@HIDDEN>
Message-ID: <jwvha6jzpf4.fsf-monnier+emacsbugs@HIDDEN>
References: <8761n0wmir.fsf@HIDDEN>
Date: Thu, 27 Mar 2014 10:31:23 -0400
In-Reply-To: <8761n0wmir.fsf@HIDDEN> (Michael Heerdegen's message of "Thu, 27
 Mar 2014 00:47:08 +0100")
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain
Precedence: list
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>

> 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

Last modified: Mon, 25 Nov 2019 12:00:02 UTC

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997 nCipher Corporation Ltd, 1994-97 Ian Jackson.