1. 17
  1.  

  2. 7

    Some points:

    • I agree with the sentiment we can do better in shells than Unix - PowerShell is very interesting, not just because of the scripting language being typed, but the way you interact with the system as well.

    • I think putting anything more than a command-line conversation in a glorified vt100 is counterproductive at best and reactionary at worst - we can do so much better with actual GUIs, with the advantages that they bring. (Even a command line shell might be better done in a real GUI - see Mathematica notebooks and Jupyter for rich REPLs, and Acme, pad, Oberon, and MPW for editor-shell hybrids.)

    I agree with this article’s sentiment, even if eshell isn’t my way. It’s such a shame a slavish adherence to “the Unix philosophy” has held back UI research and experimentation with developer tools and command lines. Emacs harkens back to the Lisp machine, even if it’s just a shadow of what a real one could do.

    1. 6

      we can do so much better with actual GUIs, with the advantages that they bring

      Maybe. A GUI is discoverable in a way a CLI isn’t and convenient when you do something infrequently but my experience is they limit rather than extend what I do as my expertise grows. For example, Handbrake UI is an improvement over cli for ripping my kid’s DVD’s both because I don’t want to spend the time fiddling with ffmpeg, etc. on a one off and because the feedback (adding to queue, progress, etc.) is better. On the other hand ffmpeg at the command line is perfect for batch adjusting the audio gain on videos or copying streams to a different container format. Two mildly interesting examples where a simple UI improves my productivity are bpython and, in Emacs, magit. There’s no question that I make fewer mistakes and have an easier time when I use those even though I already know [more than I’d like of] the underlying tools.

      1. 5

        By this, I don’t mean GUIs vs. command lines; they have both have a place and can compliment and improve each other, as mentioned. I mean things like curses based UIs, or the old Turbo Vision “TUIs.” These poorly emulate a GUI inside a vt100-like thing, and our attachment with them holds us back.

      2. 2

        I think putting anything more than a command-line conversation in a glorified vt100 is counterproductive at best and reactionary at worst - we can do so much better with actual GUIs, with the advantages that they bring.

        I agree in principle that such a thing could and maybe even should exist, but for a lot of the things I do, TUIs still end up the least-bad thing currently available to me. In the cases I use them, I like three things about them: 1) ability to run remotely, 2) sessions are stored on the remote side and persistent, so a flaky local connection doesn’t kill things, and 3) there’s very low UI lag.

        For years, the main “real GUI” satisfying #1 was X, but it’s not very good at #2 or #3. I’ve heard NX fixes that, but it appeared after I’d stopped using X, so I haven’t taken a look yet (maybe I should?). The modern-era alternative is webapps, but they often aren’t great with #2 and rarely satisfy #3; despite a pile of newer technology, clicking around in a webapp in Chrome or Firefox ends up usually feeling far more sluggish than an ncurses app in iTerm does. This all seems like it should be fixable, but as it is now it feels very much like a set of tradeoffs rather than a clearly superior modern solution that makes TUIs obsolete.

        1. 2

          Even a command line shell might be better done in a real GUI - see Mathematica notebooks and Jupyter for rich REPLs, and Acme, pad, Oberon, and MPW for editor-shell hybrids.

          And Emacs! org-mode is pretty much a Jupyter-like notebook, except that it doesn’t result in a giant JSON blob. Like Jupyter, you can execute code fragments, plot graphs, display the output inline, etc. Similarly to Jupyter, I have used org-mode to train small neural networks, visualize the decision boundaries, etc.

          I think for the larger population, elisp is one of the things that holds people back from Emacs. But it seems more editors are moving in this direction, e.g. Sublime Text can display HTML fragments inline, which is e.g. used one of the most-widely used LaTeX plugins to render inline equations, but also a plugin that can connect to Jupyter kernels and visualize the results [1].

          [1] https://github.com/ngr-t/SublimeHermes

        2. 2

          I think video is a far better medium for showing why something is useful or better. Text is good for the detail afterwards, but I’d love to see a power user work in eshell.

          1. 1

            Even though eshell is also my main shell, the article seems a bit of an overstatement: I wouldn’t say that eshell is that far from a standard UNIX shell to be such a step forward. I understand the feeling and I hope that eshell is able to walk its own way, but currently it just seems like a regular UNIX shell inside Emacs. However, it is always nice to see other fellow eshell users out there!

            1. 1

              I like eshell, but it doesn’t quite solve all my problems since it chokes on large outputs. Still occasionally handy esp given emacs tramp is seamlessly integrated so you can cd into a server or vm or container. (ssh/vagrant/docker/lxc)

              1. 1

                Doesn’t eshell lack pipe support, among other things?

                My general impression has been that even though emacs is my main editor, it’s shell support has been relatively lacking. I either have to use ansi-term, but then lack emacs-like editing support, or use eshell and lack (proper) shell support. Or maybe I just haven’t read up on all the documentation I should have. It’s quite disappointing that I usual end up using a terminal emulator in the end, but on the other hand, if a proper emacs interface (magit, AucTeX, …) exists, it’s at least as good or better than what the shell implementation has to offer (especially when it comes to TUIs).