The prompt buffer (previously known as "minibuffer") supports fuzzy completion: you never have to type the suggestion in full. Just type a portion of what you want and the appropriate suggestion should come to the top. Even typos are supported.
If duckduckgo does not load, maybe you enable noscript-mode, proxy-mode or similar? Try starting the browser with `nyxt -I` (no config file).
Do other HTTPS site work?
`d` is not bound by default.
To see the full list of commands and bindings, press `Ctrl+space`, it will display them all.
Nyxt does not assume POSIX, in fact it is completely independent of any POSIX-ness.
It has been reported to run on Windows via WSL and also without it, but it needs much more work because WebKitGTK is not trivial to get to run on Windows.
- You can press `enter` instead of typing "default" in full if it's selected.
- Running `vi-normal-mode` enables VI bindings in the current buffer only. If you want to enable them everywhere, you can use the graphical confiuration menu that's presented on startup.
- `tab` inserts the current selection in the input. Do you mean something else?
Note this is the "fully contained Guix pack" (a bit like a container) which contains all the recursive dependencies, which includes WebKitGTK, GTK and the like.
Nyxt alone is about 100-150 MiB uncompressed, which is what it costs you if you install it via your package manager.
(To reiterate what I answered for Ammonite, s/Ammonite/Xonsh:)
I've only scratched the surface of Xonsh, so please correct me if I'm wrong.
From what I understand, Xonsh was designed as a "readline shell" as I wrote in the article. It perpetuates this approach that everything is a command.
The thesis of my article suggests we do the opposite: I'm suggesting to rethink shells by starting from the interface (here the SLY REPL) and then implement the shell features.
In particular, it seems that Xonsh does not support back-references and I'm not sure it has an interactive inspector (or does Emacs python mode provide one?).
While Xonsh seems to be a definite improvement over the syntax of Bash, etc., I'm not sure it brings much novelty in terms of user interface. But again, I know very little about it so I may have missed some features, in particular regarding the Emacs integration :)
From what I understand, Ammonite was designed as a "readline shell" as I wrote in the article. It perpetuates this approach that everything is a command.
The thesis of my article suggests we do the opposite: I'm suggesting to rethink shells by starting from the interface (here the SLY REPL) and then implement the shell features.
In particular, it seems that Ammonite does not support back-references and I'm not sure it has an interactive inspector.
While Ammonite seems to be a definite improvement over the _syntax_ of Bash, etc., I'm not sure it brings much novelty in terms of user interface. But again, I know very little about it so I may have missed some features :)
Agreed, I think Jupyter got many things right, in particular when it comes to prompt handler and data visualization.
What I find limiting for now is interactions with the shell process, in my case the Common Lisp compiler: no interactive stacktrace, no debugger, etc. This is very limiting. I don't know if there is a way around it, as this could be a limitation of the Jupyter design with its kernels. Please let me know if there is a way out! :)
About the .deb: Indeed, it's built on Ubuntu, so it's not guaranteed to work on Debian, which is why we didn't mention it.