4 ms·

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,

• 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".
• distcs 4y ago
  > 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.
  • tyingq 4y ago
    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.
  • sundarurfriend 4y ago
    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.
    • distcs 4y ago
      > 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?
      • funklute 4y ago
        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).
• pjmlp 4y ago
  They could have reached for Turbo Vision and call it a day.
• civopsec 4y ago
  > 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.