Request: Newest nano version 8.4
Thank you for this project!
My request: Would love to see nano bumped to its current version 8.4 @ https://www.nano-editor.org/dist/latest/nano-8.4.tar.gz.
Updated to nano-8.4 in https://github.com/ahgamut/superconfigure/commit/0c5fe461d5d1984a5a15d19840b4a8c9e737e0de
You can download the testing build in the artifact.zip from here.
Wonderful! Commercial grade support :))
This build of nano seems to have rather serious problems, at least in my shell (busybox-w32). I remember reading somewhere that it was a known problem. Found it under Known Issues in Cosmopolitan v4.0.2 release notes. The proposed workaround unfortunately makes this build of nano--my main editor, would you believe--too unusable for me.
I don't know where to ask for nano to get some Cosmo love.
Regardless, thanks for super fast turnaround!
What TERM variable does busybox-w32 use by default?
Okay @stianhoiland I patched the nano build to force TERM=vt100 as a possible workaround for the issue when on Windows. Testing binaries available here.
If your shell uses a different TERM variable, we can set it to that instead.
The most immediate issue is that TERM=vt100 disables color support in nano.
Looks like busybox-w32's compile time setting for the TERM variable is here CONFIG_INIT_TERMINAL_TYPE.
nano falls back to vt220 here. More notes on nano's terminal compatibility.
Playing around with TERM=linux ./nano and TERM=rxvt ./nano and color works again, yay, but there is some weirdness when nano exits and tries to restore the terminal from raw to cooked. This could be an issue with Cosmo's termios.h implementation (something tcgetattr_nt-adjacent?)
On the other hand, nano uses ncurses (here). Which curses library was the new nano build you posted built with? Could be an issue with Cosmo's (n/PD)curses(w)? EDIT Cosmo doesn't have its own curses implementation, so this question is important. EDIT2 Ah, here we go 1, 2.
I want to add that there is value in getting a Cosmopolitan nano going. There are a couple of nano forks that try to patch things up to get a workable Windows version. But I haven't liked nor settled with any of these projects and have instead ended up with a MSYS2 version of nano, which is a lot of overhead for nano, methinks.
Oh and that reminds me that in the MSYS2 version I'm using the scroll wheel scrolls the viewport as expected (except that it scrolls 2 lines instead of 3 which is customary at least on Windows), while the Cosmo build you've provided scrolls the cursor line up/down, which is annoying and unexpected. Oh and clicking the mouse doesn't move the cursor in the Cosmo build, but does so in the MSYS2 version. So yeah, mouse support is lacking. Possibly, again, an ncurses issue?
EDIT Oh, and to answer your question directly, busybox-w32 explicitly doesn't set TERM at all.
EDIT There is a newer ncurses version: v6.5 vs. v6.4 (oh, and look: --without-sysmouse), but I doubt updating will fix the issues.
Playing around with TERM=linux ./nano and TERM=rxvt ./nano and color works again, yay, but there is some weirdness when nano exits and tries to restore the terminal from raw to cooked.
Perhaps we can set TERM=rxvt as the default for Windows then. Does this build work as expected? (It ignores TERM on windows and forces TERM=vt100).
Which curses library was the new nano build you posted built with?
nano is built with ncurses-6.4, which uses the configuration options from here: https://github.com/ahgamut/superconfigure/blob/main/lib/ncurses/BUILD.mk#L3
So yeah, mouse support is lacking. Possibly, again, an ncurses issue?
Yes, the build config above disables sysmouse, and there's some confusion with the --enable-widec flag. Perhaps we can figure out what ncurses receives here vs what it does on MSYS2.
there is value in getting a Cosmopolitan
nanogoing.
Agreed. Part of starting this repo was to build vim and emacs as APE binaries, and I would love to see nano also be used similarly.
The build you posted disables (at least) color support, and I can't coerce it to support color by passing a different TERM variable. I'm trying to find where ncurses gets its has_color() function return value from so that I can pick some sane default for the TERM variable for Windows. TERM=rxvt seems overly weird as a default for Windows.
Here's the MSYS2 build script/patches for nano, and for ncurses. The MSYS2 ncurses build has many switches (including --enable-widec), which is obviously referencing functionality in the MSYS2 subsystem. They're using ncurses v6.3. What I find weird is that the binary distribution of MSYS2 nano that I'm using (I believe I got it from here, but the previous version 8.3 here) reports --enable-utf8 when I nano --version, but I can't find that switch neither in the nano build scripts nor ncurses':
GNU nano, version 8.3
(C) 2024 the Free Software Foundation and various contributors
Compiled options: --enable-utf8
EDIT I think I got the nano binary from the source I gave, but dropped it into a full msys64/usr/bin installation. Blerh.
The build you posted disables (at least) color support, and I can't coerce it to support color by passing a different TERM variable.
Yup, the patch explictly ignores TERM and forces TERM=vt100. We can have the default as rxvt or linux. Does the scrolling work as expected?
Colors and scrolling does not work as expected. Scrolling moves the cursor line up/down, not the viewport.
Btw, if we end up with something good here, and you seem open to some light patching, there is one thing that drives me absolutely bonkers in nano and which I'd love to have patched: When you have a text selection, entering text does not replace the selected text, but simply unselects and inserts. It's insane (to me), and the maintainer has expressed resistance to change it on the mailing list. It's rewiring my brain and not in a good way!
The recent commit https://github.com/ahgamut/superconfigure/commit/0f84e60ccf559c71f2ce813a92ee629f7d1d5542 now adds most of the flags specified in the MSYS2 builds, and makes nano set TERM=rxvt if not specified already. Not sure if this fixes the scrolling issue.
Testing binaries are available here.
The build based on 0f84e60 still exhibits the same issues. Weirdly enough it also doesn't even seem to be setting TERM=rxvt as patched; I have to manually override TERM to work around the bug mentioned in Cosmo 4.0.2 release notes:
Use TERM=vt100 nano to fix frozen display state with nano editor
So, in summary:
- The build still exhibits the 4.0.2 frozen display state bug (more like incessant flashing on my setup--busybox-w32 in Windows Terminal)
- This bug can be worked around by manually overriding
TERMin the shell. Some values (like the suggestedvt100) disable color support (and therefore syntax highlighting innano) - Mouse support isn't working even when compiled with
--with-sysmouse(scrolling doesn't scroll viewport + clicking doesn't place cursor)
Here's what the "frozen display state bug" looks like for me on BusyBox v1.37.0.git-5467-g9376eebd8 & Windows Terminal Version: 1.22.11141.0. This is the latest Cosmo nano build based on 0f84e60. I have to manually kill nano in a separate shell to regain control.
https://github.com/user-attachments/assets/9407645b-0ce8-4f71-9ee3-06c73c52d555
Also want to note that after launching nano (and killing it), the terminal emulator also starts treating mouse scroll wheel as arrow up/down, scrolling through prompt history instead of scrolling the scrollback.
what happens if renamed to nano.com and run it in a Command Prompt window (without busybox)?
The same flashing/loop happens as shown in the video clip I posted. I tried using the old conhost.exe as well (not Windows Terminal): Same flashing/loop, and I have to kill the nano process.
Does @jart know why nano is having these issues when compiled with Cosmopolitan Libc?
Okay, we'll just keep TERM=vt100 for nano for now. @stianhoiland Do vim / emacs have the same flickering issue on Conhost/Windows Terminal? If so the issue may be due to how nano calls for a screen refresh, otherwise we might have to patch something with ncurses/termios on Cosmo.
Just now downloaded vim @ https://cosmo.zip/pub/cosmos/bin/vim and it works without issue. Scroll wheel doesn't work, but otherwise mouse support works (click places cursor, click-&-drag to select, double-click to select word, etc.)
Okay I explicitly enabled mouse support in https://github.com/ahgamut/superconfigure/commit/1a5d0ab8b2f572f65988b9f7de42c5831f1f4c5b, try the build here. (I don't think this fixes the color issue).
Okay I explicitly enabled mouse support in 1a5d0ab, try the build here. (I don't think this fixes the color issue).
- Still exhibits the display bug
- Display bug can be worked around by manually overriding TERM (
rxvt&linuxconfirmed to workaround, with unknown side-effects) - Mouse support isn't working (scrolling doesn't scroll viewport + clicking doesn't place cursor). Mouse clicks show the error "Unknown sequence"
Mouse support started working on Linux once it was explicitly enabled 🤔
Still not sure where the display bug is. I'll take another look at the build in the weekend.