Textadept-curses cannot be launched from another process (zk) about textadept HOT 9 OPEN

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?

from textadept.

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

from textadept.

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)

from textadept.

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).

from textadept.

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?

from textadept.

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.

from textadept.

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?

from textadept.

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.

from textadept.

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.

from textadept.