It was worth reading and emotionally stimulating.
Thanks for writing.

Understood. It seems that the original purpose was different,
so it cannot be replaced with another function.
Thank you for the implementation.
I'm pleased it has become more convenient.

Thanks. As far as I'm briefly testing it now, it doesn't seem to have any glitches.

I think it would be easy to understand if you could do the same thing with 'swayr nop <CRITERIA>' as below, but what do you think?

```
$ swayr get-windows-as-json --error-if-no-match --matching '[app_name="foot"]' >/dev/null ; echo $?
0
$ swayr get-windows-as-json --error-if-no-match --matching '[app_name="foott"]' >/dev/null ; echo $?
Error: "No matching windows"
1
$ 
```

Sorry, my example was a bit wrong. It is as follows.

```
$ swaymsg '[app_id="foot"]' nop ; echo $?
0
$ swaymsg '[app_id="foott"]' nop ; echo $?
Error: No matching node.
2
$
```

`swaymsg <criteria> nop` returns a non-zero return value on failure,
allowing conditional decisions for use in scripting.

```
$ swaymsg '[app_id="foot"]' nop ; echo $?
0
$ swaymsg '[app_id="foot"]' nop ; echo $?
Error: No matching node.
2
$
```

I think it would be useful if the swayr nop command could do this as well.

Thanks again.

A discussion has been opened to discuss merging a patch created by rkta
that adds gemini support to w3m.

https://github.com/tats/w3m/issues/264

If you would like to help, please give +1 to emoticon and other support.

The patch is here, which is very useful because it allows seamless use
of www, gemini and gopher.

https://rkta.de/w3m-gemini.html

> I like it very much that swayr has no dependencies other than sway and
> some menu program of the user's choice.  Having an optional feature
> requiring some optional third-party tool would not be the end of the
> world but complicate things for both users and me as the maintainer.

Indeed it is.
I guess I should hold off on this idea until 
we or someone comes up with an alternative.

Thanks for all your kindness.

> So long story short: I don't intend to implement features in swayr which
> require anything else than sway IPC (the menu program being a notable
> exception, of course).

For example, even if there were an external tool that just returned the 
absolute position of the mouse pointer on the sway when executed, 
wouldn't you want to use something that depends on something other than the 
sway?

> Apparently, it seems to have the ability to move the pointer but no
> means to query the current location...

I don't know much about this, so sorry if I'm missing the point.
Is it possible to do this using the following wlroots functions, etc.?

    - /usr/lib/libwlroots.so
    - /usr/include/wlr/types/wlr_virtual_pointer_v1.h

> Given that seat deals with absolute positions, I think that would be
> quite cumbersome.  And I think it's totally common to have the mouse
> cursor not on the focused window but somewhere else in which case a
> relative position would be quite useless, at least when a window got
> moved.

I understand, it certainly seems like a hassle. I think you are right, absolute
position is fine.
On top of that, just ignoring the pointer position if the restored pointer 
position is outside the window's range might be about right.

> That's not feasible for swayr.  I can only intercept events but that
> don't tell why and how some node was moved.