Re: [PATCH] mergetool: reorder vim/gvim buffers in three-way diffs

David Aguilar writes: > On Thu, Feb 11, 2016 at 08:03:57AM -0800, Junio C Hamano wrote: >> Michael J Gruber writes: >> >> >> Does this mean that I should warn in the release notes that some >> >> existing users might get their expectation broken but

Re: [PATCH] mergetool: reorder vim/gvim buffers in three-way diffs

Dickson Wong writes: > Thanks for looking into the patch. No. Thank _you_ for contributing ;-) > Vim buffers are not reorderable and windows are always numbered from > top-left to bottom-right. However, I can see someone who is familiar with > the old behavior issue a

Re: [PATCH] mergetool: reorder vim/gvim buffers in three-way diffs

Thanks for looking into the patch. > Thanks. I, being a non-user of vim, was wondering if people who had > their own user-defined commands (macros? and possibly short-cut keys > to invoke them) built around the old (and odd) numbering need to > adjust--in which case we may need to forewarn. >

Re: [PATCH] mergetool: reorder vim/gvim buffers in three-way diffs

On 11 February 2016 at 11:31, Junio C Hamano wrote: > So it should suffice to mention it in the release notes as one > bullet item that describes one positive change, among all other > updates described in a simlar way. And there is no special > "warnings for existing users"

Re: [PATCH] mergetool: reorder vim/gvim buffers in three-way diffs

Junio C Hamano venit, vidit, dixit 10.02.2016 18:45: > Michael J Gruber writes: > >>> Second call for help. Any comments on this from anybody other than >>> the author that I missed to support this change? >> >> OK, applied it (on top of next), looks sane and improves

Re: [PATCH] mergetool: reorder vim/gvim buffers in three-way diffs

Michael J Gruber writes: >> Does this mean that I should warn in the release notes that some >> existing users might get their expectation broken but we are going >> ahead anyway because we think most people read left to right and >> then top down? I am OK with saying

Re: [PATCH] mergetool: reorder vim/gvim buffers in three-way diffs

On Thu, Feb 11, 2016 at 08:03:57AM -0800, Junio C Hamano wrote: > Michael J Gruber writes: > > >> Does this mean that I should warn in the release notes that some > >> existing users might get their expectation broken but we are going > >> ahead anyway because we think

Re: [PATCH] mergetool: reorder vim/gvim buffers in three-way diffs

Junio C Hamano venit, vidit, dixit 09.02.2016 23:25: > Junio C Hamano writes: > >> Dickson Wong writes: >> >>> When invoking default (g)vimdiff three-way merge, the merged file is >>> loaded as the first buffer but moved to the bottom as the fourth

Re: [PATCH] mergetool: reorder vim/gvim buffers in three-way diffs

Michael J Gruber writes: >> Second call for help. Any comments on this from anybody other than >> the author that I missed to support this change? > > OK, applied it (on top of next), looks sane and improves the situation > for the majority of people who read left to

Re: [PATCH] mergetool: reorder vim/gvim buffers in three-way diffs

Junio C Hamano writes: > Dickson Wong writes: > >> When invoking default (g)vimdiff three-way merge, the merged file is >> loaded as the first buffer but moved to the bottom as the fourth window. >> This causes a disconnect between vim commands that

Re: [PATCH] mergetool: reorder vim/gvim buffers in three-way diffs

Dickson Wong writes: > When invoking default (g)vimdiff three-way merge, the merged file is > loaded as the first buffer but moved to the bottom as the fourth window. > This causes a disconnect between vim commands that operate on window > positions (e.g. CTRL-W_w) and

[PATCH] mergetool: reorder vim/gvim buffers in three-way diffs

When invoking default (g)vimdiff three-way merge, the merged file is loaded as the first buffer but moved to the bottom as the fourth window. This causes a disconnect between vim commands that operate on window positions (e.g. CTRL-W_w) and those that operate on buffer index (e.g. do/dp). This