Two feature ideas for diffs

Two feature ideas for diffs

[Tom]

I was reading this description of PyCharm 

   http://nicoddemus.github.io/articles/pycharm/

and there was two features described which could be useful in
emacs too.

The first is diff indicators in the sidebar. If the file is under
version control and it is edited then a mark appears beside the
changed lines and if it is clicked then you can see what's
changed in the line or in that hunk, you don't have to do a full
file diff which may contain many other changes unrelated to the
current line. You can also rollback that particular change,
etc. Is there something like this for emacs? If not it could be a
useful addition.

The other interesting feature is editable diffs. So, for example,
before checking in one usually does a diff to see what was
changed in the file. If you notice a typo then you go back to the
file, fix it, do a diff again to check the changes, etc. PyCharm
lets you edit the diff instead, so if you made a typo then you
can fix it in the diff buffer and it is applied to the original
file. It would be a nice convenience feature.

Re: Two feature ideas for diffs

[nhs]

> The first is diff indicators in the sidebar. If the file is under
> version control and it is edited then a mark appears beside the
> changed lines and if it is clicked then you can see what's
> changed in the line or in that hunk, you don't have to do a full
> file diff which may contain many other changes unrelated to the
> current line. You can also rollback that particular change,
> etc. Is there something like this for emacs? If not it could be a
> useful addition.

There are git-gutter and git-gutter+. As the name suggests, they only 
work with git, but do what you describe.

     Nicolas

Re: Two feature ideas for diffs

[Tom]

nhs <nhs <at> openmailbox.org> writes:

> 
> There are git-gutter and git-gutter+. As the name suggests, they only 
> work with git, but do what you describe.
> 

Nice, but it's a pity it's written as git-specific. Git should
only be one of the backends and the frontend should call the
appropriate backend after checking what VC the file is under.

Re: Two feature ideas for diffs

[Dmitry Gutov]

Tom <adatgyujto@gmail.com> writes:

> nhs <nhs <at> openmailbox.org> writes:
>> There are git-gutter and git-gutter+. As the name suggests, they only 
>> work with git, but do what you describe.
>
> Nice, but it's a pity it's written as git-specific. Git should
> only be one of the backends and the frontend should call the
> appropriate backend after checking what VC the file is under.

Check out https://github.com/dgutov/diff-hl

Re: Two feature ideas for diffs

[Dmitry Gutov]

Tom <adatgyujto@gmail.com> writes:

> The other interesting feature is editable diffs. So, for example,
> before checking in one usually does a diff to see what was
> changed in the file. If you notice a typo then you go back to the
> file, fix it, do a diff again to check the changes, etc. PyCharm
> lets you edit the diff instead, so if you made a typo then you
> can fix it in the diff buffer and it is applied to the original
> file. It would be a nice convenience feature.

I've been pointed to https://github.com/caldwell/commit-patch in the
past, but it depends on Perl, and I haven't gotten around to trying it.

Re: Two feature ideas for diffs

[Tom]

Dmitry Gutov <dgutov <at> yandex.ru> writes:

> Check out https://github.com/dgutov/diff-hl
> 


Thanks. I haven't yet tried it, but it looks promising.

Re: Two feature ideas for diffs

[Tom]

Dmitry Gutov <dgutov <at> yandex.ru> writes:
> 
> I've been pointed to https://github.com/caldwell/commit-patch in the
> past, but it depends on Perl, and I haven't gotten around to trying it.

The described feature does not seem that complicated if diff editing
supports only simple changes (e.g. no adding/deleting lines, only changing
existing lines in the diff buffer). It should be enough (if one wants to
do extensive modifications then he should go back to the file instead),
so relying on external tools seems an overkill. 

Re: Two feature ideas for diffs

[Barry OReilly]

