8 ms·

Apparently, I'm feeling ranty today... <rant>I've used Vi and Emacs as my primary editor. Now I've moved on to Sublime Text 3. Despite being powerful tools Vi

by flogic 11y ago

Apparently, I'm feeling ranty today... <rant>I've used Vi and Emacs as my primary editor. Now I've moved on to Sublime Text 3. Despite being powerful tools Vi and Emacs have probably harmed the state of Unix text editing. They've kept antiquated UIs from before keyboards were an text editing UIs were standardized. It's kinda sad that MS Dos, Windows and MacOS have all had a plethora of powerful editors with convenient standard user interface meanwhile the Unix world is anchored to Vi and Emacs. It seems like they've managed to starve out a good chunk of innovation on this front.

FenugreekAcerb 11y ago
Yeah or you should install Atom and be spied by Google Analytics [1]. Let's take the creepiness of the web to the desktop. [1]: https://atom.io/faq https://atom.io/faq
- WizardOfTheWest 11y ago
  Thankfully, for Arch and Arch derivatives, the AUR package removes this before building. https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=atom-editor https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=atom-...
- merpnderp 11y ago
  I've found VS Code a great alternative to Atom for that level of editor (fast and light). Don't tell me it does something equally as awful?
  - dopu 11y ago
    You should know better; it's made by Microsoft. However, like with Atom, you can disable telemetry: https://code.visualstudio.com/Docs/supporting/FAQ#_how-to-disable-crash-reporting https://code.visualstudio.com/Docs/supporting/FAQ#_how-to-di...
kstrauser 11y ago
I went from Emacs to Sublime and back to Emacs. The UI could be improved, maybe, but there's a lot to be said for knowing that your editor will still exist next year. I'm frankly not confident in ST3, but I'm 100% certain that Emacs will be there. But beyond that, I find that a lot more stuff Just Works in Emacs. I spend my days working in Python, and both major Python modes for Emacs are miles ahead of ST's equivalents. Things like linters work as expected and there are lot more packages available for niche things. Emacs is subjectively better, even if the UI doesn't feel as platform-native as other editors. I don't use Emacs because I'm a graybeard afraid to learn something new. I use it because I've tried every new hotness to come along and I've yet to find something as powerful, well-supported, and ubiquitous.
- oblio 11y ago
  The thing is, in this day and age most people don't need their editor to last 100 years. Because of https://en.wikipedia.org/wiki/IBM_Common_User_Access https://en.wikipedia.org/wiki/IBM_Common_User_Access & friends, you can just switch to another editor. Meanwhile, if you're used to Vi's modal editing or Emacs's elisp, you're basically going to hate the other tools forever if for whatever reason. For example if you need IDE features for your project or the Vim/Emacs extensions for language X are no stable/flexible enough.
  - merpnderp 11y ago
    Nearly every IDE of importance has either a full VIM plugin or is working hard on it. Not having to take your hands off the keyboard line to hit the arrows or mouse is a big deal to a lot of devs. Having easy and powerful regex is nearly as important. And having buffers is probably a close number three.
    - jjnoakes 11y ago
      How do you reach the escape key?
      - rodelrod 11y ago
