11 ms·

The cursor stays in the viewport because, deep down, Emacs still thinks that it's outputting to a 1970s-era ASCII terminal. See this https://www.facebook.com/n

The cursor stays in the viewport because, deep down, Emacs still thinks that it's outputting to a 1970s-era ASCII terminal. See this https://www.facebook.com/notes/daniel-colascione/buttery-smooth-emacs/10155313440066102/ https://www.facebook.com/notes/daniel-colascione/buttery-smo... “Internally, Emacs still belives it’s a text program, and we pretend Xt is a text terminal, and we pretend GTK is an Xt toolkit. It’s a fractal of delusion.” For years, James Gosling, author of the first version of Emacs that ran on Unix (the ancestor of GNU Emacs), has been begging people to stop using Emacs. Emacs is in a race, not against Vim, but against VS Code and Atom for which editor can be more easily customized. In the long run, it doesn't look good for Emacs.

jonathanstrange 8y ago
For me as a daily Emacs user this sounds like another "editor war" rant. I neither find Emacs hard to customize nor do I think it has any substantial limitations other than the ones that are based on my own lack of knowledge. It's always fair to compare it to Vim, but I don't think it makes much sense to compare it in general to VS Code or Atom. One major reason for me to use Emacs and not newer software is that it is not only cross-platform but also gives some confidence that I will be able to use it in twenty years from now on a new platform. The same could be said about Vim. In comparison to these two, newer editors sometimes appear too ephemeral and fragile to me. (Then again, I used to use BBedit on the Mac and just found out that it's still around! What a nice surprise!)
- jhall1468 8y ago
  Both Atom and VSCode are multiplatform and can run on any platform emacs can. Hell there's a version of it that runs in-browser. Both have commercial backing and the platform is built ok Chrome. Hard to imagine a world where any of that adds up to ephemeral.
  - LanceH 8y ago
    Any platform? Like the terminal on my server?
    - jhall1468 8y ago
      No, like your browser since it's a GUI? A terminal isn't a platform.
      - gilnaa 8y ago
        Not all environments have GUI or need to have it
        jhall1468 8y ago
        Never said otherwise. Just assumed my statement would be clear that environments lacking a windowing system wouldn't qualify given GUIs require a windowing system.
  - PeCaN 8y ago
    I'd love to use Atom on a little QNX system, can you tell me where I can find the Atom distribution? It's possible to build Emacs on it.
    - jhall1468 8y ago
      That's my bad, I should expect stupid responses when I make a stupid statement. Major platform where, you know, it makes sense to have. You'd "love" to have Atom on your realtime OS? For what, exactly?
      - gilnaa 8y ago
        I'd bet he'd want to edit text; but I'm no fortune teller.
        jhall1468 8y ago
        You'd probably use a text editor in that case. I'd bet most operating systems include one.
      - PeCaN 8y ago
        I need to work on my disruptive startup's decentralized AI blockchain machine learning product using Vue.js from my car's infotainment system. Actually though pre-6.6 QNX had a great GUI and is capable of running on desktops and laptops just fine¹. I rather like it. ¹ Hardware support is not great but way better than you might be expecting. Either way, it runs fine in VMWare and VirtualBox. I'm currently trying to acquire some parts to build a PowerPC laptop for QNX.
- rusk 8y ago
  Same. I used to swear by Intellij but they just kept on changing things, and even breaking things on me the odd time. This latest emacs upgrade has been seamless and hasn't required any cognitive overhead to transition. That said, I'll always be back to IntelliJ for heavy edits. There's nothing better for Java. I find for less structured languages the less-structured approach engendered by emacs is an advantage.
  - saulrh 8y ago
    emacs has a couple of packages working to implement the editor side of the language server protocol, so it's probably not long until it's at rough feature parity for structured editing of languages with rich semantics.
- oblio 8y ago
  For some perspective: BBEdit - launched in 1992 (26 years ago), still around. Notepad++ - launched in 2003 (15 years ago), still around. Textmate - launched in 2004 (14 years ago), still around. Sublime - launched in 2008 (10 years ago), still around. Almost all the mainstream editors since 1995 at least are around. They have been marginalized, but they're generally around. Especially cross platform editors and even more so Open Source ones have great survival characteristics. That's why both Atom and VS Code seem like solid long term bets.
  - mseebach 8y ago
    To see why this isn't necessarily the case, add to your list all the text editors launched between 1992 and 2008 that are no longer around ("being around" defined as being able to install and run on whatever OS you're using on your main computer with no special effort).
    - mr_overalls 8y ago
      Exactly. The post above yours is simply an illustration of survivorship bias.
      - oblio 8y ago
        I'd be interested to hear about former mainstream editors from that time that are gone. Especially cross platform and Open Source ones :)
        fredsanford 8y ago
        Brief, Multiedit, Codewright, Semware, Slickedit and Epsilon used to keep the lights on at many programming/tech magazines. You don't hear much about them anymore... Clark Maurer still updates Slickedit at least annually though.
        oblio 8y ago
        You made me curious as I'd never heard of any of these editors... (except for Slickedit, I think) A bit of digging around: Brief seems completely dead, was killed off by Borland. Multiedit seems operational: http://multieditsoftware.com/ http://multieditsoftware.com/ It doesn't seem to active, but you can still buy the product. Semware is still technically "alive": http://www.semware.com/ http://www.semware.com/ It was last updated in 2005, so there's that :) Slickedit: is definitely operational: https://www.slickedit.com/ https://www.slickedit.com/ I have no idea why you're counting it as dead? Epsilon: seems operational http://www.lugaru.com/ http://www.lugaru.com/ They even had a release in 2018. To also clarify my previous statement, in the history of software, there's pre-mass PC and pre-internet. In my opinion the 2 periods are not comparable. Anything which was launched before 1995-9 or so is way more likely to have died. The mass PC and the internet have offered even commercial products much higher resilience. Now, if a tool for developers reaches the mainstream, it super likely to stick. I find very often that arguments by Emacs and Vim users come from a time before 1999 or so, when companies were super volatile. Look at this: https://www.joelonsoftware.com/2003/08/01/rick-chapman-is-in-search-of-stupidity/ https://www.joelonsoftware.com/2003/08/01/rick-chapman-is-in...
