dgutov / diff-hl

Emacs package for highlighting uncommitted changes
GNU General Public License v3.0
926 stars 45 forks source link

Add a specific "modified" face for Dired mode #25

Open fniessen opened 10 years ago

fniessen commented 10 years ago

When editing a buffer, having red - green - blue for deleted - inserted - changed looks very nice, by matching colors used in Diff mode.

However, in Dired, I'd prefer to see the modified files with an orange icon, to match my "vc-icon" in the modeline (à la Tortoise) : green for not modified since last commit, orange for modified. See http://screencast.com/t/nUvy7GMnlmi.

Currently, in Dired, we have "diff-hl-unknown" for non-versioned files (not under version control, but have not been ignored). Can we have new faces:

For normal files, can we have a "v" indicator in the fringe? For modified files, can we change the indicator to be "!" instead of "|" in the fringe?

Thanks in advance!

dgutov commented 10 years ago

for modified files?

Yep. I'll add diff-hl-dired-specific faces that will derive from diff-hl as appropriate.

For normal files, can we have a "v" indicator in the fringe?

I'm not convinced: this won't convey any extra information to the user. If the file is displayed normally, we already know it's "unchanged", otherwise, it would have some modification status, or be "unknown".

for ignored files (for version control purposes)?

That would be nice, but first we'd have to start highlighting them. That is hard to do currently, because vc-git-dir-status-goto-stage (as one example) only includes the ignored files if we ask for status of a specific set of files, and retrieving the list of all files in the repo and then passing it to that function would be pretty crazy.

This would also not fit our logic very well: currently, if there's a non-up-to-date file in the repository somewhere, we highlight the subdirectory containing it with its status. For ignored files, this can become an annoyance, because the files stay there indefinitely, and they will create an impression that the whole directory is ignored.

That leaves an option of collecting the list of all ignored files sort of manually, parsing the contents of the applicable .*ignore files and matching the contents of the current directory against them. I wonder if these files have the same syntax, across all the interesting VC systems.

For modified files, can we change the indicator to be "!" instead of "|" in the fringe?

That sounds kinda nice, but Flymake already uses exclamation marks to highlight errors in the fringe, albeit using a different color. I'm wary about having that conflict (and we might have some colorblind users).

EDIT: And this is a concern because when diff-hl-fringe-bmp-function is set to diff-hl-fringe-bmp-from-type, we also use these indicators inside file buffers.

fniessen commented 10 years ago

Hello Dmitry,

Dmitry Gutov wrote:

for modified files?

Yep. I'll add diff-hl-dired-specific faces that will derive from diff-hl as appropriate.

Thanks!

For normal files, can we have a "v" indicator in the fringe?

I'm not convinced: this won't convey any extra information to the user. If the file is displayed normally, we already know it's "unchanged", otherwise, it would have some modification status, or be "unknown".

The idea is to get something similar to the famous Tortoise, which is one tool some people can't give away to go to Emacs Dired.

for ignored files (for version control purposes)?

That would be nice, but first we'd have to start highlighting them. That is hard to do currently, because vc-git-dir-status-goto-stage (as one example) only includes the ignored files if we ask for status of a specific set of files, and retrieving the list of all files in the repo and then passing it to that function would be pretty crazy.

This would also not fit our logic very well: currently, if there's a non-up-to-date file in the repository somewhere, we highlight the subdirectory containing it with its status. For ignored files, this can become an annoyance, because the files stay there indefinitely, and they will create an impression that the whole directory is ignored.

That leaves an option of collecting the list of all ignored files sort of manually, parsing the contents of the applicable .*ignore files and matching the contents of the current directory against them. I wonder if these files have the same syntax, across all the interesting VC systems.

I'm sure syntax (can) differ between VC, and I now understand that this can be complex. So, I'd understand you don't do anything for the ignored files.

But that brings back my request for something visible for the "unchanged" files: it's good to see a difference between files which are ignored and files which are up-to-date IMHO.

For modified files, can we change the indicator to be "!" instead of "|" in the fringe?

That sounds kinda nice, but Flymake already uses exclamation marks to highlight errors in the fringe, albeit using a different color. I'm wary about having that conflict (and we might have some colorblind users).

Here, we're speaking of Dired. I guess Flymake never does anything in Dired, right?

And, would it even be, I wouldn't search for a different icon because it's like Flymake's icon: that's up to the theme (or user customization) to make it clear who's who.