tptacek 11y ago
There's a lot of antiquated stuff in Emacs, but despite the almost total lack of a modern UI toolkit for extensions, there are also interfaces in Emacs that are better than anything available elsewhere --- reasons to launch Emacs even if you don't need its expressive power for editing. Magit is a good example, Helm is another, org-mode another, FlyCheck another. If Emacs looked as good as Sublime, I'd be marginally happier. But if Emacs lost Helm or Magit, I'd be devastated.
- benaiah 11y ago
  Helm may be the most flagrant example of a terrible package that remains inexplicably popular. I haven't uninstalled it yet, because there are a few packages that use helm that don't have ido equivalents yet, but I try to minimize my usage of it as much as possible. Issues include: - Significant performance issues - Constant bugs - updates often break the package completely, especially if you're using the melpa version (melpa is another rant for another time - standard melpa is totally brain-dead) - An atrocious version of "fuzzy matching" (you have to separate terms with spaces, which are then turned into ".asterisk" (can't type a single asterisk in HN comments) and everything's concatenated into a regex to match) - The default helm-mode (what they recommend using for completing-read, which controls execute-extended-command, i.e. M-x, and such) is unsorted. Not badly sorted - unsorted. - Doesn't use a lot of the standard layout functions, instead replacing them with its own stuff that can't be customized in a standard way. - Dictatorial maintainers that only allows options and features that they deem the "right way" to do it. This is fine for some projects, but total control of my editing experience is the primary reason I use Emacs in the first place. ido with a few simple plugins is vastly better, less buggy, more compatible, faster, has better matching, and is easier to customize. I recommend against using helm for completing-read unequivocally.
  - clocksld 11y ago
    I can't say that I have experienced all of these issues myself after using helm for about a year. - There certainly are performance issues with helm, but setting gc-cons-threshold to a higher value helps my setup a lot. - I update all my installed packages pretty frequently, and I just use regular melpa. I haven't really noticed bugs with Helm. - As for the fuzzy matching, look into the "helm-flx" package. It gives you real fuzzy matching, much better than the default helm matching. - I have M-x bound to helm-M-x, which is a better option than the default. Also, helm-mini is a better option for a buffer switcher. I agree that Helm is lacking in many areas, but this guide made Helm work better for me: https://tuhdo.github.io/helm-intro.html https://tuhdo.github.io/helm-intro.html
bch 11y ago
Not trying to be confrontational, but conversational -- I'd say that both vi and Emacs have solid fundamentals and have stuck with a model that works, to their credit. I must admit that I shop around for editors occasionally (I'm a long-time emacs person, who swapped back to vi a few years ago to re-develop his vi-fu), but I haven't seen anything so compelling that I've switched to anything else. It may well be that I'm looking in the wrong place, or that I don't realize the true awesomeness of something that does cross my desk. In the spirit of advancing text editing, what would you say is missing from vi or Emacs that you've found in other editors (even if the advancements aren't present in one singular other processor)? Edit: stray words
- flogic 11y ago
  My primary issue with Vi and Emacs isn't really about lack. They are quite powerful tools. The primary problem is that they impose a certain amount of mental overhead. Emacs was a bit worse in that regard since many of its key bindings are actually sequences. Sublime Text is rather powerful but in terms of features it's probably the one that is lacking of the 3. The win was in unloading the overhead from my normal work patterns.
  - __david__ 11y ago
    I think that mental overhead is the steep learning curve that everyone talks about. I remember when I first started learning Emacs it was hard. I just had to think in this new way (I was used to cua style keystrokes), but after a month or so my muscle memory developed and I started not having to directly think about what I was doing. Once you get to that point, the overhead is gone and things become very nice. But I'll grant you it's a hard sell to say "this is great, but you're going to be unproductive for a month". Nonetheless, I think the payout is very much worth it, and if you are interested, make sure you are prepared, and stick with it for a good long time before giving up.
