I don't think I can ever get used to a non-vi editor (I feel uncomfortable even browsing without vim-style shortcuts thanks to pentadactyl/vimfx), but there is one for Emacs so that is not a show-stopper.
I did in fact try Spacemacs for a while, and wanted to like it, but in the end I couldn't get rid of my muscle memory to just start new editors in terminals all the time, and Emacs' daemon mode had stability issues for me, so it wasn't very usable: either it'd crash at times or startup would be unusably slow.
Muscle memory is a powerful thing. I had to alias "vi" to "nvim" just to be able to use neovim...
A fully Lisp ecosystem is one of emacs' greatest attractions, and one that neither vim nor neovim is likely to ever achieve.
The vim ecosystem is overwhelmingly vimscript. Python is gaining popularity, and if anything a mainstream language like that is likely what the neovim ecosystem will eventually wind up consisting of. Not Lisp.
Contrast that with emacs, where it's Lisp, Lisp, Lisp, and will continue to be Lisp for the foreseeable future (with a detour to Scheme possible in the long run).
Unfortunately many current 'vi' users have never actually
seen the real thing, since most linuces simply alias vi to vim.. I realias it back to nvi because every new vim distro package has a new layer of auto indenting shiny garbage I have to unfiddle before approaching actual vi..
If I want fast text hacking, I use vi. If I want fancy stuff in the sweet spot between basic editor and ide,
I use emacs, and if I want vi key bindings in that sweet
spot, I turn on viper/evil. Done.
* Syntax highlighting
* Visual selection
* Multiple buffers
If I have a task for an editor that doesn't do those things and runs really fast, I usually reach for sed.
How is kakoune in practice? I've been eyeing it as well but was waiting for it to mature a bit.
In a sense... I kept seeing vim plugins promoted as a way
to make my life more awesome, but every time I tried one
it was incredibly slow and I bounced back to vanilla vim.
Not only that, but I kept getting burned every time I would
try what seemed like simple customizations, like adding a
few extra pieces of information to the status bar. After
the Nth time I went to open a 50M file and had vim lock
up on me, I reverted my .vimrc.
> Plain vim doesn't seem much more bloated than in the past.
It's not, and to be fair to vim you can build a pretty lean
version of it if you want to. But the fact that all of the
creaky vimscript machinery is there behind the scenes was
starting to bother me.
That alone wouldn't have been enough to bounce me to kak,
but when I tried it, it immediately overwrote 20 years of
vim muscle memory and I had a lot of trouble switching
back. I had been using visual mode a lot in vim, and I
always felt a little bad about it -- like if I'd been better
at ex I wouldn't have had to use visual mode as much. Kak's
editing paradigm is all about selections anyway, so I'm a
lot more comfortable using it than I ever was with vim.
> How is kakoune in practice? I've been eyeing it as well but was waiting for it to mature a bit.
It's mature enough for me -- I've been building it from
master every couple of days, and crashes are very unusual.
The tmux integration is amazing. I always hated having
vim splits inside of tmux panes inside of i3 windows, and
now I don't.
However, the functionality quickly falls off. I do tend to keep around intellij, but mostly for the various debugger integrations, but you can quickly replace any integrations with project-wide search and replace + a decent auto suggest + compile/linting integration. That's not terribly hard to find these days in emacs, vi, vscode, sublime, etc etc, and it's only going to get easier when we start seeing language servers pop up so you can refactor from any editor!
Plus the vim-emacs debate is fun to keep alive, it's a like a surrogate discussion. Other people might talk about sports or the weather.
Basically: I don't really care about the out-of-the-box environment. I care about an environment that's tailored to my use-cases and programming style. This will cause me to frequently gravitate toward Emacs or something very similar.
I also happen to like Lisp, so there's that. TRAMP also helps considerably for editing remote files, and very few non-Emacs IDEs/editors offer any real equivalent.
I mean Visual Studio and Eclipse and (I imagine) Xcode offer substantial features and optimizations for the languages and ecosystems they primarily support. The cost of those optimizations and features appears when a person moves outside of the languages and ecosystems a particular IDE supports. Any language outside of those for which an IDE was designed is an edge-case (google up "Xcode Perl" for example).
Sure, it's possible to use an IDE outside of it's design sweetspot but it's swimming upstream in the Turing Tarpit. And the likely longterm outcome is that a programmer will wind up using a different tool and one of the options for most languages will be a text editor.
So the model I would use for why people choose a text editor is analogous to gradient descent where text editors are a local minima.
This isn't a bad thing, I just prefer to stick with what I know how to use efficiently to do the tasks I've done before.
One thing to keep in mind: I don't just use a different set of tools, I have a different workflow. Vim rarely takes up a full screen. (well, half now we've all agreed on widescreen monitors...)
As a quick breakdown of working on a project:
- I usually have a 'command' terminal, where I run build commands, execute / debug the app, manage project files, etc... (usually in the root dir of the project I'm working on, so paths are relative and easy to work with everywhere)
- I have a 'main editor' terminal, using Vim to open multiple files for editing, splitting the window and switching buffers on the fly based on what I'm doing.
- I have a browser window with tabs open to various documentation/reference pages for the code I'm writing. This gives me my 'intellisense' equivalent, I guess.
- I might open terminals temporarily to display other code, etc... when I want additional references displayed. (but only ever edit from the main editor window)
- I use tools like cscope (or even just grep) to browse my source code, which I can even do from the editor.
- I generally write a build.sh / run.sh / clean.sh I'll add to as I go, which wrap things like CMake, Make, lint tools, etc...
The biggest perk is that I can work in 100% the same way from any system with an SSH client, with zero change to my workflow. I can reconfigure my entire development workspace on a clean system and be productive with a couple 'git clone' commands and running a shell script to 'yum/dnf install' a couple standard development tools from the default repos.
I don't mean this defensively, I'm genuinely curious... What do you think an IDE gives you that other tools don't?
The first two that come to mind are a tightly integrated build system (eg. creating a new source file automatically builds and links it with the project), and the GUI design tools that generate the relevant class files. (Those could be huge factors for some people)
Is it simply the all-in-one packaging and integration between the tools?
Thanks for taking the time to reply if you get through all that :)
I won't do that, and instead state that the wise person selects the tool appropriate for the task.
I sometimes use emacs, and avoids vi as much as possible because I happened to learn emacs first.
But prefer IDE's and typed languages because I have a unreliable memory in respect to function names and argument order and irrelevant details like that, and I don't want to spend half my life trying to set up either emacs or vi to handle code completion so that it's even halfway-decent.
But that's just me...
Even when I don't have SSH access to a machine (perhaps because sshd ain't running yet), my increasing use of OpenBSD means increasing availability of 'mg' on my servers, which further means that I don't have to leave the comfort of an Emacs-ish environment (even if I lose some of the more advanced features). It's only on my Linux machines (and on SmartOS) that I have to resort to 'vi' or 'ed' for anything, and even that's going away as more distros ship with 'nano'.
From my understanding, GNU Emacs is a specific flavor of Emacs (which is a general class of editor). From wikipedia, it's the most common flavor of Emacs. Is it not generally understood that Emacs implies GNU Emacs? Would it not be sufficient to introduce the article with, "... Emacs -- specifically, GNU Emacs -- ..." and then carry on with Emacs elsewhere?
It seems needless, or even pedantic, but maybe I'm missing something?
Basically: yes, you can be unambiguous by just saying "emacs" and everyone who cares will know exactly what software you use. But for the same reason it's not really correct anymore to use "emacs" to refer to a "general class of editor". You need to be more explicit if you're invoking historical or oddball variants.
Edit: Confused about downvotes too. My question comes from a genuine place of not understanding.
Never got into that Emacs as an OS mentality, but I can see it's appeal to someone but I didn't like it. But I am really grateful for system wide shortcuts in OS X, just C-A, C-E has saved me so much time in macOS. And yeah, Emacs made me rebind ctrl to Caps Lock, which is so good, I can't imagine how I used keyboard before this!
I like UNIX and use it for everything I can. (there is other thing on internet called UNIX as an IDE)
Edit: and oh, I forgot there are some beautiful things with Emacs like magit. I have understood git and it's concepts thanks to this emacs git interface, now I am 10 times better and I know what I am doing in terminal.
Both can do basically anything nowdays so the argument of particular workflow suiting better different people does not hold. Its just that some people dont want to invest time into learning vim because vim on-boarding is probably the hardest compared to any other editor. There are maybe some other aspects involved for some people (like lisp vs viml) but those can safelly be ignorred as non important in majority of casses.
There's also spacemacs (for a large config) and evil-mode (if you want to get into the nitty gritty details) for using vim bindings in emacs. Doing the opposite would be a much harder feat.
I love both editors... and there's a reason I have both a vimrc and an init.el. vim has the advantage of being pretty much everywhere (so it works really well when editing on servers), and has awesome modal editing, but emacs works really well for local development where I can make sure I'm using the right version and have it tweaked to work exactly how I want.
I don't think that one is better than the other, just that they have different use cases.
Emacs provides object motion commands, too, based on b/f/p/n. It can have two modes (in the vi sense), if you wish, using evil-mode.
It's also far, far better than vi at editing and navigating the text of a news post, or a newsgroup, or an email, or a web page, or a process listing, or a kubernetes definition, or or or.
Emacs can completely emulate vim; vim cannot emulate emacs. Seems to me emacs is more powerful.
That is probably not true. The main reason is more probably that nobody wants to emulate emacs in vim. Its more telling IMO that emacs people want vim in it. As user slurry above pointed out, its probably because old habits die hard and because people continue doing the same stuff to justify time investment.
Yes, you can give up the vim bindings in certain modes, or spend lots of time re-configuring various packages' bindings. But that is not something you'd ever have to struggle with when using vim.
The argument emacs can do frames is irrelevant in this respect.
For example the Pantheon's architectural design more readily facilitates shelter from inclement weather. While the Pyramid of Cheops could be modified to do so, it seems to me that adding a portico or walk-in interior space is both non-trivial and at odds with the existing architecture.
But Emacs makes it easier for that "anything" to include things the user wants to be able to do, but aren't built into the system. I use VI, but far prefer Emacs because I can keep adding functionality to it as I need it. That's what's important to me.
"The reality is that I already spend most of my editing time in vim"