- BooneJS 8y ago
  Emacs is compared to vim because both can be run in a terminal on a remote machine, not because it’s the JS-editor-of-the-month. There’s a fairly decent chance I’d switch away from vim if I ever had a job where I could edit code locally.
  - oblio 8y ago
    I see this occasionally. Why can't you edit locally?
    - BooneJS 8y ago
      Sometimes it’s policy (no source code on laptops), but mostly it’s because my line of work uses the verilog language and the tool suites require “very stable” (read: archaic) versions of Linux.
      - oblio 8y ago
        Damn, that's a shame, I hope that the pay is good at least :)
      - hprotagonist 8y ago
        do you know about TRAMP? https://www.emacswiki.org/emacs/TrampMode https://www.emacswiki.org/emacs/TrampMode
      - vq 8y ago
        Can you use ssh/scp? Emacs is able to use that to edit files remotely. I often use it when I work with small Arm Linux boards. https://www.gnu.org/software/emacs/manual/html_node/emacs/Remote-Files.html https://www.gnu.org/software/emacs/manual/html_node/emacs/Re...
  - xfer 8y ago
    sshfs is a thing. If i had to use remote machines only, i would use tramp; not run an emacs instance on a remote machine. I haven't had good experience running editors inside tmux.
  - 8y ago
- Mononokay 8y ago
  VS Code and Atom are practically guaranteed to run until the end of time at this point. The sole benefit of web apps is that they're more likely to remain functional than native ones.
  - deleted 8y ago
    [deleted]
emodendroket 8y ago
I have to admit that I mostly use IntelliJ and related products or VSCode these days, but I can't give up the emacs key bindings.
gkya 8y ago
Emacs is in no race with text editors. If Emacs was a pack of a dozen of eggs, text editing would be that one egg on the corner with the fragile shell. Mr. Java can beg all he wants, but one thing people don't get is that Emacs is not a text editor. It has one, yes, but it's a program where the user can interactively manipulate data presented in buffers via Lisp, and keys bound to some Lisp. Thus, it is in a league of its own. The only modern player that tried to enter was Light Table for Clojure, but it did not hold on, I guess. Then there is Climacs, Hemlock and Edwin, but they don't have much or any adoption. I have not used one program til this day that is easier and more optimised for user customisation than Emacs. And if not much people will be using it in the future, be it so. But it will be around as long as computers with physical keyboards will be (and will probably adapt if they ever become obsolete).
- fpoling 8y ago
  Emacs is not optimized for customizations. It allows to customize everything, but the efforts required often becomes a programming project on its own. 20 years ago I spent eventually months to make the buffers switch the way I liked. Yes, i made it work precisely the way I wanted, but I suspect it would be easier to implement that feature in a native code as a patch for an editor where a configuration is just an ini file.
  - TeMPOraL 8y ago
    In any other program, such customization you made would be impossible. The things you can customize in other editors and IDEs, you can customize through the M-x customize interface. The things you'd install as plugins, you can get from Emacs package manager. All other things that you can - with smaller or greater amount of work - alter in elisp, are more-less impossible in other editors.
    - fpoling 8y ago
      Think about why one needs a sofisticated customization in an editor. It implies it's defaults reflecting the workflow of the developers are significantly different from yours. To fix this you essentially must become a developer. And since the feature you want is not what the developers want, your has to maintain the feature as long as you use the editor. Now think about all the time one spends on that. If it does not feel like fun or hobby, then one better try to find some other editor that matches what one wants by default or after 5 minutes of poking in the preferences menu.
