On 17:56 Sun 04 Nov     , Tony Mechelynck wrote:
> On 04/11/12 11:06, Marcin Szamotulski wrote:
> > On 23:40 Sat 03 Nov     , Chris Lott wrote:
> >> Currently running:
> >>
> >>      VIM - Vi IMproved 7.3 (2010 Aug 15, compiled Sep  1 2012 18:08:47)
> >>      MacOS X (unix) version
> >>      Included patches: 1-646
> >>      Compiled by Bjorn Winckler <bjorn.winckler@...>
> >>
> >> I have these lines in my .vimrc
> >>
> >>      if has("gui_macvim")
> >>        source ~/.vim/vimrc/mygfuncs.vim
> >>      endif
> >>
> >> In the mygfuncs file are some functions that set the `guitablabel` and
> >> `guitabtooltip` based on two custom functions. The file is being
> >> sourced (because the functions are defined), but the lines that set
> >> those variables using those functions aren't working:
> >>
> >>      set guitabtooltip=%{GuiTabToolTip()}
> >>      set guitablabel=%{GuiTabLabel()}
> >>
> >> At this point, the variables are set properly, because if I
> >>
> >>      :set guitabtooltip
> >>
> >> Vim responds with
> >>
> >>      guitabtooltip=%{GuiTabToolTip()}
> >>
> >> But it isn't actually being applied.
> >>
> >> **But** if I then `:so ~/.vimrc`, the tab label and tooltips *are* applied.
> >>
> >> What is going on here?
> >>
> >> c
> >> --
> >> Chris Lott <chris@...>
> >>
> >> --
> >> You received this message from the "vim_use" 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
> >
> > The way to set an option from a value returned by a function is:
> >
> >      let &guitabltooltip=GuiTabToolTip()
> >
> > if you want to set local value (like setlocal does) you could use:
> >
> >      let &l:guitabtooltip=GuiTabToolTip()
> >
> > You can read about it in ":help :let-&".  You can also use the short
> > name of an option.  &guitabtooltip is just a VimL variable.  There is
> > also &g:guitabtooltip which will work like using the :setglobal command.
> >
> > Best,
> > Marcin
> >
> No, :set guitablabel=%{GuiTabLabel()} is actually the example given
> under :help 'guitablabel' so that the function is calculated every time
> Vim tries to display the GUI tabs. Using :let &guitablabel =
> GuiTabLabel() would calculate the function just once, when setting the
> option.
>
> For GUI tabs to be displayed, you need the e flag in 'guioptions'. Also,
> the value of 'showtabline' is relevant:
>  0  Never
>  1  (default) Only if there are two or more tab pages
>  2  Always
>
> If 'showtabline' is nonzero and 'guioptions' does not contain e you'll
> get text-style tabs as defined by the 'tabline' option, even in GUI mode.
>
> If these options are set correctly and you still don't see the tabs,
> then another possibility is that Vim would set 'guitablabel' and
> 'guitabtooltip' to some default (or empty) value at GUI startup. To
> counteract this, you can set them at the GUIEnter autocommand event:
>
> if has('gui') && has('autocmd') && has('windows')
>      au GUIEnter * set gtl=%{GuiTabLabel()} gtt=%{GuiTabTooltip()}
> endif
>
>
> Best regards,
> Tony.
> --
> Mother told me to be good, but she's been wrong before.

Tony is right! ":help setting-guitablabel" is the exact reference.

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

Andy Wokula wrote:

> Looks like split() never ignores case:
>      :set ic
>      :echo split('abcABC', 'b')
>      ['a', 'cABC']
>
> but this is not mentioned in
>      :h split()
>
> What about adding a line (taken from :h :helpgrep):
>      'ignorecase' is not used, add "\c" to ignore case.

I'll add something like that.

--
hundred-and-one symptoms of being an internet addict:
17. You turn on your intercom when leaving the room so you can hear if new
     e-mail arrives.

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

Comment #7 on issue 71 by shlomif@...: gvim over ssh features undrawn
characters
http://code.google.com/p/vim/issues/detail?id=71

Update: now that I upgraded my laptop to Mageia Cauldron (the Mageia
development distribution that is going to be Mageia 3), I can no longer
reproduce this problem. As far as I am concerned, it can be closed, but you
may wish to investigate this problem in order to prevent future users
running into it and reporting it.

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

Hi

