On 15/02/13 08:08, Bram Moolenaar wrote:
>
> 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.

There's a lot of exploitable redundancy in a typical text file. For
English text, you can just check if MSB of each byte is zero. The
computational requirements are probably lower than verifying a MAC.
You would need a very large password before similarly large candidate
passwords started generating ASCII text, and if the password was so
large, brute force wouldn't be a problem.

You could devise a scheme involving compression to reduce the amount
of redundancy in the message. But key strengthening (PBKDF2 etc.) is
probably a more robust way to mitigate brute force attacks.

-- Tim Starling

--
--
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 guys, I'm trying to add new options to allow users tweak their fold columns.
The first option is:

     'foldcolshowlvl'  'fsl': Show a number representing the fold level.

This allow user to "hide" the numbers representing the fold level. It is very
useful is the `foldcolumn` is 1.

My second option is the definition of custom characters to use while drawing the
fold column. This way users can have characters representing folders other than
`+`, `-` and `|`.

So far I could make this works very well with one exception: multi-bytes.

If I define the new characters to be like this:

     set fds=fa:\ ,fo:▾,fc:▸

Nothing is shown on the fold column. I notice that on `screen.c` we have a
function called `fill_foldcolumn` where those characters are defined, and there
is where I tried to use the new characts, but since it has code like this:

		 p[i] = fds_fo;

This means that since `p` is a `char_u`, anything that is hold after the first 8
bits will be truncated. I tried to force the copy of the rest of the bits but
had no luck on that!

Any one have a clue about this?

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

Key strengthening is done in vim73.

Compression would be nice before encryption; Alternatively you can just use
gpg or pgp (compression, encryption, mac signatures, multiple keys),
there was a vim plugin to do that.


On Fri, Feb 15, 2013 at 11:10 AM, Tim Starling <tstarling@...> wrote:
> On 15/02/13 08:08, Bram Moolenaar wrote:
>>
>> 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.
>
> There's a lot of exploitable redundancy in a typical text file. For
> English text, you can just check if MSB of each byte is zero. The
> computational requirements are probably lower than verifying a MAC.
> You would need a very large password before similarly large candidate
> passwords started generating ASCII text, and if the password was so
> large, brute force wouldn't be a problem.
>
> You could devise a scheme involving compression to reduce the amount
> of redundancy in the message. But key strengthening (PBKDF2 etc.) is
> probably a more robust way to mitigate brute force attacks.
>
> -- Tim Starling
>
> --
> --
> 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.

Hey,

For doing libclang assisted re-factoring (renaming of symbols), I want to
replace the symbol name at given locations with the new symbol name.

Now, the locations are given as (fileName,line,column).
I could issue the editor commands to:

* edit fileName
* jump to (line,column)
* delete old symbol (I know how long it is)
* insert new symbol

While this would work, it would pollute my jump list.
So I am wondering, what would be the best way to replace words at a given set of
locations without any side effects like polluting the jump list?

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 15-Feb-13 09:24:11 +0100, Nathan H�sken wrote:

> Hey,
>
> For doing libclang assisted re-factoring (renaming of symbols), I want
> to replace the symbol name at given locations with the new symbol
> name.
>
> Now, the locations are given as (fileName,line,column). I could issue
> the editor commands to:
>
> * edit fileName * jump to (line,column) * delete old symbol (I know
> how long it is) * insert new symbol
>
> While this would work, it would pollute my jump list. So I am
> wondering, what would be the best way to replace words at a given set
> of locations without any side effects like polluting the jump list?

I would use getline() in a loop over the positions and perform the replacement
with either substitute() or strpart() (probably the latter when I already have
the byte indices). Then write back the result with setline(). This avoids all
side effects.

-- regards, ingo

PS: Such questions are better directed to vim_use.

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

There seems to be a small bug in the completion popup behavior.
Here is a simple way to reproduce it (I used vim 7.3-798 on Linux):

1) Start vim with "vim -u NONE -c "set nocp"

2) Enter the following text:
foobar
foobaz
foofoo1
foofoo2
foo

3) In insert mode, with the cursor at the end of the last word, type
<c-n><c-p> to open the completion menu and remove the inserted text

4) Type <Down> to highlight "foobar" again

4) Type 'f': the completion list shrinks to "foofoo1" and "foofoo2" only

5) Type <bs>: the list is restored, and "foofoo1" is still selected
(and typing <CR> now would insert it)

6) Type <down>: instead of selecting "foofoo2" as expected, the
selection is now on "foobaz", as if there was still a reference to the
previous "foobar" selection somehow. This is even more visible when
the completion list has more items.

I don't know if it's preferable to have the selection back to "foobar"
after <bs>, or to have it _really_ on "foofoo1", but the current
situation is wrong IMHO.

Best regards,
--
Olivier

--
--
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 4:20 PM, Bram Moolenaar <Bram@...> wrote:
>
> Patch 7.3.820
> Problem:    Build errors and warnings when building with small features and
>             Lua, Perl or Ruby.

Perhaps it was an earlier patch (my previous build was .801), but my
build with Cygwin now is broken:

mkdir -p obj i686-pc-mingw32-gcc -c -O3 -fomit-frame-pointer
-freg-struct-return -fno-strength-reduce -DWIN32 -DHAVE_PATHDEF
-DFEAT_H UGE  -DWINVER=0x0500 -D_WIN32_WINNT=0x0500 -DFEAT_PERL
-DDYNAMIC_PERL -DDYNAMIC_PERL_DLL=\"perl58.dll\" -DFEAT_PYTHON -D
DYNAMIC_PYTHON -DDYNAMIC_PYTHON_DLL=\"python27.dll\" -DFEAT_RUBY
-DDYNAMIC_RUBY -DDYNAMIC_RUBY_DLL=\"msvcrt-ruby191.dll\ "
-DDYNAMIC_RUBY_VER=191 -DFEAT_LUA -DDYNAMIC_LUA
-DDYNAMIC_LUA_DLL=\"lua51.dll\" -DDYNAMIC_GETTEXT -DDYNAMIC_ICONV -DFE
AT_MBYTE -DFEAT_MBYTE_IME -DDYNAMIC_IME -DFEAT_CSCOPE -DFEAT_OLE
-march=i386 -Iproto -I/cygdrive/c/strawberry/perl/lib/C ORE
-I/cygdrive/c/Ruby193/lib/ruby/1.9.1/i386-mingw32
-I/cygdrive/c/Ruby193/include/ruby-1.9.1 -I/cygdrive/c/Ruby193/inc
lude/ruby-1.9.1/i386-mingw32 -I/cygdrive/c/PROGRA~2/Lua/5.1/include -s
-mno-cygwin blowfish.c -o obj/blowfish.o /bin/sh: i686-pc-mingw32-gcc:
command not found
Make_cyg.mak:613: recipe for target `obj/blowfish.o' failed
make: *** [obj/blowfish.o] Error 127

--
Steve Hall  [ digitect dancingpaper com ]

--
--
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?
>
> That's the other part I forgot to mention.  The documentation already
> describes the behavior I implemented.

Where?  I cannot find a match for \L\u in the documentation.

--
An SQL statement walks into a bar.  He approaches two tables
and says, "Mind if I join you?"

  /// 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 Steve,

2013/02/15 Fri 22:54:17 UTC+9 Steve Hall wrote:

> Perhaps it was an earlier patch (my previous build was .801), but my
> build with Cygwin now is broken:
>
> mkdir -p obj i686-pc-mingw32-gcc -c -O3 -fomit-frame-pointer
> -freg-struct-return -fno-strength-reduce -DWIN32 -DHAVE_PATHDEF
> -DFEAT_H UGE  -DWINVER=0x0500 -D_WIN32_WINNT=0x0500 -DFEAT_PERL
> -DDYNAMIC_PERL -DDYNAMIC_PERL_DLL=\"perl58.dll\" -DFEAT_PYTHON -D
> DYNAMIC_PYTHON -DDYNAMIC_PYTHON_DLL=\"python27.dll\" -DFEAT_RUBY
> -DDYNAMIC_RUBY -DDYNAMIC_RUBY_DLL=\"msvcrt-ruby191.dll\ "
> -DDYNAMIC_RUBY_VER=191 -DFEAT_LUA -DDYNAMIC_LUA
> -DDYNAMIC_LUA_DLL=\"lua51.dll\" -DDYNAMIC_GETTEXT -DDYNAMIC_ICONV -DFE
> AT_MBYTE -DFEAT_MBYTE_IME -DDYNAMIC_IME -DFEAT_CSCOPE -DFEAT_OLE
> -march=i386 -Iproto -I/cygdrive/c/strawberry/perl/lib/C ORE
> -I/cygdrive/c/Ruby193/lib/ruby/1.9.1/i386-mingw32
> -I/cygdrive/c/Ruby193/include/ruby-1.9.1 -I/cygdrive/c/Ruby193/inc
> lude/ruby-1.9.1/i386-mingw32 -I/cygdrive/c/PROGRA~2/Lua/5.1/include -s
> -mno-cygwin blowfish.c -o obj/blowfish.o /bin/sh: i686-pc-mingw32-gcc:
> command not found
> Make_cyg.mak:613: recipe for target `obj/blowfish.o' failed
> make: *** [obj/blowfish.o] Error 127

The default compiler for Make_cyg.mak was changed from 'gcc' to
'i686-pc-mingw32-gcc' in 7.3.814.  It is because the latest
cygwin-gcc (gcc-4) does not support -mno-cygwin option anymore.

You may do one of the following:

1. Install mingw-gcc-g++ package.
    i686-pc-mingw32-gcc (4.5.2) can be used.

2. Specify the old version of gcc explicitly.
    E.g.
     $ make -f Make_cyg.mak CC=gcc-3

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

On Feb 15, 2013 9:24 AM, "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.
>
> Where? �I cannot find a match for \L\u in the documentation.

The s/\L topic states

� following characters made uppercase, until \E

and s/\u states

� next character made uppercase

so a \u should only affect the character after it, not terminate the existing \L effect.� Were you looking for this specific example to be documented?

James

From: Ulrik
> Sent: February-14-13 1:00 PM
> The blowfish encryption mode is vulnerable (not to revelation of the
> plaintext), but the encryption is not checked for integrity or

I suspect the real problem is a weakness in Vim's blowfish
implementation.

But yes, I can reproduce this with gvim73_46.exe on
Win7 64-bit Enterprise.

> 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 isn't supposed to happen. A strong encryption algorithm will
render completely different crypt text for even a single bit change in
the plaintext, and, a single bit change in the crypt text is supposed
to decrypt to corrupt plaintext.

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

Agreed that someone can modify a VimCrypt file and have the
modification propagate into the plain text. However, for this to be a
useful attack I think that the plaintext already needs to be known
which is unlikely, and if it is known, given the plaintext and the
crypttext, it won't take to long to find the key, and then you can
make all the changes you want.

I'm more concerned that this indicates there is a bug in Vim's
blowfish implementation and that will allow keys to be recovered more
easily. *That's* a big problem.

> The solution is an authenticated encryption mode. The common way to do

Perhaps, but only if this effect turns out to be endemic in blowfish
and not a result of the implementation. I feel strongly that we need
to examine the implementation first.

> key. This code will detect the previous attack case, and additionally it
> allows vim to detect that the wrong password was entered. Security

When the wrong password is entered the file decrypts to garbage, as it
should. There's no need to through an error there. If the file is
corrupted (as per your test or disk failure or cosmic ray) then it is
supposed to decrypt to garbage.

I don't see a need for an authentication scheme, but then, I'm not a
security programmer by profession so I'm a novice and could be
incorrect.

...Stu

--
--
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 2013-02-15 16:34, MacDonald, Stuart wrote:
> From: Ulrik
>> Sent: February-14-13 1:00 PM
>> The blowfish encryption mode is vulnerable (not to revelation of the
>> plaintext), but the encryption is not checked for integrity or
>
> I suspect the real problem is a weakness in Vim's blowfish
> implementation.
>
> But yes, I can reproduce this with gvim73_46.exe on
> Win7 64-bit Enterprise.
>
>> 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 isn't supposed to happen. A strong encryption algorithm will
> render completely different crypt text for even a single bit change in
> the plaintext, and, a single bit change in the crypt text is supposed
> to decrypt to corrupt plaintext.
>

I think this is your misconception. It can't strictly be true, because
the uncorrupted prefix of the file will always decrypt ok. To truly
render the *whole* decryption corrupt when the ciphertext is altered,
that would require a multi-pass encryption algorithm.

I modern crypto the error propagation and error detection discussions
have totally vanished and authenticated encryption has taken its place;
the new paradigm requires verified authenticity and integrity or
discarding the message!

I agree that Vim might have implementation issues. I have looked into
the code and it says Blowfish with OFB mode however I cannot get the
code or the behavior to line up with any block cipher mode I know of!

>> 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.
>
> Agreed that someone can modify a VimCrypt file and have the
> modification propagate into the plain text. However, for this to be a
> useful attack I think that the plaintext already needs to be known
> which is unlikely, and if it is known, given the plaintext and the
> crypttext, it won't take to long to find the key, and then you can
> make all the changes you want.
>
> I'm more concerned that this indicates there is a bug in Vim's
> blowfish implementation and that will allow keys to be recovered more
> easily. *That's* a big problem.
>
>> The solution is an authenticated encryption mode. The common way to do
>
> Perhaps, but only if this effect turns out to be endemic in blowfish
> and not a result of the implementation. I feel strongly that we need
> to examine the implementation first.
>
>> key. This code will detect the previous attack case, and additionally it
>> allows vim to detect that the wrong password was entered. Security
>
> When the wrong password is entered the file decrypts to garbage, as it
> should. There's no need to through an error there. If the file is
> corrupted (as per your test or disk failure or cosmic ray) then it is
> supposed to decrypt to garbage.