AlexCoventry 8y ago
If you're using a ceremonious language like Java, the automation in a modern editor could be useful. I think that's what Gosling was getting at.
- kamaal 8y ago
  Java by many definitions is a bit like assembly language of our current times. You will end up stitching highly verbose pieces of code. Which is why Java IDEs have specific features to emit get/set functions etc. Plus you will have to access a method hiding 5 class layers below. You will need IDEs designed to do this sort of work really well. Emacs and Vi have been designed to largely play with Text, plus I think with Java's verbosity you are just better off with a specialized IDE.
  - varjag 8y ago
    Wouldn't call assembly programming "highly verbose". If anything it's opposite - very little boilerplate, if at all.
    - kqr 8y ago
      Do we have different ideas of what boilerplate is? Almost everything in assembly is boilerplate because there are no advanced, built in features. (Sure, modern x86 assembly is a complex language with many advanced builtins but they are generally meant to express solutions in the x86 domain, not the business domain.)
      - varjag 8y ago
        I stick to traditional definition. > In computer programming, boilerplate code or boilerplate refers to sections of code that have to be included in many places with little or no alteration. https://en.wikipedia.org/wiki/Boilerplate_code https://en.wikipedia.org/wiki/Boilerplate_code
zeveb 8y ago
> Emacs is in a race, not against Vim, but against VS Code and Atom for which editor can be more easily customized. In the long run, it doesn't look good for Emacs. Emacs is extensible in Lisp; VS Code & Atom are extensible in JavaScript. The point goes to emacs. Emacs has Magit, Org Mode, AucTeX, notmuch, gnus, ERC, emms, TRAMP, calc, calendar, Diary Mode — what do VS Code & Atom have? The point goes to emacs. Emacs runs in a GUI. Emacs runs in a terminal. Emacs runs on a machine halfway across the world on the other side of an SSH session. The point goes to emacs. Emacs is far from perfect, but it's far ahead of its competition.
- oblio 8y ago
  VS Code can be extended in Typescript: https://code.visualstudio.com/docs/extensions/overview#_writing-an-extension https://code.visualstudio.com/docs/extensions/overview#_writ... Philosophically Lisp may be superior, but I'm not sure it's so clear cut in real life. Regarding most of the features you present, a good chunk of them aren't editing features and another chunk are related to running in a limited environment (the terminal). So a big part of them aren't as strong selling points as you seem to think they are, since many people don't care about them.
  - kqr 8y ago
    One of the frequently overlooked benefits of Lisp is that the culture around Lisp actively promotes software that is /supposed/ to be extended by its user and sort of grow into the user, rather than the user growing into it. There is also a huge difference between "building an extension" and "extending the actual code that is the running process." In Emacs, one can redefine one of its core functions at the push of a button, and suddenly all new calls will call your version of the function. If your redefined function has a breakpoint in it, you'll be able to debug-step into the core of the editor as it is running. Not sure how well TypeScript in VS Code works in that regard.
    - oblio 8y ago
      I've found that I prefer a very nice, coherent design by someone who spent a lot of time thinking about the problem in a holistic manner, than tinkering with stuff. And I do/did tinker a lot. IMO that's the best design: a solid, coherent design with clear extension points. Of course, I'm the Anti-Emacs by saying this :)
anamoulous 8y ago
vscode can only be customized by an extension. There's a bunch of one off plugins you have to install to get little bits of functionality that you can get by pasting 15 lines of elisp from the emacs wiki. If no one has built that extension yet, you have to learn to build one yourself. You could always create private "personal" extension and keep it local, but that workflow is tedious. I'm not saying vscode is less extensible or customizable though, I'm saying there's a barrier to ad-hoc personalization that's will keep it from ever being more easily customized (unless you and I have different definitions of what is "easily customized"). Script Commands[1] is an interesting plugin that attempts to address this shortcoming, but I'd like to see something official at some point. [1] https://marketplace.visualstudio.com/items?itemName=mkloubert.vs-script-commands https://marketplace.visualstudio.com/items?itemName=mklouber...
- oblio 8y ago
  The upside for anything like this is that the barrier to entry being higher, the people who do this tend to create higher quality things overall and maybe even share them. It's not my idea, it's the premise from http://winestockwebdesign.com/Essays/Lisp_Curse.html http://winestockwebdesign.com/Essays/Lisp_Curse.html
  - anamoulous 8y ago
    Have you looked at the VS Code marketplace? It is not great. The LSP modes are great and then here and there you get interesting extensions, but a bunch of it I would not call higher quality by any means. (I use vscode all day for my work projects and generally enjoy it and am not trying to drag it, just trying to be honest about this aspect of it.)
    - oblio 8y ago
      I have, and I'd fault the immaturity of the ecosystem more than anything. VS Code was launched just 3 years ago. I don't even know if it had extensions from the beginning. The extensions I've generally used were quite solid, haven't had many problems with them.
