error in process filter: Invalid search bound (wrong side of point)

[jlagarespo]

I am currently using exwm as my main window manager, and everything seems to be working fine... everything except one thing :(
At first the problem seemed to be quite random, but now I think I figured out the (possible) source. When I open a window, everything runs nicely. However, if I try to open another window and I "overlay" it (by putting it in the same emacs window than the other) bad things happen. I guess this is because even though in a tiling window manager there's no such thing as "overlaying windows", their effective positions are equal. Anyways, here are the symptoms:
In the messages buffer these two errors start getting spammed, quite randomly:

error in process filter: ansi-color-apply-on-region: Invalid search bound (wrong side of point)
error in process filter: Invalid search bound (wrong side of point)

If I turn on debug-on-error, this is the backtrace I get:

Debugger entered--Lisp error: (error "Invalid search bound (wrong side of point)")
  re-search-forward("\33\\[[0-?]*[ -/]*[@-~]" #<marker at 1 in *Async Shell Command*> t)
  ansi-color-apply-on-region(#<marker at 152 in *Async Shell Command*> #<marker at 1 in *Async Shell Command*>)
  ansi-color-process-output("[03/29/20, 16:21:53:387] info: [FOCUS-EVENT] Clien...")
  run-hook-with-args(ansi-color-process-output "[03/29/20, 16:21:53:387] info: [FOCUS-EVENT] Clien...")
  comint-output-filter(#<process Shell> "[03/29/20, 16:21:53:387] info: [FOCUS-EVENT] Clien...")

At first, I wanted to ignore this error but it's not really possible. It makes executing commands really difficult, because every time it appears it locks your keyboard for a few seconds, all your keystrokes get mixed up and it is very annoying in general.

I have no idea what that backtrace means, nor if that has anything to do with any packages/configurations I have. If needed I'll post potentially relevant configuration files.
Many thanks in advance :)

[medranocalvo]

Hello Jacob,

this does not seem like an EXWM issue, though it could be that running EXWM makes it trigger more often. The backtrace shows an error in ansi-color: it's trying to search for something in the shell output, but the bounds are too tight. ansi-color colorizes shell output.

This is a bug in Emacs (I think). Please, report it to the Emacs bugtracker with report-emacs-bug. Let me know if you need help doing that.

[jlagarespo]

Hi, thanks for your reply.
Except for the *Async Shell Command* buffer there is no shell open, which makes things strange, because there is really not much coloring in that buffer... (except for some occasional green messages).

I must say though, that if I open something that's quite verbose (such as slack) things get worse, so it is possibly related.
As for the bug report, I'm going to do that now, I'll post back here if I get any results. Thanks for now :)

[jlagarespo]

Also, I will not close the issue just yet in case there is something related to EXWM.

[ch11ng]

Perhaps you should try starting programs without the *Async Shell Command* buffers?

[jlagarespo]

Do you have any suggestions on how I could do that? Do you mean using something along the lines of Rofi?

[medranocalvo]

I think @ch11ng means using a launcher such as the following instead of invoking async-shell-command:

exwm/exwm-config.el

Lines 49 to 51 in 27a884e

	([?\s-&] . (lambda (command)
	(interactive (list (read-shell-command "$ ")))
	(start-process-shell-command command nil command)))

It's better if you don't need the process' output, as it's often the case.

[jlagarespo]

Now i am using dmenu. I am not exacly sure what originally caused that problem, I ended up reinstalling emacs.
I will be closing this now.