[-- Attachment #1: Type: text/plain, Size: 413 bytes --]

> Nice, but it's a pity it's written as git-specific. Git should only
> be one of the backends and the frontend should call the appropriate
> backend after checking what VC the file is under.

It should operate on unified diffs and provide the customization for
how to obtain the unified diffs, eg 'git diff'.

Dmitry, can diff-hl be used to review patch files distributed as diff
files without relying on a VCS?

[-- Attachment #2: Type: text/html, Size: 493 bytes --]

Re: Two feature ideas for diffs

[Stefan Monnier]

> Check out https://github.com/dgutov/diff-hl

Would be good to add it to GNU ELPA,


        Stefan

Re: Two feature ideas for diffs

[Stefan Monnier]

> The other interesting feature is editable diffs.  So, for example,
> before checking in one usually does a diff to see what was
> changed in the file.  If you notice a typo then you go back to the
> file, fix it, do a diff again to check the changes, etc.  PyCharm
> lets you edit the diff instead, so if you made a typo then you
> can fix it in the diff buffer and it is applied to the original
> file.  It would be a nice convenience feature.

diff-mode has supported editing the diffs "for ever".
It does not propagate the changes back to the source file, tho.
Patches to do that are welcome,


        Stefan

Re: Two feature ideas for diffs

[Dmitry Gutov]

On 07.11.2013 21:09, Stefan Monnier wrote:
>> Check out https://github.com/dgutov/diff-hl
>
> Would be good to add it to GNU ELPA,

Sure. I was thinking it might use a rename, though ("Git Gutter" has a 
much better ring to it), and this would be a good time.

Any suggestions? Or do you think the name is fine?

Re: Two feature ideas for diffs

[Stefan Monnier]

> Any suggestions? Or do you think the name is fine?

Bikeshedding is tempting, but I'll pass,


        Stefan

Re: Two feature ideas for diffs

[Dmitry Gutov]

Barry OReilly <gundaetiapo@gmail.com> writes:

>> Nice, but it's a pity it's written as git-specific. Git should only
>> be one of the backends and the frontend should call the appropriate
>> backend after checking what VC the file is under.
>
> It should operate on unified diffs and provide the customization for
> how to obtain the unified diffs, eg 'git diff'.
>
> Dmitry, can diff-hl be used to review patch files distributed as diff
> files without relying on a VCS?

No, it's rather tied to the VC package.  But why would you want that?

The main benefit of diff-hl is to see the diff on the margin updated as
you edit and save the file.

Re: Two feature ideas for diffs

[Ivan Andrus]

On Nov 7, 2013, at 3:11 PM, Dmitry Gutov <dgutov@yandex.ru> wrote:

> Tom <adatgyujto@gmail.com> writes:
> 
>> The other interesting feature is editable diffs. So, for example,
>> before checking in one usually does a diff to see what was
>> changed in the file. If you notice a typo then you go back to the
>> file, fix it, do a diff again to check the changes, etc. PyCharm
>> lets you edit the diff instead, so if you made a typo then you
>> can fix it in the diff buffer and it is applied to the original
>> file. It would be a nice convenience feature.
> 
> I've been pointed to https://github.com/caldwell/commit-patch in the
> past, but it depends on Perl, and I haven't gotten around to trying it.

I can give commit-patch a hearty two thumbs up (I've used it mostly with mercurial and git).

-Ivan

Re: Two feature ideas for diffs

[Michael Heerdegen]

Hi all,

> Check out https://github.com/dgutov/diff-hl

That's nice.

In addition, I would like to see the vc state in the mode-line.  I see
"Git-master" in the mode-line and a mouse echo telling the state ("Up to
date"; "Locally modified" etc.).  But I want to see the state from the
indicator - preferably by using faces.  I tried to use this in
`mode-line-format' (using my own faces):

(vc-mode (:eval (propertize vc-mode 'face
                  (pcase (vc-state buffer-file-truename)
                    (`up-to-date 'mode-line-important)
                    (`edited                      nil)
                    (_             'mode-line-warning)))))

But that doesn't work.  The state is never refreshed, I need to restart
Emacs.  (vc-state buffer-file-truename) seems to return the same value
for the entire Emacs session.  I'm not familiar with the VC code - how
can it be done?  And shouldn't vc-state return an up-to-date value (bug)?


Thanks,

Michael.

 

Re: Two feature ideas for diffs

[Óscar Fuentes]

Michael Heerdegen <michael_heerdegen@web.de> writes:

> Hi all,
>
>> Check out https://github.com/dgutov/diff-hl
>
> That's nice.
>
> In addition, I would like to see the vc state in the mode-line.  I see
> "Git-master" in the mode-line and a mouse echo telling the state ("Up to
> date"; "Locally modified" etc.).  But I want to see the state from the
> indicator

The char between "Git" and "master" indicates the VC state. `-' means up
to date, `:' means "modified", etc

> - preferably by using faces.

I implemented that on my personal branch of Emacs. IIRC I submitted it
for inclusion, but possibly it went lost on the mailing list.

diff --git a/lisp/vc/vc-git.el b/lisp/vc/vc-git.el
index 1d67dee..657980c 100644
--- a/lisp/vc/vc-git.el
+++ b/lisp/vc/vc-git.el
@@ -204,12 +204,12 @@ matching the resulting Git log output, and KEYWORDS is a list of
     (?M 'edited)
     (?A 'added)
     (?D 'removed)
-    (?U 'edited)     ;; FIXME
+    (?U 'conflict)
     (?T 'edited)))   ;; FIXME
 
 (defun vc-git-state (file)
   "Git-specific version of `vc-state'."
-  ;; FIXME: This can't set 'ignored or 'conflict yet
+  ;; FIXME: This can't set 'ignored yet.
   ;; The 'ignored state could be detected with `git ls-files -i -o
   ;; --exclude-standard` It also can't set 'needs-update or
   ;; 'needs-merge. The rough equivalent would be that upstream branch
@@ -781,6 +781,7 @@ If LIMIT is non-nil, show no more than this many entries."
                     ,(format "--pretty=tformat:%s"
 			     (car vc-git-root-log-format))
 		    "--abbrev-commit"))
+		'("--follow")
 		(when limit (list "-n" (format "%s" limit)))
 		(when start-revision (list start-revision))
 		'("--")))))))
diff --git a/lisp/vc/vc-hooks.el b/lisp/vc/vc-hooks.el
index c47bc4c..3140157 100644
--- a/lisp/vc/vc-hooks.el
+++ b/lisp/vc/vc-hooks.el
@@ -34,6 +34,93 @@
 
 ;; Customization Variables (the rest is in vc.el)
 
+(defvar vc-ignore-vc-files nil)
+(make-obsolete-variable 'vc-ignore-vc-files
+                        "set `vc-handled-backends' to nil to disable VC."
+			"21.1")
+
+(defvar vc-master-templates ())
+(make-obsolete-variable 'vc-master-templates
+ "to define master templates for a given BACKEND, use
+vc-BACKEND-master-templates.  To enable or disable VC for a given
+BACKEND, use `vc-handled-backends'."
+ "21.1")
+
+(defvar vc-header-alist ())
+(make-obsolete-variable 'vc-header-alist 'vc-BACKEND-header "21.1")
+
+(defface vc-up-to-date-state
+  '((((class color) (background light))
+     :foreground "blue1")
+    (((class color) (background dark))
+     :foreground "white"))
+  "Face for VC modeline state when the file is up to date."
+  :version "24.1"
+  :group 'vc)
+
+(defface vc-needs-update-state
+  '((((class color) (background light))
+     :foreground "blue1")
+    (((class color) (background dark))
+     :foreground "white"))
+  "Face for VC modeline state when the file needs update."
+  :version "24.1"
+  :group 'vc)
+
+(defface vc-locked-state
+  '((((class color) (background light))
+     :foreground "blue1" :weight bold)
+    (((class color) (background dark))
+     :foreground "white" :weight bold))
+  "Face for VC modeline state when the file locked."
+  :version "24.1"
+  :group 'vc)
+
+(defface vc-locally-added-state
+  '((((class color) (background light))
+     :foreground "red" :weight bold)
+    (((class color) (background dark))
+     :foreground "red" :weight bold))
+  "Face for VC modeline state when the file is locally added."
+  :version "24.1"
+  :group 'vc)
+
+(defface vc-conflict-state
+  '((((class color) (background light))
+     :foreground "black" :background "red")
+    (((class color) (background dark))
+     :foreground "white" :background "red"))
+  "Face for VC modeline state when the file contains merge conflicts."
+  :version "24.1"
+  :group 'vc)
+
+(defface vc-removed-state
+  '((((class color) (background light))
+     :foreground "black" :background "red" :weight bold)
+    (((class color) (background dark))
+     :foreground "white" :background "red" :weight bold))
+  "Face for VC modeline state when the file was removed from the VC system."
+  :version "24.1"
+  :group 'vc)
+
+(defface vc-missing-state
+  '((((class color) (background light))
+     :foreground "black" :background "red" :weight bold)
+    (((class color) (background dark))
+     :foreground "white" :background "red" :weight bold))
+  "Face for VC modeline state when the file is missing from the file system."
+  :version "24.1"
+  :group 'vc)
+
+(defface vc-edited-state
+  '((((class color) (background light))
+     :foreground "red")
+    (((class color) (background dark))
+     :foreground "red"))
+  "Face for VC modeline state when the file is up to date."
+  :version "24.1"
+  :group 'vc)
+
 (defcustom vc-ignore-dir-regexp
   ;; Stop SMB, automounter, AFS, and DFS host lookups.
   locate-dominating-stop-dir-regexp
@@ -788,33 +875,42 @@ This function assumes that the file is registered."
   (let* ((backend-name (symbol-name backend))
 	 (state   (vc-state file backend))
 	 (state-echo nil)
+	 (face nil)
 	 (rev     (vc-working-revision file backend)))
     (propertize
      (cond ((or (eq state 'up-to-date)
 		(eq state 'needs-update))
 	    (setq state-echo "Up to date file")
+	    (setq face 'vc-up-to-date-state)
 	    (concat backend-name "-" rev))
 	   ((stringp state)
 	    (setq state-echo (concat "File locked by" state))
+	    (setq face 'vc-locked-state)
 	    (concat backend-name ":" state ":" rev))
            ((eq state 'added)
             (setq state-echo "Locally added file")
+	    (setq face 'vc-locally-added-state)
             (concat backend-name "@" rev))
            ((eq state 'conflict)
             (setq state-echo "File contains conflicts after the last merge")
+	    (setq face 'vc-conflict-state)
             (concat backend-name "!" rev))
            ((eq state 'removed)
             (setq state-echo "File removed from the VC system")
+	    (setq face 'vc-removed-state)
             (concat backend-name "!" rev))
            ((eq state 'missing)
             (setq state-echo "File tracked by the VC system, but missing from the file system")
+	    (setq face 'vc-missing-state)
             (concat backend-name "?" rev))
 	   (t
 	    ;; Not just for the 'edited state, but also a fallback
 	    ;; for all other states.  Think about different symbols
 	    ;; for 'needs-update and 'needs-merge.
 	    (setq state-echo "Locally modified file")
+	    (setq face 'vc-edited-state)
 	    (concat backend-name ":" rev)))
+     'face face
      'help-echo (concat state-echo " under the " backend-name
 			" version control system"))))
 

Re: Two feature ideas for diffs

[Michael Heerdegen]

Óscar Fuentes <ofv@wanadoo.es> writes:

> > In addition, I would like to see the vc state in the mode-line.  I see
> > "Git-master" in the mode-line and a mouse echo telling the state ("Up to
> > date"; "Locally modified" etc.).  But I want to see the state from the
> > indicator
>
> The char between "Git" and "master" indicates the VC state. `-' means up
> to date, `:' means "modified", etc

Uff, I would never have guessed that, not in a thousand years.

> > - preferably by using faces.
>
> I implemented that on my personal branch of Emacs. IIRC I submitted it
> for inclusion, but possibly it went lost on the mailing list.

Having something like that would be nice.  Dunno if coloring the
mode-line is acceptable...?

BTW, in the meanwhile, I found out that

  (vc-state (expand-file-name buffer-file-truename))

is always correct.  Seems `vc-state' needs an expanded file name.


Regards,

Michael.

Re: Two feature ideas for diffs

[Stefan Monnier]

> Uff, I would never have guessed that, not in a thousand years.

Don't need to guess.  It says so in the manual.


        Stefan

Re: Two feature ideas for diffs

[Stefan Monnier]

> --- a/lisp/vc/vc-git.el
> +++ b/lisp/vc/vc-git.el
> @@ -204,12 +204,12 @@ matching the resulting Git log output, and KEYWORDS is a list of
>      (?M 'edited)
>      (?A 'added)
>      (?D 'removed)
> -    (?U 'edited)     ;; FIXME
> +    (?U 'conflict)
>      (?T 'edited)))   ;; FIXME
 
>  (defun vc-git-state (file)
>    "Git-specific version of `vc-state'."
> -  ;; FIXME: This can't set 'ignored or 'conflict yet
> +  ;; FIXME: This can't set 'ignored yet.
>    ;; The 'ignored state could be detected with `git ls-files -i -o
>    ;; --exclude-standard` It also can't set 'needs-update or
>    ;; 'needs-merge. The rough equivalent would be that upstream branch
> @@ -781,6 +781,7 @@ If LIMIT is non-nil, show no more than this many entries."
>                      ,(format "--pretty=tformat:%s"
>  			     (car vc-git-root-log-format))
>  		    "--abbrev-commit"))
> +		'("--follow")
>  		(when limit (list "-n" (format "%s" limit)))
>  		(when start-revision (list start-revision))
>  		'("--")))))))

Is it really all it takes to detect `conflict' state?


        Stefan

Re: Two feature ideas for diffs

[Óscar Fuentes]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> Is it really all it takes to detect `conflict' state?

Git conflict state detection worked when I implemented the feature many
moons ago, although it was not 100% reliable. It doesn't work anymore.
Maybe something was lost on one of the many merges.

Re: Two feature ideas for diffs

[Michael Heerdegen]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> > Uff, I would never have guessed that, not in a thousand years.
>
> Don't need to guess.  It says so in the manual.

I've read it now.  Didn't think that Emacs VC has that many features,
not bad.  Sorry, but I thought the colon is just a ... colon (like in
"Term: char run" in M-x term).  It's IMHO not very intuitive.

Thanks,

Michael.

Re: Two feature ideas for diffs

[Stefan Monnier]

>> Is it really all it takes to detect `conflict' state?
> Git conflict state detection worked when I implemented the feature many
> moons ago, although it was not 100% reliable. It doesn't work anymore.
> Maybe something was lost on one of the many merges.

Could you try and make it work again and submit/install the patch for that?


        Stefan