`Args out of range: [], 0` when clicking X window during isearch

[thomasheartman]

Thanks for the great package and your work on it! 🙏🏾 I've got an issue that's been bothering me for a bit, but I haven't gotten around to reporting it before now. I couldn't find anyone else reporting the same issue.

Problem

If I abort an isearch in progress (in a normal Emacs buffer) by clicking on an X window, I get this error in the minibuffer and one of three unwanted outcomes.

Args out of range: [], 0

The messages buffer may also say:

exwm-input--fake-last-comand: Args out of range: [], 0 [n times]

The outcome is one of:

1. All X windows (also new ones) stop responding to all mouse input. Keyboard input still works, but they don't respond to mouse events at all. Only way I've found to fix this is to restart Emacs.
2. Emacs stops responding to mouse events in general. This may be the same as above, but I can't be absolutely sure. I can still move the pointer, but not click or scroll.
3. Emacs freezes completely. kill -12 <emacs pid> may be able to get you out of it.

Steps to reproduce

• start an isearch (C-s) in a regular Emacs buffer. (You may need to type something to get search results shown.)
• without running isearch-exit, move your mouse to an X window and focus it by clicking.

~I'm currently unsure whether this only occurs when clicking an X window on a different monitor or not.~ I can confirm that this happens regardless of whether the X window is on the same monitor (and frame/workspace) as the

System info etc

• emacs version: GNU Emacs 28.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.27, cairo version 1.16.0)

• os: Linux, NixOS, 21.05 (but this issue has been there for a while)

• exwm-version: 45ac28cc9cffe910c3b70979bc321a1a60e002ea

---

Anything else you'd like to know, just ask and I'd be happy to supply what info I can! 😄

[daviwil]

Hi Thomas! I attempted to fix this bug in my EXWM fork, give it a try and let me know if it resolves the issue for you!

https://github.com/daviwil/exwm/commit/7b1be884124711af0a02eac740bdb69446bc54cc

I actually fixed this live on a stream: https://www.youtube.com/watch?v=1y3MxU1YXdY

[thomasheartman]

Hey, David! Nice work! 🎉 Trying out your fork now, and I'm not able to replicate the behavior I mentioned above, so that's great! Thanks for your work on that! 🙏🏾

That said, if I understand the code you added correctly, then I'd expect to see the error reported and a backtrace pop up in a new buffer. However, I'm not seeing any errors (or indications thereof) at all 🤔 Does that mean it's not causing an error right now anyway?

[daviwil]

The buffer trick I'm using there is to write the backtrace out to a string so that I can include it in a log message that gets written to the *XELB-DEBUG* buffer when exwm-debug is turned on. The user wouldn't get to see it.

I've been discussing with someone else that it might be good to let the user know that an error was raised in that case, what do you think?

[thomasheartman]

Ah, got it! Nice! 😄

In regards to letting the user know: I think it depends on the error. In this case, I consider it a bug -- I don't think the UI should ever freeze up like that. And if it's a bug, I don't think the user should need to get a notification -- though being able to find it in the *XELB-DEBUG* buffer is nice. If the error is an actual error though (can't think of a situation like that right now), then I think they should be notified.

Does that make sense?

[daviwil]

Yep, definitely makes sense. Might be hard to distinguish between a bug and a legitimate error, so it might be better to make the error known to the user in an unobtrusive way just in case it's legitimate and needs to be addressed somehow. I might try hacking on that a bit the next time I look at it.

[thomasheartman]

Yeah, that's a fair point! As long as it's unobtrusive, I don't think a little message in the echo area would be a big deal. Something like 'An EXWM error was caught. Check the XELB-DEBUG buffer for more information' might be all you need.

Regardless: great work and thanks for looking into this! 🙏🏾

[daviwil]

Yep, that's basically what I had in mind. No problem, and thank you for trying out the fix!

[timor]

Yep, definitely makes sense. Might be hard to distinguish between a bug and a legitimate error

Emacs has the notion of user-error vs. other errors, maybe that distinction is helpful here? If I understand correctly, user-errors should technically be the only ones to be legitimately reported, and all other errors would be considered bugs, but I don't know if that distinction is helpful in practice.

[daviwil]

@timor Good point! Honestly, it would make sense to look specifically for user-error and surface it. I'll look into that too.

[Zaijab]

Forgive me if this comment seems pushy.

Is @daviwil's fix working well enough to be merged as a pull request? I think everyone will benefit from this bug fix and it appears to have been solved. One time I had to restart my window session during an important meeting because of this bug (my fault, I knew what was the trigger).

[mattbeshara]

I just happened to have stumbled across this issue, but it sounds a lot like something which I've encountered multiple times. Is there any reason not to merge @daviwil's commit if it fixes the problem?

[mattbeshara]

@medranocalvo Could we get @daviwil 's fork merged please? This bug has bitten me several times and it's extremely inconvenient when it happens.

@daviwil Is there an open PR with the fix from your fork?

[ArneBab]

Now there is a pull-request: https://github.com/ch11ng/exwm/pull/919

[medranocalvo]

#919 has been merged with some changes. Please test latest master (or wait for https://elpa.gnu.org/devel/exwm.html to update).