readline VS busybox

... I kind of am, though. Which is why I didn't know what to do. I don't see a lot of free open source projects with extensive documentation in their README. Some, yes, but for example here's the readline library I'm using. I, in my well-meaning ignorance, supplied 50 pages of documentation and people are behaving like I ate a baby 'cos it's in the wrong format. I will now put it all in the README as people would like, but I did genuinely act out of ignorance and not out of a wish to insult the customs of the tribe.

> I would like to see a framework for creating rich REPLs that would be language agnostic, so that I could get a state of the art auto-completion dialog no matter which language I decided to make into a shell.

It's doable with existing tools. You have LSP to provide the syntactical framework and there's no shortage of alternatives to readline (I'd written my own[1] to use in murex[2], and open sourced that).

[1] https://github.com/lmorg/readline

[2] https://murex.rocks

The problem you still face is that a good shell will offer autocompletion suggestions for strings that aren't language keywords or function names. eg

- file names; and there's a lot of hidden logic in how to do this. Do you build in fzf-like support, just include fzf wholesale but increase your dependency tree, or go for basic path completion. Do you check metadata (eg hidden files and system files on Windows), include dot-prefixed files on Linux / UNIX, etc. How do you know when to return paths, or paths and files, or even know not to return disk items at all? (see next point)

- flags for existing CLI tools (assuming you want compatibility with existing tools). Fish and murex will parse man pages to populate suggestions, others rely entirely on the community to write autocompletion scripts.

- Are you including variables in your completion of strings. And if so are you reading the variables to spot if it's a path and then following that path. eg `cd $HOME/[tab]` should then return items inside a your home directory even though you've not actually specified your home directory as a string. That means the shell needs to expand the variables to see if it's a valid path. But that's a shell decision rather than a language feature.

Some of these lists might take a while to populate so you then have another problem. Do you delay the autocompletion list (bad UX because it slows the user down) or provide the autocompletion sooner. And if the latter, how do you do that without:

1. changing the items under what you're about to select causing you to accidentally select the wrong option

2. communicate that there are update clearly

3. ensure the UI is consistent when slower loading entries might not fit the same dimensions as the space allocated for the list (if you dynamically size your completions to fit the screen real estate)

4. ensure that there's still something present while you're lazy loading the rest of the suggestions; and that those early entries on the completion list are worthwhile and accurate

5. what about sorting the list? Alphabetical? By feature? etc

The REPL in murex was inspired by IDEs so I've spent a lot of time trying to consider how to provide the best UX around autocompletion. One thing I've learnt is that it's a lot harder to get right than it seems on the surface.

Well.

Maybe you have better luck with the Busybox diff: https://github.com/brgl/busybox/blob/master/editors/diff.c

You can use busybox devmem to debug. The source code gives you an idea of how it works to write your own code.

You can fairly easily spot things like recursive search tree implementations in the wild.

Also, compilers and interpreters often recursion, and that goes to as many levels as the program requires.

Have you heard of a "recursive descent parser"? GNU C++ uses one (a huge source file written in C++, well over a megabyte long). This will recurse as deeply as the program's nesting goes; C++ programs often go to more than three levels of nesting. (There are some non-recursive hacks mixed in there, like some operator precedence parsing involving an explicit stack: Shunting-Yard or similar?)

https://github.com/gcc-mirror/gcc/blob/master/gcc/cp/parser....

Let's switch over to embedded. Have you heard of BusyBox? BusyBox provides scaled down system utilities for embedded systems. It is very widely used.

BusyBox's "libb" internal library contains a function called "recursive_action" for walking file system trees. This is actually recursive, and frequently goes more than three levels deep in actual use:

https://github.com/brgl/busybox/blob/master/libbb/recursive_...

This is used by BusyBox programs like mdev (udev replacement) lsusb, lspci, chmod, ...

Also, HN isn't a good place to exhibit Lisp condescension/ignorance.

This is almost the same implementation you see in busybox's id command source