kamaal 8y ago
>>For years, James Gosling, author of the first version of Emacs that ran on Unix (the ancestor of GNU Emacs) Then I discovered that Gosling's Emacs did not have a real Lisp. It had a programming language that was known as ‘mocklisp’, which looks syntactically like Lisp, but didn't have the data structures of Lisp. So programs were not data, and vital elements of Lisp were missing. Its data structures were strings, numbers and a few other specialized things. From : https://www.gnu.org/gnu/rms-lisp.en.html https://www.gnu.org/gnu/rms-lisp.en.html
- kazinator 8y ago
  Then he continued to mock lisp with an AST preprocessor for C called Ace [1989], and through Java.
armitron 8y ago
This is not at all fair or accurate in terms of general architecture. The quote from Daniel Colascione describes some implementation details that can and will be improved. The same Daniel Colascione is very passionate about Emacs and spends a lot of his free time working on it. Moreover, you did not mention any of the things that make Emacs great. Its mode-based buffer-centric architecture comes from the Lisp Machines, maps well to countless disparate tasks and has certainly stood the test of time. Emacs is essentially the closest thing we have to a Lisp Machine. Atom and VS Code on the other hand are ad-hoc editors on top of environments that can only be said to re-implement old, dead-end ideas and do so badly. I'm not sure why you mentioned Gosling, if not to mislead, since he's never as far as I know been a Lisper (Mocklisp is a mockery of Lisp) and his contributions to GNU Emacs -- besides inspiring Stallman to come up with something better -- were minimal and very quickly rewritten or removed. Gosling's influence to the architecture (Lisp Machines, Symbolics) and evolution of GNU Emacs has been NIL.
krylon 8y ago
Regarding Emacs vs. VS Code, it is kind of funny that Emacs was once the canonical big, fat, bloated editor, but it did not grow much bigger since then. So today, Emacs is kind of lightweight: On my work computer, VS Code will easily gobble up half a gigabyte of RAM with only a handful of files open, while Emacs with dozens of buffers consistently stays below 100 MB. Compared to nvi or mg, GNU Emacs is still pretty big, but I think the size-to-feature-richness ratio is more balanced in Emacs. Also, I will come out and admit that I like Emacs for being Emacs. I have tried VS Code at work, and it is not bad. But from a certain point of view, VS Code is just Emacs Re-Imagined using Javascript instead of Lisp. And Emacs just has a ~30-year head start on VS Code at being Emacs. Last, but not least, the Emacs default key bindings for moving the cursor around are by now so deeply ingrained in my muscle memory that I will not willingly switch to an editor that does not support them. And all the Emacs-keybindings extensions for VS Code I have tried were ... not quite there, yet, at least for me.
- varjag 8y ago
  A few years ago I was astonished to see Gnome's gedit having bigger memory footprint than very tricked out Emacs.
- macavity23 8y ago
  Vi folks used to make fun of Emacs as ‘Eight Megabytes And Constantly Swapping’!
deleted 8y ago
[deleted]
kazinator 8y ago
So those GNU Emacs screenshots with embedded graphics are fakes? Like: https://www.gnu.org/software/emms/screenshots.html https://www.gnu.org/software/emms/screenshots.html
- kqr 8y ago
  Not fake. My report authoring process includes a live updating PDF preview in an Emacs sidebar. However, this graphics stuff is still bolted onto a core engine that treats everything as a text terminal.
  - kazinator 8y ago
    Won't it fly away if you don't bolt it to something?
mindB 8y ago
You have a source on Gosling trying to get people not to use Emacs (not calling you out; just genuinely curious)?
- rudolfwinestock 8y ago
  From ten years ago: https://www.computerworld.com.au/article/207799/don_t_use_emacs_says_java_father/ https://www.computerworld.com.au/article/207799/don_t_use_em...
kaushalmodi 8y ago
> Emacs is in a race, not against Vim, but against VS Code and Atom for which editor can be more easily customized. In the long run, it doesn't look good for Emacs. I use Emacs as my daily driver. Your comment feels very much like from someone who hasn't realized the true powers of Emacs-Lisp. Even if someone doesn't hack in Elisp, once they discover power packages like Org mode or Magit, they will know right away that there's no competition for those out there (vim, Atom, VS Code, etc). > For years, James Gosling, author of the first version of Emacs that ran on Unix (the ancestor of GNU Emacs), has been begging people to stop using Emacs. Even if that's the case, what's the point he's trying to make? Why? How does that matter to folks who are using Emacs today, and know it first hand that it's the best hackable text buffer engine out there?
mark_l_watson 8y ago
I am tied to using Emacs because so much of my work is done in SSH sessions on remote servers. I own licenses for all JetBrains IDEs, and find real value in them, but I can’t imagine not using Emacs + configurations for favorite languages + orgmode frequently and every day.

