Most folks who use Vim/Emacs seem loyal to their editor and are not in much need of alternatives. Those who don't have plenty of graphical ones—Sublime, VS, Atom.
Most folks who use Vim/Emacs seem loyal to their editor and are not in much need of alternatives. Those who don't have plenty of graphical ones—Sublime, VS, Atom.
I tried to move to Atom, because I've heard good things, I read you could extend it in JS and that sounded good to me. The difference between customizing Emacs and customizing Atom could not be more night and day in my experience. Emacs is like a living thing, as crazy as that sounds. I feel the urge to make a slight customization to a key (which happens often) I just ask Emacs what function the key is executing and either wrap it in a custom function, or advise the function. I usually write and eval these customizations in the scratch buffer.
Meanwhile, Atom makes me restart to get any changes detected. There wasn't any live documentation system that I could find (which is something I can't fathom not having now).
Emacs, in terms of customization, is simply light years ahead of absolutely everything else. It's absurd to me that we're still stuck with it because seemingly nobody who wants to make a text editor has learned the lessons it has.
Emacs doesn't play super well with others. You can do a lot of things in emacs, but you can't do emacs in other things.
On the occasions that I'm writing Java, I find IntelliJ to be super awesome. But I get annoyed because the editor in IntelliJ is not emacs. I'd like to be able to do things I can do in emacs in IntelliJ. Realistically, that means replacing the IntelliJ editor with emacs, but at the moment that isn't really possible.
Some things you can use emacs for, like editing web forms (I used to do that with an extension in Firefox), but emacs is really not so great at being used in other programs.
As far as emacs itself, the somewhat crappy GUI rendering precludes creating an IntelliJ like experience.
Instead, everyone almost always finds their own way of rendering the text editor portion of what they are doing. Consider, your concern could just as easily be shifted to complaining about IntelliJ. Why can't I easily call out to it to get the information it knows?
And this is largely up to each person. I personally loathe the IDEA GUI. And most any GUI. I will grant that they do better screenshots, but I will take what is effectively a super powerful terminal buffer any day.
It doesn't change your point at all, but I simply have a different opinion and was asked about it. I don't really care about embedding intellij, I just want to use emacs in other things.
I do feel it is a rather personal choice. As I said, I don't care for the IDEA GUI, but I understand others do.
Vim is very powerful so although it hasn’t got features like visual blocks, you can do pretty much the same thing with macros and shortcuts - as long as you know and remember them, but that’s the tricky part... Somethings it would be nice just to click a menu to find that feature you use one a month.
I tried switching to Atom but then got lost and felt it was no way near as powerful as Vim out the box (even with the Vim plugin), so here I am stuck with Vim :-)
Vim has visual blocks? Ctrl-v. Did you mean multiple cursors?
If you're writing an editor and want to include a special feature, please consider an online help system that
-- allows you to view help about the mode and keyboard settings immediately by one keypress - with absolutely zero delay, at any time and ideally fullscreen - and return to exactly where you were before you looked up the documentation
-- optionally shows you continuous online help during your editing (like e.g. the contextually most important keybindings while you're editing)
I've never expected nor done any work to attract users other than myself, so there are a handful of rough edges I've never bothered to polish, but I have in fact been using this thing full-time for several years.
Perhaps I wouldn't have written it if micro had existed back then.
It's funny how life works. There is nothing especially sophisticated about this bit of code, it has many little bugs I've never bothered to fix, and I'd design it completely differently if I started now. Still, though: after thirty-plus years writing code, I've gotten more actual use out of this little tool than anything else I've ever written. Judging by the ratio of hours spent writing it to hours spent using it, nothing else even comes close, not within an order of magnitude.
Maybe actually instead of caps-lock.
I think I've solved all my keyboard related problems know.
LOL. My experience with an average of 5-6 backgrounded vims *per each named tmux session" which I use to keep track of different source files I'm working on goes against this. Sure, I can use vim's windows, but I don't want split screen usually (I'll use the other terminal I have open if I do). I don't use tmux's windows either really. It's more a way to preserve session when changing workstations (these are remote terminals), and preserve against network drops. I use each tmux session as a contained work environment for the most part. I do all my software development using vim on a remote server, and have for most of the last two decades. I've worked with numerous other developers that work similarly for professional projects, personal projects, or both.
Let's just say that there might be people that use the combined features of terminal applications, terminals, and remote connections in ways that you might think were rare, but actually have large following and leave it at that. :)
There are benefits to being comfortable in a somewhat stock Vin, and there are benefits to having it highly customized. I find the benefits imparted might be outweighed by the discomfort when it's not as you expect if your work flow forces that situation on you, so as my work flow has changed with the type of work I do, I've tried adopting different vim strategies.
But in the end it's not about whether it's efficient, it's about whether it's rare, and I think it's not from the different vim users I've encountered, which may be an entirely different subset than the ones you have.
"My fingers cannot be retrained."
* The IDE can be too slow to start.
* Maybe it's not working today.
* Maybe it's not on the server.
Vim addresses nearly all the requirements -- it's reliable; it's easy to use as $EDITOR, to be called by other CLI tools; and it offers great syntax coloring and editing options. It's just that it's too confusing. The old joke about developers shutting off the computer to quit...
I'm not sure whether I am happy or sad that it does that now.
I filled an issue regarding that but the maintainer seems absent.