Christian Brabandt wrote:

> On Mi, 13 Feb 2013, Bram Moolenaar wrote:
>
> > Still have a long pending job of making the fast RE code work properly
> > and test it...
>
> Can't we just have an 'experimental' setting, that enables experimental
> features, e.g. the new fast RE? This would get this feature a lot more
> testing and we could check, whether it suffers the same bug (otherwise
> we never know, when this feature has enough testing to be ready to be
> included).
>
> (Also, patches to the regular expression engine like the last patch
> /[^\n] that shouldn't match linebreaks possibly also need to be applied
> to the new RE engine).

The idea was to have a "whitelist" for the pattern.  If it passes that
then use the new RE code, otherwise fall back to the old stuff.
Gradually the whitelist would get longer.

Main thing still to do is testing.  We can't really expect users to just
run in bugs all the time.  It's complicated stuff.  Don't want the same
long time bug fighting as we had with the conceal mode.
For testing we would have a way to force the old or new RE engine,
and compare the results.

--
Why is "abbreviation" such a long word?

  /// Bram Moolenaar -- Bram@... -- 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+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Hey,

I am currently trying to improve the clang_complete plugin to have a global
notion of symbols.
One thing I would like to do is highlighting all occurences of the symbol under
the cursor.

I have the position and extend of all occurences. All I need to do is
highlighting these ranges.

How can I do this with vimscript (or python)?

Thanks!
Nathan

--
--
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+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

On Wed, Feb 13, 2013 at 10:50:28AM -0800, Nathan Hüsken wrote:
> Hey,
>
> I am currently trying to improve the clang_complete plugin to have a global
notion of symbols.
> One thing I would like to do is highlighting all occurences of the symbol
under the cursor.

If you're ok with the highlighting being window-local, I briefly toyed
with something like the following to mimic Eclipse's automatic
"highlight the word under the cursor" functionality.

   hi link AutomaticWord IncSearch
   function! TransientMatch(word)
     if exists('w:matchid')
       call matchdelete(w:matchid)
     endif
     let w:matchid = matchadd('AutomaticWord', '\<'.a:word.'\>', -1)
   endfunction
   augroup TransientMatch
     autocmd!
     autocmd CursorHold * call TransientMatch(expand('<cword>'))
   augroup END

Since this is triggered by CursorHold, you'd also want to lower
'updatetime' to a value that's not too slow.

Cheers,
--
James
GPG Key: 4096R/331BA3DB 2011-12-05 James McCoy <jamessan@...>

Bram,

The other day in #vim, someone was wondering why :s/SOMEWORD/\L\u&/
was resulting in sOMEWORD instead of title-case (Someword).

That seemed like a reasonable expectation and is how PCRE would treat
that substitution, so I came up with the attached patch to make Vim work
like that.  Also included are tests.

Cheers,
--
James
GPG Key: 4096R/331BA3DB 2011-12-05 James McCoy <jamessan@...>

On Wed, Feb 13, 2013 at 09:53:59PM -0500, James McCoy wrote:
> The other day in #vim, someone was wondering why :s/SOMEWORD/\L\u&/
> was resulting in sOMEWORD instead of title-case (Someword).

Oops, messed up my example.  :s/sOmeWord/\L\u&/ is better as the
expected outcome is "Someword" but only the \u takes effect so it's
actually "SOmeWord".

Cheers,
--
James
GPG Key: 4096R/331BA3DB 2011-12-05 James McCoy <jamessan@...>

If I correctly understood OP, current symbol != all words that are the same as
the one under cursor (i.e. local variable in one function is different symbol
from the local variable in another function, even if it has the same name). Thus
what is needed, given positions in a list of three-tuples of (lnum, col, len) is
constructing the regex like this:

     let regex='\v'.join(map(copy(positions),
'"%".v:val[0]."l%".v:val[1]."c.{".v:val[3]."}"'), '|')
. This assumes length is given it terms of characters, but column is byte
offset. Then this regex may be used in your function.

--
--
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+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

On Wednesday, February 13, 2013 4:57:15 PM UTC-6, Christian Brabandt wrote:
>
>
> Ok. But my idea is to have it included and only use it, if users
>
> explicitly set the 'experimental' option. So by default users would
>
> still use the old, working RE, but users that like to test and
>
> contribute can enable the new RE engine so that the new RE engine can be
>
> tested more easily.
>

I like this idea. I'd be happy to turn the option on and run with it as long as
I had the ability to revert to the old mode when needed if I run into a problem.
Then we also don't need to worry about a whitelist. Just keep it as an
"experimental" feature and people know to turn it off (and submit a bug report!)
if they run into situations where it doesn't work.

--
--
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+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Thanks (once again) for the patch!

Here are a few ideas:

     It would be nice to end paragraph line before the match for some
     patterns.  For example if you have

	 lorem ipsum lorem ipsum
	 lorem ipsum lorem ipsum
	 lorem ipsum lorem ipsum
	 \section{New Aproach}

     adding ¶='/\\section' and using d} will delete one line to
     much.  But this should be only for some patters hence this will
     require that ¶ is a list of patterns with some kind of
     modifiers, or one would have to make support for multiline patterns.
     Using something like ¶='/\n\s*\\section' is not working with the
     patch.



     With the patch and ¶='/^\zs\s*$' and the following text:

     lorem ipsum lorem ipsum
     lorem ipsum lorem ipsum


     lorem ipsum lorem ipsum
     lorem ipsum lorem ipsum


     }, and { stop on the first met empty line, i.e. } will stop on the
     top one, and { on the bottom one.  But I think this is not a big
     deal, though it is inconsistent with the nroff setting.  Again
     recognising multiple line patterns would help.  Something like:

     let ¶='/^\_s*$'

A solution: after matching the line against the ¶ pattern and moving
the cursor to that line use something like:
     :call search(¶, 'bc')


Z wyrazami szacunku :)
Marcin

--
--
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+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

On 13-Feb-13 20:19:55 +0100, Christian Brabandt wrote:

> Hi clime!
>
> On Mi, 13 Feb 2013, clime wrote:
>
>> With respect to this thread on so:
>>
http://stackoverflow.com/questions/14842987/vim-wildmenu-move-into-subdirectory-\
with-a-different-key-than-down
>>
>> It seems like command-line mappings aren't interpreted in wildmenu
>> mode, and instead exit it and insert the 'wildchar' literally.
>>
>> Would it be possible to interpret these mappings and potentially add
>> wildmenuvisible() - a function analog to the pumvisible()?
>
> Looks like a bug to me. However, I think, if you set wildcharm=<Tab> you
> can make your mapping work:
>
> :set wildcharm=<Tab>
> :cnoremap <C-j> <DOWN><Tab>
>
> I agree, this is not really useful, without a wildmodevisual() function,
> so you could do:
> :cnoremap <expr> <C-j> wildmodevisible() ? "\<Down>\<Tab>" : "\<c-j>"
>
> Attached patch enables this. Probably needs a test, but not sure how.

Thanks for the patch, Christian. This is certainly useful, also for other
command-line mappings.

I didn't know about 'wildcharm'; it looks to me that making it equal to the
'wildchar' value makes sense (and not setting it to an unused key as suggested
by its help), so that one is able to record and replay stuff like :split
~/<Tab><Tab>foo.txt in a macro. I wonder why it's empty by default.

-- regards, ingo

--
--
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+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Ben Fritz wrote:

> On Wednesday, February 13, 2013 4:57:15 PM UTC-6, Christian Brabandt wrote:
> >
> >
> > Ok. But my idea is to have it included and only use it, if users
> >
> > explicitly set the 'experimental' option. So by default users would
> >
> > still use the old, working RE, but users that like to test and
> >
> > contribute can enable the new RE engine so that the new RE engine can be
> >
> > tested more easily.
> >
>
> I like this idea. I'd be happy to turn the option on and run with it
> as long as I had the ability to revert to the old mode when needed if
> I run into a problem. Then we also don't need to worry about a
> whitelist. Just keep it as an "experimental" feature and people know
> to turn it off (and submit a bug report!) if they run into situations
> where it doesn't work.

Question is, if you run into a problem, how do you know you have to turn
off that option?  If syntax highlighting is off it might be obvious, but
when some plugins behave badly you might not have a clue.

--
    [The rest of the ARMY stand around looking at a loss.]
INSPECTOR END OF FILM: (picks up megaphone) All right!  Clear off!  Go on!
                  "Monty Python and the Holy Grail" PYTHON (MONTY) PICTURES LTD

  /// Bram Moolenaar -- Bram@... -- 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+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Christian Brabandt wrote:

> Hi Bram!
>
> On Mi, 06 Feb 2013, Bram Moolenaar wrote:
>
> >
> > Patch 7.3.799
> > Problem:    The color column is not correct when entering a buffer. (Ben
> > 	    Fritz)
> > Solution:   Call check_colorcolumn() if 'textwidth' changed. (Christian
> > 	    Brabandt)
> > Files:     src/buffer.c
>
> This segfaults for me at Test 87 in test49.vim This patch fixes it:
>
> diff --git a/src/buffer.c b/src/buffer.c
> --- a/src/buffer.c
> +++ b/src/buffer.c
> @@ -1442,7 +1442,7 @@
>      buf_T      *buf;
>  {
>  #ifdef FEAT_SYN_HL
> -    long old_tw = curbuf->b_p_tw;
> +    long old_tw = buf_valid(curbuf) ? curbuf->b_p_tw : 0;
>  #endif
>
>      /* Copy buffer and window local option values.  Not for a help buffer. */

Any idea why it crashes for you and not for me?
Perhaps should run under valgrind.

--
ARTHUR: CHARGE!
    [The mighty ARMY charges.  Thundering noise of feet.  Clatter of coconuts.
    Shouts etc.   Suddenly there is a wail of a siren and a couple of police
    cars roar round in front of the charging ARMY and the POLICE leap out and
    stop them.  TWO POLICEMAN and the HISTORIAN'S WIFE.  Black Marias skid up
    behind them.]
HISTORIAN'S WIFE: They're the ones, I'm sure.
                  "Monty Python and the Holy Grail" PYTHON (MONTY) PICTURES LTD

  /// Bram Moolenaar -- Bram@... -- 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+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Am Donnerstag, 14. Februar 2013 04:46:04 UTC+1 schrieb ZyX:
> If I correctly understood OP, current symbol != all words that are the same as
the one under cursor (i.e. local variable in one function is different symbol
from the local variable in another function, even if it has the same name).

That is correct.

> Thus what is needed, given positions in a list of three-tuples of (lnum, col,
len) is constructing the regex like this:
>
>     let regex='\v'.join(map(copy(positions),
'"%".v:val[0]."l%".v:val[1]."c.{".v:val[3]."}"'), '|')
> . This assumes length is given it terms of characters, but column is byte
offset. Then this regex may be used in your function.

Ok, I have (line,col) but I convert it to byte offset using line2byte(line) +
col.

Unfortantly something does not work. The regex I get is:

\v%1l%164c.{5}|%1l%234c.{5}|%1l%332c.{5}

now I put this into:

let w:matchid = matchadd('AutomaticWord',regex, -1)

But the positions are not highlighted.

Thanks!
Nathan

--
--
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+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Hi Bram!

On Do, 14 Feb 2013, Bram Moolenaar wrote:

> Question is, if you run into a problem, how do you know you have to turn
> off that option?  If syntax highlighting is off it might be obvious, but
> when some plugins behave badly you might not have a clue.

Anybody that uses such an option should be aware, that this can have
consequences. So I would expect the first thing to do when one notices
something strange to turn that option off.

regards,
Christian
--
Ich gehe jetzt in den Birkenwald,
denn meine Pillen wirken bald.

--
--
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+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Hi Bram!

On Do, 14 Feb 2013, Bram Moolenaar wrote:

> Any idea why it crashes for you and not for me?
> Perhaps should run under valgrind.

No and it doesn't segfault, if I only let test87 run. Problem is,
close_buffer() might close curbuf and curbuf can get freed(). Of course
then you can't access curbuf->b_p_tw in enter_buffer() anymore.

Valgrind confirms this:

==12456== Memcheck, a memory error detector
==12456== Copyright (C) 2002-2011, and GNU GPL'd, by Julian Seward et al.
==12456== Using Valgrind-3.7.0 and LibVEX; rerun with -h for copyright info
==12456== Command: ../vim -u unix.vim -U NONE --noplugin -s dotest.in test49.in
==12456== Parent PID: 12450
==12456==
==12456== Invalid read of size 8
==12456==    at 0x40FB67: enter_buffer (buffer.c:1445)
==12456==    by 0x40FB51: set_curbuf (buffer.c:1433)
==12456==    by 0x40F8FC: do_buffer (buffer.c:1330)
==12456==    by 0x40ED18: do_bufdel (buffer.c:872)
==12456==    by 0x472768: ex_bunload (ex_docmd.c:5062)
==12456==    by 0x46DE03: do_one_cmd (ex_docmd.c:2681)
==12456==    by 0x46B3EF: do_cmdline (ex_docmd.c:1122)
==12456==    by 0x454E8C: call_user_func (eval.c:22604)
==12456==    by 0x43DB87: call_func (eval.c:8484)
==12456==    by 0x43D73C: get_func_tv (eval.c:8326)
==12456==    by 0x43905E: eval7 (eval.c:5160)
==12456==    by 0x4388F7: eval6 (eval.c:4812)
==12456==    by 0x438447: eval5 (eval.c:4628)
==12456==    by 0x43774E: eval4 (eval.c:4321)
==12456==    by 0x437592: eval3 (eval.c:4233)
==12456==  Address 0xc68b550 is 5,360 bytes inside a block of size 7,064 free'd
==12456==    at 0x4C2A739: free (in
/usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==12456==    by 0x4DD924: vim_free (misc2.c:1744)
==12456==    by 0x40E983: free_buffer (buffer.c:665)
==12456==    by 0x40E5F0: close_buffer (buffer.c:499)
==12456==    by 0x40FAE8: set_curbuf (buffer.c:1409)
==12456==    by 0x40F8FC: do_buffer (buffer.c:1330)
==12456==    by 0x40ED18: do_bufdel (buffer.c:872)
==12456==    by 0x472768: ex_bunload (ex_docmd.c:5062)
==12456==    by 0x46DE03: do_one_cmd (ex_docmd.c:2681)
==12456==    by 0x46B3EF: do_cmdline (ex_docmd.c:1122)
==12456==    by 0x454E8C: call_user_func (eval.c:22604)
==12456==    by 0x43DB87: call_func (eval.c:8484)
==12456==    by 0x43D73C: get_func_tv (eval.c:8326)
==12456==    by 0x43905E: eval7 (eval.c:5160)
==12456==    by 0x4388F7: eval6 (eval.c:4812)
==12456==

regards,
Christian
--
Der Fortschritt geschieht heute so schnell, daß, während jemand eine
Sache für gänzlich undurchführbar erklärt, er von einem anderen
unterbrochen wird, der sie schon realisiert hat.
		 -- Albert Einstein

--
--
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+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

On Thu, Feb 14, 2013 at 12:54 PM, Christian Brabandt wrote:
>> Question is, if you run into a problem, how do you know you have to turn
>> off that option?  If syntax highlighting is off it might be obvious, but
>> when some plugins behave badly you might not have a clue.
>
> Anybody that uses such an option should be aware, that this can have
> consequences. So I would expect the first thing to do when one notices
> something strange to turn that option off.

I think as well that such an option could be a good idea, not just for
RE but for any bigger changes that strives to be eventually included
into the main development line. I'm sure many people on this list
would go for experimental just to help testing new features. I
personally don't have enough time to help in Vim development, but I'm
always happy to run into various issues and report them.
"experimental" could be a compilation option as well to avoid having
both "old" and "new" code compiled into the program. It should be
reported with bug reports like any other compilation option (just as
in "happens with big features but not with tiny").

--
--
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+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Am Donnerstag, 14. Februar 2013 11:13:36 UTC+1 schrieb Nathan Hüsken:
> Am Donnerstag, 14. Februar 2013 04:46:04 UTC+1 schrieb ZyX:
> > If I correctly understood OP, current symbol != all words that are the same
as the one under cursor (i.e. local variable in one function is different symbol
from the local variable in another function, even if it has the same name).
>
> That is correct.
>
> > Thus what is needed, given positions in a list of three-tuples of (lnum,
col, len) is constructing the regex like this:
> >
> >     let regex='\v'.join(map(copy(positions),
'"%".v:val[0]."l%".v:val[1]."c.{".v:val[3]."}"'), '|')
> > . This assumes length is given it terms of characters, but column is byte
offset. Then this regex may be used in your function.
>
> Ok, I have (line,col) but I convert it to byte offset using line2byte(line) +
col.
>
> Unfortantly something does not work. The regex I get is:
>
> \v%1l%164c.{5}|%1l%234c.{5}|%1l%332c.{5}
>
> now I put this into:
>
> let w:matchid = matchadd('AutomaticWord',regex, -1)
>
> But the positions are not highlighted.
>
> Thanks!
> Nathan

Ok, you got me confused there. I thought col was supposed to be the byte offset
in the buffer.
Got it corrected and it works like a charm. Thanks!

--
--
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+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Christian Brabandt wrote:

> Hi Bram!
>
> On Do, 14 Feb 2013, Bram Moolenaar wrote:
>
> > Any idea why it crashes for you and not for me?
> > Perhaps should run under valgrind.
>
> No and it doesn't segfault, if I only let test87 run. Problem is,
> close_buffer() might close curbuf and curbuf can get freed(). Of course
> then you can't access curbuf->b_p_tw in enter_buffer() anymore.
>
> Valgrind confirms this:
>
> ==12456== Memcheck, a memory error detector
> ==12456== Copyright (C) 2002-2011, and GNU GPL'd, by Julian Seward et al.
> ==12456== Using Valgrind-3.7.0 and LibVEX; rerun with -h for copyright info
> ==12456== Command: ../vim -u unix.vim -U NONE --noplugin -s dotest.in
test49.in
> ==12456== Parent PID: 12450
> ==12456==
> ==12456== Invalid read of size 8
> ==12456==    at 0x40FB67: enter_buffer (buffer.c:1445)
> ==12456==    by 0x40FB51: set_curbuf (buffer.c:1433)
> ==12456==    by 0x40F8FC: do_buffer (buffer.c:1330)
> ==12456==    by 0x40ED18: do_bufdel (buffer.c:872)
> ==12456==    by 0x472768: ex_bunload (ex_docmd.c:5062)
> ==12456==    by 0x46DE03: do_one_cmd (ex_docmd.c:2681)
> ==12456==    by 0x46B3EF: do_cmdline (ex_docmd.c:1122)
> ==12456==    by 0x454E8C: call_user_func (eval.c:22604)
> ==12456==    by 0x43DB87: call_func (eval.c:8484)
> ==12456==    by 0x43D73C: get_func_tv (eval.c:8326)
> ==12456==    by 0x43905E: eval7 (eval.c:5160)
> ==12456==    by 0x4388F7: eval6 (eval.c:4812)
> ==12456==    by 0x438447: eval5 (eval.c:4628)
> ==12456==    by 0x43774E: eval4 (eval.c:4321)
> ==12456==    by 0x437592: eval3 (eval.c:4233)
> ==12456==  Address 0xc68b550 is 5,360 bytes inside a block of size 7,064
free'd
> ==12456==    at 0x4C2A739: free (in
/usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
> ==12456==    by 0x4DD924: vim_free (misc2.c:1744)
> ==12456==    by 0x40E983: free_buffer (buffer.c:665)
> ==12456==    by 0x40E5F0: close_buffer (buffer.c:499)
> ==12456==    by 0x40FAE8: set_curbuf (buffer.c:1409)
> ==12456==    by 0x40F8FC: do_buffer (buffer.c:1330)
> ==12456==    by 0x40ED18: do_bufdel (buffer.c:872)
> ==12456==    by 0x472768: ex_bunload (ex_docmd.c:5062)
> ==12456==    by 0x46DE03: do_one_cmd (ex_docmd.c:2681)
> ==12456==    by 0x46B3EF: do_cmdline (ex_docmd.c:1122)
> ==12456==    by 0x454E8C: call_user_func (eval.c:22604)
> ==12456==    by 0x43DB87: call_func (eval.c:8484)
> ==12456==    by 0x43D73C: get_func_tv (eval.c:8326)
> ==12456==    by 0x43905E: eval7 (eval.c:5160)
> ==12456==    by 0x4388F7: eval6 (eval.c:4812)
> ==12456==

I think we should actually move the code to get the old value of
'textwidth' to the caller of enter_buffer().  It might be that there are
only one or two places where this is relevant.  Perhaps it can be
combined with some other option value that might have changed and
require an action after entering another buffer?

--
"I love deadlines.  I especially like the whooshing sound they
make as they go flying by."
                          -- Douglas Adams

  /// Bram Moolenaar -- Bram@... -- 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+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

On Thursday, February 14, 2013 6:54:39 AM UTC-6, François Ingelrest wrote:
>
> I think as well that such an option could be a good idea, not just for
>
> RE but for any bigger changes that strives to be eventually included
>
> into the main development line. I'm sure many people on this list
>
> would go for experimental just to help testing new features. I
>
> personally don't have enough time to help in Vim development, but I'm
>
> always happy to run into various issues and report them.
>
> "experimental" could be a compilation option as well to avoid having
>
> both "old" and "new" code compiled into the program. It should be
>
> reported with bug reports like any other compilation option (just as
>
> in "happens with big features but not with tiny").

With a runtime configurable option I'd be able to test at work where I actually
exercise Vim more rigorously just because I use it for more stuff. I doubt I'd
go to the trouble of installing two different versions of Vim at work, and I
know I don't compile myself at work, at least not for Windows. I'm toying with
the idea of compiling a version for running on our Solaris servers, because the
one provided by IT is stuck at version 6.x.

--
--
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+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Patch 7.3.817
Problem:    Test 89 fails with tiny and small features.
Solution:   Add sourcing small.vim.
Files:     src/testdir/test89.in


*** ../vim-7.3.816/src/testdir/test89.in 2013-02-13 15:44:22.000000000 +0100
--- src/testdir/test89.in 2013-02-14 20:06:53.000000000 +0100
***************
*** 1,6 ****
--- 1,7 ----
   Some tests for setting 'number' and 'relativenumber'

   STARTTEST
+ :so small.vim
   :set hidden nocp nu rnu
   :redir @a | set nu? rnu? | redir END
   :e! xx
*** ../vim-7.3.816/src/version.c 2013-02-13 17:34:59.000000000 +0100
--- src/version.c 2013-02-14 20:10:00.000000000 +0100
***************
*** 727,728 ****
--- 727,730 ----
   {   /* Add new patch number below this line */
+ /**/
+     817,
   /**/

--
INSPECTOR END OF FILM: Move along.  There's nothing to see!  Keep moving!
    [Suddenly he notices the cameras.]
INSPECTOR END OF FILM: (to Camera) All right, put that away sonny.
    [He walks over to it and puts his hand over the lens.]
                  "Monty Python and the Holy Grail" PYTHON (MONTY) PICTURES LTD

  /// Bram Moolenaar -- Bram@... -- 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+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Hi,

The blowfish encryption mode is vulnerable (not to revelation of the
plaintext), but the encryption is not checked for integrity or
authenticity. This means that someone might corrupt the encrypted file
(hexedit or similar), and vim will decrypt it without notice of error or
warning.

This attack allows someone to modfiy encrypted files so that the owner
doesn't notice. With sufficient tries or skill it might be possible to
change a file's values in a predictable way at a certain offset.

The solution is an authenticated encryption mode. The common way to do
it is 'Encrypt-then-MAC' where a message authentication code is formed
from the ciphertext and the key. This code when matching will prove that
the document is unchanged and was produced by someone with access to the
key. This code will detect the previous attack case, and additionally it
allows vim to detect that the wrong password was entered. Security
practise says that Vim must fail with an error if the MAC does not match.

HTH,
ulrik

--
--
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+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Patch 7.3.818
Problem:    When test 40 fails because of a bad build it may leave files
	     behind that cause it to fail later.
Solution:   Let the file names start with "X".
Files:     src/testdir/test40.in


*** ../vim-7.3.817/src/testdir/test40.in 2010-08-15 21:57:29.000000000 +0200
--- src/testdir/test40.in 2013-02-14 20:56:45.000000000 +0100
***************
*** 3,20 ****
   STARTTEST
   :so small.vim
   :/^start/,$w! Xxx  " write lines below to Xxx
! :au BufReadCmd testA 0r Xxx|$del
! :e testA 	 " will read text of Xxd instead
! :au BufWriteCmd testA call append(line("$"), "write")
   :w 		 " will append a line to the file
! :r testA 	 " should not read anything
   : 		 " now we have:
   : 		 " 1 start of Xxx
   : 		 " 2  test40
   : 		 " 3 end of Xxx
   : 		 " 4 write
! :au FileReadCmd testB '[r Xxx
! :2r testB 	 " will read Xxx below line 2 instead
   : 		 " 1 start of Xxx
   : 		 " 2  test40
   : 		 " 3 start of Xxx
--- 3,20 ----
   STARTTEST
   :so small.vim
   :/^start/,$w! Xxx  " write lines below to Xxx
! :au BufReadCmd XtestA 0r Xxx|$del
! :e XtestA 	 " will read text of Xxd instead
! :au BufWriteCmd XtestA call append(line("$"), "write")
   :w 		 " will append a line to the file
! :r XtestA 	 " should not read anything
   : 		 " now we have:
   : 		 " 1 start of Xxx
   : 		 " 2  test40
   : 		 " 3 end of Xxx
   : 		 " 4 write
! :au FileReadCmd XtestB '[r Xxx
! :2r XtestB 	 " will read Xxx below line 2 instead
   : 		 " 1 start of Xxx
   : 		 " 2  test40
   : 		 " 3 start of Xxx
***************
*** 22,31 ****
   : 		 " 5 end of Xxx
   : 		 " 6 end of Xxx
   : 		 " 7 write
! :au FileWriteCmd testC '[,']copy $
   4GA1
! :4,5w testC 	 " will copy lines 4 and 5 to the end
! :r testC 	 " should not read anything
   : 		 " 1 start of Xxx
   : 		 " 2  test40
   : 		 " 3 start of Xxx
--- 22,31 ----
   : 		 " 5 end of Xxx
   : 		 " 6 end of Xxx
   : 		 " 7 write
! :au FileWriteCmd XtestC '[,']copy $
   4GA1
! :4,5w XtestC 	 " will copy lines 4 and 5 to the end
! :r XtestC 	 " should not read anything
   : 		 " 1 start of Xxx
   : 		 " 2  test40
   : 		 " 3 start of Xxx
***************
*** 35,48 ****
   : 		 " 7 write
   : 		 " 8  test401
   : 		 " 9 end of Xxx
! :au FILEAppendCmd testD '[,']w! test.out
! :w >>testD 	 " will write all lines to test.out
! :$r testD 	 " should not read anything
   :$w >>test.out 	 " append "end of Xxx" to test.out
! :au BufReadCmd testE 0r test.out|$del
! :sp testE 	 " split window with test.out
   5Goasdf   :"
! :au BufWriteCmd testE w! test.out
   :wall 		 " will write other window to test.out
   : 		 " 1 start of Xxx
   : 		 " 2  test40
--- 35,48 ----
   : 		 " 7 write
   : 		 " 8  test401
   : 		 " 9 end of Xxx
! :au FILEAppendCmd XtestD '[,']w! test.out
! :w >>XtestD 	 " will write all lines to test.out
! :$r XtestD 	 " should not read anything
   :$w >>test.out 	 " append "end of Xxx" to test.out