jonathanstrange 8y ago

For me as a daily Emacs user this sounds like another "editor war" rant. I neither find Emacs hard to customize nor do I think it has any substantial limitations other than the ones that are based on my own lack of knowledge. It's always fair to compare it to Vim, but I don't think it makes much sense to compare it in general to VS Code or Atom. One major reason for me to use Emacs and not newer software is that it is not only cross-platform but also gives some confidence that I will be able to use it in twenty years from now on a new platform. The same could be said about Vim. In comparison to these two, newer editors sometimes appear too ephemeral and fragile to me. (Then again, I used to use BBedit on the Mac and just found out that it's still around! What a nice surprise!)

jhall1468 8y ago
Both Atom and VSCode are multiplatform and can run on any platform emacs can. Hell there's a version of it that runs in-browser. Both have commercial backing and the platform is built ok Chrome. Hard to imagine a world where any of that adds up to ephemeral.
- LanceH 8y ago
  Any platform? Like the terminal on my server?
  - jhall1468 8y ago
    No, like your browser since it's a GUI? A terminal isn't a platform.
    - gilnaa 8y ago
      Not all environments have GUI or need to have it
      - jhall1468 8y ago
        Never said otherwise. Just assumed my statement would be clear that environments lacking a windowing system wouldn't qualify given GUIs require a windowing system.
- PeCaN 8y ago
  I'd love to use Atom on a little QNX system, can you tell me where I can find the Atom distribution? It's possible to build Emacs on it.
  - jhall1468 8y ago
    That's my bad, I should expect stupid responses when I make a stupid statement. Major platform where, you know, it makes sense to have. You'd "love" to have Atom on your realtime OS? For what, exactly?
    - gilnaa 8y ago
      I'd bet he'd want to edit text; but I'm no fortune teller.
      - jhall1468 8y ago
        You'd probably use a text editor in that case. I'd bet most operating systems include one.
    - PeCaN 8y ago
      I need to work on my disruptive startup's decentralized AI blockchain machine learning product using Vue.js from my car's infotainment system. Actually though pre-6.6 QNX had a great GUI and is capable of running on desktops and laptops just fine¹. I rather like it. ¹ Hardware support is not great but way better than you might be expecting. Either way, it runs fine in VMWare and VirtualBox. I'm currently trying to acquire some parts to build a PowerPC laptop for QNX.
rusk 8y ago
Same. I used to swear by Intellij but they just kept on changing things, and even breaking things on me the odd time. This latest emacs upgrade has been seamless and hasn't required any cognitive overhead to transition. That said, I'll always be back to IntelliJ for heavy edits. There's nothing better for Java. I find for less structured languages the less-structured approach engendered by emacs is an advantage.
- saulrh 8y ago
  emacs has a couple of packages working to implement the editor side of the language server protocol, so it's probably not long until it's at rough feature parity for structured editing of languages with rich semantics.
oblio 8y ago
For some perspective: BBEdit - launched in 1992 (26 years ago), still around. Notepad++ - launched in 2003 (15 years ago), still around. Textmate - launched in 2004 (14 years ago), still around. Sublime - launched in 2008 (10 years ago), still around. Almost all the mainstream editors since 1995 at least are around. They have been marginalized, but they're generally around. Especially cross platform editors and even more so Open Source ones have great survival characteristics. That's why both Atom and VS Code seem like solid long term bets.
- mseebach 8y ago
  To see why this isn't necessarily the case, add to your list all the text editors launched between 1992 and 2008 that are no longer around ("being around" defined as being able to install and run on whatever OS you're using on your main computer with no special effort).
  - mr_overalls 8y ago
    Exactly. The post above yours is simply an illustration of survivorship bias.
    - oblio 8y ago
      I'd be interested to hear about former mainstream editors from that time that are gone. Especially cross platform and Open Source ones :)
      - fredsanford 8y ago
        Brief, Multiedit, Codewright, Semware, Slickedit and Epsilon used to keep the lights on at many programming/tech magazines. You don't hear much about them anymore... Clark Maurer still updates Slickedit at least annually though.
        oblio 8y ago
        You made me curious as I'd never heard of any of these editors... (except for Slickedit, I think) A bit of digging around: Brief seems completely dead, was killed off by Borland. Multiedit seems operational: http://multieditsoftware.com/ http://multieditsoftware.com/ It doesn't seem to active, but you can still buy the product. Semware is still technically "alive": http://www.semware.com/ http://www.semware.com/ It was last updated in 2005, so there's that :) Slickedit: is definitely operational: https://www.slickedit.com/ https://www.slickedit.com/ I have no idea why you're counting it as dead? Epsilon: seems operational http://www.lugaru.com/ http://www.lugaru.com/ They even had a release in 2018. To also clarify my previous statement, in the history of software, there's pre-mass PC and pre-internet. In my opinion the 2 periods are not comparable. Anything which was launched before 1995-9 or so is way more likely to have died. The mass PC and the internet have offered even commercial products much higher resilience. Now, if a tool for developers reaches the mainstream, it super likely to stick. I find very often that arguments by Emacs and Vim users come from a time before 1999 or so, when companies were super volatile. Look at this: https://www.joelonsoftware.com/2003/08/01/rick-chapman-is-in-search-of-stupidity/ https://www.joelonsoftware.com/2003/08/01/rick-chapman-is-in...
