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?

Nice! Thanks for sharing!

This would be extremely demanding a project indeed, which is probably one no such thing has really taken off in many decades.

I'm not criticizing the power of TeX in terms of typesetting, I'm only referring to the _language_ here. (And you are aboslutely right, Org and other markup languages are not competing with TeX.)

Imaging the capabilities of TeX with a good programming language.

I don't find WEB beautiful. In my opinion, literate programming (at least in this case) is a pretext to hide a terrible, unexpressive programming language.

As you're saying, Emacs had the good taste to use a Lisp back in those days, so it really is a pity that TeX didn't.

All this is definitely true, but in my opinion not ideal. LuaTeX adds a significant layer of complexity to an already way-too-complex system.

At this point we might want to step back and wonder why this has become so hard.

TeX is a poor foundation to build upon, so I don't think LuaTeX, despite being the best solution currently, is the right direction to explore.

The article is for the bigger part about operating systems, only a minor part is about programming languages (which is important for the matter at hand). It's not pro-Lisp in particular, it's pro-"general-purpose, well tested and well designed programming languages". I don't exlude other programming languages from the picture. The alternative I gave as examples are the ones that I know of, but sure thing there are others out there in Python, Lua, Ruby, you name it.

I personally like S-expressions because they are very general and have deep semantic implications (eval-apply, a.k.a. code is data) that go beyond mere syntactic considerations.

Regarding your examples, if I understand correctly they are not equivalent, so they don't exactly compare.

Here LaTeX would require the \begin{document}...\end{document} bits.

But regardless, TeX is very painful to program with (lack of proper data structures and control structures). It's very important in my opinion.

I don't think that would be enough. At the end of the article I linked the paper "Code staging in GNU Guix" (https://arxiv.org/abs/1709.00833) which explains why 2 stages of code execution are so central in Guix. In practice, this means that a Turing-complete language (Scheme) is used both at the declaration level and the build level. Lots of packages make use of this feature, it brings tremendous flexibility to packaging.