Taken together, I think this is ridiculous. It is bad usability to give
the user garbage output, as mistyped keys will happen to anyone. Instead
you give them the opportunity to absent-mindedly save the garbage
(destroying their data), or confusing them.

>
> I don't see a need for an authentication scheme, but then, I'm not a
> security programmer by profession so I'm a novice and could be
> incorrect.
>
> ...Stu
>

I'm not a crypto professional, and so I have respect for the ample
documentation you can find about current best practice, and if Vim wants
to go forward with a better encryption scheme, we must absolutely
respect these practices.

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

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.
> >
> > Where?  I cannot find a match for \L\u in the documentation.
>
> The s/\L topic states
>
>   following characters made uppercase, until \E
>
> and s/\u states
>
>   next character made uppercase
>
> so a \u should only affect the character after it, not terminate the
> existing \L effect.  Were you looking for this specific example to be
> documented?

But it never worked that way, so far a \u would undo a previous \L.
That was not explicitly mentioned, but it has always worked that way.
I think it's good to explicitly state how this works.

There should be a specific example of how to change a line of words into
title case.  It's very useful.  We might even want to put it in the user
manual.  That would be usr_10.txt

--
FATAL ERROR! SYSTEM HALTED! - Press any key to continue doing nothing.

  /// 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 Fri, Feb 15, 2013 at 9:58 AM, Ken Takata <kentkt@...> wrote:
> 2013/02/15 Fri 22:54:17 UTC+9 Steve Hall wrote:
>
>> Perhaps it was an earlier patch (my previous build was .801), but my
>> build with Cygwin now is broken:
[...]
>> Make_cyg.mak:613: recipe for target `obj/blowfish.o' failed
>> make: *** [obj/blowfish.o] Error 127
>
> The default compiler for Make_cyg.mak was changed from 'gcc' to
> 'i686-pc-mingw32-gcc' in 7.3.814.  It is because the latest
> cygwin-gcc (gcc-4) does not support -mno-cygwin option anymore.
>
> You may do one of the following:
>
> 1. Install mingw-gcc-g++ package.
>    i686-pc-mingw32-gcc (4.5.2) can be used.

This solved my build error, but now I have a dependency problem:

   The program can't start because libstdc++-6.dll is missing from your
   computer. Try reinstalling the program to fix this problem.

I'm trying to build Vim binaries without library dependencies. Is it
going to be possible with Cygwin's mingw-gcc-g++? Not sure why this
was changed.


> 2. Specify the old version of gcc explicitly.
>    E.g.
>     $ make -f Make_cyg.mak CC=gcc-3

I wonder how long this will be supported. Is it, too, going to break
in the near future?


--
Steve Hall  [ digitect dancingpaper com ]

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

Status: New
Owner: ----
Labels: Type-Defect Priority-Medium

New issue 108 by mortba...@...: rst syntax file, completion
http://code.google.com/p/vim/issues/detail?id=108

The completion ^x^p doesn't work for words with some special characters
like � with rst syntax highlighting. It works fine with other syntax files
but not with rst. Attached is an example document where the comletion will
fail for the last word in the text.

I have tried to figure out where the problem could be, but I have no idea,
I'm already happy to have tracked it down to the rst syntax file
http://code.google.com/p/vim/source/browse/runtime/syntax/rst.vim.

Thanks

Attachments:
	 example.rst  111 bytes

--
You received this message because this project is configured to send all
issue notifications to this address.
You may adjust your notification preferences at:
https://code.google.com/hosting/settings

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

2013/02/16 Sat 2:12:54 UTC+9 Steve Hall wrote:

> > 1. Install mingw-gcc-g++ package.
> >    i686-pc-mingw32-gcc (4.5.2) can be used.
>
> This solved my build error, but now I have a dependency problem:
>
>   The program can't start because libstdc++-6.dll is missing from your
>   computer. Try reinstalling the program to fix this problem.
>
> I'm trying to build Vim binaries without library dependencies. Is it
> going to be possible with Cygwin's mingw-gcc-g++? Not sure why this
> was changed.

Do you enable OLE?  Sorry, I didn't care about that.
Please try attached patch with an option STATIC_STDCPLUS=yes.

   $ make -f Make_cyg.mak STATIC_STDCPLUS=yes

This option is the same as Make_ming.mak.


> > 2. Specify the old version of gcc explicitly.
> >    E.g.
> >     $ make -f Make_cyg.mak CC=gcc-3
>
> I wonder how long this will be supported. Is it, too, going to break
> in the near future?

I'm not sure, but I think it's better to use the new one.

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

From: Ulrik
> Sent: February-14-13 7:08 PM
>
> Using Vim 7.3 patches 1-547, this is not true, and it is trivially
> testable (otherwise I would not have claimed it).

I can confirm that several smaller test cases fail; details below.

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

In the future sending a precise list of steps to reproduce the problem
is a much better bug report than a vague set of instructions and a
couple of file contents. To be honest, I was nervous using vim on your
file below because you could have been trying to exploit an unknown
security bug in vim. _Reporting_ a security bug would have been a
clever bit of social engineering. Please note, I'm not trying to say
anything about you or your intentions, just trying to describe my
state of thought at the time. Your file contents appear to me to be
good and non-malicious.

The original file contents are <<EOF

This is encrypted text.
This is encrypted text.
This is encrypted text.
This is encrypted text.
This is encrypted text.

I owe you 200 USD.
EOF

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

Confirmed. Sadly. :-(

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

You are correct. I have only tested altering the 9th last byte in the
crypttext. Why did you pick that byte to modify?

Vim needs more testing on this I think:
- what happens when bytes other than the 9th last are modified?
- exactly how much modification can be done before the file decrypts
   to garbage like it's supposed to
- is there a range of bytes that are affected?
- are certain keys affected? Or all keys?
- is it something about the structure of the plaintext? The repetion
   or the small size?
- what other characteristics of the bug can be determined?
- are other crypt methods affected?

I have tested tese contents <<EOF
adsfasdfasdfasdfasdf
asdmxzcvzxcvsdf980890asdf
sdafknzxclv890asdf90uamsdfm
xzcvklsadfnlasdf0

1,211.98 is my tax refund this year.
EOF

by doing
- vim -u NONE -U NONE S
- enter the text above
- :set cm=blowfish
- :X
- correcthorsebatterystaple
- <confirm key>
- :x

xxd < S > S.xxd gives me:

0000000: 5669 6d43 7279 7074 7e30 3221 244b 0178  VimCrypt~02!$K.x
0000010: 2f63 cde0 50e2 b48d 5085 57c1 659a 4e03  /c..P...P.W.e.N.
0000020: a08e c4e6 658d 5903 a08e c4e6 658d 5903  ....e.Y.....e.Y.
0000030: ccf7 c1f3 6093 451f a28b daf8 6788 4e01  ....`.E.....g.N.
0000040: a7c4 98b0 3cc7 0d04 b299 c68d 0e8d 5904  ....<.........Y.
0000050: a796 cefa 7c9d 5113 f9c4 90e1 ab45 1fd6  ....|.Q......E..
0000060: 39d9 8e01 5e0f 2faf 930f 2eaa 4396 2b44  9...^./.....C.+D
0000070: f817 8a97 d8ae d153 ee24 b879 ab76 9ae5  .......S.$.y.v..
0000080: b462 33e5 d9a5 26ba 2771 451a 59a8 012b  .b3...&.'qE.Y..+
0000090: 63d4 af6d 092c 1cda 5fb7 2bd9 a568 a349  c..m.,.._.+..h.I
00000a0: e794 ab16 dc                             .....