BooneJS 8y ago
Emacs is compared to vim because both can be run in a terminal on a remote machine, not because it’s the JS-editor-of-the-month. There’s a fairly decent chance I’d switch away from vim if I ever had a job where I could edit code locally.
- oblio 8y ago
  I see this occasionally. Why can't you edit locally?
  - BooneJS 8y ago
    Sometimes it’s policy (no source code on laptops), but mostly it’s because my line of work uses the verilog language and the tool suites require “very stable” (read: archaic) versions of Linux.
    - oblio 8y ago
      Damn, that's a shame, I hope that the pay is good at least :)
    - hprotagonist 8y ago
      do you know about TRAMP? https://www.emacswiki.org/emacs/TrampMode https://www.emacswiki.org/emacs/TrampMode
    - vq 8y ago
      Can you use ssh/scp? Emacs is able to use that to edit files remotely. I often use it when I work with small Arm Linux boards. https://www.gnu.org/software/emacs/manual/html_node/emacs/Remote-Files.html https://www.gnu.org/software/emacs/manual/html_node/emacs/Re...
- xfer 8y ago
  sshfs is a thing. If i had to use remote machines only, i would use tramp; not run an emacs instance on a remote machine. I haven't had good experience running editors inside tmux.
- 8y ago
Mononokay 8y ago
VS Code and Atom are practically guaranteed to run until the end of time at this point. The sole benefit of web apps is that they're more likely to remain functional than native ones.
- deleted 8y ago
  [deleted]

emodendroket 8y ago

I have to admit that I mostly use IntelliJ and related products or VSCode these days, but I can't give up the emacs key bindings.

gkya 8y ago

Emacs is in no race with text editors. If Emacs was a pack of a dozen of eggs, text editing would be that one egg on the corner with the fragile shell. Mr. Java can beg all he wants, but one thing people don't get is that Emacs is not a text editor. It has one, yes, but it's a program where the user can interactively manipulate data presented in buffers via Lisp, and keys bound to some Lisp. Thus, it is in a league of its own. The only modern player that tried to enter was Light Table for Clojure, but it did not hold on, I guess. Then there is Climacs, Hemlock and Edwin, but they don't have much or any adoption. I have not used one program til this day that is easier and more optimised for user customisation than Emacs. And if not much people will be using it in the future, be it so. But it will be around as long as computers with physical keyboards will be (and will probably adapt if they ever become obsolete).

fpoling 8y ago
Emacs is not optimized for customizations. It allows to customize everything, but the efforts required often becomes a programming project on its own. 20 years ago I spent eventually months to make the buffers switch the way I liked. Yes, i made it work precisely the way I wanted, but I suspect it would be easier to implement that feature in a native code as a patch for an editor where a configuration is just an ini file.
- TeMPOraL 8y ago
  In any other program, such customization you made would be impossible. The things you can customize in other editors and IDEs, you can customize through the M-x customize interface. The things you'd install as plugins, you can get from Emacs package manager. All other things that you can - with smaller or greater amount of work - alter in elisp, are more-less impossible in other editors.
  - fpoling 8y ago
    Think about why one needs a sofisticated customization in an editor. It implies it's defaults reflecting the workflow of the developers are significantly different from yours. To fix this you essentially must become a developer. And since the feature you want is not what the developers want, your has to maintain the feature as long as you use the editor. Now think about all the time one spends on that. If it does not feel like fun or hobby, then one better try to find some other editor that matches what one wants by default or after 5 minutes of poking in the preferences menu.

AlexCoventry 8y ago

If you're using a ceremonious language like Java, the automation in a modern editor could be useful. I think that's what Gosling was getting at.

