9 ms·

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

by distcs 4y ago

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

deleted 4y ago
[deleted]
deleted 4y ago
[deleted]
rmorey 4y ago
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
- distcs 4y ago
  > 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 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?
  - forgotpwd16 4y ago
    >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.
ckolkey 4y ago
My pet theory is that its to do with the rate of new developers to the field. I think the accepted figure is something like "the field doubles every five years". To me, this explains things like idea-churn, wheel-reinvention, and "grandpas tools", where you see tried-and-true tools (emacs, in this case) passed by because they lack modern trappings, or because people just never hear about them.
- davepdotorg 4y ago
  I mean, nice idea, but I'm a 55 year old Emacs user and I work on Textual.
  - willm 4y ago
    CEO Here. 48.
tyingq 4y ago
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 in the blog, it's an editor at heart...not a rich text/tty library for other tools to leverage.
- throw10920 4y ago
  > emacs isn't a library for creating rich text mode applications 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".
  - tyingq 4y ago
    The key word was "library". It's not a library someone can easily pull into their own application. Yes, you can write a pixel editor in emacs, but it's an opinionated ecosystem that doesn't appeal to everyone.
- MonkeyClub 4y ago
  > 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.
  - tyingq 4y ago
    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".
johanvts 4y ago
> I think all of this already possible in Emacs, right? 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.
- __MatrixMan__ 4y ago
  I think the point of textual isn't so much "look what you can do with it." Most of what it does is possible with ncurses also, if you're really committed. But neither ncurses nor emacs feel like modern UI development tools, and that feel (e.g. styling with css) is important to a lot of people.
samwillis 4y ago
> EDIT: Downvoters, care to explain what about this comment violates this site's guidelines? 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. https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html
samwillis 4y ago
> 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.
asah 4y ago
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.
dec0dedab0de 4y ago
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.
margarina72 4y ago
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.
cryptonector 4y ago
> 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.
kleinsch 4y ago
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.
- distcs 4y ago
  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.
JulianWasTaken 4y ago
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).
- forgotpwd16 4y ago
  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.
robenkleene 4y ago
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.

by distcs 4y ago

deleted 4y ago

[deleted]

deleted 4y ago

[deleted]

rmorey 4y ago

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

distcs 4y ago
> 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 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?
- forgotpwd16 4y ago
  >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.

ckolkey 4y ago

My pet theory is that its to do with the rate of new developers to the field. I think the accepted figure is something like "the field doubles every five years". To me, this explains things like idea-churn, wheel-reinvention, and "grandpas tools", where you see tried-and-true tools (emacs, in this case) passed by because they lack modern trappings, or because people just never hear about them.

davepdotorg 4y ago
I mean, nice idea, but I'm a 55 year old Emacs user and I work on Textual.
- willm 4y ago
  CEO Here. 48.

tyingq 4y ago

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 in the blog, it's an editor at heart...not a rich text/tty library for other tools to leverage.

throw10920 4y ago
> emacs isn't a library for creating rich text mode applications 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".
- tyingq 4y ago
  The key word was "library". It's not a library someone can easily pull into their own application. Yes, you can write a pixel editor in emacs, but it's an opinionated ecosystem that doesn't appeal to everyone.
MonkeyClub 4y ago
> 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.
- tyingq 4y ago
  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".

johanvts 4y ago

> I think all of this already possible in Emacs, right? 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.

__MatrixMan__ 4y ago
I think the point of textual isn't so much "look what you can do with it." Most of what it does is possible with ncurses also, if you're really committed. But neither ncurses nor emacs feel like modern UI development tools, and that feel (e.g. styling with css) is important to a lot of people.

samwillis 4y ago

> EDIT: Downvoters, care to explain what about this comment violates this site's guidelines? 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. https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html

samwillis 4y ago

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

asah 4y ago

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.

dec0dedab0de 4y ago

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.

margarina72 4y ago

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.

cryptonector 4y ago

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

kleinsch 4y ago

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.

distcs 4y ago
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.

JulianWasTaken 4y ago

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

forgotpwd16 4y ago
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.

robenkleene 4y ago

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.