I've done this exact set of text a few times, and the crypttext is
different each time as it should be. It's easiest if one does the
encryption until the 9th last byte has the MSB set, that way you don't
have to fiddle with the ascii representation at the end of the line,
just change the hex value. Here it's offset 0x9c which is 0xa5.

Then I do:

- vim S.xxd
- alter the value at 0x9c
- :x
- xxd -r < S.xxd > S
- vim -u NONE -U NONE S
- correcthorsebatterystaple
- note the last line is alterated from "this year" to something:

0xa0 == thiv
0xa1 == thiw
0xa2 == thit
0xa3 == thiu
0xa4 == thir
0xa5 == this
0xa6 == thip
0xa7 == thiq
0xa8 == thi~
0xa9 == thi\0x7f
0xaa == thi|
0xab == thi}
0xac == thiz
0xad == thi{
0xae == thix
0xaf == thiy

0xaa is a 4 bit change. This problem is bigger than single bit flips.
The sharp-eyed will note the pattern in the incorrect text, which I
expect is a direct result of a flaw in the blowfish implementation.

Altering the high nibble also produces the incorrect behaviour (being
careful to also alter the ascii character at the end of the line):

0xb5 == thic
0x55 == thi\0x83
0x5a == thi\0x8c

0x5a is an 8 bit difference. That's not insignificant.

...Stu

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

From: Ulrik
> Sent: February-15-13 11:57 AM
>
> On 2013-02-15 16:34, MacDonald, Stuart wrote:
> > This isn't supposed to happen. A strong encryption algorithm will
> > render completely different crypt text for even a single bit change in
> > the plaintext, and, a single bit change in the crypt text is supposed
> > to decrypt to corrupt plaintext.
>
> I think this is your misconception. It can't strictly be true, because
> the uncorrupted prefix of the file will always decrypt ok. To truly
> render the *whole* decryption corrupt when the ciphertext is altered,
> that would require a multi-pass encryption algorithm.

I did say I'm a novice in this area. :-) The prefix argument is a good
point.

...Stu

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

Comment #1 on issue 108 by chrisbr...@...: rst syntax file,
completion
http://code.google.com/p/vim/issues/detail?id=108

Problem is, the rst syntax file includes the lisp syntax file, which sets
the 'iskeyword' option to unwanted values. I think, the syntax script
should reset those settings back.

As a workaround, create a file ~/.vim/after/syntax/rst.vim and put into it
:set isk&vim

Then the keyword completion should work again.

--
You received this message because this project is configured to send all
issue notifications to this address.
You may adjust your notification preferences at:
https://code.google.com/hosting/settings

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

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

Here is a patch

> Perhaps it can be combined with some other option value that might
> have changed and require an action after entering another buffer?

Not sure which ones need to be taken care of.

regards,
Christian
--
Phantasie ist etwas, das sich viele gar nicht vorstellen k�nnen.
		 -- Helmut Qualtinger

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

Comment #5 on issue 28 by fritzoph...@...: out of the box, gVim
7.3.46 for Win32 cannot write swap files on Windows 7
http://code.google.com/p/vim/issues/detail?id=28

I was just upgraded to Windows 7 at work and ran into this issue.

The problem is that Vim defaults the 'directory' option
to ".,C:\TMP,C:\Temp" but these directories either do not exist or are not
writeable.

Vim should instead use the $TMP and $TEMP environment variables instead of
hard-coded paths.

For now I have a workaround for the problem in my .vimrc like this:

http://cfc.kizzx2.com/index.php/gvim-e303-unable-to-open-swap-file-for-no-name-r\
ecovery-impossible/

--
You received this message because this project is configured to send all
issue notifications to this address.
You may adjust your notification preferences at:
https://code.google.com/hosting/settings

--
--
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 11:59:48 AM UTC-6, Ulrik wrote:
> 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.
>
>

I kind of like this idea, however, the point of Vim's encryption is not so you
can send somebody a file and have them know it has not been modified. For this,
you would need authentication as you say. The point of Vim's encryption is so
that somebody who somehow gains access to a copy of a sensitive file (or
somebody who hops on your computer while you step out a bit) can't SEE sensitive
data.

If an attacker has write access to your sensitive files, you have other
problems.

--
--
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 Fri, Feb 15, 2013 at 12:47 PM, Ken Takata <kentkt@...> wrote:
>
> Do you enable OLE?  Sorry, I didn't care about that.
> Please try attached patch with an option STATIC_STDCPLUS=yes.
>
>   $ make -f Make_cyg.mak STATIC_STDCPLUS=yes
>
> This option is the same as Make_ming.mak.

This breaks my gui build (gvim.exe) with OLE=yes reporting the
following:

gobj/if_ole.o:if_ole.cpp:(.text+0x1384): undefined reference to
`operator new(unsigned int)'
gobj/if_ole.o:if_ole.cpp:(.text+0x151d): undefined reference to
`operator delete(void*)'
gobj/if_ole.o:if_ole.cpp:(.text+0x1572): undefined reference to
`operator delete(void*)'
gobj/if_ole.o:if_ole.cpp:(.text+0x1593): undefined reference to
`operator new(unsigned int)'
gobj/if_ole.o:if_ole.cpp:(.text+0x1aa0): undefined reference to
`operator new(unsigned int)'
gobj/if_ole.o:if_ole.cpp:(.text+0x1b8e): undefined reference to
`operator delete(void*)'
gobj/if_ole.o:if_ole.cpp:(.text+0x1bad): undefined reference to
`operator delete(void*)'
gobj/if_ole.o:if_ole.cpp:(.text+0x1cd3): undefined reference to
`operator delete(void*)'
gobj/if_ole.o:if_ole.cpp:(.text+0x1cee): undefined reference to
`operator delete(void*)'
gobj/if_ole.o:if_ole.cpp:(.rdata$_ZTI6CVimCF[typeinfo for
CVimCF]+0x0): undefined reference to `vtable for
__cxxabiv1::__si_class_type_info'
gobj/if_ole.o:if_ole.cpp:(.rdata$_ZTI4CVim[typeinfo for CVim]+0x0):
undefined reference to `vtable for __cxxabiv1::__si_class_type_info'
gobj/if_ole.o:if_ole.cpp:(.rdata$_ZTV13IClassFactory[vtable for
IClassFactory]+0x8): undefined reference to `___cxa_pure_virtual'
gobj/if_ole.o:if_ole.cpp:(.rdata$_ZTV13IClassFactory[vtable for
IClassFactory]+0xc): undefined reference to `___cxa_pure_virtual'
gobj/if_ole.o:if_ole.cpp:(.rdata$_ZTV13IClassFactory[vtable for
IClassFactory]+0x10): undefined reference to `___cxa_pure_virtual'
gobj/if_ole.o:if_ole.cpp:(.rdata$_ZTV13IClassFactory[vtable for
IClassFactory]+0x14): undefined reference to `___cxa_pure_virtual'
gobj/if_ole.o:if_ole.cpp:(.rdata$_ZTV13IClassFactory[vtable for
IClassFactory]+0x18): undefined reference to `___cxa_pure_virtual'
gobj/if_ole.o:if_ole.cpp:(.rdata$_ZTV8IUnknown[vtable for
IUnknown]+0x8): more undefined references to `___cxa_pure_virtual'
follow
gobj/if_ole.o:if_ole.cpp:(.rdata$_ZTI13IClassFactory[typeinfo for
IClassFactory]+0x0): undefined reference to `vtable for
__cxxabiv1::__si_class_type_info'
gobj/if_ole.o:if_ole.cpp:(.rdata$_ZTI4IVim[typeinfo for IVim]+0x0):
undefined reference to `vtable for __cxxabiv1::__si_class_type_info'
gobj/if_ole.o:if_ole.cpp:(.rdata$_ZTI8IUnknown[typeinfo for
IUnknown]+0x0): undefined reference to `vtable for
__cxxabiv1::__class_type_info'
gobj/if_ole.o:if_ole.cpp:(.rdata$_ZTI9IDispatch[typeinfo for
IDispatch]+0x0): undefined reference to `vtable for
__cxxabiv1::__si_class_type_info'
collect2: ld returned 1 exit status
Make_cyg.mak:567: recipe for target `gvim.exe' failed
make: *** [gvim.exe] Error 1


--
Steve Hall  [ digitect dancingpaper com ]

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

John Marriott wrote:

> I think there may be a problem with patch 7.3.819 which I got from the
> ftp site. When applying on windows I get:
>
>        # patch --binary -p0
>          <..\patches\7.3.819
>          patching file src/if_py_both.h
>          patching file src/feature.h
>          patching file src/eval.c
>          patching file src/ex_docmd.c
>          patching file src/normal.c
>          patching file src/ex_docmd.c
>          Reversed (or previously applied) patch
>          detected!  Assume -R? [n]
>          Apply anyway? [n]
>          Skipping patch.
>          5 out of 5 hunks ignored -- saving rejects to
>          file src/ex_docmd.c.rej
>          patching file src/gui_gtk_x11.c
>          patching file src/version.c
>
> It seems that the changes for ex_docmd.c are in the patch file twice.
> After removing the second changes from the patch file the patch applies
> cleanly.

You are right, I have corrected the file on the ftp site.

--
Mushrooms always grow in damp places and so they look like umbrellas.

  /// 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 Do, 14 Feb 2013, Bram Moolenaar wrote:
>
> > 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.
>
> Here is a patch

Thanks!

> > Perhaps it can be combined with some other option value that might
> > have changed and require an action after entering another buffer?
>
> Not sure which ones need to be taken care of.

Never mind then.

--
To keep milk from turning sour: Keep it in the cow.

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

Life's been a bit hectic lately (as I'm sure you'd find familiar
:-)), and I haven't had a chance to follow up regarding the
various options for the idea below.  The original patch provided
a Vim option to control the behavior of buffer-local mappings
that have global mappings as prefixes.  The modified patch below
removed the idea of a new Vim option.

