unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Daniel Colascione <dancol@dancol.org>
To: Po Lu <luangruo@yahoo.com>
Cc: 57012@debbugs.gnu.org
Subject: bug#57012: Activating versus raising frames
Date: Sat, 06 Aug 2022 23:11:24 -0400	[thread overview]
Message-ID: <18276492f60.2829.cc5b3318d7e9908e2c46732289705cb0@dancol.org> (raw)
In-Reply-To: <87pmhc21t3.fsf@yahoo.com>

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



On August 6, 2022 23:03:04 Po Lu <luangruo@yahoo.com> wrote:

> Daniel Colascione <dancol@dancol.org> writes:
>
>> pgtk also runs on X, and the problem must be solved there in some
>> manner.
>
> It does not.  We do not support running the PGTK build on X (the
> selection code doesn't work on X, for example), and there is no way to
> "touch" the user time on that platform without relying on X11-specific
> code.  At present, it's not even possible to include gdk/gdkx.h there
> due to typedef conflicts with dispextern.h

I'm surprised to hear that considering that many other GTK applications 
manage selections adequately. If the intent of pgtk is to run only on 
Wayland, you should break the pgtk build at runtime if it's running under 
X11, and probably rename it too --- because "pure GTK" sounds like it 
should rely only on things GTK provides and that it should therefore run 
anywhere GTK does. If in fact it's just a Wayland window system 
implementation, call it that.

>
>
>> GTK has no magic facility for knowing that emacsclient
>> ran. Regardless, a terminal hook is not expensive, and I don't want to
>> add yet more window system typecases to the code. Terminal access
>> should be polymorphic. It's through terminal hooks that we make them
>> polymorphic. I'm not removing the terminal hook.
>
> After thinking a bit, I figure that a better way to solve the problem
> would be to document that window managers don't always respect
> x-focus-frame, and to add a force parameter which makes it query for the
> current server time and set it as the user time, thus making focus
> setting more reliable.


I don't agree. Telling Emacs that a user has interacted with a frame is not 
an X specific concept. And even in the context of X11, we should be 
resetting the user time generally, not just hacking something up for the 
special case of x-focus-frame, because 1) the general approach preserves 
timestamp monotonicity, and 2) the user did in fact interact with the frame.


>
> Thanks.


[-- Attachment #2: Type: text/html, Size: 3954 bytes --]

  reply	other threads:[~2022-08-07  3:11 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-08-06  0:54 bug#57012: Activating versus raising frames Daniel Colascione
2022-08-06  1:44 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-08-06 23:57   ` Daniel Colascione
2022-08-07  1:55     ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-08-07  2:07       ` Daniel Colascione
2022-08-07  2:45         ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-08-07  2:52           ` Daniel Colascione
2022-08-07  3:02             ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-08-07  3:11               ` Daniel Colascione [this message]
2022-08-07  3:29                 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-08-07  4:10                   ` Daniel Colascione
2022-08-07  4:29                     ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-08-07  4:59                       ` Daniel Colascione
2022-08-07  5:27                         ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-10-20 11:30                           ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=18276492f60.2829.cc5b3318d7e9908e2c46732289705cb0@dancol.org \
    --to=dancol@dancol.org \
    --cc=57012@debbugs.gnu.org \
    --cc=luangruo@yahoo.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).