sublime, bruh
Vim is the worst editor, except all the other editors
11–20 of 145 posts
Re: Vim is the worst editor, except all the other editors
#12Kinda sounds like this person just wants Sublime to me.
Re: Vim is the worst editor, except all the other editors
#13> 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 par…
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.
Re: Vim is the worst editor, except all the other editors
#14The 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.
Re: Vim is the worst editor, except all the other editors
#15The 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.
Re: Vim is the worst editor, except all the other editors
#16Using vi is not bad, its a "penance". Emacs is the real editor! So says Richard Stallman. :-)
Normally I'd respect something RMS said and I love him for his conviction but on this we must disagree :)
Re: Vim is the worst editor, except all the other editors
#17The 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…
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.
Re: Vim is the worst editor, except all the other editors
#181) 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
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/
Vim has a full tree undo, gundo makes it easy to navigate and see diffs between changes in code.
Re: Vim is the worst editor, except all the other editors
#19The 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…
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.
Re: Vim is the worst editor, except all the other editors
#20Pasting 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/
[2] https://github.com/Shougo/vimproc.vim
[3] https://github.com/sickill/vim-pasta
[4] https://github.com/m2mdas/phpcomplete-extended