Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A year of building for the terminal

textual.textualize.io

Post reply on HN
Print view View original

71–80 of 95 posts

Re: A year of building for the terminal

#71

Post by JulianWasTaken »

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…

Do you know of an example of a commonly used application which uses the emacs-driven functionality you're referencing, but where the application isn't generally used inside of emacs itself? I.e. do you know of a widely-used program which uses emacs as a library, but not as the top-level application?

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

Re: A year of building for the terminal

#72

Post by carapace »

I went through a TUI phase recently and investigated a slew of these projects. In the end, I just used ncurses, there's no real point in using anything else. The biggest problem (that also affects Textualize) is poor or lacking documentation. But really the fundamental issue is that ncurses is all you need and it already covers all the edges and weird terminals etc.

Re: A year of building for the terminal

#73

Post by robenkleene »

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…

Emacs is great and flexible software, but maintaining an Emacs install for the features described in the blog post, if you're not already using Emacs as a text editor, is a bad idea in my opinion for these reasons:

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.

Re: A year of building for the terminal

#74

Post by jarbus »

I have a very specific use case: I want to have a UI interface around images generated by the kitty graphics protocol. Kitty, the terminal emulator, can render images in full resolution, which has been so helpful for viewing plots over ssh. I made a hacky ui for generating plots as I need them using prompt-toolkit, but having a proper TUI library that supports images would be so much nicer

Re: A year of building for the terminal

#75

Post by distcs »

kleinsch wrote: post #70
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…

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 hass…

I don't see how inverting this comment would make it valid.

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.

Re: A year of building for the terminal

#76

Post by willm »

tambourine_man wrote: post #69

I’m really exited about the work you guys are doing. 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.

Thank you!

Re: A year of building for the terminal

#77

Post by davepdotorg »

carapace wrote: post #72

I went through a TUI phase recently and investigated a slew of these projects. In the end, I just used ncurses, there's no real point in using anything else. The biggest problem (that also affects Textualize) is poor or lacking documentation. But really the fundamental issue is that ncurses is all you need and it already covers all the edges and weird terminals etc.

How long ago did you check the documentation? As of October this year the first full set of docs were published, with more to come: https://textual.textualize.io/

Re: A year of building for the terminal

#78

Post by forgotpwd16 »

JulianWasTaken wrote: post #71
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…

Do you know of an example of a commonly used application which uses the emacs-driven functionality you're referencing, but where the application isn't generally used inside of emacs itself? I.e. do you know of a widely-used program which uses emacs as a library, but not as the top-level application? This is a slightly leading question -- I certainly don't use any such applications, and am not really familiar with any…

I think the question they're making is why a shell-oriented ecosystem usually preferred over an Emacs one. Or differently why most users prefer an environment consisting of distinct libraries/apps rather Emacs and packages made for it.

Re: A year of building for the terminal

#79

Post by carapace »

davepdotorg wrote: post #77
carapace wrote: post #72

I went through a TUI phase recently and investigated a slew of these projects. In the end, I just used ncurses, there's no real point in using anything else. The biggest problem (that also affects Textualize) is poor or lacking documentation. But really the fundamental issue is that ncurses is all you need and it already covers all the edges and weird terminals etc.

How long ago did you check the documentation? As of October this year the first full set of docs were published, with more to come: https://textual.textualize.io/

I just checked my browser history and my latest visit was October 1st. I must have just missed it.

Re: A year of building for the terminal

#80

Post by forgotpwd16 »

distcs wrote: post #36
rmorey wrote: post #35

Earlier quoted context omitted.

I’m not sure emacs is a good comparison here - Emacs is a complete environment and set of capabilities, whereas this is a library/toolkit for Python, much smaller/ more specific scope. I think it may be possible to take a python script, and create a UI for it in emacs, but I think the goal here is an python-native solution to turn a python script into a TUI

> Emacs is a complete environment and set of capabilities 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 termi…

>But I was pondering from user POV.

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.

Post reply on HN