Hi Bram and List,

2016-1-11(Mon) 6:13:31 UTC+9 Bram Moolenaar:
> Hirohito Higashi wrote:
> 
> > 2016-1-10(Sun) 22:14:01 UTC+9 Bram Moolenaar:
> > > Hirohito Higashi wrote:
> > > 
> > > > 2016-1-10(Sun) 4:15:14 UTC+9 Bram Moolenaar:
> > > > > Hirohito Higashi wrote:
> > > > > 
> > > > > > 2016-1-8(Fri) 2:27:17 UTC+9 Bram Moolenaar:
> > > > > > > Hirohito Higashi wrote:
> > > > > > > 
> > > > > > > > > > To: Bram (As a Vimboss)
> > > > > > > > > > To: Christian Brabandt (As a visual <C-A>/<C-X> first patch 
> > > > > > > > > > author)
> > > > > > > > > > To: Jason Schulz (As a support for bin 'nrformats' patch 
> > > > > > > > > > author)
> > > > > > > > > > 
> > > > > > > > > > Hi,
> > > > > > > > > > 
> > > > > > > > > > I refactored visual <C-A>/<C-X> to support vcol et al.
> > > > > > > > > > This mean is <TAB> code free!
> > > > > > > > > > 
> > > > > > > > > > Contents of patch.
> > > > > > > > > > - visual <C-A>/<C-X> support vcol. (<TAB> code free)
> > > > > > > > > > - 'test_increment' convert from old style test to new style 
> > > > > > > > > > test. and added some test items. 
> > > > > > > > > > - Processing was allowed to separate.
> > > > > > > > > >   (line loop process and add/subtract process)
> > > > > > > > > >   (We have to use the existing function block_prep() to 
> > > > > > > > > > process the block-wise)
> > > > > > > > > > - We removed the halfway right-to-left processing.
> > > > > > > > > >   (Remove RLADDSUBFIX() macro)
> > > > > > > > > >   (This is causing the actual problem)
> > > > > > > > > >    $ vim -Nu NONE -c "set rightleft"
> > > > > > > > > >    i123 45<Esc>
> > > > > > > > > >    <C-A>           " Unexpected swap the numbers of strings 
> > > > > > > > > > occurred.
> > > > > > > > > > 
> > > > > > > > > > Christian Brabandt and Jason Schulz and List>
> > > > > > > > > > I was wondering if you could review this patch.
> > > > > > > > > > 
> > > > > > > > > > Jason Schulz>
> > > > > > > > > > Sorry to such just your patch was included.
> > > > > > > > > > I have just completed the doing has been working since last 
> > > > > > > > > > fall :-)
> > > > > > > > > 
> > > > > > > > > That's a big change.  Can you give an example of what didn't 
> > > > > > > > > work before
> > > > > > > > > and works now?
> > > > > > > > 
> > > > > > > > Please see Test_visual_increment_27() ~ 
> > > > > > > > Test_visual_increment_34().
> > > > > > > > Below is ather exsample.
> > > > > > > > 
> > > > > > > > Case 1 (Visual blockwise <C-A> with TAB and SPACE mixed)
> > > > > > > >   - Manipulate
> > > > > > > >     $ vim -Nu NONE
> > > > > > > >     :call setline(1, ["1234    56", "\<TAB>78"])
> > > > > > > >     :exec "norm! ggw\<C-V>jl\<C-A>"
> > > > > > > >   - Expect result
> > > > > > > >     "1234    57"
> > > > > > > >     "\<TAB>79"
> > > > > > > >   - Unpatched result
> > > > > > > >     "1235    56"
> > > > > > > >     "\<TAB>79"
> > > > > > > 
> > > > > > > 
> > > > > > > I see, thanks for fixing that.
> > > > > > > 
> > > > > > > > > To make reviewing easier, it would be good to first make a 
> > > > > > > > > patch to
> > > > > > > > > change the test from old to new style.  Then we know the test 
> > > > > > > > > works with
> > > > > > > > > the old code.
> > > > > > > > 
> > > > > > > > Okay. I attached simple patch that only convert to new style 
> > > > > > > > test of
> > > > > > > > test_increment.
> > > > > > > 
> > > > > > > Thanks.  The original test had a nice explanation of what it was 
> > > > > > > doing.
> > > > > > > Although the new style test do have the assert_equal() calls that 
> > > > > > > make
> > > > > > > it easier to see what is going on, the commands themselves are 
> > > > > > > still a
> > > > > > > bit of a puzzle.  Since the explanations were already written, we 
> > > > > > > can
> > > > > > > keep them.  Using the comment above the test function should work 
> > > > > > > well.
> > > > > > 
> > > > > > Indeed. I did it.  Please check and include attached patch.
> > > > > 
> > > > > Thanks!
> > > > 
> > > > Thanks for including this.
> > > >   Patch 7.4.1072
> > > >   https://groups.google.com/d/topic/vim_dev/_K0eQkIB5aY/discussion
> > > > 
> > > > > 
> > > > > > BTW, The following changes I thought happy for test_increment.vim.
> > > > > > How do you like it?
> > > > > 
> > > > > Yes, that's better than the arbitrary order we have now.
> > > > > Unfortunately it break test_quickfix, it makes an assumption about 
> > > > > test
> > > > > function ordering.  That needs to be fixed.
> > > > 
> > > > Thanks for including this too.
> > > >   Patch 7.4.1071
> > > >   https://groups.google.com/d/topic/vim_dev/p6IAS6bPFDU/discussion
> > > > 
> > > > 
> > > > Well, the next simple patch is about this.
> > > > > - We removed the halfway right-to-left processing.
> > > > >   (Remove RLADDSUBFIX() macro)
> > > > >   (This is causing the actual problem)
> > > > >    $ vim -Nu NONE -c "set rightleft"
> > > > >    i123 45<Esc>
> > > > >    <C-A>           " Unexpected swap the numbers of strings occurred.
> > > > 
> > > > Investigation result:
> > > > Reverse line process of 'rightleft' is performed by the display part.   
> > > > therefore it doesn't need in do_addsub().
> > > > 
> > > > I've attached a patch containing the test.
> > > > Please check it.
> > > 
> > > Thanks.  Now I could check that the test fails before including the
> > > change in ops.c.
> > 
> > Thanks for include this quickly.
> >   Patch 7.4.1076
> >   https://groups.google.com/d/topic/vim_dev/TOHFHDxek34/discussion
> > 
> > The last patch fixing this.
> > - visual <C-A>/<C-X> support vcol. (<TAB> code free)
> > - Processing was allowed to separate.
> >   (line loop process and add/subtract process)
> >   (We have to use the existing function block_prep() to process the 
> > block-wise)
> > 
> > Sorry, more than this is difficult to separate the patch...
> > Please include this.
> 
> I have included it now.  Unfortunately there was a merge conflict with
> patch 7.4.1085.  I solved that.  Then it turns out that the marks are
> set differently.  Patch 7.4.1085 sets then before the first changed
> number and at the end of the last changed number.  Your patch put them
> on the Visual area.  I think the first solution is more accurate, thus I
> kept that.

Thanks you verrry much.  I think so.

However, I think, '[ and '] marks process is not consistent with other 
operators.
Of course, it should be modified other operator processing of the  '[ and '] 
marks.
(e.g. op_tilde() in ops.c : 2387)

The report message is required modify too.
(e.g. op_tilde() in ops.c : 2390)

I will write the patch this weekend if you are okay.

--
Best regards,
Hirohito Higashi (a.k.a h_east)


> 
> I found that OP_ADD and OP_SUBTRACT are also used in a Perl header file.
> Thus I changed them to OP_NR_ADD and OP_NR_SUB.  Not so nice...

-- 
-- 
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

--- 
You received this message because you are subscribed to the Google Groups 
"vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
For more options, visit https://groups.google.com/d/optout.

Raspunde prin e-mail lui