- ezy 11y ago
  This is going to sound a little misguided, but bear with me. If you want to see what you're missing: Take a look at the IDEs of the moment. Try something like eclipse on java code or maybe devstudio in the windows world. In general, vi/emacs are missing support for editing above the level of text (eg. refactoring) and support for UI above the level of a text terminal. I know add-ons exist for both editors that do some of these things, and of course, you can run both in a graphical terminal with custom fonts, etc -- but if one is being honest, it's not very well integrated in either of the old standbys. I'm a vim user, but not really an advocate. I'm just used to it, I like the way it works (mostly) out of the box[1], and I think it's text editing facilities match the way I edit better. It's a great generic text editor -- as is emacs (for some others, not me). But all they do is understand text... I had to do some Java development recently. So I tried eclipse (with a vim keymap plugin). Now, eclipse kind of sucks in many ways, but one thing it definitely has is the ability to refactor code. Something like variable rename over multiple files that would have me concocting a sed-ish script for vi, or doing query-search-replace, next,next,next,skip,next in emacs was literally two keystrokes and bang, done. Forget about actually moving language constructs from one file to another or to another package, etc. And the UI for it was very clear: inplace modification, and popping up a warning about where the refactoring would break, if it would. And then we have modern UI. Eclipse isn't even very pretty (or modern) by modern standards, but it still highlights properties of code (warnings, unused variables, etc) by actually drawing symbols or boxes on the screen rather than attempting to wrangle indications into the world of VT220 terminals. Among other things... One could put this all making up for deficiencies in Java, I suppose. Except, again, if one is honest, one realizes that this kind of thing is highly useful no matter what language you're developing in... Neither Vim or Emacs has very good support for any of this at all. There are examples of add-ons that do it kinda-sorta, but they aren't very good. Emacs is better than vim at this, of course[2], but it's still not very common for language support to get to this level. It's not a standard thing, and it should be. Such is history, and the pragmatics are writing a substantial piece of software inside another piece of software in a crappy language :-). Emacs still crappier (and slower) than eclipse at just highlighting syntax (and barely does the highlighting of semantics). Emacs & vim have real issues as code editors because they are stuck in the past -- and not the recent past either. Vi was never meant to be anything but a text editor, for good or ill. And Emacs... well emacs lives in it's own little world reminiscent of a half-baked lisp machine crossed with a VT220 terminal. And while the capability is there somewhat to do the above, there is a lot of historical baggage and historical code to overcome. So, is eclipse my editor of choice now? :-) :-P Well, no (except for java code). :-) It's a shitty editor, it's slow to start, it crashes or gets into a funky state too often, and it's really a Java-editor, not a generic text/code/anything editor (although it tries to be, and fails). But I think eclipse and tools like it show clearly "what is missing" in an old-school editor like vim/emacs, or indeed any new editor which uses either of these as a model. [1] I also think key-chording, which emacs uses (and others influenced by emacs use) is actively physically harmful. [2] A better scripting language helps. I'm sure emacs is somewhat passable at refactoring lisp code. :-)
alayne 11y ago
Sublime Text is proprietary closed source. That seems counter to modern Unix/Linux goals.
- pjmlp 11y ago
  Which UNIX isn't proprietary? Note UNIX, not UNIX like.
  - groovy2shoes 11y ago
    All of the BSDs.
    - pjmlp 11y ago
      Which of them is certified as such?
      - groovy2shoes 11y ago
        Oh, didn't realize you meant only certified Unices. I'll be on my way...
      - curt15 11y ago
        Who really cares about whether something is "certified" UNIX? Certification is not some seal of quality. "Unix" is commonly understood to denote "functional" unix systems as well for lack of a more convenient term.
        pjmlp 11y ago
        That os what the UNIX-like expression is for.
      - mitchty 11y ago
        OS X would have been the only one certified. Even then I wouldn't call it a BSD per-se.
  - 11y ago
