Re: [patch] :make doesn't support encoding conversion
Hi Bram,
2016/8/18 Thu 6:17:48 UTC+9 Bram Moolenaar wrote:
> Ken Takata wrote:
>
> > I wrote a patch for the following todo item:
> >
> > > Win32: When running ":make" and 'encoding' differs from the system
> > > locale, the
> > > output should be converted. Esp. when 'encoding' is "utf-8". (Yongwei Wu)
> > > Should we use 'termencoding' for this?
> >
> > I think using 'termencoding' for this is not so good. Normally the encoding
> > of a command output is the same as the encoding of the terminal, but not
> > always the same. I hear that some commands on Windows use utf-8 instead of
> > the current codepage. So I added a new option 'cmdencoding' ('cenc').
> > What do you think of this?
>
> Seems reasonable. It's not nice that it's yet another option. But in
> case you know the compiler output is in a certain encoding it's the only
> way to make it work.
>
> Why they "char" value? It's using the system locale, wouldn't "system"
> be better? Hmm, I don't see where "char" is recognized.
At least, GNU libiconv supports "char".
See: https://www.gnu.org/software/libiconv/
| Locale dependent, in terms of `char' or `wchar_t' (with machine dependent
| endianness and alignment, and with OS and locale dependent semantics)
| char, wchar_t
| The empty encoding name "" is equivalent to "char": it denotes the locale
| dependent character encoding.
I don't know about other iconv implementations.
Regards,
Ken Takata
--
--
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.
For more options, visit https://groups.google.com/d/optout.
Re: Vim 8 pre-announcement
Hi,
On Wed, Aug 17, 2016 at 2:17 PM, Bram Moolenaar wrote:
>
> Yegappan Lakshmanan wrote:
>
>> On Wed, Aug 17, 2016 at 2:10 AM, 'Guyzmo' via vim_dev
>> wrote:
>> > On Wed, Aug 17, 2016 at 11:48:23AM +0300, LCD 47 wrote:
>> >> On 16 August 2016, Yegappan Lakshmanan wrote:
>> >> > getbufinfo()
>> >> "options", "signs", and "variables" return lists that are potentially
>> >> huge. Perhaps there should be a way to tell getbufinfo() to skip these
>> >> lists;
>> >> otherwise plugins would just avoid calling this function, for performance
>> >> reasons.
>> >
>> > I share the opinion that having a mechanism to select and/or exclude
>> > keys from the dict to avoid loading and carrying around huge dicts
>> > sounds a great thing.
>> >
>> >> > gettabinfo()
>> >> > getwininfo()
>> >>
>> >> From the manual:
>> >>
>> >> : Each List item is a Dictionary with the following entries:
>> >> : bufnum number of buffer in the window
>> >> : height window height
>> >> : loclist 1 if showing a location list
>> >> : {only with the +quickfix feature}
>> >> : nr window number
>> >> : options dictionary of window local options
>> >> : quickfix1 if quickfix or location list
>> >> window
>> >> : {only with the +quickfix feature}
>> >> : tpnrtab page number
>> >> : variables dictionary of window local variables
>> >> : width window width
>> >> : winid window ID
>> >>
>> >> Perhaps "tpnr" should be renamed to something more suggestive, such as
>> >> "tabnr"?
>> >
>> > I guess this should apply also for the window, as `winnr` for example,
>> > for consistency in the keys naming scheme.
>> >
>>
>> Note that window ID is different from window number. The getwininfo()
>> function returns both the window ID (winid field) and the window
>> number (nr field). Are you suggesting to rename the "nr" field to winnr?
>
> In most places "winnr" is used. And also "bufnr" instead of "nr" for
> buffers. getqflist() also uses "bufnr". And uses "nr" for the quickfix
> list nr (that's OK).
>
I am attaching a patch to rename the keys returned by the getbufinfo(),
gettabinfo() and getwininfo() functions.
- Yegappan
--
--
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.
For more options, visit https://groups.google.com/d/optout.
diff --git a/runtime/doc/eval.txt b/runtime/doc/eval.txt
index 32d8dad..f7e89c2 100644
--- a/runtime/doc/eval.txt
+++ b/runtime/doc/eval.txt
@@ -4004,6 +4004,7 @@ getbufinfo([{dict}])
Each returned List item is a dictionary with the following
entries:
+ bufnr buffer number.
changed TRUE if the buffer is modified.
changedtick number of changes made to the buffer.
hidden TRUE if the buffer is hidden.
@@ -4011,7 +4012,6 @@ getbufinfo([{dict}])
lnumcurrent line number in buffer.
loaded TRUE if the buffer is loaded.
namefull path to the file in the buffer.
- nr buffer number.
options dictionary of buffer local options.
signs list of signs placed in the buffer.
Each list item is a dictionary with
@@ -4529,7 +4529,7 @@ gettabinfo([{arg}])
*gettabinfo()*
empty List is returned.
Each List item is a Dictionary with the following entries:
- nr tab page number.
+ tabnr tab page number.
variables dictionary of tabpage local variables.
windows List of window IDs in the tag page.
@@ -4585,18 +4585,18 @@ getwininfo([{winid}])
*getwininfo()*
pages is returned.
Each List item is a Dictionary with the following entries:
- bufnum number of buffer in the window
+ bufnr number of buffer in the window
height window height
loclis
Re: Vim 8 pre-announcement
2016-08-18 0:17 GMT+03:00 Bram Moolenaar : > > Skywind3000 wrote: > >> > Hello Vim users, >> > >> > Work on Vim 8.0 is coming close to an end. I hope version 8.0 can be >> > released in about two weeks. >> > >> > This is a last chance to modify new features in a way that is not >> > backwards compatible. Once 8.0 is out we can't make changes that would >> > break plugins. >> >> Can we have a binary mode in channels ? Which could be used to implement >> a virtual terminal inside vim in VimScript. >> >> According to the ":help channel", There is a "raw" mode in channels, but it >> will treat the whole message as a string, not a binary data. > > Raw mode is nearly binary. The only limitation I'm aware of is that it > can't handle NUL bytes. And since there is no way to deal with binary > data anyway in Vim script, it's probably the only thing possible. Neovim handled this just fine from the very beginning: just callback receives not a string, but a `readfile(,'b')`-style list. Though it led to some confusion (line `"abc\n"` may be received as `['abc', '']` or `['ab']` and `['c', '']`, but some plugin authors thought that Neovim is waiting for line to finish, so `'ab'` in the second example is the whole line), this is the only normal way to represent binary data in VimL. Another variant is a list like `[0x61, 0x62, 0x63, 0x0A]` which has very high overhead. > > An alternative is NL mode, then you get lines at a time where NUL bytes > have been changed to NL bytes. But it will be stuck waiting for the > next NL. > > -- > This planet has -- or rather had -- a problem, which was this: most > of the people living on it were unhappy for pretty much of the time. > Many solutions were suggested for this problem, but most of these > were largely concerned with the movements of small green pieces of > paper, which is odd because on the whole it wasn't the small green > pieces of paper that were unhappy. > -- Douglas Adams, "The Hitchhiker's Guide to the Galaxy" > > /// Bram Moolenaar -- b...@moolenaar.net -- http://www.Moolenaar.net \\\ > ///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\ > \\\ an exciting new programming language -- http://www.Zimbu.org/// > \\\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. > For more options, visit https://groups.google.com/d/optout. -- -- 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. For more options, visit https://groups.google.com/d/optout.
Re: error in test_startup_utf8
Hi, 2016/8/18 Thu 5:36:51 UTC+9 Danek Duvall wrote: > On Wed, Aug 17, 2016 at 09:52:12PM +0200, Bram Moolenaar wrote: > > > Danek Duvall wrote: > > > > > I'm seeing this. It's on Solaris, but I'm not sure whether that matters, > > > or if it does, what aspect does. > > > > > > From test_startup_utf8.vim: > > > Found errors in Test_read_fifo_utf8(): > > > function RunTheTest[9]..Test_read_fifo_utf8 line 24: Expected ['テスト', > > > '€ÀÈÌÒÙ'] but got [] > > > > > > When I run the RunVim command standalone: > > > > > > ../vim -f -u NONE -U NONE --noplugin --not-a-term --cmd "so b" <(cat > > > Xtestin) > > > > > > I do in fact get nothing in the buffer, and a warning in the status line > > > > > > "/dev/fd/12" [character special][converted][READ ERRORS] 0 lines, 0 > > > characters > > > > > > I get the same thing if I remove cp932 from fencs and add ascii, but > > > latin1 > > > gives me something, at least. Aren't errors in conversion supposed to be > > > ignored and move vim on to the next entry in fencs, or am I > > > misunderstanding that whole thing? > > > > It is supposed to work. No idea why it fails in your situation. > > Would require debugging (or adding some printf's). > > Hm. Any suggestions on where to start? Am I right that it should try to > convert from cp932, fail, and then try utf8? Is there anything I can do > with the iconv command that could demonstrate that there's something wrong > with iconv on the system? Does Solaris have S_ISFIFO()? If not, it might happen. Could you try the attached patch? > Am I right that it should try to > convert from cp932, fail, and then try utf8? Yes, right. Regards, Ken Takata -- -- 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. For more options, visit https://groups.google.com/d/optout. # HG changeset patch # Parent 4b9116734e30ebc49a24b2e972c86df402d39499 diff --git a/src/buffer.c b/src/buffer.c --- a/src/buffer.c +++ b/src/buffer.c @@ -216,9 +216,13 @@ open_buffer( if (perm >= 0 && (0 # ifdef S_ISFIFO || S_ISFIFO(perm) +# elif defined(S_IFIFO) + || ((perm & S_IFMT) == S_IFIFO) # endif # ifdef S_ISSOCK || S_ISSOCK(perm) +# elif defined(S_IFSOCK) + || ((perm & S_IFMT) == S_IFSOCK) # endif )) read_fifo = TRUE;
[patch] test62.{in,ok} convert to the new style test `test_tabpage.vim`
Hi Bram and list,
Attach a patch.
Please include this.
--
Best regards,
Hirohito Higashi (a.k.a. h_east)
--
--
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.
For more options, visit https://groups.google.com/d/optout.
diff --git a/src/Makefile b/src/Makefile
index 28b4b20..5d895f1 100644
--- a/src/Makefile
+++ b/src/Makefile
@@ -2041,7 +2041,7 @@ test1 \
test30 test31 test32 test33 test34 test36 test37 test38 test39 \
test40 test41 test42 test43 test44 test45 test46 test48 test49 \
test50 test51 test52 test53 test54 test55 test56 test57 test58 test59 \
- test60 test62 test64 test65 test66 test67 test68 test69 \
+ test60 test64 test65 test66 test67 test68 test69 \
test70 test71 test72 test73 test74 test75 test76 test77 test78 test79 \
test80 test81 test82 test83 test84 test85 test86 test87 test88 test89 \
test90 test91 test92 test93 test94 test95 test97 test98 test99 \
@@ -2122,6 +2122,7 @@ test_arglist \
test_syn_attr \
test_syntax \
test_tabline \
+ test_tabpage \
test_tagjump \
test_textobjects \
test_timers \
diff --git a/src/testdir/Make_all.mak b/src/testdir/Make_all.mak
index 2762a39..19973d5 100644
--- a/src/testdir/Make_all.mak
+++ b/src/testdir/Make_all.mak
@@ -50,7 +50,6 @@ SCRIPTS_ALL = \
test56.out \
test57.out \
test60.out \
- test62.out \
test64.out \
test65.out \
test66.out \
diff --git a/src/testdir/test62.in b/src/testdir/test62.in
deleted file mode 100644
index c437f36..000
--- a/src/testdir/test62.in
+++ /dev/null
@@ -1,205 +0,0 @@
-Tests for tab pages
-
-STARTTEST
-:so small.vim
-:lang C
-:" Simple test for opening and closing a tab page
-:tabnew
-:let nr = tabpagenr()
-:q
-:call append(line('$'), 'tab page ' . nr)
-:unlet nr
-:"
-:" Open three tab pages and use ":tabdo"
-:0tabnew
-:1tabnew
-:$tabnew
-:tabdo call append(line('$'), 'this is tab page ' . tabpagenr())
-:tabclose! 2
-:tabrewind
-:let line1 = getline('$')
-:undo
-:q
-:tablast
-:let line2 = getline('$')
-:q!
-:call append(line('$'), line1)
-:call append(line('$'), line2)
-:unlet line1 line2
-:"
-:" Test for settabvar() and gettabvar() functions. Open a new tab page and
-:" set 3 variables to a number, string and a list. Verify that the variables
-:" are correctly set.
-:tabnew
-:tabfirst
-:call settabvar(2, 'val_num', 100)
-:call settabvar(2, 'val_str', 'SetTabVar test')
-:call settabvar(2, 'val_list', ['red', 'blue', 'green'])
-:"
-:let test_status = 'gettabvar: fail'
-:if gettabvar(2, 'val_num') == 100 && gettabvar(2, 'val_str') == 'SetTabVar test' && gettabvar(2, 'val_list') == ['red', 'blue', 'green']
-:let test_status = 'gettabvar: pass'
-:endif
-:call append(line('$'), test_status)
-:"
-:tabnext 2
-:let test_status = 'settabvar: fail'
-:if t:val_num == 100 && t:val_str == 'SetTabVar test' && t:val_list == ['red', 'blue', 'green']
-: let test_status = 'settabvar: pass'
-:endif
-:tabclose
-:call append(line('$'), test_status)
-:"
-:if has('gui') || has('clientserver')
-:" Test for ":tab drop exist-file" to keep current window.
-:sp test1
-:tab drop test1
-:let test_status = 'tab drop 1: fail'
-:if tabpagenr('$') == 1 && winnr('$') == 2 && winnr() == 1
-:let test_status = 'tab drop 1: pass'
-:endif
-:close
-:call append(line('$'), test_status)
-:"
-:"
-:" Test for ":tab drop new-file" to keep current window of tabpage 1.
-:split
-:tab drop newfile
-:let test_status = 'tab drop 2: fail'
-:if tabpagenr('$') == 2 && tabpagewinnr(1, '$') == 2 && tabpagewinnr(1) == 1
-:let test_status = 'tab drop 2: pass'
-:endif
-:tabclose
-:q
-:call append(line('$'), test_status)
-:"
-:"
-:" Test for ":tab drop multi-opend-file" to keep current tabpage and window.
-:new test1
-:tabnew
-:new test1
-:tab drop test1
-:let test_status = 'tab drop 3: fail'
-:if tabpagenr() == 2 && tabpagewinnr(2, '$') == 2 && tabpagewinnr(2) == 1
-:let test_status = 'tab drop 3: pass'
-:endif
-:tabclose
-:q
-:call append(line('$'), test_status)
-:else
-:" :drop not supported
-:call append(line('$'), 'tab drop 1: pass')
-:call append(line('$'), 'tab drop 2: pass')
-:call append(line('$'), 'tab drop 3: pass')
-:endif
-:"
-:"
-:for i in range(9) | tabnew | endfor
-1gt
-:$put =tabpagenr()
-:tabmove 5
-:$put =tabpagenr()
-:.tabmove
-:$put =tabpagenr()
-:tabmove -
-:$put =tabpagenr()
-:tabmove +
-:$put =tabpagenr()
-:tabmove -2
-:$put =tabpagenr()
-:tabmove +4
-:$put =tabpagenr()
-:tabmove
-:$put =tabpagenr()
-:tabmove -20
-:$put =tabpagenr()
-:tabmove +20
-:$put =tabpagenr()
-:0tabmove
-:$put =tabpagenr()
-:$tabmove
-:$put =tabpagenr()
-:tabmove 0
-:$put =tabpagenr()
-:tabmove $
-:$put =tabpagenr()
-:3tabmove
-:$put =tabpagenr()
-:7tabmove 5
-:$put =tabpa
Re: Vim 8 pre-announcement
Skywind3000 wrote: > > Hello Vim users, > > > > Work on Vim 8.0 is coming close to an end. I hope version 8.0 can be > > released in about two weeks. > > > > This is a last chance to modify new features in a way that is not > > backwards compatible. Once 8.0 is out we can't make changes that would > > break plugins. > > Can we have a binary mode in channels ? Which could be used to implement > a virtual terminal inside vim in VimScript. > > According to the ":help channel", There is a "raw" mode in channels, but it > will treat the whole message as a string, not a binary data. Raw mode is nearly binary. The only limitation I'm aware of is that it can't handle NUL bytes. And since there is no way to deal with binary data anyway in Vim script, it's probably the only thing possible. An alternative is NL mode, then you get lines at a time where NUL bytes have been changed to NL bytes. But it will be stuck waiting for the next NL. -- This planet has -- or rather had -- a problem, which was this: most of the people living on it were unhappy for pretty much of the time. Many solutions were suggested for this problem, but most of these were largely concerned with the movements of small green pieces of paper, which is odd because on the whole it wasn't the small green pieces of paper that were unhappy. -- Douglas Adams, "The Hitchhiker's Guide to the Galaxy" /// Bram Moolenaar -- b...@moolenaar.net -- http://www.Moolenaar.net \\\ ///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\ \\\ an exciting new programming language -- http://www.Zimbu.org/// \\\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. For more options, visit https://groups.google.com/d/optout.
Re: Vim 8 pre-announcement
Thinca wrote: > :help job-term says: > > *job-term* > "term": "open"Start a terminal and connect the job > stdin/stdout/stderr to it. > NOTE: Not implemented yet! > > This is not implemented yet. Is this not implemented in Vim 8.0? It would be useful, especially when running a job that has output. Or when it prompts for input. It's not so easy to do. At least in a way that it works on most systems. But, if someone sends a patch... -- The technology involved in making anything invisible is so infinitely complex that nine hundred and ninety-nine billion, nine hundred and ninety-nine million, nine hundred and ninety-nine thousand, nine hundred and ninety-nine times out of a trillion it is much simpler and more effective just to take the thing away and do without it. -- Douglas Adams, "The Hitchhiker's Guide to the Galaxy" /// Bram Moolenaar -- b...@moolenaar.net -- http://www.Moolenaar.net \\\ ///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\ \\\ an exciting new programming language -- http://www.Zimbu.org/// \\\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. For more options, visit https://groups.google.com/d/optout.
Re: Patch 7.4.2219
Andy Wokula wrote: > Am 16.08.2016 um 21:04 schrieb Bram Moolenaar: > > Patch 7.4.2219 > > Problem:Recursive call to substitute gets stuck in sandbox. (Nikolai > > Pavlov) > > Solution: Handle the recursive call. (Christian Brabandt, closes #950) > > Add a test. > > Files: src/ex_cmds.c, src/testdir/test_regexp_latin.vim > > What about recursive sub-replace-\= ? > > (fixed as well? related at all? already fixed?) Well, try to come up with an example that doesn't work. -- The History of every major Galactic Civilization tends to pass through three distinct and recognizable phases, those of Survival, Inquiry and Sophistication, otherwise known as the How, Why and Where phases. For instance, the first phase is characterized by the question 'How can we eat?' the second by the question 'Why do we eat?' and the third by the question 'Where shall we have lunch?' -- Douglas Adams, "The Hitchhiker's Guide to the Galaxy" /// Bram Moolenaar -- b...@moolenaar.net -- http://www.Moolenaar.net \\\ ///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\ \\\ an exciting new programming language -- http://www.Zimbu.org/// \\\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. For more options, visit https://groups.google.com/d/optout.
Re: Vim 8 pre-announcement
Andy Wokula wrote: > Am 16.08.2016 um 18:43 schrieb Bram Moolenaar: > > Hello Vim users, > > > > Work on Vim 8.0 is coming close to an end. I hope version 8.0 can be > > released in about two weeks. > > > > This is a last chance to modify new features in a way that is not > > backwards compatible. Once 8.0 is out we can't make changes that would > > break plugins. > > Can we have 'langnoremap' renamed to 'langremap' please? > > Double negation is confusing. > > And it's more consistent with 'remap' (although that option should be removed > ...). I agree that double negative is confusing. I don't recall why we got to the current name. Changing it now will cause some trouble for those who are using it, but not changing it may be worse. -- Time is an illusion. Lunchtime doubly so. -- Ford Prefect, in Douglas Adams' "The Hitchhiker's Guide to the Galaxy" /// Bram Moolenaar -- b...@moolenaar.net -- http://www.Moolenaar.net \\\ ///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\ \\\ an exciting new programming language -- http://www.Zimbu.org/// \\\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. For more options, visit https://groups.google.com/d/optout.
Re: [patch] :make doesn't support encoding conversion
Ken Takata wrote:
> I wrote a patch for the following todo item:
>
> > Win32: When running ":make" and 'encoding' differs from the system locale,
> > the
> > output should be converted. Esp. when 'encoding' is "utf-8". (Yongwei Wu)
> > Should we use 'termencoding' for this?
>
> I think using 'termencoding' for this is not so good. Normally the encoding
> of a command output is the same as the encoding of the terminal, but not
> always the same. I hear that some commands on Windows use utf-8 instead of
> the current codepage. So I added a new option 'cmdencoding' ('cenc').
> What do you think of this?
Seems reasonable. It's not nice that it's yet another option. But in
case you know the compiler output is in a certain encoding it's the only
way to make it work.
Why they "char" value? It's using the system locale, wouldn't "system"
be better? Hmm, I don't see where "char" is recognized.
> It would be nice, if `:make` and other commands would support encoding
> detection, but I think it's difficult because `:make` reads the output
> line by line. So encoding detection is not implemented now.
Yes, this would make it a lot more complicated.
--
The startling truth finally became apparent, and it was this: Numbers
written on restaurant checks within the confines of restaurants do not follow
the same mathematical laws as numbers written on any other pieces of paper in
any other parts of the Universe. This single statement took the scientific
world by storm. So many mathematical conferences got held in such good
restaurants that many of the finest minds of a generation died of obesity and
heart failure, and the science of mathematics was put back by years.
-- Douglas Adams, "The Hitchhiker's Guide to the Galaxy"
/// Bram Moolenaar -- b...@moolenaar.net -- http://www.Moolenaar.net \\\
///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\ an exciting new programming language -- http://www.Zimbu.org///
\\\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.
For more options, visit https://groups.google.com/d/optout.
Re: Vim 8 pre-announcement
Yegappan Lakshmanan wrote:
> On Wed, Aug 17, 2016 at 2:10 AM, 'Guyzmo' via vim_dev
> wrote:
> > On Wed, Aug 17, 2016 at 11:48:23AM +0300, LCD 47 wrote:
> >> On 16 August 2016, Yegappan Lakshmanan wrote:
> >> > getbufinfo()
> >> "options", "signs", and "variables" return lists that are potentially
> >> huge. Perhaps there should be a way to tell getbufinfo() to skip these
> >> lists;
> >> otherwise plugins would just avoid calling this function, for performance
> >> reasons.
> >
> > I share the opinion that having a mechanism to select and/or exclude
> > keys from the dict to avoid loading and carrying around huge dicts
> > sounds a great thing.
> >
> >> > gettabinfo()
> >> > getwininfo()
> >>
> >> From the manual:
> >>
> >> : Each List item is a Dictionary with the following entries:
> >> : bufnum number of buffer in the window
> >> : height window height
> >> : loclist 1 if showing a location list
> >> : {only with the +quickfix feature}
> >> : nr window number
> >> : options dictionary of window local options
> >> : quickfix1 if quickfix or location list window
> >> : {only with the +quickfix feature}
> >> : tpnrtab page number
> >> : variables dictionary of window local variables
> >> : width window width
> >> : winid window ID
> >>
> >> Perhaps "tpnr" should be renamed to something more suggestive, such as
> >> "tabnr"?
> >
> > I guess this should apply also for the window, as `winnr` for example,
> > for consistency in the keys naming scheme.
> >
>
> Note that window ID is different from window number. The getwininfo()
> function returns both the window ID (winid field) and the window
> number (nr field). Are you suggesting to rename the "nr" field to winnr?
In most places "winnr" is used. And also "bufnr" instead of "nr" for
buffers. getqflist() also uses "bufnr". And uses "nr" for the quickfix
list nr (that's OK).
--
Tips for aliens in New York: Land anywhere. Central Park, anywhere.
No one will care or indeed even notice.
-- Douglas Adams, "The Hitchhiker's Guide to the Galaxy"
/// Bram Moolenaar -- b...@moolenaar.net -- http://www.Moolenaar.net \\\
///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\ an exciting new programming language -- http://www.Zimbu.org///
\\\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.
For more options, visit https://groups.google.com/d/optout.
Re: error in test_startup_utf8
On Wed, Aug 17, 2016 at 09:52:12PM +0200, Bram Moolenaar wrote: > Danek Duvall wrote: > > > I'm seeing this. It's on Solaris, but I'm not sure whether that matters, > > or if it does, what aspect does. > > > > From test_startup_utf8.vim: > > Found errors in Test_read_fifo_utf8(): > > function RunTheTest[9]..Test_read_fifo_utf8 line 24: Expected ['テスト', > > '€ÀÈÌÒÙ'] but got [] > > > > When I run the RunVim command standalone: > > > > ../vim -f -u NONE -U NONE --noplugin --not-a-term --cmd "so b" <(cat > > Xtestin) > > > > I do in fact get nothing in the buffer, and a warning in the status line > > > > "/dev/fd/12" [character special][converted][READ ERRORS] 0 lines, 0 > > characters > > > > I get the same thing if I remove cp932 from fencs and add ascii, but latin1 > > gives me something, at least. Aren't errors in conversion supposed to be > > ignored and move vim on to the next entry in fencs, or am I > > misunderstanding that whole thing? > > It is supposed to work. No idea why it fails in your situation. > Would require debugging (or adding some printf's). Hm. Any suggestions on where to start? Am I right that it should try to convert from cp932, fail, and then try utf8? Is there anything I can do with the iconv command that could demonstrate that there's something wrong with iconv on the system? Thanks, Danek -- -- 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. For more options, visit https://groups.google.com/d/optout.
Patch 7.4.2225
Patch 7.4.2225
Problem:Crash when placing a sign in a deleted buffer.
Solution: Check for missing buffer name. (Dominique Pelle). Add a test.
Files: src/ex_cmds.c, src/testdir/test_signs.vim
*** ../vim-7.4.2224/src/ex_cmds.c 2016-08-16 21:04:37.827952367 +0200
--- src/ex_cmds.c 2016-08-17 22:22:26.106231680 +0200
***
*** 7861,7866
--- 7861,7871
{ /* ... not currently in a window */
char_u *cmd;
+ if (buf->b_fname == NULL)
+ {
+ EMSG(_("E934: Cannot jump to a buffer that does not
have a name"));
+ return;
+ }
cmd = alloc((unsigned)STRLEN(buf->b_fname) + 25);
if (cmd == NULL)
return;
*** ../vim-7.4.2224/src/testdir/test_signs.vim 2016-08-10 21:36:19.315004293
+0200
--- src/testdir/test_signs.vim 2016-08-17 22:24:41.224984587 +0200
***
*** 181,183
--- 181,195
call assert_fails('sign place 1 buffer=', 'E158:')
call assert_fails('sign define Sign2 text=', 'E239:')
endfunc
+
+ func Test_sign_delete_buffer()
+ new
+ sign define Sign text=x
+ let bufnr = bufnr('%')
+ new
+ exe 'bd ' . bufnr
+ exe 'sign place 61 line=3 name=Sign buffer=' . bufnr
+ call assert_fails('sign jump 61 buffer=' . bufnr, 'E934:')
+ sign unplace 61
+ sign undefine Sign
+ endfunc
*** ../vim-7.4.2224/src/version.c 2016-08-17 21:51:52.259045616 +0200
--- src/version.c 2016-08-17 22:11:32.512257441 +0200
***
*** 765,766
--- 765,768
{ /* Add new patch number below this line */
+ /**/
+ 2225,
/**/
--
`The Guide says there is an art to flying,' said Ford, `or at least a
knack. The knack lies in learning how to throw yourself at the ground
and miss.' He smiled weakly.
-- Douglas Adams, "The Hitchhiker's Guide to the Galaxy"
/// Bram Moolenaar -- b...@moolenaar.net -- http://www.Moolenaar.net \\\
///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\ an exciting new programming language -- http://www.Zimbu.org///
\\\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.
For more options, visit https://groups.google.com/d/optout.
Re: [patch] fixed crash in sign command with deleted buffer
Dominique Pellé wrote: > Vim-7.4. and older segfaults with this command: > > $ vim -u NONE -S crash-sign-7.4..vim > > Vim: Caught deadly signal SEGV > > Vim: Finished. > Segmentation fault (core dumped) > > crash-sign-7.4..vim is the attached file. > > Bug was found using afl-fuzz. > > Attached patch fixes it, but I'm not sure whether commands > "sign place 1 line=3 name=Sign1 buffer=1" and > "sign jump 1 buffer=1" should have complained about > buffer 1 being deleted. Thanks. Yes, it should result in an error message, instead of silently not jumping. -- "Space is big. Really big. You just won't believe how vastly hugely mind- bogglingly big it is. I mean, you may think it's a long way down the road to the chemist, but that's just peanuts to space." -- Douglas Adams, "The Hitchhiker's Guide to the Galaxy" /// Bram Moolenaar -- b...@moolenaar.net -- http://www.Moolenaar.net \\\ ///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\ \\\ an exciting new programming language -- http://www.Zimbu.org/// \\\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. For more options, visit https://groups.google.com/d/optout.
Re: [patch][doc] Fix typos
Ken Takata wrote: > 2016/8/17 Wed 9:52:24 UTC+9 Ken Takata wrote: > > Hi, > > > > Please check the attached patch for fixing typos in docs. > > And... the patches 7.4.2063 - 7.4.2162 in the list were duplicated. > > I think we need description for binary number. Thanks. -- I'm not familiar with this proof, but I'm aware of a significant following of toddlers who believe that peanut butter is the solution to all of life's problems...-- Tim Hammerquist /// Bram Moolenaar -- b...@moolenaar.net -- http://www.Moolenaar.net \\\ ///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\ \\\ an exciting new programming language -- http://www.Zimbu.org/// \\\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. For more options, visit https://groups.google.com/d/optout.
Re: [patch][doc] Fix typos
Ken Takata wrote: > Please check the attached patch for fixing typos in docs. > And... the patches 7.4.2063 - 7.4.2162 in the list were duplicated. Thanks! -- One difference between a man and a machine is that a machine is quiet when well oiled. /// Bram Moolenaar -- b...@moolenaar.net -- http://www.Moolenaar.net \\\ ///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\ \\\ an exciting new programming language -- http://www.Zimbu.org/// \\\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. For more options, visit https://groups.google.com/d/optout.
Re: Vim 8 pre-announcement
Hello Bram,
On 8/16/2016 6:43 PM, Bram Moolenaar wrote:
> Hello Vim users,
>
> Work on Vim 8.0 is coming close to an end. I hope version 8.0 can be
> released in about two weeks.
>
> This is a last chance to modify new features in a way that is not
> backwards compatible. Once 8.0 is out we can't make changes that would
> break plugins.
>
> An overview of new features can be found in:
> https://github.com/vim/vim/blob/master/runtime/doc/version8.txt
> A version with links (but a day older):
> http://vimhelp.appspot.com/version8.txt.html
>
> Please review the new features, try them out and report what should be
> changed on the vim-dev maillist. Of course you should also report bugs
> you find.
>
> Happy Vimming!
>
>
> PS. If you are interested in meeting Vim users: Vimfest is happening in
> Berlin Sept. 16-18. http://vimfest.org
I was wondering whether you could also include into Vim 8 the following patch
(the original reason for pull request https://github.com/vim/vim/pull/543,
which you can reject, since the langmap part doesn't seem to have a chance in,
anyway)
The behavior this patch tries to achieve is given by the test case in the patch.
diff --git src/getchar.c src/getchar.c
index 1c170cc..ce68a2f 100644
--- src/getchar.c
+++ src/getchar.c
@@ -2144,12 +2144,15 @@ vgetorpeek(int advance)
/*
* Only consider an entry if the first character
* matches and it is for the current state.
- * Skip ":lmap" mappings if keys were mapped.
*/
if (mp->m_keys[0] == c1
&& (mp->m_mode & local_State)
-&& ((mp->m_mode & LANGMAP) == 0
-|| typebuf.tb_maplen == 0))
+ /* && ((mp->m_mode & LANGMAP) == 0 ||
typebuf.tb_maplen == 0)
+ * Used to skip ":lmap" mappings for keymap'ed
keys here,
+ * but the result of the keymap is not placed in
the register,
+ * so the register content needs to be remapped
here.
+ */
+ )
{
#ifdef FEAT_LANGMAP
intnomap = nolmaplen;
diff --git src/testdir/test_digraph.vim src/testdir/test_digraph.vim
index 9550085..3578ced 100644
--- src/testdir/test_digraph.vim
+++ src/testdir/test_digraph.vim
@@ -450,6 +450,20 @@ func! Test_loadkeymap()
bw!
endfunc
+func! Test_registerkeymap()
+ if !has('keymap')
+return
+ endif
+ new
+ set keymap=russian-jcukenwin
+ set iminsert=1
+ call feedkeys("qqods\qdd@q", 'tx')
+ call assert_equal("вы", getline('.'))
+ " reset keymap and encoding option
+ set keymap=
+ bw!
+endfunc
+
func! Test_digraph_cmndline()
" Create digraph on commandline
" This is a hack, to let Vim create the digraph in commandline mode
--
--
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.
For more options, visit https://groups.google.com/d/optout.
Re: error in test_startup_utf8
Danek Duvall wrote: > I'm seeing this. It's on Solaris, but I'm not sure whether that matters, > or if it does, what aspect does. > > From test_startup_utf8.vim: > Found errors in Test_read_fifo_utf8(): > function RunTheTest[9]..Test_read_fifo_utf8 line 24: Expected ['テスト', > '€ÀÈÌÒÙ'] but got [] > > When I run the RunVim command standalone: > > ../vim -f -u NONE -U NONE --noplugin --not-a-term --cmd "so b" <(cat > Xtestin) > > I do in fact get nothing in the buffer, and a warning in the status line > > "/dev/fd/12" [character special][converted][READ ERRORS] 0 lines, 0 > characters > > I get the same thing if I remove cp932 from fencs and add ascii, but latin1 > gives me something, at least. Aren't errors in conversion supposed to be > ignored and move vim on to the next entry in fencs, or am I > misunderstanding that whole thing? It is supposed to work. No idea why it fails in your situation. Would require debugging (or adding some printf's). -- How To Keep A Healthy Level Of Insanity: 18. When leaving the zoo, start running towards the parking lot, yelling "run for your lives, they're loose!!" /// Bram Moolenaar -- b...@moolenaar.net -- http://www.Moolenaar.net \\\ ///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\ \\\ an exciting new programming language -- http://www.Zimbu.org/// \\\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. For more options, visit https://groups.google.com/d/optout.
Patch 7.4.2224
Patch 7.4.2224
Problem:Compiler warnings with older compiler and 64 bit numbers.
Solution: Add "LL" to large values. (Mike Williams)
Files: src/eval.c, src/evalfunc.c
*** ../vim-7.4.2223/src/eval.c 2016-08-14 16:07:44.717705432 +0200
--- src/eval.c 2016-08-17 21:46:57.953745759 +0200
***
*** 4087,4097
{
#ifdef FEAT_NUM64
if (n1 == 0)
! n1 = -0x7fff - 1; /* similar to NaN */
else if (n1 < 0)
! n1 = -0x7fff;
else
! n1 = 0x7fff;
#else
if (n1 == 0)
n1 = -0x7fffL - 1L; /* similar to NaN */
--- 4087,4097
{
#ifdef FEAT_NUM64
if (n1 == 0)
! n1 = -0x7fffLL - 1; /* similar to NaN */
else if (n1 < 0)
! n1 = -0x7fffLL;
else
! n1 = 0x7fffLL;
#else
if (n1 == 0)
n1 = -0x7fffL - 1L; /* similar to NaN */
*** ../vim-7.4.2223/src/evalfunc.c 2016-08-17 21:31:54.437870436 +0200
--- src/evalfunc.c 2016-08-17 21:46:57.957745723 +0200
***
*** 3291,3300
if (get_float_arg(argvars, &f) == OK)
{
# ifdef FEAT_NUM64
! if (f < -0x7fff)
! rettv->vval.v_number = -0x7fff;
! else if (f > 0x7fff)
! rettv->vval.v_number = 0x7fff;
else
rettv->vval.v_number = (varnumber_T)f;
# else
--- 3291,3300
if (get_float_arg(argvars, &f) == OK)
{
# ifdef FEAT_NUM64
! if (f < -0x7fffLL)
! rettv->vval.v_number = -0x7fffLL;
! else if (f > 0x7fffLL)
! rettv->vval.v_number = 0x7fffLL;
else
rettv->vval.v_number = (varnumber_T)f;
# else
*** ../vim-7.4.2223/src/version.c 2016-08-17 21:31:54.445870364 +0200
--- src/version.c 2016-08-17 21:47:49.313281276 +0200
***
*** 765,766
--- 765,768
{ /* Add new patch number below this line */
+ /**/
+ 2224,
/**/
--
Now it is such a bizarrely improbable coincidence that anything as
mind-bogglingly useful as the Babel fish could have evolved purely by chance
that some thinkers have chosen to see it as a final and clinching proof of the
NON-existence of God.
The argument goes something like this: 'I refuse to prove that I exist,' says
God, 'for proof denies faith, and without faith I am nothing.'
'But,' says Man, 'the Babel fish is a dead giveaway, isn't it? It could not
have evolved by chance. It proves you exist, and so therefore, by your own
arguments, you don't. QED.'
'Oh dear,' says God, 'I hadn't thought of that,' and promptly vanishes in a
puff of logic.
'Oh, that was easy,' says Man, and for an encore goes on to prove that black
is white and gets himself killed on the next pedestrian crossing.
-- Douglas Adams, "The Hitchhiker's Guide to the Galaxy"
/// Bram Moolenaar -- b...@moolenaar.net -- http://www.Moolenaar.net \\\
///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\ an exciting new programming language -- http://www.Zimbu.org///
\\\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.
For more options, visit https://groups.google.com/d/optout.
Re: Patch 7.4.2219
Am 16.08.2016 um 21:04 schrieb Bram Moolenaar: Patch 7.4.2219 Problem:Recursive call to substitute gets stuck in sandbox. (Nikolai Pavlov) Solution: Handle the recursive call. (Christian Brabandt, closes #950) Add a test. Files: src/ex_cmds.c, src/testdir/test_regexp_latin.vim What about recursive sub-replace-\= ? (fixed as well? related at all? already fixed?) -- 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. For more options, visit https://groups.google.com/d/optout.
Patch 7.4.2223
Patch 7.4.2223
Problem:Buffer overflow when using latin1 character with feedkeys().
Solution: Check for an illegal character. Add a test.
Files: src/testdir/test_regexp_utf8.vim, src/testdir/test_source_utf8.vim,
src/testdir/test_alot_utf8.vim, src/Makefile, src/getchar.c,
src/macros.h, src/evalfunc.c, src/os_unix.c, src/os_win32.c,
src/spell.c
*** ../vim-7.4./src/testdir/test_regexp_utf8.vim2016-08-16
22:50:50.758254682 +0200
--- src/testdir/test_regexp_utf8.vim2016-08-17 20:17:41.702422218 +0200
***
*** 92,109
call s:classes_test()
set re=0
endfunc
-
- func Test_source_utf8()
- " check that sourcing a script with 0x80 as second byte works
- new
- call setline(1, [':%s/àx/--à1234--/g', ':%s/Àx/--À1234--/g'])
- write! Xscript
- bwipe!
- new
- call setline(1, [' àx ', ' Àx '])
- source! Xscript | echo
- call assert_equal(' --à1234-- ', getline(1))
- call assert_equal(' --À1234-- ', getline(2))
- bwipe!
- call delete('Xscript')
- endfunc
--- 92,94
*** ../vim-7.4./src/testdir/test_source_utf8.vim2016-08-17
21:30:50.354447196 +0200
--- src/testdir/test_source_utf8.vim2016-08-17 21:28:17.083826957 +0200
***
*** 0
--- 1,33
+ " Test the :source! command
+ if !has('multi_byte')
+ finish
+ endif
+
+ func Test_source_utf8()
+ " check that sourcing a script with 0x80 as second byte works
+ new
+ call setline(1, [':%s/àx/--à1234--/g', ':%s/Àx/--À1234--/g'])
+ write! Xscript
+ bwipe!
+ new
+ call setline(1, [' àx ', ' Àx '])
+ source! Xscript | echo
+ call assert_equal(' --à1234-- ', getline(1))
+ call assert_equal(' --À1234-- ', getline(2))
+ bwipe!
+ call delete('Xscript')
+ endfunc
+
+ func Test_source_latin()
+ " check that sourcing a latin1 script with a 0xc0 byte works
+ new
+ call setline(1, ["call feedkeys('r')", "call feedkeys('\xc0', 'xt')"])
+ write! Xscript
+ bwipe!
+ new
+ call setline(1, ['xxx'])
+ source Xscript
+ call assert_equal("\u00c0xx", getline(1))
+ bwipe!
+ call delete('Xscript')
+ endfunc
*** ../vim-7.4./src/testdir/test_alot_utf8.vim 2016-07-21
20:33:28.835262339 +0200
--- src/testdir/test_alot_utf8.vim 2016-08-17 21:29:14.823307132 +0200
***
*** 8,10
--- 8,11
source test_expr_utf8.vim
source test_matchadd_conceal_utf8.vim
source test_regexp_utf8.vim
+ source test_source_utf8.vim
*** ../vim-7.4./src/Makefile2016-08-14 15:31:53.353671912 +0200
--- src/Makefile2016-08-17 21:29:25.523210804 +0200
***
*** 2114,2119
--- 2114,2120
test_set \
test_signs \
test_sort \
+ test_source_utf8 \
test_startup \
test_startup_utf8 \
test_stat \
*** ../vim-7.4./src/getchar.c 2016-08-16 22:50:50.754254718 +0200
--- src/getchar.c 2016-08-17 21:06:50.959528112 +0200
***
*** 4658,4665
char_u*res;
char_u*s, *d;
! /* Need a buffer to hold up to three times as much. */
! res = alloc((unsigned)(STRLEN(p) * 3) + 1);
if (res != NULL)
{
d = res;
--- 4658,4673
char_u*res;
char_u*s, *d;
! /* Need a buffer to hold up to three times as much. Four in case of an
! * illegal utf-8 byte:
! * 0xc0 -> 0xc3 0x80 -> 0xc3 K_SPECIAL KS_SPECIAL KE_FILLER */
! res = alloc((unsigned)(STRLEN(p) *
! #ifdef FEAT_MBYTE
! 4
! #else
! 3
! #endif
! ) + 1);
if (res != NULL)
{
d = res;
***
*** 4674,4695
}
else
{
- #ifdef FEAT_MBYTE
- int len = mb_char2len(PTR2CHAR(s));
- int len2 = mb_ptr2len(s);
- #endif
/* Add character, possibly multi-byte to destination, escaping
!* CSI and K_SPECIAL. */
d = add_char2buf(PTR2CHAR(s), d);
! #ifdef FEAT_MBYTE
! while (len < len2)
! {
! /* add following combining char */
! d = add_char2buf(PTR2CHAR(s + len), d);
! len += mb_char2len(PTR2CHAR(s + len));
! }
! #endif
! mb_ptr_adv(s);
}
}
*d = NUL;
--- 4682,4691
}
else
{
/* Add character, possibly multi-byte to destination, escaping
!* CSI and K_SPECIAL. Be careful, it can be an illegal byte! */
d = add_char2buf(PTR2CHAR(s), d);
! s += MB_CPTR2LEN(s);
}
}
*d = NUL;
*** ../vim-7.4./src/macros.h2016-07-17 20:37:38.235378864 +0200
--- src/macros.h2016-08-17 21:08:28.650636119 +0200
***
*** 274,280
/* Backup multi-byte pointer. Only use with "p" > "s" ! */
# define mb_ptr_back(s, p)
Re: [bug] write beyond end of string when calling feedkeys
Dominique wrote:
> Valgrind shows a write beyond end of string
> in Vim-7.4. (huge) and older when doing:
>
> $ vim -u NONE -N -S bug-feedkeys-7.4.7222.vim 2> log
>
> ... where bug-feedkeys-7.4.7222.vim is the one-line
> attached file. Note that the file is in latin1 encoding
> and my locale is en_US.UTF-8.
>
> log file contains:
>
> ==4157== Memcheck, a memory error detector
> ==4157== Copyright (C) 2002-2015, and GNU GPL'd, by Julian Seward et al.
> ==4157== Using Valgrind-3.12.0.SVN and LibVEX; rerun with -h for copyright
> info
> ==4157== Command: vim -u NONE -N -S bug-feedkeys-7.4.7222.vim
> ==4157==
> ==4157== Invalid write of size 1
> ==4157==at 0x4BB05F: vim_strsave_escape_csi (getchar.c:4695)
> ==4157==by 0x44DE8C: f_feedkeys (evalfunc.c:3126)
> ==4157==by 0x44A339: call_internal_func (evalfunc.c:997)
> ==4157==by 0x5E53E6: call_func (userfunc.c:1372)
> ==4157==by 0x5E319D: get_func_tv (userfunc.c:455)
> ==4157==by 0x5E8F70: ex_call (userfunc.c:2981)
> ==4157==by 0x47AC68: do_one_cmd (ex_docmd.c:2925)
> ==4157==by 0x477954: do_cmdline (ex_docmd.c:1110)
> ==4157==by 0x4755F8: do_source (ex_cmds2.c:4084)
> ==4157==by 0x474C0A: cmd_source (ex_cmds2.c:3697)
> ==4157==by 0x474B58: ex_source (ex_cmds2.c:3672)
> ==4157==by 0x47AC68: do_one_cmd (ex_docmd.c:2925)
> ==4157== Address 0xcd992d4 is 0 bytes after a block of size 4 alloc'd
> ==4157==at 0x4C2ABF5: malloc (vg_replace_malloc.c:299)
> ==4157==by 0x4F1427: lalloc (misc2.c:920)
> ==4157==by 0x4F12F4: alloc (misc2.c:818)
> ==4157==by 0x4BAE5B: vim_strsave_escape_csi (getchar.c:4662)
> ==4157==by 0x44DE8C: f_feedkeys (evalfunc.c:3126)
> ==4157==by 0x44A339: call_internal_func (evalfunc.c:997)
> ==4157==by 0x5E53E6: call_func (userfunc.c:1372)
> ==4157==by 0x5E319D: get_func_tv (userfunc.c:455)
> ==4157==by 0x5E8F70: ex_call (userfunc.c:2981)
> ==4157==by 0x47AC68: do_one_cmd (ex_docmd.c:2925)
> ==4157==by 0x477954: do_cmdline (ex_docmd.c:1110)
> ==4157==by 0x4755F8: do_source (ex_cmds2.c:4084)
> ==4157==
> ==4157== Invalid read of size 1
> ==4157==at 0x4C2DA04: strlen (vg_replace_strmem.c:454)
> ==4157==by 0x4B4FD2: ins_typebuf (getchar.c:979)
> ==4157==by 0x44DEDD: f_feedkeys (evalfunc.c:3129)
> ==4157==by 0x44A339: call_internal_func (evalfunc.c:997)
> ==4157==by 0x5E53E6: call_func (userfunc.c:1372)
> ==4157==by 0x5E319D: get_func_tv (userfunc.c:455)
> ==4157==by 0x5E8F70: ex_call (userfunc.c:2981)
> ==4157==by 0x47AC68: do_one_cmd (ex_docmd.c:2925)
> ==4157==by 0x477954: do_cmdline (ex_docmd.c:1110)
> ==4157==by 0x4755F8: do_source (ex_cmds2.c:4084)
> ==4157==by 0x474C0A: cmd_source (ex_cmds2.c:3697)
> ==4157==by 0x474B58: ex_source (ex_cmds2.c:3672)
> ==4157== Address 0xcd992d4 is 0 bytes after a block of size 4 alloc'd
> ==4157==at 0x4C2ABF5: malloc (vg_replace_malloc.c:299)
> ==4157==by 0x4F1427: lalloc (misc2.c:920)
> ==4157==by 0x4F12F4: alloc (misc2.c:818)
> ==4157==by 0x4BAE5B: vim_strsave_escape_csi (getchar.c:4662)
> ==4157==by 0x44DE8C: f_feedkeys (evalfunc.c:3126)
> ==4157==by 0x44A339: call_internal_func (evalfunc.c:997)
> ==4157==by 0x5E53E6: call_func (userfunc.c:1372)
> ==4157==by 0x5E319D: get_func_tv (userfunc.c:455)
> ==4157==by 0x5E8F70: ex_call (userfunc.c:2981)
> ==4157==by 0x47AC68: do_one_cmd (ex_docmd.c:2925)
> ==4157==by 0x477954: do_cmdline (ex_docmd.c:1110)
> ==4157==by 0x4755F8: do_source (ex_cmds2.c:4084)
>
> Code in getchar.c:
>
> 4654 char_u *
> 4655 vim_strsave_escape_csi(
> 4656 char_u *p)
> 4657 {
> 4658 char_u *res;
> 4659 char_u *s, *d;
> 4660
> 4661 /* Need a buffer to hold up to three times as much. */
> 4662 res = alloc((unsigned)(STRLEN(p) * 3) + 1);
> 4663 if (res != NULL)
> 4664 {
> 4665 d = res;
> 4666 for (s = p; *s != NUL; )
> 4667 {
> 4668 if (s[0] == K_SPECIAL && s[1] != NUL && s[2] != NUL)
> 4669 {
> 4670 /* Copy special key unmodified. */
> 4671 *d++ = *s++;
> 4672 *d++ = *s++;
> 4673 *d++ = *s++;
> 4674 }
> 4675 else
> 4676 {
> 4677 #ifdef FEAT_MBYTE
> 4678 int len = mb_char2len(PTR2CHAR(s));
> 4679 int len2 = mb_ptr2len(s);
> 4680 #endif
> 4681 /* Add character, possibly multi-byte to
> destination, escaping
> 4682 * CSI and K_SPECIAL. */
> 4683 d = add_char2buf(PTR2CHAR(s), d);
> 4684 #ifdef FEAT_MBYTE
> 4685 while (len < len2)
> 4686 {
> 4687 /* add following combining char */
> 4688 d = add_char2buf(PTR2CHAR(s + len), d);
> 4689 len += mb_char2len(PTR2CHAR(s + len));
> 4690 }
> 4691 #endif
> 4692 mb_ptr_a
Re: Vim 8 pre-announcement
On Wed, Aug 17, 2016 at 10:54:17AM -0700, Yegappan Lakshmanan wrote: > On Wed, Aug 17, 2016 at 2:10 AM, 'Guyzmo' via vim_dev > wrote: > > On Wed, Aug 17, 2016 at 11:48:23AM +0300, LCD 47 wrote: > >> On 16 August 2016, Yegappan Lakshmanan wrote: > >> Perhaps "tpnr" should be renamed to something more suggestive, such as > >> "tabnr"? > > I guess this should apply also for the window, as `winnr` for example, > > for consistency in the keys naming scheme. > Note that window ID is different from window number. The getwininfo() > function returns both the window ID (winid field) and the window > number (nr field). Are you suggesting to rename the "nr" field to winnr? yup, that's what I meant, no confusion. Consistency and all ☺ -- Guyzmo -- -- 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. For more options, visit https://groups.google.com/d/optout.
Re: Vim 8 pre-announcement
Hi, On Wed, Aug 17, 2016 at 4:12 AM, Michael Henry wrote: > On 08/17/2016 12:00 AM, Yegappan Lakshmanan wrote: >> I am in particular interested in any comments/suggestions about the > following >> new functions: >> >> getbufinfo() >> gettabinfo() >> getwininfo() >> getqflist() >> setqflist() >> getcompletion() > > I've got some custom functions in my .vimrc related to QuickFix > and Location List windows. They are clunky and inefficient > because as far as I can tell, Vim doesn't expose quite enough > information. I've included the functions below for reference. > > I haven't been able to track all of the new developments, but > perhaps someone can say whether there is a better way than the > below functions (either with pre-existing or recently added Vim > functionality). I'd like functions that: > > - Return True if a given window is a QuickFix or Location List > window. (Both types of window have &buftype == "quickfix".) > The new getwininfo() function can be used to distinguish between the quickfix and location list windows. Check the 'quickfix' and the 'loclist' keys in the returned dictionary. > > - Return True if the QuickFix is window open. > The getqflist() function returns the window ID of the quickfix window (if it is opened). You can check for this. > > - Return True if the Location List window is open for a given > window. > You can use the getloclist() function for this. > > - Return the window number of the QuickFix window (0 if not > open). > - Return the window number of the associated Location List > for a given window (0 if not open). > You can use the getqflist() and getloclist() functions for these. - Yegappan > > When the current window has ``&buftype == "quickfix"``, I'd > originally tried to determine whether it was a QuickFix window > or a Location List using ``getloclist(0)``. I'd wanted to say > ``isLocationList = (getloclist(0) > 0)``, but that fails when > it's a Location List that happens to be empty, so I resorted to > the uglier hacks you see below. > > I thought I'd seen some activity along these lines that might > expose the details directly, but I haven't been keeping up with > all of the new changes. > > Michael Henry > -- -- 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. For more options, visit https://groups.google.com/d/optout.
Re: Vim 8 pre-announcement
Hi,
On Wed, Aug 17, 2016 at 2:10 AM, 'Guyzmo' via vim_dev
wrote:
> On Wed, Aug 17, 2016 at 11:48:23AM +0300, LCD 47 wrote:
>> On 16 August 2016, Yegappan Lakshmanan wrote:
>> > getbufinfo()
>> "options", "signs", and "variables" return lists that are potentially
>> huge. Perhaps there should be a way to tell getbufinfo() to skip these
>> lists;
>> otherwise plugins would just avoid calling this function, for performance
>> reasons.
>
> I share the opinion that having a mechanism to select and/or exclude
> keys from the dict to avoid loading and carrying around huge dicts
> sounds a great thing.
>
>> > gettabinfo()
>> > getwininfo()
>>
>> From the manual:
>>
>> : Each List item is a Dictionary with the following entries:
>> : bufnum number of buffer in the window
>> : height window height
>> : loclist 1 if showing a location list
>> : {only with the +quickfix feature}
>> : nr window number
>> : options dictionary of window local options
>> : quickfix1 if quickfix or location list window
>> : {only with the +quickfix feature}
>> : tpnrtab page number
>> : variables dictionary of window local variables
>> : width window width
>> : winid window ID
>>
>> Perhaps "tpnr" should be renamed to something more suggestive, such as
>> "tabnr"?
>
> I guess this should apply also for the window, as `winnr` for example,
> for consistency in the keys naming scheme.
>
Note that window ID is different from window number. The getwininfo()
function returns both the window ID (winid field) and the window
number (nr field). Are you suggesting to rename the "nr" field to winnr?
- Yegappan
>
> just my $.02,
>
> --
> Guyzmo
--
--
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.
For more options, visit https://groups.google.com/d/optout.
Re: Vim 8 pre-announcement
Hi,
On Wed, Aug 17, 2016 at 1:48 AM, LCD 47 wrote:
> On 16 August 2016, Yegappan Lakshmanan wrote:
>> I am in particular interested in any comments/suggestions about the following
>> new functions:
>>
>> getbufinfo()
>
> From the manual:
>
> : Each returned List item is a dictionary with the following
> : entries:
> : changed TRUE if the buffer is modified.
> : changedtick number of changes made to the buffer.
> : hidden TRUE if the buffer is hidden.
> : listed TRUE if the buffer is listed.
> : lnumcurrent line number in buffer.
> : loaded TRUE if the buffer is loaded.
> : namefull path to the file in the buffer.
> : nr buffer number.
> : options dictionary of buffer local options.
> : signs list of signs placed in the buffer.
> : Each list item is a dictionary with
> : the following fields:
> : idsign identifier
> : lnum line number
> : name sign name
> : variables dictionary of buffer local variables.
> : windows list of window IDs with this buffer
>
> "options", "signs", and "variables" return lists that are potentially
> huge. Perhaps there should be a way to tell getbufinfo() to skip these lists;
> otherwise plugins would just avoid calling this function, for performance
> reasons.
>
We can use the dict argument to the getbufinfo() function to specify
what to return. The default is to return everything like above. I will send
a patch for this.
>
> On the other hand, finding the number of lines in a buffer as "line('$')"
> is very inefficient, so maybe this would be a good place to return it. But
> again, as an option, since it would involve loading the buffer.
>
>> gettabinfo()
>> getwininfo()
>
> From the manual:
>
> : Each List item is a Dictionary with the following entries:
> : bufnum number of buffer in the window
> : height window height
> : loclist 1 if showing a location list
> : {only with the +quickfix feature}
> : nr window number
> : options dictionary of window local options
> : quickfix1 if quickfix or location list window
> : {only with the +quickfix feature}
> : tpnrtab page number
> : variables dictionary of window local variables
> : width window width
> : winid window ID
>
> Perhaps "tpnr" should be renamed to something more suggestive, such as
> "tabnr"?
>
This can be changed.
>
>> getqflist()
>
> The manual could use some rephrasing. As it is, it sounds unnatural even
> to my broken English.
>
Any particular text in the help that is confusing?
>
>> setqflist()
>> getcompletion()
>
> Again, getcompletion() can return some potentially huge lists. Being able
> to restrict results to smaller subsets could make this function a lot lighter.
>
The "pattern" (first argument) can be used to filter the returned results.
Is that not sufficient?
- Yegappan
>
> /lcd
>
--
--
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.
For more options, visit https://groups.google.com/d/optout.
Re: Vim 8 pre-announcement
Am 16.08.2016 um 18:43 schrieb Bram Moolenaar: Hello Vim users, Work on Vim 8.0 is coming close to an end. I hope version 8.0 can be released in about two weeks. This is a last chance to modify new features in a way that is not backwards compatible. Once 8.0 is out we can't make changes that would break plugins. Can we have 'langnoremap' renamed to 'langremap' please? Double negation is confusing. And it's more consistent with 'remap' (although that option should be removed ...). -- 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. For more options, visit https://groups.google.com/d/optout.
error in test_startup_utf8
I'm seeing this. It's on Solaris, but I'm not sure whether that matters, or if it does, what aspect does. From test_startup_utf8.vim: Found errors in Test_read_fifo_utf8(): function RunTheTest[9]..Test_read_fifo_utf8 line 24: Expected ['テスト', '€ÀÈÌÒÙ'] but got [] When I run the RunVim command standalone: ../vim -f -u NONE -U NONE --noplugin --not-a-term --cmd "so b" <(cat Xtestin) I do in fact get nothing in the buffer, and a warning in the status line "/dev/fd/12" [character special][converted][READ ERRORS] 0 lines, 0 characters I get the same thing if I remove cp932 from fencs and add ascii, but latin1 gives me something, at least. Aren't errors in conversion supposed to be ignored and move vim on to the next entry in fencs, or am I misunderstanding that whole thing? Thanks, Danek -- -- 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. For more options, visit https://groups.google.com/d/optout.
Re: Vim 8 pre-announcement
On Wed, Aug 17, 2016 at 3:48 AM, LCD 47 wrote: > On 16 August 2016, Yegappan Lakshmanan wrote: > > I am in particular interested in any comments/suggestions about the > following > > new functions: > > > > getbufinfo() > > From the manual: > > : Each returned List item is a dictionary with the following > : entries: > : changed TRUE if the buffer is modified. > : changedtick number of changes made to the > buffer. > : hidden TRUE if the buffer is hidden. > : listed TRUE if the buffer is listed. > : lnumcurrent line number in buffer. > : loaded TRUE if the buffer is loaded. > : namefull path to the file in the > buffer. > : nr buffer number. > : options dictionary of buffer local options. > : signs list of signs placed in the buffer. > : Each list item is a dictionary with > : the following fields: > : idsign identifier > : lnum line number > : name sign name > : variables dictionary of buffer local > variables. > : windows list of window IDs with this buffer > > "options", "signs", and "variables" return lists that are potentially > huge. Perhaps there should be a way to tell getbufinfo() to skip these > lists; > otherwise plugins would just avoid calling this function, for performance > reasons. > I was about to make a similar suggestion. As it is now, the docs claim that the "options" dictionary will only contain buffer-local options. But this is a bit misleading. That dictionary will hold the values of the so-called "global-local" options, even when the local value doesn't differ from the global one. For example, in my vimrc I have ":set stl=blah", and nowhere do I have ":setlocal stl=blah"; yet my entire statusline string appears in the "options" dictionary. This is very unexpected. For an even more annoying example, the entire gigantic string for "&lispwords"---an option I have never touched in my life---appears in the options dict, because &lispwords is global-local. I think it should not appear there unless the user has (in that buffer) set the local value to something different from the global one. Also I'm not sure why the get*info() functions have a "variables" dict, since there is already get*var() and one can call get*var() on whatever bufs/wins/tabs are returned by get*info(). It would probably be nice if there were also analogous get*options() functions. Then the "variables" and "options" dicts could both be removed from get*info(), and that would make get*info() return lighter lists. In summary, I think the get*info() functions would be improved by (1) not including global-local options in the "options" dict unless the local values differ from the global ones; (2) eliminating the "variables" dictionary, since that information is easily found by combining get*info() with get*var(). -Manny -- -- 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. For more options, visit https://groups.google.com/d/optout.
Re: Vim 8 pre-announcement
Dnia Wtorek, 16 Sierpnia 2016 18:43 Bram Moolenaar napisał(a) > > Hello Vim users, > > An overview of new features can be found in: > https://github.com/vim/vim/blob/master/runtime/doc/version8.txt In lines 321 and 346 are described two variables with the same given name (or one variable with two completely different descriptions): v:vim_did_enter m. -- -- 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. For more options, visit https://groups.google.com/d/optout.
[patch] fixed crash in sign command with deleted buffer
Hi
Vim-7.4. and older segfaults with this command:
$ vim -u NONE -S crash-sign-7.4..vim
Vim: Caught deadly signal SEGV
Vim: Finished.
Segmentation fault (core dumped)
crash-sign-7.4..vim is the attached file.
Bug was found using afl-fuzz.
Attached patch fixes it, but I'm not sure whether commands
"sign place 1 line=3 name=Sign1 buffer=1" and
"sign jump 1 buffer=1" should have complained about
buffer 1 being deleted.
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.
For more options, visit https://groups.google.com/d/optout.
diff --git a/src/ex_cmds.c b/src/ex_cmds.c
index aeb2bf9..881a63a 100644
--- a/src/ex_cmds.c
+++ b/src/ex_cmds.c
@@ -7860,7 +7860,8 @@ ex_sign(exarg_T *eap)
else
{ /* ... not currently in a window */
char_u *cmd;
-
+ if (buf->b_fname == NULL)
+ return;
cmd = alloc((unsigned)STRLEN(buf->b_fname) + 25);
if (cmd == NULL)
return;
crash-sign-7.4..vim
Description: Binary data
Re: Vim 8 pre-announcement
On 08/17/2016 12:00 AM, Yegappan Lakshmanan wrote:
> I am in particular interested in any comments/suggestions about the
following
> new functions:
>
> getbufinfo()
> gettabinfo()
> getwininfo()
> getqflist()
> setqflist()
> getcompletion()
I've got some custom functions in my .vimrc related to QuickFix
and Location List windows. They are clunky and inefficient
because as far as I can tell, Vim doesn't expose quite enough
information. I've included the functions below for reference.
I haven't been able to track all of the new developments, but
perhaps someone can say whether there is a better way than the
below functions (either with pre-existing or recently added Vim
functionality). I'd like functions that:
- Return True if a given window is a QuickFix or Location List
window. (Both types of window have &buftype == "quickfix".)
- Return True if the QuickFix is window open.
- Return True if the Location List window is open for a given
window.
- Return the window number of the QuickFix window (0 if not
open).
- Return the window number of the associated Location List
for a given window (0 if not open).
When the current window has ``&buftype == "quickfix"``, I'd
originally tried to determine whether it was a QuickFix window
or a Location List using ``getloclist(0)``. I'd wanted to say
``isLocationList = (getloclist(0) > 0)``, but that fails when
it's a Location List that happens to be empty, so I resorted to
the uglier hacks you see below.
I thought I'd seen some activity along these lines that might
expose the details directly, but I haven't been keeping up with
all of the new changes.
Michael Henry
Sample functions for reference
" Return 1 if current window is the QuickFix window.
function! IsQuickFixWin()
if &buftype == "quickfix"
" This is either a QuickFix window or a Location List window.
" Try to open a location list; if this window *is* a location list,
" then this will succeed and the focus will stay on this window.
" If this is a QuickFix window, there will be an exception and the
" focus will stay on this window.
try
noautocmd lopen
catch /E776:/
" This was a QuickFix window.
return 1
endtry
endif
return 0
endfunction
" Return 1 if current window is a Location List window.
function! IsLocListWin()
return (&buftype == "quickfix" && !IsQuickFixWin())
endfunction
" Return window number of QuickFix buffer (or zero if not found).
function! GetQuickFixWinNum()
let qfWinNum = 0
let curWinNum = winnr()
for winNum in range(1, winnr("$"))
execute "noautocmd " . winNum . "wincmd w"
if IsQuickFixWin()
let qfWinNum = winNum
break
endif
endfor
execute "noautocmd " . curWinNum . "wincmd w"
return qfWinNum
endfunction
" Return 1 if the QuickFix window is open.
function! QuickFixWinIsOpen()
return GetQuickFixWinNum() > 0
endfunction
" Return 1 if current window's location list window is open.
function! LocListWinIsOpen()
let curWinNum = winnr()
let numOpenWindows = winnr("$")
" Assume location list window is already open.
let isOpen = 1
try
noautocmd lopen
catch /E776:/
" No location list available; nothing was changed.
let isOpen = 0
endtry
if numOpenWindows != winnr("$")
" We just opened a new location list window. Revert to original
" window and close the newly opened window.
noautocmd wincmd p
noautocmd lclose
let isOpen = 0
endif
return isOpen
endfunction
" Open Quickfix window (if not already open).
function! Copen()
if !QuickFixWinIsOpen()
execute "silent botright copen " . g:QuickFixWinHeight
endif
endfunction
" Open QuickFix window using standard position and height.
command! -bar Copen call Copen()
" Open Location List window (if not already open).
function! Lopen()
if !LocListWinIsOpen()
execute "silent lopen " . g:LocListWinHeight
endif
endfunction
" Open Location List window using standard height.
command! -bar Lopen call Lopen()
--
--
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.
For more options, visit https://groups.google.com/d/optout.
Re: Vim 8 pre-announcement
On Wed, Aug 17, 2016 at 11:48:23AM +0300, LCD 47 wrote:
> On 16 August 2016, Yegappan Lakshmanan wrote:
> > getbufinfo()
> "options", "signs", and "variables" return lists that are potentially
> huge. Perhaps there should be a way to tell getbufinfo() to skip these lists;
> otherwise plugins would just avoid calling this function, for performance
> reasons.
I share the opinion that having a mechanism to select and/or exclude
keys from the dict to avoid loading and carrying around huge dicts
sounds a great thing.
> > gettabinfo()
> > getwininfo()
>
> From the manual:
>
> : Each List item is a Dictionary with the following entries:
> : bufnum number of buffer in the window
> : height window height
> : loclist 1 if showing a location list
> : {only with the +quickfix feature}
> : nr window number
> : options dictionary of window local options
> : quickfix1 if quickfix or location list window
> : {only with the +quickfix feature}
> : tpnrtab page number
> : variables dictionary of window local variables
> : width window width
> : winid window ID
>
> Perhaps "tpnr" should be renamed to something more suggestive, such as
> "tabnr"?
I guess this should apply also for the window, as `winnr` for example,
for consistency in the keys naming scheme.
just my $.02,
--
Guyzmo
--
--
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.
For more options, visit https://groups.google.com/d/optout.
[bug] write beyond end of string when calling feedkeys
Hi
Valgrind shows a write beyond end of string
in Vim-7.4. (huge) and older when doing:
$ vim -u NONE -N -S bug-feedkeys-7.4.7222.vim 2> log
... where bug-feedkeys-7.4.7222.vim is the one-line
attached file. Note that the file is in latin1 encoding
and my locale is en_US.UTF-8.
log file contains:
==4157== Memcheck, a memory error detector
==4157== Copyright (C) 2002-2015, and GNU GPL'd, by Julian Seward et al.
==4157== Using Valgrind-3.12.0.SVN and LibVEX; rerun with -h for copyright info
==4157== Command: vim -u NONE -N -S bug-feedkeys-7.4.7222.vim
==4157==
==4157== Invalid write of size 1
==4157==at 0x4BB05F: vim_strsave_escape_csi (getchar.c:4695)
==4157==by 0x44DE8C: f_feedkeys (evalfunc.c:3126)
==4157==by 0x44A339: call_internal_func (evalfunc.c:997)
==4157==by 0x5E53E6: call_func (userfunc.c:1372)
==4157==by 0x5E319D: get_func_tv (userfunc.c:455)
==4157==by 0x5E8F70: ex_call (userfunc.c:2981)
==4157==by 0x47AC68: do_one_cmd (ex_docmd.c:2925)
==4157==by 0x477954: do_cmdline (ex_docmd.c:1110)
==4157==by 0x4755F8: do_source (ex_cmds2.c:4084)
==4157==by 0x474C0A: cmd_source (ex_cmds2.c:3697)
==4157==by 0x474B58: ex_source (ex_cmds2.c:3672)
==4157==by 0x47AC68: do_one_cmd (ex_docmd.c:2925)
==4157== Address 0xcd992d4 is 0 bytes after a block of size 4 alloc'd
==4157==at 0x4C2ABF5: malloc (vg_replace_malloc.c:299)
==4157==by 0x4F1427: lalloc (misc2.c:920)
==4157==by 0x4F12F4: alloc (misc2.c:818)
==4157==by 0x4BAE5B: vim_strsave_escape_csi (getchar.c:4662)
==4157==by 0x44DE8C: f_feedkeys (evalfunc.c:3126)
==4157==by 0x44A339: call_internal_func (evalfunc.c:997)
==4157==by 0x5E53E6: call_func (userfunc.c:1372)
==4157==by 0x5E319D: get_func_tv (userfunc.c:455)
==4157==by 0x5E8F70: ex_call (userfunc.c:2981)
==4157==by 0x47AC68: do_one_cmd (ex_docmd.c:2925)
==4157==by 0x477954: do_cmdline (ex_docmd.c:1110)
==4157==by 0x4755F8: do_source (ex_cmds2.c:4084)
==4157==
==4157== Invalid read of size 1
==4157==at 0x4C2DA04: strlen (vg_replace_strmem.c:454)
==4157==by 0x4B4FD2: ins_typebuf (getchar.c:979)
==4157==by 0x44DEDD: f_feedkeys (evalfunc.c:3129)
==4157==by 0x44A339: call_internal_func (evalfunc.c:997)
==4157==by 0x5E53E6: call_func (userfunc.c:1372)
==4157==by 0x5E319D: get_func_tv (userfunc.c:455)
==4157==by 0x5E8F70: ex_call (userfunc.c:2981)
==4157==by 0x47AC68: do_one_cmd (ex_docmd.c:2925)
==4157==by 0x477954: do_cmdline (ex_docmd.c:1110)
==4157==by 0x4755F8: do_source (ex_cmds2.c:4084)
==4157==by 0x474C0A: cmd_source (ex_cmds2.c:3697)
==4157==by 0x474B58: ex_source (ex_cmds2.c:3672)
==4157== Address 0xcd992d4 is 0 bytes after a block of size 4 alloc'd
==4157==at 0x4C2ABF5: malloc (vg_replace_malloc.c:299)
==4157==by 0x4F1427: lalloc (misc2.c:920)
==4157==by 0x4F12F4: alloc (misc2.c:818)
==4157==by 0x4BAE5B: vim_strsave_escape_csi (getchar.c:4662)
==4157==by 0x44DE8C: f_feedkeys (evalfunc.c:3126)
==4157==by 0x44A339: call_internal_func (evalfunc.c:997)
==4157==by 0x5E53E6: call_func (userfunc.c:1372)
==4157==by 0x5E319D: get_func_tv (userfunc.c:455)
==4157==by 0x5E8F70: ex_call (userfunc.c:2981)
==4157==by 0x47AC68: do_one_cmd (ex_docmd.c:2925)
==4157==by 0x477954: do_cmdline (ex_docmd.c:1110)
==4157==by 0x4755F8: do_source (ex_cmds2.c:4084)
Code in getchar.c:
4654 char_u *
4655 vim_strsave_escape_csi(
4656 char_u *p)
4657 {
4658 char_u *res;
4659 char_u *s, *d;
4660
4661 /* Need a buffer to hold up to three times as much. */
4662 res = alloc((unsigned)(STRLEN(p) * 3) + 1);
4663 if (res != NULL)
4664 {
4665 d = res;
4666 for (s = p; *s != NUL; )
4667 {
4668 if (s[0] == K_SPECIAL && s[1] != NUL && s[2] != NUL)
4669 {
4670 /* Copy special key unmodified. */
4671 *d++ = *s++;
4672 *d++ = *s++;
4673 *d++ = *s++;
4674 }
4675 else
4676 {
4677 #ifdef FEAT_MBYTE
4678 int len = mb_char2len(PTR2CHAR(s));
4679 int len2 = mb_ptr2len(s);
4680 #endif
4681 /* Add character, possibly multi-byte to
destination, escaping
4682 * CSI and K_SPECIAL. */
4683 d = add_char2buf(PTR2CHAR(s), d);
4684 #ifdef FEAT_MBYTE
4685 while (len < len2)
4686 {
4687 /* add following combining char */
4688 d = add_char2buf(PTR2CHAR(s + len), d);
4689 len += mb_char2len(PTR2CHAR(s + len));
4690 }
4691 #endif
4692 mb_ptr_adv(s);
4693 }
4694 }
4695 *d = NUL;
4696 }
4697 return res;
4698 }
I see that vim_strsave_escape_csi() is invoked with
p[0]=0xc0 p[1]=0x0 which is a truncated utf-8 string,
or character À in latin1. Line
[patch] :make doesn't support encoding conversion
Hi,
I wrote a patch for the following todo item:
> Win32: When running ":make" and 'encoding' differs from the system locale, the
> output should be converted. Esp. when 'encoding' is "utf-8". (Yongwei Wu)
> Should we use 'termencoding' for this?
I think using 'termencoding' for this is not so good. Normally the encoding
of a command output is the same as the encoding of the terminal, but not
always the same. I hear that some commands on Windows use utf-8 instead of
the current codepage. So I added a new option 'cmdencoding' ('cenc').
What do you think of this?
It would be nice, if `:make` and other commands would support encoding
detection, but I think it's difficult because `:make` reads the output line by
line. So encoding detection is not implemented now.
Regards,
Ken Takata
--
--
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.
For more options, visit https://groups.google.com/d/optout.
# HG changeset patch
# Parent 2cc7f84f678149b42c75ee230dd601806846122d
diff --git a/runtime/doc/options.txt b/runtime/doc/options.txt
--- a/runtime/doc/options.txt
+++ b/runtime/doc/options.txt
@@ -1627,6 +1627,24 @@ A jump table for the options with a shor
The rest of the option value will be used for
{pattern}, this must be the last entry.
+ *'cmdencoding'* *'cenc'*
+'cmdencoding' 'cenc' string (default "")
+ global
+ {only available when compiled with the |+multi_byte|
+ feature}
+ {not in Vi}
+ Encoding used for reading/writing the output/input of external
+ commands. When empty, encoding is not converted.
+ This is used for `:make`, `:lmake`, `:grep`, `:lgrep`, `:grepadd`,
+ `:lgrepadd`, `:cfile`, `:cgetfile`, `:caddfile`, `:lfile`, `:lgetfile`,
+ and `:laddfile`.
+
+ This would be mostly useful when you use MS-Windows and set 'encoding'
+ to "utf-8". If iconv is enabled, setting 'cmdencoding' to "char" has
+ the same effect as setting to the system locale encoding. Example: >
+ :set encoding=utf-8
+ :set cmdencoding=char " system locale is used
+<
*'cmdheight'* *'ch'*
'cmdheight' 'ch' number (default 1)
global
diff --git a/runtime/doc/quickfix.txt b/runtime/doc/quickfix.txt
--- a/runtime/doc/quickfix.txt
+++ b/runtime/doc/quickfix.txt
@@ -320,6 +320,7 @@ use this code: >
endfunction
au QuickfixCmdPost make call QfMakeConv()
+Another option is using 'cmdencoding'.
EXECUTE A COMMAND IN ALL THE BUFFERS IN QUICKFIX OR LOCATION LIST:
@@ -586,11 +587,17 @@ 4. Using :make *:make_makeprg*
like |:cnext| and |:cprevious|, see above.
This command does not accept a comment, any "
characters are considered part of the arguments.
+ If the encoding of the program output differs from the
+ 'encoding' option, you can use the 'cmdencoding'
+ option to specify the encoding.
*:lmak* *:lmake*
:lmak[e][!] [arguments]
Same as ":make", except the location list for the
current window is used instead of the quickfix list.
+ If the encoding of the program output differs from the
+ 'encoding' option, you can use the 'cmdencoding'
+ option to specify the encoding.
The ":make" command executes the command given with the 'makeprg' option.
This is done by passing the command to the shell given with the 'shell'
@@ -645,6 +652,7 @@ read the error messages: >
au QuickfixCmdPost make call QfMakeConv()
(Example by Faque Cheng)
+Another option is using 'cmdencoding'.
==
5. Using :vimgrep and :grep*grep* *lid*
diff --git a/src/option.c b/src/option.c
--- a/src/option.c
+++ b/src/option.c
@@ -781,6 +781,15 @@ static struct vimoption options[] =
{(char_u *)"", (char_u *)0L}
#endif
SCRIPTID_INIT},
+{"cmdencoding", "cenc", P_STRING|P_VI_DEF|P_RCLR,
+#ifdef FEAT_MBYTE
+ (char_u *)&p_cenc, PV_NONE,
+ {(char_u *)"", (char_u *)0L}
+#else
+ (char_u *)NULL, PV_NONE,
+ {(char_u *)0L, (char_u *)0L}
+#endif
+ SCRIPTID_INIT},
{"cmdheight", "ch", P_NUM|P_VI_DEF|P_RALL,
(char_u *)&p_ch, PV_NONE,
{(char_u *)1L, (char_u *)0L} SCRIPTID_INIT},
@@ -6092,7 +6101,8 @@ did_set_string_option(
#ifdef FEAT_MBYTE
/* 'encoding' and 'fileencoding' */
-else if (varp == &p_enc || gvarp == &p_fenc || varp == &p_tenc)
+else if (varp == &p_enc || gvarp == &p_fenc || varp == &p_tenc
+ || varp == &p_cenc)
{
if (gvarp == &p_fenc)
{
diff --git a/src/option.h b/src/option.h
--- a/src/option.h
+++ b/src/option.h
@@ -410,6 +410,9 @@ EXTERN long p_cwh; /* 'cmdwinheight' */
#ifdef FEAT_CLIPBOARD
EXTERN char_u *p_cb; /* 'clipboard' *
Re: Vim 8 pre-announcement
On 16 August 2016, Yegappan Lakshmanan wrote:
> I am in particular interested in any comments/suggestions about the following
> new functions:
>
> getbufinfo()
From the manual:
: Each returned List item is a dictionary with the following
: entries:
: changed TRUE if the buffer is modified.
: changedtick number of changes made to the buffer.
: hidden TRUE if the buffer is hidden.
: listed TRUE if the buffer is listed.
: lnumcurrent line number in buffer.
: loaded TRUE if the buffer is loaded.
: namefull path to the file in the buffer.
: nr buffer number.
: options dictionary of buffer local options.
: signs list of signs placed in the buffer.
: Each list item is a dictionary with
: the following fields:
: idsign identifier
: lnum line number
: name sign name
: variables dictionary of buffer local variables.
: windows list of window IDs with this buffer
"options", "signs", and "variables" return lists that are potentially
huge. Perhaps there should be a way to tell getbufinfo() to skip these lists;
otherwise plugins would just avoid calling this function, for performance
reasons.
On the other hand, finding the number of lines in a buffer as "line('$')"
is very inefficient, so maybe this would be a good place to return it. But
again, as an option, since it would involve loading the buffer.
> gettabinfo()
> getwininfo()
From the manual:
: Each List item is a Dictionary with the following entries:
: bufnum number of buffer in the window
: height window height
: loclist 1 if showing a location list
: {only with the +quickfix feature}
: nr window number
: options dictionary of window local options
: quickfix1 if quickfix or location list window
: {only with the +quickfix feature}
: tpnrtab page number
: variables dictionary of window local variables
: width window width
: winid window ID
Perhaps "tpnr" should be renamed to something more suggestive, such as
"tabnr"?
> getqflist()
The manual could use some rephrasing. As it is, it sounds unnatural even
to my broken Engrish.
> setqflist()
> getcompletion()
Again, getcompletion() can return some potentially huge lists. Being able
to restrict results to smaller subsets could make this function a lot lighter.
/lcd
--
--
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.
For more options, visit https://groups.google.com/d/optout.
Re: Vim 8 pre-announcement
Bram: > Hello Vim users, > > Work on Vim 8.0 is coming close to an end. I hope version 8.0 can be > released in about two weeks. > > This is a last chance to modify new features in a way that is not > backwards compatible. Once 8.0 is out we can't make changes that would > break plugins. Can we have a binary mode in channels ? Which could be used to implement a virtual terminal inside vim in VimScript. According to the ":help channel", There is a "raw" mode in channels, but it will treat the whole message as a string, not a binary data. -- -- 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. For more options, visit https://groups.google.com/d/optout.
Re: Vim 8 pre-announcement
Hi Bram, 2016-08-17 1:43 GMT+09:00 Bram Moolenaar : > > Hello Vim users, > > Work on Vim 8.0 is coming close to an end. I hope version 8.0 can be > released in about two weeks. > > This is a last chance to modify new features in a way that is not > backwards compatible. Once 8.0 is out we can't make changes that would > break plugins. > > An overview of new features can be found in: > https://github.com/vim/vim/blob/master/runtime/doc/version8.txt > A version with links (but a day older): > http://vimhelp.appspot.com/version8.txt.html > > Please review the new features, try them out and report what should be > changed on the vim-dev maillist. Of course you should also report bugs > you find. > > Happy Vimming! > > > PS. If you are interested in meeting Vim users: Vimfest is happening in > Berlin Sept. 16-18. http://vimfest.org > > > -- > How To Keep A Healthy Level Of Insanity: > 9. As often as possible, skip rather than walk. > > /// Bram Moolenaar -- b...@moolenaar.net -- http://www.Moolenaar.net \\\ > ///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\ > \\\ an exciting new programming language -- http://www.Zimbu.org/// > \\\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. > For more options, visit https://groups.google.com/d/optout. :help job-term says: *job-term* "term": "open"Start a terminal and connect the job stdin/stdout/stderr to it. NOTE: Not implemented yet! This is not implemented yet. Is this not implemented in Vim 8.0? Thanks, thinca -- -- 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. For more options, visit https://groups.google.com/d/optout.
