A year of building for the terminal • Hacker News Board

Re: A year of building for the terminal

#51

Post by tyingq » Thu, Dec 22, 2022, 4:19 PM UTC

MonkeyClub wrote: post #48

tyingq wrote: post #38

Earlier quoted context omitted.

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…

> emacs isn't a library for creating rich text mode applications. 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.

I do get the viewpoint, but was pointing out the difference is "library you can use in your own app" versus "you can build a similar app wholly inside emacs, using it's very opinionated ecosystem".

Re: A year of building for the terminal

#52

Post by samwillis » Thu, Dec 22, 2022, 4:20 PM UTC

distcs wrote: 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 many of the same users are averse to investing that time in Emacs. Why is that? What explains this?

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.

Re: A year of building for the terminal

#53

Post by distcs » Thu, Dec 22, 2022, 4:20 PM UTC

tyingq wrote: post #38

distcs wrote: 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.

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.

Re: A year of building for the terminal

#54

Post by tyingq » Thu, Dec 22, 2022, 4:23 PM UTC

distcs wrote: post #53

tyingq wrote: post #38

Earlier quoted context omitted.

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

Yes, but it's sort of like saying nobody should use libcurl because you can already write a browser plugin in chrome. An opinionated extendable ecosystem isn't the same as a library even if they can do similar things.

Re: A year of building for the terminal

#55

Post by asah » Thu, Dec 22, 2022, 4:23 PM UTC

distcs wrote: 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…

Actually, you got my upvote - emacs solved this problem 3 decades ago (!), runs everywhere, is easy to extend, and I'm gonna wager that emacs has far more users than these bespoke terminal programs, which come and go.

Countries will rise and fall, the sun will fade, and all that will remain are *nix and emacs.

Re: A year of building for the terminal

#56

Post by __MatrixMan__ » Thu, Dec 22, 2022, 4:24 PM UTC

kjcondon wrote: 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 spend a lot of time with k9s, a TUI, and if there's a browser based or native GUI version, I don't care.

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.

Re: A year of building for the terminal

#57

Post by sundarurfriend » Thu, Dec 22, 2022, 4:27 PM UTC

distcs wrote: post #53

tyingq wrote: post #38

Earlier quoted context omitted.

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

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.

Re: A year of building for the terminal

#58

Post by jrmg » Thu, Dec 22, 2022, 4:32 PM UTC

kjcondon wrote: 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…

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.

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

Re: A year of building for the terminal

#59

Post by pjmlp » Thu, Dec 22, 2022, 4:32 PM UTC

tyingq wrote: post #38

distcs wrote: 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…

They could have reached for Turbo Vision and call it a day.

Re: A year of building for the terminal

#60

Post by distcs » Thu, Dec 22, 2022, 4:35 PM UTC

sundarurfriend wrote: post #57

distcs wrote: post #53

Earlier quoted context omitted.

> Your comment is confusing because emacs isn't a library for creating rich text mode applications. 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.

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 commands, keybindings, workflows and learning curve?