Re: Vim 8 pre-announcement

[Nikolay Aleksandrovich Pavlov]

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

[Ken Takata]

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`

[h_east]

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 

Re: Vim 8 pre-announcement

[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.

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

[Bram Moolenaar]

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

[Bram Moolenaar]

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

[Bram Moolenaar]

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

[Bram Moolenaar]

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

[Bram Moolenaar]

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

[Danek Duvall]

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.

Re: [patch] fixed crash in sign command with deleted buffer

[Bram Moolenaar]

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

[Bram Moolenaar]

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

[Bram Moolenaar]

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

[Roland Puntaier]

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.

Patch 7.4.2224

[Bram Moolenaar]

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, ) == 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, ) == 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: error in test_startup_utf8

[Bram Moolenaar]

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.

Re: [bug] write beyond end of string when calling feedkeys

[Bram Moolenaar]

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 

Re: Vim 8 pre-announcement

['Guyzmo' via vim_dev]

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

[Yegappan Lakshmanan]

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  == "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 `` == "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

[Yegappan Lakshmanan]

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

[Yegappan Lakshmanan]

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

['Andy Wokula' via vim_dev]

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.

[patch] fixed crash in sign command with deleted buffer

[Dominique Pellé]

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

[Michael Henry]

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  == "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 `` == "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  == "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 ( == "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

['Guyzmo' via vim_dev]

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

[Dominique Pellé]

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.  

[patch] :make doesn't support encoding conversion

[Ken Takata]

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 *)_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 *)_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 == _enc || gvarp == _fenc || varp == _tenc)
+else if (varp == _enc || gvarp == _fenc || varp == _tenc
+			|| varp == _cenc)
 {
 	if (gvarp == _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' */
 #endif
+#ifdef 

Re: Vim 8 pre-announcement

[LCD 47]

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

[skywind3000]

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

[thinca]

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.