A year of building for the terminal
textual.textualize.io
textual.textualize.io
Now I am not someone who would ask creators not to build something new because something like it already exists. By all means build new stuff and create new tools. It providers options and choice for user. So I fully support work like this.
But I also ponder about user behavior. New users who flock to the modern terminal tools need to learn new keybindings, new shortcuts, new workflows. Yet they are willing to invest that time in learning these modern terminal tools. But many of the same users are averse to investing that time in Emacs. Why is that? What explains this?
EDIT: Downvoters, care to explain what about this comment violates this site's guidelines? My comment is an honest question. You can post comments and explain if you disagree with my premise. But downvoting isn't helping me learn anything.
But so is the shell and the terminal and yet new young folks are much more willing to try out shell+terminal tools than Emacs+packages.
Your comment describes the difference between this toolkit and Emacs perfectly from a dev POV and what you say makes complete sense. But I was pondering from user POV.
I mean when devs use this library/toolkit and create terminal apps, I am sure those terminal apps will find many enthusiastic users. Many of the same users would not find themselves so enthusiastic if Elisp devs provided the same tool to them as an Emacs capability. You see my point? I don't know why this difference in attitude towards terminal tools and Emacs tools exists. Is it because of the reputation of Emacs being old? Or its reputation of unusual keybindings?
Users are first exposed to a shell rather Emacs by running some commands. They then continue down the road, acquire expertise, and improve their experience in the environment they grew accustomed with.
Your comment is confusing because emacs isn't a library for creating rich text mode applications. While it has some things that are somewhat similar to things mentioned in the blog, it's an editor at heart...not a rich text/tty library for other tools to leverage.
It (almost) literally is. You ever hear that old joke "Emacs is a great operating system, now if only it had a decent text editor"? That comes from that reality that Emacs is better at creating "rich text mode applications" (e.g. org-mode, SLIME, magit) than it is at actually being a good out-of-the-box text editor.
Emacs gives you a text-based abstraction that exists on a bunch of platforms, an extensive standard library, and a massive ecosystem for building text mode applications. Including, yes, "in the terminal".
One could say with at least equal merit that Emacs is exactly that: a language and library for creating rich text mode applications, itself being the first application written in it.
To consider Emacs as merely an extensible text editor would be to miss out on what can be done with the digital text metaphor beyond its editing.
But all the functions Emacs has and Elisp together do seem like a library for creating rich text mode applications. Just look at how Magit does text-mode and rich-text visualization of Git commits, trees. Look at how Org-mode formats headings, code blocks, tables in different styles.
Is your argument that no one should create TUI applications except within Emacs? It's pretty confusing at this point.
Not at all. I said in my original comment that I am all for creating TUI applications. And also that the work done by Textual is nothing short of impressive.
What I ask here is why new users are averse to using Emacs+packages when they are ready to put similar time investment in learning TUI applications which also come with their own commands, keybindings, workflows and learning curve?
I think the bottomline is that it's quite natural to delve into TUIs, when needed, whereas emacs requires a bit more of a dedicated interest (I say this as someone whose main driver was emacs for many years, though I've now gone back to (neo)vim).
You keep using that word. I do not think it means what you think it means.
Not a new user, but because I use vim as an editor, IntelliJ as an IDE, and have precisely no interest in emacs.
On the other hand the new TUIs I use are minimal in number - k9s and damon are the extent.
The point isn’t what it is. The point is presumably that it can do this task better than the terminal.
Dired, diff, Linum. Seems to cover these examples pretty well.
I think most people think of emacs as an overly complicated text editor and don't really ask themselves if they should consider learning emacs when they want a diff tool or a file navigator.
Downvotes on HN are not limited to "moderating", users are entitled to use them as they wish, many use them to mark that they disagree with a comment. I think people are disagreeing with your premise, or think you have misunderstood what Textualize is.
The guidelines do however suggest not commenting on voting on your comments:
> Please don't comment about the voting on comments. It never does any good, and it makes boring reading.
The issues is somewhat explained with how you form your question here, you frame it a little as "the users are wrong for not seeing that X is better than Y", that has a habit of pushing people away.
Ultimately is comes down to branding and communication, I have never learnt Emacs because it seems (from the communication around it) to be an elitist and complex ecosystem. I suspect I am not alone.
Countries will rise and fall, the sun will fade, and all that will remain are *nix and emacs.
I've been using terminals for over 30 years, been using linux and other unixes for over 20 years, and I have attempted to learn emacs multiple times. I have never been able to get to the point where i felt comfortable at all using it. In contrast with vi/vim I felt comfortable editing files within 10 minutes. So while I'm not a new user, I think I can offer some anecdata.
Attempting to learn emacs feels like wanting to watch spiderman no way home, and not knowing which of the hundreds of hours of related content you should watch first. Some of it makes your experience more enjoyable, Some of it is barely related, some of it is actively shunned by the creators, some is largely considered required viewing by the community, but not necessarily by the creators.
Emacs has decades of history, plugins and configurations that are entirely overwhelming to someone coming in new. There are a few tutorials out there, but all the ones I have tried felt strangely opinionated, and out of date. One of the first things I learned was that the keybindings are designed for a keyboard that no longer exists, but for some reason the documentation uses the terminology for that keyboard. Why must we read about meta keys when none of us have a meta key? Another thing I learned is that there are so many configurations and plugins, that there are distributions of emacs that come with modified defaults, but that you shouldn't use them until you take the time to learn why you need all of those plugins and settings. But who's advice should I take?
I think for emacs to gain market share there needs to be an official modern tutorial that holds your hand, and walks you through all the basics, and common configurations, including the top X most important plugins and how to use them. All while focusing on the actual benefits over the alternatives, without glossing over it's own negatives. It would need to be written by an emacs expert that is not an emacs zealot. I don't know if such a person exists, I have certainly never met one. It also would need to be updated atleast once a year to keep up to date with changes in the plugin ecosystem.
That is to say, it needs to feel like a thriving active project that wants new users. Instead it feels like a neighborhood pub with a sign that's falling down, and you have to go in the back door because the front one is always locked these days, but all the regulars know that so there is no point in doing anything about it.
Downvotes don't have to be only motivated by the downvoted's breaking site guidelines -- that's what flagging is for. Downvotes can be for any reason.
Use the tools you want to use. Don’t hassle other people for using different tools.
Users seem to like terminals already. The same users who like terminals still turn out to be averse to Emacs.
So if I invert the comment and ask, "Why do you new users who flock to Emacs won't learn the terminal ecosystem", the question would be nonsense because the fact is that new users do not flock to Emacs.
But new users do flock to terminal and still would not touch Emacs with a 10 foot pole. So my comment makes sense only in one direction.
This is a slightly leading question -- I certainly don't use any such applications, and am not really familiar with any, though I can't say I've ever looked.
But I think the above, as other commenters have mentioned, has a lot to do with why this isn't really a good comparison.
Even more so given that even if such applications do exist, programmers definitely like using libraries written or wrapped in their host language over ones simply available over FFI, so someone'd still want the functionality from elisp wrapped in a native API (a Python one in this case).
1. Emacs (with a useful number of plugins installed) is slow to launch, fine if you're using it as a with `emacsclient` as a server, but using it for one-off use cases like these would be unacceptable due to the slow startup time. (E.g., `nnn` as a file manager in contrast opens instantly.)
2. Emacs does not compose well with other Unix tools if you aren't already running Emacs. E.g., you can't pipe to Emacs and process STDIN, this makes it a terrible fit for the diff example from the post.
3. Accomplishing these tasks from a terminal prompt is an unacceptable number of key strokes. E.g., you'd have to launch Emacs itself, and then run at least one other command to perform any of these functions. Simply unacceptable for those of use that value efficiency (e.g., produce as much output as possible per key stroke.)
Frankly, none of this should need to be said, but the highest voted comment on this thread doesn't acknowledge Emacs deficiencies for the use cases described in the blog post.
Disclaimer: Version 0.6.x has a pretty severe flaw where the constraints around hook order are way too strict, and this also prevents conditional renders [1]. I'm working on a full rewrite which will be released as version 0.7.0, which exists on github as a branch right now [2]. Docs also exist for an alpha version of 0.7.0 [3].
[0]: https://docs.rs/intuitive/latest/intuitive/
[1]: https://github.com/enricozb/intuitive/issues/4
[2]: https://github.com/enricozb/intuitive/tree/0.7.0
[3]: https://docs.rs/intuitive/0.7.0-alpha.0/intuitive/index.html
Textualize (Python), Charm (Go) and tui-rs/Cursive (Rust) make building TUI apps appealing, but I'm put off by the idea of making apps like this if they have no screenreader support.
On the roadmap is a browser target for Textual (same API, just rendering in the browser). Once that's available Textual can make use of browser technology for accessibility.
So all operations happening via the websocket connection. Only the GUI in the browser? I bit like Phoenix LiveView.
This would be a really interesting toolkit for building real-time UIs for remote processes.
Are you also considering a "WebView" front end, a little like Electron?
I don't really see it's use case though, mostly cli is used for either:
A) Ability to run in automated environments (e.g CI) - think aws cli
B) Interop, think piping data from grep to xargs
C) Hacking - writing a script quick and dirty to just get a job done
I'd have thought if I was investing enough time to think about user interface, I'd just build my tool in Qt/GTK/JavaFX/Electron etc
Though I can see the argument that if I was building an app with keybinds as controls rather than mouse primarly, probably a framework like this would be the way to go.
The target users here are pretty clearly them. It’s pretty hard to make usable tuis because the libraries kinda suck or are ancient - this project seems to be looking to change that.
I’d even argue that the reason more people don’t use TUIs as much as GUIs is because TUIs aren’t always as intuitive or user friendly. Hopefully this helps that and makes them easier to build usable intuitive guis
Terminals provide a uniform experience everywhere, more or less, and they compose better than browser apps. I can run tmux in asciinema and from there I can ssh elsewhere and use k9s. fzf and my zsh history make it so that it requires a few keystrokes to do anything (contrast this with being at the mercy of several conflicting designer opinions). A bunch of browser tabs is a comparatively clunky experience.
If web or native GUI apps interoperate, it's because their authors had a conversation. Terminal apps interoperate by accident.
Those old terminal apps that used to be used in banks, car hire places, airports, pharmacies and the like were _extremely efficient_ to use when you got to know them. Like, anything could be done with a few muscle-memory keystrokes. I always think of them when I’m in a line and an employee is busy peering and mousing around.
I’m not sure how you could convince a company to go back to something like that though - it just _seems_ so unintuitively unapproachable at first. Maybe if you got a few high profile clients and they could publish how much more efficient they were (presuming they were)?
One of the revolutions of the Macintosh was not just the GUI and Mouse, but the standard visual UI and keyboard shortcuts.
Borland's Turbo Vision almost got us these features for TUI, but it was too late. I am glad to see people taking another crack at it.
So let's make this TUI consistent with the conventions of your preferred GUI. I personally prefer macOS, but I am currently logged into to Windows 10 and KDE Neon. I spend most of my day in VSCode, with lets me configure it any way I want to.
I played with Textual and Rich over the weekend. I found it super compelling to use TUI forms to generate json or other kinds of configs. I particularly like the faux CSS for styling and modeling UI updates as reactive components.
Before I invest further with it, I'm curious where this is all headed and if there will continue to be sustainable development in the future.
Not trying to be snarky or anything -- generally curious! I love the project.
That tab and easing animation is jaw dropping. I can’t shake the “that shouldn’t be possible in a terminal” feeling. In a good way.
And git diff | dunk seems really useful.
Keep going and posting.
I'm not trying to slight Textualize (or any of the other fine TUI systems) when I say that, to me, they all seem like "fun toys". What I mean is that ncurses covers the terminal abstraction (glorified turd-polished teletype machine, literally an electric typewriter) and provides all the building blocks that make sense to provide. All these TUI projects then add an additional abstraction layer to essentially add a GUI toolkit on top.
For my use case, it was more work to learn and use the additional abstractions than it was to implement the behaviour I wanted in ncurses. And this was true for every TUI system I tried, in every language I tried (OCaml, C, Nim, Python).
The conclusion I came to was that TUI systems are essentially nerd toys (I mean that in an affectionate way), one gets "nerd-sniped" into making a TUI system and then sometimes it becomes a "real project" (Textualize has VC money?) but in ten or twenty years... ncurses will still be there, eh?
(My lil tui side-quest got started when a terminal text editor project went by here on HN and I thought, "How hard could it be...?" Nerd-sniped by a classic: write your own text editor. The thing that saved me was that, as I said, I bounced off of the TUI sub-universe into the arms of ncurses, and then I realized that all my design ideas were basically vim, and that snapped me out of it. Whew! Close call!)
From my POV the important thing is that the Textualize folks are having fun. (I don't mean that in a snark way, I'm sincere!)
For these new-fangled frameworks though... Like Textualize? You have to use Python. Fancy Golang? You have to go with Glamour. Rust fan? Wait a couple of months and there will be something equally awesome.
They are all awesome except they are sort of "competing standards" and you never know how long they will be maintained in the future. Whereas ncurses works in every language and will always be around.
Perhaps it’ll lead one or two more people down the path to eventually learning ncurses (or S-Lang, which I tended to use back in the day).
I'm wondering also how Rich compares to something like Python Prompt Toolkit.
So... Doom?
I’ve used Araxis Merge as my diff tool for over a decade. It’s great. I don’t think there’s significant value in reimplementing something in a TUI just for the sake of it.
Nothing wrong with new tools to make building TUI’s easier. I just wish the examples were providing new capabilities rather than old capabilities in a very similar but slightly different form factor.
It all hinges not necessarily on more fanciness in the terminal, but on the availability of data to work on, on other systems to open their data to the terminal in some way. Many SAAS tools have no interest or incentive to do that; is the trend going away from data available the terminal? Example, Kibana and Splunk are silos that provide powerful ways to analyze logs - what else could you possible want more?
Well, even the most sophisticated logfile queries can be repetitive, and those advanced search patterns could be distilled into a script that follows the user's hunches, add a bit of an ad-hoc regression test, correlate it with data from elsewhere, take user input from log files and use it in automated tests, maybe feed it all into a terminal based statistical analysis tool? I don't see myself doing any of that, the devs want a clickable link to the relevant Kibana and they are getting that.
More colors in terminals are nice but is it enough to make a difference?
But the topic here is exactly the sort of framework whose apps are not particularly easily scriptable and integratable in typical shell-driven workflows.
A terminal is not meant to resemble graphical UIs with all those whistles and bells! Looks like I am the only one who is wondering :D ;)
Actually I would argue that graphical UIs copied terminal UIs that existed first and in some cases they did not catch up even as of now. See file managers. There is Total Commander on Windows, which managed to surpass the old Midnight Commander in functionality and ease of use, but that's about it. Very hard to find a decent file manager on Linux or OSX that comes even close to mc.