Patch 8.1.2126
Patch 8.1.2126
Problem:Viminfo not sufficiently tested.
Solution: Add more test cases. Clean up comments. (Yegappan Lakshmanan,
closes #5032)
Files: src/search.c, src/structs.h, src/testdir/test_viminfo.vim,
src/viminfo.c
*** ../vim-8.1.2125/src/search.c2019-10-06 22:00:08.301244080 +0200
--- src/search.c2019-10-09 21:55:06.286304147 +0200
***
*** 5783,5794
--- 5783,5800
#endif
#ifdef FEAT_VIMINFO
+ /*
+ * Return the last used search pattern at "idx".
+ */
spat_T *
get_spat(int idx)
{
return &spats[idx];
}
+ /*
+ * Return the last used search pattern index.
+ */
int
get_spat_last_idx(void)
{
*** ../vim-8.1.2125/src/structs.h 2019-09-28 19:04:06.997029566 +0200
--- src/structs.h 2019-10-09 21:55:06.286304147 +0200
***
*** 1134,1151
} vimconv_T;
/*
- * Structure used for reading from the viminfo file.
- */
- typedef struct
- {
- char_u*vir_line; // text of the current line
- FILE *vir_fd;// file descriptor
- vimconv_T vir_conv; // encoding conversion
- int vir_version;// viminfo version detected or -1
- garray_T vir_barlines; // lines starting with |
- } vir_T;
-
- /*
* Structure used for the command line history.
*/
typedef struct hist_entry
--- 1134,1139
*** ../vim-8.1.2125/src/testdir/test_viminfo.vim2019-10-04
21:20:21.779342097 +0200
--- src/testdir/test_viminfo.vim2019-10-09 21:55:06.286304147 +0200
***
*** 1,5
--- 1,7
" Test for reading and writing .viminfo
+ source check.vim
+
function Test_viminfo_read_and_write()
" First clear 'history', so that "hislen" is zero. Then set it again,
" simulating Vim starting up.
***
*** 715,740
rviminfo! Xviminfo
call assert_equal(join(repeat(["sun is rising"], 200), "\n"), @r)
call delete('Xviminfo')
let &viminfo = save_viminfo
endfunc
" Test for setting 'viminfofile' to NONE
func Test_viminfofile_none()
set viminfofile=NONE
wviminfo Xviminfo
call assert_false(filereadable('Xviminfo'))
call writefile([''], 'Xviminfo')
call assert_fails('rviminfo Xviminfo', 'E195:')
call delete('Xviminfo')
endfunc
! " Test for an unwritable 'viminfo' file
! func Test_viminfo_readonly()
! if !has('unix')
! return
! endif
call writefile([''], 'Xviminfo')
call setfperm('Xviminfo', 'r-x--')
call assert_fails('wviminfo Xviminfo', 'E137:')
call delete('Xviminfo')
endfunc
--- 717,794
rviminfo! Xviminfo
call assert_equal(join(repeat(["sun is rising"], 200), "\n"), @r)
call delete('Xviminfo')
+ let @r = ''
let &viminfo = save_viminfo
endfunc
" Test for setting 'viminfofile' to NONE
func Test_viminfofile_none()
+ let save_vif = &viminfofile
set viminfofile=NONE
wviminfo Xviminfo
call assert_false(filereadable('Xviminfo'))
call writefile([''], 'Xviminfo')
call assert_fails('rviminfo Xviminfo', 'E195:')
call delete('Xviminfo')
+ let &viminfofile = save_vif
endfunc
! " Test for an unwritable and unreadble 'viminfo' file
! func Test_viminfo_perm()
! CheckUnix
call writefile([''], 'Xviminfo')
call setfperm('Xviminfo', 'r-x--')
call assert_fails('wviminfo Xviminfo', 'E137:')
+ call setfperm('Xviminfo', '--x--')
+ call assert_fails('rviminfo Xviminfo', 'E195:')
+ call delete('Xviminfo')
+ endfunc
+
+ " Test for writing to an existing viminfo file merges the file marks
+ func XTest_viminfo_marks_merge()
+ let save_viminfo = &viminfo
+ set viminfo&vim
+ set viminfo^=%
+ enew
+ %argdelete
+ %bwipe
+
+ call writefile(repeat(['editor'], 10), 'Xbufa')
+ call writefile(repeat(['Vim'], 10), 'Xbufb')
+
+ " set marks in buffers
+ call test_settime(10)
+ edit Xbufa
+ 4mark a
+ wviminfo Xviminfo
+ edit Xbufb
+ 4mark b
+ wviminfo Xviminfo
+ %bwipe
+
+ " set marks in buffers again
+ call test_settime(20)
+ edit Xbufb
+ 6mark b
+ wviminfo Xviminfo
+ edit Xbufa
+ 6mark a
+ wviminfo Xviminfo
+ %bwipe
+
+ " Load the buffer and check the marks
+ edit Xbufa
+ rviminfo! Xviminfo
+ call assert_equal(6, line("'a"))
+ edit Xbufb
+ rviminfo! Xviminfo
+ call assert_equal(6, line("'b"))
+
+ " cleanup
+ %bwipe
call delete('Xviminfo')
+ call delete('Xbufa')
+ call delete('Xbufb')
+ call test_settime(0)
+ let &viminfo=save_viminfo
endfunc
*** ../vim-8.1.2125/src/viminfo.c 2019-09-01 16:01:25.588754537 +0200
--- src/viminfo.c 2019-10-09 21:55:06.286304147 +0200
***
*** 14,19
--- 14,31
#include "vim.h"
#include "version.h"
+ /*
+ * Structure used for reading from the viminfo file.
+ */
+ typedef struct
+ {
+ char_u*vir_line; // text of the current line
+ FILE *vir_fd;// file descriptor
+
Re: How about highlighting captured groups in regex?
Am 09.10.2019 um 18:57 schrieb Dominique Pell??:
Andy Wokula wrote
> Am 07.10.2019 um 13:51 schrieb Dominique Pell??:
> > Hi
> >
> > Vim now highlights matching text when
> > typing an Ex command like :%s/foobar/
> > I like it. But I wish that it would use
> > a different color for the regex captured group(s).
> >
> > For example, if I do :%s/foo\(bar\)/
> > I would like "bar" (the captured group) to
> > be highlighted with a different color than foo
> > in matching text, so it's easier to visually see
> > that my regexp matches and what \1 is
> > when I do :%s/foo\(bar\)/\1/. In this example
> > the regexp and captured group are obvious
> > of course, so a different color may not seem
> > useful. But it becomes more useful when the
> > the regex is more complex.
> >
> > There are 10 possibly regexp groups. Having 10
> > different colors might be overkill (not sure).
> > The same color for any group may good enough,
> > or perhaps alternative colors for \1 \2 \3...?
> >
> > I wonder whether other vim users would also
> > find it useful.
> >
> > Regards
> > Dominique
>
> What about nesting / overlapping group matches (?):
> /foo\(ba\(baz\)r\)
>
> can be several levels deep.
The outer group in your example is \1 and the
inner group is \(baz\) is \1. Highlighting of inner group
should shadow highlighting of outer groups I would
say in the common portion of the matched text.
So matching text when searching for /foo\(ba\(baz\)r\)
could look like this for example if:
* Search group is yellow
* \1 is light brown
* \2 is darker brown
xxfoobabazr__xx
But multiple colors for \1, \2 (etc) is maybe overkill.
Personally I'd be happy enough with a single color for all
captured groups, i.e.:
xxfoobabazr__xx
Regards
Dominique
What about rainbow-highlighting of parens `\(', `\)'?
Ie instead of highlighting the text, just highlight
the grouping parens.
And then, `\1', `\2' ... using the same colors.
I'd prefer that, also because weird colors will not hide
my regexp text then.
--
Andy
--
--
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/5D9E2102.7000301%40yahoo.de.
Re: How about highlighting captured groups in regex?
Andy Wokula wrote > Am 07.10.2019 um 13:51 schrieb Dominique Pell??: > > Hi > > > > Vim now highlights matching text when > > typing an Ex command like :%s/foobar/ > > I like it. But I wish that it would use > > a different color for the regex captured group(s). > > > > For example, if I do :%s/foo\(bar\)/ > > I would like "bar" (the captured group) to > > be highlighted with a different color than foo > > in matching text, so it's easier to visually see > > that my regexp matches and what \1 is > > when I do :%s/foo\(bar\)/\1/. In this example > > the regexp and captured group are obvious > > of course, so a different color may not seem > > useful. But it becomes more useful when the > > the regex is more complex. > > > > There are 10 possibly regexp groups. Having 10 > > different colors might be overkill (not sure). > > The same color for any group may good enough, > > or perhaps alternative colors for \1 \2 \3...? > > > > I wonder whether other vim users would also > > find it useful. > > > > Regards > > Dominique > > What about nesting / overlapping group matches (?): > /foo\(ba\(baz\)r\) > > can be several levels deep. The outer group in your example is \1 and the inner group is \(baz\) is \1. Highlighting of inner group should shadow highlighting of outer groups I would say in the common portion of the matched text. So matching text when searching for /foo\(ba\(baz\)r\) could look like this for example if: * Search group is yellow * \1 is light brown * \2 is darker brown xxfoobabazrxx But multiple colors for \1, \2 (etc) is maybe overkill. Personally I'd be happy enough with a single color for all captured groups, i.e.: xxfoobabazrxx Regards Dominique -- -- 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/CAON-T_gqt%3DEtZODO0izhM6P%2B9W5KC5uEDOaTGER605SNt_VUeA%40mail.gmail.com.
Re: How about highlighting captured groups in regex?
Am 07.10.2019 um 13:51 schrieb Dominique Pell??: Hi Vim now highlights matching text when typing an Ex command like :%s/foobar/ I like it. But I wish that it would use a different color for the regex captured group(s). For example, if I do :%s/foo\(bar\)/ I would like "bar" (the captured group) to be highlighted with a different color than foo in matching text, so it's easier to visually see that my regexp matches and what \1 is when I do :%s/foo\(bar\)/\1/. In this example the regexp and captured group are obvious of course, so a different color may not seem useful. But it becomes more useful when the the regex is more complex. There are 10 possibly regexp groups. Having 10 different colors might be overkill (not sure). The same color for any group may good enough, or perhaps alternative colors for \1 \2 \3...? I wonder whether other vim users would also find it useful. Regards Dominique What about nesting / overlapping group matches (?): /foo\(ba\(baz\)r\) can be several levels deep. -- Andy -- -- 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/5D9E07AB.1040304%40yahoo.de.
Re: [vim/vim] Allow redefinition of the sentence text object (#5035)
So how would a definition of a sentence text object look like? > Am 09.10.2019 um 12:57 schrieb Ainar Garipov (Vim Github Repository) > : > > Is your feature request related something that is currently hard to do? > Please describe > Currently, the definition of the sentence text object cannot be changed. This > prevents users from doing several useful things: > > Using sentence text objects with emoticons (e.g. :-)) as sentence-ending > punctuation. Note that while it is possible to require users to add a “real” > punctuation after the emoticon, some designers recommend against it. Example: > > Hey there :-) I hope you're all right. > > Using sentence text object with emojis (e.g. ☺) as sentence-ending > punctuation. Same as the above. Example: > > Hey there ☺ I hope you're all right. > > Using additional punctuation provided in Unicode, e.g. the “interrobang” mark > (‽). Example: > > Did they really do that‽ I can't believe it! > > Using American style of punctuation ordering with Unicode quotes. Example: > > “I don't like sand,” he said, “It gets everywhere.” She didn't respond. > > (A continuation of the pevious point.) Using Unicode quotes in Russian etc. > texts. Example: > > Я спросил: «Как дела?» Он мне не ответил. > > Using the Greek question mark in Greek texts. Example: > > Τι κάνεις; Όλα καλά; > > Describe the solution you'd like > An ability to redefine the sentence-ending markers would solve all these > issues. > > Describe alternatives you've considered > One alternative would be creating your own text object and remapping every > sentence-related movement. That sounds like an overkill to me, although it is > probably a working solution. > > Another alternative would be adding all those cases as “corner cases” into > the still-non-redefinable sentence text object. This sounds bad, since it > probably won't be a single change, but an ever-increasing number of changes > and complications. > > Additional context > None, I guess? > > — > You are receiving this because you are subscribed to this thread. > Reply to this email directly, view it on GitHub, or mute the thread. > > -- > -- > 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/vim/vim/issues/5035%40github.com. -- -- 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/2C31FD59-0B12-4E55-8C49-C6F81DC6F9A9%40256bit.org.
windows filename regex recognition
Hi, Here is a kind of filename in fat chars that I would like to recognize: * $FOOBBBAR_Ffbar_f_oobar_(2019-07-29) - Copie.zed.lnk* 232.0 KiB 2019 Thank you -- -- 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/5523304d-71ba-4fe5-980a-fba0da8752d6%40googlegroups.com.