! :au BufReadCmd XtestE 0r test.out|$del
! :sp XtestE 	 " split window with test.out
   5Goasdf   :"
! :au BufWriteCmd XtestE w! test.out
   :wall 		 " will write other window to test.out
   : 		 " 1 start of Xxx
   : 		 " 2  test40
*** ../vim-7.3.817/src/version.c 2013-02-14 20:10:28.000000000 +0100
--- src/version.c 2013-02-14 20:57:44.000000000 +0100
***************
*** 727,728 ****
--- 727,730 ----
   {   /* Add new patch number below this line */
+ /**/
+     818,
   /**/

--
JOHN CLEESE PLAYED: SECOND SOLDIER WITH A KEEN INTEREST IN BIRDS, LARGE MAN
                     WITH DEAD BODY, BLACK KNIGHT, MR NEWT (A VILLAGE
                     BLACKSMITH INTERESTED IN BURNING WITCHES), A QUITE
                     EXTRAORDINARILY RUDE FRENCHMAN, TIM THE WIZARD, SIR
                     LAUNCELOT
                  "Monty Python and the Holy Grail" PYTHON (MONTY) PICTURES LTD

  /// Bram Moolenaar -- Bram@... -- 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+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

James McCoy wrote:

> The other day in #vim, someone was wondering why :s/SOMEWORD/\L\u&/
> was resulting in sOMEWORD instead of title-case (Someword).
>
> That seemed like a reasonable expectation and is how PCRE would treat
> that substitution, so I came up with the attached patch to make Vim work
> like that.  Also included are tests.

Thanks, sounds like a good solution.  Implementation is fairly simple.

Can you also write an update for the documentation?


--
MICHAEL PALIN PLAYED: 1ST SOLDIER WITH A KEEN INTEREST IN BIRDS, DENNIS, MR
                       DUCK (A VILLAGE CARPENTER WHO IS ALMOST KEENER THAN
                       ANYONE ELSE TO BURN WITCHES), THREE-HEADED KNIGHT, SIR
                       GALAHAD, KING OF SWAMP CASTLE, BROTHER MAYNARD'S ROOMATE
                  "Monty Python and the Holy Grail" PYTHON (MONTY) PICTURES LTD

  /// Bram Moolenaar -- Bram@... -- 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+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Christian Brabandt wrote:

> Hi Marcin!
>
> On So, 10 Feb 2013, Marcin Szamotulski wrote:
>
> > On 12:19 Sat 09 Feb     , Zyad wrote:
> > > Hi,
> > >
> > > I'm finding the auto-format option very attractive (setl fo+=a), but I'm
having trouble getting it to work nicely when editing LaTeX documents.
> > >
> > > More specifically, I'd like to make it aware of LaTeX keywords so that,
for example, when writing the following,
> > >
> > > This is a paragraph that is properly
> > > formatted to have a textwidth of 40.
> > > 'auto-format' helps maintain it in a
> > > formatted form, even if I edit parts of
> > > it.
> > > \begin{equation}
> > > z^2 = x^2 + y^2
> > > \end{equation
> > >
> > > as soon as I enter '\', the cursor moves to the previous line. Is it
possible to have auto-format understand that a keyword like '\begin{' should not
be considered part of the paragraph before it? I'm aware of formatoptions' 'w'
flag, but it is inconvenient for me since the document is usually edited by
others.
> > >
> > > Thanks,
> > > Zyad
> >
> > The problem is that vim the 'paragraphs' setting accepts only nroff
> > macros.  ATP (http://atp-vim.sf.net) defined a map gW which detects
> > paragraphs and formats them - it is still not what you (and me) wanted
> > but it a bit better.
>
> Personally, I have never used nroff macros and I think the 'paragraphs'
> and 'sections' setttings are pretty useless, if you can't use regular
> expressions.
>
> Does anything speak against having a special casing of the 'paragraphs'
> and 'sections' option to use a regular expression pattern to test
> against if it starts with a '/'?
>
> Attached is a toy patch.

It's an idea.  Several users have asked for a more flexible way to
define paragraph boundaries.

I think the help needs some more work.  How is the regular expression
used?  What if a two-character part before it already matched?
An example would be helpful.


--
A disclaimer for the disclaimer:
"and before I get a huge amount of complaints , I have no control over the
disclaimer at the end of this mail :-)" (Timothy Aldrich)

  /// Bram Moolenaar -- Bram@... -- 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+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Patch 7.3.819
Problem:    Compiling without +eval and with Python isn't working.
Solution:   Add the eval feature when building with Python.
Files:     src/if_py_both.h, src/feature.h, src/eval.c, src/ex_docmd.c,
	     src/normal.c, src/ex_docmd.c, src/gui_gtk_x11.c


*** ../vim-7.3.818/src/if_py_both.h 2012-12-05 16:30:03.000000000 +0100
--- src/if_py_both.h 2013-02-14 19:22:59.000000000 +0100
***************
*** 310,316 ****
       return result;
   }

- #ifdef FEAT_EVAL
   /*
    * Function to translate a typval_T into a PyObject; this will recursively
    * translate lists/dictionaries into their Python equivalents.
--- 310,315 ----
***************
*** 425,436 ****

       return result;
   }
- #endif

       static PyObject *
   VimEval(PyObject *self UNUSED, PyObject *args UNUSED)
   {
- #ifdef FEAT_EVAL
       char *expr;
       typval_T *our_tv;
       PyObject *result;
--- 424,433 ----
***************
*** 466,475 ****
       Py_END_ALLOW_THREADS

       return result;
- #else
-     PyErr_SetVim(_("expressions disabled at compile time"));
-     return NULL;
- #endif
   }

   static PyObject *ConvertToPyObject(typval_T *);
--- 463,468 ----
***************
*** 477,483 ****
       static PyObject *
   VimEvalPy(PyObject *self UNUSED, PyObject *args UNUSED)
   {
- #ifdef FEAT_EVAL
       char *expr;
       typval_T *our_tv;
       PyObject *result;
--- 470,475 ----
***************
*** 506,515 ****
       Py_END_ALLOW_THREADS

       return result;
- #else
-     PyErr_SetVim(_("expressions disabled at compile time"));
-     return NULL;
- #endif
   }

       static PyObject *
--- 498,503 ----
***************
*** 946,952 ****
   }

       static PyObject *
! DictionaryListKeys(PyObject *self)
   {
       dict_T *dict = ((DictionaryObject *)(self))->dict;
       long_u todo = dict->dv_hashtab.ht_used;
--- 934,940 ----
   }

       static PyObject *
! DictionaryListKeys(PyObject *self UNUSED)
   {
       dict_T *dict = ((DictionaryObject *)(self))->dict;
       long_u todo = dict->dv_hashtab.ht_used;
***************
*** 2549,2555 ****
       return 0;
   }

- #ifdef FEAT_EVAL
   typedef int (*pytotvfunc)(PyObject *, typval_T *, PyObject *);

       static int
--- 2537,2542 ----
***************
*** 2781,2784 ****
  	     return NULL;
       }
   }
- #endif
--- 2768,2770 ----
*** ../vim-7.3.818/src/feature.h 2013-01-23 13:40:54.000000000 +0100
--- src/feature.h 2013-02-14 19:25:33.000000000 +0100
***************
*** 392,397 ****
--- 392,404 ----
   #endif

   /*
+  * +python and +python3 require FEAT_EVAL.
+  */
+ #if !defined(FEAT_EVAL) && (defined(FEAT_PYTHON3) || defined(FEAT_PYTHON))
+ # define FEAT_EVAL
+ #endif
+
+ /*
    * +profile  Profiling for functions and scripts.
    */
   #if defined(FEAT_HUGE) \
*** ../vim-7.3.818/src/eval.c 2013-02-13 17:34:59.000000000 +0100
--- src/eval.c 2013-02-14 19:38:09.000000000 +0100
***************
*** 917,923 ****
--- 917,925 ----
       hash_clear(&compat_hashtab);

       free_scriptnames();
+ # if defined(FEAT_CMDL_COMPL)
       free_locales();
+ # endif

       /* global variables */
       vars_clear(&globvarht);
***************
*** 1561,1568 ****
   }


