Textadept-curses cannot be launched from another process (zk)

[quesada]

To reproduce, install zk: https://github.com/zk-org/zk

configure it to use textadept-curses to launch notes. Then simply do $ zk new --title 'some-note'

It will segfault:

On ubuntu 22.04, gnome, X11.

[orbitalquark]

I think this may be related to the inability to determining the filesystem encoding in #510. If you manually export CHARSET=UTF-8 and try again, does it work?

[quesada]

I'm using fish. tried this on config.fish:

set CHARSET "UTF-8" set LANG "en_US.UTF-8"

Segfault persists

EDIT: tried in bash. set the same vars, stayed in bash. doing 'zk new' does get the same segfault. Sorry to be the bearer of bad news

[quesada]

Update: the curses version also doesn't work when launched by a different tool, tpnote (https://blog.getreu.net/projects/tp-note/tpnote--manpage.html).

The error is this time:

The external application did not terminate gracefully: signal : 11 (SIGSEGV)

[orbitalquark]

You may need to do something like xterm -e textadept-curses. Based on your screenshot, it appears to be invoking textadept-curses $file < /dev/tty, which (to me) appears to be doing odd things with stdin. It doesn't look like it's launching the terminal application with the shell's current stdin (which is required).

[quesada]

Yes, that replicates the problem.

xterm -e textadept-curses creates a popup window on X with a new terminal. This is not what we want, we want to reuse the existing terminal. It's not just better ergonomics: it won't work using the default linux/bsd console (ctrl alt F1-F6) which is a very important use case for a curses editor aiming to replace vim (ie, my use case).

The other way textadept-curses $file < /dev/tty does produce the same error message, but stays within the existing window (which is what we want).

I used 2 examples of 3rd party apps calling an editor this way, zk and tpnote. there are many more. Git for example. I think this second workflow is the most common in the TUI world. If textadept cannot adopt it, I would consider it a bug?

[rgieseke]

Git for example. I think this second workflow is the most common in the TUI world.

Do you mean using textadept-curses for writing a Git commit message after git commit?

I use this with fish without problems.

[quesada]

Yes this is what I mean. I haven't tried it yet. Could it be that I found the only two apps that do call textadept-courses wrong?

[orbitalquark]

I can reproduce the crash by calling textadept-curses $file < /dev/tty. I'll look into that when I have a chance.

Applications should simply be invoking textadept-curses $file. There shouldn't be a need to provide a stdin resource like /dev/tty. It should already be the current stdin, and Textadept should take over the foreground. I have it set up so that when I do hg commit or git commit, textadept-curses opens up with the commit message, as Robert hints at. No crashes, and everything works as expected.

[quesada]

Yeah, it's strange these two apps do it that way. The config file seems to indicate they would do it like you describe, like git commit does it... but no. They are in rust and go each. Maybe 'modern' languages have libraries for TUI that do it this way? Not sure.