16 ms·

Vim is the worst editor, except all the other editors

55 points by dave1010uk 13y ago

lutusp 13y ago
> Vim is the worst editor ... except all the other editors Yes to the first five words, no to the rest. How many Vim users realize that some of its more infuriating behaviors can be traced back to its predecessor vi, which had to be able operate with a "paper terminal", essentially a roll of paper as a display, without wasting too much paper during editing? And how do I know this? During my time at NASA designing part of the Space Shuttle, I was obliged to use vi and its immediate predecessor, with a roll of paper as a display. It was bad then, and it's worse now. The difference is there's no longer an excuse. http://en.wikipedia.org/wiki/Vi#History http://en.wikipedia.org/wiki/Vi#History Quote: "vi was derived from a sequence of UNIX command line editors, starting with ed, which was a line editor designed to work well on teletypes ... "
- chrismorgan 13y ago
  I am curious: have you used Vim much in the past few years? (Determine for yourself what "few" means here.)
  - lutusp 13y ago
    I just installed vim and tried to use it. For those who don't live in the dark ages, vim is still a command-line editor, and it still has the classic vi modes -- one mode for loading and saving files, one mode for moving the cursor around, one mode for deleting text, one mode for typing in new text, one mode for searching, etc. etc.. In other words, it's vi with a few changes. I still can't navigate while typing, or delete while navigating, or search while deleting. As I tried to remember all those weird incantations that I last used in the mid 1970s, I felt as though I was in a time warp. Guess why Apple Writer was so popular in 1979 (http://en.wikipedia.org/wiki/Apple_Writer http://en.wikipedia.org/wiki/Apple_Writer), in spite of its many limitations? I wrote Apple Writer specifically to avoid the handicaps built into vi, which was the default editor in those times. After Apple Writer came out, people would write articles saying things like, "My God! With Apple Writer, you can read files, write files, type, navigate and search without having to change modes! How did Lutus do it?" The answer is simple. Apple Writer wasn't so extraordinary, but I wasn't mentally crippled by the vi code base or method of operation, and I wasn't averse to exposing people to new ideas. But you know what? If I was told that people would still be using vi thirty-four years later, and boasting about its wonderfulness, I would have fallen down laughing. Even pico and nano are easier to use, and they're desperately weak. I shouldn't complain. Apple Writer made me a multimillionaire through the simple virtue of not being vi, and little else. I should thank you people.
    - aidos 13y ago
      Kudos on Apple Writer - but I think you're confusing easy to learn and more powerful. The modes that you complain about (and let's be honest - there are really just 2 that you use) are what make it so powerful. You don't go into another mode to perform those operations - they're already there, and just a keystroke away. You go into another mode to insert text. By making that compromise you make the system faster and more powerful but it needs to be learnt. That's where you won - you dropped the barrier to entry.
      - lutusp 13y ago
        > The modes that you complain about (and let's be honest - there are really just 2 that you use) ... No, to switch from entering text, to deleting text, to searching for text, to copying and pasting text, to saving a file, to loading a file, all require switching modes. Let's be honest. > By making that compromise you make the system faster and more powerful ... Having to enter additional keystrokes, a throwback to a computer keyboard that either didn't have control keys or couldn't exploit them, makes editing "faster and more powerful"? Nice reasoning.
        jamesbooker 13y ago
        No extra keystrokes required, which was your original argument, moron. Please fuck off, actually learn to use vim properly (its changed a lot from the ancient editor you used) and then come back with some arguments that are accurate and based on facts. I guarantee you will learn a few things that you can out into that crappy editor that you maintain (you know, the one that needs an ENTIRE JRE TO RUN)
        aidos 13y ago
        You'll need to provide explicit examples of where any of those operations requires more keystrokes in vim than any other editor - I can't think of any. You're calling vim commands "modes" to deliberately make it sound more complex than it is. I want to change to next 3 words. I type 'c3w' - you're saying that's modal - which it sort of vaugly is. I could have done 'v3w' to highlight the next 3 words (something you would do in any other editor). Then I hit 's' to substitute them for something else. No mode involved (other than the selection - which is the same for any editor). I stand by my assertions - it's up to you to provide the counter examples to back up your claims.
- goldfeld 13y ago
  You seem to be an otherwise great guy with insightful comments and writings[1] that I occasionaly see on elsethreads. But as soon as a vim post hits the frontpage here you are to rehash the same authority fallacies, brag about having used and created this and that editor, and claim that what's in discussion here is as good as vi (which wasn't even extensible to begin with.) If you hated the little editor so much during your time being forced to use it, why do you insist on visiting these threads and reliving such horrid memories? I'm not sure who you're trying to save here, the bunch of us seem to be mostly happy with what is really the worst editor we can get except all the others. [1]: Was really pleased to bump into your article on Examples in Math the other day.
  - lutusp 13y ago
    > ... why do you insist on visiting these threads and reliving such horrid memories? That's easy to answer -- as astonishing as it may sound, people are still using vim. Some of them might even think it's natural to have to use twice as many keystrokes as are required on a modern editor, even another command-line editor, to switch from editing to navigating (as just one example). > I'm not sure who you're trying to save here, the bunch of us seem to be mostly happy with what is really the worst editor we can get except all the others. Yes, except that that is false. Any meaningful comparison is so obviously against vim that I feel like I'm trying to dissuade True Believers from an irrational belief.
    - pestaa 13y ago
      Please tell me more about this modern editor where half the keystrokes get the same job done. Or tell me about any editor where the same amount of keystrokes get the same job done.
      - lutusp 13y ago
        I can't drag you kicking and screaming into the early twenty-first century. You have to make that trip on your own.
        13y ago
- danielbarla 13y ago
  I would actually love to hear some specific and insightful criticisms of Vim, but referring to its history is not a particularly compelling one (for me, at least). In today's terms, the above "without wasting too much paper during editing" argument translates into "with as few keystrokes as possible". In some situations, I definitely find my ability to type (or in general, to edit text) to be the bottleneck in getting things out of my brain and into a file. In these cases, Vim allows me to trade a bit of brainpower for efficiency in editing, which is great. Other times, I'm being held up because I'm not sure what to type, but I prefer to do creative thinking away from the keyboard, so Vim is neither here nor there in those cases. So basically, the historical argument doesn't make sense for me; do you have any specific issues with Vim?
  - lutusp 13y ago
    > I would actually love to hear some specific and insightful criticisms of Vim ... Sure, no problem: * It's still a command-line editor. Just like vi. * To perform multiple operations, like moving the cursor around, entering text, deleting text, searching the document, saving and loading files, requires you to switch modes. Just like vi. * It cannot take advantage of the modern computing environment -- mouse navigation, different fonts, text styling, page layout, or anything else. Just like vi. * No clipboard support -- all copying and pasting operations, apart from being another example of bizarre vi incantations requiring the recall of a raft of magic characters, is within vi/vim and disregards the system clipboard. I can say this in vi/vim's favor: it's a step up from ed, its predecessor. > In today's terms, the above "without wasting too much paper during editing" argument translates into "with as few keystrokes as possible". No, actually, in the vi days, to save paper one had to enter more keystrokes, not fewer. When I wrote Apple Writer, former users of vi were astonished by how few keystrokes were required to accomplish things. > do you have any specific issues with Vim? Just one. It doesn't belong in modern times, it belongs in a museum.
    - virtualwhys 13y ago
      What is/are your replacement(s) for VIM?
