emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
From: Ihor Radchenko <yantar92@posteo.net>
To: Max Nikulin <manikulin@gmail.com>
Cc: emacs-orgmode@gnu.org
Subject: Re: org-x11idle-exists-p with emacs --daemon
Date: Sun, 30 Oct 2022 01:33:30 +0000	[thread overview]
Message-ID: <87mt9egknp.fsf@localhost> (raw)
In-Reply-To: <tjj6i1$uos$1@ciao.gmane.io>

Max Nikulin <manikulin@gmail.com> writes:

> On 28/10/2022 11:28, Ihor Radchenko wrote:
>> 
>> * lisp/org-clock.el (org-x11idle-exists-p): Do not check if load-time
>> `window-system' is `x'.  Instead, rely on the check in
>> `org-user-idle-seconds'.
>
> I would say that even there it is not strictly correct to test 
> `window-system', perhaps `x-display-list' is a bit better since 
> particular frame may be a terminal one running in xterm, but user has x 
> frames.

I am not sure here.

Let us first establish the purpose of all this fiddling with idle
program.

`org-user-idle-seconds' is aiming to find the actual idle time of an Org
user. Not just in Emacs, but also in other places. That's why the
fallback `org-emacs-idle-seconds' is not the most accurate, and we are
trying to use other, more accurate, means to determine idle time.

`org-user-idle-seconds' uses system command to determine idle time, when
possible. On Mac, such command is always available. On X11, Org defaults
to https://git.sr.ht/~bzg/worg/tree/master/item/code/scripts/x11idle.c
script that will fail to work from non-X frame, AFAIU.

So, I do think the `window-system' is the right way to invoke x11idle at
least. Terminal frames may not have access to X11 scope and thus will
not be able to determine the real idle time. Not to mention that
terminal Emacs may not be running on X and even successfully getting
idle time will yield erroneous results.

> In server.el I found
>
>      (frame-parameter frame 'display)
>
> that might be even better and should work with daemon having a single 
> frame in xterm. I can not figure out if --display command line option 
> affects some variable of Emacs daemon.

I do not understand. I just tried to check the value of `window-system'
in terminal Emacs frame and in X11 Emacs frame running using the same
Emacs daemon. The value in X11 frame is 'x and nil in terminal. So,
`window-system' already accounts for current frame.

> Another tricky case is multiple x connection to different displays. It 
> seems GTK3 have some limitations (pgtk build) and such rarely used 
> configuration will become completely obsolete.

Multiple X connection means non-deterministic idle time. Each individual
X server will have its own idle time. The current approach with running
`org-x11-idle-seconds' in current frame is the most reasonable in such
scenario, IMHO.

>> diff --git a/lisp/org-clock.el b/lisp/org-clock.el
>> index e98a34f0d..ca026c44f 100644
>> --- a/lisp/org-clock.el
>> +++ b/lisp/org-clock.el
>> @@ -1201,8 +1201,7 @@ (defun org-mac-idle-seconds ()
>>  
>>  (defvar org-x11idle-exists-p
>>    ;; Check that x11idle exists
>> -  (and (eq window-system 'x)
>> -       (eq 0 (call-process-shell-command
>> +  (and (eq 0 (call-process-shell-command
>>                (format "command -v %s" org-clock-x11idle-program-name)))
>
> I joined to this discussion presuming (by some confusion) that such 
> variable should be lazily initialized on first call of 
> `org-user-idle-seconds'. I considered `window-system' test as a way to 
> distinguish GUI and text Emacs sessions. Actually such parameter is 
> dynamic. Remotely running Emacs may be disconnected from one X server 
> and connected to another session.
>
> Actually `window-system' check has another role: skip command 
> availability test on systems other than Linux.
>
> What is the result of "command -v" on Windows? Should it be executed 
> there at all (unconditionally at load time)?

It will fail and the value of `org-x11idle-exists-p' will be nil. I do
not see any problem here.

> P.S. There are a number of X11 servers for Windows. I am unsure if Emacs 
> builds for Windows and X11 frames are supported. I am lost how to 
> properly test such cases in the code.

We do not care. We check if idle program works by calling it. If it
fails (due to command being not available or not supporting the X11
server), we fall back to safe approach using Emacs idle time.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>


  reply	other threads:[~2022-10-30  1:34 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-10-27 22:31 org-x11idle-exists-p with emacs --daemon Julien Cubizolles
2022-10-28  3:08 ` Max Nikulin
2022-10-28  4:29   ` Ihor Radchenko
2022-10-28  4:39     ` Max Nikulin
2022-10-28  5:19       ` Ihor Radchenko
2022-10-28  4:28 ` Ihor Radchenko
2022-10-28 21:48   ` Julien Cubizolles
2022-10-29  2:54     ` Ihor Radchenko
2022-10-29 12:33   ` Max Nikulin
2022-10-30  1:33     ` Ihor Radchenko [this message]
2022-10-30  6:20       ` Max Nikulin
2022-10-31  2:50         ` Ihor Radchenko
2022-10-31  2:53         ` Change default value of org-clock-x11-idle-program-name (was: org-x11idle-exists-p with emacs --daemon) Ihor Radchenko
2023-01-24 12:41           ` [PATCH] Change default value of org-clock-x11-idle-program-name Ihor Radchenko
2023-01-26 15:43             ` Max Nikulin
2023-01-27 10:20             ` Ihor Radchenko

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.orgmode.org/

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

  git send-email \
    --in-reply-to=87mt9egknp.fsf@localhost \
    --to=yantar92@posteo.net \
    --cc=emacs-orgmode@gnu.org \
    --cc=manikulin@gmail.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/org-mode.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).