Live data from Hacker News

A year of building for the terminal

textual.textualize.io

61–70 of 95 posts

Re: A year of building for the terminal

#61
post #38
post #27

Impressive work! I am not trying to diminish the awesome work done here but I think all of this is already possible in Emacs, right? And Emacs an be made to run in Terminal if the user wants it to, right? 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 full…

The blog post is from a team that builds a library for creating rich text mode applications in the terminal. The examples include a file manager, a diff tool, a floating gutter, dropdown autocomplete, animated underlines, pixel editor, and so forth. 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 i…

> Your comment is confusing because emacs isn't a library for creating rich text mode applications

The point isn’t what it is. The point is presumably that it can do this task better than the terminal.

Re: A year of building for the terminal

#62
post #27

Impressive work! I am not trying to diminish the awesome work done here but I think all of this is already possible in Emacs, right? And Emacs an be made to run in Terminal if the user wants it to, right? 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 full…

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?

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.

Re: A year of building for the terminal

#63
post #27

Impressive work! I am not trying to diminish the awesome work done here but I think all of this is already possible in Emacs, right? And Emacs an be made to run in Terminal if the user wants it to, right? 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 full…

Many options exist, but in case you are building in python, this is an awesome library. Charm in goland is what I can think of that come as close to it, and in elisp of course you would do that with emacs. While emacs is awesome, not everything that can be done in emacs would be an optimal solutions for all use case. Always use the tool for the job.

Re: A year of building for the terminal

#64
post #60

Earlier quoted context omitted.

Except all such tools assume a lot of implicit knowledge about Emacs itself, and how to navigate it, on the part of the user. Is your argument that no one should create TUI applications except within Emacs? It's pretty confusing at this point.

> Is your argument that no one should create TUI applications except within Emacs? 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…

Arguably, the terminal is more general. Pretty much every developer will at some point have significant interactions with a terminal. The same cannot be said for emacs. On top of that, the terminal is a more general-purpose tool than emacs, and it is much less opinionated than emacs (each TUI tends instead to do their own thing, for good or bad).

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

Re: A year of building for the terminal

#66
post #6

This is an interesting framework, it's refreshing in that you don't need to bootstrap a whole web browser (electron) to build a user interface. 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…

I am someone who used micro-computers such as TRS-80, Apple ][, CP/M and early MS-DOS PC's. I used VisiCalc, MultiPlan, the original MS Word, dBase and many more. One of the most significant pain points with such apps was the lack of stand UI and keyboard conventions.

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.

Re: A year of building for the terminal

#67
post #27

Impressive work! I am not trying to diminish the awesome work done here but I think all of this is already possible in Emacs, right? And Emacs an be made to run in Terminal if the user wants it to, right? 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 full…

> Downvoters, care to explain what about this comment violates this site's guidelines?

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.

Re: A year of building for the terminal

#68

Has TUI accessibility improved at all? 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.

I once asked the dev relations person of a TUI framework company if their stuff worked on a real physical terminal, and they didn't even know what I meant by that. Back to the nursing home for me!

Re: A year of building for the terminal

#70
post #27

Impressive work! I am not trying to diminish the awesome work done here but I think all of this is already possible in Emacs, right? And Emacs an be made to run in Terminal if the user wants it to, right? 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 full…

You could invert everything in this comment and it would be just as valid. If you built this in Emacs, someone would comment: all this is possible in the terminal, new users who flock to Emacs won’t learn the terminal ecosystem, etc. Anything related to Emacs, Rust, JavaScriptjust turns into a religious “use this instead of that” opinion debate where nobody is wrong or right.

Use the tools you want to use. Don’t hassle other people for using different tools.

Post reply on HN