But, like I said, my request in this post are only targetting Dired, and a Tortoise-like interaction.

Best regards.

dgutov commented 10 years ago

The idea is to get something similar to the famous Tortoise

I see. Personally, I didn't like Tortoise very much. I'd rather reproduce the looks of modern IDEs in this regard, and given an open project, they don't mark up-to-date files in any special way. The assumption is, I guess, that any such project is version-controlled.

But that brings back my request for something visible for the "unchanged" files: it's good to see a difference between files which are ignored and files which are up-to-date IMHO.

Getting the list of all up-to-date files in a VCS-agnostic way is actually not a lot easier: vc-git-dir-status-goto-stage likewise doesn't pass them to the callback (or it might generate a lot of objects when working with a large repository).

Thinking about it more, maybe showing the list of all ignored files is feasible, if we limit them only to plain files in the current directory: we collect that list (which hopefully will be easy), then do a second call to dir-status with it, and collect the ignored items from there.

Here, we're speaking of Dired. I guess Flymake never does anything in Dired, right?

True, but see the edit at the end of my previous message. The same bitmap-choosing function can be used in file buffers, too, and some users prefer it. And supplying another function that would differ in just one element seems rather redundant. Any user can write their own function for that anyway.

However, actually we already conflict with it a bit, with the "unregistered" bitmap. So maybe one more won't hurt, I'll take a look.

dgutov commented 10 years ago

All done!

Suggestions for better bitmap and default face for the ignored files would be welcome.

fniessen commented 10 years ago

Hello Dmitry. I confirm that face and "!" are working for changed files.

However, in my tests, I never saw an indicator for Git ignored files (plain text syntax, no wildcards or such).

And, I don't see anything neither for up-to-date files, but you did not commit to do something for these (and I accept that ;-)).

Thanks for your work. It's already very nice to use!

dgutov commented 10 years ago

in my tests, I never saw an indicator for Git ignored files

That is troubling: ignored files are displayed just fine on my machine, in the three versions of Emacs I have on hand (24.3, 24.4 pretest and trunk). Are you sure you're trying a Git repository, and not, say, a Bazaar one? What's your Git version?

(plain text syntax, no wildcards or such)

Any supported syntax should work, because I'm using the dir-status-files VC command to fetch them. Could you try it on a repository known to us both? Say, clone company-mode, add a file foo.elc in the cloned directory, and open it in Dired with diff-hl-dired-mode. No indicator?

Try running git ls-files -z -o -i --directory --no-empty-directory --exclude-standard -- foo.elc in that directory. Does it output foo.elc?

fniessen commented 10 years ago

Regarding my repo, it was either a SVN or a Git repo, the only two VCS I work with.

My Git version is 2.1.1 (from Cygwin, running on Windows 8).

Regarding cloning Cmp, and doing your tests: both did work. I do have the gray square displayed next to foo.elc and I do have it reported in the command output.

I don't understand what happens with my repo. I'll try to come back with more evidence at hand. Thanks for your help and patience.

dgutov commented 10 years ago

It's possible that the Git backend fails for some configurations, or the SVN backend doesn't show ignored files (I've tried to test this just now and failed, in part due to having very little SVN experience).

There is a known bug in the Bazaar backend. Alas, it'll not be fixed in time for the upcoming release.

Please do show the example if you can reproduce the problem.

fniessen commented 10 years ago

I could reproduce the problem with SVN repo. I'm sending you a video privately.

dgutov commented 10 years ago

Yep. There's a bug in vc-svn-dir-status-files, but it can be worked around. Thanks.

dgutov commented 9 years ago

Everything here seems resolved, one way or another, except for the up-to-date files.

For them, I need:

So far, the second item has proven the hardest: the red-green-blue diff palette doesn't leave a lot of strong colors. Yellow? :) Orange, like the error face?

dgutov commented 9 years ago

Bad news: even vc-git doesn't return the list of up-to-date files correctly in the current release.

So this won't work anyway until Emacs 24.5.

fniessen commented 9 years ago

Bad news: even vc-git doesn't return the list of up-to-date files correctly in the current release.

So this won't work anyway until Emacs 24.5.

You mean Emacs 25.0? ;-)

dgutov commented 9 years ago

Or that. :) 24.5 might still come out, as a bugfix-only release.