Re: [vim/vim] Enable new diff option linematch (PR #9661)
> This was recently merged to Neovim
> (https://github.com/neovim/neovim/pull/14537?fbclid=IwAR2QVeuXcCjZ6-Q5_UUmxBe076CxJixfVrztunS92VzjW0w9HyeX4zU09sM).
> Are you interested in merging it to vim if I update this pull request?
As I mentioned before, it's certainly an area where improvement is
desired. I haven't had time to look at the details though.
We should distinguish a few goals for optimizing how it works. Perhaps
it's possible to do this without an option, but it might be needed to
have the user pick a priority of what is most important for the current
view. This is an important decision for how to optimize the algorithm.
The three-way merge seems like something that is very useful for version
control work. There it must be prioritized to see the
original/current/new-version aligned in a way the user can easily decide
which text to end up with. This is tricky, since some text may just
have some internal changes (e.g. a variable was renamed), some may be
reordered, some may be added and some may be removed. Aligning on
"helper lines" would work well for this (those are lines with block
markers, such as { and }, empty and comment lines, and other lines that
don't contain functional code).
The second goal is to just see "what changed". The first screen shots
in this PR are a good indication: Instead of having a block of different
lines and then a block of added lines, finding the added lines where
they probably were added looks much better. As I mentioned before,
giving indent changes a low priority probably also helps a lot here.
I often add "iwhite" to the 'diffopt' option to get close to this kind
of display.
I'm not sure about the example where all three buffers have three lines
that differ. Making the diff higher than three lines because it seems
they are different lines, instead of slightly changed lines, is a bit
doubtful. How can you decide two lines are too different to consider
them to be changed instead of replaced?
--
hundred-and-one symptoms of being an internet addict:
39. You move into a new house and setup the Wifi router before
unpacking any kitchen stuff.
/// Bram Moolenaar -- b...@moolenaar.net -- http://www.Moolenaar.net \\\
/// \\\
\\\sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ ///
\\\help me help AIDS victims -- http://ICCF-Holland.org///
--
--
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 vim_dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/vim_dev/20221112010040.4925B1C0473%40moolenaar.net.
Patch 9.0.0861
Patch 9.0.0861 (after 9.0.0858)
Problem:Solution for "!!sort" in closed fold is not optimal.
Solution: Use a different range instead of the subtle difference in handling
a range with an offset. (issue #11487)
Files: runtime/doc/cmdline.txt, src/ops.c, src/ex_docmd.c,
src/testdir/test_fold.vim
*** ../vim-9.0.0860/runtime/doc/cmdline.txt 2022-10-04 16:23:39.002042197
+0100
--- runtime/doc/cmdline.txt 2022-11-11 22:51:01.745976916 +
***
*** 736,742
--- 736,744
'T position of mark T (uppercase); when the mark is in
another file it cannot be used in a range
/{pattern}[/] the next line where {pattern} matches *:/*
+ also see |:range-pattern| below
?{pattern}[?] the previous line where {pattern} matches *:?*
+ also see |:range-pattern| below
\/ the next line where the previously used search
pattern matches
\? the previous line where the previously used search
***
*** 744,754
--- 746,794
\& the next line where the previously used substitute
pattern matches
+ *:range-offset*
Each may be followed (several times) by '+' or '-' and an optional number.
This number is added or subtracted from the preceding line number. If the
number is omitted, 1 is used. If there is nothing before the '+' or '-' then
the current line is used.
+ *:range-closed-fold*
+ When a line number after the comma is in a closed fold it is adjusted to the
+ last line of the fold, thus the whole fold is included.
+
+ When a number is added this is done after the adjustment to the last line of
+ the fold. This means these lines are additionally included in the range. For
+ example: >
+:3,4+2print
+ On this text:
+ 1 one ~
+ 2 two ~
+ 3 three ~
+ 4 four FOLDED ~
+ 5 five FOLDED ~
+ 6 six ~
+ 7 seven ~
+ 8 eight ~
+ Where lines four and five are a closed fold, ends up printing lines 3 to 7.
+ The 7 comes from the "4" in the range, which is adjusted to the end of the
+ closed fold, which is 5, and then the offset 2 is added.
+
+ An example for subtracting (which isn't very useful): >
+:2,4-1print
+ On this text:
+ 1 one ~
+ 2 two ~
+ 3 three FOLDED~
+ 4 four FOLDED ~
+ 5 five FOLDED ~
+ 6 six FOLDED ~
+ 7 seven ~
+ 8 eight ~
+ Where lines three to six are a closed fold, ends up printing lines 2 to 6.
+ The 6 comes from the "4" in the range, which is adjusted to the end of the
+ closed fold, which is 6, and then 1 is subtracted, then this is still in the
+ closed fold and the last line of that fold is used, which is 6.
+ *:range-pattern*
The "/" and "?" after {pattern} are required to separate the pattern from
anything that follows.
***
*** 804,812
Count and Range *N:*
! When giving a count before entering ":", this is translated into:
:.,.+(count - 1)
! In words: The 'count' lines at and after the cursor. Example: To delete
three lines: >
3:d is translated into: .,.+2d
<
--- 844,852
Count and Range *N:*
! When giving a count before entering ":", this is translated into: >
:.,.+(count - 1)
! In words: The "count" lines at and after the cursor. Example: To delete
three lines: >
3:d is translated into: .,.+2d
<
*** ../vim-9.0.0860/src/ops.c 2022-10-15 16:41:49.780490432 +0100
--- src/ops.c 2022-11-11 22:02:21.689369371 +
***
*** ,3346
stuffcharReadbuff('.');
else
stuffnumReadbuff((long)oap->start.lnum);
! if (oap->end.lnum != oap->start.lnum)
{
stuffcharReadbuff(',');
if (oap->end.lnum == curwin->w_cursor.lnum)
stuffcharReadbuff('.');
else if (oap->end.lnum == curbuf->b_ml.ml_line_count)
stuffcharReadbuff('$');
! else if (oap->start.lnum == curwin->w_cursor.lnum)
{
stuffReadbuff((char_u *)".+");
stuffnumReadbuff((long)oap->line_count - 1);
--- ,3364
stuffcharReadbuff('.');
else
stuffnumReadbuff((long)oap->start.lnum);
!
! #ifdef FEAT_FOLDING
! // When using !! on a closed fold the range ".!" works best to operate
! // on, it will be made the whole closed fold later.
! linenr_T endOfStartFold = oap->start.lnum;
! (void)hasFolding(oap->start.lnum, NULL, );
! #endif
! if
Patch 9.0.0860
Patch 9.0.0860
Problem:MS-Windows: windres fails with clang 15.0.4.
Solution: Use llvm-windres. (John Marriott)
Files: src/Make_cyg_ming.mak
*** ../vim-9.0.0859/src/Make_cyg_ming.mak 2022-10-08 19:26:35.694195418
+0100
--- src/Make_cyg_ming.mak 2022-11-11 21:22:10.071162312 +
***
*** 227,233
--- 227,237
ifeq ($(UNDER_CYGWIN),yes)
WINDRES := $(CROSS_COMPILE)windres
else
+ ifeq ($(findstring clang,$(CC)),)
WINDRES := windres
+ else
+ WINDRES := llvm-windres
+ endif
endif
# Get the default ARCH.
*** ../vim-9.0.0859/src/version.c 2022-11-11 01:40:44.430990388 +
--- src/version.c 2022-11-11 21:23:07.775220154 +
***
*** 697,698
--- 697,700
{ /* Add new patch number below this line */
+ /**/
+ 860,
/**/
--
I started out with nothing, and I still have most of it.
-- Michael Davis -- "Tonight Show"
/// Bram Moolenaar -- b...@moolenaar.net -- http://www.Moolenaar.net \\\
/// \\\
\\\sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ ///
\\\help me help AIDS victims -- http://ICCF-Holland.org///
--
--
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 vim_dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/vim_dev/2022212510.6B6221C1263%40moolenaar.net.
Re: clang 15.0.4 windres error
John Marriott wrote: > When compiling with clang x64 15.0.4 (from msys2) on Win8.1 x64, I get > this error from windres: > > windres -DWIN32 -DWINVER=0x0603 -D_WIN32_WINNT=0x0603 -DHAVE_PATHDEF > -DFEAT_NORMAL -DHAVE_STDINT_H -DMS_WIN64 -DFEAT_GUI_MSWIN -DFEAT_CLIPBOARD \ > --input-format=rc --output-format=coff -i vim.rc -o gobjx86-64/vimres.o > windres: preprocessing failed. > make: *** [Make_cyg_ming.mak:1222: gobjx86-64/vimres.o] Error 1 > > > The attached patch is probably not the best fix but it corrects it for me. Thanks, I'll include it. -- Don't believe everything you hear or anything you say. /// Bram Moolenaar -- b...@moolenaar.net -- http://www.Moolenaar.net \\\ /// \\\ \\\sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ /// \\\help me help AIDS victims -- http://ICCF-Holland.org/// -- -- 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 vim_dev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/vim_dev/2022212510.66A541C120E%40moolenaar.net.
clang 15.0.4 windres error
Hi All, When compiling with clang x64 15.0.4 (from msys2) on Win8.1 x64, I get this error from windres: windres -DWIN32 -DWINVER=0x0603 -D_WIN32_WINNT=0x0603 -DHAVE_PATHDEF -DFEAT_NORMAL -DHAVE_STDINT_H -DMS_WIN64 -DFEAT_GUI_MSWIN -DFEAT_CLIPBOARD \ --input-format=rc --output-format=coff -i vim.rc -o gobjx86-64/vimres.o windres: preprocessing failed. make: *** [Make_cyg_ming.mak:1222: gobjx86-64/vimres.o] Error 1 The attached patch is probably not the best fix but it corrects it for me. Cheers John -- -- 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 vim_dev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/vim_dev/e6116376-98c8-b211-192f-2a416399a499%40internode.on.net. --- Make_cyg_ming.mak.orig 2022-10-15 06:24:24.0 +1100 +++ Make_cyg_ming.mak 2022-11-12 06:48:03.371617100 +1100 @@ -227,7 +227,11 @@ ifeq ($(UNDER_CYGWIN),yes) WINDRES := $(CROSS_COMPILE)windres else +ifeq ($(findstring clang,$(CC)),) WINDRES := windres +else +WINDRES := llvm-windres +endif endif # Get the default ARCH.
Re: Patch 9.0.0858
I wrote: > Patch 9.0.0858 > Problem:"!!sort" in a closed fold sorts too many lines. > Solution: Round to end of fold after adding the line count. (closes #11487) > Files: src/ex_docmd.c, src/testdir/test_fold.vim I had been working on this and decided to finish it, but looking back I'm not happy with this solution. As I mentioned before, there are two options: - Expanding "!!" and then handling the expanded range - this seemed like the most user-friendly way, because you can see a range of lines is going to be operated upon before you hit Enter. - Not expanding "!!" and including the whole fold when turning it into line numbers. This doesn't give any hint about including the whole fold, thus it seemed not the best choice. However, it turns out that we have an existing behavior that interferes: Adding an offset to a range with a fold allowed for excluding or including some lines above/below the end of the fold. The second line number is adjusted to the end of the closed fold before adding/subtracting the offset. Not sure if this is being actively used, but at least there is a test for it. I worked around it by checking for a dot before the offset. That's what we get when expanding "!!" and the tests didn't have the dot, so it works, the tests pass. But it's a very subtle difference that most likely confuses users, it requires reading the help to find out the details. This is really a choice between the two options that are neither good. At this moment I think not expanding "!!" would be slightly better than the presence of a dot making a difference. Unless someone objects, I'm going for the other choice. -- Everybody lies, but it doesn't matter since nobody listens. -- Lieberman's Law /// Bram Moolenaar -- b...@moolenaar.net -- http://www.Moolenaar.net \\\ /// \\\ \\\sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ /// \\\help me help AIDS victims -- http://ICCF-Holland.org/// -- -- 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 vim_dev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/vim_dev/2022114331.653CE1C108B%40moolenaar.net.