- jamesbooker 13y ago
  Ah - Paul Lutus, the fantastically boring, ridiculously bad wig-wearing dinosaur manages to wheel himself into another discussion by popular demand from no-one at all to remind the participants how he wrote Apple Writer and worked on the Space Shuttle and is a multimillionare. How many people use Apple Writer these days Paul? Is it more than Vim? A number closer to zero? The bitterness seething out of your every pore that your software has been consigned to the graveyard of history whilst Vim is growing in popularity is so tangible!
  - lutusp 13y ago
    Imagine bolstering your fantasies with evidence. Apple Writer was retired at just the right moment -- when something better came along. That's how technology works, and no one was more pleased than I was. > The bitterness seething out of your every pore that your software has been consigned to the graveyard ... Dream on, moron. Apple Writer belongs in a museum along with vi. What's astonishing is that people are still using vi when there are any number of much better choices. > ... whilst Vim is growing in popularity is so tangible! Based on that fantasy, you may want to resume your medication.
    - jeremysmyth 13y ago
      I feel the need to point out that everyone else is talking about vim, but you're talking about vi. Could that explain some of the differences in how you remember things based on how they are? (redux)
      - lutusp 13y ago
        > I feel the need to point out that everyone else is talking about vim, but you're talking about vi. Yes, and vim = vi with decorations, but essentially the same editor. Or did you miss the first time I pointed that out?
  - klibertp 13y ago
    Heh, that was completely unneeded, really.
- klibertp 13y ago
  Oh, it's you again. We talked about this some time ago. Since then I stopped using Vim in favor of Emacs, which is modeless - I remember that having modes was the biggest sin of Vim in your eyes. It's been 5 months since I switched to Emacs. My .emacs.d is actually bigger than .vim_runtime was, but it's because of more configurable features found in Emacs plugins, so it's natural. My init.el is also longer than my .vimrc, but this is because of much friendlier Emacs API and my love for Lisps (and dislike for vimscript). On the whole I'm quite pleased with the switch, although making Emacs into my editor took a comparable amount of time and code to Vim. I don't use Evil or anything like it, of course. Emacs is better in many respects. CEDET is nice, SpeedBar and imenu with it's syntactic extensions work wonders - TagBar in Vim comes close to SpeedBar, but there's no imenu. auto-complete is better than omni-complete and easier to extend. Eshell works better than conque. Icicles, ido and smex make working with minibuffer a pleasure to the extent that Vim could never match - although it has basic completion of commands. Of course there is more, but the important thing to note here is that, while Emacs implements many things a bit better, Vim has them too. And it's perfectly reasonable to prefer Vim versions. So what I'm saying is that I found Emacs better but Vim is still really great. Ok, so now to the modality. Emacs lacks modes, Vim has them. Last time we talked you were saying that modes are inefficient and hard to use. I could argue for modality then, but not against it, because I lacked experience with non-modal editor. Now I can compare the two. The truth is that I was suspicious of non-modal editing in Emacs. I heard and read many rants about long sequences of modifier keys you need to press in order to do something. Turns out these rants where right for the most part. Some examples: C-- C-4 C-x <tab> performs hard dedent by four spaces. C-s C-w C-s ... performs incremental search (forward) for current word (Esc # in Vim). C-4 M-f goes four words forward (4w in Vim). There are also tricky ones, like C-x d opening dired and much easier to type C-x C-d displaying a list of files in current directory in a buffer. In practice, however, with some amount of remapping, this is not an issue. But wait, isn't pressing escape instead of some universal prefix (C-c for user commands in emacs) not a problem in practice, too? After using Emacs and Vim I can say that the complexity of commands in both is almost the same. In Vim I remapped Esc to CapsLock - in Emacs I have Ctrl in place of CapsLock (although I'm contemplating placing Alt there and Ctrl in place of Alt). The only real difference I feel is that in Vim I could just hit the first modifier key (esc) while in Emacs I need to keep it pressed. Emacs uses Alt (Meta), while Vim does not, but that's a little difference, because Alt is usually in a place that's easy to reach. In conclusion, while I like Emacs very much, I still find your claim that "modal editors" are for sad, handicapped individuals who just don't know any better full of bullshit. Modality is not any worse than modeless model in itself and Vim implements modality in a way which makes using it as convenient as Emacs chords. While there are other things I like in Emacs better, bashing Vim because of modes alone is pure stupidity; bashing it because of it's ancestry is an equivalent of saying that "your mama is fat" and saying it has no X feature is most likely false anyway. PS. Elsewhere in this thread you're saying that Vim can't use mouse and clipboard. Of course it can - <esc>"=y copies to system clipboard instead of local one. I admit that Emacs support for mouse events is by far superior, and of course typesetting - colors, sizes and styles of fonts - are well supported in Emacs and not in Vim. But reaching for the mouse is bad anyway and if you have to, Vim supports all three mouse keys, which only makes the latter a valid claim. It's up to everyone to decide whether they truly need different fonts in their editor.
- gregjor 13y ago
  vi has always been a full-screen visual editor, as in display screen visual, not teletype visual. The paper-oriented predecessors to vim/vi were ed and ex. Like you I used teletype-oriented editors until vi came along, about the same time I got my own ADM-3A, the same dumb terminal Bill Joy used to develop vi on. I think most of us who learned vi back when it was simple have the keystrokes burned into our brains, and we know that vi is quite efficient once learned. I still use vim but not any plugins or extensions and I don't write scripts for it, because I just forget about them anyway and they aren't going to be installed on the GUI-less servers I ssh into. I use a more modern editor (TextMate) most of the time. I don't think vi or vim are terrible, but they can feel clunky on modern GUI-based operating systems. A serious driver should know how to shift a manual transmission. A serious programmer or sys admin should know how to manipulate files and text with standard UNIX tools and editors. vi may not be the best text editor depending on how you measure "best," but it is ubiquitous and does the job it was intended for. My advice for vim users is to start with the vanilla install, no plugins. Learn to configure things you really need in the .vimrc file. If you find yourself creating a complex and over-personalized editing environment to save the occasional keystroke or make vim work like an IDE, you are shooting yourself in the foot in the long run. You may as well just use Eclipse.
seren 13y ago
As a regular Vim user, I don't understand why some of these features, like Ctrl-P are not implemented natively in C, rather than to have to rely on Vimscript or Ruby plugin.
- chrismorgan 13y ago
  Writing things in Vimscript makes for easy and entirely reliable deployment. Ruby requires a +ruby build and Ruby to be installed, but at least avoids some of the warts of Vimscript, while still being as simple as "put it in and use it". (For myself, I'd prefer not to depend on Ruby, or even Python, though it's a much safer bet.) Any plugins in C require a compilation step before you can use it.
  - seren 13y ago
    I was maybe unclear, but I was regretting that a fuzzy find for opening files was not part of the vim core. It seems to be a generic editor feature that could benefit everyone.
bgar 13y ago
First of all, you have to dump Janus. It is bad for you. Learn to use stock Vim and gradually integrate plugins as needed. I recommend NeoBundle to manage them, as it is able to compile plugins if required. I've been using vim for years and the only plugins I use are vim-airline[1] and vim-bufferline[2]. Of course, my editing needs may not be as complex as yours, but in reality most things you think you need a plugin for can be done with plain Vim. Feel free to check out my humble .vimrc[3] for some inspiration. 1: https://github.com/bling/vim-airline https://github.com/bling/vim-airline 2: https://github.com/bling/vim-bufferline https://github.com/bling/vim-bufferline 3: https://github.com/wolfcore/air-dotfiles/blob/master/.vimrc https://github.com/wolfcore/air-dotfiles/blob/master/.vimrc
- icambron 13y ago
  That may well be good advice, but it doesn't really solve the other problems he's complaining about, right?
  - bgar 13y ago
    No, but it's a good start.
icambron 13y ago
Yes! With the exception of item #5 and #6, I really strongly agree with these items. Vim's automatic indenting, in particular, just seems systematically broken. On 5, ctl-p works great for me. I have it set up to use git in choosing what to ignore and it's plenty fast. On 6, I probably just don't know any better.
chatman 13y ago
Using vi is not bad, its a "penance". Emacs is the real editor! So says Richard Stallman. :-)
- markeganfuller 13y ago
  Normally I'd respect something RMS said and I love him for his conviction but on this we must disagree :)
  - chatman 13y ago
    And he himself makes these remarks in a cool and snarky style, his usual humorous self. It is never emacs vs. vi war for him. :-)
