I needed this feature at work today, and it seemed like it would be simple enough to add, so after I got home I decided to give it a shot.
Basically, what this does is add a new option called diffbuf (short name dbuf) which defaults to 0 (meaning standard behavior) but can also be set to a buffer number. If it's set to a valid buffer number, then instead of highlighting all the lines that any buffer has different, it will only highlight lines that that specific buffer has different. That is, for the purpose of highlighting lines, it will be as if the buffer whose lines are to be highlighted and the buffer specified by diffbuf are the only buffers open; others won't affect it, beyond adding filler lines if that option is turned on.
Lines inside the buffer specified by diffbuf will be highlighted as normal.
This is my first contribution to this project—or any project as popular as Vim, for that matter—so please forgive me if I did anything incorrectly.
https://github.com/vim/vim/pull/3527
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
@flarn2006 pushed 1 commit.
—
You are receiving this because you are subscribed to this thread.
I think Vim already has what you want to do.
See the following document.
:h diffthis
Example:
- Start Vim without specifying a file name.
$ vim
- Edit the buffer appropriately. Here we set numbers on each line.
:call setline(1, range(0,9))
- Open new buffer in split vertically
:vnew
- Edit the buffer appropriately.
:call setline(1, range(3,6))
- Highlight difference between two buffers.
:windo diffthis
--
Best regards,
Hirohito Higashi (h_east)
There is a reply from @h-east at here: https://groups.google.com/d/msg/vim_dev/9CwgjallJDg/4A8Gi7xVBgAJ
@flarn2006 pushed 2 commits.
—
You are receiving this because you are subscribed to this thread.
@k-takata, I replied to you on Google Groups; just making sure you saw.
Also, I noticed a case just now where it isn't working properly. But I'm at work so I'll look into fixing that when I get home.
Please add a screenshot or two, so that we can see how this works. Also, please add the help for this option, which a good explanation (can't add a screenshot in the help).
@brammool Will do. I'll also take a look at the part where it wasn't working and try and fix that.
Screenshots added. Will add help next.
Also, Gary Johnson posted in the Google Group:
If this turns out to be something useful and worth including in Vim,
I think we really need to come up with some better method of
invoking it than setting the value of an option to a buffer number.I don't understand what this does well enough to suggest a name, but
I think some command like :diffref that sets the current buffer as
the reference buffer, or whatever 'diffbuf' means, would be much
better than requiring the user to figure out the number of the
buffer of interest, then setting some option to it. Further, an
option value will hang around and confuse the user the next time
they execute :diffthis.
That's a good point. Maybe keep the option though, and just add a command to set it to the current buffer, because potentially it can also be extended in the future to support a list of multiple buffers to compare against.
Actually, I think I'm going to change it to be a per-buffer option, diffignore/nodiffignore or something, defaulting to nodiffignore. Or alternatively diffref/nodiffref, defaulting to diffref.
--
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subscribed to a topic in the Google Groups "vim_dev" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/vim_dev/9CwgjallJDg/unsubscribe.
To unsubscribe from this group and all its topics, send an email to vim_dev+u...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
You received this message because you are subscribed to the Google Groups "vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+u...@googlegroups.com.
Sure, so basically diffref from my suggestion above only it automatically turns off on all other other buffers when you set it on one?
I'll create a separate pull request when I'm ready; let me know if that sounds good.
Reminds me of an old feature request: Humble feature request: 3way-merge diff mode .
—
You are receiving this because you commented.
—
You are receiving this because you commented.
How about I do it like I said before, calling it diffref instead of diffmaster and having it be on by default and settable on multiple buffers at once, but then I also add diffmaster as a command that turns it on for the current buffer and off for all others? That way it's just as easy as before to use it for that most common use case of only comparing with a single buffer, but at the same time if someone does ever get the need to turn it on for multiple (but not all) buffers, they can do that too? From my understanding of the way it's coded, it would be no more difficult than only allowing a single master (actually less difficult because I won't need to have it check other buffers when you set the variable) so it would be a shame to explicitly remove that functionality if there's another way to get the ease of use it would bring.
Also you know the code a lot more than I do, but I'm pretty sure it actually would be a buffer option, not a window option. It's the buffer that it compares against. If two windows have the same buffer, what difference would it make which of the two is set as the master? The diff option is window-specific because it's specific to the way that window is treated, but the diffref or diffmaster option, whatever it's called, doesn't really involve the window; it just tells other windows whether or not to reference the buffer inside.
—
You are receiving this because you commented.
Ah, good point. Window option it is. I'm going to close this pull request and open a new one when it's ready.
—
You are receiving this because you commented.
Since I'm not going to use this code (and shouldn't have used the master branch for it) I'm going to change history in my fork and put the master branch back to the official one. I've created a separate branch in my fork, pullreq3527, to hold these changes that aren't going to be use, since I'm not sure how this will affect the pull request.
—
You are receiving this because you commented.
—
--
—
You are receiving this because you are subscribed to this thread.