document alternative to diff mode

[josephholsten]

One of the very few goals of vis I'm not sure I agree with is lack of diff mode. I've used a variety of techniques to get diff capability in acme over the years, including using

• http://ipn.caerwyn.com/2009/05/lab-95-acme-side-by-side-diff.html
• 9fans.net/go/acme/Watch + diff

What do you recommend for merging commits and other diff tasks?

[qiu-x]

What do you recommend for merging commits and other diff tasks?

For me, editing diffs like normal files is pretty intuitive. The side-by-side view is good for getting an overview and the diff utility already has it built-in (--side-by-side option)

[mcepl]

For me, editing diffs like normal files is pretty intuitive. The side-by-side view is good for getting an overview and the diff utility already has it built-in (--side-by-side option)

How are you doing with recomputing numbers in hunks headers? I have written https://gitlab.com/mcepl/vim-diff_navigator (which I have unsuccessfully tried to port to Lua and it seems I have lost even that draft I had … oh well).

[mcepl]

@josephholsten This either be reformulated into some action item (relevant to vis, I have a suspicion that this should be done by plugin anyway), or it should be closed. This is supposed to be an issue tracker not a place for dreaming.

[josephholsten]

@mcepl "document alternative to diff mode" is about as concrete an action as I can briefly write. What, are you wanting acceptance tests? As the answer appears to be, "If you need documentation to figure out how to do one of the most frequently performed operations in source code maintenance, we don't want you as a user."
But with that attitude, you won't have to deal with so many contributors you have merge conflicts anyway.
Have fun with your undocumented code!

[mcepl]

@mcepl "document alternative to diff mode" is about as concrete an action as I can briefly write. What, are you wanting acceptance tests? As the answer appears to be, "If you need documentation to figure out how to do one of the most frequently performed operations in source code maintenance, we don't want you as a user." But with that attitude, you won't have to deal with so many contributors you have merge conflicts anyway. Have fun with your undocumented code!

Have you noticed a tiny difference in size between vis and nvim (I don’t have Bram’s vim installed)?

stitny~$ ls -lh /usr/bin/{vis,nvim}
-rwxr-xr-x. 1 root root 3,9M 19. led 08.14 /usr/bin/nvim
-rwxr-xr-x. 1 root root 388K 15. led 23.30 /usr/bin/vis
stitny~$ 

The brutal answer then is “this is a way too big functionality for vis”. If you want something so large then you better come to us with a patch or (most likely) you should create a Lua plugin doing the thing.

[ninewise]

Please don't be rude.

vis currently does not have any functionality, either build in or as a plugin, for viewing diff files other than just opening the raw diff. I consider this OK, since I'm used to 3-way git diffs.

The interactive diff views do seem like quite difficult behaviour to implement as well, so I don't think this would fit in core vis. And it'd probably be very hard to write a plugin fot it.

So I guess the answer would be that there is nothing do document, except perhaps to say that there's nothing to document so people don't have to go look for it.

[mcepl]

And it'd probably be very hard to write a plugin fot it.

See the examples in the original description of this ticket, I wonder whether some combination of watch(1) and diff(1) working in the background wouldn’t be possible as a plugin, but certainly it is a way bigger project than I have time for right now.

[mcepl]

Also, for the uninitiated, adiff is basically loading of diff into ACME, side by side.