If there is anything you'd like me to adjust about either patch
to make the change suitable for inclusion, please let me know.

Thanks,
Michael Henry

On 01/30/2013 09:14 AM, Michael Henry wrote:
> On 01/29/2013 04:33 PM, Bram Moolenaar wrote:
>> I do not like the behavior to depend on timing. I would prefer the
>> local mapping to always take precedence, also when another character was
>> already typed that causes a global mapping to match. Otherwise the
>> behavior depends on how busy your computer is, or the remote connection.
>
> Agreed. The patch eliminates the dependence on timing, which I
> see as a good thing, too.
>
>> Even better would be if we do not need an option at all. Every option
>> makes it more difficult for a Vim user to understand what's happening.
>
> Agreed.
>
>> So would it be "the right thing to do" to always let local mappings
>> overrule any matching global mapping? It's a slightly incompatible
>> change though. But the current behavior is bad enough to accept that
>> (you need to type another chacter to stop waiting for the possibility
>> that the global mapping would match).
>
> I'd be in favor of making the behavior non-optional. Here is a
> modification to the patch that removes the option.
>
> Michael Henry
>
> diff -r 274c841f033a runtime/doc/map.txt
> --- a/runtime/doc/map.txt Fri Jan 25 20:11:01 2013 +0100
> +++ b/runtime/doc/map.txt Wed Jan 30 09:13:18 2013 -0500
> @@ -654,6 +654,18 @@
> you type slowly, or your system is slow, reset the 'timeout' option.
> Then you
> might want to set the 'ttimeout' option.
>
> + *map-precedence*
> +Buffer-local mappings (defined using |:map-<buffer>|) take precedence
over
> +global mappings. When a buffer-local mapping is the same as a global
> mapping,
> +Vim will use the buffer-local mapping. In addition, Vim will use a
> complete
> +buffer-local mapping immediately, even if a longer global mapping has the
> +buffer-local mapping as a prefix. For example, given the following two
> +mappings: >
> + :map <buffer> \a :echo "Local \a"<CR>
> + :map \abc :echo "Global \abc"<CR>
> +The buffer-local mapping \a will be used immediately. Vim will not
> +wait for more characters to see if the user might be typing \abc.
> +
> *map-keys-fails*
> There are situations where key codes might not be recognized:
> - Vim can only read part of the key code. Mostly this is only the first
> diff -r 274c841f033a src/getchar.c
> --- a/src/getchar.c Fri Jan 25 20:11:01 2013 +0100
> +++ b/src/getchar.c Wed Jan 30 09:13:18 2013 -0500
> @@ -1912,6 +1912,7 @@
> mapblock_T *mp;
> #ifdef FEAT_LOCALMAP
> mapblock_T *mp2;
> + int expecting_global_mappings;
> #endif
> mapblock_T *mp_match;
> int mp_match_len = 0;
> @@ -2093,6 +2094,7 @@
> /* First try buffer-local mappings. */
> mp = curbuf->b_maphash[MAP_HASH(local_State, c1)];
> mp2 = maphash[MAP_HASH(local_State, c1)];
> + expecting_global_mappings = (mp && mp2);
> if (mp == NULL)
> {
> mp = mp2;
> @@ -2116,6 +2118,20 @@
> #endif
> (mp = mp->m_next))
> {
> +#ifdef FEAT_LOCALMAP
> + if (expecting_global_mappings && mp2 == NULL)
> + {
> + /*
> + * This is the first global mapping. If we've
> + * got a complete buffer-local match, use it.
> + */
> + if (mp_match)
> + {
> + break;
> + }
> + expecting_global_mappings = FALSE;
> + }
> +#endif
> /*
> * Only consider an entry if the first character
> * matches and it is for the current state.
>


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

2013/02/16 Sat 5:45:48 UTC+9 Steve Hall wrote:

> >
> > Do you enable OLE?  Sorry, I didn't care about that.
> > Please try attached patch with an option STATIC_STDCPLUS=yes.
> >
> >   $ make -f Make_cyg.mak STATIC_STDCPLUS=yes
> >
> > This option is the same as Make_ming.mak.
>
> This breaks my gui build (gvim.exe) with OLE=yes reporting the
> following:

Sorry. There was a mistake in my patch.
I have updated the patch. Please try this.

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

On 2013-02-06 Wednesday at 23:08 +0100 Bram Moolenaar wrote:
> Roland Eggner wrote:
> > > > :mksession writes wrong column number of cursor position in presence of
> > > > multibyte characters.
> > > >
> > > > I have been using vim-7.3.135 with this patch applied for several
> > > > months  … it works for me:
> > >
> > > I do not see the problem.  How to reproduce?
> > >
> > > Your patch can't be right, the "l" command moves over characters, not
> > > columns.
> >
> > Session files created with :mksession restore cursor line and column,
> > as long as there is no multibyte character between start of line and
> > cursor.  Otherwise, without my patch restored column is off by the
> > difference between character position and byte position counted from
> > start of line.
> >
> > With my patch applied, cursor line and column is restored correctly,
> > with and without multibyte characters, with and without changing of
> > options fileencoding or binary, even with files preprocessed by
> > BufRead autocommands gzip -dc, bzip -dc, xz -dc, pdftotext, elinks
> > -dump, antiword, … which I find pretty cool, use and enjoy it nearly
> > every day.
>
> I asked how to reproduce.  I suspect your 'encoding' matters.
> Please start with "vim -u NONE" and check what the default value of
> 'encoding' is then.
>
> Note that your patch most likely is wrong when there is a Tab before the
> cursor, try that.

Indeed, you are right:  my patch beeing wrong was hidden by autocommands
restoring cursor positions based on textmarks.

For investigation of the problem I have created test{91,92}.
In my environment (TERM=linux, unicode-mode) and with locale
en_US.ISO-8859-1 both succeed, whereas with locale en_US.utf8 both fail:


pushd vim-7.3.816
patch -p1 -N -u -i my.patch.provided.below
pushd src/testdir
rm -f test{91,92}.{out,failed,messages}
env {LANG,LC_CTYPE,LC_MESSAGES}=en_US.ISO-8859-1 make -j1

   Test results:
   ALL DONE

grep '[=.]' test91.messages
   LANG=en_US.ISO-8859-1
   LC_MESSAGES=en_US.ISO-8859-1
   LC_ALL=
   test91.in
     fileencoding=utf-8
     termencoding=
     encoding=latin1

grep '[=.]' test92.messages
   LANG=en_US.ISO-8859-1
   LC_MESSAGES=en_US.ISO-8859-1
   LC_ALL=
   test92.in
     fileencoding=latin1
     termencoding=
     encoding=latin1


rm -f test{91,92}.{out,failed,messages}
env {LANG,LC_CTYPE,LC_MESSAGES}=en_US.utf8 make -j1

   Test results:
   test91 FAILED
   test92 FAILED

diff -u test91.{failed,ok}
> --- test91.failed       2013-02-16 01:45:55.979190588 +0100
> +++ test91.ok   2013-02-15 20:36:45.226981063 +0100
> @@ -1,6 +1,6 @@
>  normal! 06l
>  normal! 06l
>  normal! 06l
> -normal! 08l
> -normal! 09l
> -normal! 011l
> +normal! 06l
> +normal! 06l
> +normal! 06l

diff -u test92.{failed,ok}
> --- test92.failed       2013-02-16 01:45:56.363190562 +0100
> +++ test92.ok   2013-02-15 20:36:45.226981063 +0100
> @@ -1,6 +1,6 @@
>  normal! 06l
>  normal! 06l
>  normal! 06l
> -normal! 07l
> -normal! 08l
> -normal! 09l
> +normal! 06l
> +normal! 06l
> +normal! 06l

grep '[=.]' test91.messages
   LANG=en_US.utf8
   LC_MESSAGES=en_US.utf8
   LC_ALL=
   test91.in
     fileencoding=utf-8
     termencoding=
     encoding=utf-8

grep '[=.]' test92.messages
   LANG=en_US.utf8
   LC_MESSAGES=en_US.utf8
   LC_ALL=
   test92.in
     fileencoding=latin1
     termencoding=
     encoding=utf-8

env LC_MESSAGES=C ../vim --version
VIM - Vi IMproved 7.3 (2010 Aug 15, compiled Feb 15 2013 20:37:25)
Included patches: 1-816
Modified by Gentoo-7.3.816-<odvx1@... s/o/e/g>
Compiled by <odvx1@... s/o/e/g>
Huge version without GUI.  Features included (+) or not (-):
-arabic +autocmd -balloon_eval -browse ++builtin_terms +byte_offset +cindent
-clientserver +clipboard +cmdline_compl +cmdline_hist +cmdline_info +comments
+conceal -cryptv +cscope +cursorbind +cursorshape +dialog_con +diff +digraphs
-dnd -ebcdic +emacs_tags +eval +ex_extra +extra_search -farsi +file_in_path
+find_in_path +float +folding -footer +fork() +gettext -hangul_input +iconv
+insert_expand +jumplist +keymap +langmap +libcall +linebreak +lispindent
+listcmds +localmap -lua +menu +mksession +modify_fname +mouse -mouseshape
+mouse_dec -mouse_gpm -mouse_jsbterm +mouse_netterm +mouse_sgr -mouse_sysmouse
+mouse_urxvt +mouse_xterm +multi_byte +multi_lang -mzscheme -netbeans_intg
+path_extra +perl -persistent_undo -printer +profile +python -python3 +quickfix
  +reltime -rightleft -ruby +scrollbind +signs +smartindent -sniff +startuptime
+statusline -sun_workshop +syntax +tag_binary +tag_old_static -tag_any_white
-tcl +terminfo +termresponse +textobjects +title -toolbar +user_commands
+vertsplit +virtualedit +visual +visualextra +viminfo +vreplace +wildignore
+wildmenu +windows +writebackup +X11 +xfontset -xim +xsmp_interact
+xterm_clipboard -xterm_save
    system vimrc file: "/etc/vim/vimrc"
      user vimrc file: "$HOME/.vimrc"
       user exrc file: "$HOME/.exrc"
   fall-back for $VIM: "/usr/share/vim"
Compilation: x86_64-pc-linux-gnu-gcc -c -I. -Iproto -DHAVE_CONFIG_H     -O2
-march=native -pipe -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=1
Linking: x86_64-pc-linux-gnu-gcc   -Wl,-E  -Wl,-O1 -Wl,--as-needed
-L/usr/local/lib -Wl,--as-needed -o vim    -lSM -lICE -lXpm -lXt -lX11 -lXdmcp
-lSM -lICE  -lm   -lcurses -ldl   -Wl,-E -Wl,-O1 -Wl,--as-needed
-L/usr/lib64/perl5/5.12.3/x86_64-linux/CORE -lperl -lnsl -ldl -lm -lcrypt -lutil
-lc -L/usr/lib/python2.7/config -lpython2.7 -lpthread -ldl -lutil -lm -Xlinker
-export-dynamic


-------------------
-- bugreport END --
-------------------

src/testdir/Make_amiga.mak |   4 ++-
src/testdir/Make_dos.mak   |   2 +-
src/testdir/Make_ming.mak  |   2 +-
src/testdir/Make_os2.mak   |   2 +-
src/testdir/Make_vms.mms   |   2 +-
src/testdir/Makefile       |   8 +++---
src/testdir/test91.in      |  50 ++++++++++++++++++++++++++++++++++++++++++++++
src/testdir/test91.ok      |   6 +++++
src/testdir/test92.in      |  50 ++++++++++++++++++++++++++++++++++++++++++++++
src/testdir/test92.ok      |   6 +++++
10 files changed, 123 insertions(+), 9 deletions(-)

-------------------------------------------------------------
-- patch START -- when read by vim, binary mode  __REQUIRED__
-------------------------------------------------------------
>From: Roland Eggner <edvx1@...>
test if :mksession saves cursor columns correctly in presence of tab and
multibyte characters

diff --git a/src/testdir/Make_amiga.mak b/src/testdir/Make_amiga.mak
--- a/src/testdir/Make_amiga.mak
+++ b/src/testdir/Make_amiga.mak
@@ -32,7 +32,7 @@ SCRIPTS = test1.out test3.out test4.out
 		 test71.out test72.out test73.out test74.out test75.out \
 		 test76.out test77.out test78.out test79.out test80.out \
 		 test81.out test82.out test83.out test84.out test88.out \
-  test89.out test90.out
+  test89.out test90.out test91.out test92.out

  .SUFFIXES: .in .out

@@ -139,3 +139,5 @@ test84.out: test84.in
  test88.out: test88.in
  test89.out: test89.in
  test90.out: test90.in
+test91.out: test91.in
+test92.out: test92.in
diff --git a/src/testdir/Make_dos.mak b/src/testdir/Make_dos.mak
--- a/src/testdir/Make_dos.mak
+++ b/src/testdir/Make_dos.mak
@@ -31,7 +31,7 @@ SCRIPTS = test3.out test4.out test5.out
 		 test74.out test75.out test76.out test77.out test78.out \
 		 test79.out test80.out test81.out test82.out test83.out \
 		 test84.out test85.out test86.out test87.out test88.out \
-  test89.out test90.out
+  test89.out test90.out test91.out test92.out

  SCRIPTS32 = test50.out test70.out

diff --git a/src/testdir/Make_ming.mak b/src/testdir/Make_ming.mak
--- a/src/testdir/Make_ming.mak
+++ b/src/testdir/Make_ming.mak
@@ -51,7 +51,7 @@ SCRIPTS = test3.out test4.out test5.out
 		 test74.out test75.out test76.out test77.out test78.out \
 		 test79.out test80.out test81.out test82.out test83.out \
 		 test84.out test85.out test86.out test87.out test88.out \
-  test89.out test90.out
+  test89.out test90.out test91.out test92.out

  SCRIPTS32 = test50.out test70.out

diff --git a/src/testdir/Make_os2.mak b/src/testdir/Make_os2.mak
--- a/src/testdir/Make_os2.mak
+++ b/src/testdir/Make_os2.mak
@@ -32,7 +32,7 @@ SCRIPTS = test1.out test3.out test4.out
 		 test71.out test72.out test73.out test74.out test75.out \
 		 test76.out test77.out test78.out test79.out test80.out \
 		 test81.out test82.out test83.out test84.out test88.out \
-  test89.out test90.out
+  test89.out test90.out test91.out test92.out

  .SUFFIXES: .in .out

diff --git a/src/testdir/Make_vms.mms b/src/testdir/Make_vms.mms
--- a/src/testdir/Make_vms.mms
+++ b/src/testdir/Make_vms.mms
@@ -77,7 +77,7 @@ SCRIPT = test1.out  test2.out  test3.out
 	  test71.out test72.out test74.out test75.out test76.out \
 	  test77.out test78.out test79.out test80.out test81.out \
 	  test82.out test83.out test84.out test88.out test89.out \
-  test90.out
+  test90.out test91.out test92.out

  # Known problems:
  # Test 30: a problem around mac format - unknown reason
diff --git a/src/testdir/Makefile b/src/testdir/Makefile
--- a/src/testdir/Makefile
+++ b/src/testdir/Makefile
@@ -28,7 +28,7 @@ SCRIPTS = test1.out test2.out test3.out
 		 test74.out test75.out test76.out test77.out test78.out \
 		 test79.out test80.out test81.out test82.out test83.out \
 		 test84.out test85.out test86.out test87.out test88.out \
-  test89.out test90.out
+  test89.out test90.out test91.out test92.out

  SCRIPTS_GUI = test16.out

@@ -58,7 +58,7 @@ clean:
  test1.out: test1.in
 	 -rm -rf $*.failed $(RM_ON_RUN) $(RM_ON_START)
 	 $(RUN_VIM) $*.in
- @/bin/sh -c "if diff test.out $*.ok; \
+ @/bin/sh -c "if diff -u test.out $*.ok; \
 		 then mv -f test.out $*.out; \
 		 else echo; \
 		 echo test1 FAILED - Something basic is wrong; \
@@ -74,7 +74,7 @@ test1.out: test1.in

 	 # For flaky tests retry one time.
 	 @/bin/sh -c "if test -f test.out -a $* = test61; then \
- 	  if diff test.out $*.ok; \
+ 	  if diff -u test.out $*.ok; \
 		   then echo flaky test ok first time; \
 		   else rm -rf $*.failed $(RM_ON_RUN); \
 			 $(RUN_VIM) $*.in; \
@@ -83,7 +83,7 @@ test1.out: test1.in

 	 # Check if the test.out file matches test.ok.
 	 @/bin/sh -c "if test -f test.out; then\
- 	  if diff test.out $*.ok; \
+ 	  if diff -u test.out $*.ok; \
 		   then mv -f test.out $*.out; \
 		   else echo $* FAILED >>test.log; mv -f test.out $*.failed; \
 		   fi \
diff --git a/src/testdir/test91.in b/src/testdir/test91.in
new file mode 100644
--- /dev/null
+++ b/src/testdir/test91.in
@@ -0,0 +1,50 @@
+vim: set ft=vim fenc=utf-8:
+
+Tests if :mksession saves cursor columns correctly in presence of tab and
+multibyte characters when fileencoding=utf-8.
+
+STARTTEST
+:so mbyte.vim
+:if !has('mksession')
+   e! test.ok
+   wq! test.out
+:endif
+:set sessionoptions=buffers splitbelow fileencoding=utf-8
+:" debugging stuff START
+:redir > test91.messages
+:echo 'LANG=' . ( exists('$LANG') ? $LANG : '' )
+:echo 'LC_MESSAGES=' . ( exists('$LC_MESSAGES') ? $LC_MESSAGES : '' )
+:echo 'LC_ALL=' . ( exists('$LC_ALL') ? $LC_ALL : '' )
+:echo bufname('%')
+:set fileencoding? termencoding? encoding?
+:redir END
+:" debugging stuff END
+:" Start test.  For each of 6 test text lines create another window and
position
+:" the cursor at column 7.  Session file written by :mksession must contain six
+:" lines “normal! 06l”, we delete deviating lines and save result as
“test.out”.
+:" For debugging purpose additionally report &{file,term,}encoding.
+/^start:
+:normal j06l
+:split
+:normal j06l
+:split
+:normal j06l
+:split
+:normal j06l
+:split
+:normal j06l
+:split
+:normal j06l
+:mksession! test.out
+:e! test.out
+:v/^normal! 0/d
+:wqa!
+ENDTEST
+
+start:
+no multibyte character
+ one tab
+two  tabs
+one … multibyte character
+a “b” two multibyte characters
+“c”1€ three multibyte characters
diff --git a/src/testdir/test91.ok b/src/testdir/test91.ok
new file mode 100644
--- /dev/null
+++ b/src/testdir/test91.ok
@@ -0,0 +1,6 @@
+normal! 06l
+normal! 06l
+normal! 06l
+normal! 06l
+normal! 06l
+normal! 06l
diff --git a/src/testdir/test92.in b/src/testdir/test92.in
new file mode 100644
--- /dev/null
+++ b/src/testdir/test92.in
@@ -0,0 +1,50 @@
+vim: set ft=vim fenc=latin1:
+
+Tests if :mksession saves cursor columns correctly in presence of tab and
+multibyte characters when fileencoding=latin1.
+
+STARTTEST
+:so mbyte.vim
+:if !has('mksession')
+   e! test.ok
+   wq! test.out
+:endif
+:set sessionoptions=buffers splitbelow fileencoding=latin1
+:" debugging stuff START
+:redir > test92.messages
+:echo 'LANG=' . ( exists('$LANG') ? $LANG : '' )
+:echo 'LC_MESSAGES=' . ( exists('$LC_MESSAGES') ? $LC_MESSAGES : '' )
+:echo 'LC_ALL=' . ( exists('$LC_ALL') ? $LC_ALL : '' )
+:echo bufname('%')
+:set fileencoding? termencoding? encoding?
+:redir END
+:" debugging stuff END
+:" Start test.  For each of 6 test text lines create another window and
position
+:" the cursor at column 7.  Session file written by :mksession must contain six
+:" lines 'normal! 06l', we delete deviating lines and save result as
'test.out'.
+:" For debugging purpose additionally report &{file,term,}encoding.
+/^start:
+:normal j06l
+:split
+:normal j06l
+:split
+:normal j06l
+:split
+:normal j06l
+:split
+:normal j06l
+:split
+:normal j06l
+:mksession! test.out
+:e! test.out
+:v/^normal! 0/d
+:wqa!
+ENDTEST
+
+start:
+no multibyte character
+ one tab
+two  tabs
+one � multibyte character
+a� �  two multibyte characters
+A���  three multibyte characters
diff --git a/src/testdir/test92.ok b/src/testdir/test92.ok
new file mode 100644
--- /dev/null
+++ b/src/testdir/test92.ok
@@ -0,0 +1,6 @@
+normal! 06l
+normal! 06l
+normal! 06l
+normal! 06l
+normal! 06l
+normal! 06l

--
Roland Eggner

Status: New
Owner: ----
Labels: Type-Defect Priority-Medium

New issue 109 by bland...@...: src/Make_mvc.mak fails for quoted
values of SDK_INCLUDE_DIR
http://code.google.com/p/vim/issues/detail?id=109

using msvs 2012 express for desktop
nmake version 11.00.51106.1

while following the instructions on lines 18-19 of src/Make_mvc.mak causes
nmake to complain and result in a fatal error. i eventually found putting
quotes in the var SDK_INCLUDE_DIR to be the culprit.

e:\projects\vim\src>set SDK_INCLUDE_DIR="C:\Program Files (x86)\Microsoft
SDKs\Windows\v7.1\Include"

removing the quotes enables everything to work fine but feels a little
scary. an alternative is to make use of nmake's INCLUDE macro:

INCLUDE=$(SDK_INCLUDE_DIR);$(INCLUDE)

then use angle brackets as usual:

!include <Win32.mak>

this works great but the INCLUDE macro will also need to be updated in
GvimExt Makefile as well if it is desired to build GvimExt on its own and
that could result in some weirdness since you'll be duplicating the
SDK_INCLUDE_DIR in nmakes INCLUDE paths.

attached is a diff with these changes to the makefiles and including an
additional .bat for setting the msvs 2012 environment.

Attachments:
	 msvs_2012_makefile_updates.diff  1.1 KB

--
You received this message because this project is configured to send all
issue notifications to this address.
You may adjust your notification preferences at:
https://code.google.com/hosting/settings

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