kamaal 8y ago
Java by many definitions is a bit like assembly language of our current times. You will end up stitching highly verbose pieces of code. Which is why Java IDEs have specific features to emit get/set functions etc. Plus you will have to access a method hiding 5 class layers below. You will need IDEs designed to do this sort of work really well. Emacs and Vi have been designed to largely play with Text, plus I think with Java's verbosity you are just better off with a specialized IDE.
- varjag 8y ago
  Wouldn't call assembly programming "highly verbose". If anything it's opposite - very little boilerplate, if at all.
  - kqr 8y ago
    Do we have different ideas of what boilerplate is? Almost everything in assembly is boilerplate because there are no advanced, built in features. (Sure, modern x86 assembly is a complex language with many advanced builtins but they are generally meant to express solutions in the x86 domain, not the business domain.)
    - varjag 8y ago
      I stick to traditional definition. > In computer programming, boilerplate code or boilerplate refers to sections of code that have to be included in many places with little or no alteration. https://en.wikipedia.org/wiki/Boilerplate_code https://en.wikipedia.org/wiki/Boilerplate_code

zeveb 8y ago

> Emacs is in a race, not against Vim, but against VS Code and Atom for which editor can be more easily customized. In the long run, it doesn't look good for Emacs. Emacs is extensible in Lisp; VS Code & Atom are extensible in JavaScript. The point goes to emacs. Emacs has Magit, Org Mode, AucTeX, notmuch, gnus, ERC, emms, TRAMP, calc, calendar, Diary Mode — what do VS Code & Atom have? The point goes to emacs. Emacs runs in a GUI. Emacs runs in a terminal. Emacs runs on a machine halfway across the world on the other side of an SSH session. The point goes to emacs. Emacs is far from perfect, but it's far ahead of its competition.

oblio 8y ago
VS Code can be extended in Typescript: https://code.visualstudio.com/docs/extensions/overview#_writing-an-extension https://code.visualstudio.com/docs/extensions/overview#_writ... Philosophically Lisp may be superior, but I'm not sure it's so clear cut in real life. Regarding most of the features you present, a good chunk of them aren't editing features and another chunk are related to running in a limited environment (the terminal). So a big part of them aren't as strong selling points as you seem to think they are, since many people don't care about them.
- kqr 8y ago
  One of the frequently overlooked benefits of Lisp is that the culture around Lisp actively promotes software that is /supposed/ to be extended by its user and sort of grow into the user, rather than the user growing into it. There is also a huge difference between "building an extension" and "extending the actual code that is the running process." In Emacs, one can redefine one of its core functions at the push of a button, and suddenly all new calls will call your version of the function. If your redefined function has a breakpoint in it, you'll be able to debug-step into the core of the editor as it is running. Not sure how well TypeScript in VS Code works in that regard.
  - oblio 8y ago
    I've found that I prefer a very nice, coherent design by someone who spent a lot of time thinking about the problem in a holistic manner, than tinkering with stuff. And I do/did tinker a lot. IMO that's the best design: a solid, coherent design with clear extension points. Of course, I'm the Anti-Emacs by saying this :)

anamoulous 8y ago

vscode can only be customized by an extension. There's a bunch of one off plugins you have to install to get little bits of functionality that you can get by pasting 15 lines of elisp from the emacs wiki. If no one has built that extension yet, you have to learn to build one yourself. You could always create private "personal" extension and keep it local, but that workflow is tedious. I'm not saying vscode is less extensible or customizable though, I'm saying there's a barrier to ad-hoc personalization that's will keep it from ever being more easily customized (unless you and I have different definitions of what is "easily customized"). Script Commands[1] is an interesting plugin that attempts to address this shortcoming, but I'd like to see something official at some point. [1] https://marketplace.visualstudio.com/items?itemName=mkloubert.vs-script-commands https://marketplace.visualstudio.com/items?itemName=mklouber...

oblio 8y ago
The upside for anything like this is that the barrier to entry being higher, the people who do this tend to create higher quality things overall and maybe even share them. It's not my idea, it's the premise from http://winestockwebdesign.com/Essays/Lisp_Curse.html http://winestockwebdesign.com/Essays/Lisp_Curse.html
- anamoulous 8y ago
  Have you looked at the VS Code marketplace? It is not great. The LSP modes are great and then here and there you get interesting extensions, but a bunch of it I would not call higher quality by any means. (I use vscode all day for my work projects and generally enjoy it and am not trying to drag it, just trying to be honest about this aspect of it.)
  - oblio 8y ago
    I have, and I'd fault the immaturity of the ecosystem more than anything. VS Code was launched just 3 years ago. I don't even know if it had extensions from the beginning. The extensions I've generally used were quite solid, haven't had many problems with them.

kamaal 8y ago

