All right, I think I'll stop here. Parsing the -U0 ranges in raw C++ is gonna be too much wasted effort. I'll finish this another time, likely after switching to Go.
For historical reasons, mainly. If I were starting from scratch today, I wouldn't pick it. I'm in the process of making a change to golang, but I want to use the existing project to develop the next-gen version. There's only a few more things I need to add to make it viable for working on a large-scale project.
I started the project a year ago. I wanted to have the power and flexibility to achieve anything, and use OpenGL for graphics so there'd be no restrictions as to what can be put on screen. Plus I've been using C++ for many years before for making indie games.
Back then, I was even more motivated to work on it because I felt C++ itself badly needed a more efficient way or writing it. I really dislike the manual duplication it forces you to create and maintain as you change things (e.g. cpp and header files). But even with a more script-like high level language like Go, I feel there is a lot of potential to innovate past a basic text editor. I'm gonna find out.
Relatedly, noble cause with your IDE project, here's hoping you run into wonderful things (alas, I can't code C++ and VimL serves me fine for my current extension needs)
Not to take away from the post, anyone else feeling a bit of Vim overload in the past few days? I'm pretty much Vim'ed out with all the Vim related postings.
I don't really understand what you mean. People submit vim-related content, which then gets upvoted and brought to everyone's attention on Hacker News.
It might just be that it actually reflects people's interests.
Given how established vim and emacs are, I have to say I'm not surprised, they remain extremely versatile and complete developing environments to this day.
I actually use Vim. I don't have any issues with it. I do agree with you that it's a great tool.
Just pointing out that lately there has been a lot of Vim related posts that are being up-voted. Maybe that's been the case for a while, and I am just noticing it.
Anyway, my comment was meant more as a light humour rather than critical.
This is really nice, but I wish the background color of the gutter would automatically match the rest of my background. The gray band [1] is pretty unappealing IMO.
Also noteworthy is that that the gutter only updates when the file is saved.
Alternatively, using `hi! link SignColumn LineNr` will ensure that styling the user has applied to the more commonly used line numbering column will match the sign column used by vim-gitgutter.
I hate it when plugins try to override my colorscheme, so I would highly discourage adding this to the plugin. To account for colorschemes that don't add colors for SignColumn without angering users, use the `default` keyword without the bang.
Some other things to consider: The sign column and line numbers are separated by the fold column. The default colorscheme has SignColumn and FoldColumn the same (Cyan or DarkBlue on Grey) and different from LineNr (Yellow or Brown).
AFAICT, this was technique advice specifically relevant to the parent post, the ongoing thread, and to improving folks experience with the tool in original post. To the anonymous downvoter: I give up. I have no idea what message you were trying to send.
I've added it at the bottom of ~/.vimrc, but for some reason it doesn't work until I explicitly type `highlight clear SignColumn` while editing a document. Any ideas why this could be happening?
I experimented a bit more and found if I put it before my "syntax on" and color scheme setup lines it doesn't work, but if I put it after them the fix works. Raticide's comment clued me in.
I've also got a similar plugin https://bitbucket.org/sirpengi/iwilldiffer that works with hg as well as git. Mine uses python though, nice to see an implementation that's all in viml. Neither of our plugins are async though (so vim ui will block while the diff is running), which is the biggest hurdle I want to cross.
That's neither here not there. You have plenty of things which are single threaded but allow concurrency (Twisted, NodeJS...). That it does not have an asynchronous API is something different.
Yes, but there is a way to work around that with a ton of hacks (by spawning a separate process, and polling CursorHold events). See https://github.com/troydm/shellasync.vim and a bunch of linting plugins do this too (but I can't remember them off the top of my head).
Or you could, e.g., use the Lua scripting extension, load one of the native threading libraries for Lua (Lua Lanes, for example) and fire away a few background tasks. Whatever actions the background tasks need to perform with the buffers you'd have to serialize, but that shouldn't be all that difficult.
So long as any plugin script is running, vim will block waiting for it. And if you fire off a background process and exit from your main script, any reference to the vim environment within your child process becomes useless, so you can't modify anything in vim from within there anymore. I'm not entirely familiar with the lua scripting extension, but this was my experience attempting the same thing in python. I mean, at the end of it, vim is single threaded, and after your primary script exits its state is being used elsewhere - if you could modify it from your child process that'd be major cause for crashage.
That and who has lua on their system (I mean, i do for Love but that's irrelevant) or wants to install it just to use a git/hg plugin?
Eclipse pretty much does this out of the box. I guess so do IntelliJ and Visual Studio. You can also display the name of the last person to change a line in the same position (ie. svn/git blame), which is very useful to quickly find out who to talk to regarding a section of a file. The commit message is displayed on mouseover.
Yes, IntelliJ handles this pretty nicely. For modified lines, you can mouse over to see what you changed. For all changes, you can click a context menu to revert any given change. (Of course, that does require touching a mouse... though I believe you can set up a key mapping for it.)
In the Sublime version, one of the things I did to avoid that is it doesn't call `git diff` if it has been less then 5 seconds since the last `git diff`.
Is there any way to make it so that the gutter is always present? There's a bit of a noticeable jump to include it when I save a file, it's sort of annoying me.
probably not, the way vim works if there are no more signs attached to a document the gutter goes away. This isn't plugin related, it's just a manner of how vim works.
Although I suppose you can work around this by displaying a fake sign (color match gutter background?), but that has its downsides (depending on colorscheme, the sign can show up. and vim doesn't support whitespace characters for signs, at least not from what I can see).
I wish it could be made to stand on the right side of a vim buffer. This way it would still be present on demand but would not shift the whole buffer one column to the right.
Maybe because there are more vim users than sublime users on hn? FWIW i did see that story on front-page of hn and it's what prompted me to immediately write my vim-port. I finished it like a few days after that.
An aside question; what's the deal with "pathogen"?
I've been using the "/bin/cp" command for years installing vim plugins and it's worked remarkably well; requiring just about 1 invocation on average...
If you decide you no longer want a particular plugin, or want to upgrade it, it can be hard to tease out the files you /bin/cp'd into place. Adding a single folder under bundle makes removal easier later.
ETA: also note that git-cloning into bundle means that upgrading is just a question of entering the plugin directory and running git pull.
Each plugin resides in it's own directory, rather than being scattered around your .vim dir. Try to remove one of your installed plugins, you'll have to dig around and it'll be messy.
Also it makes it easier to update, since all you need to do is replace the folder with the newer version and you're all set.
To elaborate on the response others have offered about everything being in one folder, I'll further note that it allows you to keep track of the plugin through git, so you can very easily grab updates when desired.
Why git? I store my .vim directory in dropbox and just have it symlinked into my home directory on each of my machines. I don't really see a need for version control, and I don't want to have to do anything to make sure a change on one machine is reflected on all the others.
It lets you put your various vim things inside a single 'bundle' directory instead of having files in plugin/ftplugin and whatnot. Very convenient and easy to setup.
Figured as much. I would argue for/request forking that "git diff" command and only processing its output in the VIM process, but for the moment I'll stick with my trusty ",gd" command:
I'm really impressed with this -- I would love to see this see functionality for other VCSes (subversion, etc) so that I could use it with my non-git projects. The vimscript looks pretty clean -- maybe I have a new weekend project ahead of me.
Thank you! I wasn't aware that these plugins existed already. While I was getting excited to get my "vim -D" on to get the script in the OP to work with svn, I might just work one of these plugins into my workflow.
Any way to bind "toggle the gutter" so I can press my "set nonumber" button and have it toggle the gutter as well? [edit] Apparently I didn't read down far enough! This functionality exists already through the plugin. This works for me: nnoremap <F2> :set nonumber! <bar> ToggleGitGutter<CR>
I find it really useful in particular for working with Mercurial patch queues. I have a command in my .vimrc that will run ReversePatchReview on the topmost patch in my patch queue. It pops up a diff tab for each file that has changed. I can easily use "[c" and "]c" to jump between changes within each file.
This setup makes it incredibly easy to review the changes a patch makes, and it's so convenient that I often write quite a bit of my code inside these diff views. I don't think I could live without vim-patchreview when working with Mercurial.
Awesome work! Cheers airblade. One nitpicky thing though, why do you use "_" and not "-" for removed lines? Can't see why you wouldn't want it vertically centered!
I honestly like vim fugitive because of it's awesome power. I just type ,gd to see a diff in a split. I probably don't want to scan the gutter for files i've changed, and fugitive diff folds all non-changed lines
also, who the hell sets their font size that small? (screenshot in the readme). that's a sociopathically small font size. I will never trust you airblade. never.
I use both. If I need a full diff, fugitive is great. Sometimes I just want to scan to see what lines I changed in a a file. In other words, it is impractical to use this plugin to find out what _files_ you've changed. It is great for finding out what lines in whatever file you've opened have changed.
No. You you do your thing. I'll do this. I don't want to have to run another command to see what lines have changed in my file. I want small, non-intrusive icons in the gutter without doing a damned thing.
