help-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: closing emacsclient always focuses another emacs window


From: Michael Heerdegen
Subject: Re: closing emacsclient always focuses another emacs window
Date: Wed, 12 Mar 2014 01:31:58 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux)

Eli Zaretskii <eliz@gnu.org> writes:

> > From: Michael Heerdegen <michael_heerdegen@web.de>
> > Date: Tue, 11 Mar 2014 05:25:43 +0100
> > 
> > Michael Heerdegen <michael_heerdegen@web.de> writes:
> > 
> > > IMHO the only problem is the vague name and documentation of the
> > > option
> > > `server-raise-frame'
> > 
> > No, that can't be all.  Because the behavior depends on the fact which
> > buffer is coincidentally selected by Emacs when it deletes the frame
> > after hitting C-x #.  That can't have been the intention of the
> > author.
>
> Why not?

Because in one case, Emacs looses input focus, and in another, Emacs
keeps it.  And because the doc of C-x # says that there will always be a
frame raised, which is obviously not the case.

> Anyway, now I'm utterly confused.

Sorry about that.  You seemed to deny that there is a problem.  So I
argued that there is absolutely no clear description in the
documentation of how C-x # should behave, for no case, so it's
impossible to says what behavior is right and what is a bug.  So I
showed that the behavior is not even consistent, and I proved that the
cause of the inconsistent behavior is in the code in server.el.  What
could I do more to show that there _is_ a problem?

> First, the OP's description of the
> problem included iconified frames -- did you do your testing like he
> described?

I tested with gui frames.  And yes, Emacs even raises and focuses
iconified frames.

> Second, I'm still unsure whether we are talking about GUI or TTY
> frames; in the latter case, I'm sure you will agree that
> select-frame-set-input-focus will never give focus to any TTY frame.

I tried with GUI frames.

> Last, but not least, AFAIK the effect of select-frame-set-input-focus
> on the GUI frame that gets focus does depend on the window manager to
> some extent.

In my experiments, this function always in effect raised the argument
frame and set input focus to exactly that frame.  But whether Emacs
calls `select-frame-set-input-focus' after hitting C-x # is not
consistent, so no window manager could have the effect of making the
behavior consistent again.

> In any case, I suggest to report the full detailed description of the
> issue via "M-x report-emacs-bug", and include there suggestions to fix
> the doc strings, if you still think they need fixing.

trygve.flathen, can you please file a bug report (M-x report-emacs-bug)
with your original problem and a recipe?  I'll then step in and add what
I found out and some words about missing documentation.

But if you happen to find out that setting `server-raise-frame' to nil
does what you want, then I suggest that you don't file the report.  In
that case, I'll just report the missing doc and strange behavior.
Thanks.


Regards,

Michael.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]