blumkvist 13y ago
sublime, bruh
stormbrew 13y ago
Kinda sounds like this person just wants Sublime to me.
- n1c 13y ago
  Yeah; I use Sublime in vintage mode and I think it has all those bases covered.
djur 13y ago
The reason there's no project-wide find and replace in vim is that vim has no concept of a project. It's designed to be one of many tools, which works really well for some workflows and not for others. #5 is the same deal -- they're limited by the design of vim, and that design doesn't fit anything like TextMate's project search. It would drive me _crazy_ if vim saved without me telling it to. I think a lot of people suffer needlessly trying to make vim be what they want it to be, when it never is going to meet their expectations. You'd be better off trying to get those things you find useful about vim implemented in TextMate or Sublime than the reverse.
- jessedhillon 13y ago
  The only thing that drives me crazy about the save/do-you-want-to-reload prompt is actually a git related issue. When you commit, git updates all committed files in some way that triggers vim change detection. You go back to vim, write some code, try to save and then you get this DANGER WILL ROBINSON message. It's horrible because you're not quite sure sometimes if there was a legitimate change made in another process that you're now about to undo. Half the time I end up copying the lines I know I added, allowing a reload, and then pasting them back in, just to be safe.
  - aidos 13y ago
    Really? That sounds misconfigured and it certainly doesn't happen for me. Are you on windows? Maybe it's just a problem there. I'd take a look a bit deeper to see if I could figure that out if I were you as it does sound like a nuisance. Personally (regarding the original gripe in the post) I'd be horrified if my text editor was silently ignoring edits or just updating the code under me. If that was really a concern while I was working on my software I'd take a look at the workflow to see what could be done about it.
  - heurist 13y ago
    gitattributes or autoclrf could do that if not configured properly. I never have that issue when working on personal projects using vim and git.
  - 13y ago
gabemart 13y ago
The issue of soft-wrapping text drives me nuts, not just with editors like vim but with programming-focused tools that can edit text in general. Github is terrible for this. Why isn't it possible to enable soft-wraps when viewing diffs? Hard-wrapping the text is not always a solution because it makes the text so much less versatile in terms of what you can do with it, unless you're willing to periodically remove the hard-wraps when you want to move the text somewhere else. Using markdown is not a solution because markdown is destructive; it eats blank lines and indentation.
- djur 13y ago
  A programmer's text editor and a word processor have much different requirements and should be different tools. There are much better options than vim to author formatted documents.
