12 ms·

Well I care, and so should anyone who would like to see Emacs live on for another 40 years. There will be major new areas of innovation, that will require massi

Well I care, and so should anyone who would like to see Emacs live on for another 40 years. There will be major new areas of innovation, that will require massive amounts of work, and without an energetic and large community Emacs will not be able to adapt.

tonyarkles 6y ago
> There will be major new areas of innovation I’m really curious what you mean by that, and how you see the world evolving such that Emacs, as is, won’t be able to come along with it.
- Dangeranger 6y ago
  Imagine a world where your terminal isn’t emulating a TTY from fifty years ago. Gary Bernhardt gave a talk about this in 2012[0]. [0] https://www.destroyallsoftware.com/talks/a-whole-new-world https://www.destroyallsoftware.com/talks/a-whole-new-world
  - tonyarkles 6y ago
    Pretty cool talk! I love some of the features he's added! https://imgur.com/Gtytll1 https://imgur.com/Gtytll1 An interesting thing that often gets forgotten or missed is that Emacs doesn't depend on a conventional TTY to run. It's already capable of displaying images either in separate buffers or inline. From Gary's talk there, my thoughts would be that a number of the features he's put in there would: a) be potentially better-served as CLI tools instead of baked directly into the IDE, with well-defined inputs and outputs. I have no problem imagining use cases for e.g. the crash navigation stuff outside of an editor (perhaps as part of an error-handling dashboard). b) likely already be possible to build in non-terminal versions of Emacs, without having to design your own terminal and editor from scratch. By no means do I think Emacs is a perfect editor, but I'm also very cautious when pondering "do we rebuild from scratch"-type questions. I'm always keeping my eye on other editors and IDEs, and with varying levels of difficulty, I haven't really come across too many useful things that wouldn't be possible to do within the current Emacs/Elisp environment. Awkward, maybe.
TeMPOraL 6y ago
Well, as sad as it is for someone like me, who lives and breathes Emacs, there are already signs showing. There's still no decent support for C++, even in community. If you have a patience to bash together a number of elisp packages and write some extra config to paper over the idiosyncrasies of your project, then sure, you'll get something mostly working. But then just downloading Visual Studio will get you 90% there. There's support for language servers (and I consider the existence of LSP to be a new hope for Emacs and Vim to stay relevant in the future), but it's arguably so-so. As good as the Emacs community is, it still has pretty limited amount of time and manpower to throw at problems. I feel the wider development world starts to outpace this capacity.

tonyarkles 6y ago

> There will be major new areas of innovation I’m really curious what you mean by that, and how you see the world evolving such that Emacs, as is, won’t be able to come along with it.

Dangeranger 6y ago
Imagine a world where your terminal isn’t emulating a TTY from fifty years ago. Gary Bernhardt gave a talk about this in 2012[0]. [0] https://www.destroyallsoftware.com/talks/a-whole-new-world https://www.destroyallsoftware.com/talks/a-whole-new-world
- tonyarkles 6y ago
  Pretty cool talk! I love some of the features he's added! https://imgur.com/Gtytll1 https://imgur.com/Gtytll1 An interesting thing that often gets forgotten or missed is that Emacs doesn't depend on a conventional TTY to run. It's already capable of displaying images either in separate buffers or inline. From Gary's talk there, my thoughts would be that a number of the features he's put in there would: a) be potentially better-served as CLI tools instead of baked directly into the IDE, with well-defined inputs and outputs. I have no problem imagining use cases for e.g. the crash navigation stuff outside of an editor (perhaps as part of an error-handling dashboard). b) likely already be possible to build in non-terminal versions of Emacs, without having to design your own terminal and editor from scratch. By no means do I think Emacs is a perfect editor, but I'm also very cautious when pondering "do we rebuild from scratch"-type questions. I'm always keeping my eye on other editors and IDEs, and with varying levels of difficulty, I haven't really come across too many useful things that wouldn't be possible to do within the current Emacs/Elisp environment. Awkward, maybe.

TeMPOraL 6y ago

Well, as sad as it is for someone like me, who lives and breathes Emacs, there are already signs showing. There's still no decent support for C++, even in community. If you have a patience to bash together a number of elisp packages and write some extra config to paper over the idiosyncrasies of your project, then sure, you'll get something mostly working. But then just downloading Visual Studio will get you 90% there. There's support for language servers (and I consider the existence of LSP to be a new hope for Emacs and Vim to stay relevant in the future), but it's arguably so-so. As good as the Emacs community is, it still has pretty limited amount of time and manpower to throw at problems. I feel the wider development world starts to outpace this capacity.