justbur / emacs-vdiff Goto Github PK

In the Readme, you mention

In ediff you control the diffed buffers through a third control buffer, which works great until you want to edit the buffers directly.

I do not understand your ediff workflow. You can always edit the buffers being ediff'd without quitting ediff. Then once back in the control window, hit ! to update the diffs and proceed.

Hello,
after a fresh install i try to start vdiff-mode but after M-x vdiff-mode the following error occurs:

Compiling c:/Users/Held/emax/elpa/vdiff-20180627.615/vdiff.el...done
Wrote c:/Users/Held/emax/elpa/vdiff-20180627.615/vdiff.elc
Checking c:/Users/Held/emax/elpa/vdiff-20180627.615...
Done (Total of 1 file compiled, 2 skipped)
vdiff--buffer-init: Wrong type argument: vdiff-session, nil

Any clues whats going wrong?
Regards
Poul

Linux Mint 20, Emacs 27.2, vdiff -20210426.155

I create two files. And want to find difference in it.

M-x vdiff-files
Select file1.txt and file2.txt

Here result.

As you can see both files has different contents(last char in every row).

Why vdiff not show this differents?

hi, first of all, thanks for this nice package!

is it possible to use a diff program that could potentially produce nicer diffs, like patience diff using git diff in stand-alone mode (this works outside git repos)?

git diff --patience --no-index FILE-A FILE-B

i tried

  (setq vdiff-diff-program "git")
  (seq vdiff-diff-extra-args "diff --no-index --patience")

but the result is that i don't see any diffs. :(

also these extra args wouldn't make any sense for diff3.

How to reproduce:

1. start emacs within terminal
2. do M-x xterm-mouse-mode
3. M-x eval-expression (setq vdiff-lock-scrolling t)
4. do M-x vdiff-files with two files (the amount of lines / difference between them dont seem to matter).
5. place the cursor on the left buffer
6. hover the mouse above the right buffer
7. scroll the right buffer with the mouse wheel, keeping the cursor on the left buffer and the mouse-cursor on the right buffer

What happens?

1. only the right buffer scrolls

What should happen?

1. both of the buffers should scroll

Notes:

1. Running from X (and not the terminal) have the same behavior.
2. Also happens when the cursor is on the right buffer and the mouse scrolls on the left one.

First off, thank you very much for your work on this vdiff package! Compared to ediff, I really like (1) the better alignment of diff regions, which stay aligned as you scroll; and (2) the highlighting of all fine diffs, rather than just those of the current region. I find that these two things make it easier to quickly review diffs.

