Re: Feature request: Better way to handle SCM blame/annotate syntax highlighting
On Jan 26, 9:30 am, Ted Pavlic t...@tedpavlic.com wrote: That is, an output of git blame myfile.c | vim - would get highlighted so that the left side of the blame output was highlighted matching git blame rules, and the right side of the blame output would use standard highlighting rules for c. While it is possible in some cases to highlight certain areas of a file using rules for a different filetype (http://vim.wikia.com/wiki/ Different_syntax_highlighting_within_regions_of_a_file) what you are asking is currently not possible in Vim. Syntax highlighting works using regular expressions, often spanning multiple lines. You would need to somehow force Vim to skip over the left side when applying the rules and highlighting to the right, and the same for the left. Modifying syntax rules to accomplish this for specific cases might be possible, but really isn't feasible. To include blame rules in the filetype for the base file, you could modify the syntax rules of every possible filetype you're going to be using blame on, adding regions for the blame output that can be contained in every multi-line syntax group. You'd also need to change any rules that match the beginning of a line. This would be a never-ending task, and wouldn't really be very maintainable. It might not even be possible for some syntax rules without a wholesale rewrite. The opposite approach, including basic file types in the blame syntax rules, would be even more daunting. You would somehow need to duplicate or apply the rules for multi-line matches in the file within the single-line matches of the blame output. All this being said, you could probably make some sort of plugin to get functionality similar to what you want. After reading in the blame output, you could fairly easily split the file into a left and right window, with the left window containing only the blame output and the right containing only the un-annotated file. Set filetypes in each window appropriately, set scrollbind, and you're basically done. This method could even be generalized to fit _any_ blame output and _any_ base file type. It would rely on a simple regex to recognize where the blame output ends and a line in the file starts. Obviously you'd want several blame types built in, but simply allowing a custom regex would make it infinitely extensible. Perhaps there is even a plugin that does this already? --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: Feature request: Better way to handle SCM blame/annotate syntax highlighting
On 26-Jan-09 16:30, Ted Pavlic wrote: There are several syntax highlighting options available for SCM blame/annotate outputs (e.g., CVSAnnotate.vim, HGAnnotate.vim, etc.). However, AFAIK, none of them have the ability to use the annotate-style highlighting on the left side of the page (where all of the SCM info is) and filetype highlighting on the right side of the page. It would be nice if there was some feature that would allow something like: :set scmtype=git :set filetype=c That is, an output of git blame myfile.c | vim - would get highlighted so that the left side of the blame output was highlighted matching git blame rules, and the right side of the blame output would use standard highlighting rules for c. Then left/right autodetection would be the next nice feature... That is, Vim would have to be able to detect that it's looking at a blame/annotate-type file and then detect which SCM format to use on the left and which filetype to use on the right. I have a feeling that such a feature is non-trivial. That being said, I think the demand for such a feature is growing. Thanks -- Ted Hi Ted, You're right, such a feature would be difficult to accommodate with the current mechanism for syntax highlighting (and without duplicating and maintaining an entire suite of git-c, git-cpp, ... syntaxes). I also cannot imagine support for a new ':set scmtype' setting within VIM; after all, it is a text editor, and those SCM annotations are usually only viewed, not edited, right? However, I can imagine a quick solution that could be implemented relatively cheaply in vimscript, and might be suitable if all you want is _view_ these kinds of output. Here's a sketch: 1. Create two scratch buffers (buftype=nofile, etc), vertically split, with :set scrollbind. 2. Open the 'git blame' output in a third buffer and use e.g. blockwise Visual mode (CTRL-V) to copy-and-paste the left (git) block into the left scratch buffer, and the right (programming-language) block into the right one. 3. Close the third buffer, :set filetype=git on the left, trigger a filetype detection on the right buffer. If you put these actions in a custom command, you could prettify the output with a few keystrokes, or even use the existing filetype detection mechanism to auto-detect and auto-prettify this. Of course, it's two buffers, not one, so jumping around isn't completely natural. On the other hand, the two-buffer split may even make certain copy-paste actions easier to do. -- regards, ingo PS: Ben, just saw your reply coming in when I wanted to press send. Seems you have had the same idea?! -- -- Ingo Karkat -- /^-- /^-- /^-- /^-- /^-- /^-- http://ingo-karkat.de/ -- -- Shift happens. -- Doppler --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: Feature request: Better way to handle SCM blame/annotate syntax highlighting
On Tue, Jan 27, 2009 at 06:12:39AM -0800, Ben Fritz wrote: On Jan 26, 9:30 am, Ted Pavlic t...@tedpavlic.com wrote: That is, an output of git blame myfile.c | vim - would get highlighted so that the left side of the blame output was highlighted matching git blame rules, and the right side of the blame output would use standard highlighting rules for c. While it is possible in some cases to highlight certain areas of a file using rules for a different filetype (http://vim.wikia.com/wiki/ Different_syntax_highlighting_within_regions_of_a_file) what you are asking is currently not possible in Vim. [ ... ] All this being said, you could probably make some sort of plugin to get functionality similar to what you want. After reading in the blame output, you could fairly easily split the file into a left and right window, with the left window containing only the blame output and the right containing only the un-annotated file. Ideally, wouldn't annotate look very much like the 'number' option in terms of how it's put on the screen? They're both per-line metadata, after all. Danek --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: A branch for join_O(n) patches was: Re: [patch] Re: make joining lines O(n)
Christian Michon wrote: On Mon, Jan 26, 2009 at 9:45 PM, Milan Vancura mi...@ucw.cz wrote: 5. what about a cooperation with Christian and pul his git tree as vim_upstream? There is no dependency on svn, nice tags for vim versions are there... Would it be possible? No, it wouldn't. It looks nice at first sight, but it isn't really useful for development. Look at the branches, they each have their own root, they don't have any relation to each other. With Vim 7.3, the master branch will be rewritten from scratch. You can't merge and forward-port the feature branches to the next minor release. In fact you'd end up with a rebase of all your branches as well. It would be nice if you two agreed on some simple system good for everyone. I think that the development of vim is, from its definition (just one committer) linear. So if there were tags for each versio of vim and patches named by their number and subject, one can find everything in history easily. We don't probably need no branches for upstream vim, we need them for paralel development like patch sets of other authors etc. And with patches named with their number (and subject), we will not need so many tags... I asked Markus his requirements: his answers show a trend hard to satisfy. I also know from vim cvs the current existing linear flow. I now believe branches should be up to the local git directory: we'll never get to convince anybody that this or that specific workflow is the best. So I'm moving forward to have a linear git repo with few tags (ex: beginning of vim-7.0 and last vim-7.0). The users will be able to checkout those tags in their local repo and this will create local branches with the tag's names. Anyone against this ? If it gets enough votes, I'll use git-cvsimport I did during this weekend and make minor modifications/grafts. The result will be visible on github (I'll announce it when ready) Bram: any chance we could get your opinion on this subject ? I have no opinion on how to use git. -- How To Keep A Healthy Level Of Insanity: 8. Don't use any punctuation marks. /// Bram Moolenaar -- b...@moolenaar.net -- http://www.Moolenaar.net \\\ ///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\ \\\download, build and distribute -- http://www.A-A-P.org/// \\\help me help AIDS victims -- http://ICCF-Holland.org/// --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: description of CTRL-W = in index.txt
Chris Littell wrote: In the help file index.txt, the description for CTRL-W = should mention that it also makes window widths equal. Right now it looks like there is no command to do this until you see the detailed description. I'll make it: make all windows the same height width -- How To Keep A Healthy Level Of Insanity: 9. As often as possible, skip rather than walk. /// Bram Moolenaar -- b...@moolenaar.net -- http://www.Moolenaar.net \\\ ///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\ \\\download, build and distribute -- http://www.A-A-P.org/// \\\help me help AIDS victims -- http://ICCF-Holland.org/// --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: description of CTRL-W = in index.txt
Bram Moolenaar wrote: Chris Littell wrote: In the help file index.txt, the description for CTRL-W = should mention that it also makes window widths equal. Right now it looks like there is no command to do this until you see the detailed description. I'll make it: make all windows the same height width How about: make all windows the same size ~Matt --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: description of CTRL-W = in index.txt
I'll make it: make all windows the same height width How about: make all windows the same size FWIW, I prefer 'height width'. Neither is strictly correct of course; consider any three window layout which is a mix of horizontal and vertical splits. Ben. --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