jamespo 11y ago
A lot of the reason I used emacs is that it works in a terminal... nothing else with its power does.
- MarcScott 11y ago
  While on the other hand, I use it because I can open a shell from within Emacs. I can also use tramp to ssh onto another machine from within emacs, and so don't have to bother installing my favourite editor on headless servers and Raspberry Pis.
  - sooheon 11y ago
    Is there a true terminal inside emacs that I don't know about, because all the ones I've tried were buggy chimeras of odd behaviours.
    - Bogdanp 11y ago
      `ansi-term` works well in most cases. The only time it really breaks down for me is when I run commands that combine really long lines and complex escape sequences (like npm's new progress bar which you can thankfully disable).
    - rekado 11y ago
      I'm quite content with shell-mode for most of the things I do (took me a while to get used to some of its quirks, but now I like them). For curses applications (like alsamixer) I use ansi-term.
jayvanguard 11y ago
I quite like Sublime Text 3 as well, but only because it has a vi mode.
nextos 11y ago
I think they come with quite a lot of baggage, yes. But if you get past the initial steep learning curve, there's a lot of productivity gains waiting for you. With regards to simpler editors, the problem is that they come and go. Learning an editor is a big investment, so I'd rather stick to something that will still be around next decade.
MarcScott 11y ago
Given that all these editors are cross-platform, I don't see how the continued development of Emacs could be starving out innovation in the Unix world.
- pjmlp 11y ago
  Many on UNIX seem to keep living as if their quad-core with 16GB is actually a better PDP-11, hence starving innovation.
  - TeMPOraL 11y ago
    Well, if those quad-cores and 16GB of RAM would actually be put to good use in the "modern"/"hot" IDE world, we could talk. If anything is starving out innovation, it's sticking to CUA, mouse-driven development and rewriting nano in JavaScript...
    - pjmlp 11y ago
      When those IDEs are able to achieve what was possible in Xerox PARC workstations, as demoed occasionally by Bret Victor, then we can talk about moving forward. PDP-11 command line experience is not even there.
      - __david__ 11y ago
        > PDP-11 command line experience is not even there. Are you saying the modern unix command line is not as good/better than the "PDP-11 command line experience"? Also, which PDP-11 command line? RSTS? RT11? Unix? or maybe that awesome front panel where you had to manually input your boot loader in binary every time you started the machine?
        pjmlp 11y ago
        > Are you saying the modern unix command line is not as good/better than the "PDP-11 command line experience"? No, I am saying that it isn't even close to the Xerox PARC REPL experience from Interlisp-D, Mesa/Cedar and Smalltalk environments. > Also, which PDP-11 command line? RSTS? RT11? Unix? or maybe that awesome front panel where you had to manually input your boot loader in binary every time you started the machine? The VT-100 interface some people seem to keep living on.
lottin 11y ago
What is true is that Vi and Emacs are deeply tied to the Unix tradition. Whether they are 'antiquated' or whether there are 'better' alternatives is a matter of opinion. Personally I haven't seen any other editor that comes close.
- lispm 11y ago
  Maybe GNU Emacs, because it was originally written for Unix. Emacs itself came from ITS/Teco. Lisp-based Emacs came from the MIT Lisp Machine (using Lisp Machine Lisp as implementation language) and Multics Emacs (using Maclisp as implementation language).
merpnderp 11y ago
I won't use an IDE on OSX or windows that doesn't support VIM or Emacs key bindings because I'm not an animal that wants to take his fingers off the line to use the mouse or arrow keys every time needs to move the cursor (or run a regex real fast to mass update code). Luckily there are VIM bindings for nearly every single IDE of importance out there.
- alkonaut 11y ago
  > I won't use an IDE > a regex real fast to mass update code For things like renaming, an IDE would have a function for that, which isn't text based but symbolic. At the very least, bringing up a replace diaglog with regex functionality doesn't require any more keys to be pressed in an IDE than in emacs. Most IDEs's also support key bindings that are pretty close to Emacs or vim. unless you use a dynamic language in which case you are shit out of luck.
  - TeMPOraL 11y ago
    Symbolic renames are one thing, but sometimes you really want to do textual renames. When you have names like fooFrobnicator, barFrobnicatorFactory and quuxFrobnicatorController, and you want to rename Frobnicator to Twiddler, symbolic rename won't help you. Also, you can create quite a lot of code indirectly by few well-placed keystrokes that utilize multiple cursors / keyboard macros, regexp-replaces and things like this. Think of it as chiseling out an entire block of code at once. Spend little time mastering those features, and you can do things like this on the fly, without much conscious focus.
  - eeperson 11y ago
    You can do the same thing in Emacs too. For example, this[1] supports that for Scala (and I think Java now as well). [1] http://ensime.github.io/ http://ensime.github.io/
sklogic 11y ago
I'd be interested to hear more about "powerful" text editors from the DOS or Windows world. Likely your definition of "powerful" is quite peculiar.
sandisk5 11y ago
> It seems like they've managed to starve out a good chunk of innovation on this front. If you look the way magit dialogs are handled, they're quite innovative and could be useful in many other contexts (like shell commands). Magit itself has many other innovative UI approaches. EMMS/gnus/notmuch/twittering-mode have innovative UIs of their own. Also look at spacemacs and the things its doing with guide-key for more UI innovation. Being able to search (C-s) or filter (occur) almost any text on the screen (including UI like button names) is very nice, and something I miss when in Atom (like the Settings tab where one can only search things the creator decided to add a search field for). There is a ton of innovation in vim and emacs these days, mostly in new packages. I'm glad we have them (and Atom and others) exploring different approaches. There are plenty of gedit-like editors with standard user interfaces.
shiro 11y ago
On standard UI: The kind of unity of UI I want is a bit more than common cut/copy/paste/save/open shortcuts---for example, using the same incremental search or mark-and-kill-ring-save keystrokes on items in the long pull-down menu or labels in property-editing dialogs...
melted 11y ago
You simply don't grok vim. Don't know about Emacs, I'm not a Emacs user, but chances are pretty good you don't grok it either. To begin to grok vim, please refer to the following StackOverflow answer: http://stackoverflow.com/questions/1218390/what-is-your-most-productive-shortcut-with-vim/1220118#1220118 http://stackoverflow.com/questions/1218390/what-is-your-most...

by flogic 11y ago

FenugreekAcerb 11y ago

Yeah or you should install Atom and be spied by Google Analytics [1]. Let's take the creepiness of the web to the desktop. [1]: https://atom.io/faq https://atom.io/faq

WizardOfTheWest 11y ago
Thankfully, for Arch and Arch derivatives, the AUR package removes this before building. https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=atom-editor https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=atom-...
merpnderp 11y ago
I've found VS Code a great alternative to Atom for that level of editor (fast and light). Don't tell me it does something equally as awful?
- dopu 11y ago
  You should know better; it's made by Microsoft. However, like with Atom, you can disable telemetry: https://code.visualstudio.com/Docs/supporting/FAQ#_how-to-disable-crash-reporting https://code.visualstudio.com/Docs/supporting/FAQ#_how-to-di...

kstrauser 11y ago

I went from Emacs to Sublime and back to Emacs. The UI could be improved, maybe, but there's a lot to be said for knowing that your editor will still exist next year. I'm frankly not confident in ST3, but I'm 100% certain that Emacs will be there. But beyond that, I find that a lot more stuff Just Works in Emacs. I spend my days working in Python, and both major Python modes for Emacs are miles ahead of ST's equivalents. Things like linters work as expected and there are lot more packages available for niche things. Emacs is subjectively better, even if the UI doesn't feel as platform-native as other editors. I don't use Emacs because I'm a graybeard afraid to learn something new. I use it because I've tried every new hotness to come along and I've yet to find something as powerful, well-supported, and ubiquitous.

oblio 11y ago
The thing is, in this day and age most people don't need their editor to last 100 years. Because of https://en.wikipedia.org/wiki/IBM_Common_User_Access https://en.wikipedia.org/wiki/IBM_Common_User_Access & friends, you can just switch to another editor. Meanwhile, if you're used to Vi's modal editing or Emacs's elisp, you're basically going to hate the other tools forever if for whatever reason. For example if you need IDE features for your project or the Vim/Emacs extensions for language X are no stable/flexible enough.
- merpnderp 11y ago
  Nearly every IDE of importance has either a full VIM plugin or is working hard on it. Not having to take your hands off the keyboard line to hit the arrows or mouse is a big deal to a lot of devs. Having easy and powerful regex is nearly as important. And having buffers is probably a close number three.
  - jjnoakes 11y ago
    How do you reach the escape key?
    - rodelrod 11y ago

tptacek 11y ago

There's a lot of antiquated stuff in Emacs, but despite the almost total lack of a modern UI toolkit for extensions, there are also interfaces in Emacs that are better than anything available elsewhere --- reasons to launch Emacs even if you don't need its expressive power for editing. Magit is a good example, Helm is another, org-mode another, FlyCheck another. If Emacs looked as good as Sublime, I'd be marginally happier. But if Emacs lost Helm or Magit, I'd be devastated.

benaiah 11y ago
Helm may be the most flagrant example of a terrible package that remains inexplicably popular. I haven't uninstalled it yet, because there are a few packages that use helm that don't have ido equivalents yet, but I try to minimize my usage of it as much as possible. Issues include: - Significant performance issues - Constant bugs - updates often break the package completely, especially if you're using the melpa version (melpa is another rant for another time - standard melpa is totally brain-dead) - An atrocious version of "fuzzy matching" (you have to separate terms with spaces, which are then turned into ".asterisk" (can't type a single asterisk in HN comments) and everything's concatenated into a regex to match) - The default helm-mode (what they recommend using for completing-read, which controls execute-extended-command, i.e. M-x, and such) is unsorted. Not badly sorted - unsorted. - Doesn't use a lot of the standard layout functions, instead replacing them with its own stuff that can't be customized in a standard way. - Dictatorial maintainers that only allows options and features that they deem the "right way" to do it. This is fine for some projects, but total control of my editing experience is the primary reason I use Emacs in the first place. ido with a few simple plugins is vastly better, less buggy, more compatible, faster, has better matching, and is easier to customize. I recommend against using helm for completing-read unequivocally.
- clocksld 11y ago
  I can't say that I have experienced all of these issues myself after using helm for about a year. - There certainly are performance issues with helm, but setting gc-cons-threshold to a higher value helps my setup a lot. - I update all my installed packages pretty frequently, and I just use regular melpa. I haven't really noticed bugs with Helm. - As for the fuzzy matching, look into the "helm-flx" package. It gives you real fuzzy matching, much better than the default helm matching. - I have M-x bound to helm-M-x, which is a better option than the default. Also, helm-mini is a better option for a buffer switcher. I agree that Helm is lacking in many areas, but this guide made Helm work better for me: https://tuhdo.github.io/helm-intro.html https://tuhdo.github.io/helm-intro.html

