Highlight differences on a changed line

[mhinz]

Highlight differences on a changed line

[mhinz]

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!

[ipkiss42]

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]

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]

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]

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

[mhinz]

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]

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]

@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]

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]

@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]

@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]

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]

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]

:h 'buflisted'

[mhinz]

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]

Further discussion: #120