Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Highlight differences on a changed line #32

Closed
ipkiss42 opened this issue Jun 22, 2013 · 16 comments
Closed

Highlight differences on a changed line #32

ipkiss42 opened this issue Jun 22, 2013 · 16 comments

Comments

@ipkiss42
Copy link

When the diff highlighting is on, it would be great to see the modified part of a changed line with a special highlighting, just like with a standard vimdiff (or like :Gdiff, in the fugitive plugin). At the moment you know that something has changed, but you don't know what exactly.

@mhinz
Copy link
Owner

mhinz commented Jun 23, 2013

I'm not sure I want that feature for Sy. It would makethe sign drawing 3 times as slow for modified lines since you have to grep 2 more lines from the diff output. And that's no even counting in the overhead of comparing 2 lines for differences and using regular expressions to show these.

I'll note it for the 2.0 release anyway. When I can come up with another way I'm satisfied with I'll add it (but disabled by default).

Thanks for the feedback!

@mhinz mhinz closed this as completed Jun 23, 2013
@ipkiss42
Copy link
Author

I don't think there would be any noticeable performance impact:

  • the diff output is already in memory
  • vim's regular expressions engine is very fast (syntax highlighting is based on regexp...)
  • there is no need to use a complex comparison algorithm: you can do like vimdiff, which highlights at most one part of the line (the part of the string after the common prefix and before the common suffix)

The feature can be disabled by default, that's fine with me.

Any ETA for Sy 2.0?

@mhinz
Copy link
Owner

mhinz commented Jun 25, 2013

Au contraire, Vim's regular expressions are known to be pretty slow. (Lots of discussions about this on vim-dev@). That's why they added a second engine. If you have a recent enough version, see :h 're'.

I'll have a look at some other plugins to see how they do it.

There's no real ETA, but it won't be a monster release either. I still have some things on my TODO, will commit them one after the other, and when I'm satisfied, I'll tag it as 2.0 and set up a github page with a "Guide to Signify". (I think 2~3 weeks).

@mhinz
Copy link
Owner

mhinz commented Jun 25, 2013

Okay, I'll include it.

But in the next days I'll push 1.9 first, which will be the first release, that isn't backwards-compatible, since it's removes a lot of the complicated color control mess. It will be replaced by simple custom color groups.

@ipkiss42
Copy link
Author

That's great news, I'm looking forward to it!

@mhinz
Copy link
Owner

mhinz commented Oct 24, 2013

Current status: I yet have to find a solution that doesn't have a huge impact on performance. So unless someone else comes up with a nice solution, we won't get this feature.

@ipkiss42
Copy link
Author

I don't understand where the "huge performance impact" would come from. The :Gdiff command (from the fugitive plugin) already does that. Do you think it is slow?

The difference here is that you wouldn't use vimdiff. But you've already done the difficult part (identify which lines are added, removed and changed). To highlight the changes, why not doing something as simple as what vimdiff does? As explained above, it considers that there is at most one change per line, and that the change spans from the first modified character to the last modified character (even if all the characters in between are the same). This is quite straightforward, you wouldn't even need to use regular expressions for that.

@justinmk
Copy link

justinmk commented Nov 3, 2013

@ipkiss42 :Gdiff doesn't do anything except feed a diff to vimdiff. Anyways, it sounds like you just want vimdiff except without a split. Right?

@mhinz
Copy link
Owner

mhinz commented Nov 3, 2013

I guess so. "vimdiff" is really just a collection of certain options. One would have to add an extra system() for getting the file version from the last commit; open it; set diff options; hide the buffer in the background; open target file with or without changes; set diff options; run :diffupdate at certain events.

This all is probably fast enough to be added, optionally. Too bad that you can't get info about changed lines from diffing buffers, ohterwise I could remove all the hunk parsing code which would result in a much faster plugin.

@ipkiss42
Copy link
Author

ipkiss42 commented Nov 8, 2013

@justinmk I want vimdiff-like highlighting, but I don't care if it's actually implemented using vimdiff itself, or emulated by comparing lines "manually".
In this case, I don't see why you would want to go the vimdiff way: if you know that a line has changed, it seems quite easy to compare the current and original versions. Using vimdiff as a backend sounds more painful to do. But maybe I have an over-simplified vision, since I don't know how the plugin is implemented...

@justinmk
Copy link

justinmk commented Nov 8, 2013

@ipkiss42 Well, I mean to imply that you can already get what you are asking for by simply invoking vimdiff and hiding the split.

@ipkiss42
Copy link
Author

ipkiss42 commented Nov 8, 2013

Yes, but if I wanted that, I would call :Gdiff :)
The nice thing with Signify is that it doesn't require any action from the user.

@mhinz
Copy link
Owner

mhinz commented Nov 9, 2013

Well, I'd prefer the vimdiff version, because it handles a lot by itself (using C instead of VimL) and doesn't bloat the plugin as much. The only annoying thing would be that there will always be a hidden buffer in :ls, when this option gets enabled. This might upset some people using plugins that list all buffers all the time (either in tabline or statusline).

@ipkiss42
Copy link
Author

ipkiss42 commented Nov 9, 2013

:h 'buflisted'

@mhinz
Copy link
Owner

mhinz commented Nov 9, 2013

Yea, I'm working at a git version right now and commit it to a new branch.

EDIT: So it's kind of working in my local copy. I'll try to polish it in the next time.

@mhinz
Copy link
Owner

mhinz commented Oct 7, 2014

Further discussion: #120

@mhinz mhinz closed this as completed Oct 7, 2014
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants