nnn with netbsd-curses

[jarun]

Hi,

We are trying out nnn with netbsd-curses and musl libc.

The performance results are just awesome!

Seeing the issue jarun/nnn#998 because of the following difference between ncursesw and netbsd-curses:

In a case where ncursesw sends KEY_RESIZE (key value 410) twice, netbsd-curses sends a KEY_RESIZE (key value 512) followed by a NULL (key value 0) character.

nnn uses the NULL key (^Space) for range selection leading into issues.

Can you please take a look why the NULL key is sent after the KEY_RESIZE?

Attached the debug logs from ncursesw and netbsd-curses. A diff would show the problem.

Please let us know if you need some more details.

nnndbg_ncurses.txt
nnndbg_netbsd.txt

[jarun]

While we have made changes in nnn to discard the keybind ^Space which also sends a 0 value, it would be great if this can be fixed in netbsd curses to make the bahaviour uniform with ncursesw.

[jarun]

Also, is there any macro available to identify the netbsd curses library?

[rofl0r]

hi @jarun , i just finished backporting 2 years worth of commits from upstream. could you test whether that fixes your issue ?
if not we need probably to report this issue to netbsd mailing list and adopt their fix (or debug the issue ourselves, if you feel up to it).

is there any macro available to identify the netbsd curses library?

fortunately not, altough in the commits i backported are 2 that introduced a curses_version function and another one that introduced a version macro for internal usage, but it was then reverted in 2bd1239 (with a link to discussion on mailing list). i used to have a backchannel on IRC to one of their developers, but he is sadly currently not online due to health issues.

in regard to curses macro, i say fortunately because having a macro would just lead to people hardcoding wrong assumptions with ifdefs into their sources, instead of having proper configure-style checks for functionality. this is also the reason why there's no MUSL macro. i've written extensively about this in https://sabotage-linux.neocities.org/blog/5/.

[jarun]

Unfortunately, it's still not fixed. However, the patch from nnn hides it.

The latest issue I see is jarun/nnn#998 (comment).

And I couldn't figure it out yet. In case of some KEY_RESIZE events, the statusbar gets broken. We use a move(LINES - 1, 0) to go to the last line. However, it doesn't work in some cases as you will see in the asciicast.

If I call move() in a loop for each line the statusbar goes down. But when the issue happens it's still 2 lines above the last line.

Please see if you can do something about it.

[rofl0r]

since it happens with a specific terminal, it might be something stupid related to terminfo.
if you dont mind you could update terminfo/terminfo with latest from ncurses, rebuild all of ncurses; this could fix at least the statusbar issue.
i didn't update terminfo yet as there's an ever-growing mismatch between ncurses version, the one used by netbsd, and ours. i'll probably resort to import vanilla ncurses into the repo, and apply a number of custom patches during build process to create the binary version that's baked into libterminfo from.

[jarun]

terminfo/terminfo with latest from ncurses

Can you please point me to the repo?

[jarun]

If you are indicating this: https://ftp.gnu.org/pub/gnu/ncurses/ I am not sure if it compiles with musl libc. The reason I wanted to try netbsd-curses is it plays well with musl libc.

[jarun]

With the terminfo from ncurses-6.2.tar.gz that issue seems to be fixed. However, I see one small problem - the cursor at the filter prompt (bottom line) does not move:

[jarun]

Sorry, even the issue persists if I open nnn from tmux.

[rofl0r]

yeah i meant terminfo file from ncurses or directly from https://invisible-island.net/datafiles/current/terminfo.src.gz (latest). so you're saying using latest terminfo, the issue with statusbar is fixed in xfce4-terminal, but not in tmux ?

[jarun]

No, the original issue persists. And I see the new issue of the block cursor not moving.

[jarun]

The cursor not moving issue is probably introduced by one of the latest changes you pulled in yesterday.

Update: Confirmed. I tested with netbsd-curses v0.3.1 and the stuck cursor issue is not there.

So probably we should just concentrate on the issue I mentioned in #46 (comment). It's present in v0.3.1 as well.

[jarun]

Please let me know if there is any provision to enable debug logs which I can provide.

I was planning to generate a static binary in the next release but this issue is annoying enough to turn off users who use the detached edit in a tabbed terminal. So we need to get it fixed first before releasing such a binary. Also, it appears to me a well-tested new netbsd-curses release would be a good confidence booster.

Would it be possible to merge upstream netbsd changes soon?

[rofl0r]

The cursor not moving issue is probably introduced by one of the latest changes you pulled in yesterday.

could you try to git bisect to find the commit that introduced it ?

Would it be possible to merge upstream netbsd changes soon?

that's precisely what i did yesterday. we're currently even with upstream.