>>>> Package: eom >>>> Version: 1.26.0-1 >>>> Severity: normal >>>> X-Debbugs-Cc: none, Francesco Potortì <poto...@isti.cnr.it> >>>> >>>> I have eom woth a window opened on display :7 >>>> >>>> If I call it on display :0 it just exits without messages. >>>> >>>> Killing it on display :7 fixes the problem. >>>> >>>> This is what I get on ~/.xsession-errors: >>>> >>>> Window manager warning: Buggy client sent a _NET_ACTIVE_WINDOW >>>> message with a timestamp of 0 for 0x5200007 (Eye of MAT) >>>> Window manager warning: meta_window_activate called by a pager with >>>> a 0 timestamp; the pager needs to be fixed. >>>> >>> >>> Please try "dbus-run-session eom" on your second $DISPLAY. This is a >>> DBus session specific feature added with Debian 9 or 10. >> >> Sort of works. I am using Xpra remotely on display :7. Emacs is >> running on the server on :0. I create an Emacs frame on display :7 >> so that I can access it from home. An Eom process is running on :0. >> From the Emacs frame on :7 I call eom and it exits without >> messages. Then I call dbus-run-session eom and it spits the >> following: >> >> [...] > >I'd rather recommend starting Emacs on :7 with dbus-run-session. In >fact, Xpra should be bright enough to handle this for you.
In fact, I start Emacs on the server with Screen runing on a virtual terminal on :0. Then, from there, I create a frame on the server display :0 and one more on the Xpra display :7. I then work on the server, both on a virtual terminal and on display :0 when I am at the office and Screen and Xpra over ssh when I am out of office. I think it is already awfully complex as is, and launching Emacs from :7 would expose my long-running Emacs process to one more layer of software (Xpra) with possible instabilities. I often run programs from inside Emacs and launch them without worrying where from, like Libreoffice, Gnumeric, Inkscape, Atril, and not one of them has had problems (until now, at least) with having windows on both :0 and :7 displays. As far as I can tell, Eom requiring a specific trick to obtain seamless behaviour should be seen as a regression. Even if there was a good reason to forcing the user to use the dbus trick, I think that the delay and the warning messages that I observed shouldn't be seen as normal.