- #if (defined(FEAT_USR_CMDS) && defined(FEAT_CMDL_COMPL)) \
-  || defined(FEAT_COMPL_FUNC) || defined(PROTO)
   /*
    * Call some vimL function and return the result in "*rettv".
    * Uses argv[argc] for the function arguments.  Only Number and String
--- 1563,1568 ----
***************
*** 1640,1692 ****
       return ret;
   }

- # if (defined(FEAT_USR_CMDS) && defined(FEAT_CMDL_COMPL)) || defined(PROTO)
   /*
!  * Call vimL function "func" and return the result as a string.
!  * Returns NULL when calling the function fails.
    * Uses argv[argc] for the function arguments.
    */
!     void *
! call_func_retstr(func, argc, argv, safe)
       char_u      *func;
       int  argc;
       char_u      **argv;
       int  safe;  /* use the sandbox */
   {
       typval_T rettv;
!     char_u *retval;

       /* All arguments are passed as strings, no conversion to number. */
       if (call_vim_function(func, argc, argv, safe, TRUE, &rettv) == FAIL)
!  return NULL;

!     retval = vim_strsave(get_tv_string(&rettv));
       clear_tv(&rettv);
       return retval;
   }
- # endif

! # if defined(FEAT_COMPL_FUNC) || defined(PROTO)
   /*
!  * Call vimL function "func" and return the result as a number.
!  * Returns -1 when calling the function fails.
    * Uses argv[argc] for the function arguments.
    */
