bug#57939: 29.0.50; Fixing raise-frame on Sway

bug#57939: 29.0.50; Fixing raise-frame on Sway

[Sean Whitton]

Under Sway, with pgtk, raise-frame doesn't work.  We could make it work
by using Sway's IPC to send a request to "focus" the frame.  This can be
done without invoking any external processes, but here is a hack using
swaymsg(1) just as a demonstration:

    (defun spw/sway-raise-frame (orig-fun &optional frame)
      (unless frame (setq frame (selected-frame)))
      (if (member "XDG_CURRENT_DESKTOP=sway"
                  (frame-parameter frame 'environment))
          (call-process "swaymsg" nil nil nil
    		    (format "[title=\"%s\"]"
                            (frame-parameter frame 'name))
    		    "focus")
        (funcall orig-fun frame)))
    (advice-add 'raise-frame :around #'spw/sway-raise-frame)

On the one hand, Sway is one of the more popular Wayland compositors, so
it would be nice to support this.  On the other hand, this isn't a
generic wlroots mechanism -- it will work only for Sway.  (I suppose
it's possible that some other compositors will adopt Sway's IPC.)

Would this be an appropriate thing to add to raise-frame?  Or is it
better left as a piece of advice?  The IPC protocol is documented here:
<https://manpages.debian.org/sway-ipc>.

-- 
Sean Whitton

bug#57939: 29.0.50; Fixing raise-frame on Sway

[Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Sean Whitton <spwhitton@spwhitton.name> writes:

> Under Sway, with pgtk, raise-frame doesn't work.  We could make it work
> by using Sway's IPC to send a request to "focus" the frame.  This can be
> done without invoking any external processes, but here is a hack using
> swaymsg(1) just as a demonstration:
>
>     (defun spw/sway-raise-frame (orig-fun &optional frame)
>       (unless frame (setq frame (selected-frame)))
>       (if (member "XDG_CURRENT_DESKTOP=sway"
>                   (frame-parameter frame 'environment))
>           (call-process "swaymsg" nil nil nil
>     		    (format "[title=\"%s\"]"
>                             (frame-parameter frame 'name))
>     		    "focus")
>         (funcall orig-fun frame)))
>     (advice-add 'raise-frame :around #'spw/sway-raise-frame)

> On the one hand, Sway is one of the more popular Wayland compositors, so
> it would be nice to support this.  On the other hand, this isn't a
> generic wlroots mechanism -- it will work only for Sway.  (I suppose
> it's possible that some other compositors will adopt Sway's IPC.)

If there's anything I've learned in over 2 decades of dealing with
windowing on GNU/Linux, it's that these mechanisms tend to be yanked
from underneath our feet.  It sounds very risky to add support for that
to such a basic function in Emacs.

In addition, raise-frame is not really supposed to focus the frame.  But
I guess that's unavoidable here.

And what if there are multiple frames with the same name? What frame is
raised in that case?

So thanks, but this is not really the right thing for Emacs.

bug#57939: 29.0.50; Fixing raise-frame on Sway

[Sean Whitton]

Hello,

On Tue 20 Sep 2022 at 09:30AM +08, Po Lu wrote:

> If there's anything I've learned in over 2 decades of dealing with
> windowing on GNU/Linux, it's that these mechanisms tend to be yanked
> from underneath our feet.  It sounds very risky to add support for that
> to such a basic function in Emacs.

Sway is pretty committed to interface stability, but it's a valid concern.

> And what if there are multiple frames with the same name? What frame is
> raised in that case?

Yeah, we'd need to make a more precise IPC query to get some sort of
unique handle.

-- 
Sean Whitton

bug#57939: 29.0.50; Fixing raise-frame on Sway

[Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Sean Whitton <spwhitton@spwhitton.name> writes:

> Sway is pretty committed to interface stability, but it's a valid concern.

I'm not worried about whether or not Sway keeps the interface stable,
the problem is whether or not Sway will still be a thing in 2, 5, 10, or
20 years.

Not to mention that Sway is still a niche compositor, compared to the
likes of GNOME Shell or Kwin.

If we take the route of supporting non-standard interfaces provided by
all "popular" Wayland compositors at any given time, then we will
quickly fall into the rabbit hole of constantly keeping up with changes
to that status quo.

bug#57939: 29.0.50; Fixing raise-frame on Sway

[Lars Ingebrigtsen]

Po Lu via "Bug reports for GNU Emacs, the Swiss army knife of text
editors" <bug-gnu-emacs@gnu.org> writes:

> I'm not worried about whether or not Sway keeps the interface stable,
> the problem is whether or not Sway will still be a thing in 2, 5, 10, or
> 20 years.

That is indeed a worry.

> Not to mention that Sway is still a niche compositor, compared to the
> likes of GNOME Shell or Kwin.
>
> If we take the route of supporting non-standard interfaces provided by
> all "popular" Wayland compositors at any given time, then we will
> quickly fall into the rabbit hole of constantly keeping up with changes
> to that status quo.

There's no set rules for any of this -- but we want Emacs to be as
usable as possible across as large a number of systems as possible.
This means that we have a lot of special purpose code in Emacs to work
around oddities in systems, and to interact with specific systems and
libraries.

Sway seems to be one of the major players in the Wayland world, so I'd
welcome code to make Emacs work better under Sway.