Changes the empty string io/key.Set to represent all key events.
This restores backwards compatibility with how key.InputOp worked
before commit 380f96b3fc9b9fd99b440ab3d228a22ea2267dc6.

Signed-off-by: aarzilli <alessandro.arzilli@gmail.com>
---
 io/key/key.go         | 3 +++
 io/router/key_test.go | 2 +-
 2 files changed, 4 insertions(+), 1 deletion(-)

diff --git a/io/key/key.go b/io/key/key.go
index af31e3e6..17f775e3 100644
--- a/io/key/key.go
+++ b/io/key/key.go
@@ -229,6 +229,9 @@ func (m Modifiers) Contain(m2 Modifiers) bool {
 }
 
 func (k Set) Contains(name string, mods Modifiers) bool {
+	if k == "" {
+		return true
+	}
 	ks := string(k)
 	for len(ks) > 0 {
 		// Cut next key expression.
diff --git a/io/router/key_test.go b/io/router/key_test.go
index b8dc9e92..6767dd64 100644
--- a/io/router/key_test.go
+++ b/io/router/key_test.go
@@ -335,7 +335,7 @@ func TestKeyRouting(t *testing.T) {
 	key.InputOp{Tag: &handlers[2], Keys: "A"}.Add(ops)
 	cl1.Pop()
 	cl2 := rect.Push(ops)
-	key.InputOp{Tag: &handlers[3]}.Add(ops)
+	key.InputOp{Tag: &handlers[3], Keys: "C"}.Add(ops)
 	key.InputOp{Tag: &handlers[4], Keys: "A"}.Add(ops)
 	cl2.Pop()
 	call := macro.Stop()
-- 
2.25.1

gio/patches: SUCCESS in 27m2s

[io/key: add way to receive all key events][0] from [aarzilli][1]

[0]: https://lists.sr.ht/~eliasnaur/gio-patches/patches/38626
[1]: alessandro.arzilli@gmail.com

✓ #932549 SUCCESS gio/patches/openbsd.yml https://builds.sr.ht/~eliasnaur/job/932549
✓ #932548 SUCCESS gio/patches/linux.yml   https://builds.sr.ht/~eliasnaur/job/932548
✓ #932547 SUCCESS gio/patches/freebsd.yml https://builds.sr.ht/~eliasnaur/job/932547
✓ #932546 SUCCESS gio/patches/apple.yml   https://builds.sr.ht/~eliasnaur/job/932546

May I ask what prompted this patch? The change was made to be
able to route key events to several interested input handlers.
Effectively reverting that change will make it too easy to
catch every key event, thus blocking, say, top-level input
handlers.

Perhaps the API can be designed differently to suit your needs.

Elias

I have been upgrading nucular to the last version of gio. Previously it was
stuck on a version from april 2021 because I didn't have time to keep up
with the API changes.
Nucular wants to read all the keyboard and mouse event all the time, there
is no concept of event handling.

On Mon, Feb 06, 2023 at 12:12:43PM -0600, Elias Naur wrote:
> May I ask what prompted this patch? The change was made to be
> able to route key events to several interested input handlers.
> Effectively reverting that change will make it too easy to
> catch every key event, thus blocking, say, top-level input
> handlers.
> 
> Perhaps the API can be designed differently to suit your needs.
> 
> Elias

I sent a patch that may fix your issue in a less intrusive way.
WDYT?

Elias

Ping?

On Mon, Feb 06, 2023 at 05:17:07PM -0600, Elias Naur wrote:
> I sent a patch that may fix your issue in a less intrusive way.
> WDYT?
> 
> Elias

On Mon, Apr 3, 2023 at 4:27 AM aarzilli <alessandro.arzilli@gmail.com> wrote:
>
> Ping?

Did you see the change Elias made about this?

https://git.sr.ht/~eliasnaur/gio/commit/0dba85f52e5131c03d903c84355fb90cdb978811

Does that solve your issue?

Cheers,
Chris

No, I didn't see it. I even looked at the log but I missed it. Sorry.

On Mon, Apr 03, 2023 at 10:38:39AM -0400, Chris Waldon wrote:
> On Mon, Apr 3, 2023 at 4:27 AM aarzilli <alessandro.arzilli@gmail.com> wrote:
> >
> > Ping?
> 
> Did you see the change Elias made about this?
> 
> https://git.sr.ht/~eliasnaur/gio/commit/0dba85f52e5131c03d903c84355fb90cdb978811
> 
> Does that solve your issue?
> 
> Cheers,
> Chris

Never mind, I did see and even commented it back in february, I just didn't
realize it had been merged.
The problem with that change is that, AFAICT, it doesn't work, I'll report
my comment from back then:

'''
AFAICT it doesn't help. No FrameEvent is generated for key.Events, they are
queued but they can't be processed until some other event generates a
FrameEvent.
'''

On Mon, Apr 03, 2023 at 06:32:33PM +0200, aarzilli wrote:
> No, I didn't see it. I even looked at the log but I missed it. Sorry.
> 
> On Mon, Apr 03, 2023 at 10:38:39AM -0400, Chris Waldon wrote:
> > On Mon, Apr 3, 2023 at 4:27 AM aarzilli <alessandro.arzilli@gmail.com> wrote:
> > >
> > > Ping?
> > 
> > Did you see the change Elias made about this?
> > 
> > https://git.sr.ht/~eliasnaur/gio/commit/0dba85f52e5131c03d903c84355fb90cdb978811
> > 
> > Does that solve your issue?
> > 
> > Cheers,
> > Chris

On Tue, 4 Apr 2023 at 08:40, aarzilli <alessandro.arzilli@gmail.com> wrote:
>
> Never mind, I did see and even commented it back in february, I just didn't
> realize it had been merged.
> The problem with that change is that, AFAICT, it doesn't work, I'll report
> my comment from back then:
>
> '''
> AFAICT it doesn't help. No FrameEvent is generated for key.Events, they are
> queued but they can't be processed until some other event generates a
> FrameEvent.
> '''
>

I don't think I intended to merge the change without your verification
(and fixing the typo!),
but here we are. It sounds to me the approach will solve your problem,
but that my implementation
is faulty? If so, see my patch follow-up (still untested).

Elias

On Tue, Apr 04, 2023 at 09:07:36AM -0600, Elias Naur wrote:
> I don't think I intended to merge the change without your verification
> (and fixing the typo!),
> but here we are. It sounds to me the approach will solve your problem,
> but that my implementation
> is faulty?

Yes.

> If so, see my patch follow-up (still untested).

That one works, thank you.

On Tue, 4 Apr 2023 at 10:39, aarzilli <alessandro.arzilli@gmail.com> wrote:
>
> On Tue, Apr 04, 2023 at 09:07:36AM -0600, Elias Naur wrote:
> > I don't think I intended to merge the change without your verification
> > (and fixing the typo!),
> > but here we are. It sounds to me the approach will solve your problem,
> > but that my implementation
> > is faulty?
>
> Yes.
>
> > If so, see my patch follow-up (still untested).
>
> That one works, thank you.
>

Great. I've merged my patch.

Elias