!     long
! call_func_retnr(func, argc, argv, safe)
       char_u      *func;
       int  argc;
       char_u      **argv;
       int  safe;  /* use the sandbox */
   {
       typval_T rettv;
!     long retval;

       /* All arguments are passed as strings, no conversion to number. */
       if (call_vim_function(func, argc, argv, safe, TRUE, &rettv) == FAIL)
!  return -1;

!     retval = get_tv_number_chk(&rettv, NULL);
       clear_tv(&rettv);
       return retval;
   }
--- 1640,1693 ----
       return ret;
   }

   /*
!  * Call vimL function "func" and return the result as a number.
!  * Returns -1 when calling the function fails.
    * Uses argv[argc] for the function arguments.
    */
!     long
! call_func_retnr(func, argc, argv, safe)
       char_u      *func;
       int  argc;
       char_u      **argv;
       int  safe;  /* use the sandbox */
   {
       typval_T rettv;
!     long retval;

       /* All arguments are passed as strings, no conversion to number. */
       if (call_vim_function(func, argc, argv, safe, TRUE, &rettv) == FAIL)
!  return -1;

!     retval = get_tv_number_chk(&rettv, NULL);
       clear_tv(&rettv);
       return retval;
   }

! #if (defined(FEAT_USR_CMDS) && defined(FEAT_CMDL_COMPL)) \
!  || defined(FEAT_COMPL_FUNC) || defined(PROTO)
!
! # if (defined(FEAT_USR_CMDS) && defined(FEAT_CMDL_COMPL)) || defined(PROTO)
   /*
!  * Call vimL function "func" and return the result as a string.
!  * Returns NULL when calling the function fails.
    * Uses argv[argc] for the function arguments.
    */
!     void *
! call_func_retstr(func, argc, argv, safe)
       char_u      *func;
       int  argc;
       char_u      **argv;
       int  safe;  /* use the sandbox */
   {
       typval_T rettv;
!     char_u *retval;

       /* All arguments are passed as strings, no conversion to number. */
       if (call_vim_function(func, argc, argv, safe, TRUE, &rettv) == FAIL)
!  return NULL;

!     retval = vim_strsave(get_tv_string(&rettv));
       clear_tv(&rettv);
       return retval;
   }
***************
*** 1720,1726 ****
   }
   #endif

-
   /*
    * Save the current function call pointer, and set it to NULL.
    * Used when executing autocommands and for ":source".
--- 1721,1726 ----
***************
*** 9330,9336 ****
    */
       static void
   f_cindent(argvars, rettv)
