Re: Patch 7.4.1646

[Ken Takata]

Hi Bram,

2016/3/25 Fri 5:58:36 UTC+9 Bram Moolenaar wrote:
> Patch 7.4.1646
> Problem:Using Python vim.bindeval() on a partial doesn't work. (Nikolai
> Pavlov)
> Solution:   Add VAR_PARTIAL support in Python.
> Files:  src/if_py_both.h

Maybe we also need VAR_PARTIAL support in if_mzsch.

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.

remote_expr() is broken

[ramelo1]

Hi,

I compiled the latest version (7.4.1643) and found that remote_expr() function 
is not working. I can use --remote-expr command line argument successfully but 
not the corresponding function:

$ gvim -u NONE --servername FOOBAR
$ gvim -u NONE

In the last Vim instance:

:echo remote_expr('FOOBAR', 'v:servername')

-Vim hangs and I get no response.

I'm using RHEL 5.5.

Thanks,
Ramel


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

[Bram Moolenaar]

Patch 7.4.1646
Problem:Using Python vim.bindeval() on a partial doesn't work. (Nikolai
Pavlov)
Solution:   Add VAR_PARTIAL support in Python.
Files:  src/if_py_both.h


*** ../vim-7.4.1645/src/if_py_both.h2016-03-19 22:11:47.436674835 +0100
--- src/if_py_both.h2016-03-24 21:54:12.266629182 +0100
***
*** 6032,6044 
case VAR_FUNC:
return NEW_FUNCTION(tv->vval.v_string == NULL
  ? (char_u *)"" : tv->vval.v_string);
case VAR_UNKNOWN:
Py_INCREF(Py_None);
return Py_None;
!   default:
PyErr_SET_VIM(N_("internal error: invalid value type"));
return NULL;
  }
  }
  
  typedef struct
--- 6032,6057 
case VAR_FUNC:
return NEW_FUNCTION(tv->vval.v_string == NULL
  ? (char_u *)"" : tv->vval.v_string);
+   case VAR_PARTIAL:
+   return NEW_FUNCTION(tv->vval.v_partial == NULL
+   ? (char_u *)"" : tv->vval.v_partial->pt_name);
case VAR_UNKNOWN:
+   case VAR_CHANNEL:
+   case VAR_JOB:
Py_INCREF(Py_None);
return Py_None;
!   case VAR_SPECIAL:
!   switch (tv->vval.v_number)
!   {
!   case VVAL_FALSE: return AlwaysFalse(NULL);
!   case VVAL_TRUE:  return AlwaysTrue(NULL);
!   case VVAL_NONE:
!   case VVAL_NULL:  return AlwaysNone(NULL);
!   }
PyErr_SET_VIM(N_("internal error: invalid value type"));
return NULL;
  }
+ return NULL;
  }
  
  typedef struct
*** ../vim-7.4.1645/src/testdir/test_partial.vim2016-03-24 
21:41:47.206312503 +0100
--- src/testdir/test_partial.vim2016-03-24 21:45:28.936030177 +0100
***
*** 206,208 
--- 206,222 
  call assert_true(v:errmsg, v:exception)
endtry
  endfunc