>>For years, James Gosling, author of the first version of Emacs that ran on Unix (the ancestor of GNU Emacs) Then I discovered that Gosling's Emacs did not have a real Lisp. It had a programming language that was known as ‘mocklisp’, which looks syntactically like Lisp, but didn't have the data structures of Lisp. So programs were not data, and vital elements of Lisp were missing. Its data structures were strings, numbers and a few other specialized things. From : https://www.gnu.org/gnu/rms-lisp.en.html https://www.gnu.org/gnu/rms-lisp.en.html

kazinator 8y ago
Then he continued to mock lisp with an AST preprocessor for C called Ace [1989], and through Java.

armitron 8y ago

This is not at all fair or accurate in terms of general architecture. The quote from Daniel Colascione describes some implementation details that can and will be improved. The same Daniel Colascione is very passionate about Emacs and spends a lot of his free time working on it. Moreover, you did not mention any of the things that make Emacs great. Its mode-based buffer-centric architecture comes from the Lisp Machines, maps well to countless disparate tasks and has certainly stood the test of time. Emacs is essentially the closest thing we have to a Lisp Machine. Atom and VS Code on the other hand are ad-hoc editors on top of environments that can only be said to re-implement old, dead-end ideas and do so badly. I'm not sure why you mentioned Gosling, if not to mislead, since he's never as far as I know been a Lisper (Mocklisp is a mockery of Lisp) and his contributions to GNU Emacs -- besides inspiring Stallman to come up with something better -- were minimal and very quickly rewritten or removed. Gosling's influence to the architecture (Lisp Machines, Symbolics) and evolution of GNU Emacs has been NIL.

krylon 8y ago

Regarding Emacs vs. VS Code, it is kind of funny that Emacs was once the canonical big, fat, bloated editor, but it did not grow much bigger since then. So today, Emacs is kind of lightweight: On my work computer, VS Code will easily gobble up half a gigabyte of RAM with only a handful of files open, while Emacs with dozens of buffers consistently stays below 100 MB. Compared to nvi or mg, GNU Emacs is still pretty big, but I think the size-to-feature-richness ratio is more balanced in Emacs. Also, I will come out and admit that I like Emacs for being Emacs. I have tried VS Code at work, and it is not bad. But from a certain point of view, VS Code is just Emacs Re-Imagined using Javascript instead of Lisp. And Emacs just has a ~30-year head start on VS Code at being Emacs. Last, but not least, the Emacs default key bindings for moving the cursor around are by now so deeply ingrained in my muscle memory that I will not willingly switch to an editor that does not support them. And all the Emacs-keybindings extensions for VS Code I have tried were ... not quite there, yet, at least for me.

varjag 8y ago
A few years ago I was astonished to see Gnome's gedit having bigger memory footprint than very tricked out Emacs.
macavity23 8y ago
Vi folks used to make fun of Emacs as ‘Eight Megabytes And Constantly Swapping’!

deleted 8y ago

[deleted]

kazinator 8y ago

So those GNU Emacs screenshots with embedded graphics are fakes? Like: https://www.gnu.org/software/emms/screenshots.html https://www.gnu.org/software/emms/screenshots.html

kqr 8y ago
Not fake. My report authoring process includes a live updating PDF preview in an Emacs sidebar. However, this graphics stuff is still bolted onto a core engine that treats everything as a text terminal.
- kazinator 8y ago
  Won't it fly away if you don't bolt it to something?

mindB 8y ago

You have a source on Gosling trying to get people not to use Emacs (not calling you out; just genuinely curious)?

rudolfwinestock 8y ago
From ten years ago: https://www.computerworld.com.au/article/207799/don_t_use_emacs_says_java_father/ https://www.computerworld.com.au/article/207799/don_t_use_em...

kaushalmodi 8y ago

> Emacs is in a race, not against Vim, but against VS Code and Atom for which editor can be more easily customized. In the long run, it doesn't look good for Emacs. I use Emacs as my daily driver. Your comment feels very much like from someone who hasn't realized the true powers of Emacs-Lisp. Even if someone doesn't hack in Elisp, once they discover power packages like Org mode or Magit, they will know right away that there's no competition for those out there (vim, Atom, VS Code, etc). > For years, James Gosling, author of the first version of Emacs that ran on Unix (the ancestor of GNU Emacs), has been begging people to stop using Emacs. Even if that's the case, what's the point he's trying to make? Why? How does that matter to folks who are using Emacs today, and know it first hand that it's the best hackable text buffer engine out there?

mark_l_watson 8y ago

I am tied to using Emacs because so much of my work is done in SSH sessions on remote servers. I own licenses for all JetBrains IDEs, and find real value in them, but I can’t imagine not using Emacs + configurations for favorite languages + orgmode frequently and every day.