I'm having trouble understanding when this issue appears and doesn't appear, but I'll describe what I know. My impression is that vdiff's scrolling is supposed to allow the beginning of a window to be in the middle of a subtraction region, thus keeping the two buffers aligned as you scroll through a long subtraction/addition. (It looks like this was something you improved with #5 .) This behavior works for me with a fresh, uncustomized emacs. However, with some customizations, this doesn't work: subtractions are shown either in their entirety or not at all, so that when scrolling, the full set of subtraction lines will be shown until the addition in the other buffer completely disappears. (I can make a screencast if this description isn't clear.)

My minimal reproducer involves an emacs customization that just prints a message on startup. It seems like some messages trigger the issue and others don't. This feels really bizarre, but I am able to reproduce this repeatedly with a particular message.

I have experienced this issue when comparing the two attached files (I have renamed them to have .txt extensions to make GitHub happy), starting at the top of each file. Here is my reproducer, using GNU Emacs 28.0.91 (build 1, x86_64-apple-darwin21.3.0, NS appkit-2113.30 Version 12.2 (Build 21D49)) of 2022-02-18, first giving a "good" result, then making a small change that results in a "bad" result:

(1) From a fresh emacs installation, run:

(require 'package)
(add-to-list 'package-archives
'("melpa" . "https://melpa.org/packages/") t)

M-x list-packages

Then install vdiff from melpa

(2) Quit and restart emacs

(3) Load two files with C-x C-f:
(a) NutrientCompetitionCLM45defaultMod.F90
(b) NutrientCompetitionFlexibleCNMod.F90

(4) Expand emacs window to take up the full screen

(5) Run M-x vdiff-buffers; for first buffer select NutrientCompetitionCLM45defaultMod.F90; for second select NutrientCompetitionFlexibleCNMod.F90

(6) Do C-x o to move cursor to the right window (NutrientCompetitionFlexibleCNMod.F90). Position the mouse over that window and scroll about 10 lines. The removed lines on the left scroll away one at a time.

(7) Add the following to the top of ~/.emacs:

(message "[Prelude] Loading personal configuration files in /Users/sacks/.emacs.d/personal...")

(8) Quit and restart emacs

(9) Redo steps (3)-(6). This time, the removed lines on the left don't scroll away until the corresponding added lines on the right have all gone by.

(Note that I have also reproduced this behavior with emacs27.2, although with a less clean setup.)

NutrientCompetitionCLM45defaultMod.F90.txt

NutrientCompetitionFlexibleCNMod.F90.txt

When comparing buffers and one of them has a very long line (and another one doesn't) whole diff becomes unaligned. This can be solved by M-x toggle-truncate-lines in both buffers, but I think this should be the default (it is in vim).

It would be nice to be able to send/receive only parts of changes (specifically, single lines like you can in vimdiff or magi)t. I thought the existing commands would do this based on the docstring, but it looks like visual selection can only be used to send/receive multiple hunks as opposed to a part of one.

Is there any way to hack a region-based diff with vdiff? Like ediff-regions-wordwise?

I'm not sure if this is a user error or a true issue with the package, but I can't get toggling of case and whitespace to work.

I use If I try either vdiff-toggle-whitespace or vdiff-toggle-case with the Ivy completion framework, when I select an option, I get this error:

make-process--with-editor-process-filter: Wrong type argument: stringp, 45

Then I tried without Ivy, instead manually entering -i (or -i) to the vdiff-toggle-case prompt. This avoids the error, but doesn't seem to have any effect on the diff. I am attaching the two test files I used for this, which are identical except for uppercase/lowercase. Every line shows up as a difference even after running vdiff-toggle-case and entering -i.

file1.txt
file2.txt

Am I doing something wrong here, or are there problems with these toggling commands? These toggling commands seem like a really great feature of vdiff!

2 buffers should be easy

3 requires parsing diff3 output

how to fixed vdiff working on emacs -nw console mode

Hi, I think being able to manipulate vdiff folds via evil's z o/z c/etc would be a nice integration b/w evil and vdiff. Would you mind me submitting the following PR to evil's repo:

git diff evil-vars.el
diff --git a/evil-vars.el b/evil-vars.el
index a5c8ddd..0e10747 100644
--- a/evil-vars.el
+++ b/evil-vars.el
@@ -1633,7 +1638,14 @@ Elements have the form (NAME . FUNCTION).")
      :toggle     ,(lambda () (origami-toggle-node (current-buffer) (point)))
      :open       ,(lambda () (origami-open-node (current-buffer) (point)))
      :open-rec   ,(lambda () (origami-open-node-recursively (current-buffer) (point)))
-     :close      ,(lambda () (origami-close-node (current-buffer) (point)))))
+     :close      ,(lambda () (origami-close-node (current-buffer) (point))))
+    ((vdiff-mode)
+     :open-all   vdiff-open-all-folds
+     :close-all  vdiff-close-all-folds
+     :toggle     nil
+     :open       vdiff-open-fold
+     :open-rec   nil
+     :close      vdiff-close-fold))
   "Actions to be performed for various folding operations.

 The value should be a list of fold handlers, were a fold handler has

Thanks

It would be nice to have a command to open a closed fold or close an open fold at the point (and maybe one for all folds).

Hi and thanks for this package!

