Add a set of "staged change" faces

[PythonNut]

I don't know how vc-system specific you want to get, but I think it would be great if there was some way to tell if a given hunk is staged or not.

I would try adding this myself, but I don't currently understand vc.el well enough to contribute.

[dgutov]

Basically, VC doesn't have a notion of staged hunks.

That would have to be implemented first, and then we'd also have to find a way to get the info about staged and unstaged hunks in one process call. Don't want to do it twice, right?

IOW, probably not going to happen soon.

[PythonNut]

git specific diffs are understood by diff-git.el from ELPA, although I'm not aware (on the git side) of a way to get both kinds of differences in one process call.

Should I leave this open?

[dgutov]

git specific diffs are understood by diff-git.el from ELPA

Which archive do you mean? It's not in GNU ELPA.

I'm not aware (on the git side) of a way to get both kinds of differences in one process call

Well, it would be good, but maybe not essential. CPU and disks are getting faster, etc... But it'll be much more useful if/when VC implements staging operations.

Should I leave this open?

Sure.

[PythonNut]

Is it in the Tromey ELPA?

I think that you can blast out enough of git's on disk format to construct both diffs in a single process, but that probably won't be any faster. I'd expect git to be better at collecting its own data than emacs, although I could be wrong (really high disk overhead, perhaps?).

diff-git can also stage/unstage hunks.

[dgutov]

Right, Tromey's ELPA is deprecated, though. I don't even have it set up. There's that package: https://github.com/alanfalloon/diff-git.el

So, I'd look at a patch, provided the author there is open to signing over its copyright to FSF (and get rid of the Magit dependency, which shouldn't be too hard), but putting this functionality into VC first would be better.

[dgutov]

Hmm, I think we can get the "staged" changes by binding vc-git-diff-switches to ("-U0" "--cached").

Then the question becomes, how to display them. There's not much place on the fringe. Just use different faces? Which ones?

[PythonNut]

I was thinking lighter, or otherwise more prominent variations of the regular diff faces. Is git the only system with the concept of staging?

[dgutov]

I was thinking lighter, or otherwise more prominent variations of the regular diff faces.

It would be best if we could pick some of the default faces, included in Emacs.

Is git the only system with the concept of staging?

Apparently so: http://mercurial.selenic.com/wiki/GitConcepts#Git.27s_staging_area

[PythonNut]

The problem, I suspect, with that is that most color schemes do not define six faces (three lighter/darker pairs). Solarized certainly doesn't.

Most of the faces included in Emacs will be defined in terms of the colors the color scheme provides, which is not enough.

[dgutov]

The fringe bitmaps also can have some variation. Thicker lines, for instance.

[PythonNut]

That would be awesome.

What of diff-hl-margin-mode, though? Perhaps we can use a different letter.

[dgutov]

We can use two characters, similarly to the first column in the git status --short output.

[noctuid]

How much work would this take to implement? This is the main thing keeping me from using diff-hl.

[dgutov]

How much work would this take to implement?

Some.

And as long as VC doesn't help with staging, this feature wouldn't help me much, personally. So the code will most likely have to be written by someone else.

[dgutov]

Even if we do get both diffs, and choose appropriate faces, what do we show on the lines that have changes both inside the staging area, and in the working directory on top of that?

What I wouldn't want to do is copy emacs-git-gutter and use two columns (uses too much space, don't like how it looks; no idea how to do it in the fringe). Are there any examples of other editors showing both as well?

[noctuid]

I didn't know that git gutter could even use two columns for that. My current setup with git gutter just compares a line with what is staged or the last commit if nothing has been staged. If there are no changes for a line or if it matches what is in the staging area, nothing is shown. If the line does not match what is in the staging area, it shows up as a change. I don't have any suggestions for what should be default, but this is my preference.

[dgutov]

OK, that's doable.

[dgutov]

@noctuid Please follow #161 for that feature.