Ambrevar

What mention did you not see? Is there anything I can clarify? Please let me know, feedback is always welcome.

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.

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.

Click on the URL (" Help" when you start) or run the set-url command with `C-l`.

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.

Contributions are welcome!

Thanks for the feedback. Some answers:

- 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.

Thanks for the suggestion.

The "widget" you are talking about seems to required some specific support from the host REPL, no? Could SLY do it? Could graphical Emacs do it?

I believe I answered most of your notes in the article ;)

(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 :)

Wow, looks like you've got a lot of cool stuff in there! I'll try it out later and give you some feedback!

I've never tested Ammonite, only read the https://ammonite.io/#Ammonite-Shell, so I'm only guessing here.

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! :)

The article presents a few libraries. There is https://github.com/ruricolist/cmd in particular which is very helpful.

I'm going to publish a few more libraries which should help with file manipulation (as I demoed it).

Stay tuned!

Thanks for the list! :)

The binary dump feature is used by projects like StumpWM, Lem and Next.

Thanks for sharing!

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'll check out the other libs, thanks!

Didn't know about this, it looks very cool indeed! Thanks for sharing!

For immutable data structures, there is this helper library which can help: http://quickdocs.org/immutable-struct/

Thanks for the fset link.

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.

I've never used them myself, so in all honesty I have nothing to say about them! :p

That said, I support free software and I believe a proprietary compiler is not a good idea :(

A fun read with some good points, although many of them are a bit dated :p

Indeed, tail-call optimization is not part of the standard, unlike Scheme.

The point of the article is that while the Common Lisp standard is not really focused on functional programming, nothing prevents the implementions (and libraries) of today to be so.

Immutability is something I'm still exploring in Common Lisp. Any pointer, anyone?