!     typval_T *argvars;
       typval_T *rettv;
   {
   #ifdef FEAT_CINDENT
--- 9330,9336 ----
    */
       static void
   f_cindent(argvars, rettv)
!     typval_T *argvars UNUSED;
       typval_T *rettv;
   {
   #ifdef FEAT_CINDENT
***************
*** 10379,10387 ****

       static void
   findfilendir(argvars, rettv, find_what)
!     typval_T *argvars;
       typval_T *rettv;
!     int  find_what;
   {
   #ifdef FEAT_SEARCHPATH
       char_u *fname;
--- 10379,10387 ----

       static void
   findfilendir(argvars, rettv, find_what)
!     typval_T *argvars UNUSED;
       typval_T *rettv;
!     int  find_what UNUSED;
   {
   #ifdef FEAT_SEARCHPATH
       char_u *fname;
***************
*** 10751,10759 ****
    */
       static void
   foldclosed_both(argvars, rettv, end)
!     typval_T *argvars;
       typval_T *rettv;
!     int  end;
   {
   #ifdef FEAT_FOLDING
       linenr_T lnum;
--- 10751,10759 ----
    */
       static void
   foldclosed_both(argvars, rettv, end)
!     typval_T *argvars UNUSED;
       typval_T *rettv;
!     int  end UNUSED;
   {
   #ifdef FEAT_FOLDING
       linenr_T lnum;
***************
*** 10802,10809 ****
    */
       static void
   f_foldlevel(argvars, rettv)
!     typval_T *argvars;
!     typval_T *rettv;
   {
   #ifdef FEAT_FOLDING
       linenr_T lnum;
--- 10802,10809 ----
    */
       static void
   f_foldlevel(argvars, rettv)
!     typval_T *argvars UNUSED;
!     typval_T *rettv UNUSED;
   {
   #ifdef FEAT_FOLDING
       linenr_T lnum;
***************
*** 11583,11589 ****
       static void
   f_getmatches(argvars, rettv)
       typval_T *argvars UNUSED;
!     typval_T *rettv;
   {
   #ifdef FEAT_SEARCH_EXTRA
       dict_T *dict;
--- 11583,11589 ----
       static void
   f_getmatches(argvars, rettv)
       typval_T *argvars UNUSED;
!     typval_T *rettv UNUSED;
   {
   #ifdef FEAT_SEARCH_EXTRA
       dict_T *dict;
***************
*** 13589,13595 ****
    */
       static void
   f_lispindent(argvars, rettv)
!     typval_T *argvars;
       typval_T *rettv;
   {
   #ifdef FEAT_LISP
--- 13589,13595 ----
    */
       static void
   f_lispindent(argvars, rettv)
!     typval_T *argvars UNUSED;
       typval_T *rettv;
   {
   #ifdef FEAT_LISP
***************
*** 13983,13990 ****
    */
       static void
   f_matchadd(argvars, rettv)
!     typval_T *argvars;
!     typval_T *rettv;
   {
   #ifdef FEAT_SEARCH_EXTRA
       char_u buf[NUMBUFLEN];
--- 13983,13990 ----
    */
       static void
   f_matchadd(argvars, rettv)
!     typval_T *argvars UNUSED;
!     typval_T *rettv UNUSED;
   {
   #ifdef FEAT_SEARCH_EXTRA
       char_u buf[NUMBUFLEN];
***************
*** 14021,14027 ****
    */
       static void
   f_matcharg(argvars, rettv)
!     typval_T *argvars;
       typval_T *rettv;
   {
       if (rettv_list_alloc(rettv) == OK)
--- 14021,14027 ----
    */
       static void
   f_matcharg(argvars, rettv)
!     typval_T *argvars UNUSED;
       typval_T *rettv;
   {
       if (rettv_list_alloc(rettv) == OK)
***************
*** 14053,14060 ****
    */
       static void
   f_matchdelete(argvars, rettv)
!     typval_T *argvars;
!     typval_T *rettv;
   {
   #ifdef FEAT_SEARCH_EXTRA
       rettv->vval.v_number = match_delete(curwin,
--- 14053,14060 ----
    */
       static void
   f_matchdelete(argvars, rettv)
!     typval_T *argvars UNUSED;
!     typval_T *rettv UNUSED;
   {
   #ifdef FEAT_SEARCH_EXTRA
       rettv->vval.v_number = match_delete(curwin,
***************
*** 14871,14878 ****
    */
       static void
   f_reltime(argvars, rettv)
!     typval_T *argvars;
!     typval_T *rettv;
   {
   #ifdef FEAT_RELTIME
       proftime_T res;
--- 14871,14878 ----
    */
       static void
   f_reltime(argvars, rettv)
!     typval_T *argvars UNUSED;
!     typval_T *rettv UNUSED;
   {
   #ifdef FEAT_RELTIME
       proftime_T res;
***************
*** 14920,14926 ****
    */
       static void
   f_reltimestr(argvars, rettv)
!     typval_T *argvars;
       typval_T *rettv;
   {
   #ifdef FEAT_RELTIME
--- 14920,14926 ----
    */
       static void
   f_reltimestr(argvars, rettv)
!     typval_T *argvars UNUSED;
       typval_T *rettv;
   {
   #ifdef FEAT_RELTIME
***************
*** 15965,15971 ****
       int  flags;     /* SP_SETPCMARK and other SP_ values */
       pos_T *match_pos;
       linenr_T lnum_stop;  /* stop at this line if not zero */
!     long time_limit; /* stop after this many msec */
   {
       char_u *save_cpo;
       char_u *pat, *pat2 = NULL, *pat3 = NULL;
--- 15965,15971 ----
       int  flags;     /* SP_SETPCMARK and other SP_ values */
       pos_T *match_pos;
       linenr_T lnum_stop;  /* stop at this line if not zero */
!     long time_limit UNUSED; /* stop after this many msec */
   {
       char_u *save_cpo;
       char_u *pat, *pat2 = NULL, *pat3 = NULL;
***************
*** 16390,16397 ****
    */
       static void
   f_setmatches(argvars, rettv)
!     typval_T *argvars;
!     typval_T *rettv;
   {
   #ifdef FEAT_SEARCH_EXTRA
       list_T *l;
--- 16390,16397 ----
    */
       static void
   f_setmatches(argvars, rettv)
!     typval_T *argvars UNUSED;
!     typval_T *rettv UNUSED;
   {
   #ifdef FEAT_SEARCH_EXTRA
       list_T *l;
***************
*** 18463,18469 ****
    */
       static void
   f_undofile(argvars, rettv)
!     typval_T *argvars;
       typval_T *rettv;
   {
       rettv->v_type = VAR_STRING;
--- 18463,18469 ----
    */
       static void
   f_undofile(argvars, rettv)
!     typval_T *argvars UNUSED;
       typval_T *rettv;
   {
       rettv->v_type = VAR_STRING;
*** ../vim-7.3.818/src/ex_docmd.c 2012-12-05 19:13:11.000000000 +0100
--- src/ex_docmd.c 2013-02-14 20:50:56.000000000 +0100
***************
*** 1734,1739 ****
--- 1734,1741 ----
   #ifdef FEAT_EVAL
  	     /* avoid that a function call in 'statusline' does this */
  	     && !getline_equal(fgetline, cookie, get_func_line)
+ #endif
+ #ifdef FEAT_AUTOCMD
  	     /* avoid that an autocommand, e.g. QuitPre, does this */
  	     && !getline_equal(fgetline, cookie, getnextac)
   #endif
***************
*** 5375,5381 ****
--- 5377,5385 ----
   #endif
       return FAIL;
   }
+ #endif

+ #if defined(FEAT_USR_CMDS) || defined(FEAT_EVAL) || defined(PROTO)
   /*
    * List of names for completion for ":command" with the EXPAND_ flag.
    * Must be alphabetical for completion.
***************
*** 5430,5436 ****
--- 5434,5442 ----
       {EXPAND_USER_VARS, "var"},
       {0, NULL}
   };
+ #endif

+ #if defined(FEAT_USR_CMDS) || defined(PROTO)
       static void
   uc_list(name, name_len)
       char_u *name;
***************
*** 6375,6384 ****
       int  vallen;
       int  *complp;
       long *argt;
!     char_u **compl_arg;
   {
       char_u *arg = NULL;
       size_t arglen = 0;
       int  i;
       int  valend = vallen;

--- 6381,6392 ----
       int  vallen;
       int  *complp;
       long *argt;
!     char_u **compl_arg UNUSED;
   {
       char_u *arg = NULL;
+ # if defined(FEAT_EVAL) && defined(FEAT_CMDL_COMPL)
       size_t arglen = 0;
+ # endif
       int  i;
       int  valend = vallen;

***************
*** 6388,6394 ****
--- 6396,6404 ----
  	 if (value[i] == ',')
  	 {
  	     arg = &value[i + 1];
+ # if defined(FEAT_EVAL) && defined(FEAT_CMDL_COMPL)
  	     arglen = vallen - i - 1;
+ # endif
  	     valend = i;
  	     break;
  	 }
*** ../vim-7.3.818/src/normal.c 2013-01-24 21:00:15.000000000 +0100
--- src/normal.c 2013-02-14 19:33:36.000000000 +0100
***************
*** 2292,2298 ****
--- 2292,2300 ----
   {
   #ifdef FEAT_EVAL
       char_u *(argv[1]);
+ # ifdef FEAT_VIRTUALEDIT
       int  save_virtual_op = virtual_op;
+ # endif

       if (*p_opfunc == NUL)
  	 EMSG(_("E774: 'operatorfunc' is empty"));
***************
*** 2312,2324 ****
--- 2314,2330 ----
  	 else
  	     argv[0] = (char_u *)"char";

+ # ifdef FEAT_VIRTUALEDIT
  	 /* Reset virtual_op so that 'virtualedit' can be changed in the
  	  * function. */
  	 virtual_op = MAYBE;
+ # endif

  	 (void)call_func_retnr(p_opfunc, 1, argv, FALSE);

+ # ifdef FEAT_VIRTUALEDIT
  	 virtual_op = save_virtual_op;
+ # endif
       }
   #else
       EMSG(_("E775: Eval feature not available"));
*** ../vim-7.3.818/src/ex_docmd.c 2012-12-05 19:13:11.000000000 +0100
--- src/ex_docmd.c 2013-02-14 20:50:56.000000000 +0100
***************
*** 1734,1739 ****
--- 1734,1741 ----
   #ifdef FEAT_EVAL
  	     /* avoid that a function call in 'statusline' does this */
  	     && !getline_equal(fgetline, cookie, get_func_line)
+ #endif
+ #ifdef FEAT_AUTOCMD
  	     /* avoid that an autocommand, e.g. QuitPre, does this */
  	     && !getline_equal(fgetline, cookie, getnextac)
   #endif
***************
*** 5375,5381 ****
--- 5377,5385 ----
   #endif
       return FAIL;
   }
+ #endif

+ #if defined(FEAT_USR_CMDS) || defined(FEAT_EVAL) || defined(PROTO)
   /*
    * List of names for completion for ":command" with the EXPAND_ flag.
    * Must be alphabetical for completion.
***************
*** 5430,5436 ****
--- 5434,5442 ----
       {EXPAND_USER_VARS, "var"},
       {0, NULL}
   };
+ #endif

+ #if defined(FEAT_USR_CMDS) || defined(PROTO)
       static void
   uc_list(name, name_len)
       char_u *name;
***************
*** 6375,6384 ****
       int  vallen;
       int  *complp;
       long *argt;
!     char_u **compl_arg;
   {
       char_u *arg = NULL;
       size_t arglen = 0;
       int  i;
       int  valend = vallen;

--- 6381,6392 ----
       int  vallen;
       int  *complp;
       long *argt;
!     char_u **compl_arg UNUSED;
   {
       char_u *arg = NULL;
+ # if defined(FEAT_EVAL) && defined(FEAT_CMDL_COMPL)
       size_t arglen = 0;
+ # endif
       int  i;
       int  valend = vallen;

***************
*** 6388,6394 ****
--- 6396,6404 ----
  	 if (value[i] == ',')
  	 {
  	     arg = &value[i + 1];
+ # if defined(FEAT_EVAL) && defined(FEAT_CMDL_COMPL)
  	     arglen = vallen - i - 1;
+ # endif
  	     valend = i;
  	     break;
  	 }
*** ../vim-7.3.818/src/gui_gtk_x11.c 2013-01-23 16:00:05.000000000 +0100
--- src/gui_gtk_x11.c 2013-02-14 19:38:42.000000000 +0100
***************
*** 5164,5171 ****
       return FAIL;
   }

! #if defined(FEAT_TITLE) \
!  || defined(PROTO)
   /*
    * Return the text window-id and display.  Only required for X-based GUI's
    */
--- 5164,5170 ----
       return FAIL;
   }

! #if defined(FEAT_TITLE) || defined(FEAT_EVAL) || defined(PROTO)
   /*
    * Return the text window-id and display.  Only required for X-based GUI's
    */
*** ../vim-7.3.818/src/version.c 2013-02-14 20:58:30.000000000 +0100
--- src/version.c 2013-02-14 22:09:41.000000000 +0100
***************
*** 727,728 ****
--- 727,730 ----
   {   /* Add new patch number below this line */
+ /**/
+     819,
   /**/

--
(letter from Mark to Mike, about the film's probable certificate)
       For an 'A' we would have to: Lose as many shits as possible; Take Jesus
       Christ out, if possible; Loose "I fart in your general direction"; Lose
       "the oral sex"; Lose "oh, fuck off"; Lose "We make castanets out of your
       testicles"
                  "Monty Python and the Holy Grail" PYTHON (MONTY) PICTURES LTD

  /// Bram Moolenaar -- Bram@... -- 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+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Patch 7.3.820
Problem:    Build errors and warnings when building with small features and
	     Lua, Perl or Ruby.
Solution:   Add #ifdefs and UNUSED.
Files:     src/if_perl.xs, src/if_lua.c, src/if_ruby.c


*** ../vim-7.3.819/src/if_perl.xs 2013-02-06 19:58:38.000000000 +0100
--- src/if_perl.xs 2013-02-14 19:16:00.000000000 +0100
***************
*** 600,608 ****
    */
       char_u *
   eval_to_string(arg, nextcmd, dolist)
!     char_u *arg;
!     char_u **nextcmd;
!     int  dolist;
   {
       return NULL;
   }
--- 600,608 ----
    */
       char_u *
   eval_to_string(arg, nextcmd, dolist)
!     char_u *arg UNUSED;
!     char_u **nextcmd UNUSED;
!     int  dolist UNUSED;
   {
       return NULL;
   }
*** ../vim-7.3.819/src/if_lua.c 2012-10-14 03:41:54.000000000 +0200
--- src/if_lua.c 2013-02-14 19:15:29.000000000 +0100
***************
*** 845,852 ****
   }

       static int
! luaV_dict_iter (lua_State *L)
   {
       hashitem_T *hi = (hashitem_T *) lua_touserdata(L, lua_upvalueindex(2));
       int n = lua_tointeger(L, lua_upvalueindex(3));
       dictitem_T *di;
--- 845,853 ----
   }

       static int
! luaV_dict_iter (lua_State *L UNUSED)
   {
+ #ifdef FEAT_EVAL
       hashitem_T *hi = (hashitem_T *) lua_touserdata(L, lua_upvalueindex(2));
       int n = lua_tointeger(L, lua_upvalueindex(3));
       dictitem_T *di;
***************
*** 860,865 ****
--- 861,869 ----
       lua_pushinteger(L, n - 1);
       lua_replace(L, lua_upvalueindex(3));
       return 2;
+ #else
+     return 0;
+ #endif
   }

       static int
*** ../vim-7.3.819/src/if_ruby.c 2012-11-24 13:38:56.000000000 +0100
--- src/if_ruby.c 2013-02-14 22:18:50.000000000 +0100
***************
*** 1210,1230 ****
       return height;
   }

! static VALUE window_width(VALUE self)
   {
!     win_T *win = get_win(self);
!
!     return INT2NUM(win->w_width);
   }

! static VALUE window_set_width(VALUE self, VALUE width)
   {
       win_T *win = get_win(self);
       win_T *savewin = curwin;

       curwin = win;
       win_setwidth(NUM2INT(width));
       curwin = savewin;
       return width;
   }

--- 1210,1230 ----
       return height;
   }

! static VALUE window_width(VALUE self UNUSED)
   {
!     return INT2NUM(W_WIDTH(get_win(self)));
   }

! static VALUE window_set_width(VALUE self UNUSED, VALUE width)
   {
+ #ifdef FEAT_VERTSPLIT
       win_T *win = get_win(self);
       win_T *savewin = curwin;

       curwin = win;
       win_setwidth(NUM2INT(width));
       curwin = savewin;
+ #endif
       return width;
   }

*** ../vim-7.3.819/src/version.c 2013-02-14 22:11:31.000000000 +0100
--- src/version.c 2013-02-14 22:19:09.000000000 +0100
***************
*** 727,728 ****
--- 727,730 ----
   {   /* Add new patch number below this line */
+ /**/
+     820,
   /**/

--
Did Adam and Eve have navels?

  /// Bram Moolenaar -- Bram@... -- 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+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

On Feb 14, 2013 4:08 PM, "Bram Moolenaar" <Bram@...> wrote:
>
>
> James McCoy wrote:
>
> > The other day in #vim, someone was wondering why :s/SOMEWORD/\L\u&/
> > was resulting in sOMEWORD instead of title-case (Someword).
> >
> > That seemed like a reasonable expectation and is how PCRE would treat
> > that substitution, so I came up with the attached patch to make Vim work
> > like that.  Also included are tests.
>
> Thanks, sounds like a good solution.  Implementation is fairly simple.
>
> Can you also write an update for the documentation?

That's the other part I forgot to mention.  The documentation already describes the behavior I implemented.

James

Ulrik Sverdrup wrote:

> The blowfish encryption mode is vulnerable (not to revelation of the
> plaintext), but the encryption is not checked for integrity or
> authenticity. This means that someone might corrupt the encrypted file
> (hexedit or similar), and vim will decrypt it without notice of error or
> warning.
>
> This attack allows someone to modfiy encrypted files so that the owner
> doesn't notice. With sufficient tries or skill it might be possible to
> change a file's values in a predictable way at a certain offset.
>
> The solution is an authenticated encryption mode. The common way to do
> it is 'Encrypt-then-MAC' where a message authentication code is formed
> from the ciphertext and the key. This code when matching will prove that
> the document is unchanged and was produced by someone with access to the
> key. This code will detect the previous attack case, and additionally it
> allows vim to detect that the wrong password was entered. Security
> practise says that Vim must fail with an error if the MAC does not match.

I think that a verification key will actually make it easier to crack
the password.  Currently, when an attacker tries all kinds of passwords,
he also needs a way to verify the decrypted text is actually readable.
That is not so easy to do.  With a verification key the verify part
becomes really easy and fast.

It is extremely difficult to change the file in a way that after
decryption it is readable text.  Probably just as difficult as cracking
the password.  When knowing that a file is only plain text, checking for
invalid Unicode characters is probably sufficient to notice that the
decryption failed.

--
Communication is one of the most compli..., eh, well, it's hard.
You know what I mean.  Not?

  /// Bram Moolenaar -- Bram@... -- 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+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Bram Moolenaar, Thu 2013-02-14 @ 22:08:21+0100:
> I think that a verification key will actually make it easier to crack
> the password.  Currently, when an attacker tries all kinds of
> passwords, he also needs a way to verify the decrypted text is
> actually readable. That is not so easy to do.  With a verification key
> the verify part becomes really easy and fast.

Also, if you just need to ensure the integrity of the encrypted file,
you could always use an external tool like gpg to sign it. That doesn't
really need to be built into Vim, in my opinion.

On 2013-02-14 22:08, Bram Moolenaar wrote:
>
> Ulrik Sverdrup wrote:
>
>> The blowfish encryption mode is vulnerable (not to revelation of the
>> plaintext), but the encryption is not checked for integrity or
>> authenticity. This means that someone might corrupt the encrypted file
>> (hexedit or similar), and vim will decrypt it without notice of error or
>> warning.
>>
>> This attack allows someone to modfiy encrypted files so that the owner
>> doesn't notice. With sufficient tries or skill it might be possible to
>> change a file's values in a predictable way at a certain offset.
>>
>> The solution is an authenticated encryption mode. The common way to do
>> it is 'Encrypt-then-MAC' where a message authentication code is formed
>> from the ciphertext and the key. This code when matching will prove that
>> the document is unchanged and was produced by someone with access to the
>> key. This code will detect the previous attack case, and additionally it
>> allows vim to detect that the wrong password was entered. Security
>> practise says that Vim must fail with an error if the MAC does not match.
>
> I think that a verification key will actually make it easier to crack
> the password.  Currently, when an attacker tries all kinds of passwords,
> he also needs a way to verify the decrypted text is actually readable.
> That is not so easy to do.  With a verification key the verify part
> becomes really easy and fast.
>
> It is extremely difficult to change the file in a way that after
> decryption it is readable text.  Probably just as difficult as cracking
> the password.  When knowing that a file is only plain text, checking for
> invalid Unicode characters is probably sufficient to notice that the
> decryption failed.
>

Using Vim 7.3 patches 1-547, this is not true, and it is trivially
testable (otherwise I would not have claimed it).

Using :set cm=blowfish  :X goodenough
I produced file A that ends with "I owe you 200 USD"

using hex editor I flipped 1 single bit to produce file B, that ends
with "I owe you 300 USD".  You can diff the two binary files by using:

diff <(xxd A) <(xxd B)

a one-bit difference in the ciphertext leads to a one-bit difference in
the plain text, and we have a false document and undedetected corruption.

To reproduce, here are files A and B:

xxd -r >A <<EOF
0000000: 5669 6d43 7279 7074 7e30 3221 4638 a780  VimCrypt~02!F8..
0000010: 332a 14a3 e680 d2dd 2003 d079 9b8a 6ca7  3*...... ..y..l.
0000020: 0e43 da8b b1bb 6aad 0f1a c38c f4ba 24ba  .C....j.......$.
0000030: 181b c7d6 9b8a 6ca7 0e43 da8b b1bb 6aad  ......l..C....j.
0000040: 0f1a c38c f4ba 24ba 181b c7d6 9b8a 6ca7  ......$.......l.
0000050: 0e43 da8b b1bb 6aad 0f1a c38c ec09 c98f  .C....j.........
0000060: 2322 0fd6 1aff 59b1 47cc a61f 5a62 c89c  #"....Y.G...Zb..
0000070: eba3 d824 ec09 c98f 2322 0fd6 1aff 59b1  ...$....#"....Y.
0000080: 47cc a61f 5a62 c89c eba3 d824 ec09 c98f  G...Zb.....$....
0000090: 2322 0fd6 1aa1 78f8 5b9b aa4c dbfb 6d56  #"....x.[..L..mV
00000a0: 32e5 962e b15c 000a f6                   2....\...
EOF

xxd -r >B <<EOF
0000000: 5669 6d43 7279 7074 7e30 3221 4638 a780  VimCrypt~02!F8..
0000010: 332a 14a3 e680 d2dd 2003 d079 9b8a 6ca7  3*...... ..y..l.
0000020: 0e43 da8b b1bb 6aad 0f1a c38c f4ba 24ba  .C....j.......$.
0000030: 181b c7d6 9b8a 6ca7 0e43 da8b b1bb 6aad  ......l..C....j.
0000040: 0f1a c38c f4ba 24ba 181b c7d6 9b8a 6ca7  ......$.......l.
0000050: 0e43 da8b b1bb 6aad 0f1a c38c ec09 c98f  .C....j.........
0000060: 2322 0fd6 1aff 59b1 47cc a61f 5a62 c89c  #"....Y.G...Zb..
0000070: eba3 d824 ec09 c98f 2322 0fd6 1aff 59b1  ...$....#"....Y.
0000080: 47cc a61f 5a62 c89c eba3 d824 ec09 c98f  G...Zb.....$....
0000090: 2322 0fd6 1aa1 78f8 5b9b aa4c dbfb 6d56  #"....x.[..L..mV
00000a0: 33e5 962e b15c 000a f6                   3....\...
EOF


Note: I didn't search or brute force this, I only counted the right byte
offset in the file and flipped a bit. I really hope I am somehow
mistaken, but I don't think I am.

Regarding quickening brute force by using a MAC, this is a false, the
MAC can have equivalent security factor to the block cipher, it should
really not be a concern.

HTH,
ulrik

PS. the password is 'goodenough' literally.

--
--
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+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Ulrik,

Any one random bit flip will cause to one block (8 bytes) to be
corrupted at that point,
and then all bytes thereafter will be corrupted.  Not just 1 bit
corruption in encrypted text.

And if you encrypt two text files with 1 bit difference, they should
be completely
different when encrypted. Even same text file will come out different
each time it is
written encrypted. Because a random seed is also used.

Let me do more tests, and check how you got 1 bit difference. I am
using an older gvim73,
that I compiled myself.

thanks for the report,
mohsin

On Fri, Feb 15, 2013 at 5:37 AM, Ulrik <ulrik.sverdrup@...> wrote:
> On 2013-02-14 22:08, Bram Moolenaar wrote:
>>
>> Ulrik Sverdrup wrote:
>>
>>> The blowfish encryption mode is vulnerable (not to revelation of the
>>> plaintext), but the encryption is not checked for integrity or
>>> authenticity. This means that someone might corrupt the encrypted file
>>> (hexedit or similar), and vim will decrypt it without notice of error or
>>> warning.
>>>
>>> This attack allows someone to modfiy encrypted files so that the owner
>>> doesn't notice. With sufficient tries or skill it might be possible to
>>> change a file's values in a predictable way at a certain offset.
>>>
>>> The solution is an authenticated encryption mode. The common way to do
>>> it is 'Encrypt-then-MAC' where a message authentication code is formed
>>> from the ciphertext and the key. This code when matching will prove that
>>> the document is unchanged and was produced by someone with access to the
>>> key. This code will detect the previous attack case, and additionally it
>>> allows vim to detect that the wrong password was entered. Security
>>> practise says that Vim must fail with an error if the MAC does not match.
>>
>> I think that a verification key will actually make it easier to crack
>> the password.  Currently, when an attacker tries all kinds of passwords,
>> he also needs a way to verify the decrypted text is actually readable.
>> That is not so easy to do.  With a verification key the verify part
>> becomes really easy and fast.
>>
>> It is extremely difficult to change the file in a way that after
>> decryption it is readable text.  Probably just as difficult as cracking
>> the password.  When knowing that a file is only plain text, checking for
>> invalid Unicode characters is probably sufficient to notice that the
>> decryption failed.
>>
>
> Using Vim 7.3 patches 1-547, this is not true, and it is trivially
> testable (otherwise I would not have claimed it).
>
> Using :set cm=blowfish  :X goodenough
> I produced file A that ends with "I owe you 200 USD"
>
> using hex editor I flipped 1 single bit to produce file B, that ends
> with "I owe you 300 USD".  You can diff the two binary files by using:
>
> diff <(xxd A) <(xxd B)
>
> a one-bit difference in the ciphertext leads to a one-bit difference in
> the plain text, and we have a false document and undedetected corruption.
>
> To reproduce, here are files A and B:
>
> xxd -r >A <<EOF
> 0000000: 5669 6d43 7279 7074 7e30 3221 4638 a780  VimCrypt~02!F8..
> 0000010: 332a 14a3 e680 d2dd 2003 d079 9b8a 6ca7  3*...... ..y..l.
> 0000020: 0e43 da8b b1bb 6aad 0f1a c38c f4ba 24ba  .C....j.......$.
> 0000030: 181b c7d6 9b8a 6ca7 0e43 da8b b1bb 6aad  ......l..C....j.
> 0000040: 0f1a c38c f4ba 24ba 181b c7d6 9b8a 6ca7  ......$.......l.
> 0000050: 0e43 da8b b1bb 6aad 0f1a c38c ec09 c98f  .C....j.........
> 0000060: 2322 0fd6 1aff 59b1 47cc a61f 5a62 c89c  #"....Y.G...Zb..
> 0000070: eba3 d824 ec09 c98f 2322 0fd6 1aff 59b1  ...$....#"....Y.
> 0000080: 47cc a61f 5a62 c89c eba3 d824 ec09 c98f  G...Zb.....$....
> 0000090: 2322 0fd6 1aa1 78f8 5b9b aa4c dbfb 6d56  #"....x.[..L..mV
> 00000a0: 32e5 962e b15c 000a f6                   2....\...
> EOF
>
> xxd -r >B <<EOF
> 0000000: 5669 6d43 7279 7074 7e30 3221 4638 a780  VimCrypt~02!F8..
> 0000010: 332a 14a3 e680 d2dd 2003 d079 9b8a 6ca7  3*...... ..y..l.
> 0000020: 0e43 da8b b1bb 6aad 0f1a c38c f4ba 24ba  .C....j.......$.
> 0000030: 181b c7d6 9b8a 6ca7 0e43 da8b b1bb 6aad  ......l..C....j.
> 0000040: 0f1a c38c f4ba 24ba 181b c7d6 9b8a 6ca7  ......$.......l.
> 0000050: 0e43 da8b b1bb 6aad 0f1a c38c ec09 c98f  .C....j.........
> 0000060: 2322 0fd6 1aff 59b1 47cc a61f 5a62 c89c  #"....Y.G...Zb..
> 0000070: eba3 d824 ec09 c98f 2322 0fd6 1aff 59b1  ...$....#"....Y.
> 0000080: 47cc a61f 5a62 c89c eba3 d824 ec09 c98f  G...Zb.....$....
> 0000090: 2322 0fd6 1aa1 78f8 5b9b aa4c dbfb 6d56  #"....x.[..L..mV
> 00000a0: 33e5 962e b15c 000a f6                   3....\...
> EOF
>
>
> Note: I didn't search or brute force this, I only counted the right byte
> offset in the file and flipped a bit. I really hope I am somehow
> mistaken, but I don't think I am.
>
> Regarding quickening brute force by using a MAC, this is a false, the
> MAC can have equivalent security factor to the block cipher, it should
> really not be a concern.
>
> HTH,
> ulrik
>
> PS. the password is 'goodenough' literally.
>
> --
> --
> 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+unsubscribe@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>

--
--
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+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.