Text starts from the right hand side on ARM Mac

[lewis262626]

Irssi on Apple ARM does not properly render to screen.

The issue is that Apple on ARM puts variadic arguments in function calls in a different place than everyone else.

In the mean time, you can find a patch to try in #1238 (comment)

Unfortunately, we cannot unconditionally patch Irssi like this because it might break rendering on other platforms.

original bug report follows

1. I've installed Irssi on Arm Mac using Homebrew
2. When I launch Irssi and start typing the text starts on the far right side and then continues on a new line
3. I'm unable to see what I'm typing due to this bug
4. Various other issues with scrolling

[dequis]

Well, it's not the obvious thing, so i'm out of ideas really. Ask the homebrew people, I guess? They messed up their terminfo or whatever.

[vague666]

See if you get same behavior with another terminal, like iTerm2, which is the 'preferred' terminal by most irssi users. At least that's what everybody says but there is no poll on it or anything :)

[Julian]

Same issue here, across multiple terminals (Terminal.app as OP mentioned and Rosetta'd Alacritty).

Homebrew is just running ./configure; make; make install for irssi on ARM (because there's no ARM Homebrew support for binary bottles) -- I'll try to confirm in a separate install, but seems possible or even likely it has nothing to do with Homebrew.

[dequis]

but seems possible or even likely it has nothing to do with Homebrew.

I see homebrew as both a build system and a distro. They are in charge of ensuring that their builds interact well with the libraries they depend on. Also, they know more about their own platform than we do. Not saying it's their fault, but they are way more likely to be able to help on this issue than us.

[676339784]

Hi guys, I compiled irssi manually but it still results in a right-aligned irssi. Wondering how you guys resolved this?

[676339784]

Tried debugging this issue with the Homebrew community (see Homebrew/homebrew-core#68856) but they suggested it's an upstream issue.

[lewis262626]

@676339784 Only other thing I can think of trying is iTerm2 (does it have an ARM build?)

[WA9ACE]

I can confirm I do actually have the same issue. I forgot to report back after this but when I confirmed it was working for myself I was accidentally SSH'd into a server in my TMUX pane and not on my macbook. This problem occurs in both the builtin Terminal.app and iTerm2 (which does have an ARM build) with various $TERM settings tested in-between.

[676339784]

@WA9ACE Yup, I share the same problems as you do

[WA9ACE]

I'm not too good at C but I'll try stepping through it tonight, to see if I can pinpoint the problem for a PR.

[bsandro]

Trying to look into it, just writing down some stuff that might be useful to someone too in digging.
I don't build irssi from homebrew; instead resorted to building from the source as-is to exclude any brew quirks and whatnot; moreover it is hardly brews fault so I left it out of the equation for now.

Bug is totally reproducing on both iterm2 and Terminal.app; it is not terminals fault because irssi on x86_64 and aarch64 Linux renders just fine in both of them (via ssh).

Building irssi from source with added ncurses to the PKG_CONFIG_PATH doesn't do the trick apparently and it still links against system libncurses; possibly that's why Homebrew/homebrew-core#68856 (comment) this tryout didn't change anything.

Overriding CFLAGS and LDFLAGS though produces some interesting result - irssi now clearly builds with libncurses-6.2 from homebrew installation and links against that and it totally destroys iterm2 upon launch. Whole terminal emulator with all its apps just leaks indefinitely and hard freezes.

"Stock" Terminal.app manages to withstands the new binary but produces pitch black screen.

I'll try to debug it / check ncurses but maybe the provided info will help some folks that are more knowledgeable than me.

Output of otool -L irssi

src/fe-text/irssi:
	/System/Library/Perl/5.28/darwin-thread-multi-2level/CORE/libperl.dylib (compatibility version 5.28.0, current version 5.28.2)
	/opt/homebrew/opt/glib/lib/libgmodule-2.0.0.dylib (compatibility version 6601.0.0, current version 6601.4.0)
	/opt/homebrew/opt/glib/lib/libglib-2.0.0.dylib (compatibility version 6601.0.0, current version 6601.4.0)
	/opt/homebrew/opt/gettext/lib/libintl.8.dylib (compatibility version 11.0.0, current version 11.0.0)
	/opt/homebrew/opt/openssl@1.1/lib/libssl.1.1.dylib (compatibility version 1.1.0, current version 1.1.0)
	/opt/homebrew/opt/openssl@1.1/lib/libcrypto.1.1.dylib (compatibility version 1.1.0, current version 1.1.0)
	/opt/homebrew/opt/ncurses/lib/libncursesw.6.dylib (compatibility version 6.0.0, current version 6.0.0)
	/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1292.60.1)

Screenshot of the Terminal app with irssi -! and /help command that I've tried to run inside.

[ailin-nemui]

does this patch do anything

diff --git a/src/fe-text/terminfo-core.c b/src/fe-text/terminfo-core.c
index d2273d71..be59b0a7 100644
--- a/src/fe-text/terminfo-core.c
+++ b/src/fe-text/terminfo-core.c
@@ -14,6 +14,8 @@ inline static int term_putchar(int c)
 
 /* Don't bother including curses.h because of these -
    they might not even be defined there */
+#include <ncursesw/term.h>
+#if 0
 char *tparm();
 int tputs();
 
@@ -21,6 +23,7 @@ int setupterm();
 char *tigetstr();
 int tigetnum();
 int tigetflag();
+#endif
 #define term_getstr(x, buffer) tigetstr(x.ti_name)
 #define term_getnum(x) tigetnum(x.ti_name);
 #define term_getflag(x) tigetflag(x.ti_name);

[patheticpat]

Yes, this patch and building with ncurses from homebrew does seem to fix it.

[bsandro]

Used wise @ailin-nemui insight and the following change allowed the fix to work with a "stock" macos ncurses too (homebrew ncurses works as well):

diff --git a/src/fe-text/terminfo-core.c b/src/fe-text/terminfo-core.c
index d2273d71..0cff18de 100644
--- a/src/fe-text/terminfo-core.c
+++ b/src/fe-text/terminfo-core.c
@@ -14,13 +14,13 @@ inline static int term_putchar(int c)

 /* Don't bother including curses.h because of these -
    they might not even be defined there */
-char *tparm();
-int tputs();
+char *tparm(const char *str, ...);
+int tputs(const char *str, int affcnt, int (*putc)(int));
+int setupterm(char *term, int fildes, int *errret);
+char *tigetstr(const char *capname);
+int tigetnum(const char *capname);
+int tigetflag(const char *capname);

-int setupterm();
-char *tigetstr();
-int tigetnum();
-int tigetflag();
 #define term_getstr(x, buffer) tigetstr(x.ti_name)
 #define term_getnum(x) tigetnum(x.ti_name);
 #define term_getflag(x) tigetflag(x.ti_name);

[ailin-nemui]

https://gitlab.com/embeddable-common-lisp/ecl/-/issues/224

[ailin-nemui]

note that this is an Apple issue, arm64 on Linux has no such issues

[ailin-nemui]

as discussed on IRC, we cannot just apply above patch due to compatibility concerns.

We need a comprehensive and compatible solution. One such solution might be to properly search for and, if found, #include <term.h>. Otherwise we should stick to the Solaris&AIX compatible generic functions (which are unfortunately broken on Apple's new chip because Apple decided to break ... functions).

Technically of course, it is illegal to have ... functions without prototype in C, so Irssi is doing the wrong thing here. Unfortunately, depending on the term implementation, tparm can be implemented either with ... or with many parameters (see e.g. https://docs.oracle.com/cd/E88353_01/html/E37849/tparm-3curses.html)

So if anyone can come up with and contribute such a solution, that would be great. Especially since the devs don't have any proprietary devices to test. Interested contributors should keep in mind that, for the time being, the solution has to be implemented in both meson and autotools.