bch 11y ago

Not trying to be confrontational, but conversational -- I'd say that both vi and Emacs have solid fundamentals and have stuck with a model that works, to their credit. I must admit that I shop around for editors occasionally (I'm a long-time emacs person, who swapped back to vi a few years ago to re-develop his vi-fu), but I haven't seen anything so compelling that I've switched to anything else. It may well be that I'm looking in the wrong place, or that I don't realize the true awesomeness of something that does cross my desk. In the spirit of advancing text editing, what would you say is missing from vi or Emacs that you've found in other editors (even if the advancements aren't present in one singular other processor)? Edit: stray words

flogic 11y ago
My primary issue with Vi and Emacs isn't really about lack. They are quite powerful tools. The primary problem is that they impose a certain amount of mental overhead. Emacs was a bit worse in that regard since many of its key bindings are actually sequences. Sublime Text is rather powerful but in terms of features it's probably the one that is lacking of the 3. The win was in unloading the overhead from my normal work patterns.
- __david__ 11y ago
  I think that mental overhead is the steep learning curve that everyone talks about. I remember when I first started learning Emacs it was hard. I just had to think in this new way (I was used to cua style keystrokes), but after a month or so my muscle memory developed and I started not having to directly think about what I was doing. Once you get to that point, the overhead is gone and things become very nice. But I'll grant you it's a hard sell to say "this is great, but you're going to be unproductive for a month". Nonetheless, I think the payout is very much worth it, and if you are interested, make sure you are prepared, and stick with it for a good long time before giving up.