Here are more signed int overflows with undefined behavior
discovered with the IOC tool (http://embed.cs.utah.edu/ioc/):

CLANG ARITHMETIC UNDEFINED at <move.c, (2591:12)> : Op: +, Reason :
Signed Addition Overflow, BINARY OPERATION: left (int32): 2147483647
right (int32): 1

CLANG ARITHMETIC UNDEFINED at <move.c, (2603:12)> : Op: +, Reason :
Signed Addition Overflow, BINARY OPERATION: left (int32): 2147483647
right (int32): 2147483647

CLANG ARITHMETIC UNDEFINED at <move.c, (2603:41)> : Op: +, Reason :
Signed Addition Overflow, BINARY OPERATION: left (int32): 2147483647
right (int32): 1

I can reproduce these overflows as follows:

$ yes 1 | head -5 > 1
$ yes 2 | head -5 > 2
$ vim -u NONE -c 'set wrap' -d 1 2

Then press <PgDown> followed by <PgUp> and the overflow happens.

Even assuming a two's complement representation of
signed value, I think that code is still wrong here:

move.c:

2591     if (h3 + h2 > min_height)
2592     {
2593         *lp = loff0;    /* no overlap */
2594         return;
2595     }

h3 and/or h2 are signed int variables. They can be
equal to MAXCOL (0x7fffffffL).  So the addition
at line 2591 can overflow giving in general a negative
value (but in theory behavior is undefined for signed
int overflows). The intention of MAXCOL here was
behave as a large height.

Attached patch fixes it but please review it.

IOC tool no longer complains with the patch.

Regards
-- Dominique

--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

Comment #1 on issue 77 by esw...@...: [patch] Non-empty file without
EOL markers should use default fileformat instead of mac.
http://code.google.com/p/vim/issues/detail?id=77

Revised reproduction steps:

1. echo -n "set ffs=unix,dos,mac" > oneline.txt
2. vim -u oneline.txt oneline.txt
3. set ff?

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

Hi,

Could you please include the Dungeon Crawl syntax file with Vim?

URL: 
<http://gitorious.org/crawl/crawl/blobs/master/crawl-ref/source/dat/vim/syntax/l\
evdes.vim>.

License:  GPL v2 or later.  See
<http://gitorious.org/crawl/crawl/blobs/master/crawl-ref/licence.txt>.

Maintainer:  Darshan Shaligram <scintilla at gmail.com>.

P.S.  I thank you all for writing/developing Vim.

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

Hello Dominique,

On Mon, Nov 5, 2012 at 8:40 PM, Dominique Pellé
<dominique.pelle@...> wrote:

> Attached patch fixes it but please review it.

This part of the diff looks off to me:

-    if (h4 + h3 + h2 > min_height || h3 + h2 + h1 > min_height)
+    if (h4 == MAXCOL + h4 + h3 + h2 > min_height || h3 + h2 + h1 > min_height)

You probably meant 'h4 == MAXCOL || h4 + h3 + h2 > min_height' here?

Christ van Willegen
--
09 F9 11 02 9D 74 E3 5B D8 41 56 C5 63 56 88 C0

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

Christ van Willegen wrote:

> Hello Dominique,
>
> On Mon, Nov 5, 2012 at 8:40 PM, Dominique Pellé
> <dominique.pelle@...> wrote:
>
>> Attached patch fixes it but please review it.
>
> This part of the diff looks off to me:
>
> -    if (h4 + h3 + h2 > min_height || h3 + h2 + h1 > min_height)
> +    if (h4 == MAXCOL + h4 + h3 + h2 > min_height || h3 + h2 + h1 >
min_height)
>
> You probably meant 'h4 == MAXCOL || h4 + h3 + h2 > min_height' here?
>
> Christ van Willegen

Thanks for spotting it. You are of course right.
Attached is the updated patch.

-- Dominique

--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

Hi,

This is a feature request to be able to read and write .svgz files.

It is already possible to read/write *.txt.gz files.
It is already possible to read/write .svg files.
It is already possible to read/write .svg.gz files, but .svg files that are
compressed with gzip don't have .svg.gz file extension but .svgz.

Thanks!

Une messagerie gratuite, garantie à vie et des services en plus, ça vous tente ?
Je crée ma boîte mail www.laposte.net

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

Dominique Pelle wrote:

> I ran "make test" with vim-7.3.712 compiled with IOC
> (http://embed.cs.utah.edu/ioc/), a tool that detects integer
> overflows, which behave in undefined way according to
> the C standard.  Only unsigned integer is guaranteed to
> behave in a predictable way. IOC found a few bugs:

The actual problem is in the standard.  Having integer operations behave
in an undefined way is not very useful.  They should have defined
uniform behavior.  It's the compiler writers who like these things to be
undefined, not the users.

> CLANG ARITHMETIC UNDEFINED at <hashtab.c, (179:25)> : Op: +, Reason :
> Signed Addition Overflow, BINARY OPERATION: left (int32): 2140052020
> right (int32): 1608754829
>
> CLANG ARITHMETIC UNDEFINED at <misc2.c, (4005:36)> : Op: *, Reason :
> Signed Multiplication Overflow, BINARY OPERATION: left (int32): 64087
> right (int32): 64086CLANG ARITHMETIC UNDEFINED at <misc2.c, (3981:6)>
> : Op: *, Reason : Signed Multiplication Overflow, BINARY OPERATION:
> left (
>
> CLANG ARITHMETIC UNDEFINED at <misc2.c, (3981:6)> : Op: *, Reason :
> Signed Multiplication Overflow, BINARY OPERATION: left (int32): 64087
> right (int32): 64086
>
> Attached patch fixes them.

Thanks, I'll add it to the todo list.

> There is one more undefined behavior operation (float divide by 0
> which is also undefined in C). Fixing it would require to use the
> INFINITY macro I think but it's C99 macro and Vim needs to compile on
> older compilers so I did not fix it:

Undefined?  I thought divide by zero always results in INF.  What
compiler does otherwise?

> CLANG ARITHMETIC UNDEFINED at <eval.c, (4901:15)> : Op: /, Reason :
> Floating Division: Divisor is 0, BINARY OPERATION: left (double):
> 1.000000 right (double): 0.000000
>
> It could be fixed by checking for INFINITY in autoconf.
>
> There might be more of such bugs: IOC is runtime checker so it only
> checked what was executed while running "make test".

These might not be bugs, compilers often do more sensible things than
what C99 defines.  C99 is not a very good standard, it drifted away from
the goal to make the language more useful for programmers.

Although such a tool can find possible problems, there would also need
to be a compiler that actually does something wrong with the code.


--
hundred-and-one symptoms of being an internet addict:
21. Your dog has its own home page.

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

Dominique Pelle wrote:

> Here are more signed int overflows with undefined behavior
> discovered with the IOC tool (http://embed.cs.utah.edu/ioc/):
>
> CLANG ARITHMETIC UNDEFINED at <move.c, (2591:12)> : Op: +, Reason :
> Signed Addition Overflow, BINARY OPERATION: left (int32): 2147483647
> right (int32): 1
>
> CLANG ARITHMETIC UNDEFINED at <move.c, (2603:12)> : Op: +, Reason :
> Signed Addition Overflow, BINARY OPERATION: left (int32): 2147483647
> right (int32): 2147483647
>
> CLANG ARITHMETIC UNDEFINED at <move.c, (2603:41)> : Op: +, Reason :
> Signed Addition Overflow, BINARY OPERATION: left (int32): 2147483647
> right (int32): 1
>
> I can reproduce these overflows as follows:
>
> $ yes 1 | head -5 > 1
> $ yes 2 | head -5 > 2
> $ vim -u NONE -c 'set wrap' -d 1 2
>
> Then press <PgDown> followed by <PgUp> and the overflow happens.
>
> Even assuming a two's complement representation of
> signed value, I think that code is still wrong here:
>
> move.c:
>
> 2591     if (h3 + h2 > min_height)
> 2592     {
> 2593         *lp = loff0;    /* no overlap */
> 2594         return;
> 2595     }
>
> h3 and/or h2 are signed int variables. They can be
> equal to MAXCOL (0x7fffffffL).  So the addition
> at line 2591 can overflow giving in general a negative
> value (but in theory behavior is undefined for signed
> int overflows). The intention of MAXCOL here was
> behave as a large height.
>
> Attached patch fixes it but please review it.
>
> IOC tool no longer complains with the patch.

Thanks, I'll add this to the todo list.

--
Shift happens.
                 -- Doppler

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

Bram,
there seems to be a problem with backslash escaped strings when using
expand(), glob() or globpath():

#v+
cb@host: mkdir -p /tmp/test
ch@host: touch /tmp/test/bar /tmp/teest/foo\\1
cb@host: vim -u NONE -U NONE -N -c ':e /tmp/test/bar|echo
expand(@#)|echo expand("#")' /tmp/test/foo\\1
#v-

This outputs:
"/tmp/test/bar" 0L, 0C
test/foo1
test/foo\1

The problem is, you can't rely on expand() to skip one backslash,
because on Windows it behaves correctly (e.g. expand('foobar\1') on
Windows returns 'foobar\1' while on Unixs returns 'foobar1').

Also, you can't use glob('/tmp/test/foo\\1') to return the correct
result, and if you use glob(expand(path)) where path contains a
backslash, glob() won't return the empty string.

This is problematic because glob() is mentioned below :h filereadable()
to check for the existence of a file.

Here is a patch, that fixes this problematic behaviour and makes it at
least consistent to the Windows behaviour. But ... it is a backward
incompatible change and probably breaks a lot of plugins, that work
around that bug by using something like

if glob(expand(escape(filename, '\\')))
      " file exists
      …
else
      " create file
      …
endif

Nevertheless, I tend to consider this as a bug and would like it to work
consistently on all plattforms.

regards,
Christian
--

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

Hello Bram,
hello folks, (cc'ing vim dev)

if this already has been discussed excuse me.
Some time ago we had a discussion about how to handle specific settings in Vim
the correct way.
Now some time later i think i have a approach that could be of some use in this
regard.
example code follows:

^-------------------------------------------------------------------------------
" Make sure compatible-options is [re]set to vim defaults.
" Vim default: "aABceFs". Commas can be added for readability.
   set cpo&vim

" set cpo to your likings e.g:
   set cpo+=y

   if exists("g:global_cpoptions_save")
     unlockvar g:global_cpoptions_save
   endif
   let g:global_cpoptions_save = &cpo
   lockvar g:global_cpoptions_save
   autocmd SourcePre  *  let &cpo = g:global_cpoptions_save
		     \|  set isfname&vim
		     \|  set isident&vim
		     \|  set iskeyword&vim
		     \|  set isprint&vim

^-------------------------------------------------------------------------------

Now this code isn't perfect neither as all other aproaches. Still it has
benefits:
parallelises instead of serialisation, means:
The current approach of handling cpo serialize each and every runtime file.
Results: if only one of the runtime files handles cpo wrongly the whole process
will fail resulting in non wanted cpo settings at runtime (note some runtime
files even modify cpo on their own and cpo is global only).
With the approach above each runtime file will get the same terms at startup and
the whole process will only fail, if the LAST runtime file being processed
breaks.
IMHO this lifts much of the burden.

Now if we only had a 'au SourcePost'.....

--
Regards,
Thilo

4096R/0xC70B1A8F
721B 1BA0 095C 1ABA 3FC6  7C18 89A4 A2A0 C70B 1A8F


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

Jason Spiro wrote:

> Could you please include the Dungeon Crawl syntax file with Vim?
>
> URL: 
<http://gitorious.org/crawl/crawl/blobs/master/crawl-ref/source/dat/vim/syntax/l\
evdes.vim>.
>
> License:  GPL v2 or later.  See
<http://gitorious.org/crawl/crawl/blobs/master/crawl-ref/licence.txt>.
>
> Maintainer:  Darshan Shaligram <scintilla at gmail.com>.

I normally expect the author or maintainer of the file to email it to
me.  That way it is clear what version is to be distributed.

We prefer using the Vim license, so that all of the runtime files can be
distributed under the same license.  Dual-licencing, both GPL and the
Vim license is fine (the Vim license itself is also dual-licensed with
GPL).


--
hundred-and-one symptoms of being an internet addict:
22. You've already visited all the links at Yahoo and you're halfway through
     Lycos.

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

Dominique Pelle wrote:

> I ran "make test" with vim-7.3.712 compiled with IOC
> (http://embed.cs.utah.edu/ioc/), a tool that detects integer
> overflows, which behave in undefined way according to
> the C standard.  Only unsigned integer is guaranteed to
> behave in a predictable way. IOC found a few bugs:

The actual problem is in the standard.  Having integer operations behave
in an undefined way is not very useful.  They should have defined
uniform behavior.  It's the compiler writers who like these things to be
undefined, not the users.

> CLANG ARITHMETIC UNDEFINED at <hashtab.c, (179:25)> : Op: +, Reason :
> Signed Addition Overflow, BINARY OPERATION: left (int32): 2140052020
> right (int32): 1608754829
>
> CLANG ARITHMETIC UNDEFINED at <misc2.c, (4005:36)> : Op: *, Reason :
> Signed Multiplication Overflow, BINARY OPERATION: left (int32): 64087
> right (int32): 64086CLANG ARITHMETIC UNDEFINED at <misc2.c, (3981:6)>
> : Op: *, Reason : Signed Multiplication Overflow, BINARY OPERATION:
> left (
>
> CLANG ARITHMETIC UNDEFINED at <misc2.c, (3981:6)> : Op: *, Reason :
> Signed Multiplication Overflow, BINARY OPERATION: left (int32): 64087
> right (int32): 64086
>
> Attached patch fixes them.

Thanks, I'll add it to the todo list.

> There is one more undefined behavior operation (float divide by 0
> which is also undefined in C). Fixing it would require to use the
> INFINITY macro I think but it's C99 macro and Vim needs to compile on
> older compilers so I did not fix it:

Undefined?  I thought divide by zero always results in INF.  What
compiler does otherwise?

> CLANG ARITHMETIC UNDEFINED at <eval.c, (4901:15)> : Op: /, Reason :
> Floating Division: Divisor is 0, BINARY OPERATION: left (double):
> 1.000000 right (double): 0.000000
>
> It could be fixed by checking for INFINITY in autoconf.
>
> There might be more of such bugs: IOC is runtime checker so it only
> checked what was executed while running "make test".

These might not be bugs, compilers often do more sensible things than
what C99 defines.  C99 is not a very good standard, it drifted away from
the goal to make the language more useful for programmers.

Although such a tool can find possible problems, there would also need
to be a compiler that actually does something wrong with the code.


--
hundred-and-one symptoms of being an internet addict:
21. Your dog has its own home page.

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

Dominique Pelle wrote:

> Here are more signed int overflows with undefined behavior
> discovered with the IOC tool (http://embed.cs.utah.edu/ioc/):
>
> CLANG ARITHMETIC UNDEFINED at <move.c, (2591:12)> : Op: +, Reason :
> Signed Addition Overflow, BINARY OPERATION: left (int32): 2147483647
> right (int32): 1
>
> CLANG ARITHMETIC UNDEFINED at <move.c, (2603:12)> : Op: +, Reason :
> Signed Addition Overflow, BINARY OPERATION: left (int32): 2147483647
> right (int32): 2147483647
>
> CLANG ARITHMETIC UNDEFINED at <move.c, (2603:41)> : Op: +, Reason :
> Signed Addition Overflow, BINARY OPERATION: left (int32): 2147483647
> right (int32): 1
>
> I can reproduce these overflows as follows:
>
> $ yes 1 | head -5 > 1
> $ yes 2 | head -5 > 2
> $ vim -u NONE -c 'set wrap' -d 1 2
>
> Then press <PgDown> followed by <PgUp> and the overflow happens.
>
> Even assuming a two's complement representation of
> signed value, I think that code is still wrong here:
>
> move.c:
>
> 2591     if (h3 + h2 > min_height)
> 2592     {
> 2593         *lp = loff0;    /* no overlap */
> 2594         return;
> 2595     }
>
> h3 and/or h2 are signed int variables. They can be
> equal to MAXCOL (0x7fffffffL).  So the addition
> at line 2591 can overflow giving in general a negative
> value (but in theory behavior is undefined for signed
> int overflows). The intention of MAXCOL here was
> behave as a large height.
>
> Attached patch fixes it but please review it.
>
> IOC tool no longer complains with the patch.

Thanks, I'll add this to the todo list.

--
Shift happens.
                 -- Doppler

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

On Wed, 07 Nov 2012 16:04:41 +0100, Bram Moolenaar
<Bram@...> wrote:

> Dominique Pelle wrote:
>
> > I ran "make test" with vim-7.3.712 compiled with IOC
> > (http://embed.cs.utah.edu/ioc/), a tool that detects integer
> > overflows, which behave in undefined way according to
> > the C standard.  Only unsigned integer is guaranteed to
> > behave in a predictable way. IOC found a few bugs:
>
> The actual problem is in the standard.  Having integer operations behave
> in an undefined way is not very useful.  They should have defined
> uniform behavior.  It's the compiler writers who like these things to be
> undefined, not the users.

It's useful because the alternative would require the compiler to
check for overflow after every operation if the underlying hardware
behaved differently from the standard. Almost from the beginning it
was C's policy to prefer efficiency and put the burden of avoiding
non-portable behaviour on the programmer rather than slow everything
down by checking things that rarely matter.

> > There is one more undefined behavior operation (float divide by 0
> > which is also undefined in C). Fixing it would require to use the
> > INFINITY macro I think but it's C99 macro and Vim needs to compile on
> > older compilers so I did not fix it:
>
> Undefined?  I thought divide by zero always results in INF.  What
> compiler does otherwise?

I think it depends on the floating-point hardware, if there is any.
I remember hearing of systems that didn't have Inf or NaN but I don't
remember using one myself.

--
Matthew Winn

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

Dominique Pelle wrote:

> I ran "make test" with vim-7.3.712 compiled with IOC
> (http://embed.cs.utah.edu/ioc/), a tool that detects integer
> overflows, which behave in undefined way according to
> the C standard.  Only unsigned integer is guaranteed to
> behave in a predictable way. IOC found a few bugs:

The actual problem is in the standard.  Having integer operations behave
in an undefined way is not very useful.  They should have defined
uniform behavior.  It's the compiler writers who like these things to be
undefined, not the users.

> CLANG ARITHMETIC UNDEFINED at <hashtab.c, (179:25)> : Op: +, Reason :
> Signed Addition Overflow, BINARY OPERATION: left (int32): 2140052020
> right (int32): 1608754829
>
> CLANG ARITHMETIC UNDEFINED at <misc2.c, (4005:36)> : Op: *, Reason :
> Signed Multiplication Overflow, BINARY OPERATION: left (int32): 64087
> right (int32): 64086CLANG ARITHMETIC UNDEFINED at <misc2.c, (3981:6)>
> : Op: *, Reason : Signed Multiplication Overflow, BINARY OPERATION:
> left (
>
> CLANG ARITHMETIC UNDEFINED at <misc2.c, (3981:6)> : Op: *, Reason :
> Signed Multiplication Overflow, BINARY OPERATION: left (int32): 64087
> right (int32): 64086
>
> Attached patch fixes them.

Thanks, I'll add it to the todo list.

> There is one more undefined behavior operation (float divide by 0
> which is also undefined in C). Fixing it would require to use the
> INFINITY macro I think but it's C99 macro and Vim needs to compile on
> older compilers so I did not fix it:

Undefined?  I thought divide by zero always results in INF.  What
compiler does otherwise?

> CLANG ARITHMETIC UNDEFINED at <eval.c, (4901:15)> : Op: /, Reason :
> Floating Division: Divisor is 0, BINARY OPERATION: left (double):
> 1.000000 right (double): 0.000000
>
> It could be fixed by checking for INFINITY in autoconf.
>
> There might be more of such bugs: IOC is runtime checker so it only
> checked what was executed while running "make test".

These might not be bugs, compilers often do more sensible things than
what C99 defines.  C99 is not a very good standard, it drifted away from
the goal to make the language more useful for programmers.

Although such a tool can find possible problems, there would also need
to be a compiler that actually does something wrong with the code.


--
hundred-and-one symptoms of being an internet addict:
21. Your dog has its own home page.

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

Dominique Pelle wrote:

> Here are more signed int overflows with undefined behavior
> discovered with the IOC tool (http://embed.cs.utah.edu/ioc/):
>
> CLANG ARITHMETIC UNDEFINED at <move.c, (2591:12)> : Op: +, Reason :
> Signed Addition Overflow, BINARY OPERATION: left (int32): 2147483647
> right (int32): 1
>
> CLANG ARITHMETIC UNDEFINED at <move.c, (2603:12)> : Op: +, Reason :
> Signed Addition Overflow, BINARY OPERATION: left (int32): 2147483647
> right (int32): 2147483647
>
> CLANG ARITHMETIC UNDEFINED at <move.c, (2603:41)> : Op: +, Reason :
> Signed Addition Overflow, BINARY OPERATION: left (int32): 2147483647
> right (int32): 1
>
> I can reproduce these overflows as follows:
>
> $ yes 1 | head -5 > 1
> $ yes 2 | head -5 > 2
> $ vim -u NONE -c 'set wrap' -d 1 2
>
> Then press <PgDown> followed by <PgUp> and the overflow happens.
>
> Even assuming a two's complement representation of
> signed value, I think that code is still wrong here:
>
> move.c:
>
> 2591     if (h3 + h2 > min_height)
> 2592     {
> 2593         *lp = loff0;    /* no overlap */
> 2594         return;
> 2595     }
>
> h3 and/or h2 are signed int variables. They can be
> equal to MAXCOL (0x7fffffffL).  So the addition
> at line 2591 can overflow giving in general a negative
> value (but in theory behavior is undefined for signed
> int overflows). The intention of MAXCOL here was
> behave as a large height.
>
> Attached patch fixes it but please review it.
>
> IOC tool no longer complains with the patch.

Thanks, I'll add this to the todo list.

--
Shift happens.
                 -- Doppler

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

Jason Spiro wrote:

> Could you please include the Dungeon Crawl syntax file with Vim?
>
> URL: 
<http://gitorious.org/crawl/crawl/blobs/master/crawl-ref/source/dat/vim/syntax/l\
evdes.vim>.
>
> License:  GPL v2 or later.  See
<http://gitorious.org/crawl/crawl/blobs/master/crawl-ref/licence.txt>.
>
> Maintainer:  Darshan Shaligram <scintilla at gmail.com>.

I normally expect the author or maintainer of the file to email it to
me.  That way it is clear what version is to be distributed.

We prefer using the Vim license, so that all of the runtime files can be
distributed under the same license.  Dual-licencing, both GPL and the
Vim license is fine (the Vim license itself is also dual-licensed with
GPL).


--
hundred-and-one symptoms of being an internet addict:
22. You've already visited all the links at Yahoo and you're halfway through
     Lycos.

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

Christian Brabandt wrote:


> there seems to be a problem with backslash escaped strings when using
> expand(), glob() or globpath():
>
> #v+
> cb@host: mkdir -p /tmp/test
> ch@host: touch /tmp/test/bar /tmp/teest/foo\\1
> cb@host: vim -u NONE -U NONE -N -c ':e /tmp/test/bar|echo
> expand(@#)|echo expand("#")' /tmp/test/foo\\1
> #v-
>
> This outputs:
> "/tmp/test/bar" 0L, 0C
> test/foo1
> test/foo\1
>
> The problem is, you can't rely on expand() to skip one backslash,
> because on Windows it behaves correctly (e.g. expand('foobar\1') on
> Windows returns 'foobar\1' while on Unixs returns 'foobar1').

Yeah, handling a backslash in a filename gets tricky on MS-Windows, you
don't always know if it is used as a path separator or to escape the
special meaning of a character.

On the command line backslashes are accepted as path separators on
Windows, thus it will be different from Unix.  That is intentional and
should not be changed.

For functions it gets tricky.  And then we also have 'shellslash'.  Thus
it probably won't ever be consistent.


> Also, you can't use glob('/tmp/test/foo\\1') to return the correct
> result, and if you use glob(expand(path)) where path contains a
> backslash, glob() won't return the empty string.
>
> This is problematic because glob() is mentioned below :h filereadable()
> to check for the existence of a file.

Why would you use "\\1" here?  It doesn't have a special meaning, thus
perhaps the user actually wanted two backslashes?

> Here is a patch, that fixes this problematic behaviour and makes it at
> least consistent to the Windows behaviour. But ... it is a backward
> incompatible change and probably breaks a lot of plugins, that work
> around that bug by using something like
>
> if glob(expand(escape(filename, '\\')))
>      " file exists
>      &
> else
>      " create file
>      &
> endif
>
> Nevertheless, I tend to consider this as a bug and would like it to work
> consistently on all plattforms.

As mentioned, consistency is not really a goal here, MS-Windows handles
backslashes differently.  We need a better reason to make backwards
incompatible changes.


--
hundred-and-one symptoms of being an internet addict:
26. You check your mail. It says "no new messages." So you check it again.

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

Matthew Winn wrote:

> On Wed, 07 Nov 2012 16:04:41 +0100, Bram Moolenaar
> <Bram@...> wrote:
>
> > Dominique Pelle wrote:
> >
> > > I ran "make test" with vim-7.3.712 compiled with IOC
> > > (http://embed.cs.utah.edu/ioc/), a tool that detects integer
> > > overflows, which behave in undefined way according to
> > > the C standard.  Only unsigned integer is guaranteed to
> > > behave in a predictable way. IOC found a few bugs:
> >
> > The actual problem is in the standard.  Having integer operations behave
> > in an undefined way is not very useful.  They should have defined
> > uniform behavior.  It's the compiler writers who like these things to be
> > undefined, not the users.
>
> It's useful because the alternative would require the compiler to
> check for overflow after every operation if the underlying hardware
> behaved differently from the standard. Almost from the beginning it
> was C's policy to prefer efficiency and put the burden of avoiding
> non-portable behaviour on the programmer rather than slow everything
> down by checking things that rarely matter.

I don't know any hardware that behaves different with overflow.  All
CPUs just discard the upper bits.  it's the software that has a problem.
And then instead of solving this in the compiler, it's left to every
progammer to figure out.

AFAIK the C99 standard was written mostly by compiler writers.  They
have their own view on the world and made choices that are not always
what a programmer would do.  This standardization work is often very
boring and time consuming, which results in people who just want to get
things done not get involved.  I'm sure I will never be part of it, just
because it takes too much time.  I believe in specs that are written by
a small team of dedicated people. And I don't believe in design by
comittee.


> > > There is one more undefined behavior operation (float divide by 0
> > > which is also undefined in C). Fixing it would require to use the
> > > INFINITY macro I think but it's C99 macro and Vim needs to compile on
> > > older compilers so I did not fix it:
> >
> > Undefined?  I thought divide by zero always results in INF.  What
> > compiler does otherwise?
>
> I think it depends on the floating-point hardware, if there is any.
> I remember hearing of systems that didn't have Inf or NaN but I don't
> remember using one myself.

If the hardware doesn't support it then should the compiler take care of
it or should every programmer know exactly what is going on and write
bulky code to handle it?  I think it's best when the compiler does it.
Anyway, C99 does define INF and NaN, thus it must be supported, either
with hardware or otherwise.


--
Q: What is the difference betwee open-source and commercial software?
A: If you have a problem with commercial software you can call a phone
    number and they will tell you it might be solved in a future version.
    For open-source software there isn't a phone number to call, but you
    get the solution within a day.

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

On Wed, Nov 7, 2012 at 2:31 PM, Bram Moolenaar <Bram@...> wrote:

> We prefer using the Vim license, so that all of the runtime files can be
> distributed under the same license.  Dual-licencing, both GPL and the
> Vim license is fine (the Vim license itself is also dual-licensed with
> GPL).

Relicensing will require agreement from whoever has contributed
changes to the file which are large enough to be
copyright-significant.  Note that, before January 2010, the file was
in a different place in Git:  it was at
<crawl-ref/source/dat/levdes.vim>.

But first let's decide whether or not Vim will periodically sync with
upstream, and if so, how.

> I normally expect the author or maintainer of the file to email it to
> me.  That way it is clear what version is to be distributed.

Darshan:

Do you agree that Gitorious is a fine place for Bram to get the file from?

Bram:

The Dungeon Crawl development team is not small. The syntax file is
maintained by some team members.  I assume they want to maintain it
upstream, not in Vim.  The file changes very slowly.

It's not crucial for you to sync with upstream ever again.  The only
benefit would be that new keywords would be colored properly.  If it's
important to you, then you can do it, manually or by script.  You can
always get the latest version by HTTP at
<http://gitorious.org/crawl/crawl/blobs/raw/master/crawl-ref/source/dat/vim/synt\
ax/levdes.vim>.

A disclaimer:  I'm not on the Crawl dev team.  I just play Crawl
sometimes, and sometimes view the level files while I play.  Bram, I
didn't even discuss my idea with any Crawl dev team member before I
emailed you.

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

On Wed, 7 Nov 2012, Jason A. Spiro wrote:

> But first let's decide whether or not Vim will periodically sync
> with upstream, and if so, how.

Bram typically doesn't gather runtime files from people; he expects
maintainers to keep him updated by sending them to him.

- Christian

--
              Ambiguity:  Telling the truth when you don't mean to.
Christian J. Robinson <heptite@...>      http://christianrobinson.name/

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

Hi,

I'm the maintainer of Vim-R-plugin which may start a separate Vim
instance to run an "Object Browser". This Vim instance has a UDP
server running in a new thread. The server is written in Python and it
receives messages from R to update the list of objects. This Vim
instance isn't used to edit code and thus there is no problem if Vim
code is executed from the server thread.

Problem: The server stopped working after patch 691. The problem is
the line 748 of src/if_python.c. If I delete this line, the server
works as before. The server is created by the function VimServer() of
https://github.com/jcfaria/Vim-R-plugin/blob/master/r-plugin/vimcom.py

I'm far from an expert in Python programming, and I don't know how to
solve the problem. Any help is appreciated.

Thanks

--
Jakson Alves de Aquino
Federal University of Ceará
Social Sciences Department
www.lepem.ufc.br/aquino.php

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

I'm adding more details on the problem...

On Thu, Nov 8, 2012 at 6:21 PM, Jakson Alves de Aquino
<jalvesaq@...> wrote:
> I'm the maintainer of Vim-R-plugin which may start a separate Vim
> instance to run an "Object Browser". This Vim instance has a UDP
> server running in a new thread. The server is written in Python and it
> receives messages from R to update the list of objects. This Vim
> instance isn't used to edit code and thus there is no problem if Vim
> code is executed from the server thread.
>
> Problem: The server stopped working after patch 691. The problem is
> the line 748 of src/if_python.c. If I delete this line, the server
> works as before. The server is created by the function VimServer() of
> https://github.com/jcfaria/Vim-R-plugin/blob/master/r-plugin/vimcom.py

The line 748 of src/if_python.c is:

     pygilstate = PyGILState_Ensure();

The function VimServer() is called by RunServer() which uses the
threading module to create a new thread running VimServer(). The
VimServer() becomes immediately unresponsive. For example, there one
message that the VimServer() function sends to R when the server is
successfully started, but this message is actually being sent only
when the server is joined to the main thread or when the thread is
killed.

It seems that currently it's not possible to run a thread in parallel
to the main Vim process.

> I'm far from an expert in Python programming, and I don't know how to
> solve the problem. Any help is appreciated.

The solutions that I think that may be possible are:

     1) Undo the effect of PyGILState_Ensure() in the vimcom.py code
        (I don't know if this is possible).

     2) Create a Vim option to call/not call PyGILState_Ensure(). That
        is, transfer to plugin developers the option to use or not use
        unsafe threads.

In the Vim-R-plugin, the server is only used when Vim is running
inside a Tmux session and we have two independent Vim instances. I use
the server in the editor instance of Vim only to change the value of a
variable storing the number of the port of the Object Browser server.
In the Object Browser instance of Vim, the server calls functions to
rewrite the content of the buffer but that is almost always done when
the user is editing code in the editor instance and, thus, it's almost
always idle and almost never crashes. And when it does crash, no data
is lost since the Object Browser is not used to edit code.

Thanks

--
Jakson Alves de Aquino
Federal University of Ceará
Social Sciences Department
www.lepem.ufc.br/aquino.php

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

Hi Bram!

On Mi, 07 Nov 2012, Bram Moolenaar wrote:

>
> Christian Brabandt wrote:
>
>
> > there seems to be a problem with backslash escaped strings when using
> > expand(), glob() or globpath():
> >
> > #v+
> > cb@host: mkdir -p /tmp/test
> > ch@host: touch /tmp/test/bar /tmp/teest/foo\\1
> > cb@host: vim -u NONE -U NONE -N -c ':e /tmp/test/bar|echo
> > expand(@#)|echo expand("#")' /tmp/test/foo\\1
> > #v-
> >
> > This outputs:
> > "/tmp/test/bar" 0L, 0C
> > test/foo1
> > test/foo\1
> >
> > The problem is, you can't rely on expand() to skip one backslash,
> > because on Windows it behaves correctly (e.g. expand('foobar\1') on
> > Windows returns 'foobar\1' while on Unixs returns 'foobar1').
>
> Yeah, handling a backslash in a filename gets tricky on MS-Windows, you
> don't always know if it is used as a path separator or to escape the
> special meaning of a character.
>
> On the command line backslashes are accepted as path separators on
> Windows, thus it will be different from Unix.  That is intentional and
> should not be changed.
>
> For functions it gets tricky.  And then we also have 'shellslash'.  Thus
> it probably won't ever be consistent.
>
>
> > Also, you can't use glob('/tmp/test/foo\\1') to return the correct
> > result, and if you use glob(expand(path)) where path contains a
> > backslash, glob() won't return the empty string.
> >
> > This is problematic because glob() is mentioned below :h filereadable()
> > to check for the existence of a file.
>
> Why would you use "\\1" here?  It doesn't have a special meaning, thus
> perhaps the user actually wanted two backslashes?

On Unix a filename can contain backslashes. glob/expand shoudln't skip
them. Or saying it differently, I don't see a reason for expand() to
change it's input, if it can't expand the input parameter, it should
return in unchanged.

> > Here is a patch, that fixes this problematic behaviour and makes it at
> > least consistent to the Windows behaviour. But ... it is a backward
> > incompatible change and probably breaks a lot of plugins, that work
> > around that bug by using something like
> >
> > if glob(expand(escape(filename, '\\')))
> >      " file exists
> >      &
> > else
> >      " create file
> >      &
> > endif
> >
> > Nevertheless, I tend to consider this as a bug and would like it to work
> > consistently on all plattforms.
>
> As mentioned, consistency is not really a goal here, MS-Windows handles
> backslashes differently.  We need a better reason to make backwards
> incompatible changes.

I don't really mind, but it should be mentioned, that expand/glob
changes it input.

regards,
Christian
--
Musik im besten Sinne bedarf weniger der Neuheit, ja vielmehr,
je älter sie ist, je gewohnter man sie ist, desto mehr wirkt sie.
		 -- Goethe, Maximen und Reflektionen, Nr. 1235

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

Bram,

this patch changes how confirm writes messages on the console.
It will now highlight each choice using the Title highlighting group.

regards,
Christian

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

Could anyone successfully compile vim in windows 8 with visual studio 12?

I just installed the system yesterday, and I was trying to compile vim but I am
having issues.

These are the steps:
first setting up the variables:
call "c:\Program Files (x86)\Microsoft Visual Studio
11.0\VC\bin\x86_amd64\vcvarsx86_amd64.bat"

then
nmake -f Make_mvc.mak CPU=AMD64 GUI=yes

this stops with the error:
Microsoft (R) Program Maintenance Utility Version 11.00.50727.1
Copyright (C) Microsoft Corporation.  All rights reserved.

Make_mvc.mak(236) : fatal error U1052: file 'Win32.mak' not found
Stop.


I searched and found out that in windows 7 this file was under:
C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\Include\Win32.Mak

but with this in windows 8 I cannot find the file in the same folder (the folder
doesn't exist anymore).

Any idea on how to solve this?

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

On Friday, November 9, 2012 5:39:32 PM UTC-5, skeept wrote:
> Could anyone successfully compile vim in windows 8 with visual studio 12?
>
> I just installed the system yesterday, and I was trying to compile vim but I
am having issues.
>
> These are the steps:
> first setting up the variables:
> call "c:\Program Files (x86)\Microsoft Visual Studio
11.0\VC\bin\x86_amd64\vcvarsx86_amd64.bat"
>
> then
> nmake -f Make_mvc.mak CPU=AMD64 GUI=yes
>
> this stops with the error:
> Microsoft (R) Program Maintenance Utility Version 11.00.50727.1
> Copyright (C) Microsoft Corporation.  All rights reserved.
>
> Make_mvc.mak(236) : fatal error U1052: file 'Win32.mak' not found
> Stop.
>
>
> I searched and found out that in windows 7 this file was under:
> C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\Include\Win32.Mak
>
> but with this in windows 8 I cannot find the file in the same folder (the
folder doesn't exist anymore).
>
> Any idea on how to solve this?
>
> Thanks!

Copying the mentioned file from the old location to vim source fixes this,
should have thought of that before!

Regards.

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