Crashes in tmux / macos

[normen]

When trying to run gomuks in tmux on macos I am getting an error from tview:

exit status 1
panic: exit status 1 [recovered]
        panic: exit status 1

goroutine 1 [running]:
maunium.net/go/gomuks/debug.Recover()
        /Users/normenhansen/Dev/GoCode/gomuks/debug/debug.go:109 +0x98
panic(0x48a7720, 0xc000543b60)
        /usr/local/Cellar/go/1.15.5/libexec/src/runtime/panic.go:969 +0x1b9
main.(*Gomuks).Start(0xc000464870)
        /Users/normenhansen/Dev/GoCode/gomuks/gomuks.go:118 +0x1e5
main.main()
        /Users/normenhansen/Dev/GoCode/gomuks/main.go:83 +0x585

I tried to track it down but for some reason tview doesn't give much info. I do have multiple other tview apps running in the same tmux instance without issues though..

When running in a normal terminal everything works fine.

Versions:

• gomuks master
• go 1.15.5
• tmux 3.1c
• zsh 5.7.1

[normen]

Okay, just to test it I did this and it works: unset TMUX;gomuks

Seems like something inside gomuks is trying to be smart about tmux and fails hard.

[ericonr]

Can reproduce this on Linux with Go 1.15.6 and fish shell. I'm on musl libc, which might matter.

[astralchan]

I installed tmux 3.1c. Can reproduce on VOID Linux x86_64-musl with zshell:

[amber@otaku ~]$ gomuks
panic: exit status 1 [recovered]
        panic: exit status 1

goroutine 1 [running]:
maunium.net/go/gomuks/debug.Recover()
        /builddir/gomuks-0.2.2/debug/debug.go:109 +0x98
panic(0xca4ce0, 0xc00031bea0)
        /usr/lib/go/src/runtime/panic.go:969 +0x1b9
main.(*Gomuks).Start(0xc000395950)
        /builddir/gomuks-0.2.2/gomuks.go:116 +0x14a
main.main()
        /builddir/gomuks-0.2.2/main.go:83 +0x585

[ehrlichja]

Getting this too - also using fish shell.

[jhe2]

I was experiencing the same issue and then looked at the source to figure out what was going on. It turns out the tcell library used by gomuks explicitly sets the terminfo to tmux when it detects that tmux is running and TERM has been set to screen (which is the default behavior for tmux). Since there is no terminfo entry for tmux on my system (as is very common), it then fails and gomuks won't run. I've created a pull request that reverts the commit that introduced this behavior.

[ElDifinitivo]

I'm getting the same issue as well. I brought up a workaround here that works so that it can actually be run in tmux, but there's a lack of functionality within tmux that diminishes it's usefulness. Other than the support without needing workarounds, I've also noticed that gomuks does not push an activity change or an alert. which not only affects tmux (no window name highlight with a new message) but also a status bar like polybar where the workspace with an alert is also highlighted.

Notifications on new messages is also not reliable: it's hit or miss whether they'll pop up (using dunst), but it seems like not having the terminal window or tmux pane selected makes the notification more likely to pop up. It can be anecdotal though and I haven't really been able to look into it yet.

The only good alternatives to GUI clients for Matrix are this or weechat-matrix, which is currently broken with python3.10 and is in maintenance mode as development is focusing on the rust rewrite weechat-matrix-rs. With such a lack of CLI clients, this could be a great way for gomuks to push itself as a great front-end, and I think it's important to work well with a very common set-up.

[jgarte]

I got a crash the other day running gomuks in abduco/dvtm. Maybe related.

[motorto]

@tulir was this issue fixed ? Even 11h ago someone created an issue and closed the issue because it was a duplicate of this.
Did a quick glance at commit messages and didn't see any with a 'fix this issue' .

Does this still happen ?

[FiskFan1999]

@tulir was this issue fixed ? Even 11h ago someone created an issue and closed the issue because it was a duplicate of this. Did a quick glance at commit messages and didn't see any with a 'fix this issue' .

Does this still happen ?

That person was using the homebrew formula which installs v0.2.4 from September last year (seen here). Meanwhile this issue was closed in April this year, and I (on x86 macos) haven't experienced this problem myself, am looking to see which commit references this.

[aaronraimist]

(0.2.4 is the latest release)