Open andychu opened 5 years ago
@andychu , maybe use the Python s created at https://github.com/indygreg/python-build-standalone/ , available from the Releases tab, or use the build scripts there.
They include libedit, and also exclude other GPL/LGPL components.
OK thanks for the pointer. We have forked our own readline binding for a couple reasons, so we couldn't use them literally. But they're probably a good thing to look at.
Got ya. Cheers. Well, time of course is the big killer but check out replxx ,o)
I looked at editline/libedit, it doesn't inspire confidence since the docs are on archive.org !!!
https://web.archive.org/web/20200430175306/http://www.cs.utah.edu/~bigler/code/libedit.html
https://www.thrysoee.dk/editline/
This is an autotool- and libtoolized port of the NetBSD Editline library (libedit). This Berkeley-style licensed command line editor library provides generic line editing, history, and tokenization functions, similar to those found in GNU Readline.
https://github.com/antirez/linenoise
A minimal, zero-config, BSD licensed, readline replacement used in Redis, MongoDB, and Android.
Not updated in 2 years, but it has real usage. And some docs.
Bestline is a fork by jart of sectorlisp:
set -o vi
. What about editline? This is different than lineedit?
replxx seems to be maintained, not sure if it supports vi
mode :-(
https://github.com/AmokHuginnsson/replxx
Or LINES and COLUMNS ...
Question I have regarding #459 and the general architecture #1078
ioctl()
WINSZ ?Related function in bestline:
https://github.com/jart/bestline/blob/master/bestline.c#L1916
This uses ROWS and COLUMNS.
/**
* Returns number of columns in current terminal.
*
* 1. Checks COLUMNS environment variable (set by Emacs)
* 2. Tries asking termios (works for pseudoteletypewriters)
* 3. Falls back to inband signalling (works w/ pipe or serial)
* 4. Otherwise we conservatively assume 80 columns
*
* @param ws should be initialized by caller to zero before first call
* @param ifd is input file descriptor
* @param ofd is output file descriptor
* @return window size
*/
libedit appears to have a vi mode, but none of the others do.
It's also 10x bigger like GNU readline! It's 22K lines, and GNU readline is like 30K-40K lines. :-(
replxx is like 8K lines; editline/linenoise/bestline are smaller
747 chared.c
774 vis.c
837 common.c
843 filecomplete.c
1160 vi.c
1183 history.c
1228 refresh.c
1372 tty.c
1427 map.c
1666 terminal.c
2516 readline.c
22333 total
andy@lenny:~/src/libedit-20210910-3.1/src$
There's also the "multiprocess" approach: https://github.com/hanslub42/rlwrap
Although one problem there is that it's harder to render PS1
, but maybe that can be solved with IPC as well?
The issue is that readline has to know how long the prompt is? Or does it?
Hm Tecla seems to have vi mode too https://sites.astro.caltech.edu/~mcs/tecla/tecla.html
Hi , sorry if I didn't provide any feedback. I have been away but I don't have much to add. I just as an experiment not using readline used libedit, rlwrap and the like. There are of course occasional issues I suppose but at least from my side it was simply a "have you seen this?" to see if it held any point of interest. All I know, looking back is that I built osh with the --without-readline flag in musl :p I often would happily help if I could but my time is alway sucked dry purely maintaining. Not that I am a worthwhile programmer anyway. :) good luck. osh seems ok, when I type env though, I get coloured stuff going on when possibly parsing some 'colour' stuff. instead of retaining the term colours. I don't know if that would be osh or due to my env. I don't wanna distract from your work and I don't even recall if this was an issue I brought up or not. (I hope not :p). Just going through my notifications.replxx I see has updates from 5 months ago. Yes, I don't know if _least locs_is always the best, but I do agree on this policy. Keep it as small as possible. But ye, me out. gazing from afar.
Right now it's tied to GNU readline, and I would like to avoid that long term. We use GNU readline is a slightly different way than bash does, because we want to be principled about interactive completion.
This is simpler than #185, and maybe a step on the way.