I'm trying to map ] c and [ c in evil normal state for next/previous hunk. This is working as expected:

  (define-key vdiff-mode-map (kbd "] c") 'vdiff-next-hunk)
  (define-key vdiff-mode-map (kbd "[ c") 'vdiff-previous-hunk)

But this isn't:

  (evil-define-key 'normal vdiff-mode-map (kbd "] c") 'vdiff-next-hunk)
  (evil-define-key 'normal vdiff-mode-map (kbd "[ c") 'vdiff-next-hunk)

Results in ] c is undefined.

Is evil-define-key the proper way to bind keys for vdiff in normal evil state?

Thanks!

Firstly, thanks for such a great plugin.

I found a potential bug I wanted to report. I don't know if it's by design or the limitation.

When the git configured to use emacs-vdiff like the following with git vdiff doesn't activate the highlight.

[difftool "vdiffclient"]
    cmd = emacsclient --eval \"(vdiff-files \\\"$LOCAL\\\" \\\"$REMOTE\\\")\"
[alias]
    vdiff = difftool --tool=vdiffclient

To work around, you can create a function like this and use this instead.

    cmd = emacsclient --eval \"(vdiff-files \\\"$LOCAL\\\" \\\"$REMOTE\\\") (vdiff-mode)\"

Question about your screenshot:
https://github.com/justbur/emacs-vdiff/blob/master/img/leuven.png

I noticed that if one of buffers has at least one line with a change and is missing any lines right after the line with the change, "vdiff" correctly adds the dashed lines (when vdiff-subtraction-style = full) and uses the "subtraction" face color on the buffer that is missing lines, but uses the "change" overlay color on the buffer that has extra added lines. If I use "vimdiff" instead, the line with the change is overlaid with the "change" color (same as vdiff), but the buffer with the extra lines after the changed line uses the "addition" overlay color.

Is there a way to achieve similar behavior to vimdiff for this?
Thanks so much,
Jordi

I want to use folding for python buffers. Only folding not diff.

I'm aware of Installation & Usage but all "entry points" there are commands that I don't need. They all related to diff not to folding.

I am using evil-mode. When I do "z m" in a python buffer I get that message

Enable one of the following modes for folding to work: vdiff-mode, vdiff-3way-mode, hs-minor-mode, hide-ifdef-mode, outline-mode, origami-mode

Doing M: there is no vdiff-mode.

Installed is 20210426.155. I also verified that 0.2.4 from elpa is not installed and interfere.

I just had buffer A on the left of my emacs window, and buffer B on the right. Starting from buffer B I executed vdiff-buffers. It correctly guessed the first buffer to use was B, and the second A. The result was that B was on the left and A on the right.

I used this service to compare two text sometimes: https://text-compare.com
Is it posible to have option to open vdiff, ready to receive two text?
The current implementation require you to create two tmp buffer for that which isn't just quick.

vimdiff allows the beginning of the window to be in the middle of a subtraction, even though the subtraction does not represent real lines in the buffer. Emacs does too, but only with vscroll which I haven't figured out how to use correctly yet.

When using folding in combination with truncation disabled, such that the text of the file is wrapped, it is noticeable when using display-line-numbers-mode that the fold string can be too long.

This is likely due to the calculation in vdiff--make-fold relying on window-width and not taking into consideration the width of the line numbers themselves. According to this thread, line-number-display-width can be used to retrieve the amount of space used for showing the line number.

Note also that depending on the settings for display-line-numbers-mode, the actual width of the window used by the line number may grow and shrink based upon where you are in the document. Thus, invoking display-line-numbers-mode will be different depending on where in the document you are. It likely cannot be relied upon alone to calculate the number of columns, especially when folding is being used. It may be necessary to explicitly set the display-line-numbers-width when this mode is enabled. There is some text in the manual which indicates this could be problematic.

It would be great if there was an option/way to have vdiff-magit-stage do a 2-way diff without the HEAD buffer (or without the buffer file; that might be useful in some cases). Most of the time I just want the diff to have the file and the index version.

When using vdiff alongside emacsclient, diff is not showing up until vdiff-refresh is manually called. This issue was first seen in http://emacs.stackexchange.com/questions/30033/vdiff-refine-all-hunks-ediff-update-diffs-in-startup-eval.

init.el:
(require 'package)
(add-to-list 'package-archives
'("melpa" . "http://melpa.milkbox.net/packages/") t)
(package-initialize)

(require 'vdiff)
(setq vdiff-auto-refine t)

Command line:
emacsclient -c -e "(vdiff-files \"new1\" \"new2\")"

1)Result in no diff showing:

2)After manually vdiff-refresh:

Now only knowing a workaround which uses sit-for can partially solve it without the need of manually calling vdiff-refresh, but a drawback is that it works only starting from the second time of vdiff run:
emacsclient -c -e "(progn (vdiff-files \"$file1\" \"$file2\") (sit-for 1))"

Please consider making a new release of this package on GNU ELPA.

The version in GNU ELPA seems to be version 0.2.3 from 2017:
https://elpa.gnu.org/packages/vdiff.html

Thanks in advance.

I don't have hydra installed and when I installed emacs-vdiff I got lots of errors. I think part of it has to do with the fact that defhydra is (likely) a macro.

I thought about putting the hydra bits in another file and optionally loading that file, but I'm afraid that might not work either since package.el will try to compile them all. I think the way many other packages do this is to have a completely separate vdiff-hydra package that depends on vdiff and hydra.

However, I wonder if it would be possible to change package.el to handle situations like this. There was a similar thread on emacs-devel a year ago http://lists.gnu.org/archive/html/emacs-devel/2015-07/msg00175.html