Repository: alacritty/alacritty (language: rust)

Issue:
Vi Mode Freezes
Vi Mode freezes. I have to close the terminal instance and open a new one.

Two things worth noting in my current setup:
- The mentioned issue occurs intermittently
- The mentioned issue occurs only when alacrity is launched using the shortcut, never when launched from the command line
- I use https://github.com/jeffreytse/zsh-vi-mode, perhaps this is causing contention?

### System

OS: Linux
Version: alacritty 0.13.0-dev (33306142)
X11, ubuntu:GNOME, GNOME Shell


Discussion / hints:
If this happens specifically when running something inside the shell, what makes you think it's an Alacritty issue?

Does selection still work? If so, it's  not Alacritty.
Selection doesn't work. 
I'd assume you select with the mouse and not by other means and you're talking about vi mode from alacritty on `ctrl + shift + space` (by default).
If mouse selection doesn't work while holding shift, then Alacritty might actually be frozen. In that case a gdb backtrace would be helpful.
I'm launching `alacritty` via an i3 shortcut:

```
# start a terminal
bindsym $mod+t exec alacritty
```

Then inside the terminal I launch a command, for example `toggl now`, which writes to `stdout`.

I hit `CTRL + SHIFT + SPACE`, `hjkl` keys don't work and hitting the shortcut does not exit the VI mode - `alacritty` is stuck. I must kill the process, otherwise I am not able to use the terminal.

Mouse selection does not work either - text gets selected, but I can't seem to be able to copy it.

It does not happen each time, but quite often :/
if you run alacritty with `--print-events` does it stuck? 
Besides, obtaining a backtrace from freeze with gdb could help, though, you should build yourself with `cargo run --release` and attach to that process once it freezes.
Yes, it also does freeze with `--print-events`.

