https://github.com/vim/vim/pull/4693
--
--
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 Goo
At crypt.c#L45:
> // Function pointer for initializing encryption/description.
is "decryption", not "description".
--
--
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.or
It need remove the following.
--- a/src/testdir/test_functions.vim
+++ b/src/testdir/test_functions.vim
@@ -1237,7 +1237,6 @@ func Test_platform_name()
if has('unix') && executable('uname')
let uname = system('uname')
call assert_equal(uname =~? 'BeOS', has('beos'))
-call assert_e
FYI: the previous version of cpp-coveralls 0.3.12 is installable with clang.
https://github.com/vim/vim/compare/master...ichizok:test/travis.diff
# the latest version of cpp-coveralls is 0.4.0, released a few days ago.
--
--
You received this message from the "vim_dev" maillist.
Do not top-pos
I'm sorry that I failed to confirm, set_ref_in_term() is undefined on
mingw/msvc.
fix:
https://github.com/ichizok/vim/commit/c9b6a6b121208ed26d16601c1a47930efad8f4db.diff
--
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are repl
copyID of job of terminal needs to be updated.
https://gist.github.com/ichizok/0f5559a771ae40c15616e20cd3515d2b
(this includes above fix-terminal-refcount.patch)
* Add set_ref_in_term() to update copyID of job of terminal
Ozaki Kiichi
--
--
You received this message from the "vi
n(s));
return 0;
}
```
gcc -o cursor cursor.c
vim --clean -c terminal
and execute './cursor off' on terminal buffer, then it occurs descrepancy
between cursor and input position.
Thank you.
Ozaki Kiichi
--
--
You received this message from the "vim_dev" maillist.
Do n
> First, the patch seems to prevent Vim from crashing by simply changing the
> order of the calls of XCheckTypedEvent(). This happens to work for the
> purpose because the call for PropertyNotify happens to catch the INCL
> PropertyNotify which is to be sent to the requestor prior to the actual
_due_timer()).
* thus current_exception is not cleanup and keeps freed pointer.
Ozaki Kiichi
--
--
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
> They should both respect 'iskeyword' for characters up to 255.
> So it looks like vim_iswordp() needs to be fixed.
>
Thank you. OK, my above patch has reflected this fix.
--
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are repl
> when c == 0xA0, p == "\xC2\xA0", and 'iskeyword' includes 160
>
> (e.g. iskeyword=@,48-57,_,128-167,224-235 (default on windows))
>
> then: vim_iswordc(c) == 1, but vim_iswordp(p) == 0.
After all, in the above case, should vim_iswordc(c) and vim_iswordp(p) be
whether TRUE or FALSE?
--
--
Yo
> Sorry, there's no need to add the test in Makefile because I added into
> test_alot.vim. I fixed the patch.
It is better to add it for an unit test.
maka -C src test_fillchars
--
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you ar
I updated patch.
https://gist.github.com/ichizok/1be6efa8364777cf167003e2c5676d8f
(This assumes [1], [2] is correct)
* vim_iswordp_buf() uses vim_iswordc_buf() directly
* add kword_test to test the results of vim_iswordc and vim_iswordp are
matched, in case the of enc=utf-8 and 0 <= c < 0x1
> Thanks for looking into this. The patch seems to be missing a change to
> mbyte.c. mb_get_class_buf() needs to be adjusted to use
> vim_iswordc_buf() when the character is below 256.
I'm sorry for confusing you, this patch is for only [3].
(It was unclear for me whether [1],[2] is correct or n
et_class_buf()
* vim_iswordp() should return vim_iswordp_buf(p, curbuf)
https://gist.github.com/ichizok/1be6efa8364777cf167003e2c5676d8f
Thank you.
- Ozaki Kiichi
--
--
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 in
Git detects src/objects/.dirstamp as untracked file, so better to add .dirstamp
to .gitignore.
--
--
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 r
I updated patches.
Change: test_cursorline.vim requires only view.vim of
https://groups.google.com/forum/#!topic/vim_dev/tzNKP7EDWYI .
--
--
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 h
I updated test patch; modified some test-function names.
https://gist.github.com/ichizok/4d177e3bf8cc9d47d47243577c8d847b
@h_east:
> I think that file name and function names that can be used with the whole
> test script should be named accordingly. Maybe we need a prefix?
Hmm. like 'test_opt
> Using the magic numbers is hard to understand. New options are probably
> better done with string values, such as "on", "off", and empty for not
> set. Perhaps in this case "number", "line" and "both"? But then naming
> it 'cursorlineopt' would be better.
I have tried making out 'cursorlineop
> From your description, this option behaves like a boolean. Why
> would you use the numerical values 1 and -1 instead?
Sorry for lack of a description about 'cursorlinenr=0'. I have fixed it.
That is, 'cursorlinenr' is set to:
1: highlighting the line number
0: no highlighting
-1: highlighting
I updated; changed type of 'cursorlinenr' to number.
https://gist.github.com/ichizok/8d016c1e4c791499d092
And added test.
https://gist.github.com/ichizok/aa54ecfe8aa7c94ce6711b940de16453
* which requires https://groups.google.com/forum/#!topic/vim_dev/tzNKP7EDWYI
--
--
You received this mess
https://gist.github.com/ichizok/4d177e3bf8cc9d47d47243577c8d847b
* add test_number.vim
* separate some functions from test_breakindent.vim and add view.vim
* change to easily visible expected values of tests in test_breakindent.vim
Thank you.
--
--
You received this message from the "vim_dev"
Thank you for your confirmation.
> Could you write a test for that? Thanks.
All right, I will do it.
--
--
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
--
Problem (a) is fixed by
https://groups.google.com/forum/#!topic/vim_dev/gsCnTUrkCXc
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
Test failed on osx. There is no 'xvfb'.
https://travis-ci.org/vim/vim/builds/175188779
We need skip xvfb on osx.
https://gist.github.com/ichizok/a5ca247d8150b22af81d1f29e43b798a
--
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are
Additionally;
https://github.com/vim/vim/blob/46fceaa/runtime/doc/channel.txt#L601
> Vim checks about every 10 seconds for jobs that ended.
Maybe we can drop this line :)
--
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are reply
() resumes process by
feedkeys(). Resume() must be called in callback.
# bacause... command-:sleep checks job-completed every 100msec, it inhibits
# test failing before applying fix.
Thank you.
- Ozaki Kiichi
--
--
You received this message from the "vim_dev" maillist.
Do not top-post!
> Seems like a reasonable solution. So the test fails for the current
> Vim? Or does it fail sometimes?
Sometimes. Especially, according to travis-ci, it is highly probable to fail on
Mac; about half or more.
--
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type y
gnals().
We need check sigprocmask availablity.
Thank you.
- Ozaki Kiichi
--
--
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
I updated patch.
- remove JOB_WAITED
- separate job_cleanup process from job_status
- get off jv_status check from job_still_useful, and new job_still_alive checks
jv_status and job_still_useful (i.e. job_still_alive is original
job_still_useful)
> Does that fix #1155?
Unfortunately not. But I
Thank you.
- Ozaki Kiichi
--
--
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 Goo
> Isn't this a bit too drastic? When termcap_active it should still be
> possible to output text (e.g. from another timer command).
>
> Also check msg_use_printf(). Looks like your change overrules its own
> check for termcap_active.
Hmm, yes. I think we should suppress updating screen while
do
is less then mincol, and second pos is skipped.
I think that the case of "col < mincol < col + len -1" should be also processed.
[patch]
https://gist.github.com/ichizok/f34c9018f5e9e452d3bc78cc9026a720
Thank you.
- Ozaki Kiichi
--
--
You received this message from the "vim
(snip)
wait_return
(timer発火)
ex_redraw // draw intro on normal (NOT alt-) screen buffer
ex_quit
getout
(exit) // :quit
[patch]
- check "termcap_active" in screen_valid(), except GUI.
(on GUI, this prevents executing external command)
https://g
I found still another mistake...
GET_TIMEDIFF() macro has a trailing semicolon.
This is not serious now, but is improper.
patch:
https://gist.github.com/ichizok/47df234e05f78f84b1abf4e8ca89f270
--
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below t
I updated patch.
I'm wondering:
In channel_close_on_error, when there is netbeans channel, channel_save writes
to PART_OUT, but is this right? to PART_SOCK?
--
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For mor
> Doing this with reference counting is tricky. It looks like if in
> channel_set_pipes() the may_close_part() actually closes an fd, then
> ch_to_be_closed is not decremented. Also, when debugging it's hard to
> see what happened. I think it would work to have a bitmask: Set the
> bit for the
;:messages' shows nothing and g:linecount == 0
[cause]
When one of the fds associated with job-channel reachs EOF,
job-channel are closed even if other fds has readable data.
[patch]
- Don't close job-channel until all readable fds are closed
https://gist.github.com/ichizok/6e0c00d
> ! let s:flaky = [
> ! \ 'Test_reltime()',
> ! \ 'Test_nb_basic()',
> ! \ 'Test_communicate()'
> ! \ 'Test_pipe_through_sort_some()'
> ! \ ]
There is a missing comma after 'Test_communicate()'.
--
--
You received this message from the "vim_dev" maillist.
Do not to
2016年9月10日土曜日 22時59分53秒 UTC+9 Bram Moolenaar:
> Ozaki Kiichi wrote:
>
> > > ! if (++last_timer_id < 0)
> > > ! /* Overflow! Might cause duplicates... */
> > > ! last_timer_id = 0;
> >
> > Sorry, I realized this is not proper
1
Thank you.
- Ozaki Kiichi
--
--
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 G
[complement]
> then vim hangs up and we can't intercept by Ctrl-C.
Sorry, 'hang up' is incorrect. Vim accepts key input and redraws screen,
but we can't leave from normal mode.
> https://gist.github.com/ichizok/d6637a6d368bbf1353a35441c34039a7
This patch changes:
* add 'tr_firing' variable to
ll TimerStart()
then vim hangs up and we can't intercept by Ctrl-C.
[patch]
https://gist.github.com/ichizok/d6637a6d368bbf1353a35441c34039a7
* evalfunc.c patch is not concerned with those problems, this modifies
efficiency of timer_start() slightly.
Thank you.
- Ozaki Kiichi
--
--
You r
ies to release "res_tv", so vim aborts.
https://github.com/vim/vim/blob/d77f9d5/src/channel.c#L2177
[patch]
https://gist.github.com/ichizok/e69e1745cece199b0608523998c9a0b7
Thank you.
- Ozaki Kiichi
--
--
You received this message from the "vim_dev" maillist.
Do not top-
at v7.4.1027 substantially, so it can be
useful.
Thank you.
- Ozaki Kiichi
--
--
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 thi
2016年7月21日木曜日 4時45分03秒 UTC+9 Bram Moolenaar:
> Ozaki Kiichi wrote:
>
> > I propose new conversion specifier '%v' (and '%V') of printf();
> > inspired by golang.
> >
> > This spec takes a value of any type and converts into string by
> > ec
#x27;%v', {'str' : 'abcdef', 'num' : 123, 'pt' : function('printf',
['%%'])})
{'str': 'abcdef', 'num': 123, 'pt': function('printf', ['%%'])}
" funcref
:echo printf(&
) before calling 'skipwhite()'.
[patch]
Calling 'get_tv_string_buf_chk()' to convert the value of 'expr' to string.
https://gist.github.com/ichizok/edca7401330a988501993e170d1388e8
Thank you.
- Ozaki Kiichi
--
--
You received this message from the "vim_d
changes to all systems.
Thank you.
- Ozaki Kiichi
--
--
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
of
https://groups.google.com/forum/#!msg/vim_dev/8ciQGDB-0Og/NiaJYwQHKF8J
Thank you.
- Ozaki Kiichi
--
--
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/maillis
/channel.c#L1649-L1654
so NUL terminator (of '*p') is overwritten by NL, and it causes buffer-overrun.
[patch]
fix and test.
https://gist.github.com/ichizok/5cb23d48135235983380b97b70b9978a
[additional issue]
test.vim of above outputs multiple lines to buffer, but maybe it is unexpected
and
h]
Add set_ref_in_timer() function:
https://gist.github.com/ichizok/b41ac7f68c3364a38bb07479bc9c7a49
Thank you.
- Ozaki Kiichi
--
--
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, vi
I added test_expand_dllpath.vim to above patch.
https://gist.github.com/ichizok/63af51836a7192e18bd6c92609b875e2
--
--
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/maill
781-L784
but 'compl_no_insert' is set in 'ins_compl_prep()' after that.
https://github.com/vim/vim/blob/3780bb9/src/edit.c#L868
[patch]
add 'set_completeopt()' function and set 'compl_no_insert' and
'compl_no_select' when ':set complete
hizok/63af51836a7192e18bd6c92609b875e2
* add 'P_EXPAND' to each option flags
Thank you.
- Ozaki Kiichi
--
--
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
---
/176e7a759a12f87255fd9aaf3134e516
What are your thoughts on this?
Thank you.
- Ozaki Kiichi
--
--
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 rec
Would you bear this issue in mind? ;-(
--
--
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 G
NOTE: on FreeBSD/OpenBSD, almost all socket tests in test_channel fail.
the above patch fixes those tests.
--
--
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
enBSD, when non-blocking socket tries
to connect to localhost, connect() returns 0 or -1 by connection-refused (no
listening-port).
Thank you.
- Ozaki Kiichi
--
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replyi
the number of ready descriptors, or -1 (error) ).
> So I did check the return value and made sure that select() returned 0 if it
> was called after connect() returned < 0 and set EINPROGRESS.
>
>
> Believe or not, that was why I included the condition ret == 0.
Thank you.
- Oz
if (FD_ISSET(sd, &rfds) || FD_ISSET(sd, &wfds))
{
ret = getsockopt(sd,
SOL_SOCKET, SO_ERROR, &so_error, &so_error_len);
That is, increased the frequency of checking socket error.
Thank you.
- Ozaki Kiichi
--
--
You received this message from the
Hmm, on my 10.11.3 environments, I cannot reproduce this failure...
--
--
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 becaus
> Are you saying that the Mac-specific code here is not working as
> expected?
Yes.
Thank you.
- Ozaki Kiichi
--
--
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 ht
scribes about such
behavior; but I forgot where it is, sorry..)
It appears that other *nix environments behave in the same way.
But not vice versa, so we need check socket error by getsockopt() when socket
is both readable and writeable after connect().
patch:
https://gist.github.com/ichizok
-1
let [res, _, idx] = matchstrpos(str, pat, idx)
" some procedure to res
endwhile
patch:
implementation, doc, and test.
https://gist.github.com/ichizok/4601620f1630ad15e720
Thank you.
- Ozaki Kiichi
--
--
You received this message from the "vim_dev" maillist.
Do not top-post!
2b8bae/src/alloc.h#L20
>>
> Is there any compiler that complains? Perhaps GCC with forcing ANSI C?
"gcc -ansi -pedantic" reports a warning of using C99 feature.
Thank you.
- Ozaki Kiichi
--
--
You received this message from the "vim_dev" maillist.
Do not top-post
fer to the above in some documents.
Thank you.
- Ozaki Kiichi
--
--
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 becaus
;localhost:' . a:port)
+ let handle = ch_open('localhost:' . a:port, s:chopt)
if handle < 0
call assert_false(1, "Can't open channel")
return
Thank you.
- Ozaki Kiichi
--
--
You received this message from the "vim_dev" maillist.
Do not top-pos
7e75c7
And, on OS X, ch_open() needs option waittime > 0 to pass test_channel.
patch:
use waittime option
https://gist.github.com/ichizok/30ae71b0e12b85a1f864
Thank you.
- Ozaki Kiichi
--
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply bel
7;) in spite of
start-of-line.
patch:
adjust w_skipcol
https://gist.github.com/ichizok/dfd1eeecb150e68bf3a1
Thank you.
- Ozaki Kiichi
--
--
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 informatio
typo, sorry.
- type: ggf2gl
+ type: ggf2jl
--
--
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
ctual:
-
2 24
5 57
-
It appears that content of redobuff is incorrect.
expected: 1j11
actual: 1j01
Thank you.
- Ozaki Kiichi
--
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replyi
I updated the patch; add syntax.vim changes
https://gist.github.com/ichizok/8d016c1e4c791499d092
--
--
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
---
Yo
A popup menu is not displayed when option `completeopt` includes both
`noinsert` and `noselect`.
[repro steps]
vimrc:
inoremap =ListMonths()
func! ListMonths()
call complete(col('.'), ['January', 'February', 'March',
\ 'April', 'May', 'June', 'July', 'August', 'September',
I updated the patch; applying upstream
https://gist.github.com/ichizok/a23a24158dcce3ecab58
--
--
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 rec
) increase a little.
patch:
https://gist.github.com/ichizok/a23a24158dcce3ecab58
The results of some existing tests are changed:
https://gist.github.com/ichizok/dfacb32910b63a9e32ab
Thank you.
- Ozaki Kiichi
--
--
You received this message from the "vim_dev" maillist.
Do not top-post! Ty
x27; or
'relativenumber'.
https://gist.github.com/ichizok/8d016c1e4c791499d092
Thank you.
- Ozaki Kiichi
--
--
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/
> * ":.bnext" == go next buffer,
> * ":+bnext" == go 2nd next buffer, same as ":.+1bnext".
> * ":.wincmd r" == go next window
> * ":+wincmd r" == go 2nd next window, same as ":.+1wincmd r"
>
> Thus it can be said that present ":[.-+]tabmove" behaviors have consistency,
> at least, as long as othe
> https://gist.github.com/h-east/ffabb0cdd589a5f9acd2
I'm concerned that it makes ":+tabmove" behavior be different from
":.+1tabmove".
I understand that ":+" of ":+tabmove" is a range expression,
and ":+" means ":.+1"; i.e. (current-tab-number)+1.
I also understand "[X]tabmove" ("X" is direct
fix)/lib"
* I'd like to confirm just in case..;
My patch provides only 'src/configure.in'. you regenerated 'src/auto/configure'?
At any rate, I think it is better to set '-ldl' to LIBS than LDFLAGS.
Thank you.
- Ozaki Kiichi
--
--
You received this mes
S variable.
It seems appropriate semantically, too.
https://gist.githubusercontent.com/ichizok/b0be31eaf20864326c3b/raw/781ff4b02d661ac4e74e992a07af4a0fdf315a05/configure.in.patch
Thank you.
- Ozaki Kiichi
--
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply
This patch drops "return 0;" from luaV_setref (if_lua.c:1549) against
return-type.
Its change seems to cause trouble with lua, especially luajit.
Actually I encountered SEGV problem;
[environment]
* vim +lua with luajit
* Ubuntu 14.04 x86_64 / CentOS 7 x86_64 / OS X 10.10.2
[repro steps]
vim -u
I have made a testcase.
test_nested_function.in
https://gist.github.com/ichizok/267bae46f179d72b27dc
test_nested_function.ok
https://gist.github.com/ichizok/e4787725e785e839f4ec
Thank you.
- Ozaki Kiichi
--
--
You received this message from the "vim_dev" maillist.
Do not top-post!
-definition.
I think there is an excess validation of function-name in ex_function().
https://gist.github.com/ichizok/4de1e7ef2b6d804356bc
Thank you.
- Ozaki Kiichi
--
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you
end-offset,
but it is always false after a first match, thus search-starting position
doesn't progress.
I suppose it should be checked only in a first match.
Thank you.
- Ozaki Kiichi
--
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your repl
fb7babdf41ff
" patched
call substitute(txt, '\n', '', 'g')
" 0.017540 sec.
Thank you.
- Ozaki Kiichi
--
--
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 infor
<-?
" start-of-line
echo 'hoge' =~# '\(^hoge\)' | " Expect 1, Result 1
echo 'hoge' =~# '\(\v^hoge)'| " Expect 1, Result 1
echo 'hoge' =~# '\(\V\^hoge\)' | " Expect 1, Result 1
echo 'hoge' =~# '\(\
match_add() set 'b_mod_bot' one fewer than correct value.
https://gist.github.com/ichizok/ba8c2c667f2fba07b09d
Thanks.
- Ozaki Kiichi
--
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For mo
88 matches
Mail list logo