+ 
+ func Test_bind_in_python()
+   if has('python')
+ let g:d = {}
+ function g:d.test2()
+ endfunction
+ python import vim
+ try
+   call assert_equal(pyeval('vim.bindeval("g:d.test2")'), g:d.test2)
+ catch
+   call assert_true(v:false, v:exception)
+ endtry
+   endif
+ endfunc
*** ../vim-7.4.1645/src/version.c   2016-03-24 21:41:47.206312503 +0100
--- src/version.c   2016-03-24 21:55:21.753911050 +0100
***
*** 750,751 
--- 750,753 
  {   /* Add new patch number below this line */
+ /**/
+ 1646,
  /**/

-- 
Two percent of zero is almost nothing.

 /// 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.1645

[Bram Moolenaar]

Patch 7.4.1645
Problem:When a dict contains a partial it can't be redefined as a
function. (Nikolai Pavlov)
Solution:   Remove the partial when overwriting with a function.
Files:  src/eval.c, src/testdir/test_partial.vim


*** ../vim-7.4.1644/src/eval.c  2016-03-24 21:23:02.281875291 +0100
--- src/eval.c  2016-03-24 21:38:30.428338372 +0100
***
*** 23455,23461 
else
arg = fudi.fd_newkey;
if (arg != NULL && (fudi.fd_di == NULL
!|| fudi.fd_di->di_tv.v_type != VAR_FUNC))
{
if (*arg == K_SPECIAL)
j = 3;
--- 23455,23462 
else
arg = fudi.fd_newkey;
if (arg != NULL && (fudi.fd_di == NULL
!|| (fudi.fd_di->di_tv.v_type != VAR_FUNC
!&& fudi.fd_di->di_tv.v_type != VAR_PARTIAL)))
{
if (*arg == K_SPECIAL)
j = 3;
*** ../vim-7.4.1644/src/testdir/test_partial.vim2016-03-24 
21:23:02.285875250 +0100
--- src/testdir/test_partial.vim2016-03-24 21:29:30.569892823 +0100
***
*** 193,195 
--- 193,208 
  call assert_true(v:false, v:exception)
endtry
  endfunc
+ 
+ func Test_redefine_dict_func()
+   let d = {}
+   function d.test4()
+   endfunction
+   let d.test4 = d.test4
+   try
+ function! d.test4(name)
+ endfunction
+   catch
+ call assert_true(v:errmsg, v:exception)
+   endtry
+ endfunc
*** ../vim-7.4.1644/src/version.c   2016-03-24 21:23:02.285875250 +0100
--- src/version.c   2016-03-24 21:31:28.668681709 +0100
***
*** 750,751 
--- 750,753 
  {   /* Add new patch number below this line */
+ /**/
+ 1645,
  /**/

-- 
hundred-and-one symptoms of being an internet addict:
115. You are late picking up your kid from school and try to explain
 to the teacher you were stuck in Web traffic.

 /// 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.1644

[Bram Moolenaar]

Patch 7.4.1644
Problem:Using string() on a partial that exists in the dictionary it binds
results in an error. (Nikolai Pavlov)
Solution:   Make string() not fail on a recursively nested structure. (Ken
Takta)
Files:  src/eval.c, src/testdir/test_partial.vim


*** ../vim-7.4.1643/src/eval.c  2016-03-24 19:14:31.821092318 +0100
--- src/eval.c  2016-03-24 21:11:33.132945779 +0100
***
*** 7851,7860 
break;
  
case VAR_PARTIAL:
!   *tofree = NULL;
!   /* TODO: arguments */
!   r = tv->vval.v_partial == NULL ? NULL : tv->vval.v_partial->pt_name;
!   break;
  
case VAR_LIST:
if (tv->vval.v_list == NULL)
--- 7851,7900 
break;
  
case VAR_PARTIAL:
!   {
!   partial_T   *pt = tv->vval.v_partial;
!   char_u  *fname = string_quote(pt == NULL ? NULL
!   : pt->pt_name, FALSE);
!   garray_Tga;
!   int i;
!   char_u  *tf;
! 
!   ga_init2(, 1, 100);
!   ga_concat(, (char_u *)"function(");
!   if (fname != NULL)
!   {
!   ga_concat(, fname);
!   vim_free(fname);
!   }
!   if (pt != NULL && pt->pt_argc > 0)
!   {
!   ga_concat(, (char_u *)", [");
!   for (i = 0; i < pt->pt_argc; ++i)
!   {
!   if (i > 0)
!   ga_concat(, (char_u *)", ");
!   ga_concat(,
!tv2string(>pt_argv[i], , numbuf, copyID));
!   vim_free(tf);
!   }
!   ga_concat(, (char_u *)"]");
!   }
!   if (pt != NULL && pt->pt_dict != NULL)
!   {
!   typval_T dtv;
! 
!   ga_concat(, (char_u *)", ");
!   dtv.v_type = VAR_DICT;
!   dtv.vval.v_dict = pt->pt_dict;
!   ga_concat(, tv2string(, , numbuf, copyID));
!   vim_free(tf);
!   }
!   ga_concat(, (char_u *)")");
! 
!   *tofree = ga.ga_data;
!   r = *tofree;
!   break;
!   }
  
case VAR_LIST:
if (tv->vval.v_list == NULL)
***
*** 7941,7990 
case VAR_FUNC:
*tofree = string_quote(tv->vval.v_string, TRUE);
return *tofree;
-   case VAR_PARTIAL:
-   {
-   partial_T   *pt = tv->vval.v_partial;
-   char_u  *fname = string_quote(pt == NULL ? NULL
-   : pt->pt_name, FALSE);
-   garray_Tga;
-   int i;
-   char_u  *tf;
- 
-   ga_init2(, 1, 100);
-   ga_concat(, (char_u *)"function(");
-   if (fname != NULL)
-   {
-   ga_concat(, fname);
-   vim_free(fname);
-   }
-   if (pt != NULL && pt->pt_argc > 0)
-   {
-   ga_concat(, (char_u *)", [");
-   for (i = 0; i < pt->pt_argc; ++i)
-   {
-   if (i > 0)
-   ga_concat(, (char_u *)", ");
-   ga_concat(,
-tv2string(>pt_argv[i], , numbuf, copyID));
-   vim_free(tf);
-   }
-   ga_concat(, (char_u *)"]");
-   }
-   if (pt != NULL && pt->pt_dict != NULL)
-   {
-   typval_T dtv;
- 
-   ga_concat(, (char_u *)", ");
-   dtv.v_type = VAR_DICT;
-   dtv.vval.v_dict = pt->pt_dict;
-   ga_concat(, tv2string(, , numbuf, copyID));
-   vim_free(tf);
-   }
-   ga_concat(, (char_u *)")");
- 
-   *tofree = ga.ga_data;
-   return *tofree;
-   }
case VAR_STRING:
*tofree = string_quote(tv->vval.v_string, FALSE);
return *tofree;
--- 7981,7986 
***
*** 7997,8002 
--- 7993,7999 
case VAR_NUMBER:
case VAR_LIST:
case VAR_DICT:
+   case VAR_PARTIAL:
case VAR_SPECIAL:
case VAR_JOB:
case VAR_CHANNEL:
***
*** 19258,19264 
  char_unumbuf[NUMBUFLEN];
  
  rettv->v_type = VAR_STRING;
! rettv->vval.v_string = tv2string([0], , numbuf, 0);
  /* Make a copy if we have a value but it's not in allocated memory. */
  if (rettv->vval.v_string != NULL && tofree == NULL)
rettv->vval.v_string = vim_strsave(rettv->vval.v_string);
--- 19255,19262 
  char_unumbuf[NUMBUFLEN];
  
  

Re: [vim] Vim cryptmethod uses SHA-256 for password-based key derivation (#639)

[Bram Moolenaar]

Manuel Ortega wrote:

> On Wed, Mar 23, 2016 at 10:28 PM, Ben Fritz  wrote:
> 
> > On Wednesday, March 23, 2016 at 6:21:21 PM UTC-5, Manuel Ortega wrote:
> > > > That reminds me of something else. Why isn't 'modified' set when you
> > change cryptmethod or the encryption password?
> > >
> > >
> > > Isn't it because the *buffer* hasn't changed?  IIUC, in the latter case
> > the *file* changes, not the buffer.  In the former case neither has
> > changed, so for sure 'modified' should not be set.
> >
> > If you change any of 'fileformat', 'fileencoding', 'bomb', or 'nofixeol'
> > then the buffer doesn't change either, only the file. 'cryptmethod' is the
> > oddball here.
> >
> 
> I knew about the first two, but the last two are *really* surprising.  They
> aren't mentioned at ":help 'mod'", nor are they mentioned at their own
> respective ":help"s.  (Bram, if this is the intended behavior, it should
> probably be documented at least at :h 'mod', and probably :h 'bomb' and :h
> 'fixeol'.)

I'll add a remark.

> > I view the 'modified' flag as saying "if you save this buffer then the
> > file will change".
> 
> If that's what it means, the docs need to be fixed.

No, that's not really what it means.


> > I got caught once while I was testing something where I had the wrong
> > password because I had quit Vim after changing the password, but I hadn't
> > saved yet. Vim let me do that without any complaint, because the buffer
> > wasn't modified.
> 
> Changing 'cryptmethod' should ONLY result in a setting of  if  is
> set to something.  If I haven't turned encryption on, so to speak, then
> setting  to "blowfish2" shouldn't set the modified flag.  (For under
> this circumstance, the file will not change even if the buffer is saved).

Although there is something to say for it, changing this behavior
probably causes more confusion than it solves.  Especially if someone
changes the key then then does "ZZ", expecting the file NOT to be
written.

-- 
hundred-and-one symptoms of being an internet addict:
113. You are asked about a bus schedule, you wonder if it is 16 or 32 bits.

 /// 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.1643

[Bram Moolenaar]

Patch 7.4.1643 (after 7.4.1641)
Problem:Terminating file name has side effects.
Solution:   Restore the character. (mostly by James McCoy, closes #713)
Files:  src/eval.c, src/testdir/test105.in, src/testdir/test105.ok


*** ../vim-7.4.1642/src/eval.c  2016-03-23 22:28:20.940072694 +0100
--- src/eval.c  2016-03-24 19:09:30.796172120 +0100
***
*** 26440,26447 
--- 26440,26449 
  if (src[*usedlen] == ':' && src[*usedlen + 1] == 'S')
  {
/* vim_strsave_shellescape() needs a NUL terminated string. */
+   c = (*fnamep)[*fnamelen];
(*fnamep)[*fnamelen] = NUL;
p = vim_strsave_shellescape(*fnamep, FALSE, FALSE);
+   (*fnamep)[*fnamelen] = c;
if (p == NULL)
return -1;
vim_free(*bufp);
*** ../vim-7.4.1642/src/testdir/test105.in  2016-03-23 22:28:20.940072694 
+0100
--- src/testdir/test105.in  2016-03-24 19:07:56.161138770 +0100
***
*** 36,41 
--- 36,42 
  :Put fnamemodify('abc''%''def',':S'  )
  :Put fnamemodify("abc\ndef",   ':S'  )
  :Put expand('%:r:S') == shellescape(expand('%:r'))
+ :Put join([expand('%:r'), expand('%:r:S'), expand('%')], ',')
  :set shell=tcsh
  :Put fnamemodify("abc\ndef",   ':S'  )
  :$put ='vim: ts=8'
*** ../vim-7.4.1642/src/testdir/test105.ok  2016-03-23 22:28:20.940072694 
+0100
--- src/testdir/test105.ok  2016-03-24 19:07:56.161138770 +0100
***
*** 26,30 
--- 26,31 
  fnamemodify('abc''%''def',':S'  ) '''abc''\%''\def'''
  fnamemodify("abc\ndef",   ':S'  ) '''abc^@def'''
  expand('%:r:S') == shellescape(expand('%:r')) 1
+ join([expand('%:r'), expand('%:r:S'), expand('%')], ',')  
'test105,''test105'',test105.in'
  fnamemodify("abc\ndef",   ':S'  ) '''abc\^@def'''
  vim: ts=8
*** ../vim-7.4.1642/src/version.c   2016-03-24 18:24:54.011501774 +0100
--- src/version.c   2016-03-24 19:11:21.147045101 +0100
***
*** 750,751 
--- 750,753 
  {   /* Add new patch number below this line */
+ /**/
+ 1643,
  /**/

-- 
Nobody will ever need more than 640 kB RAM.
-- Bill Gates, 1983
Windows 98 requires 16 MB RAM.
-- Bill Gates, 1999
Logical conclusion: Nobody will ever need Windows 98.

 /// 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] Add optiontype function

[Bram Moolenaar]

Anton Lindqvist wrote:

> Hi,
> This patch adds a function with the declaration optiontype({option})
> which returns the type of the given option. I'm currently using it to
> achieve the following option toggle mapping:
> 
>   " :NMapChangeOption[!] {letter} {option} [enable]
>   "
>   " Create a normal mode option toggle mapping for {option}. The mapping key
>   " sequence will be prefixed with 'co' followed by {letter}.
>   "
>   " By default the option will only be changed in the current buffer. Using 
> [!]
>   " will change the option globally.
>   "
>   " Boolean option example:
>   "
>   "   :NMapChangeOption s spell
>   "
>   " Pressing 'cos' will toggle the spell option on and off.
>   "
>   " Non boolean option example:
>   "
>   "   :NMapChangeOption y syntax ON
>   "
>   " The optional [enable] argument can be used for string and comma separated
>   " list options. Pressing 'coy' will add/remove 'ON' from the syntax option.
>   "
>   " This functionality is borrowed from Tim Pope's unimpaired.vim plugin.
>   command! -bang -complete=option -nargs=+ NMapChangeOption
> \ call s:NMapChangeOption(0, )
>   func! s:NMapChangeOption(global, letter, option, ...) abort
> let set = a:global ? 'set' : 'setlocal'
> let type = optiontype(a:option)
> if type == 0 " boolean
>   let rhs = printf(':%s =&%s ? "no" : ""%s',
> \ set, a:option, a:option)
> elseif type == 2 " comma separated list
>   let rhs = printf(':%s %s=&%s !~# "%s" ? "+=" : "-="%s',
> \ set, a:option, a:option, a:1, a:1)
> elseif type == 4 " string
>   let rhs = printf(':%s %s=&%s == "%s" ? "&" : "=%s"',
> \ set, a:option, a:option, a:1, a:1)
> endif
> exe 'nnoremap co' . a:letter rhs
>   endfunc
> 
>   NMapChangeOption  c colorcolumn +1
>   NMapChangeOption! h hlsearch
>   NMapChangeOption  l list
>   NMapChangeOption! p paste
>   NMapChangeOption  s spell
>   NMapChangeOption  w wrap
>   NMapChangeOption  y syntax ON
> 
> The patch includes tests and docs.

I can see how this would be useful.  But returning just a number is
limited.  There are many more properties of an option, such as whether
it is window-local, was set or not, can be set from a modeline, etc.
Not that we need to add all those properties now, but I'm sure someone
will want to add them later.  Perhaps using "optionproperties()" and
returning a Dictionary?

-- 
hundred-and-one symptoms of being an internet addict:
111. You and your friends get together regularly on IRC, even though
 all of you live in the same city.

 /// 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: Arrow characters shouldn't be wide

[Bram Moolenaar]

Matteo Cavalleri wrote:

> > > Il giorno martedì 22 marzo 2016 20:31:39 UTC+1, Bram Moolenaar ha scritto:
> > > 
> > > > 
> > > > What version?  Patch 7.4.1629 should be included.
> > >  
> > > I install vim from source, so all patches are included.
> > > 
> > > ~ brew install --HEAD --with-lua vim
> > > ~ vim --version
> > > VIM - Vi IMproved 7.4 (2013 Aug 10, compiled Mar 23 2016 09:19:48)
> > > MacOS X (unix) version
> > > Included patches: 1-1639
> > > [...]
> > > 
> > > I just checked and it still happens:
> > > 
> > > http://imgur.com/PLiTeiX
> > 
> > What is that character in the sign column?  Apparently Vim thinks it's
> > double width but the font has it single width.  Do you have the 'emoji'
> > option enabled?
> > 
> > One solution would be that after drawing any character which we don't
> > know for sure what the width is we position the cursor.
> 
> if I use "ga" on that character I get:
> 
> <✖> 10006, Hex 2716, Octal 23426
> 
> BTW if i install vim with:
> 
>  ~ brew install --with-lua vim
>  ~ vim --version
> VIM - Vi IMproved 7.4 (2013 Aug 10, compiled Mar 23 2016 09:25:39)
> MacOS X (unix) version
> Included patches: 1-1589
> 
> I don't see the problem. so the bug seems to be somewhere between
> patch 1590 and 1636. hope this helps.

I see the problem in xterm.  So this character is mostly considered
single width.

I think the idea of marking all emoji characters as full width is a bad
idea.  It doesn't match what actually happens.

Perhaps we should restrict this to the new characters in the 1f000
range?  I think that's a better solution for now.

-- 
hundred-and-one symptoms of being an internet addict:
108. While reading a magazine, you look for the Zoom icon for a better
 look at a photograph.

 /// 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.1642

[Bram Moolenaar]

Patch 7.4.1642
Problem:Handling emoji characters as full width has problems with
backwards compatibility.
Solution:   Only put characters in the 1f000 range in the emoji table.
Files:  runtime/tools/unicode.vim, src/mbyte.c


*** ../vim-7.4.1641/runtime/tools/unicode.vim   2016-03-21 22:09:39.552789897 
+0100
--- runtime/tools/unicode.vim   2016-03-24 18:23:13.672520525 +0100
***
*** 283,288 
--- 283,294 
call add(alltokens, token)
  endif
  
+ " Characters below 1F000 may be considered single width traditionally,
+ " making them double width causes problems.
+ if first < 0x1f000
+   continue
+ endif
+ 
  " exclude characters that are in the "ambiguous" or "doublewidth" table
  for ambi in s:ambitable
if first >= ambi[0] && first <= ambi[1]
*** ../vim-7.4.1641/src/mbyte.c 2016-03-21 22:15:25.489161889 +0100
--- src/mbyte.c 2016-03-24 18:20:25.318230103 +0100
***
*** 1445,1508 
   * based on http://unicode.org/emoji/charts/emoji-list.html */
  static struct interval emoji_width[] =
  {
-   {0x203c, 0x203c},
-   {0x2049, 0x2049},
-   {0x2139, 0x2139},
-   {0x21a9, 0x21aa},
-   {0x231a, 0x231b},
-   {0x2328, 0x2328},
-   {0x23cf, 0x23cf},
-   {0x23e9, 0x23f3},
-   {0x25aa, 0x25ab},
-   {0x25fb, 0x25fe},
-   {0x2600, 0x2604},
-   {0x2611, 0x2611},
-   {0x2618, 0x2618},
-   {0x261d, 0x261d},
-   {0x2620, 0x2620},
-   {0x2622, 0x2623},
-   {0x2626, 0x2626},
-   {0x262a, 0x262a},
-   {0x262e, 0x262f},
-   {0x2638, 0x263a},
-   {0x2648, 0x2653},
-   {0x2666, 0x2666},
-   {0x267b, 0x267b},
-   {0x267f, 0x267f},
-   {0x2692, 0x2694},
-   {0x2696, 0x2697},
-   {0x2699, 0x2699},
-   {0x269b, 0x269c},
-   {0x26a0, 0x26a1},
-   {0x26aa, 0x26ab},
-   {0x26b0, 0x26b1},
-   {0x26bd, 0x26bd},
-   {0x26ce, 0x26ce},
-   {0x2702, 0x2702},
-   {0x2705, 0x2705},
-   {0x2708, 0x270d},
-   {0x270f, 0x270f},
-   {0x2712, 0x2712},
-   {0x2714, 0x2714},
-   {0x2716, 0x2716},
-   {0x271d, 0x271d},
-   {0x2721, 0x2721},
-   {0x2728, 0x2728},
-   {0x2733, 0x2734},
-   {0x2744, 0x2744},
-   {0x2747, 0x2747},
-   {0x274c, 0x274c},
-   {0x274e, 0x274e},
-   {0x2753, 0x2755},
-   {0x2763, 0x2764},
-   {0x2795, 0x2797},
-   {0x27a1, 0x27a1},
-   {0x27b0, 0x27b0},
-   {0x27bf, 0x27bf},
-   {0x2934, 0x2935},
-   {0x2b05, 0x2b07},
-   {0x2b1b, 0x2b1c},
-   {0x2b50, 0x2b50},
{0x1f004, 0x1f004},
{0x1f0cf, 0x1f0cf},
{0x1f1e6, 0x1f1ff},
--- 1445,1450 
*** ../vim-7.4.1641/src/version.c   2016-03-23 22:28:20.944072651 +0100
--- src/version.c   2016-03-24 18:21:14.817727419 +0100
***
*** 750,751 
--- 750,753 
  {   /* Add new patch number below this line */
+ /**/
+ 1642,
  /**/

-- 
hundred-and-one symptoms of being an internet addict:
109. You actually read -- and enjoy -- lists like this.

 /// 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] Vim cryptmethod uses SHA-256 for password-based key derivation (#639)

[Benjamin Fritz]

On Thu, Mar 24, 2016 at 10:47 AM, Manuel Ortega 
wrote:
>
> The purpose of *Vim*'s cryptography, as Bram is trying to stress and
nobody seems to ever internalize, is to keep data secret from neighbors and
family members, i.e., people not sophisticated enough or motivated enough
to e.g., realize that it's VimCrypt, find that webpage, know what a perl
script is, know how to apply it, etc.

I disagree. If that's the case, then why did Vim ever get a new cryptmethod
at all? zip is just fine for those purposes.

>  It is pretty clearly implied in ":h encrypt" that the purpose of Vim's
encryption is not to keep data secret from people who even partly know what
they're doing.
>

I disagree here too. In :help encryption I see "The encrypted text cannot
be read without the right key" and "You could do this to edit very secret
text." In :help 'cryptmethod' I see blowfish and blowfish2 described as
"medium strong encryption." Nowhere do I get the impression Vim's
cryptography is not secure enough to keep data secret from people who know
what you're doing. In fact I get the opposite impression, that Vim's
cryptography is probably strong enough for most purposes if you use
"blowfish2".

> For this purpose, it works.
>
> But really: it shouldn't be Vim's job to encrypt files on disk anymore
than it's Vim's job to do compression and decompression.  There are plugins
to use GPG transparently like there are for compressing and decompressing
transparently.
>

And I disagree yet again here. If encryption is not built into the editor,
then you cannot use features like swap files or undo files or you risk
exposing decrypted text in those files. I think it's a great feature to
support encryption in the editor itself to avoid exposing data like that.
Additionally the editor could lock the memory to prevent unencrypted data
in a buffer from getting saved off to swap space. I don't know whether Vim
does that (it probably should), but there's no way you could do that
outside of Vim. So either you need some sort of editor built into your
encryption program with fewer features than Vim, or you need to do the
encryption within Vim, or Vim needs to provide better hooks for external
tools to encrypt in multiple places.

-- 
-- 
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] Vim cryptmethod uses SHA-256 for password-based key derivation (#639)

[Benjamin Fritz]

On Thu, Mar 24, 2016 at 9:54 AM, Benjamin Fritz 
wrote:
>
> The help entry blowfish and blowfish2 both say "medium strong
encryption". An "implementation flaw" is mentioned for blowfish, but IIUC
the flaw is severe enough to make it much, much weaker than blowfish2. Why
are they both summarized as the same strength?
>

Ah, I see some stronger warnings in :help encrypt. I think those should be
emphasized more and maybe cross-referenced in the help for 'cryptmethod'.

-- 
-- 
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] Vim cryptmethod uses SHA-256 for password-based key derivation (#639)

[Manuel Ortega]

On Thu, Mar 24, 2016 at 10:54 AM, Benjamin Fritz 
wrote:

>
>
> On Thu, Mar 24, 2016 at 6:08 AM, Bram Moolenaar 
> wrote:
> >
> >
> > Ben Fritz wrote:
> >
> > > On Wed, Mar 23, 2016 at 4:58 PM, Bram Moolenaar 
> wrote:
> > > > The original blowfish encryption is not broken, it's just weaker
> than it
> > > > should be.  It's still a lot stronger than zip.
> > >
> > > Is it? This page makes it sound like "blowfish" was pretty much
> completely
> > > broken if you knew any of the plaintext:
> https://dgl.cx/2014/10/vim-blowfish
> >
> > Your definition of broken is wrong.  Broken means it doesn't work at
> > all.  e.g., Vim crashes when using it, or when decrypting you can't get
> > back the original text.  When do you call a car broken?  When you can't
> > drive.  Not when you can't open the window.
> >
>
> I call something "broken" when it cannot serve its intended purpose.
> Cryptography's purpose is to keep data secret.
>

The purpose of *Vim*'s cryptography, as Bram is trying to stress and nobody
seems to ever internalize, is to keep data secret from neighbors and family
members, i.e., people not sophisticated enough or motivated enough to e.g.,
realize that it's VimCrypt, find that webpage, know what a perl script is,
know how to apply it, etc.  It is pretty clearly implied in ":h encrypt"
that the purpose of Vim's encryption is not to keep data secret from people
who even partly know what they're doing.

For this purpose, it works.

But really: it shouldn't be Vim's job to encrypt files on disk anymore than
it's Vim's job to do compression and decompression.  There are plugins to
use GPG transparently like there are for compressing and decompressing
transparently.

-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] Vim cryptmethod uses SHA-256 for password-based key derivation (#639)

[Benjamin Fritz]

On Thu, Mar 24, 2016 at 6:08 AM, Bram Moolenaar  wrote:
>
>
> Ben Fritz wrote:
>
> > On Wed, Mar 23, 2016 at 4:58 PM, Bram Moolenaar 
wrote:
> > > The original blowfish encryption is not broken, it's just weaker than
it
> > > should be.  It's still a lot stronger than zip.
> >
> > Is it? This page makes it sound like "blowfish" was pretty much
completely
> > broken if you knew any of the plaintext:
https://dgl.cx/2014/10/vim-blowfish
>
> Your definition of broken is wrong.  Broken means it doesn't work at
> all.  e.g., Vim crashes when using it, or when decrypting you can't get
> back the original text.  When do you call a car broken?  When you can't
> drive.  Not when you can't open the window.
>

I call something "broken" when it cannot serve its intended purpose.
Cryptography's purpose is to keep data secret. If that article is correct,
then with "blowfish" (not "blowfish2") there is a trivial attack that can
expose *at least* 64 characters of text in a file without ever knowing the
password. I'm not clear on the details (the article hand-waves a bit) but
potentially the rest of the file may also be recoverable.

If the encrypted file is the basis of a [password manager](
http://www.vim.org/scripts/script.php?script_id=5340) for example, then
this is quite bad. At least the first password is probably compromised if
an attacker gains access to the file.

If anything, this makes "blowfish" *worse* than zip in many scenarios. At
least with zip the attacker needs to work for it.

> > For example, if you had plugin that always writes a predictable header
text
> > to an encrypted file before the actual sensitive data, the attacker
would
> > know some plaintext. I'm certainly not comfortable using "blowfish",
> > knowing it had exploitable flaws fixed in blowfish2. I thought
"blowfish"
> > was just around to let people read their old data (and hopefully
convert to
> > blowfish2).
> >
> > And while I can probably *personally* use a strong-enough passphrase to
let
> > the current too-fast KDF for blowfish2 suffice, I wouldn't recommend it
to
> > anyone else, since I know most people choose passwords that can fall way
> > too fast with modern tools and techniques. I'd consider "blowfish2" to
be
> > broken for *general use* as well since you need a REALLY good password
for
> > it to provide any long-term security guarantees. Once we increase the
KDF
> > iterations sufficiently I would warn when saving in blowfish2 as well,
in
> > favor of the new method(s) using a better KDF.
>
> My favorite example is when I have some text that I don't want my
> neighbor to read.  Any encryption that Vim provides works for that.
>

That's a straw-man argument. You could also do ggg?G to rot13 the buffer
which would keep my neighbor or my kids from reading the file. If that's
not enough then a simple plugin to do a Caesar cipher as a
BufWritePre/BufRead would also do the trick. But nobody would seriously
suggest either of those are secure. Encryption must have a higher standard
than keeping out your non-hacker friends.

The help entry blowfish and blowfish2 both say "medium strong encryption".
An "implementation flaw" is mentioned for blowfish, but IIUC the flaw is
severe enough to make it much, much weaker than blowfish2. Why are they
both summarized as the same strength?

> Also keep in mind that, no matter how strong your encryption is, there
> is always a weak point.  Rembember key loggers?  There never ever is
> 100% reliable encryption.
>
> So please don't overreact.
>

This is true. Neither Vim nor any other encryption tool will protect from a
compromised system. I don't expect Vim to keep me safe from everything. But
I do expect, if I encrypt a file with any modern crypto tool, that I don't
need to worry if that file is snagged off my cloud storage, or someone
steals my USB stick, or something. Representing a crypto implementation as
"secure" when it is trivial to recover some number of bytes in a file is
going to leak someone's sensitive data because they trusted you. I don't
think it's overreacting to say "we shouldn't present weak crypto as strong
enough to keep using".

Maybe "broken" is too changed a word, I'll stop using it. I'll put it this
way:

zip - insecure, all of your file can be recovered with commonly available
tools. Not recommended.
blowfish - insecure, part or all of your file can be recovered with known
methods. Not recommended.
blowfish2 - secure for small files if you use a very strong password and
nobody else has write access.
proposed new methods - secure if you don't use a very weak password like
"123456", "password", or "letmein".

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

Re: RFE: support POSIX standard and developing RE's

[Christian Brabandt]

On Do, 24 Mär 2016, L. A. Walsh wrote:

> Posix, has 2 official RE's  already, the modern REs( like in
> grep -E, (extended RE's)
> and "obsolete RE's" as found in ed, called "basic REs".
> 
> Additionally for the past few years, more gnu utils (like grep -P)
> have started supporting a third type of RE's called
> PCRE [Perl Compatible RE's] that seem to be on their way
> to becoming a 3rd official type of RE.
> 
> Would it be possible to add the 3 RE's (w/appropriate flags)
> to invoke those standardized expressions (not as a replacement
> for any of the existing RE's), but w/different flags.
> 
> This would allow those who know the posix-compat RE's that
> are becoming more wide spread in usage, and would allow for
> easier, direct usage (cut) of the alternate RE's specifically
> to make it easer to define these expressions in shell-vars and/or
> vim-macros to allow for easier portability and usability between
> vim and other posix & gnu utils?  Note in the past few years,
> the pcreRE's have also added python-specific features to the
> syntax to allow for easier porting of python features.
> 
> Probably (or maybe) best of all, as all of these RE's are
> becoming more prevalent in posix, unix and linux environments,
> it would be a great benefit for people to be able to switch
> to alternate RE's based on familiarity and and the greater
> uniformity in these classes.
> 
> Seems this would lower the learning curve for RE usage in
> vim where it often, idiosyncratically differs from such,
> requiring much trial and error and wasted time to get
> equivalent vim-compat-RE's that are equivalent to other
> industry standard RE's.
> 
> Anyway, thought I'd mention this, since vim already has
> multiple incompatible RE's with existing standards and
> thought that providing a few "new POSIX-compat RE's" would
> only help in making vim easier to use.
> 
> Thanks for your time!
> -linda

There is https://github.com/vim/vim/issues/99
You might want to check, if this works for you.

Best,
Christian
-- 
Mögest Du leben, solange Du willst - und wollen, solange Du lebst!

-- 
-- 
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] Vim cryptmethod uses SHA-256 for password-based key derivation (#639)

[Bram Moolenaar]

Ben Fritz wrote:

> On Wed, Mar 23, 2016 at 4:58 PM, Bram Moolenaar  wrote:
> >
> > > Speaking of defaults: I think Vim should default to the strongest
> > > method available. I additionally think Vim should warn on saving with
> > > a known broken format such as the original blowfish implementation, or
> > > the zip algorithm, or even blowfish2 without a decent KDF. Maybe even
> > > compile without the broken algorithms altogether unless the user
> > > specifically passes --include-bad-crypto to the configure script or
> > > something.
> >
> > This has the danger of writing a file on one system, go on holiday and
> > find out you can't open it on your laptop (that actually happened to me).
> >
> 
> That makes some sense, however it only applies to people who edit the same
> file on multiple systems, AND they don't have the same version of Vim on
> each of those systems.
> 
> If you don't need that capability, having the old broken systems still in
> the code makes it too easy to make a mistake that could compromise your
> security.
> 
> DROWN recently showed some of the problems with keeping older known-broken
> crypto code enabled by default. I think it makes sense to keep the code
> there for people who deliberately choose to use it. But getting rid of it
> by default can potentially remove an attack vector.
> 
> At the very least, we should warn when saving in an insecure format.
> 
> > I think there should be some number of months between making a new
> > method available and making it the default.
> >
> 
> OK, that's fair.
> 
> > The original blowfish encryption is not broken, it's just weaker than it
> > should be.  It's still a lot stronger than zip.
> 
> Is it? This page makes it sound like "blowfish" was pretty much completely
> broken if you knew any of the plaintext: https://dgl.cx/2014/10/vim-blowfish

Your definition of broken is wrong.  Broken means it doesn't work at
all.  e.g., Vim crashes when using it, or when decrypting you can't get
back the original text.  When do you call a car broken?  When you can't
drive.  Not when you can't open the window.

> For example, if you had plugin that always writes a predictable header text
> to an encrypted file before the actual sensitive data, the attacker would
> know some plaintext. I'm certainly not comfortable using "blowfish",
> knowing it had exploitable flaws fixed in blowfish2. I thought "blowfish"
> was just around to let people read their old data (and hopefully convert to
> blowfish2).
> 
> And while I can probably *personally* use a strong-enough passphrase to let
> the current too-fast KDF for blowfish2 suffice, I wouldn't recommend it to
> anyone else, since I know most people choose passwords that can fall way
> too fast with modern tools and techniques. I'd consider "blowfish2" to be
> broken for *general use* as well since you need a REALLY good password for
> it to provide any long-term security guarantees. Once we increase the KDF
> iterations sufficiently I would warn when saving in blowfish2 as well, in
> favor of the new method(s) using a better KDF.

My favorite example is when I have some text that I don't want my
neighbor to read.  Any encryption that Vim provides works for that.

Also keep in mind that, no matter how strong your encryption is, there
is always a weak point.  Rembember key loggers?  There never ever is
100% reliable encryption.

So please don't overreact.

-- 
hundred-and-one symptoms of being an internet addict:
107. When using your phone you forget that you don't have to use your
 keyboard.

 /// 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: Arrow characters shouldn't be wide

[Matteo Cavalleri]

Il giorno giovedì 24 marzo 2016 10:06:57 UTC+1, Matteo Cavalleri ha scritto:

> if I use "ga" on that character I get:
> 
> <✖> 10006, Hex 2716, Octal 23426
> 

I forgot to say I have no options enabled regarding emoji in my vimrc, so I 
suppose it's set at its default value.


-- 
-- 
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: Arrow characters shouldn't be wide

[Matteo Cavalleri]

Il giorno mercoledì 23 marzo 2016 20:56:09 UTC+1, Bram Moolenaar ha scritto:
> Matteo Cavalleri wrote:
> 
> > Il giorno martedì 22 marzo 2016 20:31:39 UTC+1, Bram Moolenaar ha scritto:
> > 
> > > 
> > > What version?  Patch 7.4.1629 should be included.
> >  
> > I install vim from source, so all patches are included.
> > 
> > ~ brew install --HEAD --with-lua vim
> > ~ vim --version
> > VIM - Vi IMproved 7.4 (2013 Aug 10, compiled Mar 23 2016 09:19:48)
> > MacOS X (unix) version
> > Included patches: 1-1639
> > [...]
> > 
> > I just checked and it still happens:
> > 
> > http://imgur.com/PLiTeiX
> 
> What is that character in the sign column?  Apparently Vim thinks it's
> double width but the font has it single width.  Do you have the 'emoji'
> option enabled?
> 
> One solution would be that after drawing any character which we don't
> know for sure what the width is we position the cursor.

if I use "ga" on that character I get:

<✖> 10006, Hex 2716, Octal 23426

BTW if i install vim with:

 ~ brew install --with-lua vim
 ~ vim --version
VIM - Vi IMproved 7.4 (2013 Aug 10, compiled Mar 23 2016 09:25:39)
MacOS X (unix) version
Included patches: 1-1589

I don't see the problem. so the bug seems to be somewhere between patch 1590 
and 1636. hope this helps.


-- 
-- 
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] Add optiontype function

[Anton Lindqvist]

Hi,
This patch adds a function with the declaration optiontype({option})
which returns the type of the given option. I'm currently using it to
achieve the following option toggle mapping:

  " :NMapChangeOption[!] {letter} {option} [enable]
  "
  " Create a normal mode option toggle mapping for {option}. The mapping key
  " sequence will be prefixed with 'co' followed by {letter}.
  "
  " By default the option will only be changed in the current buffer. Using [!]
  " will change the option globally.
  "
  " Boolean option example:
  "
  "   :NMapChangeOption s spell
  "
  " Pressing 'cos' will toggle the spell option on and off.
  "
  " Non boolean option example:
  "
  "   :NMapChangeOption y syntax ON
  "
  " The optional [enable] argument can be used for string and comma separated
  " list options. Pressing 'coy' will add/remove 'ON' from the syntax option.
  "
  " This functionality is borrowed from Tim Pope's unimpaired.vim plugin.
  command! -bang -complete=option -nargs=+ NMapChangeOption
\ call s:NMapChangeOption(0, )
  func! s:NMapChangeOption(global, letter, option, ...) abort
let set = a:global ? 'set' : 'setlocal'
let type = optiontype(a:option)
if type == 0 " boolean
  let rhs = printf(':%s =&%s ? "no" : ""%s',
\ set, a:option, a:option)
elseif type == 2 " comma separated list
  let rhs = printf(':%s %s=&%s !~# "%s" ? "+=" : "-="%s',
\ set, a:option, a:option, a:1, a:1)
elseif type == 4 " string
  let rhs = printf(':%s %s=&%s == "%s" ? "&" : "=%s"',
\ set, a:option, a:option, a:1, a:1)
endif
exe 'nnoremap co' . a:letter rhs
  endfunc

  NMapChangeOption  c colorcolumn +1
  NMapChangeOption! h hlsearch
  NMapChangeOption  l list
  NMapChangeOption! p paste
  NMapChangeOption  s spell
  NMapChangeOption  w wrap
  NMapChangeOption  y syntax ON

The patch includes tests and docs.

-- 
:wq

-- 
-- 
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 642f0ad..f411beb 100644
--- a/runtime/doc/eval.txt
+++ b/runtime/doc/eval.txt
@@ -2023,6 +2023,7 @@ mode( [expr]) String  current editing 
mode
 mzeval( {expr})any evaluate |MzScheme| expression
 nextnonblank( {lnum})  Number  line nr of non-blank line >= {lnum}
 nr2char( {expr}[, {utf8}]) String  single char with ASCII/UTF8 value {expr}
+optiontype( {option})  Number  type of option {option}
 or( {expr}, {expr})Number  bitwise OR
 pathshorten( {expr})   String  shorten directory names in a path
 perleval( {expr})  any evaluate |Perl| expression
@@ -5316,6 +5317,15 @@ nr2char({expr}[, {utf8}])
*nr2char()*
characters.  nr2char(0) is a real NUL and terminates the
string, thus results in an empty string.
 
+optiontype({option})   *optiontype()* *E518*
+   Return the type of {option} as a Number:
+Boolean: 0
+ Number: 1
+   Comma separated list: 2
+ Char flag list: 3
+ String: 4
+   If {option} does not exist, -1 is returned.
+
 or({expr}, {expr}) *or()*
Bitwise OR on the two arguments.  The arguments are converted
to a number.  A List, Dict or Float argument causes an error.
diff --git a/src/eval.c b/src/eval.c
index b233833..38533d8 100644
--- a/src/eval.c
+++ b/src/eval.c
@@ -682,6 +682,7 @@ static void f_mzeval(typval_T *argvars, typval_T *rettv);
 static void f_nextnonblank(typval_T *argvars, typval_T *rettv);
 static void f_nr2char(typval_T *argvars, typval_T *rettv);
 static void f_or(typval_T *argvars, typval_T *rettv);
+static void f_optiontype(typval_T *argvars, typval_T *rettv);
 static void f_pathshorten(typval_T *argvars, typval_T *rettv);
 #ifdef FEAT_PERL
 static void f_perleval(typval_T *argvars, typval_T *rettv);
@@ -8327,6 +8328,7 @@ static struct fst
 {"nextnonblank",   1, 1, f_nextnonblank},
 {"nr2char",1, 2, f_nr2char},
 {"or", 2, 2, f_or},
+{"optiontype", 1, 1, f_optiontype},
 {"pathshorten",1, 1, f_pathshorten},
 #ifdef FEAT_PERL
 {"perleval",   1, 1, f_perleval},
@@ -15901,6 +15903,22 @@ f_or(typval_T *argvars, typval_T *rettv)
 }
 
 /*
+ * "optiontype(option)" function
+ */
+static void