IanCal 13y ago
1) Dump Janus, add the plugins you actually want 2) True 3) :set paste 4) Then wrap it in a function 5) I've always found ctrl-p to be snappy actually. You can replace the matcher with ag or similar > write the Vim configuration lines required to cause those files to be ignored. You have got to be kidding me. Write a small amount of config once per project? It's no more complex than adding things to a UI set wildignore+=*/tmp/*,*.so,*.swp,*.zip 6) No, vim can't, but plugins can. Ctrl-p has this feature (http://superuser.com/questions/390011/fuzzy-find-within-file-in-vim http://superuser.com/questions/390011/fuzzy-find-within-file...) 7) Stop just navigating with j and k. > After reading this list, feel free to tell me how I'm doing it wrong on twitter. You're not googling anything to find out the answer? Also, because occasionally people haven't heard of it, get Gundo. http://sjl.bitbucket.org/gundo.vim/ http://sjl.bitbucket.org/gundo.vim/ Vim has a full tree undo, gundo makes it easy to navigate and see diffs between changes in code.
- maaaats 13y ago
  But that's kinda the problem with vim. Having a sane configuration takes hours of setup and googling.
  - aidos 13y ago
    That's only the first time. It's a completely different paradigm and you have to learn it. Once you've learnt it this entire list is a non-issue. Not only that - configure it as you want, then take that config with you to every other machine that you ever use - surely that's worth the effort.
  - IanCal 13y ago
    It starts with a sane configuration, the problem is when you want to add loads of features you have to spend a small amount of time adding them. The alternative is to have a fucking insane amount of functionality present to begin with because everyone wants something slightly different.
  - klibertp 13y ago
    Depending on how you define "sane" it can be months. Vim is said to be a programming language for text editing - I wouldn't expect anything less of a complexity from a thing like this. I recently learned Emacs and it took me two months - that short because I already went through the process with vim some years ago - to learn it and configure it to my liking. My Emacs config counts 983 lines with comments and whitespaces removed[1]. My .vimrc was shorter, but mainly because I dislike vimscript and like Lisps. [1] cat .emacs.d/config/*.el | egrep -v '^$' | egrep -v '^;;' | wc -l
m2mdas 13y ago
Pasting the reply I gave in r/vim Answer to some of the points, Janus: There are divided opinions in vim community about whether distributions should be used or not. I am on the latter side. But still for just checking out I installed Janus a while ago. Yes it is slow, but it turns out that it is as slow as my then `.vimrc` configuration. I tried to track down the problem. It is because of vim's blocking behaviour during executing external commands. When you write a buffer or switch to a buffer, syntastic, tagbar, powerline statusline, gitgutter, bufexplorer all execute external command. Vim becomes more slow when `.git` repository grow larger or when saving a large file. So how do you solve the problem? Remove those plugins and install Unite.vim[1] with vimproc[2] asynchronous library. Files that change: If you do external edits more frequently then I think it is time to rethink your work-flow. I think there is a common consensus that you should not run live edit in server. * Indenting pastes* : There is a plugin for that [3] ? * Opening files inside my project : Last I checked command-t was damn fast, don't know where slowness comes form. Another alternative is `Unite.vim` `file/async` source. It is fast at finding files but goes slow while doing ignore-pattern checking. Without the checking it is DAMN FAST. The `phpcomplete/files` source I created for my php autocomplete plugin[4] easily list 4000+ files in seconds. If you want to list files obeying the patterns in the '.gitignore' or '.hgignore' files. Checkout my unite-file-vcs[4] plugin. It adds a `file/vcs` source that lists files by issuing `git ls-files` or `hg status -c -m -u` command for `git` or `mercurial` projects respectively. Navigating inside files*: Checkout unite-outline[6]. It shows live output by parsing the current buffer. Unite.vim required. But it does not support css files right now. Adding support should be easy. So the summary of the story. Move to `unite.vim` and friends ;) [1] https://github.com/Shougo/unite.vim/ https://github.com/Shougo/unite.vim/ [2] https://github.com/Shougo/vimproc.vim https://github.com/Shougo/vimproc.vim [3] https://github.com/sickill/vim-pasta https://github.com/sickill/vim-pasta [4] https://github.com/m2mdas/phpcomplete-extended https://github.com/m2mdas/phpcomplete-extended [5] https://github.com/m2mdas/unite-file-vcs https://github.com/m2mdas/unite-file-vcs [6] https://github.com/Shougo/unite-outline https://github.com/Shougo/unite-outline
- regularfry 13y ago
  > Files that change: If you do external edits more frequently then I think it is time to rethink your work-flow. I think there is a common consensus that you should not run live edit in server. It's possible this isn't what you meant, but external edits do not imply editing code live on a server.
rvijapurapu 13y ago
Patience my dear friend, patience. I have been using Vim as my editor of choice for over a decade, I think I barely use 10% of its features. Your configuration is always evolving - so don't fret if a plugin or a setting is not working for you, it just means its gotto go.. That said focus on `your productivity` over a religious choice of an editor. You actually got to live with it for decades to come. choose the right one which fits your use case.
Gonzih 13y ago
I prefer Unite.vim over Ctrl-P since it can be used more than for file matching. But yes, you need to spend some time to configure it.
bpizzi 13y ago
> I've been using it full-time for just over three months now. That's it: you just need to give it more time. One simply can't expect to fully climb vim's learning curve in just a quarter of a year. Your brain can't adapt so rapidly to so much new shortcuts. > Jump to CSS selector. Jump to class. Fuzzy string matching. All these things and more are what I am used to. Vim just can't do them. That's one example among others: there's vim's marking system for that, and your brain isn't just used to it now. You find it slow, broken and not user-friendly, but it's not really, it's just that you need to give it time to master it. My 2c advice: it you really want to like it, keep going and give it a full year. If you think you can't give it more time, then Vim isn't for you and some commercial editors might do it. I've been there, I know your current feeling. I'm a happy vimmer now but it hasn't been the case for something like a year. There's a reward for real vimmers: you'll never need to switch anymore to another editor, because Vim is there, powerfull, opensource, free, multi-plateform, and you know how to use it smoothly.
- pestaa 13y ago
  I like the spirit, but how will Vim's marking system help me jump to a CSS selector in an unbuffered stylesheet? I'm really curious; missing this feature from heavyweight IDEs.
  - bpizzi 13y ago
    Been there also. _My_ solution was not to rely anymore on stuff provided by a heavyweight IDE. "Jumping to somewhere in an unbuffered file according to where I am in the current buffer", that is actually depending on a background worker that knows a very specific set of rules and use it to constantly cycle threw the filesystem. Which bg process is usually provided by tanks like Eclipse. With the time I've found something that matches that behavior without the payload on the computer, and guess what, it's my brain. I'm no more in pain of jumping to the definition of a css rule, because I know which css file I have to invoke and I can do it _very_ quickly thanks to Control+P, and jumping to the definition is a matter of one or two "/". Of course you need to organize things smartly in your project if you ever want to do that without too much thinking time, but hell, I count that on the bright side of this solution.
ranza 13y ago
I feel his pain! Especially the paste thing. I've been back and forth with vim for as long as i can remember. Finally decided to switch to Sublime on my desktop and keep a stripped down version of vim for my terminal needs. I feel like Janus is doing more wrong then good. If you want to get into the mindset of vim you should ditch Janus.
regularfry 13y ago
Why limit yourself to a single editor? They're different tools, good at different things. It's really not that hard to learn, for instance, both emacs and vim. I've got both open right now!
daGrevis 13y ago
If anyone is looking for sane configuration — vim-sensible is the thing you are looking for! https://github.com/tpope/vim-sensible https://github.com/tpope/vim-sensible
DH61AG 13y ago
The only problem with Vim is that you need to learn it. If it's too hard for you then there is plenty of other editors.
jfe 13y ago
Time to get out of your two-editor bubble, folks; there are other options. In my opinion, Acme puts both Emacs and Vim to shame.

55 points by dave1010uk 13y ago

> Vim is the worst editor ... except all the other editors Yes to the first five words, no to the rest. How many Vim users realize that some of its more infuriating behaviors can be traced back to its predecessor vi, which had to be able operate with a "paper terminal", essentially a roll of paper as a display, without wasting too much paper during editing? And how do I know this? During my time at NASA designing part of the Space Shuttle, I was obliged to use vi and its immediate predecessor, with a roll of paper as a display. It was bad then, and it's worse now. The difference is there's no longer an excuse. http://en.wikipedia.org/wiki/Vi#History http://en.wikipedia.org/wiki/Vi#History Quote: "vi was derived from a sequence of UNIX command line editors, starting with ed, which was a line editor designed to work well on teletypes ... "

chrismorgan 13y ago
I am curious: have you used Vim much in the past few years? (Determine for yourself what "few" means here.)
- lutusp 13y ago
  I just installed vim and tried to use it. For those who don't live in the dark ages, vim is still a command-line editor, and it still has the classic vi modes -- one mode for loading and saving files, one mode for moving the cursor around, one mode for deleting text, one mode for typing in new text, one mode for searching, etc. etc.. In other words, it's vi with a few changes. I still can't navigate while typing, or delete while navigating, or search while deleting. As I tried to remember all those weird incantations that I last used in the mid 1970s, I felt as though I was in a time warp. Guess why Apple Writer was so popular in 1979 (http://en.wikipedia.org/wiki/Apple_Writer http://en.wikipedia.org/wiki/Apple_Writer), in spite of its many limitations? I wrote Apple Writer specifically to avoid the handicaps built into vi, which was the default editor in those times. After Apple Writer came out, people would write articles saying things like, "My God! With Apple Writer, you can read files, write files, type, navigate and search without having to change modes! How did Lutus do it?" The answer is simple. Apple Writer wasn't so extraordinary, but I wasn't mentally crippled by the vi code base or method of operation, and I wasn't averse to exposing people to new ideas. But you know what? If I was told that people would still be using vi thirty-four years later, and boasting about its wonderfulness, I would have fallen down laughing. Even pico and nano are easier to use, and they're desperately weak. I shouldn't complain. Apple Writer made me a multimillionaire through the simple virtue of not being vi, and little else. I should thank you people.
  - aidos 13y ago
    Kudos on Apple Writer - but I think you're confusing easy to learn and more powerful. The modes that you complain about (and let's be honest - there are really just 2 that you use) are what make it so powerful. You don't go into another mode to perform those operations - they're already there, and just a keystroke away. You go into another mode to insert text. By making that compromise you make the system faster and more powerful but it needs to be learnt. That's where you won - you dropped the barrier to entry.
    - lutusp 13y ago
      > The modes that you complain about (and let's be honest - there are really just 2 that you use) ... No, to switch from entering text, to deleting text, to searching for text, to copying and pasting text, to saving a file, to loading a file, all require switching modes. Let's be honest. > By making that compromise you make the system faster and more powerful ... Having to enter additional keystrokes, a throwback to a computer keyboard that either didn't have control keys or couldn't exploit them, makes editing "faster and more powerful"? Nice reasoning.
      - jamesbooker 13y ago
        No extra keystrokes required, which was your original argument, moron. Please fuck off, actually learn to use vim properly (its changed a lot from the ancient editor you used) and then come back with some arguments that are accurate and based on facts. I guarantee you will learn a few things that you can out into that crappy editor that you maintain (you know, the one that needs an ENTIRE JRE TO RUN)
      - aidos 13y ago
        You'll need to provide explicit examples of where any of those operations requires more keystrokes in vim than any other editor - I can't think of any. You're calling vim commands "modes" to deliberately make it sound more complex than it is. I want to change to next 3 words. I type 'c3w' - you're saying that's modal - which it sort of vaugly is. I could have done 'v3w' to highlight the next 3 words (something you would do in any other editor). Then I hit 's' to substitute them for something else. No mode involved (other than the selection - which is the same for any editor). I stand by my assertions - it's up to you to provide the counter examples to back up your claims.
goldfeld 13y ago
You seem to be an otherwise great guy with insightful comments and writings[1] that I occasionaly see on elsethreads. But as soon as a vim post hits the frontpage here you are to rehash the same authority fallacies, brag about having used and created this and that editor, and claim that what's in discussion here is as good as vi (which wasn't even extensible to begin with.) If you hated the little editor so much during your time being forced to use it, why do you insist on visiting these threads and reliving such horrid memories? I'm not sure who you're trying to save here, the bunch of us seem to be mostly happy with what is really the worst editor we can get except all the others. [1]: Was really pleased to bump into your article on Examples in Math the other day.
- lutusp 13y ago
  > ... why do you insist on visiting these threads and reliving such horrid memories? That's easy to answer -- as astonishing as it may sound, people are still using vim. Some of them might even think it's natural to have to use twice as many keystrokes as are required on a modern editor, even another command-line editor, to switch from editing to navigating (as just one example). > I'm not sure who you're trying to save here, the bunch of us seem to be mostly happy with what is really the worst editor we can get except all the others. Yes, except that that is false. Any meaningful comparison is so obviously against vim that I feel like I'm trying to dissuade True Believers from an irrational belief.
  - pestaa 13y ago
    Please tell me more about this modern editor where half the keystrokes get the same job done. Or tell me about any editor where the same amount of keystrokes get the same job done.
    - lutusp 13y ago
      I can't drag you kicking and screaming into the early twenty-first century. You have to make that trip on your own.
      - 13y ago
danielbarla 13y ago
I would actually love to hear some specific and insightful criticisms of Vim, but referring to its history is not a particularly compelling one (for me, at least). In today's terms, the above "without wasting too much paper during editing" argument translates into "with as few keystrokes as possible". In some situations, I definitely find my ability to type (or in general, to edit text) to be the bottleneck in getting things out of my brain and into a file. In these cases, Vim allows me to trade a bit of brainpower for efficiency in editing, which is great. Other times, I'm being held up because I'm not sure what to type, but I prefer to do creative thinking away from the keyboard, so Vim is neither here nor there in those cases. So basically, the historical argument doesn't make sense for me; do you have any specific issues with Vim?
- lutusp 13y ago
  > I would actually love to hear some specific and insightful criticisms of Vim ... Sure, no problem: * It's still a command-line editor. Just like vi. * To perform multiple operations, like moving the cursor around, entering text, deleting text, searching the document, saving and loading files, requires you to switch modes. Just like vi. * It cannot take advantage of the modern computing environment -- mouse navigation, different fonts, text styling, page layout, or anything else. Just like vi. * No clipboard support -- all copying and pasting operations, apart from being another example of bizarre vi incantations requiring the recall of a raft of magic characters, is within vi/vim and disregards the system clipboard. I can say this in vi/vim's favor: it's a step up from ed, its predecessor. > In today's terms, the above "without wasting too much paper during editing" argument translates into "with as few keystrokes as possible". No, actually, in the vi days, to save paper one had to enter more keystrokes, not fewer. When I wrote Apple Writer, former users of vi were astonished by how few keystrokes were required to accomplish things. > do you have any specific issues with Vim? Just one. It doesn't belong in modern times, it belongs in a museum.
  - virtualwhys 13y ago
    What is/are your replacement(s) for VIM?
jamesbooker 13y ago
Ah - Paul Lutus, the fantastically boring, ridiculously bad wig-wearing dinosaur manages to wheel himself into another discussion by popular demand from no-one at all to remind the participants how he wrote Apple Writer and worked on the Space Shuttle and is a multimillionare. How many people use Apple Writer these days Paul? Is it more than Vim? A number closer to zero? The bitterness seething out of your every pore that your software has been consigned to the graveyard of history whilst Vim is growing in popularity is so tangible!
- lutusp 13y ago
  Imagine bolstering your fantasies with evidence. Apple Writer was retired at just the right moment -- when something better came along. That's how technology works, and no one was more pleased than I was. > The bitterness seething out of your every pore that your software has been consigned to the graveyard ... Dream on, moron. Apple Writer belongs in a museum along with vi. What's astonishing is that people are still using vi when there are any number of much better choices. > ... whilst Vim is growing in popularity is so tangible! Based on that fantasy, you may want to resume your medication.
  - jeremysmyth 13y ago
    I feel the need to point out that everyone else is talking about vim, but you're talking about vi. Could that explain some of the differences in how you remember things based on how they are? (redux)
    - lutusp 13y ago
      > I feel the need to point out that everyone else is talking about vim, but you're talking about vi. Yes, and vim = vi with decorations, but essentially the same editor. Or did you miss the first time I pointed that out?
- klibertp 13y ago
  Heh, that was completely unneeded, really.
klibertp 13y ago
Oh, it's you again. We talked about this some time ago. Since then I stopped using Vim in favor of Emacs, which is modeless - I remember that having modes was the biggest sin of Vim in your eyes. It's been 5 months since I switched to Emacs. My .emacs.d is actually bigger than .vim_runtime was, but it's because of more configurable features found in Emacs plugins, so it's natural. My init.el is also longer than my .vimrc, but this is because of much friendlier Emacs API and my love for Lisps (and dislike for vimscript). On the whole I'm quite pleased with the switch, although making Emacs into my editor took a comparable amount of time and code to Vim. I don't use Evil or anything like it, of course. Emacs is better in many respects. CEDET is nice, SpeedBar and imenu with it's syntactic extensions work wonders - TagBar in Vim comes close to SpeedBar, but there's no imenu. auto-complete is better than omni-complete and easier to extend. Eshell works better than conque. Icicles, ido and smex make working with minibuffer a pleasure to the extent that Vim could never match - although it has basic completion of commands. Of course there is more, but the important thing to note here is that, while Emacs implements many things a bit better, Vim has them too. And it's perfectly reasonable to prefer Vim versions. So what I'm saying is that I found Emacs better but Vim is still really great. Ok, so now to the modality. Emacs lacks modes, Vim has them. Last time we talked you were saying that modes are inefficient and hard to use. I could argue for modality then, but not against it, because I lacked experience with non-modal editor. Now I can compare the two. The truth is that I was suspicious of non-modal editing in Emacs. I heard and read many rants about long sequences of modifier keys you need to press in order to do something. Turns out these rants where right for the most part. Some examples: C-- C-4 C-x <tab> performs hard dedent by four spaces. C-s C-w C-s ... performs incremental search (forward) for current word (Esc # in Vim). C-4 M-f goes four words forward (4w in Vim). There are also tricky ones, like C-x d opening dired and much easier to type C-x C-d displaying a list of files in current directory in a buffer. In practice, however, with some amount of remapping, this is not an issue. But wait, isn't pressing escape instead of some universal prefix (C-c for user commands in emacs) not a problem in practice, too? After using Emacs and Vim I can say that the complexity of commands in both is almost the same. In Vim I remapped Esc to CapsLock - in Emacs I have Ctrl in place of CapsLock (although I'm contemplating placing Alt there and Ctrl in place of Alt). The only real difference I feel is that in Vim I could just hit the first modifier key (esc) while in Emacs I need to keep it pressed. Emacs uses Alt (Meta), while Vim does not, but that's a little difference, because Alt is usually in a place that's easy to reach. In conclusion, while I like Emacs very much, I still find your claim that "modal editors" are for sad, handicapped individuals who just don't know any better full of bullshit. Modality is not any worse than modeless model in itself and Vim implements modality in a way which makes using it as convenient as Emacs chords. While there are other things I like in Emacs better, bashing Vim because of modes alone is pure stupidity; bashing it because of it's ancestry is an equivalent of saying that "your mama is fat" and saying it has no X feature is most likely false anyway. PS. Elsewhere in this thread you're saying that Vim can't use mouse and clipboard. Of course it can - <esc>"=y copies to system clipboard instead of local one. I admit that Emacs support for mouse events is by far superior, and of course typesetting - colors, sizes and styles of fonts - are well supported in Emacs and not in Vim. But reaching for the mouse is bad anyway and if you have to, Vim supports all three mouse keys, which only makes the latter a valid claim. It's up to everyone to decide whether they truly need different fonts in their editor.
gregjor 13y ago
vi has always been a full-screen visual editor, as in display screen visual, not teletype visual. The paper-oriented predecessors to vim/vi were ed and ex. Like you I used teletype-oriented editors until vi came along, about the same time I got my own ADM-3A, the same dumb terminal Bill Joy used to develop vi on. I think most of us who learned vi back when it was simple have the keystrokes burned into our brains, and we know that vi is quite efficient once learned. I still use vim but not any plugins or extensions and I don't write scripts for it, because I just forget about them anyway and they aren't going to be installed on the GUI-less servers I ssh into. I use a more modern editor (TextMate) most of the time. I don't think vi or vim are terrible, but they can feel clunky on modern GUI-based operating systems. A serious driver should know how to shift a manual transmission. A serious programmer or sys admin should know how to manipulate files and text with standard UNIX tools and editors. vi may not be the best text editor depending on how you measure "best," but it is ubiquitous and does the job it was intended for. My advice for vim users is to start with the vanilla install, no plugins. Learn to configure things you really need in the .vimrc file. If you find yourself creating a complex and over-personalized editing environment to save the occasional keystroke or make vim work like an IDE, you are shooting yourself in the foot in the long run. You may as well just use Eclipse.

seren 13y ago

As a regular Vim user, I don't understand why some of these features, like Ctrl-P are not implemented natively in C, rather than to have to rely on Vimscript or Ruby plugin.

chrismorgan 13y ago
Writing things in Vimscript makes for easy and entirely reliable deployment. Ruby requires a +ruby build and Ruby to be installed, but at least avoids some of the warts of Vimscript, while still being as simple as "put it in and use it". (For myself, I'd prefer not to depend on Ruby, or even Python, though it's a much safer bet.) Any plugins in C require a compilation step before you can use it.
- seren 13y ago
  I was maybe unclear, but I was regretting that a fuzzy find for opening files was not part of the vim core. It seems to be a generic editor feature that could benefit everyone.

bgar 13y ago

First of all, you have to dump Janus. It is bad for you. Learn to use stock Vim and gradually integrate plugins as needed. I recommend NeoBundle to manage them, as it is able to compile plugins if required. I've been using vim for years and the only plugins I use are vim-airline[1] and vim-bufferline[2]. Of course, my editing needs may not be as complex as yours, but in reality most things you think you need a plugin for can be done with plain Vim. Feel free to check out my humble .vimrc[3] for some inspiration. 1: https://github.com/bling/vim-airline https://github.com/bling/vim-airline 2: https://github.com/bling/vim-bufferline https://github.com/bling/vim-bufferline 3: https://github.com/wolfcore/air-dotfiles/blob/master/.vimrc https://github.com/wolfcore/air-dotfiles/blob/master/.vimrc

icambron 13y ago
That may well be good advice, but it doesn't really solve the other problems he's complaining about, right?
- bgar 13y ago
  No, but it's a good start.

icambron 13y ago

Yes! With the exception of item #5 and #6, I really strongly agree with these items. Vim's automatic indenting, in particular, just seems systematically broken. On 5, ctl-p works great for me. I have it set up to use git in choosing what to ignore and it's plenty fast. On 6, I probably just don't know any better.

chatman 13y ago

Using vi is not bad, its a "penance". Emacs is the real editor! So says Richard Stallman. :-)

markeganfuller 13y ago
Normally I'd respect something RMS said and I love him for his conviction but on this we must disagree :)
- chatman 13y ago
  And he himself makes these remarks in a cool and snarky style, his usual humorous self. It is never emacs vs. vi war for him. :-)

blumkvist 13y ago

sublime, bruh

stormbrew 13y ago

Kinda sounds like this person just wants Sublime to me.

n1c 13y ago
Yeah; I use Sublime in vintage mode and I think it has all those bases covered.

djur 13y ago

The reason there's no project-wide find and replace in vim is that vim has no concept of a project. It's designed to be one of many tools, which works really well for some workflows and not for others. #5 is the same deal -- they're limited by the design of vim, and that design doesn't fit anything like TextMate's project search. It would drive me _crazy_ if vim saved without me telling it to. I think a lot of people suffer needlessly trying to make vim be what they want it to be, when it never is going to meet their expectations. You'd be better off trying to get those things you find useful about vim implemented in TextMate or Sublime than the reverse.

jessedhillon 13y ago
The only thing that drives me crazy about the save/do-you-want-to-reload prompt is actually a git related issue. When you commit, git updates all committed files in some way that triggers vim change detection. You go back to vim, write some code, try to save and then you get this DANGER WILL ROBINSON message. It's horrible because you're not quite sure sometimes if there was a legitimate change made in another process that you're now about to undo. Half the time I end up copying the lines I know I added, allowing a reload, and then pasting them back in, just to be safe.
- aidos 13y ago
  Really? That sounds misconfigured and it certainly doesn't happen for me. Are you on windows? Maybe it's just a problem there. I'd take a look a bit deeper to see if I could figure that out if I were you as it does sound like a nuisance. Personally (regarding the original gripe in the post) I'd be horrified if my text editor was silently ignoring edits or just updating the code under me. If that was really a concern while I was working on my software I'd take a look at the workflow to see what could be done about it.
- heurist 13y ago
  gitattributes or autoclrf could do that if not configured properly. I never have that issue when working on personal projects using vim and git.
- 13y ago

gabemart 13y ago

The issue of soft-wrapping text drives me nuts, not just with editors like vim but with programming-focused tools that can edit text in general. Github is terrible for this. Why isn't it possible to enable soft-wraps when viewing diffs? Hard-wrapping the text is not always a solution because it makes the text so much less versatile in terms of what you can do with it, unless you're willing to periodically remove the hard-wraps when you want to move the text somewhere else. Using markdown is not a solution because markdown is destructive; it eats blank lines and indentation.

djur 13y ago
A programmer's text editor and a word processor have much different requirements and should be different tools. There are much better options than vim to author formatted documents.

IanCal 13y ago

1) Dump Janus, add the plugins you actually want 2) True 3) :set paste 4) Then wrap it in a function 5) I've always found ctrl-p to be snappy actually. You can replace the matcher with ag or similar > write the Vim configuration lines required to cause those files to be ignored. You have got to be kidding me. Write a small amount of config once per project? It's no more complex than adding things to a UI set wildignore+=*/tmp/*,*.so,*.swp,*.zip 6) No, vim can't, but plugins can. Ctrl-p has this feature (http://superuser.com/questions/390011/fuzzy-find-within-file-in-vim http://superuser.com/questions/390011/fuzzy-find-within-file...) 7) Stop just navigating with j and k. > After reading this list, feel free to tell me how I'm doing it wrong on twitter. You're not googling anything to find out the answer? Also, because occasionally people haven't heard of it, get Gundo. http://sjl.bitbucket.org/gundo.vim/ http://sjl.bitbucket.org/gundo.vim/ Vim has a full tree undo, gundo makes it easy to navigate and see diffs between changes in code.

maaaats 13y ago
But that's kinda the problem with vim. Having a sane configuration takes hours of setup and googling.
- aidos 13y ago
  That's only the first time. It's a completely different paradigm and you have to learn it. Once you've learnt it this entire list is a non-issue. Not only that - configure it as you want, then take that config with you to every other machine that you ever use - surely that's worth the effort.
- IanCal 13y ago
  It starts with a sane configuration, the problem is when you want to add loads of features you have to spend a small amount of time adding them. The alternative is to have a fucking insane amount of functionality present to begin with because everyone wants something slightly different.
- klibertp 13y ago
  Depending on how you define "sane" it can be months. Vim is said to be a programming language for text editing - I wouldn't expect anything less of a complexity from a thing like this. I recently learned Emacs and it took me two months - that short because I already went through the process with vim some years ago - to learn it and configure it to my liking. My Emacs config counts 983 lines with comments and whitespaces removed[1]. My .vimrc was shorter, but mainly because I dislike vimscript and like Lisps. [1] cat .emacs.d/config/*.el | egrep -v '^$' | egrep -v '^;;' | wc -l

m2mdas 13y ago

Pasting the reply I gave in r/vim Answer to some of the points, Janus: There are divided opinions in vim community about whether distributions should be used or not. I am on the latter side. But still for just checking out I installed Janus a while ago. Yes it is slow, but it turns out that it is as slow as my then `.vimrc` configuration. I tried to track down the problem. It is because of vim's blocking behaviour during executing external commands. When you write a buffer or switch to a buffer, syntastic, tagbar, powerline statusline, gitgutter, bufexplorer all execute external command. Vim becomes more slow when `.git` repository grow larger or when saving a large file. So how do you solve the problem? Remove those plugins and install Unite.vim[1] with vimproc[2] asynchronous library. Files that change: If you do external edits more frequently then I think it is time to rethink your work-flow. I think there is a common consensus that you should not run live edit in server. * Indenting pastes* : There is a plugin for that [3] ? * Opening files inside my project : Last I checked command-t was damn fast, don't know where slowness comes form. Another alternative is `Unite.vim` `file/async` source. It is fast at finding files but goes slow while doing ignore-pattern checking. Without the checking it is DAMN FAST. The `phpcomplete/files` source I created for my php autocomplete plugin[4] easily list 4000+ files in seconds. If you want to list files obeying the patterns in the '.gitignore' or '.hgignore' files. Checkout my unite-file-vcs[4] plugin. It adds a `file/vcs` source that lists files by issuing `git ls-files` or `hg status -c -m -u` command for `git` or `mercurial` projects respectively. Navigating inside files*: Checkout unite-outline[6]. It shows live output by parsing the current buffer. Unite.vim required. But it does not support css files right now. Adding support should be easy. So the summary of the story. Move to `unite.vim` and friends ;) [1] https://github.com/Shougo/unite.vim/ https://github.com/Shougo/unite.vim/ [2] https://github.com/Shougo/vimproc.vim https://github.com/Shougo/vimproc.vim [3] https://github.com/sickill/vim-pasta https://github.com/sickill/vim-pasta [4] https://github.com/m2mdas/phpcomplete-extended https://github.com/m2mdas/phpcomplete-extended [5] https://github.com/m2mdas/unite-file-vcs https://github.com/m2mdas/unite-file-vcs [6] https://github.com/Shougo/unite-outline https://github.com/Shougo/unite-outline

regularfry 13y ago
> Files that change: If you do external edits more frequently then I think it is time to rethink your work-flow. I think there is a common consensus that you should not run live edit in server. It's possible this isn't what you meant, but external edits do not imply editing code live on a server.

rvijapurapu 13y ago

Patience my dear friend, patience. I have been using Vim as my editor of choice for over a decade, I think I barely use 10% of its features. Your configuration is always evolving - so don't fret if a plugin or a setting is not working for you, it just means its gotto go.. That said focus on `your productivity` over a religious choice of an editor. You actually got to live with it for decades to come. choose the right one which fits your use case.

Gonzih 13y ago

I prefer Unite.vim over Ctrl-P since it can be used more than for file matching. But yes, you need to spend some time to configure it.

bpizzi 13y ago

> I've been using it full-time for just over three months now. That's it: you just need to give it more time. One simply can't expect to fully climb vim's learning curve in just a quarter of a year. Your brain can't adapt so rapidly to so much new shortcuts. > Jump to CSS selector. Jump to class. Fuzzy string matching. All these things and more are what I am used to. Vim just can't do them. That's one example among others: there's vim's marking system for that, and your brain isn't just used to it now. You find it slow, broken and not user-friendly, but it's not really, it's just that you need to give it time to master it. My 2c advice: it you really want to like it, keep going and give it a full year. If you think you can't give it more time, then Vim isn't for you and some commercial editors might do it. I've been there, I know your current feeling. I'm a happy vimmer now but it hasn't been the case for something like a year. There's a reward for real vimmers: you'll never need to switch anymore to another editor, because Vim is there, powerfull, opensource, free, multi-plateform, and you know how to use it smoothly.

pestaa 13y ago
I like the spirit, but how will Vim's marking system help me jump to a CSS selector in an unbuffered stylesheet? I'm really curious; missing this feature from heavyweight IDEs.
- bpizzi 13y ago
  Been there also. _My_ solution was not to rely anymore on stuff provided by a heavyweight IDE. "Jumping to somewhere in an unbuffered file according to where I am in the current buffer", that is actually depending on a background worker that knows a very specific set of rules and use it to constantly cycle threw the filesystem. Which bg process is usually provided by tanks like Eclipse. With the time I've found something that matches that behavior without the payload on the computer, and guess what, it's my brain. I'm no more in pain of jumping to the definition of a css rule, because I know which css file I have to invoke and I can do it _very_ quickly thanks to Control+P, and jumping to the definition is a matter of one or two "/". Of course you need to organize things smartly in your project if you ever want to do that without too much thinking time, but hell, I count that on the bright side of this solution.

ranza 13y ago

I feel his pain! Especially the paste thing. I've been back and forth with vim for as long as i can remember. Finally decided to switch to Sublime on my desktop and keep a stripped down version of vim for my terminal needs. I feel like Janus is doing more wrong then good. If you want to get into the mindset of vim you should ditch Janus.

regularfry 13y ago

Why limit yourself to a single editor? They're different tools, good at different things. It's really not that hard to learn, for instance, both emacs and vim. I've got both open right now!

daGrevis 13y ago

If anyone is looking for sane configuration — vim-sensible is the thing you are looking for! https://github.com/tpope/vim-sensible https://github.com/tpope/vim-sensible

DH61AG 13y ago

The only problem with Vim is that you need to learn it. If it's too hard for you then there is plenty of other editors.

jfe 13y ago

Time to get out of your two-editor bubble, folks; there are other options. In my opinion, Acme puts both Emacs and Vim to shame.