[print_events.zip](https://github.com/alacritty/alacritty/files/13601833/print_events.zip)

> Besides, obtaining a backtrace from freeze with gdb could help, though, you should build yourself with cargo run --release and attach to that process once it freezes.

What do you mean by:
> attach to that process

please?
Process with the INSTALL.md and build alacritty yourself. Then you run it with `cargo run --release` and try to repro your issue (cargo is rust's package manager, should come with rust package on your system).

Then once it freezes, you should run `gdb -p <PID>`(requires root), it'll attach to the process and you should obtain backtrace with `bt full`, there could be multiple threads, so you should do that for each thread and look around to figure out the place it blocks.

From your log it blocks inside the winit though, would be nice to know where.
Here is the `bt full` output:

[bt_full.zip](https://github.com/alacritty/alacritty/files/13601979/bt_full.zip)

Thanks for your cooperation.

NOTE: `alacritty` was built from `d83d5af2b571e5dc2c5c622277096a91c04ca7eb`
I would also like to add that this issue began to appear without me updating `alacritty` (meaning that the referenced hash was working fine before). It started appearing after I've updated my Ubuntu packages.
It just gets no events from X server it seems. Which video driver are you using? 
I am using `amdgpu`:
```
amdgpu-dkms-firmware/now 1:5.11.32.40501-1337797 all [installed,local]
amdgpu-dkms/now 1:5.11.32.40501-1337797 all [installed,local]
amdgpu-install/now 21.40.1.40501-1337797 all [installed,local]
libdrm-amdgpu1/jammy-updates,now 2.4.113-2~ubuntu0.22.04.1 amd64 [installed,automatic]
libdrm-amdgpu1/jammy-updates,now 2.4.113-2~ubuntu0.22.04.1 i386 [installed,automatic]
xserver-xorg-video-amdgpu/jammy-updates,now 22.0.0-1ubuntu0.2 amd64 [installed]
```
Just in case, when you have a freeze with `--print-events` typing, etc won't making new events appear in the log? It looks like x.org just ignores us or something, maybe related to driver doing weird things. If you run with `-o debug.prefer_egl=true` does it change anything?
`debug.prefer_egl` flag does not help with the issue, however, events keep appearing in the log even though `alacritty` is stuck:

```
[8.841345430s] [INFO ] [alacritty] winit event: NewEvents(WaitCancelled { start: Instant { tv_sec: 152222, tv_nsec: 116116207 }, requested_resume: None })
[8.855378879s] [INFO ] [alacritty] winit event: AboutToWait
[8.899044901s] [INFO ] [alacritty] winit event: NewEvents(WaitCancelled { start: Instant { tv_sec: 152226, tv_nsec: 216604926 }, requested_resume: None })
[8.899164722s] [INFO ] [alacritty] winit event: AboutToWait
[9.152222310s] [INFO ] [alacritty] winit event: NewEvents(WaitCancelled { start: Instant { tv_sec: 152226, tv_nsec: 260369667 }, requested_resume: None })
[9.152350292s] [INFO ] [alacritty] winit event: AboutToWait
[9.210126070s] [INFO ] [alacritty] winit event: NewEvents(WaitCancelled { start: Instant { tv_sec: 152226, tv_nsec: 513563268 }, requested_resume: None })
[9.210224359s] [INFO ] [alacritty] winit event: AboutToWait
[9.431258604s] [INFO ] [alacritty] winit event: NewEvents(WaitCancelled { start: Instant { tv_sec: 152226, tv_nsec: 571416583 }, requested_resume: None })
[9.431373045s] [INFO ] [alacritty] winit event: AboutToWait
[9.505198837s] [INFO ] [alacritty] winit event: NewEvents(WaitCancelled { start: Instant { tv_sec: 152226, tv_nsec: 792569060 }, requested_resume: None })
[9.505273664s] [INFO ] [alacritty] winit event: AboutToWait
[9.709262954s] [INFO ] [alacritty] winit event: NewEvents(WaitCancelled { start: Instant { tv_sec: 152226, tv_nsec: 866464998 }, requested_resume: None })
[9.709381435s] [INFO ] [alacritty] winit event: AboutToWait
[9.783386253s] [INFO ] [alacritty] winit event: NewEvents(WaitCancelled { start: Instant { tv_sec: 152227, tv_nsec: 70582850 }, requested_resume: None })
[9.783503514s] [INFO ] [alacritty] winit event: AboutToWait

```

Logs above were logged after visual mode was entered, terminal freezed, and I hit hjkl keys.

EDIT: updated attached log with hjkl presses
Oh, so it froze on `swap_buffers` and you trace was a bit wrong. Sounds like a driver bug? When it freezes after `RedrawRequested` could you provide a trace from all threads? 
I'll have a look at that (btw I've updated my trace to include only hjkl presses. Before it contained other events).
It looks like you just stop getting keyboard events? Is resize freezing? Like if you run something like `htop` inside of it and try to resize, does it update?
Yeah, I can confirm that running `htop` and resizing the window using `i3` works correctly, as `htop` redraws its TUI.

When I run `htop,` then enter visual mode and `alacritty` freezes, `htop` beneath still updates to reflect the current usage.
so it's not freezing, you just don't get key events. Could you change the hotkey to enter Vi mode to `Ctrl + Esc`? I think maybe you trigger some global hotkey and it breaks something, you don't actually have a freeze it seems.
Still occurs when the following shortcut is used:

```toml
[[keyboard.bindings]]
action = "ToggleViMode"
key = "Escape"
mods = "Shift"
```

I have also been able to reproduce it with
```toml
[[keyboard.bindings]]
action = "ToggleViMode"
key = "M"
mods = "Shift"
```

even though it does not occur that often.

🤔 

EDIT: updated the comment to note that it happens even when simple shortcuts such ass Shift+M are used.

Had the same problem too.

`CTRL+SHIFT+Space` (Vi Mode) occasionally prevents new events from entering.
To reproduce: Just enter and exit Vi Mode repeatedly. :smile: 

I don't know much about Alacritty internally, but taking a look, it seems that the origin of this "freeze" is when pass `false` to `set_ime_allowed` inside of `toggle_vi_mode` of `/alacritty/src/event.rs`.


But, when passing `true` (or not making this `set_ime_allowed` call)...
[/alacritty/src/event.rs](https://github.com/alacritty/alacritty/blob/c0c267d60e1b877d5c2c76893751d13547a233c4/alacritty/src/event.rs#L870)
```rs
// self.window().set_ime_allowed(was_in_vi_mode);
self.window().set_ime_allowed(true);
```
... everything works perfectly.
But, I really don't know the impacts of making this call with `true` hardcoded.

Interesting: Not calling `set_ime_allowed` also solves the problem.

Running on X11.
I can confirm that @thephenrique 's proposed solution works for me.
We can't pass `true` on all platforms, because you'll basically be stuck with IME input if you have it on-going. I'd assume you all use ibus?

Fix patch:
diff --git a/alacritty/src/display/window.rs b/alacritty/src/display/window.rs
index 14df091daae..f36d05e972d 100644
--- a/alacritty/src/display/window.rs
+++ b/alacritty/src/display/window.rs
@@ -410,7 +410,10 @@ impl Window {
     }
 
     pub fn set_ime_allowed(&self, allowed: bool) {
-        self.window.set_ime_allowed(allowed);
+        // Skip runtime IME manipulation on X11 since it breaks some IMEs.
+        if !self.is_x11 {
+            self.window.set_ime_allowed(allowed);
+        }
     }
 
     /// Adjust the IME editor position according to the new location of the cursor.


Test patch: