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! :)
Right, maybe "best practices" was poorly worded. I'll think of something better.
Regarding the visual aspect: Very nice link, thanks for sharing!
I was also thinking of showing off the macro-stepper.
Regarding the lack of libraries: well, Quicklisp is strong of some 1500 libs, which is rather poor compared to most popular languages out there. So yes, it goes both ways!
I understand your comment as a bit judgmental, if not rude.
Please keep the tone friendly, it helps if we want to have constructive discussions.
I'd be happy (as well as everyone around here I'm sure) to discuss what you find questionable.
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.