ezy 11y ago
This is going to sound a little misguided, but bear with me. If you want to see what you're missing: Take a look at the IDEs of the moment. Try something like eclipse on java code or maybe devstudio in the windows world. In general, vi/emacs are missing support for editing above the level of text (eg. refactoring) and support for UI above the level of a text terminal. I know add-ons exist for both editors that do some of these things, and of course, you can run both in a graphical terminal with custom fonts, etc -- but if one is being honest, it's not very well integrated in either of the old standbys. I'm a vim user, but not really an advocate. I'm just used to it, I like the way it works (mostly) out of the box[1], and I think it's text editing facilities match the way I edit better. It's a great generic text editor -- as is emacs (for some others, not me). But all they do is understand text... I had to do some Java development recently. So I tried eclipse (with a vim keymap plugin). Now, eclipse kind of sucks in many ways, but one thing it definitely has is the ability to refactor code. Something like variable rename over multiple files that would have me concocting a sed-ish script for vi, or doing query-search-replace, next,next,next,skip,next in emacs was literally two keystrokes and bang, done. Forget about actually moving language constructs from one file to another or to another package, etc. And the UI for it was very clear: inplace modification, and popping up a warning about where the refactoring would break, if it would. And then we have modern UI. Eclipse isn't even very pretty (or modern) by modern standards, but it still highlights properties of code (warnings, unused variables, etc) by actually drawing symbols or boxes on the screen rather than attempting to wrangle indications into the world of VT220 terminals. Among other things... One could put this all making up for deficiencies in Java, I suppose. Except, again, if one is honest, one realizes that this kind of thing is highly useful no matter what language you're developing in... Neither Vim or Emacs has very good support for any of this at all. There are examples of add-ons that do it kinda-sorta, but they aren't very good. Emacs is better than vim at this, of course[2], but it's still not very common for language support to get to this level. It's not a standard thing, and it should be. Such is history, and the pragmatics are writing a substantial piece of software inside another piece of software in a crappy language :-). Emacs still crappier (and slower) than eclipse at just highlighting syntax (and barely does the highlighting of semantics). Emacs & vim have real issues as code editors because they are stuck in the past -- and not the recent past either. Vi was never meant to be anything but a text editor, for good or ill. And Emacs... well emacs lives in it's own little world reminiscent of a half-baked lisp machine crossed with a VT220 terminal. And while the capability is there somewhat to do the above, there is a lot of historical baggage and historical code to overcome. So, is eclipse my editor of choice now? :-) :-P Well, no (except for java code). :-) It's a shitty editor, it's slow to start, it crashes or gets into a funky state too often, and it's really a Java-editor, not a generic text/code/anything editor (although it tries to be, and fails). But I think eclipse and tools like it show clearly "what is missing" in an old-school editor like vim/emacs, or indeed any new editor which uses either of these as a model. [1] I also think key-chording, which emacs uses (and others influenced by emacs use) is actively physically harmful. [2] A better scripting language helps. I'm sure emacs is somewhat passable at refactoring lisp code. :-)

alayne 11y ago

Sublime Text is proprietary closed source. That seems counter to modern Unix/Linux goals.

pjmlp 11y ago
Which UNIX isn't proprietary? Note UNIX, not UNIX like.
- groovy2shoes 11y ago
  All of the BSDs.
  - pjmlp 11y ago
    Which of them is certified as such?
    - groovy2shoes 11y ago
      Oh, didn't realize you meant only certified Unices. I'll be on my way...
    - curt15 11y ago
      Who really cares about whether something is "certified" UNIX? Certification is not some seal of quality. "Unix" is commonly understood to denote "functional" unix systems as well for lack of a more convenient term.
      - pjmlp 11y ago
        That os what the UNIX-like expression is for.
    - mitchty 11y ago
      OS X would have been the only one certified. Even then I wouldn't call it a BSD per-se.
- 11y ago

jamespo 11y ago

A lot of the reason I used emacs is that it works in a terminal... nothing else with its power does.

MarcScott 11y ago
While on the other hand, I use it because I can open a shell from within Emacs. I can also use tramp to ssh onto another machine from within emacs, and so don't have to bother installing my favourite editor on headless servers and Raspberry Pis.
- sooheon 11y ago
  Is there a true terminal inside emacs that I don't know about, because all the ones I've tried were buggy chimeras of odd behaviours.
  - Bogdanp 11y ago
    `ansi-term` works well in most cases. The only time it really breaks down for me is when I run commands that combine really long lines and complex escape sequences (like npm's new progress bar which you can thankfully disable).
  - rekado 11y ago
    I'm quite content with shell-mode for most of the things I do (took me a while to get used to some of its quirks, but now I like them). For curses applications (like alsamixer) I use ansi-term.

jayvanguard 11y ago

I quite like Sublime Text 3 as well, but only because it has a vi mode.

nextos 11y ago

I think they come with quite a lot of baggage, yes. But if you get past the initial steep learning curve, there's a lot of productivity gains waiting for you. With regards to simpler editors, the problem is that they come and go. Learning an editor is a big investment, so I'd rather stick to something that will still be around next decade.

MarcScott 11y ago

Given that all these editors are cross-platform, I don't see how the continued development of Emacs could be starving out innovation in the Unix world.

pjmlp 11y ago
Many on UNIX seem to keep living as if their quad-core with 16GB is actually a better PDP-11, hence starving innovation.
- TeMPOraL 11y ago
  Well, if those quad-cores and 16GB of RAM would actually be put to good use in the "modern"/"hot" IDE world, we could talk. If anything is starving out innovation, it's sticking to CUA, mouse-driven development and rewriting nano in JavaScript...
  - pjmlp 11y ago
    When those IDEs are able to achieve what was possible in Xerox PARC workstations, as demoed occasionally by Bret Victor, then we can talk about moving forward. PDP-11 command line experience is not even there.
    - __david__ 11y ago
      > PDP-11 command line experience is not even there. Are you saying the modern unix command line is not as good/better than the "PDP-11 command line experience"? Also, which PDP-11 command line? RSTS? RT11? Unix? or maybe that awesome front panel where you had to manually input your boot loader in binary every time you started the machine?
      - pjmlp 11y ago
        > Are you saying the modern unix command line is not as good/better than the "PDP-11 command line experience"? No, I am saying that it isn't even close to the Xerox PARC REPL experience from Interlisp-D, Mesa/Cedar and Smalltalk environments. > Also, which PDP-11 command line? RSTS? RT11? Unix? or maybe that awesome front panel where you had to manually input your boot loader in binary every time you started the machine? The VT-100 interface some people seem to keep living on.

lottin 11y ago

What is true is that Vi and Emacs are deeply tied to the Unix tradition. Whether they are 'antiquated' or whether there are 'better' alternatives is a matter of opinion. Personally I haven't seen any other editor that comes close.

lispm 11y ago
Maybe GNU Emacs, because it was originally written for Unix. Emacs itself came from ITS/Teco. Lisp-based Emacs came from the MIT Lisp Machine (using Lisp Machine Lisp as implementation language) and Multics Emacs (using Maclisp as implementation language).

merpnderp 11y ago

I won't use an IDE on OSX or windows that doesn't support VIM or Emacs key bindings because I'm not an animal that wants to take his fingers off the line to use the mouse or arrow keys every time needs to move the cursor (or run a regex real fast to mass update code). Luckily there are VIM bindings for nearly every single IDE of importance out there.

alkonaut 11y ago
> I won't use an IDE > a regex real fast to mass update code For things like renaming, an IDE would have a function for that, which isn't text based but symbolic. At the very least, bringing up a replace diaglog with regex functionality doesn't require any more keys to be pressed in an IDE than in emacs. Most IDEs's also support key bindings that are pretty close to Emacs or vim. unless you use a dynamic language in which case you are shit out of luck.
- TeMPOraL 11y ago
  Symbolic renames are one thing, but sometimes you really want to do textual renames. When you have names like fooFrobnicator, barFrobnicatorFactory and quuxFrobnicatorController, and you want to rename Frobnicator to Twiddler, symbolic rename won't help you. Also, you can create quite a lot of code indirectly by few well-placed keystrokes that utilize multiple cursors / keyboard macros, regexp-replaces and things like this. Think of it as chiseling out an entire block of code at once. Spend little time mastering those features, and you can do things like this on the fly, without much conscious focus.
- eeperson 11y ago
  You can do the same thing in Emacs too. For example, this[1] supports that for Scala (and I think Java now as well). [1] http://ensime.github.io/ http://ensime.github.io/

sklogic 11y ago

I'd be interested to hear more about "powerful" text editors from the DOS or Windows world. Likely your definition of "powerful" is quite peculiar.

sandisk5 11y ago

> It seems like they've managed to starve out a good chunk of innovation on this front. If you look the way magit dialogs are handled, they're quite innovative and could be useful in many other contexts (like shell commands). Magit itself has many other innovative UI approaches. EMMS/gnus/notmuch/twittering-mode have innovative UIs of their own. Also look at spacemacs and the things its doing with guide-key for more UI innovation. Being able to search (C-s) or filter (occur) almost any text on the screen (including UI like button names) is very nice, and something I miss when in Atom (like the Settings tab where one can only search things the creator decided to add a search field for). There is a ton of innovation in vim and emacs these days, mostly in new packages. I'm glad we have them (and Atom and others) exploring different approaches. There are plenty of gedit-like editors with standard user interfaces.

shiro 11y ago

On standard UI: The kind of unity of UI I want is a bit more than common cut/copy/paste/save/open shortcuts---for example, using the same incremental search or mark-and-kill-ring-save keystrokes on items in the long pull-down menu or labels in property-editing dialogs...

melted 11y ago

You simply don't grok vim. Don't know about Emacs, I'm not a Emacs user, but chances are pretty good you don't grok it either. To begin to grok vim, please refer to the following StackOverflow answer: http://stackoverflow.com/questions/1218390/what-is-your-most-productive-shortcut-with-vim/1220118#1220118 http://stackoverflow.com/questions/1218390/what-is-your-most...