Using PowerShell as the shell in VIM

[Mike Williams]

Hi,

I recently tried to start using Tim Pope's excellent git plugin,
vim-fugitive, on my Windows machine and soon ran into problems.  These
were all from having setup Windows PowerShell as my shell to use from
VIM.  My settings were ancient and naively cargo-culted from the web
and had worked for my relatively simple purposes. At Tim's prodding I
revisited my shell settings for VIM which improved things but
unfortunately did not manage to get the plugin fully working, so for
now I have to fall back on the ancient cmd.exe shell. Googling around
shows plenty of confusion of how to set up powershell.

And to show my greenness on this I have only just twigged there are
two versions of PowerShell, the one supplied as standard with Windows
(the one I am using, 5.1 aka .NET) and PowerShell Core (6.0) which is
multi-platform which apparently differ in ways I don't know yet. At
least they have different shell names, powershell vs pwsh. For now I
am concentrating on the former since this concerns various Windows
specific issues.

Any road, here is a summary of issues that I encountered trying to
setup PowerShell as the shell.

The powershell command works best without any quotes around it, so
shellquote should be empty (setting shq to a single quote (') makes
the command fail, using double quotes (") causes problems with quoted
arguments). According to the shellquote docs shellquote is set to " on
win32 when shell contains sh. This is not what is happening with
shell=powershell, AFAICT VIM checks for shell ending with sh. Which is
correct, doc or VIM?  If the intent is if sh is anywhere then VIM will
need modifying to detect powershell to leave shq unset.

VIM is defaulting shellxquote to " with shell=powershell since that
detects sh within the shell name. Use shell=PowerShell and shellxquote
is not set. AFAICT either setting works but I think it would be less
confusing if sxq is left unset with powershell

Shell command arguments with spaces need to be enclosed in single
quotes, not double quotes. This causes a problem with the
shellescape() function as by default on Windows it uses double quotes.
Unless shellslash is set when it will use single quotes.  However this
forces the use of shellslash in a shell that is not unix like.  Yes
powershell will accept forward quotes but any paths it reports have
backslashes, so VIM scripts start to get confused when VIM generated
paths and shell generated paths don't match. Yeah scripts can include
file path normalisation functions but I feel they shouldn't have to
(and trying to make Windows file system looks like a unix one is a
never ending job I'd rather not have to do).

shellescape() needs modifying to correctly escape when using
powershell independently of shellslash.  Should this be a new shell
setting? Does shellescape() need to be aware when the shell is
powershell and behave differently? Does shellescape() need yet another
argument to handle this in some way I haven't thought of yet?

The shellredir option defaults to just > which loses stderr output.
This can be caught with powershell using redir=>%s\ 2>&1  However
since powershell generates UTF16 this can cause problems for plugins
so the following can be used instead - shellredir=2>&1\ \|\ Out-File\
-encoding\ Default which well transcode to the configured console
codepage. The shellpipe option for powershell also defaults to > which
is not consistent with the doc - it can be set to be shellpipe=>%s\
2>&1 to just capture to a file, or if you want to see the output as
well then use shellpipe=2>&1\ \|\ Tee-Object  For both settings VIM
and doc should be updated to be aware of powershell and it's alternate
defaults.

As I said, this is based on my investigations - I may have missed some
things or misunderstood things.  As it stands I encounter problems
with scripts using powershell on windows (which is different to pwsh
on unix!) which appear to be fixable with some of the above changes.
Having sane defaults for the various shell settings for powershell
would require less tinkering to get VIM working, and provide a solid
basis for script writers having to cope with different shells.

Any comments or thoughts before I start to dive in?

TTFN
-- 
Mike

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

--- 
You received this message because you are subscribed to the Google Groups 
"vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/vim_dev/CAKz_cXatsnr_PMxGQy9L43%3DrN9n43-h1LzTTw09a2mnEdZ01jw%40mail.gmail.com.

Patch to enable channel when building Windows terminal with terminal

[Mike Williams]

Hi,

Small patch to enable IPC on Windows terminal builds when including
terminal support in VIM:

diff --git a/src/Make_mvc.mak b/src/Make_mvc.mak
--- a/src/Make_mvc.mak
+++ b/src/Make_mvc.mak
@@ -39,6 +39,7 @@
 #  Global IME support: GIME=yes (requires GUI=yes)
 #
 #  Terminal support: TERMINAL=yes (default is yes)
+#   Requires CHANNEL.
 #
 #  Sound support: SOUND=yes (default is yes)
 #
@@ -115,7 +116,7 @@
 #  doesn't work)
 #
 #  Inter process communication: CHANNEL=[yes or no] (default is yes if GUI
-#   is yes)
+#   or TERMINAL is yes)
 #
 #  XPM Image Support: XPM=[path to XPM directory]
 #  Default is "xpm", using the files included in the distribution.
@@ -388,7 +389,7 @@ NETBEANS = $(GUI)
 !endif

 !ifndef CHANNEL
-! if "$(FEATURES)"=="HUGE"
+! if "$(FEATURES)"=="HUGE" || "$(TERMINAL)"=="yes"
 CHANNEL = yes
 ! else
 CHANNEL = $(GUI)


TTFN

-- 
Mike

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

--- 
You received this message because you are subscribed to the Google Groups 
"vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/vim_dev/CAKz_cXa2_-Fsw%3DiANUVUKLaHKz1tYeEO7eEO2VxubpoxV%3D540A%40mail.gmail.com.

Re: Windows build failure including terminal in terminal build

[Mike Williams]

Hi again

On Wednesday, 18 March 2020 11:39:03 UTC, Mike Williams wrote:
>
> Hi
>
> On Wednesday, 18 March 2020 11:01:22 UTC, Dominique Pelle wrote:
>>
>> Mike Williams wrote: 
>>
>> > Hi, 
>> > 
>> > I am trying to build a terminal version of VIM that includes terminal 
>> > support.  My build line run in the src directory are: 
>> > 
>> > nmake -nologo -f make_mvc.mak TERMINAL=yes FEATURES=BIG 
>> > 
>> > The final link fails with: 
>> > 
>> > vterm_unicode.obj : error LNK2001: unresolved external symbol 
>> utf_uint2cells 
>> > vterm_unicode.obj : error LNK2001: unresolved external symbol 
>> > utf_iscomposing_uint 
>> > vim.exe : fatal error LNK1120: 2 unresolved externals 
>> > 
>> > The invoked compilation command is: 
>> > 
>> > cl -c /W3 /nologo  -I. -Iproto -DHAVE_PATHDEF -DWIN32  -DFEAT_CSCOPE 
>> > -DFEAT_TERMINAL -DFEAT_SOUND-DWINVER=0x0501 
>> > -D_WIN32_WINNT=0x0501 /source-charset:utf-8 /MP -DHAVE_STDINT_H /Ox 
>> > /GL -DNDEBUG  /Zl /MT /D_CRT_SECURE_NO_DEPRECATE 
>> > /D_CRT_NONSTDC_NO_DEPRECATE -DFEAT_MBYTE_IME -DDYNAMIC_IME 
>> > -DDYNAMIC_ICONV -DDYNAMIC_GETTEXT -DFEAT_PYTHON -DDYNAMIC_PYTHON 
>> > -DDYNAMIC_PYTHON_DLL=\"python27.dll\" -DFEAT_BIG /Fd.\ObjCYAMD64/ /Zi 
>> > /Fo.\ObjCYAMD64/ ... 
>> > 
>> > The missing symbols are from mbyte.c and checking there I can see they 
>> > are compiled in if FEAT_TERMINAL is defined, which it appears to be. 
>> > And yes mbyte.c appears in the list of files to compile and compiled. 
>>
>> Strange, it can't see why it happens. 
>> Maybe make_mvc.mak is missing a dependency and it's 
>> linking with an old object file as a result? 
>> Can you do do a clean build to make sure that this is not the issue? 
>>
>> Regards 
>> Dominique 
>>
>
> Yeah, I should have said I thought of that and made sure there were no 
> unexpected .obj files lying around.  I have done a clean debug build so I 
> can dumpbin the symbols in mbyte.obj, and sure enough the symbols do not 
> appear in it.
>
> Ah, full disclosure.  I normall build gui followed by terminal versions. 
> Using #error to check the functions were being built did fail with the gui 
> build, indicating that FEAT_TERMINAL was defined - I just assumed the same 
> with the terminal version.  I then simplified the build script to just 
> build the terminal version which continued to fail.  Retrying the #error 
> trick now shows the functions are not being compiled in even though 
> FEAT_TERMINAL is in the cl command.
>
> So, the issue is that FEAT_TERMINAL is being undefined for windows 
> terminal builds by features.h because FEAT_JOB_CHANNEL is not being 
> defined.  I guess the vterm code is not picking up feature.h and missing 
> the redefinition of flags from the compile command.
>
> I don't define this for gui builds so dont do it for terminal builds - 
> should I? Or is this an issue in the MSVC makefile being inconsistent?
>
> TIA - TTFN
>
> Mike
>

Ok, I have sorted out how to get it to build, I need to include CHANNEL=yes 
otherwise terminal support is cleared in feature.h.  CHANNEL is set for 
FEATURES=BIG or inherits the GUI setting which is why the GUI build was 
succeeding.

At it's simplest the MVC make file (and others?) needs to note that channel 
is needed for terminal support in the same way netbeans support notes 
this.  After that it is a judgement call if selecting terminal should 
enable channel support or not.  Handling this in the actual C source 
doesn't seem feasible if the vterm code is separate to the core VIM source.

My 2ps worth.

TTFN

Mike
 

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

--- 
You received this message because you are subscribed to the Google Groups 
"vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/vim_dev/3323fcae-0830-49a0-96e7-545d1466b4d0%40googlegroups.com.

Re: Windows build failure including terminal in terminal build

[Mike Williams]

Hi

On Wednesday, 18 March 2020 11:01:22 UTC, Dominique Pelle wrote:
>
> Mike Williams wrote: 
>
> > Hi, 
> > 
> > I am trying to build a terminal version of VIM that includes terminal 
> > support.  My build line run in the src directory are: 
> > 
> > nmake -nologo -f make_mvc.mak TERMINAL=yes FEATURES=BIG 
> > 
> > The final link fails with: 
> > 
> > vterm_unicode.obj : error LNK2001: unresolved external symbol 
> utf_uint2cells 
> > vterm_unicode.obj : error LNK2001: unresolved external symbol 
> > utf_iscomposing_uint 
> > vim.exe : fatal error LNK1120: 2 unresolved externals 
> > 
> > The invoked compilation command is: 
> > 
> > cl -c /W3 /nologo  -I. -Iproto -DHAVE_PATHDEF -DWIN32  -DFEAT_CSCOPE 
> > -DFEAT_TERMINAL -DFEAT_SOUND-DWINVER=0x0501 
> > -D_WIN32_WINNT=0x0501 /source-charset:utf-8 /MP -DHAVE_STDINT_H /Ox 
> > /GL -DNDEBUG  /Zl /MT /D_CRT_SECURE_NO_DEPRECATE 
> > /D_CRT_NONSTDC_NO_DEPRECATE -DFEAT_MBYTE_IME -DDYNAMIC_IME 
> > -DDYNAMIC_ICONV -DDYNAMIC_GETTEXT -DFEAT_PYTHON -DDYNAMIC_PYTHON 
> > -DDYNAMIC_PYTHON_DLL=\"python27.dll\" -DFEAT_BIG /Fd.\ObjCYAMD64/ /Zi 
> > /Fo.\ObjCYAMD64/ ... 
> > 
> > The missing symbols are from mbyte.c and checking there I can see they 
> > are compiled in if FEAT_TERMINAL is defined, which it appears to be. 
> > And yes mbyte.c appears in the list of files to compile and compiled. 
>
> Strange, it can't see why it happens. 
> Maybe make_mvc.mak is missing a dependency and it's 
> linking with an old object file as a result? 
> Can you do do a clean build to make sure that this is not the issue? 
>
> Regards 
> Dominique 
>

Yeah, I should have said I thought of that and made sure there were no 
unexpected .obj files lying around.  I have done a clean debug build so I 
can dumpbin the symbols in mbyte.obj, and sure enough the symbols do not 
appear in it.

Ah, full disclosure.  I normall build gui followed by terminal versions. 
Using #error to check the functions were being built did fail with the gui 
build, indicating that FEAT_TERMINAL was defined - I just assumed the same 
with the terminal version.  I then simplified the build script to just 
build the terminal version which continued to fail.  Retrying the #error 
trick now shows the functions are not being compiled in even though 
FEAT_TERMINAL is in the cl command.

So, the issue is that FEAT_TERMINAL is being undefined for windows terminal 
builds by features.h because FEAT_JOB_CHANNEL is not being defined.  I 
guess the vterm code is not picking up feature.h and missing the 
redefinition of flags from the compile command.

I don't define this for gui builds so dont do it for terminal builds - 
should I? Or is this an issue in the MSVC makefile being inconsistent?

TIA - TTFN

Mike

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

--- 
You received this message because you are subscribed to the Google Groups 
"vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/vim_dev/b257b636-6674-48eb-94f1-5cb93ba13e8d%40googlegroups.com.

Windows build failure including terminal in terminal build

[Mike Williams]

Hi,

I am trying to build a terminal version of VIM that includes terminal
support.  My build line run in the src directory are:

nmake -nologo -f make_mvc.mak TERMINAL=yes FEATURES=BIG

The final link fails with:

vterm_unicode.obj : error LNK2001: unresolved external symbol utf_uint2cells
vterm_unicode.obj : error LNK2001: unresolved external symbol
utf_iscomposing_uint
vim.exe : fatal error LNK1120: 2 unresolved externals

The invoked compilation command is:

cl -c /W3 /nologo  -I. -Iproto -DHAVE_PATHDEF -DWIN32  -DFEAT_CSCOPE
-DFEAT_TERMINAL -DFEAT_SOUND-DWINVER=0x0501
-D_WIN32_WINNT=0x0501 /source-charset:utf-8 /MP -DHAVE_STDINT_H /Ox
/GL -DNDEBUG  /Zl /MT /D_CRT_SECURE_NO_DEPRECATE
/D_CRT_NONSTDC_NO_DEPRECATE -DFEAT_MBYTE_IME -DDYNAMIC_IME
-DDYNAMIC_ICONV -DDYNAMIC_GETTEXT -DFEAT_PYTHON -DDYNAMIC_PYTHON
-DDYNAMIC_PYTHON_DLL=\"python27.dll\" -DFEAT_BIG /Fd.\ObjCYAMD64/ /Zi
/Fo.\ObjCYAMD64/ ...

The missing symbols are from mbyte.c and checking there I can see they
are compiled in if FEAT_TERMINAL is defined, which it appears to be.
And yes mbyte.c appears in the list of files to compile and compiled.

The vterm code seems to be derived at compile time and I don't have
time at the moment to delve into the build process to understand what
it is doing, and why it a reference to a symbol that should exist
fails.  And I checked that at compile time mbyte.c the symbols are
being compiled.

Willing to try suggestions/patches if no one else can reproduce.

TTFN

-- 
Mike

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

--- 
You received this message because you are subscribed to the Google Groups 
"vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/vim_dev/CAKz_cXYZatuE6XS%3DkK06uHYH_FAZGuL9kmpeESiaP6WnwXNtfA%40mail.gmail.com.

Re: [vim/vim] C syntax highlighting bug with uncommented #include (#5705)

[Mike Williams]

On Friday, 28 February 2020 06:21:20 UTC, Christian Brabandt wrote:
>
> Is that actually valid syntax? 
>

It is valid syntax. According to the standard all comments are replaced 
with spaces before executing pre-processor directives like #include. This 
means any directive can appear after a comment. Not a typical coding 
convention but perfectly valid.


> > Am 27.02.2020 um 21:53 schrieb Bogdan Barbu  >:
> > 
> > 
> > Try the following:
> > /* */ #include 
> > or
> > /*
> > */ #include 
> > 
> > The directive #include will not be highlighted.
> > 
> > —
> > You are receiving this because you are subscribed to this thread.
> > Reply to this email directly, view it on GitHub, or unsubscribe.
>
> —
> You are receiving this because you are subscribed to this thread.
> Reply to this email directly, view it on GitHub 
> ,
>  
> or unsubscribe 
> 
> .
>

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

--- 
You received this message because you are subscribed to the Google Groups 
"vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/vim_dev/afbadad9-9ab4-4f78-b519-4cc19a9ae2fa%40googlegroups.com.

Re: Vim crash split opening a new file - 8.2.90

[Mike Williams]

FTR the crash has been fixed by patch 96.  Nothing more to see, move along now.

Mike

From: Bram Moolenaar 
Sent: 06 January 2020 6:59 PM
To: vim_dev@googlegroups.com 
Cc: Mike Williams 
Subject: Re: Vim crash split opening a new file - 8.2.90

External Sender: Use caution with links/attachments.

Mike Williams wrote:

> Just updated after the hols and 64bit build on Ubuntu 14.04 is now
> crashing using nerdtree and opening a new file in a split window.
> Looks like an invalid free() processing autocommands but I'm in the
> early stages of tracking it down.
>
> Is anyone else seeing the crash and already working on it?  Don't want
> to waste my time if it is already on someone's radar.

I'm not aware of such a problem.  Perhaps valgrind can tell you where it
happens.

--
Q: What kind of stuff do you do?
A: I collect hobbies.

 /// Bram Moolenaar -- b...@moolenaar.net -- http://www.Moolenaar.net   \\\
///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\  an exciting new programming language -- http://www.Zimbu.org///
 \\\help me help AIDS victims -- http://ICCF-Holland.org///

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

--- 
You received this message because you are subscribed to the Google Groups 
"vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/vim_dev/AM6PR06MB6168B8788ABB9C515573B363873E0%40AM6PR06MB6168.eurprd06.prod.outlook.com.

Re: Vim crash split opening a new file - 8.2.90

[Mike Williams]

Hi,

Pinned down the patch that introduced the crash as "8.2.0056: execution stack 
is incomplete and inefficient".  I'll have a go with asan tomorrow unless 
someone else works it out first.

TTFN

Mike


From: vim_dev@googlegroups.com  on behalf of 
Dominique Pellé 
Sent: 06 January 2020 6:39 PM
To: vim_dev 
Subject: Re: Vim crash split opening a new file - 8.2.90

External Sender: Use caution with links/attachments.
Mike Williams  wrote:

> Hi,
>
> Just updated after the hols and 64bit build on Ubuntu 14.04 is now crashing 
> using nerdtree and opening a new file in a split window.  Looks like an 
> invalid free() processing autocommands but I'm in the early stages of 
> tracking it down.
>
> Is anyone else seeing the crash and already working on it?  Don't want to 
> waste my time if it is already on someone's radar.

Can you give the exact steps so we can reproduce?

Try running Vim with valgrind or asan, as described
in this comment:

https://github.com/vim/vim/issues/5410#issuecomment-569516803

And reports memory errors from valgrind or asan.

Best to try asan first, as valgrind gives noise when using python interpreter.
asan is also faster.

Regards
Dominique

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

---
You received this message because you are subscribed to the Google Groups 
"vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/vim_dev/CAON-T_j9QpAWzgLGQpdhxrzYiNtbwGYoun4a%3DS0LFv7xSztB8g%40mail.gmail.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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/vim_dev/AM6PR06MB61688E43A39C25A62D76F180873C0%40AM6PR06MB6168.eurprd06.prod.outlook.com.

Vim crash split opening a new file - 8.2.90

[Mike Williams]

Hi,

Just updated after the hols and 64bit build on Ubuntu 14.04 is now crashing 
using nerdtree and opening a new file in a split window.  Looks like an invalid 
free() processing autocommands but I'm in the early stages of tracking it down.

Is anyone else seeing the crash and already working on it?  Don't want to waste 
my time if it is already on someone's radar.

TTFN

Mike

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

--- 
You received this message because you are subscribed to the Google Groups 
"vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/vim_dev/AM6PR06MB61682F37D662678D470DEABC873C0%40AM6PR06MB6168.eurprd06.prod.outlook.com.

Re: bitbucket is going to drop Mercurial

[Mike Williams]

On 21/08/2019 11:42, Christian Brabandt wrote:
> External Sender: Use caution with links/attachments.
> 
> On Di, 20 Aug 2019, Mike Williams wrote:
> 
>> Given the relatively low access it may be simpler to set up a small
>> hosted read-only server.  The repo is only ~80MiB and most reads should
>> be for delta updates.
> 
> That's what I did. Please try out: http://hg.256bit.org

Works for me.  Or would you prefer people to use the OSDN repo?

> It should already mirror the bitbucket server.
> 
> Best,
> Christian
> 

Mike
-- 
Been there, done that, and someone stole the T-shirt! Hated 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

--- 
You received this message because you are subscribed to the Google Groups 
"vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/vim_dev/71b35106-b548-1f5c-14fa-71f6f9538edb%40globalgraphics.com.

Re: bitbucket is going to drop Mercurial

[Mike Williams]

On 20/08/2019 14:51, Christian Brabandt wrote:
> External Sender: Use caution with links/attachments.
> 
> On Di, 20 Aug 2019, Tony Mechelynck wrote:
> 
>> Full details: 
>> https://bitbucket.org/blog/sunsetting-mercurial-support-in-bitbucket
>>
>> TLDR: Bit bucket won't allow creating *new* Mercurial repos starting
>> 2020-02-01 and on 2020-06-01 all existing Mercurial repos on bitbucket
>> will be deleted. From then on it will only support git repos.
>>
>> How it concerns Vim: We have on bitbucket a Mercurial repo, which
>> mirrors the git repo maintained by Bram on github. So we don't need to
>> migrate to a git repo (we already have one) but if we do nothing our
>> existing Mercurial mirror will vanish into thin air on 2020-06-01.
>>
>> Our current Mercurial repo is maintained by Christian Brabandt, and I
>> am one of its users; I hope I'm not alone (I understand Mercurial much
>> better than I do git). So Christian: IIUC you're holding the hot
>> potato. But maybe someone else has opinions about what to do next (I
>> don't).
> 
> Oh too bad. I am more of a git users nowadays but I am still sorry,
> mercurial support is dropped. That sounds like there is only git left
> for distributed versioning control.

Mercurial itself is not disappearing, but most likely is becoming more 
niche with just a few companies and projects holding out.  But the sheep 
seem to have voted and git has won it seems.

There is the hg-git plugin for those that still want to use Mercurial to 
work on Vim, but I don't know how good it actually is.

> Does anybody know of other existing
> code sharing sites we could use instead? I am willing to keep my script
> running (since it's been running flawlessly and I haven't had many
> issues with it) and it was an interesting challenge to keep two
> repositories synced.

https://www.mercurial-scm.org/wiki/MercurialHosting#Free_services

Given the relatively low access it may be simpler to set up a small 
hosted read-only server.  The repo is only ~80MiB and most reads should 
be for delta updates.

TTFN

Mike
-- 
Verbing weirds language.

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

--- 
You received this message because you are subscribed to the Google Groups 
"vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/vim_dev/aa4dfc81-4c9d-1d1e-fd85-d1cc8d16e459%40globalgraphics.com.

Re: build error since today (invalid UTF-8)

[Mike Williams]

On 07/06/2019 06:44, Christian Brabandt wrote:
> 
> On Do, 06 Jun 2019, M Kelly wrote:
> 
>> Hi,
>>
>> I see someone else posted earlier about the same issue.
>> But those suggestions and also latest git rev do not resolve issue for me.
> 
> Yeah, it looks like Ubuntus msgfmt is seriously broken. Open a bug
> report at their issue tracker please.

In the process of doing this - first one for me so a learning process. 
Should be added by COB today UK time.

> For the time being, you can either install an updated msgfmt from here:
> https://launchpad.net/~ricotz/+archive/ubuntu/toolchain

Custom tool chains to build VIM doesn't feel right but that is just a 
grumble from me.

> or simply ignore the error and apply a local patch, like this one:
> https://groups.google.com/d/msg/vim_dev/yYGCsJJPlA0/oPYsDxBRAgAJ

I tired disturbing the file - moving the line, adding ASCII chars, 
rearranging chars but to now avail.  This one may run for a while :(

TTFN

Mike
-- 
When you're arguing with a fool, make sure he isn't doing the same thing.

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

--- 
You received this message because you are subscribed to the Google Groups 
"vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/vim_dev/a285661d-e46c-c3d6-85f5-9aeffc6a617b%40globalgraphics.com.
For more options, visit https://groups.google.com/d/optout.

Re: Patch 8.1.1468

[Mike Williams]

On 06/06/2019 18:22, Christian Brabandt wrote:
> 
> On Do, 06 Jun 2019, Mike Williams wrote:
> 
>> The desktop file still seems valid apart from encoding errors.  Is there
>> a problem if the makefile ignored the error and continued?  Or have a
> 
> The problem is, we might not notice failures :(

You still get the error reported, but yes I see your point.  Fine for 
local development, not for CI where you want it to pick up errors.

>> build option to allow ignoring errors generating desktop files?  Just a
>> wild thought.
> 
> I think for fixing your local environment, the best is to commit a local
> patch like below, that should just ignore the error. Granted, that would
> install a probably invalid desktop file, but that happened before as
> well (and it seemed nobody noticed since the desktop files are generated
> from the po files directly (8.1.1147)).
> 
> Well, at least Debian and Ubuntu do not offer official packages newer
> than 8.1.0875, in case of Debian this is probably due to the buster
> freeze).

U16.04 is 7.4.1689.  The level of pain may depend on how many people 
build recent versions of VIM or provide a PPA for others.

> That patch could be stashed on top, or just kept around in your local
> repository, shouldn't really matter.
> 
> diff --git a/src/po/Makefile b/src/po/Makefile
> index 8c7066b64..dcf88ab19 100644
> --- a/src/po/Makefile
> +++ b/src/po/Makefile
> @@ -169,14 +169,14 @@ vim.desktop: vim.desktop.in $(POFILES)
>  @echo $(LANGUAGES) | tr " " "\n" |sed -e '/\./d' | sort > LINGUAS
>  $(MSGFMT) --desktop -d . --template vim.desktop.in -o tmp_vim.desktop
>  rm -f LINGUAS
> -   if command -v desktop-file-validate; then desktop-file-validate 
> tmp_vim.desktop; fi
> +   -if command -v desktop-file-validate; then desktop-file-validate 
> tmp_vim.desktop; fi
>  mv tmp_vim.desktop vim.desktop
> 
>   gvim.desktop: gvim.desktop.in $(POFILES)
>  @echo $(LANGUAGES) | tr " " "\n" |sed -e '/\./d' | sort > LINGUAS
>  $(MSGFMT) --desktop -d . --template gvim.desktop.in -o 
> tmp_gvim.desktop
>  rm -f LINGUAS
> -   if command -v desktop-file-validate; then desktop-file-validate 
> tmp_gvim.desktop; fi
> +   -if command -v desktop-file-validate; then desktop-file-validate 
> tmp_gvim.desktop; fi
>  mv tmp_gvim.desktop gvim.desktop
> 
>   update-po: $(LANGUAGES)

I still run off an hg repo so a simple mq patch will quickly do what I 
need.  Thanks for all the help.

TTFN

Mike
-- 
If you throw a cat out of a car window... is it kitty litter??

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

--- 
You received this message because you are subscribed to the Google Groups 
"vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/vim_dev/542f88eb-4264-2415-b723-af0326dd7556%40globalgraphics.com.
For more options, visit https://groups.google.com/d/optout.

Re: Patch 8.1.1468

[Mike Williams]

On 06/06/2019 16:48, Christian Brabandt wrote:
> 
> On Do, 06 Jun 2019, Mike Williams wrote:
> 
>> 16.04 is a Ubuntu LTS and supported for another 18 months or so.  It
>> would be nice to think they would want to updated for such an obvious
>> bug on release widely used, but who knows.
> 
> Just for the fun of it, I have been trying to see what commit caused it.
> I think, this commit fixed it:
> http://git.savannah.gnu.org/cgit/gettext.git/commit/?id=68ab0dafa99f1941b3ebb47b7cf969381e7310f4
> 
> Going further I could successfully apply that patch against Ubuntus
> 16.04 LTS version and rebuild the complete package. That seems to have
> fixed the problem on my local xenial (16.04LTS) box. So perhaps you can
> convince them to rebuild with that patch applied on top.

On a straight read of the patch that seems a surprising fix, but I'll 
happily take your word for it.

>> This is for a work machine so modifying toolchains via a PPA is not
>> possible.  I can work around the problem now that I know what it is.
> 
> Understood. I have been wondering if it would be doable to detect this
> problem somewhere and then skip this step. Not sure how to do this and
> if it would be worth the trouble.

The desktop file still seems valid apart from encoding errors.  Is there 
a problem if the makefile ignored the error and continued?  Or have a 
build option to allow ignoring errors generating desktop files?  Just a 
wild thought.

TTFN

Mike
-- 
Everyone I know lives on a fold on a map!

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

--- 
You received this message because you are subscribed to the Google Groups 
"vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/vim_dev/44cc19bd-fdb6-d39c-d083-2cd65fccfdbc%40globalgraphics.com.
For more options, visit https://groups.google.com/d/optout.

Re: Patch 8.1.1468

[Mike Williams]

On 06/06/2019 15:47, Christian Brabandt wrote:
> 
> On Do, 06 Jun 2019, Mike Williams wrote:
> 
>> It looks like the last byte of the last character has been dropped in
>> processing.  The .in file has the UTF-8 sequence 0xe0 0xad 0x81 0x0a for
>> the last character and the newline, but the tmp file has  0xe0 0xad 0x0a
>> which is an invalid UTF-8 sequence.  Removing the line from both the .in
>> files allows make to run to completion with no errors.
>>
>> This looks like a bug in msgfmt which should not be emitting invalid
>> UTF-8 sequences.  In the meantime this will break all builds on U16.04. :(
> 
> Indeed. Try reporting a bug to ubuntu, though I doubt they will upload a
> new (fixed) version. In the meantime, you might want to use this package
> here:
> https://launchpad.net/~ricotz/+archive/ubuntu/toolchain
> 
> We are using this on our Travis build script as well.

16.04 is a Ubuntu LTS and supported for another 18 months or so.  It 
would be nice to think they would want to updated for such an obvious 
bug on release widely used, but who knows.

This is for a work machine so modifying toolchains via a PPA is not 
possible.  I can work around the problem now that I know what it is.

TTFN

Mike
-- 
The wind of change blows straight into the face of time.

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

--- 
You received this message because you are subscribed to the Google Groups 
"vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/vim_dev/7085e9a9-72a3-a0aa-8a99-011230d75b10%40globalgraphics.com.
For more options, visit https://groups.google.com/d/optout.

Re: Patch 8.1.1468

[Mike Williams]

On 06/06/2019 12:16, Christian Brabandt wrote:
> 
> On Do, 06 Jun 2019, Mike Williams wrote:
> 
>> Hi
>>
>> On 05/06/2019 20:25, Bram Moolenaar wrote:
>>>
>>> Patch 8.1.1468
>>> Problem:The generated desktop files may be invalid.
>>> Solution:   Check validity with desktop-file-validate. (Christian Brabandt,
>>>   Will Thompson, closes #4480)
>>> Files:  src/po/Makefile
>>>
>>
>> A clean build and install is now reporting the following warnings and
>> errors:
>>
>> msgfmt --desktop -d . --template gvim.desktop.in -o tmp_gvim.desktop
>> rm -f LINGUAS
>> if command -v desktop-file-validate; then desktop-file-validate
>> tmp_gvim.desktop; fi
>> /usr/bin/desktop-file-validate
> 
>> tmp_gvim.desktop: warning: file contains lines that are not UTF-8
>> encoded. There is no guarantee the validator will correctly work.
> 
> I have no clue where that comes from.

This may be related to the later UTF-8 warning.

>> tmp_gvim.desktop: error: file contains multiple keys named
>> "GenericName[eo]" in group "Desktop Entry"
>> tmp_gvim.desktop: error: file contains multiple keys named "Comment[eo]"
>> in group "Desktop Entry"
> 
> That is expected and fixed by
> https://github.com/vim/vim/commit/61da1bfa6c6b19dd670671a318ce9f9e2acc784c

Confirmed.

>> [Invalid UTF-8] tmp_gvim.desktop: error: value
>> "\xe0\xac\xaa\xe0\xac\xbe\xe0\xac\xa0\xe0\xad\x8d\xe0\xac\xaf
>> \xe0\xac\xab\xe0\xac\xbe\xe0\xac\x87\xe0\xac\xb2\xe0\xac\x97\xe0\xad\x81\xe0\xac\xa1\xe0\xac\xbc\xe0\xac\xbf\xe0\xac\x95\xe0\xad\x81
>> \xe0\xac\xb8\xe0\xac\xae\xe0\xad\x8d\xe0\xac\xaa\xe0\xac\xbe\xe0\xac\xa6\xe0\xac\xa8
>> \xe0\xac\x95\xe0\xac\xb0\xe0\xac\xa8\xe0\xad\x8d\xe0\xac\xa4\xe0\xad"
>> for locale string key "Comment[or]" in group "Desktop Entry" contains
>> invalid UTF-8 characters, locale string values should be encoded in UTF-8
> 
> I don't see that. I suspect either msgfmt cannot correctly handle the
> template (gvim.desktop.in) file or desktop-file-validate does
> incorrectly detect it as non UTF-8
> 
> BTW, is your locale set correctly?

I believe so.  All settings are en_GB.UTF-8

> For the records, in my debian dev box, I am using:
> gettext:
>Installed: 0.19.8.1-9
>Candidate: 0.19.8.1-9
>Version table:
>   *** 0.19.8.1-9 500
>  500 http://ftp.de.debian.org/debian buster/main amd64 Packages
>  100 /var/lib/dpkg/status
> 0 140901 chrisbra@debian ~/code/vim-src/src/po (git)-[desktop-file-utils]- % 
> apt-cache policy desktop-file-utils
> desktop-file-utils:
>Installed: 0.23-4
>Candidate: 0.23-4
>Version table:
>   *** 0.23-4 500
>  500 http://ftp.de.debian.org/debian buster/main amd64 Packages
>  100 /var/lib/dpkg/status

~/repos/vim $ apt list gettext desktop-file-utils
Listing... Done
desktop-file-utils/xenial-updates,now 0.22-1ubuntu5.2 i386 [installed]
gettext/xenial-updates,xenial-security,now 0.19.7-2ubuntu3.1 i386 
[installed]

So slightly behind your versions.

>> This is on Ubuntu 16.04  Is this a problem with the VIM po source or
>> lack or installed tooling?
> 
> I am not sure yet. What does the raw generated utf-8 file tmp_gvim.desktop 
> look like?

It looks like the last byte of the last character has been dropped in 
processing.  The .in file has the UTF-8 sequence 0xe0 0xad 0x81 0x0a for 
the last character and the newline, but the tmp file has  0xe0 0xad 0x0a 
which is an invalid UTF-8 sequence.  Removing the line from both the .in 
files allows make to run to completion with no errors.

This looks like a bug in msgfmt which should not be emitting invalid 
UTF-8 sequences.  In the meantime this will break all builds on U16.04. :(

TTFN

Mike
-- 
If you're not making waves, you're not rowing the boat.

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

--- 
You received this message because you are subscribed to the Google Groups 
"vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/vim_dev/d39ef65a-5ed1-0c28-a901-a1e2e5464586%40globalgraphics.com.
For more options, visit https://groups.google.com/d/optout.

Re: Patch 8.1.1468

[Mike Williams]

Hi

On 05/06/2019 20:25, Bram Moolenaar wrote:
> 
> Patch 8.1.1468
> Problem:The generated desktop files may be invalid.
> Solution:   Check validity with desktop-file-validate. (Christian Brabandt,
>  Will Thompson, closes #4480)
> Files:src/po/Makefile
> 

A clean build and install is now reporting the following warnings and 
errors:

msgfmt --desktop -d . --template gvim.desktop.in -o tmp_gvim.desktop
rm -f LINGUAS
if command -v desktop-file-validate; then desktop-file-validate 
tmp_gvim.desktop; fi
/usr/bin/desktop-file-validate
tmp_gvim.desktop: warning: file contains lines that are not UTF-8 
encoded. There is no guarantee the validator will correctly work.
tmp_gvim.desktop: error: file contains multiple keys named 
"GenericName[eo]" in group "Desktop Entry"
tmp_gvim.desktop: error: file contains multiple keys named "Comment[eo]" 
in group "Desktop Entry"
[Invalid UTF-8] tmp_gvim.desktop: error: value 
"\xe0\xac\xaa\xe0\xac\xbe\xe0\xac\xa0\xe0\xad\x8d\xe0\xac\xaf 
\xe0\xac\xab\xe0\xac\xbe\xe0\xac\x87\xe0\xac\xb2\xe0\xac\x97\xe0\xad\x81\xe0\xac\xa1\xe0\xac\xbc\xe0\xac\xbf\xe0\xac\x95\xe0\xad\x81
 
\xe0\xac\xb8\xe0\xac\xae\xe0\xad\x8d\xe0\xac\xaa\xe0\xac\xbe\xe0\xac\xa6\xe0\xac\xa8
 
\xe0\xac\x95\xe0\xac\xb0\xe0\xac\xa8\xe0\xad\x8d\xe0\xac\xa4\xe0\xad" 
for locale string key "Comment[or]" in group "Desktop Entry" contains 
invalid UTF-8 characters, locale string values should be encoded in UTF-8
Makefile:176: recipe for target 'gvim.desktop' failed
make[2]: *** [gvim.desktop] Error 1
make[2]: Leaving directory '/home/mikew/repos/vim/src/po'
Makefile:2021: recipe for target 'languages' failed
make[1]: *** [languages] Error 2
make[1]: Leaving directory '/home/mikew/repos/vim/src'
Makefile:26: recipe for target 'first' failed
make: *** [first] Error 2

This is on Ubuntu 16.04  Is this a problem with the VIM po source or 
lack or installed tooling?

TTFN

Mike
-- 
Why do they call it the rush hour when nothing moves?

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

--- 
You received this message because you are subscribed to the Google Groups 
"vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/vim_dev/6f3a9963-fb0a-b434-da7d-c449ad52011c%40globalgraphics.com.
For more options, visit https://groups.google.com/d/optout.

Re: resolve() on Windows breaking change

[Mike Williams]

Hi Ken

On 05/06/2019 11:56, Ken Takata wrote:
> Hi,
> 
> 2019/6/5 Wed 5:25:13 UTC+9 Mike Williams wrote:
>> On 04/06/2019 19:18, Bram Moolenaar wrote:
>>>
>>> Mike Williams wrote:
>>>
>>>> It looks like the change to Windows for resolve() in 8.1.1417 was a
>>>> breaking change.  I use the NERDtree plugin and any build after than
>>>> change results in NERDtree reports plain files on Windows as links.  See
>>>> attached image.
>>>>
>>>> I guess the question is. is this wrong in VIM or a bad assumption in
>>>> NERDtree in what resolve() returns?  Since it is a breaking change in
>>>> VIM I thought I would start the ball rolling here.
>>>
>>> Perhaps NERDtree checks if the returned path is a full path?
>>> Assuming you still have the older Vim version, compare the output of
>>> resolve() for some simple files, is it different?
>>
>> It is different.  8.1.1416 does not return a full path for simple files
>> while 8.1.1417 onwards does.
>>
>>> The docs say:
>>> On MS-Windows, when {filename} is a shortcut (a .lnk file),
>>> returns the path the shortcut points to in a simplified form.
>>> When {filename} is a symbolic link or junction point, return
>>> the full path to the target. If the target of junction is
>>> removed, return {filename}.
>>>
>>> It says some more about a simplified result.  But that wasn't changed.
>>
>> Based on the above it means that there is no way to tell the difference
>> between a simple file and a symbolic link or junction point, getftype()
>> does not help on Windows.  But perhaps that does not matter.
>>
>> Spelunking in NERDtree the root cause of the problem is directory
>> separators.  It seems a bit free in always using '/' when building
>> paths.  Now that resolve() returns a full path filepath checks based on
>> string comparison fails.  A local hack^wfix confirms this but NERDtree
>> is still able to detect symbolic links so there must some other method
>> to distinguish that I am not aware of.
>>
>> I'll bounce over to GitHub to report this.
>>
>> TTFN
>>
>> Mike
> 
> I created a PR for this: https://github.com/vim/vim/pull/4492

Many thanks for this.  Bonus points for extending getftype() to work 
under Windows for consistency with what resolve() returns ;-)

TTFN

Mike
-- 
If nodding means yes, why doesn't yesding mean no?

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

--- 
You received this message because you are subscribed to the Google Groups 
"vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/vim_dev/6330f627-17c8-c9e6-3794-5ab8994cadde%40globalgraphics.com.
For more options, visit https://groups.google.com/d/optout.

Re: resolve() on Windows breaking change

[Mike Williams]

On 04/06/2019 19:18, Bram Moolenaar wrote:
> 
> Mike Williams wrote:
> 
>> It looks like the change to Windows for resolve() in 8.1.1417 was a
>> breaking change.  I use the NERDtree plugin and any build after than
>> change results in NERDtree reports plain files on Windows as links.  See
>> attached image.
>>
>> I guess the question is. is this wrong in VIM or a bad assumption in
>> NERDtree in what resolve() returns?  Since it is a breaking change in
>> VIM I thought I would start the ball rolling here.
> 
> Perhaps NERDtree checks if the returned path is a full path?
> Assuming you still have the older Vim version, compare the output of
> resolve() for some simple files, is it different?

It is different.  8.1.1416 does not return a full path for simple files 
while 8.1.1417 onwards does.

> The docs say:
>   On MS-Windows, when {filename} is a shortcut (a .lnk file),
>   returns the path the shortcut points to in a simplified form.
>   When {filename} is a symbolic link or junction point, return
>   the full path to the target. If the target of junction is
>   removed, return {filename}.
> 
> It says some more about a simplified result.  But that wasn't changed.

Based on the above it means that there is no way to tell the difference 
between a simple file and a symbolic link or junction point, getftype() 
does not help on Windows.  But perhaps that does not matter.

Spelunking in NERDtree the root cause of the problem is directory 
separators.  It seems a bit free in always using '/' when building 
paths.  Now that resolve() returns a full path filepath checks based on 
string comparison fails.  A local hack^wfix confirms this but NERDtree 
is still able to detect symbolic links so there must some other method 
to distinguish that I am not aware of.

I'll bounce over to GitHub to report this.

TTFN

Mike
-- 
Never use a long word when a diminutive one will do.

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

--- 
You received this message because you are subscribed to the Google Groups 
"vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/vim_dev/7ddb6715-ccc8-14c4-39a0-6f8c322e32e1%40globalgraphics.com.
For more options, visit https://groups.google.com/d/optout.

resolve() on Windows breaking change

[Mike Williams]

Hi,

It looks like the change to Windows for resolve() in 8.1.1417 was a
breaking change.  I use the NERDtree plugin and any build after than
change results in NERDtree reports plain files on Windows as links.  See
attached image.

I guess the question is. is this wrong in VIM or a bad assumption in
NERDtree in what resolve() returns?  Since it is a breaking change in
VIM I thought I would start the ball rolling here.

TTFN

Mike
--
The search for happiness is one of the chief sources of unhappiness.

[Break through to drupa 2020 - find out 
more]

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

--- 
You received this message because you are subscribed to the Google Groups 
"vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/vim_dev/b87ef8ca-499b-0d1f-f01c-1f1ca2a4c59e%40globalgraphics.com.
For more options, visit https://groups.google.com/d/optout.

Internal diff doesn't show binary files diffs

[Mike Williams]

Hi,

The switch to the internal diff has stopped diffs on binary data files 
from working.  This used to work with the default values for diffopt and 
diffexpr in 8.1.0359.  Now vim detects there is a difference, showing 
closed regions where there are no differences, but fails to highlight 
the actual difference.  (FWIW the closed region is also different to the 
one before internal diff was added - not too worried about that, just 
seeing the actual difference.)  I have attached two small binary files 
with a single byte difference between them.

Is the intent that the internal diff should be a direct replacement for 
plain vanilla diff command or does it have known limitations like this?

Of course I may be strange in wanting to diff binary data, but at times 
it is a quick way to detect small changes in otherwise large complex 
encoded files.

TTFN

Mike
-- 
Is this a five minute argument, or a full half hour?

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

--- 
You received this message because you are subscribed to the Google Groups 
"vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


binary
Description: binary


binary2
Description: binary2

Re: Windows console keypad support

[Mike Williams]

On 03/10/2018 19:44, Bram Moolenaar wrote:
> 
> Mike Williams wrote:
> 
>>>> Long term user, occasional poster.
>>>>
>>>> I occasionally use vim in powershell or cmd consoles.  I have just
>>>> noticed that numbers on the keypad don't work.  All the surrounding keys
>>>> work just fine, but the numbers don't.  With -u NONE -UNONE and NumLock
>>>> on I get a lead byte of 0xce followed by 0xda (for 0) through 0xfe (for
>>>> 9) - each digit is offset by 4 from the previous one.
>>>>
>>>> With NumLock off there are no buffer updates for the number keys and
>>>> decimal point but various types of cursor/display updates occur (life's
>>>> too short to investigate 11 distinct actions with non-obvious effects).
>>>> The remaining keypad keys continue to insert expected characters.
>>>>
>>>> I rebuild 8.1. and the same happens there.  I could have sworn it
>>>> used to work.  A quick google doesn't turn up anything obvious (some
>>>> discussion of console/keypad issues and WSL a year ago or so).  Should
>>>> the keypad work in console vim?
>>>
>>> Small light bulb moment.  As you all know I am sure with NumLock off the
>>> keypad acts as the cursor movement set.  That just leaves my question of
>>> should the number pad with NumLock on result in digits being added to
>>> the buffer?
>>>
>>> Debugging the code in decode_key_event() I can see the keys being
>>> detected and handled as not being used with a modifier which results in
>>> mch_inchar() inserting K_NUL and an 8-bit character in the type ahead
>>> buffer.  In fact based on the VirtKeyMap table any of the listed keys
>>> (some with modifiers) that produce an 8-bit character ends up inserting
>>> a character sequence and not being detected as a special key press.
>>>
>>> Removing the numbers from VirtKeyMap table -
>>>
>>> diff --git a/src/os_win32.c b/src/os_win32.c
>>> --- a/src/os_win32.c
>>> +++ b/src/os_win32.c
>>> @@ -908,7 +908,7 @@ static const struct
>>> { VK_SUBTRACT, TRUE,'J',   'J','J','J',}, /* keyp '-' */
>>>  /* { VK_DIVIDE,   TRUE,'N',   'N','N','N',},keyp '/' */
>>> { VK_MULTIPLY, TRUE,'7',   '7','7','7',}, /* keyp '*' */
>>> -
>>> +#if 0
>>> { VK_NUMPAD0,TRUE,  '\332','\333', '\334', '\335', },
>>> { VK_NUMPAD1,TRUE,  '\336','\337', '\340', '\341', },
>>> { VK_NUMPAD2,TRUE,  '\342','\343', '\344', '\345', },
>>> @@ -920,7 +920,7 @@ static const struct
>>> { VK_NUMPAD8,TRUE,  '\372','\373', '\374', '\375', },
>>> /* Sorry, out of number space! */
>>> { VK_NUMPAD9,TRUE,  '\376','\377', '\377', '\367', },
>>> -
>>> +#endif
>>> };
>>>
>>>
>>> gets me the number keys working with NumLock on, but I have no idea on
>>> the effect with modifiers yet.  I doubt this is the complete solution,
>>> but I don't know how the key handling works in VIM.  Anyone willing to
>>> pick this up or tell me what needs doing?
>>
>> I believe have a fix for all this.  It was a combination of poor code
>> and the change for 8.0.1371 which exposed it - chars with top bit set
>> are negative (at least with MSVC) which causes the wrong path in newer
>> code to be taken.  Converting the 8bit chars to positive integer
>> constants appears to fix the issue and more - see attached diff against
>> 8.1.0450.
>>
>> This does raise the longer term issue of should console handling still
>> be emulating MS-DOS ANSI.SYS behaviour?  Native console key handling
>> would remove the whole issue of key mapping - as noted in original code,
>> there aren't enough values for all keys and combinations!
> 
> Thanks for taking the time to look into this.  I'll include the patch.
> 
> This is indeed very old code.  But it appears to just work.  It might be
> quite a bit of work to make something else, and then the question is if
> it's going to be better?  So what will we gain?

The code seems error prone - occasional dives by various people to fix 
isolated things seem to end up breaking other things.  Mixing olde 
MSDOS, current console, and VIM term sequences doesn't make it easy to 
see what it should be doing.  At this stage the handling of modifiers 
does not seem to be working.

As noted elsewhere my change effectively undoes the fix for 8.0.1371 - 
that seems to have broken more things than it fixed.  I'll see what I 
can do.

TTFN

Mike
-- 
A fool and his money are soon audited.

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

--- 
You received this message because you are subscribed to the Google Groups 
"vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Windows console keypad support

[Mike Williams]

On 03/10/2018 20:43, Christian Brabandt wrote:
> 
> On Mi, 03 Okt 2018, Mike Williams wrote:
> 
>> On 29/09/2018 10:50, Mike Williams wrote:
>>> On 25/09/2018 13:46, Mike Williams wrote:
>>>> Hi,
>>>>
>>>> Long term user, occasional poster.
>>>>
>>>> I occasionally use vim in powershell or cmd consoles.  I have just
>>>> noticed that numbers on the keypad don't work.  All the surrounding keys
>>>> work just fine, but the numbers don't.  With -u NONE -UNONE and NumLock
>>>> on I get a lead byte of 0xce followed by 0xda (for 0) through 0xfe (for
>>>> 9) - each digit is offset by 4 from the previous one.
>>>>
>>>> With NumLock off there are no buffer updates for the number keys and
>>>> decimal point but various types of cursor/display updates occur (life's
>>>> too short to investigate 11 distinct actions with non-obvious effects).
>>>> The remaining keypad keys continue to insert expected characters.
>>>>
>>>> I rebuild 8.1. and the same happens there.  I could have sworn it
>>>> used to work.  A quick google doesn't turn up anything obvious (some
>>>> discussion of console/keypad issues and WSL a year ago or so).  Should
>>>> the keypad work in console vim?
>>>
>>> Small light bulb moment.  As you all know I am sure with NumLock off the
>>> keypad acts as the cursor movement set.  That just leaves my question of
>>> should the number pad with NumLock on result in digits being added to
>>> the buffer?
>>>
>>> Debugging the code in decode_key_event() I can see the keys being
>>> detected and handled as not being used with a modifier which results in
>>> mch_inchar() inserting K_NUL and an 8-bit character in the type ahead
>>> buffer.  In fact based on the VirtKeyMap table any of the listed keys
>>> (some with modifiers) that produce an 8-bit character ends up inserting
>>> a character sequence and not being detected as a special key press.
>>>
>>> Removing the numbers from VirtKeyMap table -
>>>
>>> diff --git a/src/os_win32.c b/src/os_win32.c
>>> --- a/src/os_win32.c
>>> +++ b/src/os_win32.c
>>> @@ -908,7 +908,7 @@ static const struct
>>> { VK_SUBTRACT, TRUE,'J',   'J','J','J',}, /* keyp '-' */
>>>  /* { VK_DIVIDE,   TRUE,'N',   'N','N','N',},keyp '/' */
>>> { VK_MULTIPLY, TRUE,'7',   '7','7','7',}, /* keyp '*' */
>>> -
>>> +#if 0
>>> { VK_NUMPAD0,TRUE,  '\332','\333', '\334', '\335', },
>>> { VK_NUMPAD1,TRUE,  '\336','\337', '\340', '\341', },
>>> { VK_NUMPAD2,TRUE,  '\342','\343', '\344', '\345', },
>>> @@ -920,7 +920,7 @@ static const struct
>>> { VK_NUMPAD8,TRUE,  '\372','\373', '\374', '\375', },
>>> /* Sorry, out of number space! */
>>> { VK_NUMPAD9,TRUE,  '\376','\377', '\377', '\367', },
>>> -
>>> +#endif
>>> };
>>>
>>>
>>> gets me the number keys working with NumLock on, but I have no idea on
>>> the effect with modifiers yet.  I doubt this is the complete solution,
>>> but I don't know how the key handling works in VIM.  Anyone willing to
>>> pick this up or tell me what needs doing?
>>
>> I believe have a fix for all this.  It was a combination of poor code
>> and the change for 8.0.1371 which exposed it - chars with top bit set
>> are negative (at least with MSVC) which causes the wrong path in newer
>> code to be taken.  Converting the 8bit chars to positive integer
>> constants appears to fix the issue and more - see attached diff against
>> 8.1.0450.
>>
>> This does raise the longer term issue of should console handling still
>> be emulating MS-DOS ANSI.SYS behaviour?  Native console key handling
>> would remove the whole issue of key mapping - as noted in original code,
>> there aren't enough values for all keys and combinations!
> 
> Does that perhaps also fix https://github.com/vim/vim/issues/3246 and
> https://github.com/vim/vim/issues/3423 ?

It does fix 3246.  It seems to fix 3423 but it is not a method of using 
VIM that I use so I am not 100% certain.

However this fix does break what 8.0.1371 kinda fixed - shift-ins 
support.  This means that fix was not the right one so I'll look into 
that now I have a bit more knowledge of the area.

TTFN

Mike
-- 
It's easy to apply yourself, just use crazy glue!

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

--- 
You received this message because you are subscribed to the Google Groups 
"vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Windows console keypad support

[Mike Williams]

On 29/09/2018 10:50, Mike Williams wrote:
> On 25/09/2018 13:46, Mike Williams wrote:
>> Hi,
>>
>> Long term user, occasional poster.
>>
>> I occasionally use vim in powershell or cmd consoles.  I have just
>> noticed that numbers on the keypad don't work.  All the surrounding keys
>> work just fine, but the numbers don't.  With -u NONE -UNONE and NumLock
>> on I get a lead byte of 0xce followed by 0xda (for 0) through 0xfe (for
>> 9) - each digit is offset by 4 from the previous one.
>>
>> With NumLock off there are no buffer updates for the number keys and
>> decimal point but various types of cursor/display updates occur (life's
>> too short to investigate 11 distinct actions with non-obvious effects).
>> The remaining keypad keys continue to insert expected characters.
>>
>> I rebuild 8.1. and the same happens there.  I could have sworn it
>> used to work.  A quick google doesn't turn up anything obvious (some
>> discussion of console/keypad issues and WSL a year ago or so).  Should
>> the keypad work in console vim?
> 
> Small light bulb moment.  As you all know I am sure with NumLock off the
> keypad acts as the cursor movement set.  That just leaves my question of
> should the number pad with NumLock on result in digits being added to
> the buffer?
> 
> Debugging the code in decode_key_event() I can see the keys being
> detected and handled as not being used with a modifier which results in
> mch_inchar() inserting K_NUL and an 8-bit character in the type ahead
> buffer.  In fact based on the VirtKeyMap table any of the listed keys
> (some with modifiers) that produce an 8-bit character ends up inserting
> a character sequence and not being detected as a special key press.
> 
> Removing the numbers from VirtKeyMap table -
> 
> diff --git a/src/os_win32.c b/src/os_win32.c
> --- a/src/os_win32.c
> +++ b/src/os_win32.c
> @@ -908,7 +908,7 @@ static const struct
>{ VK_SUBTRACT, TRUE,'J',   'J','J','J',}, /* keyp '-' */
> /* { VK_DIVIDE,   TRUE,'N',   'N','N','N',},keyp '/' */
>{ VK_MULTIPLY, TRUE,'7',   '7','7','7',}, /* keyp '*' */
> -
> +#if 0
>{ VK_NUMPAD0,TRUE,  '\332','\333', '\334', '\335', },
>{ VK_NUMPAD1,TRUE,  '\336','\337', '\340', '\341', },
>{ VK_NUMPAD2,TRUE,  '\342','\343', '\344', '\345', },
> @@ -920,7 +920,7 @@ static const struct
>{ VK_NUMPAD8,TRUE,  '\372','\373', '\374', '\375', },
>/* Sorry, out of number space! */
>{ VK_NUMPAD9,TRUE,  '\376','\377', '\377', '\367', },
> -
> +#endif
>};
> 
> 
> gets me the number keys working with NumLock on, but I have no idea on
> the effect with modifiers yet.  I doubt this is the complete solution,
> but I don't know how the key handling works in VIM.  Anyone willing to
> pick this up or tell me what needs doing?

I believe have a fix for all this.  It was a combination of poor code 
and the change for 8.0.1371 which exposed it - chars with top bit set 
are negative (at least with MSVC) which causes the wrong path in newer 
code to be taken.  Converting the 8bit chars to positive integer 
constants appears to fix the issue and more - see attached diff against 
8.1.0450.

This does raise the longer term issue of should console handling still 
be emulating MS-DOS ANSI.SYS behaviour?  Native console key handling 
would remove the whole issue of key mapping - as noted in original code, 
there aren't enough values for all keys and combinations!

HTH - TTFN

Mike
-- 
Hell hath no fury like a vested interest masquerading as a moral principle.

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

--- 
You received this message because you are subscribed to the Google Groups 
"vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
diff --git a/src/os_win32.c b/src/os_win32.c
--- a/src/os_win32.c
+++ b/src/os_win32.c
@@ -861,49 +861,49 @@ static const struct
 { VK_F8,   TRUE,   'B','[','e','o', },
 { VK_F9,   TRUE,   'C','\\',   'f','p', },
 { VK_F10,  TRUE,   'D',']','g','q', },
-{ VK_F11,  TRUE,   '\205', '\207', '\211', '\213', },
-{ VK_F12,  TRUE,   '\206', '\210', '\212', '\214', },
-
-{ VK_HOME, TRUE,   'G','\302', 'w','\303', },
-{ VK_UP,   TRUE,   'H','\304', '\305', '\306', },
-{ VK_PRIOR,TRUE,   'I','\307', '\204', '\310

Re: Windows console keypad support

[Mike Williams]

On 25/09/2018 13:46, Mike Williams wrote:

Hi,

Long term user, occasional poster.

I occasionally use vim in powershell or cmd consoles.  I have just
noticed that numbers on the keypad don't work.  All the surrounding keys
work just fine, but the numbers don't.  With -u NONE -UNONE and NumLock
on I get a lead byte of 0xce followed by 0xda (for 0) through 0xfe (for
9) - each digit is offset by 4 from the previous one.

With NumLock off there are no buffer updates for the number keys and
decimal point but various types of cursor/display updates occur (life's
too short to investigate 11 distinct actions with non-obvious effects).
The remaining keypad keys continue to insert expected characters.

I rebuild 8.1. and the same happens there.  I could have sworn it
used to work.  A quick google doesn't turn up anything obvious (some
discussion of console/keypad issues and WSL a year ago or so).  Should
the keypad work in console vim?


Small light bulb moment.  As you all know I am sure with NumLock off the 
keypad acts as the cursor movement set.  That just leaves my question of 
should the number pad with NumLock on result in digits being added to 
the buffer?


Debugging the code in decode_key_event() I can see the keys being 
detected and handled as not being used with a modifier which results in 
mch_inchar() inserting K_NUL and an 8-bit character in the type ahead 
buffer.  In fact based on the VirtKeyMap table any of the listed keys 
(some with modifiers) that produce an 8-bit character ends up inserting 
a character sequence and not being detected as a special key press.


Removing the numbers from VirtKeyMap table -

diff --git a/src/os_win32.c b/src/os_win32.c
--- a/src/os_win32.c
+++ b/src/os_win32.c
@@ -908,7 +908,7 @@ static const struct
 { VK_SUBTRACT, TRUE,'J',   'J','J','J',}, /* keyp '-' */
  /* { VK_DIVIDE,   TRUE,'N',   'N','N','N',},keyp '/' */
 { VK_MULTIPLY, TRUE,'7',   '7','7','7',}, /* keyp '*' */
-
+#if 0
 { VK_NUMPAD0,TRUE,  '\332','\333', '\334', '\335', },
 { VK_NUMPAD1,TRUE,  '\336','\337', '\340', '\341', },
 { VK_NUMPAD2,TRUE,  '\342','\343', '\344', '\345', },
@@ -920,7 +920,7 @@ static const struct
 { VK_NUMPAD8,TRUE,  '\372','\373', '\374', '\375', },
 /* Sorry, out of number space! */
 { VK_NUMPAD9,TRUE,  '\376','\377', '\377', '\367', },
-
+#endif
 };


gets me the number keys working with NumLock on, but I have no idea on 
the effect with modifiers yet.  I doubt this is the complete solution, 
but I don't know how the key handling works in VIM.  Anyone willing to 
pick this up or tell me what needs doing?


TTFN
Mike
--
WANTED: Small person to work as Mudflap. Must be flexible.

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

--- 
You received this message because you are subscribed to the Google Groups "vim_dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Windows console keypad support

[Mike Williams]

Hi,

Long term user, occasional poster.

I occasionally use vim in powershell or cmd consoles.  I have just 
noticed that numbers on the keypad don't work.  All the surrounding keys 
work just fine, but the numbers don't.  With -u NONE -UNONE and NumLock 
on I get a lead byte of 0xce followed by 0xda (for 0) through 0xfe (for 
9) - each digit is offset by 4 from the previous one.


With NumLock off there are no buffer updates for the number keys and 
decimal point but various types of cursor/display updates occur (life's 
too short to investigate 11 distinct actions with non-obvious effects). 
The remaining keypad keys continue to insert expected characters.


I rebuild 8.1. and the same happens there.  I could have sworn it 
used to work.  A quick google doesn't turn up anything obvious (some 
discussion of console/keypad issues and WSL a year ago or so).  Should 
the keypad work in console vim?


TTFN

Mike
--
Violence never settles anything. - Ghengis Kahn.

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

--- 
You received this message because you are subscribed to the Google Groups "vim_dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Patch 8.0.1807

[Mike Williams]

On 10/05/2018 13:38, Mike Williams wrote:

Hi,

This is a bad patch - it breaks Windows builds.  Many issues ...


... and fixed by 8.07.1808 pushed mere minutes after I sent this. 
Nothing to see, move along.



term.c(1593): warning C4013: 'TGETSTR' undefined; assuming extern
returning int
term.c(1593): warning C4047: '=': 'char_u *' differs in levels of
indirection from 'int'
term.c(1598): warning C4013: 'tgetflag' undefined; assuming extern
returning int
term.c(1614): error C2065: 'key_names': undeclared identifier
term.c(1614): error C2109: subscript requires array or pointer type
term.c(1615): error C2065: 'key_names': undeclared identifier
term.c(1615): error C2109: subscript requires array or pointer type
term.c(1615): error C2198: 'find_termcode': too few arguments for call
term.c(1617): error C2065: 'key_names': undeclared identifier
term.c(1617): error C2109: subscript requires array or pointer type
term.c(1617): warning C4047: '=': 'char_u *' differs in levels of
indirection from 'int'
term.c(1621): error C2065: 'key_names': undeclared identifier
term.c(1621): error C2109: subscript requires array or pointer type
term.c(1622): error C2065: 'key_names': undeclared identifier
term.c(1622): error C2109: subscript requires array or pointer type
term.c(1623): error C2065: 'key_names': undeclared identifier
term.c(1623): error C2109: subscript requires array or pointer type
term.c(1623): error C2198: 'add_termcode': too few arguments for call
term.c(1627): warning C4013: 'tgetnum' undefined; assuming extern
returning int
term.c(1638): error C2065: 'BC': undeclared identifier
term.c(1638): warning C4047: '=': 'int' differs in levels of indirection
from 'char *'
term.c(1639): error C2065: 'UP': undeclared identifier
term.c(1639): warning C4047: '=': 'int' differs in levels of indirection
from 'char *'
term.c(1640): warning C4047: '=': 'char_u *' differs in levels of
indirection from 'int'
term.c(1642): error C2065: 'PC': undeclared identifier

HTH - TTFN

On 10/05/2018 13:12, Bram Moolenaar wrote:


Patch 8.0.1807
Problem:Function to set terminal name is too long.
Solution:   Refactor the function.  Fix typo in test.
Files:  src/term.c, src/testdir/test_options.vim


*** ../vim-8.0.1806/src/term.c  2018-05-05 14:29:02.421738251 +0200
--- src/term.c  2018-05-10 14:04:24.041744391 +0200
***
*** 1544,1549 
--- 1544,1693 
};
#endif

+ static void

+ get_term_entries(int *height, int *width)
+ {
+ static struct {
+   enum SpecialKey dest; /* index in term_strings[] */
+   char *name;   /* termcap name for string */
+ } string_names[] =
+   {   {KS_CE, "ce"}, {KS_AL, "al"}, {KS_CAL,"AL"},
+   {KS_DL, "dl"}, {KS_CDL,"DL"}, {KS_CS, "cs"},
+   {KS_CL, "cl"}, {KS_CD, "cd"},
+   {KS_VI, "vi"}, {KS_VE, "ve"}, {KS_MB, "mb"},
+   {KS_ME, "me"}, {KS_MR, "mr"},
+   {KS_MD, "md"}, {KS_SE, "se"}, {KS_SO, "so"},
+   {KS_CZH,"ZH"}, {KS_CZR,"ZR"}, {KS_UE, "ue"},
+   {KS_US, "us"}, {KS_UCE, "Ce"}, {KS_UCS, "Cs"},
+   {KS_STE,"Te"}, {KS_STS,"Ts"},
+   {KS_CM, "cm"}, {KS_SR, "sr"},
+   {KS_CRI,"RI"}, {KS_VB, "vb"}, {KS_KS, "ks"},
+   {KS_KE, "ke"}, {KS_TI, "ti"}, {KS_TE, "te"},
+   {KS_BC, "bc"}, {KS_CSB,"Sb"}, {KS_CSF,"Sf"},
+   {KS_CAB,"AB"}, {KS_CAF,"AF"}, {KS_LE, "le"},
+   {KS_ND, "nd"}, {KS_OP, "op"}, {KS_CRV, "RV"},
+   {KS_VS, "vs"}, {KS_CVS, "VS"},
+   {KS_CIS, "IS"}, {KS_CIE, "IE"},
+   {KS_CSC, "SC"}, {KS_CEC, "EC"},
+   {KS_TS, "ts"}, {KS_FS, "fs"},
+   {KS_CWP, "WP"}, {KS_CWS, "WS"},
+   {KS_CSI, "SI"}, {KS_CEI, "EI"},
+   {KS_U7, "u7"}, {KS_RFG, "RF"}, {KS_RBG, "RB"},
+   {KS_8F, "8f"}, {KS_8B, "8b"},
+   {KS_CBE, "BE"}, {KS_CBD, "BD"},
+   {KS_CPS, "PS"}, {KS_CPE, "PE"},
+   {(enum SpecialKey)0, NULL}
+   };
+ int   i;
+ char_u*p;

Re: Patch 8.0.1807

[Mike Williams]

Hi,

This is a bad patch - it breaks Windows builds.  Many issues ...

term.c(1593): warning C4013: 'TGETSTR' undefined; assuming extern 
returning int
term.c(1593): warning C4047: '=': 'char_u *' differs in levels of 
indirection from 'int'
term.c(1598): warning C4013: 'tgetflag' undefined; assuming extern 
returning int

term.c(1614): error C2065: 'key_names': undeclared identifier
term.c(1614): error C2109: subscript requires array or pointer type
term.c(1615): error C2065: 'key_names': undeclared identifier
term.c(1615): error C2109: subscript requires array or pointer type
term.c(1615): error C2198: 'find_termcode': too few arguments for call
term.c(1617): error C2065: 'key_names': undeclared identifier
term.c(1617): error C2109: subscript requires array or pointer type
term.c(1617): warning C4047: '=': 'char_u *' differs in levels of 
indirection from 'int'

term.c(1621): error C2065: 'key_names': undeclared identifier
term.c(1621): error C2109: subscript requires array or pointer type
term.c(1622): error C2065: 'key_names': undeclared identifier
term.c(1622): error C2109: subscript requires array or pointer type
term.c(1623): error C2065: 'key_names': undeclared identifier
term.c(1623): error C2109: subscript requires array or pointer type
term.c(1623): error C2198: 'add_termcode': too few arguments for call
term.c(1627): warning C4013: 'tgetnum' undefined; assuming extern 
returning int

term.c(1638): error C2065: 'BC': undeclared identifier
term.c(1638): warning C4047: '=': 'int' differs in levels of indirection 
from 'char *'

term.c(1639): error C2065: 'UP': undeclared identifier
term.c(1639): warning C4047: '=': 'int' differs in levels of indirection 
from 'char *'
term.c(1640): warning C4047: '=': 'char_u *' differs in levels of 
indirection from 'int'

term.c(1642): error C2065: 'PC': undeclared identifier

HTH - TTFN

On 10/05/2018 13:12, Bram Moolenaar wrote:


Patch 8.0.1807
Problem:Function to set terminal name is too long.
Solution:   Refactor the function.  Fix typo in test.
Files:  src/term.c, src/testdir/test_options.vim


*** ../vim-8.0.1806/src/term.c  2018-05-05 14:29:02.421738251 +0200
--- src/term.c  2018-05-10 14:04:24.041744391 +0200
***
*** 1544,1549 
--- 1544,1693 
   };
   #endif
   
+ static void

+ get_term_entries(int *height, int *width)
+ {
+ static struct {
+   enum SpecialKey dest; /* index in term_strings[] */
+   char *name;   /* termcap name for string */
+ } string_names[] =
+   {   {KS_CE, "ce"}, {KS_AL, "al"}, {KS_CAL,"AL"},
+   {KS_DL, "dl"}, {KS_CDL,"DL"}, {KS_CS, "cs"},
+   {KS_CL, "cl"}, {KS_CD, "cd"},
+   {KS_VI, "vi"}, {KS_VE, "ve"}, {KS_MB, "mb"},
+   {KS_ME, "me"}, {KS_MR, "mr"},
+   {KS_MD, "md"}, {KS_SE, "se"}, {KS_SO, "so"},
+   {KS_CZH,"ZH"}, {KS_CZR,"ZR"}, {KS_UE, "ue"},
+   {KS_US, "us"}, {KS_UCE, "Ce"}, {KS_UCS, "Cs"},
+   {KS_STE,"Te"}, {KS_STS,"Ts"},
+   {KS_CM, "cm"}, {KS_SR, "sr"},
+   {KS_CRI,"RI"}, {KS_VB, "vb"}, {KS_KS, "ks"},
+   {KS_KE, "ke"}, {KS_TI, "ti"}, {KS_TE, "te"},
+   {KS_BC, "bc"}, {KS_CSB,"Sb"}, {KS_CSF,"Sf"},
+   {KS_CAB,"AB"}, {KS_CAF,"AF"}, {KS_LE, "le"},
+   {KS_ND, "nd"}, {KS_OP, "op"}, {KS_CRV, "RV"},
+   {KS_VS, "vs"}, {KS_CVS, "VS"},
+   {KS_CIS, "IS"}, {KS_CIE, "IE"},
+   {KS_CSC, "SC"}, {KS_CEC, "EC"},
+   {KS_TS, "ts"}, {KS_FS, "fs"},
+   {KS_CWP, "WP"}, {KS_CWS, "WS"},
+   {KS_CSI, "SI"}, {KS_CEI, "EI"},
+   {KS_U7, "u7"}, {KS_RFG, "RF"}, {KS_RBG, "RB"},
+   {KS_8F, "8f"}, {KS_8B, "8b"},
+   {KS_CBE, "BE"}, {KS_CBD, "BD"},
+   {KS_CPS, "PS"}, {KS_CPE, "PE"},
+   {(enum SpecialKey)0, NULL}
+   };
+ int   i;
+ char_u*p;
+ static char_u   tstrbuf[TBUFSZ];
+ char_u*tp = tstrbuf;
+
+ /*
+  * get output strings
+  */
+ for (i = 0; string_names[i].name != NULL; ++i)
+ {
+   if (TERM_STR(string_names[i].dest) == NULL
+|| TERM_STR(string_names[i].dest) == empty_option)
+   TERM_STR(string_names[i].dest) = TGETSTR(string_names[i].name, );
+ }
+
+ /* tgetflag() returns 1 if the flag is present, 0 if not and
+  * possibly -1 if the flag doesn't exist. */
+ if ((T_MS == NULL || T_MS == empty_option) && tgetflag("ms") > 0)
+   T_MS = (char_u *)"y";
+ if ((T_XS == NULL || T_XS == empty_option) && tgetflag("xs") > 0)
+   T_XS = (char_u *)"y";
+ if ((T_XN == NULL || T_XN == 

Re: Patch 8.0.1723

[Mike Williams]

Hi

On 16/04/2018 14:16, Bram Moolenaar wrote:


I wrote:


Patch 8.0.1723
Problem:Using one item array size declaration is misleading.
Solution:   Instead of using "[1]" and actually using a larger array, use
 "[]".  This is to verify that this C99 feature works for all
 compilers.
Files:  src/structs.h, src/getchar.c


If you notice a prolem because of this patch, please speak up!
Also if it's just a compiler warning.  We want to know if this C99
feature works for everybody.


The use of unsized arrays as the last member of a structure is supported 
as an extension in MSVC, at least as far back as VS2008.  There are 
other extensions but finding a list is not trivial.  There is the /Za 
compiler option to disable the extensions, but this throws up a whole 
new bunch of compiler messages to due extensive use of the extensions in 
the system include files making spotting issues in vim code a needle in 
the haystack problem.


TTFN

Mike
--
A diplomat is a man who always remembers a woman's birthday but never 
remembers her age.


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

--- 
You received this message because you are subscribed to the Google Groups "vim_dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Is ANSI C support still needed?

[Mike Williams]

Hi

On 16/04/2018 14:16, Bram Moolenaar wrote:


Mike Williams wrote:


On 16/04/2018 01:34, James McCoy wrote:

On Sun, Apr 15, 2018 at 02:32:14PM +0200, Dominique Pellé wrote:

Bram Moolenaar <b...@moolenaar.net> wrote:


Hello Vimmers,

For a long time Vim code was made to be compiled with ANSI C (also known
as C89 and ISO C90).  This means it can also be compiled on very old
systems.  And since it wasn't too much work to support it, that was the
choice.

Now that we are adding checks for C89 compliance, it turns out that we
already are using some C99 features, such as the "long long" type.
Also, many libraries produce warnings when enforcing C89.  That means
using C89 is starting to become a hassle.  So, the question comes up: is
it still worth it?

If you CANNOT build Vim with a C99 compiler, please speak up!
If I don't hear about such cases, I think we are better off using C99 as
the standard.

Note that if we go with C99, we still need to decide what features we
will actually use, since C99 compliance was lacking for quite a while
(esp. in MS-Visual C).  That's not going to make this easier.


I would welcome C99.

gcc-4.5 has full support of C99, but many C99 features
were supported much earlier than that, see [1].

It's less clear to me when C99 features were introduced
in Visual studio. C99 support was lagging in Visual Studio.


Visual Studio doesn't fully support C99.  It supports the subset of C99
that overlaps with C++, as well as changes that could be implemented in
the standard library (i.e., didn't require compiler changes).
https://stackoverflow.com/q/9610747/198244 is a useful reference.

That will probably be enough for what Vim (and its dependencies) need.


My experience with a transition period moving to Visual Studio 2015 from
earlier versions is that the biggest issue is allowing variable
declarations to be declared anywhere within a block - it is very easy to
do.  If anyone is still using older versions this could become a regular
bump in the development road like not casting the result of STRLEN() to
an int where needed.


Are you saying that VS 2008 (the oldest that could still be used) did not
support a declaration after a statement?  If that is so we should not
allow it (at least for a while).  I don't think this is an important
restriction, putting declarations at the start of the block is always
possible.  Only including libvterm was a bit of a problem because of
this.


That is correct.  Picking some code at random I added a declaration 
after a statement ...


diff --git a/src/beval.c b/src/beval.c
--- a/src/beval.c
+++ b/src/beval.c
@@ -47,6 +47,8 @@ get_beval_info(
 {
row = Y_2_ROW(beval->y);
col = X_2_COL(beval->x);
+int j;
+j=0;
 }
 #endif
 wp = mouse_find_win(, );

... and built with VS2012, resulting in the following compiler errors 
being reported:


beval.c(50) : error C2143: syntax error : missing ';' before 'type'
beval.c(51) : error C2065: 'j' : undeclared identifier

VS2015 compiled it without complaint.  I don't have VS2008 to check 
that.  Perhaps support of C++ style language features moved in and out 
of VC over various releases, I don't know.


Trying to identify a workable subset across language standards is a 
painful process, hence my suggestion of setting a cut off date for older 
versions of VC as being an easier solution.



I just tried using VS 2008, and it seemed not to have a problem with
moving a declaration to halfway a block.  MSVC may not support C99 very
well, but this is probably a C++ feature, which they do support.


I don't know if you meant your change to main.c in path 1724.  This 
patch will only test some unix builds as the statements before it is 
only present when using X11 with a clipboard.



Designated initializers and very large arrays are concious changes in
developer habits so will be less likely if they are to be precluded for
backward MSVC support.

Perhaps the release of 8.2/9.0 could be a red flag event to only support
VS2015 and later.

My 2ps worth to the debate.


HTH - TTFN

Mike
--
If you're not part of the solution, be part of the problem!

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

--- 
You received this message because you are subscribed to the Google Groups "vim_dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Is ANSI C support still needed?

[Mike Williams]

Hiya

On 16/04/2018 01:34, James McCoy wrote:

On Sun, Apr 15, 2018 at 02:32:14PM +0200, Dominique Pellé wrote:

Bram Moolenaar  wrote:


Hello Vimmers,

For a long time Vim code was made to be compiled with ANSI C (also known
as C89 and ISO C90).  This means it can also be compiled on very old
systems.  And since it wasn't too much work to support it, that was the
choice.

Now that we are adding checks for C89 compliance, it turns out that we
already are using some C99 features, such as the "long long" type.
Also, many libraries produce warnings when enforcing C89.  That means
using C89 is starting to become a hassle.  So, the question comes up: is
it still worth it?

If you CANNOT build Vim with a C99 compiler, please speak up!
If I don't hear about such cases, I think we are better off using C99 as
the standard.

Note that if we go with C99, we still need to decide what features we
will actually use, since C99 compliance was lacking for quite a while
(esp. in MS-Visual C).  That's not going to make this easier.


I would welcome C99.

gcc-4.5 has full support of C99, but many C99 features
were supported much earlier than that, see [1].

It's less clear to me when C99 features were introduced
in Visual studio. C99 support was lagging in Visual Studio.


Visual Studio doesn't fully support C99.  It supports the subset of C99
that overlaps with C++, as well as changes that could be implemented in
the standard library (i.e., didn't require compiler changes).
https://stackoverflow.com/q/9610747/198244 is a useful reference.

That will probably be enough for what Vim (and its dependencies) need.


My experience with a transition period moving to Visual Studio 2015 from 
earlier versions is that the biggest issue is allowing variable 
declarations to be declared anywhere within a block - it is very easy to 
do.  If anyone is still using older versions this could become a regular 
bump in the development road like not casting the result of STRLEN() to 
an int where needed.


Designated initializers and very large arrays are concious changes in 
developer habits so will be less likely if they are to be precluded for 
backward MSVC support.


Perhaps the release of 8.2/9.0 could be a red flag event to only support 
VS2015 and later.


My 2ps worth to the debate.


I just thought about C99 a few days ago, when I saw a colleague
having a crash with vim, because he did not compile it with
-D_FORTIFY_SOURCE=1. The ugly compilation option won't
be needed with C99,


That would certainly be welcome.

Cheers,


TTFN

Mike
--
Reality's the only obstacle to happiness.

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

--- 
You received this message because you are subscribed to the Google Groups "vim_dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Windows gvim build failure with old SDK

[Mike Williams]

Hi

On 14/12/2017 12:15, Bram Moolenaar wrote:


Mike Williams wrote:


I have just tried to bring my windows VIM builds up to date and find the
gvim build is failing with the following error:

gui_dwrite.cpp(41) : fatal error C1083: Cannot open include file:
'dwrite_2.h': No such file or directory

This started with patch 1343 for colored emojis.

The file is from the Windows SDK 8.1 and I currently only have 8.0
installed.  If 8.1 is required then it would be nice to have a check on
version being used, something like:

#include 
#if VER_PRODUCTBUILD < whatever-magic-number-in-8.1
#error VIM DirectX support requires Windows SDK 8.1 or later.
#endif

or something helpful like that.

Apologies if I missed the memo about this, been a busy year.  Anyway,
off to track down a more recent SDK.


Looks like Ken's recent patch takes care of this.  Please give it a try
after patch 8.0.1390.


Yes, Ken's patch does resolve the build issue.  Many thanks.

TTFN

Mike
--
Does that screwdriver belong to Philip?

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

--- 
You received this message because you are subscribed to the Google Groups "vim_dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Windows gvim build failure with old SDK

[Mike Williams]

Hi,

I have just tried to bring my windows VIM builds up to date and find the 
gvim build is failing with the following error:


gui_dwrite.cpp(41) : fatal error C1083: Cannot open include file: 
'dwrite_2.h': No such file or directory


This started with patch 1343 for colored emojis.

The file is from the Windows SDK 8.1 and I currently only have 8.0 
installed.  If 8.1 is required then it would be nice to have a check on 
version being used, something like:


#include 
#if VER_PRODUCTBUILD < whatever-magic-number-in-8.1
#error VIM DirectX support requires Windows SDK 8.1 or later.
#endif

or something helpful like that.

Apologies if I missed the memo about this, been a busy year.  Anyway, 
off to track down a more recent SDK.


HTH - TTFN

Mike
--
Don't pick up that pho+>+Abe+++f NO CARRIER

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

--- 
You received this message because you are subscribed to the Google Groups "vim_dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: _UI64_MAX build error

[Mike Williams]

On 13/02/2017 19:02, Steve Hall wrote:


I've just recently starting seeing this error building on Win x64 with
Cygwin:

i686-pc-mingw32-gcc -c -Iproto -DWIN32 -DWINVER=0x0501
-D_WIN32_WINNT=0x0501 -DHAVE_PATHDEF -DFEAT_HUGE -DHAVE_STDINT_H
-DMS_WIN64 - DHAVE_GETTEXT -DHAVE_LOCALE_H -DDYNAMIC_GETTEXT
-DFEAT_CSCOPE -DFEAT_NETBEANS_INTG -DFEAT_JOB_CHANNEL -DFEAT_GUI_W32
-DFEAT_CLIPBOAR D -DFEAT_MBYTE -DFEAT_MBYTE_IME -DDYNAMIC_IME
-DDYNAMIC_ICONV -pipe -march=x86-64 -Wall -O3 -fomit-frame-pointer
-freg-struct-return -s charset.c -o gobjx86-64/charset.o
charset.c: In function 'vim_str2nr':
charset.c:1915:15: error: '_UI64_MAX' undeclared (first use in this
function)
charset.c:1915:15: note: each undeclared identifier is reported only
once for each function it appears in
charset.c:1981:15: error: '_I64_MAX' undeclared (first use in this function)
charset.c:1982:11: error: '_I64_MIN' undeclared (first use in this function)
make: *** [Make_cyg_ming.mak:887: gobjx86-64/charset.o] Error 1

Any hints?


This will be the definitions of VARNUM_MIN etc in structs.h  These are 
the MSVC constants for the min max values for 64 bit signed and unsigned 
integers.  Are these missing in the mingw32 environment?  Does it need 
an conditional include to define them?


TTFN

Mike
--
Why should I diet when the whole universe is expanding?

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

--- 
You received this message because you are subscribed to the Google Groups "vim_dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Errors found by clang UBSan

[Mike Williams]

Hi

On 19/12/2016 03:05, James McCoy wrote:

On Fri, Dec 16, 2016 at 10:51:06AM +, Mike Williams wrote:

Patch attached to limit range of parsed integer numbers, cope with 2s
complement asymmetry, and modify test that was triggering the UB warning.
Tests pass but I don't have clang to check the UB warning so please test for
that.


I found a few more places that exhibit UB.

:echo float2nr(pow(2, 33)) * float2nr(pow(2, 33))
eval.c:4085:12: runtime error: signed integer overflow: 8589934592 * 8589934592 
cannot be represented in type 'long'
#0 0x6c22e1 in eval6 /home/jamessan/src/github.com/vim/src/eval.c:4085:12
#1 0x6bf7d9 in eval5 /home/jamessan/src/github.com/vim/src/eval.c:3793:9
#2 0x6badf1 in eval4 /home/jamessan/src/github.com/vim/src/eval.c:3492:9
#3 0x6ba413 in eval3 /home/jamessan/src/github.com/vim/src/eval.c:3409:9
#4 0x66bcc3 in eval2 /home/jamessan/src/github.com/vim/src/eval.c:3341:9
#5 0x652332 in eval1 /home/jamessan/src/github.com/vim/src/eval.c:3269:9
#6 0x69703c in ex_echo /home/jamessan/src/github.com/vim/src/eval.c:8189:6
#7 0x84e8c1 in do_one_cmd 
/home/jamessan/src/github.com/vim/src/ex_docmd.c:2961:2
#8 0x82e1ef in do_cmdline 
/home/jamessan/src/github.com/vim/src/ex_docmd.c:1110:17
#9 0xcd9780 in nv_colon 
/home/jamessan/src/github.com/vim/src/normal.c:5398:15
#10 0xc7ef08 in normal_cmd 
/home/jamessan/src/github.com/vim/src/normal.c:1149:5
#11 0x14fa53b in main_loop 
/home/jamessan/src/github.com/vim/src/main.c:1311:6
#12 0x14f191e in vim_main2 
/home/jamessan/src/github.com/vim/src/main.c:877:5
#13 0x14e3529 in main /home/jamessan/src/github.com/vim/src/main.c:415:12
#14 0x7f2eddf072b0 in __libc_start_main 
(/lib/x86_64-linux-gnu/libc.so.6+0x202b0)
#15 0x41d8a9 in _start (/home/jamessan/src/github.com/vim/src/vim+0x41d8a9)

SUMMARY: AddressSanitizer: undefined-behavior eval.c:4085:12 in


:echo float2nr(pow(2, 63))
evalfunc.c:3341:29: runtime error: value 9.22337e+18 is outside the range of 
representable values of type 'long'
#0 0x6edfd9 in f_float2nr 
/home/jamessan/src/github.com/vim/src/evalfunc.c:3341:29
#1 0x6cd359 in call_internal_func 
/home/jamessan/src/github.com/vim/src/evalfunc.c:1001:5
#2 0x13a52b2 in call_func 
/home/jamessan/src/github.com/vim/src/userfunc.c:1372:14
#3 0x13a283b in get_func_tv 
/home/jamessan/src/github.com/vim/src/userfunc.c:455:8
#4 0x6c550c in eval7 /home/jamessan/src/github.com/vim/src/eval.c:4349:13
#5 0x6c1605 in eval6 /home/jamessan/src/github.com/vim/src/eval.c:3977:9
#6 0x6bf7d9 in eval5 /home/jamessan/src/github.com/vim/src/eval.c:3793:9
#7 0x6badf1 in eval4 /home/jamessan/src/github.com/vim/src/eval.c:3492:9
#8 0x6ba413 in eval3 /home/jamessan/src/github.com/vim/src/eval.c:3409:9
#9 0x66bcc3 in eval2 /home/jamessan/src/github.com/vim/src/eval.c:3341:9
#10 0x652332 in eval1 /home/jamessan/src/github.com/vim/src/eval.c:3269:9
#11 0x69703c in ex_echo /home/jamessan/src/github.com/vim/src/eval.c:8182:6
#12 0x84e6f1 in do_one_cmd 
/home/jamessan/src/github.com/vim/src/ex_docmd.c:2961:2
#13 0x82e01f in do_cmdline 
/home/jamessan/src/github.com/vim/src/ex_docmd.c:1110:17
#14 0xcd95b0 in nv_colon 
/home/jamessan/src/github.com/vim/src/normal.c:5398:15
#15 0xc7ed38 in normal_cmd 
/home/jamessan/src/github.com/vim/src/normal.c:1149:5
#16 0x14fa36b in main_loop 
/home/jamessan/src/github.com/vim/src/main.c:1311:6
#17 0x14f174e in vim_main2 
/home/jamessan/src/github.com/vim/src/main.c:877:5
#18 0x14e3359 in main /home/jamessan/src/github.com/vim/src/main.c:415:12
#19 0x7f2ded9e42b0 in __libc_start_main 
(/lib/x86_64-linux-gnu/libc.so.6+0x202b0)
#20 0x41d8a9 in _start (/home/jamessan/src/github.com/vim/src/vim+0x41d8a9)

SUMMARY: AddressSanitizer: undefined-behavior evalfunc.c:3341:29 in


:echo float2nr(pow(2, 64)) + float2nr(pow(2, 64))
eval.c:3934:12: runtime error: signed integer overflow: 9223372036854775807 + 
9223372036854775807 cannot be represented in type 'long'
#0 0x6c10d1 in eval5 /home/jamessan/src/github.com/vim/src/eval.c:3934:12
#1 0x6badf1 in eval4 /home/jamessan/src/github.com/vim/src/eval.c:3492:9
#2 0x6ba413 in eval3 /home/jamessan/src/github.com/vim/src/eval.c:3409:9
#3 0x66bcc3 in eval2 /home/jamessan/src/github.com/vim/src/eval.c:3341:9
#4 0x652332 in eval1 /home/jamessan/src/github.com/vim/src/eval.c:3269:9
#5 0x69703c in ex_echo /home/jamessan/src/github.com/vim/src/eval.c:8182:6
#6 0x84e751 in do_one_cmd 
/home/jamessan/src/github.com/vim/src/ex_docmd.c:2961:2
#7 0x82e07f in do_cmdline 
/home/jamessan/src/github.com/vim/src/ex_docmd.c:1110:17
#8 0xcd9610 in nv_colon 
/home/jamessan/src/github.com/vim/src/normal.c:5398:15
#9 0xc7ed98 in normal_cmd 
/home/jamessan/src/github.com/vim/src/normal.c:1149:5
#10 0x14fa3cb in main_loop 
/home/jamessan/src/github.com/vim/src/main.c:1311:6
#11 0x14f17ae in vim_main2 
/home/jamessan/src

Re: Errors found by clang UBSan

[Mike Williams]

On 16/12/2016 16:18, Yegappan Lakshmanan wrote:

Hi,

On Fri, Dec 16, 2016 at 2:51 AM, Mike Williams
<mike.willi...@globalgraphics.com> wrote:




Yegappan Lakshmanan wrote:


eval.c:4432:10: runtime error: negation of -9223372036854775808 cannot
be represented in type 'varnumber_T' (aka 'long long'); cast to an
unsigned type to negate this value to itself



I see it too.
It's coming from this line in Test_num64() in test_viml.vim:

call assert_equal(-9223372036854775808,  0 / 0)

Running  :echo -9223372036854775808
also gives the ubsan error.

viml parser is considering the number 9223372036854775808
(which is not a valid long long) and then negating it, instead
of considering it as number -9223372036854775808
(which is a valid long long). Not sure how it can be fix.
Even though it's undefined behavior, it probably works
on all platforms in practice.  The test would probably
fail if it did not work. But it would be good to avoid undefined
behavior.



The usual idiom for writing an integer constant for the largest negative
value 2s complement integer is to negate the largest positive value and
subtract 1.  So use (-9223372036854775807 - 1)?



Apologies.  That just solves the issue with the test and not the
underlying problem.  Caffeine took too long to kick in.

The cause is a combination of things.  eval7() parses integers as
unsigned values but uses the signed value returned from vim_str2nr()
before applying any unary minus.  In turn vim_str2nr() casts the
unsigned value of the integer to a signed value, so the value it returns
depends on whether the top bit is set from the unsigned calculation.
(Casting is lying to the compiler who will have its revenge one day -
looks like today is that day ;))

VIM doesn't signal (AFAIK) out of range integer values.  At the moment,
with the wrapping unsigned integer math in vim_str2nr(), the result for
large integers is unpredictable (for those not concerned with integer
representation)  Applying a saturating calculation would at least return
results as close as possible to the original integer value maintaining
sign.

So the simplest change would be to have vim_str2nr() saturate and return
9223372036854775807 as the largest positive varnumber_T supported.
eval7() would then apply the unary minus and return -9223372036854775807

You will still need to use -9223372036854775807 - 1 in the original test
to generate the largest negative integer value possible in VIM.



Patch attached to limit range of parsed integer numbers, cope with 2s
complement asymmetry, and modify test that was triggering the UB warning.
Tests pass but I don't have clang to check the UB warning so please test for
that.



I reran the tests with your patch (with UBSan) and the above runtime
error is resolved.


Revised patch attached - makes more use of the new value limit constants 
to remove magic constants in the source.



Only the following runtime errors are remaining:

eval.c:4068:15: runtime error: division by zero


This seems to be the following:

/* We rely on the floating point library to handle divide
 * by zero to result in "inf" and not a crash. */
f1 = f1 / f2;

Floating point division by zero is undefined behaviour.  It will need 
the idiom used elsewhere to handle the -1/0/1 / 0.0 cases to generate 
-inf/nan/inf as appropriate.


TTFN

Mike
--
'Where do these stairs go?'  'They go up.'

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

--- 
You received this message because you are subscribed to the Google Groups "vim_dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
diff --git a/src/charset.c b/src/charset.c
--- a/src/charset.c
+++ b/src/charset.c
@@ -1901,7 +1901,10 @@ vim_str2nr(
 	n += 2;	/* skip over "0b" */
 	while ('0' <= *ptr && *ptr <= '1')
 	{
-	un = 2 * un + (unsigned long)(*ptr - '0');
+	if (un < UVARNUM_MAX / 2)
+		un = 2 * un + (unsigned long)(*ptr - '0');
+	else
+		un = UVARNUM_MAX;
 	++ptr;
 	if (n++ == maxlen)
 		break;
@@ -1912,7 +1915,10 @@ vim_str2nr(
 	/* octal */
 	while ('0' <= *ptr && *ptr <= '7')
 	{
-	un = 8 * un + (uvarnumber_T)(*ptr - '0');
+	if (un < UVARNUM_MAX / 8)
+		un = 8 * un + (uvarnumber_T)(*ptr - '0');
+	else
+		un = UVARNUM_MAX;
 	++ptr;
 	if (n++ == maxlen)
 		break;
@@ -1925,7 +1931,10 @@ vim_str2nr(
 	n += 2;	/* skip over "0x" */
 	while (vim_isxdigit(*ptr))
 	{
-	un = 16 * un + (uvarnumber_T)hex2nr(*ptr);
+	if (un < UVARNUM_MAX / 16)
+		un = 16 * un + (uvarnumber_T)hex2nr(*ptr);
+	else
+		un = UVARNUM_MAX;
 	++ptr;
 	if (n++

Re: Errors found by clang UBSan

[Mike Williams]

On 14/12/2016 08:44, Dominique Pellé wrote:

Yegappan Lakshmanan wrote:

When running the Vim tests with UBSan, the following errors are
reported:

channel.c:713:5: runtime error: load of misaligned address
0x60b069ca for type 'char *', which requires 8 byte alignment
0x60b069ca: note: pointer points here


Line 713 is is this for me:

 713 memcpy((char *)_addr, host->h_addr, host->h_length);

I don't see this error with ubsan. A char* should not require 8 byte
alignment anyway. Strange.


This is a strange one.  I would guess at a compiler issue.  Stack 
overflow coughs up these somewhat related issues on OSX which I think 
you are using:


http://stackoverflow.com/questions/18821491/how-to-fix-unaligned-pointer-char#18822141
http://stackoverflow.com/questions/19916762/how-to-fix-unaligned-pointer-char?noredirect=1=1

h_addr is usually a macro to h_addr_list[0] where h_addr_list is a 
char**.  If you aren't seeing a problem it may be a false positive.


HTH - TTFN

Mike
--
As confused as a moth in a lamp store!

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

--- 
You received this message because you are subscribed to the Google Groups "vim_dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Errors found by clang UBSan

[Mike Williams]

Hi

On 16/12/2016 16:31, Dominique Pellé wrote:

Mike Williams wrote:


Tests pass but I don't have clang to check the UB warning so please test for
that.


Not sure which compiler you use, but gcc also has ubsan, if you use a version
recent enough. I don't remember in which gcc version ubsan was introduced,
probably gcc-4.8 or newer.

To use it, uncomment this line in vim/src/Makefile and rebuild:

#SANITIZER_CFLAGS = -g -O0 -fsanitize=undefined -fno-omit-frame-pointer


Good to know, but alas for "reasons" my most up to date version of gcc 
is 4.6.3.  Seems I could get clang 3.4 - a holidays project maybe.


TTFN

Mike
--
Lactomangulation: Abusing the "open here" spout on a milk carton.

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

--- 
You received this message because you are subscribed to the Google Groups "vim_dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Errors found by clang UBSan

[Mike Williams]

On 14/12/2016 18:12, Mike Williams wrote:

On 14/12/2016 11:16, Mike Williams wrote:

On 14/12/2016 08:44, Dominique Pellé wrote:

Yegappan Lakshmanan wrote:

eval.c:4432:10: runtime error: negation of -9223372036854775808 cannot
be represented in type 'varnumber_T' (aka 'long long'); cast to an
unsigned type to negate this value to itself


I see it too.
It's coming from this line in Test_num64() in test_viml.vim:

call assert_equal(-9223372036854775808,  0 / 0)

Running  :echo -9223372036854775808
also gives the ubsan error.

viml parser is considering the number 9223372036854775808
(which is not a valid long long) and then negating it, instead
of considering it as number -9223372036854775808
(which is a valid long long). Not sure how it can be fix.
Even though it's undefined behavior, it probably works
on all platforms in practice.  The test would probably
fail if it did not work. But it would be good to avoid undefined
behavior.


The usual idiom for writing an integer constant for the largest negative
value 2s complement integer is to negate the largest positive value and
subtract 1.  So use (-9223372036854775807 - 1)?


Apologies.  That just solves the issue with the test and not the
underlying problem.  Caffeine took too long to kick in.

The cause is a combination of things.  eval7() parses integers as
unsigned values but uses the signed value returned from vim_str2nr()
before applying any unary minus.  In turn vim_str2nr() casts the
unsigned value of the integer to a signed value, so the value it returns
depends on whether the top bit is set from the unsigned calculation.
(Casting is lying to the compiler who will have its revenge one day -
looks like today is that day ;))

VIM doesn't signal (AFAIK) out of range integer values.  At the moment,
with the wrapping unsigned integer math in vim_str2nr(), the result for
large integers is unpredictable (for those not concerned with integer
representation)  Applying a saturating calculation would at least return
results as close as possible to the original integer value maintaining sign.

So the simplest change would be to have vim_str2nr() saturate and return
9223372036854775807 as the largest positive varnumber_T supported.
eval7() would then apply the unary minus and return -9223372036854775807

You will still need to use -9223372036854775807 - 1 in the original test
to generate the largest negative integer value possible in VIM.


Patch attached to limit range of parsed integer numbers, cope with 2s 
complement asymmetry, and modify test that was triggering the UB 
warning.  Tests pass but I don't have clang to check the UB warning so 
please test for that.


Mike
--
I couldn't repair your brakes, so I made your horn louder.

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

--- 
You received this message because you are subscribed to the Google Groups "vim_dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
diff --git a/src/charset.c b/src/charset.c
--- a/src/charset.c
+++ b/src/charset.c
@@ -1901,7 +1901,10 @@ vim_str2nr(
 	n += 2;	/* skip over "0b" */
 	while ('0' <= *ptr && *ptr <= '1')
 	{
-	un = 2 * un + (unsigned long)(*ptr - '0');
+	if (un < UVARNUM_MAX / 2)
+		un = 2 * un + (unsigned long)(*ptr - '0');
+	else
+		un = UVARNUM_MAX;
 	++ptr;
 	if (n++ == maxlen)
 		break;
@@ -1912,7 +1915,10 @@ vim_str2nr(
 	/* octal */
 	while ('0' <= *ptr && *ptr <= '7')
 	{
-	un = 8 * un + (uvarnumber_T)(*ptr - '0');
+	if (un < UVARNUM_MAX / 8)
+		un = 8 * un + (uvarnumber_T)(*ptr - '0');
+	else
+		un = UVARNUM_MAX;
 	++ptr;
 	if (n++ == maxlen)
 		break;
@@ -1925,7 +1931,10 @@ vim_str2nr(
 	n += 2;	/* skip over "0x" */
 	while (vim_isxdigit(*ptr))
 	{
-	un = 16 * un + (uvarnumber_T)hex2nr(*ptr);
+	if (un < UVARNUM_MAX / 16)
+		un = 16 * un + (uvarnumber_T)hex2nr(*ptr);
+	else
+		un = UVARNUM_MAX;
 	++ptr;
 	if (n++ == maxlen)
 		break;
@@ -1936,7 +1945,10 @@ vim_str2nr(
 	/* decimal */
 	while (VIM_ISDIGIT(*ptr))
 	{
-	un = 10 * un + (uvarnumber_T)(*ptr - '0');
+	if (un < UVARNUM_MAX / 10)
+		un = 10 * un + (uvarnumber_T)(*ptr - '0');
+	else
+		un = UVARNUM_MAX;
 	++ptr;
 	if (n++ == maxlen)
 		break;
@@ -1950,9 +1962,18 @@ vim_str2nr(
 if (nptr != NULL)
 {
 	if (negative)   /* account for leading '-' for decimal numbers */
-	*nptr = -(varnumber_T)un;
+	{
+	if (un > VARNUM_MAX)
+		*nptr = VARNUM_MIN;
+	else
+		*nptr = -(varnumber_T)un;
+	}
 	else
+	{
+	if (un > VARNUM_MAX)
+		un = VARNUM_MAX;
 	*nptr = (varnumber_T)un;
+	}
 }
 if (unptr != NULL)
 	*unptr = 

Re: Errors found by clang UBSan

[Mike Williams]

On 14/12/2016 11:16, Mike Williams wrote:

On 14/12/2016 08:44, Dominique Pellé wrote:

Yegappan Lakshmanan wrote:

eval.c:4432:10: runtime error: negation of -9223372036854775808 cannot
be represented in type 'varnumber_T' (aka 'long long'); cast to an
unsigned type to negate this value to itself


I see it too.
It's coming from this line in Test_num64() in test_viml.vim:

call assert_equal(-9223372036854775808,  0 / 0)

Running  :echo -9223372036854775808
also gives the ubsan error.

viml parser is considering the number 9223372036854775808
(which is not a valid long long) and then negating it, instead
of considering it as number -9223372036854775808
(which is a valid long long). Not sure how it can be fix.
Even though it's undefined behavior, it probably works
on all platforms in practice.  The test would probably
fail if it did not work. But it would be good to avoid undefined
behavior.


The usual idiom for writing an integer constant for the largest negative
value 2s complement integer is to negate the largest positive value and
subtract 1.  So use (-9223372036854775807 - 1)?


Apologies.  That just solves the issue with the test and not the 
underlying problem.  Caffeine took too long to kick in.


The cause is a combination of things.  eval7() parses integers as 
unsigned values but uses the signed value returned from vim_str2nr() 
before applying any unary minus.  In turn vim_str2nr() casts the 
unsigned value of the integer to a signed value, so the value it returns 
depends on whether the top bit is set from the unsigned calculation. 
(Casting is lying to the compiler who will have its revenge one day - 
looks like today is that day ;))


VIM doesn't signal (AFAIK) out of range integer values.  At the moment, 
with the wrapping unsigned integer math in vim_str2nr(), the result for 
large integers is unpredictable (for those not concerned with integer 
representation)  Applying a saturating calculation would at least return 
results as close as possible to the original integer value maintaining sign.


So the simplest change would be to have vim_str2nr() saturate and return 
9223372036854775807 as the largest positive varnumber_T supported. 
eval7() would then apply the unary minus and return -9223372036854775807


You will still need to use -9223372036854775807 - 1 in the original test 
to generate the largest negative integer value possible in VIM.


TTFN

Mike
--
If opportunity doesn't knock, build a door.

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

--- 
You received this message because you are subscribed to the Google Groups "vim_dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Errors found by clang UBSan

[Mike Williams]

On 14/12/2016 08:44, Dominique Pellé wrote:

Yegappan Lakshmanan wrote:

eval.c:4432:10: runtime error: negation of -9223372036854775808 cannot
be represented in type 'varnumber_T' (aka 'long long'); cast to an
unsigned type to negate this value to itself


I see it too.
It's coming from this line in Test_num64() in test_viml.vim:

call assert_equal(-9223372036854775808,  0 / 0)

Running  :echo -9223372036854775808
also gives the ubsan error.

viml parser is considering the number 9223372036854775808
(which is not a valid long long) and then negating it, instead
of considering it as number -9223372036854775808
(which is a valid long long). Not sure how it can be fix.
Even though it's undefined behavior, it probably works
on all platforms in practice.  The test would probably
fail if it did not work. But it would be good to avoid undefined
behavior.


The usual idiom for writing an integer constant for the largest negative 
value 2s complement integer is to negate the largest positive value and 
subtract 1.  So use (-9223372036854775807 - 1)?


Mike
--
Don't play with matches. Lighters work much better.

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

--- 
You received this message because you are subscribed to the Google Groups "vim_dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Patch 8.0.0101

[Mike Williams]

Hi

On 24/11/2016 20:46, Bram Moolenaar wrote:


Patch 8.0.0101
Problem:Some options are not strictly checked.
Solution:   Add flags for strickter checks.
Files:  src/option.c


*** ../vim-8.0.0100/src/option.c2016-11-24 18:30:55.715444785 +0100
--- src/option.c2016-11-24 21:38:32.823206218 +0100
***
*** 992,998 
(char_u *)NULL, PV_NONE,
  #endif
{(char_u *)FALSE, (char_u *)0L} SCRIPTID_INIT},
! {"dictionary",  "dict", P_STRING|P_EXPAND|P_VI_DEF|P_ONECOMMA|P_NODUP,
  #ifdef FEAT_INS_EXPAND
(char_u *)_dict, PV_DICT,
  #else
--- 992,998 
(char_u *)NULL, PV_NONE,
  #endif
{(char_u *)FALSE, (char_u *)0L} SCRIPTID_INIT},
! {"dictionary",  "dict", 
P_STRING|P_EXPAND|P_VI_DEF|P_ONECOMMA|P_NODUP|P_NFNAME,
  #ifdef FEAT_INS_EXPAND
(char_u *)_dict, PV_DICT,
  #else


This has broken the dictionary option as you can no longer specify a 
filepath -


:set dictionary=a/b
E474: Invalid argument: dictionary=a/b

Not surprising as P_NFNAME excludes path separators - should it be 
extended to do full filepath validation if not normalisation?


TTFN

Mike
--
Make it too tough for the enemy to get in, and you can't get 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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Patch to set fileformat from ffs having done bw on last buffer

[Mike Williams]

Hi,

I imagine this is pretty obscure but I have hit it a couple of times 
this last week.  If your fileformats string initial entry is different 
to the fileformat default value then doing :bwipeout on the last buffer 
results in the new buffer using the default fileformat and not the first 
format from fileformats.  Follow?  Try the following on Windows:


> vim -u NONE -U NONE --cmd 'set ffs=unix' -c 'set ff? | bw | set ff?'

Prefer Unix?  This shows the same effect:

$ vim -u NONE -U NONE --cmd 'set ffs=dos' -c 'set ff? | bw | set ff?'

You should see the fileformat change across the bwipeout.

Attached is a patch that sets the new buffer's fileformat from an 
existing fileformats in buf_copy_options() or the global default 
fileformat if ffs is not set.  It Works For Me(TM) but I don't know if 
the side effects in set_fileformat() cause problems when called from 
buf_copy_options().


HTH - TTFN

Mike
--
I don't worry about tomorrow's problems - I'm not even acquainted with 
yesterdays.


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

--- 
You received this message because you are subscribed to the Google Groups "vim_dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
diff --git a/src/option.c b/src/option.c
--- a/src/option.c
+++ b/src/option.c
@@ -10735,7 +10735,15 @@ buf_copy_options(buf_T *buf, int flags)
 #ifdef FEAT_MBYTE
 		buf->b_p_fenc = vim_strsave(p_fenc);
 #endif
-		buf->b_p_ff = vim_strsave(p_ff);
+	{
+		int idx_ffs = findoption((char_u *)"ffs");
+
+		/* Apply the first entry of 'fileformats' to the buffer. */
+		if (idx_ffs >= 0 && (options[idx_ffs].flags & P_WAS_SET))
+		set_fileformat(default_fileformat(), OPT_LOCAL);
+		else
+		buf->b_p_ff = vim_strsave(p_ff);
+	}
 #if defined(FEAT_QUICKFIX)
 		buf->b_p_bh = empty_option;
 		buf->b_p_bt = empty_option;

Re: Screen update issue with incsearch in latest code

[Mike Williams]

Hi Christian

On 02/09/2016 20:44, Christian Brabandt wrote:

Hi Mike!

On Fr, 02 Sep 2016, Mike Williams wrote:


Hi,

On 02/09/2016 12:22, Christian Brabandt wrote:

On Mi, 31 Aug 2016, Mike Williams wrote:


Hi,

I pretty much lurk here these days but remember seeing some
discussion on changes to do with incremental search.  I am seeing
strange screen jumps with incremental search with the current
version 7.4.2295.  This is on on Windows and linux.

The following will reproduce the issue on Windows.  Start in the VIM
source directory and invoke vim with gvim -u NONE -U NONE
if_cscope.h. Next enable incsearch with ":set incsearch" and then
start a search with "/Sto" - this should cause the display to jump
to an enum near the end of the file.  At this point delete the o to
leave "/St" as the search pattern and then hit return to finish the
search.  I see VIM jumping back to the top of the file but with the
cursor at the same position as for the search.  If then hit j to go
down one line vim jumps back to the end of the file where the
original search succeeded.

The action that seems to trigger the unexpected jumps around the
buffer is deleting characters from the search pattern.  It can be
confusing as the screen doesn't initially display what you are
expecting (with the cursor appearing beyond the end of a line
sometimes) and then any cursor movement cause the display to jump
again.


Thanks for the almost perfect bug report (it just needed a patch to be
perfect ;))

I could easily reproduce it. Turns out, that after backspacing, the view
will not be reset correctly. So we have to save some variables there.

Please check the attached patch, which includes a test to fix this
behaviour.


It does fix my original problem but it has caused a new one.

With the same setup as above, delete all of pattern back to / and then
hit return.  I get the expected "No previous regular expression" error.
Then press return.  VIM should return back to the top of the file but
instead displays the end of the file - until you move the cursor when it
jumps back to the top of the file.  This does not happen without the
patch applied.


good catch. updated patch attached. I added a test, but that didn't work
as expected. Therefore the test is currently disabled. I verified
manually, that either of  works as expected.


Getting better :) but another failure case I am afraid.

Same setup as before.  This time use the search string /Stora - that
search will fail and VIM will jump back to the start of the file - but
then backspace the a to leave /Stor which is a match once again and VIM
displays it ok.  Then hit return and VIM displays the top of the file
until you move the cursor when the display updates back to the match at
the end.

HTH - TTFN

Mike
--
A leading authority is someone lucky who guessed right.
[Visit us at Labelexpo Americas 2016, stand 5931] 
<http://globalgraphics.com/company/events/labelexpo-americas-2016>

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

--- 
You received this message because you are subscribed to the Google Groups "vim_dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Screen update issue with incsearch in latest code

[Mike Williams]

Hi,

On 02/09/2016 12:22, Christian Brabandt wrote:

On Mi, 31 Aug 2016, Mike Williams wrote:


Hi,

I pretty much lurk here these days but remember seeing some
discussion on changes to do with incremental search.  I am seeing
strange screen jumps with incremental search with the current
version 7.4.2295.  This is on on Windows and linux.

The following will reproduce the issue on Windows.  Start in the VIM
source directory and invoke vim with gvim -u NONE -U NONE
if_cscope.h. Next enable incsearch with ":set incsearch" and then
start a search with "/Sto" - this should cause the display to jump
to an enum near the end of the file.  At this point delete the o to
leave "/St" as the search pattern and then hit return to finish the
search.  I see VIM jumping back to the top of the file but with the
cursor at the same position as for the search.  If then hit j to go
down one line vim jumps back to the end of the file where the
original search succeeded.

The action that seems to trigger the unexpected jumps around the
buffer is deleting characters from the search pattern.  It can be
confusing as the screen doesn't initially display what you are
expecting (with the cursor appearing beyond the end of a line
sometimes) and then any cursor movement cause the display to jump
again.


Thanks for the almost perfect bug report (it just needed a patch to be
perfect ;))

I could easily reproduce it. Turns out, that after backspacing, the view
will not be reset correctly. So we have to save some variables there.

Please check the attached patch, which includes a test to fix this
behaviour.


It does fix my original problem but it has caused a new one.

With the same setup as above, delete all of pattern back to / and then
hit return.  I get the expected "No previous regular expression" error.
Then press return.  VIM should return back to the top of the file but
instead displays the end of the file - until you move the cursor when it
jumps back to the top of the file.  This does not happen without the
patch applied.

HTH - TTFN

Mike
--
There are a thousand languages, but a smile speaks them all.
[Visit us at Labelexpo Americas 2016, stand 5931] 
<http://globalgraphics.com/company/events/labelexpo-americas-2016>

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

--- 
You received this message because you are subscribed to the Google Groups "vim_dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Screen update issue with incsearch in latest code

[Mike Williams]

Yep, it is a regression introduced by the work for CTRL-N/P with 
incsearch in 7.4.2259.


On 31/08/2016 12:09, Mike Williams wrote:

Hi,

I pretty much lurk here these days but remember seeing some discussion
on changes to do with incremental search.  I am seeing strange screen
jumps with incremental search with the current version 7.4.2295.  This
is on on Windows and linux.

The following will reproduce the issue on Windows.  Start in the VIM
source directory and invoke vim with gvim -u NONE -U NONE if_cscope.h.
Next enable incsearch with ":set incsearch" and then start a search with
"/Sto" - this should cause the display to jump to an enum near the end
of the file.  At this point delete the o to leave "/St" as the search
pattern and then hit return to finish the search.  I see VIM jumping
back to the top of the file but with the cursor at the same position as
for the search.  If then hit j to go down one line vim jumps back to the
end of the file where the original search succeeded.

The action that seems to trigger the unexpected jumps around the buffer
is deleting characters from the search pattern.  It can be confusing as
the screen doesn't initially display what you are expecting (with the
cursor appearing beyond the end of a line sometimes) and then any cursor
movement cause the display to jump again.

HTH - TTFN

Mike



Mike
--
Tennis racket broken, anyone got a extra cat?

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

--- 
You received this message because you are subscribed to the Google Groups "vim_dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Screen update issue with incsearch in latest code

[Mike Williams]

Hi,

I pretty much lurk here these days but remember seeing some discussion 
on changes to do with incremental search.  I am seeing strange screen 
jumps with incremental search with the current version 7.4.2295.  This 
is on on Windows and linux.


The following will reproduce the issue on Windows.  Start in the VIM 
source directory and invoke vim with gvim -u NONE -U NONE if_cscope.h. 
Next enable incsearch with ":set incsearch" and then start a search with 
"/Sto" - this should cause the display to jump to an enum near the end 
of the file.  At this point delete the o to leave "/St" as the search 
pattern and then hit return to finish the search.  I see VIM jumping 
back to the top of the file but with the cursor at the same position as 
for the search.  If then hit j to go down one line vim jumps back to the 
end of the file where the original search succeeded.


The action that seems to trigger the unexpected jumps around the buffer 
is deleting characters from the search pattern.  It can be confusing as 
the screen doesn't initially display what you are expecting (with the 
cursor appearing beyond the end of a line sometimes) and then any cursor 
movement cause the display to jump again.


HTH - TTFN

Mike
--
Tennis racket broken, anyone got a extra cat?

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

--- 
You received this message because you are subscribed to the Google Groups "vim_dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: set default fileformat with empty first buffer

[Mike Williams]

On 21/03/2016 06:39, Marius Gedminas wrote:

On Sun, Mar 20, 2016 at 08:46:23AM +, Mike Williams wrote:

I noticed a problem with the fileformats option not being applied to the
initial buffer when VIM is started without any initial buffer content. I
mainly work on Windows and have fileformats=unix,dos so the default file
format to be unix line-endings.  However VIM on Windows starts new empty
initial buffers with dos line-endings but if I start a new buffer with :new
or :e with the name of file that did not exist then the fileformat is set to
unix line-endings.


The help says this about 'fileformats':

Note that when Vim starts up with an empty buffer this option is not
used.  Set 'fileformat' in your .vimrc instead.


My vimrc predates the note being added.  Still, should have re-read it. 
 At least with this change an exception case has been removed.



The following patch applies fileformats to the initial buffer created by
VIM.  I have been using it for the last 9 months without any obvious issues.
I have tested a couple of ways of feeding data into the initial buffer (such
as C:> dir | vim -) and it does what I would expect.  So can anyone see any
issues with this patch?


If you're changing the behavior, you should probably also change the
help text to match.


Very good point.

diff --git a/runtime/doc/options.txt b/runtime/doc/options.txt
--- a/runtime/doc/options.txt
+++ b/runtime/doc/options.txt
@@ -3030,9 +3030,6 @@ A jump table for the options with a shor
  file only, the option is not changed.
When 'binary' is set, the value of 'fileformats' is not used.

-   Note that when Vim starts up with an empty buffer this option is not
-   used.  Set 'fileformat' in your .vimrc instead.
-
For systems with a Dos-like  (), when reading 
files that
are ":source"ed and for vimrc files, automatic  detection 
may be

done:



TTFN

Mike
--
There's so much comedy on television. Does that cause comedy in the streets?

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

--- 
You received this message because you are subscribed to the Google Groups "vim_dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

set default fileformat with empty first buffer

[Mike Williams]

Hi,

I noticed a problem with the fileformats option not being applied to the 
initial buffer when VIM is started without any initial buffer content. 
I mainly work on Windows and have fileformats=unix,dos so the default 
file format to be unix line-endings.  However VIM on Windows starts new 
empty initial buffers with dos line-endings but if I start a new buffer 
with :new or :e with the name of file that did not exist then the 
fileformat is set to unix line-endings.


The following patch applies fileformats to the initial buffer created by 
VIM.  I have been using it for the last 9 months without any obvious 
issues.  I have tested a couple of ways of feeding data into the initial 
buffer (such as C:> dir | vim -) and it does what I would expect.  So 
can anyone see any issues with this patch?


diff --git a/src/option.c b/src/option.c
--- a/src/option.c
+++ b/src/option.c
@@ -3845,6 +3845,7 @@ term_bg_default(void)
 void
 set_init_3(void)
 {
+intidx_ffs;
 #if defined(UNIX) || defined(WIN3264)
 /*
  * Set 'shellpipe' and 'shellredir', depending on the 'shell' option.
@@ -4017,6 +4018,12 @@ set_init_3(void)
 }
 #endif

+idx_ffs = findoption((char_u *)"ffs");
+if (idx_ffs >= 0 && (options[idx_ffs].flags & P_WAS_SET))
+{
+   set_fileformat(default_fileformat(), OPT_LOCAL);
+}
+
 #ifdef FEAT_TITLE
 set_title_defaults();
 #endif


TTFN

Mike
--
Computer modellers simulate it first.

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

--- 
You received this message because you are subscribed to the Google Groups "vim_dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Warnings in ex_cmds2.c, getchar.c, pathdef.c, undo.c, os_win32.c

[Mike Williams]

On 26/02/2016 10:13, Mike Williams wrote:

On 26/02/2016 09:41, Nikolay Aleksandrovich Pavlov wrote:

2016-02-26 12:34 GMT+03:00 Mike Williams <mike.willi...@globalgraphics.com>:

On 24/02/2016 23:21, Nikolay Aleksandrovich Pavlov wrote:


2016-02-22 19:57 GMT+03:00 Bram Moolenaar <b...@moolenaar.net>:


This one too.


[...]
os_win32.c: In function 'read_console_input.constprop.22':
os_win32.c:299:28: warning: array subscript is above array bounds
[-Warray-bounds]
s_irCache[i] = s_irCache[i + 1];
^



Not sure how to fix this.  Or even if this is a real problem.



I do not know whether this is a real problem, but such things are best
written with memmove:

   memmove(s_irCache + head, s_irCache + head + 1, (size_t) (tail -
head) * sizeof(s_irCache[0]));



The warning will be because ultimately i is limited by s_dwMax which is
based on a value returned from ReadConsoleInputW() and the compiler cannot
tell if this will be larger that IRSIZE although we know it from the API
doc.  Limiting the range of s_dwMax with something like

s_dwMax = min(dwEvents, IRSIZE);

may kill the warning without the code gymnastics above.


This is not code gymnastics. If one wants to shift an array he should
use memmove() because this is exactly the purpose of this function,
also slightly less code then a cycle. This should also run faster,
unless compiler was able to optimize cycle to the same code as
memmove() (which should be rather likely given how common this pattern
is).


The lack of diff hid the context, at least for me, sorry.  It is still
possible the compiler will warn about indexing beyond the end of s_irCache.

The whole double loop feels heavy - for every repeat of a the size event
the remainder of the buffer is moved down one place, even if there are
later repeats.  Since the buffer is only 10 elements it may be simpler
to read into a stack buffer and then copy into the static skipping runs
in a single loop.  Something like the following (ReadConsoleInputW()
changed to read into temporary irCache) - untested ;-):

if (s_dwMax > 1)
{
  /* Reduce sequences of buffer size events to just 1 */
  s_irCache[0] = irCache[0];
  for (head = 1, prev = 0; head < s_dwMax; head++)
  {
if (s_irCache[prev].EventType == WINDOW_BUFFER_SIZE_EVENT &&
irCache[head].EventType == WINDOW_BUFFER_SIZE_EVENT)
{
  continue;
}
s_irCache[++prev] = irCache[head];
  }
  s_dwMax = prev + 1;
}


Of course, it can be done with just the single array.  Attached is a 
patch that simplifies the code.  Since it is a such a small array it is 
hard to justify writing extra code to optimise the copying being done. 
Builds for me but untested as I have Win7 and don't use IME, YMMV.


Mike
--
The first sign of maturity is the discovery that the volume knob also 
turns to the left.


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

--- 
You received this message because you are subscribed to the Google Groups "vim_dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
diff --git a/src/os_win32.c b/src/os_win32.c
--- a/src/os_win32.c
+++ b/src/os_win32.c
@@ -256,9 +256,8 @@ read_console_input(
 static DWORD s_dwIndex = 0;
 static DWORD s_dwMax = 0;
 DWORD dwEvents;
-int head;
-int tail;
-int i;
+unsigned int next;
+unsigned int tail;
 
 if (nLength == -2)
 	return (s_dwMax > 0) ? TRUE : FALSE;
@@ -283,24 +282,17 @@ read_console_input(
 	*lpEvents = 0;
 	return TRUE;
 	}
-
 	if (s_dwMax > 1)
 	{
-	head = 0;
-	tail = s_dwMax - 1;
-	while (head != tail)
+	/* Remove repeated buffer size events to reduce flicker */
+	for (tail = 0, next = 1; next < s_dwMax; next++)
 	{
-		if (s_irCache[head].EventType == WINDOW_BUFFER_SIZE_EVENT
-			&& s_irCache[head + 1].EventType
-		  == WINDOW_BUFFER_SIZE_EVENT)
+		if (s_irCache[tail].EventType == WINDOW_BUFFER_SIZE_EVENT &&
+		s_irCache[next].EventType == WINDOW_BUFFER_SIZE_EVENT)
 		{
-		/* Remove duplicate event to avoid flicker. */
-		for (i = head; i < tail; ++i)
-			s_irCache[i] = s_irCache[i + 1];
-		--tail;
 		continue;
 		}
-		head++;
+		s_irCache[++tail] = s_irCache[next];
 	}
 	s_dwMax = tail + 1;
 	}

Re: Warnings in ex_cmds2.c, getchar.c, pathdef.c, undo.c, os_win32.c

[Mike Williams]

On 26/02/2016 09:41, Nikolay Aleksandrovich Pavlov wrote:

2016-02-26 12:34 GMT+03:00 Mike Williams <mike.willi...@globalgraphics.com>:

On 24/02/2016 23:21, Nikolay Aleksandrovich Pavlov wrote:


2016-02-22 19:57 GMT+03:00 Bram Moolenaar <b...@moolenaar.net>:


This one too.


[...]
os_win32.c: In function 'read_console_input.constprop.22':
os_win32.c:299:28: warning: array subscript is above array bounds
[-Warray-bounds]
   s_irCache[i] = s_irCache[i + 1];
   ^



Not sure how to fix this.  Or even if this is a real problem.



I do not know whether this is a real problem, but such things are best
written with memmove:

  memmove(s_irCache + head, s_irCache + head + 1, (size_t) (tail -
head) * sizeof(s_irCache[0]));



The warning will be because ultimately i is limited by s_dwMax which is
based on a value returned from ReadConsoleInputW() and the compiler cannot
tell if this will be larger that IRSIZE although we know it from the API
doc.  Limiting the range of s_dwMax with something like

   s_dwMax = min(dwEvents, IRSIZE);

may kill the warning without the code gymnastics above.


This is not code gymnastics. If one wants to shift an array he should
use memmove() because this is exactly the purpose of this function,
also slightly less code then a cycle. This should also run faster,
unless compiler was able to optimize cycle to the same code as
memmove() (which should be rather likely given how common this pattern
is).


The lack of diff hid the context, at least for me, sorry.  It is still 
possible the compiler will warn about indexing beyond the end of s_irCache.


The whole double loop feels heavy - for every repeat of a the size event 
the remainder of the buffer is moved down one place, even if there are 
later repeats.  Since the buffer is only 10 elements it may be simpler 
to read into a stack buffer and then copy into the static skipping runs 
in a single loop.  Something like the following (ReadConsoleInputW() 
changed to read into temporary irCache) - untested ;-):


if (s_dwMax > 1)
{
/* Reduce sequences of buffer size events to just 1 */
s_irCache[0] = irCache[0];
for (head = 1, prev = 0; head < s_dwMax; head++)
{
  if (s_irCache[prev].EventType == WINDOW_BUFFER_SIZE_EVENT &&
  irCache[head].EventType == WINDOW_BUFFER_SIZE_EVENT)
  {
continue;
  }
  s_irCache[++prev] = irCache[head];
}
s_dwMax = prev + 1;
}




2ps worth. TTFN

Mike
--
The face of a child can say it all, especially the mouth part of the face.

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

--- You received this message because you are subscribed to the Google
Groups "vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.





Mike
--
The face of a child can say it all, especially the mouth part of the face.

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

--- 
You received this message because you are subscribed to the Google Groups "vim_dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Warnings in ex_cmds2.c, getchar.c, pathdef.c, undo.c, os_win32.c

[Mike Williams]

On 24/02/2016 23:21, Nikolay Aleksandrovich Pavlov wrote:

2016-02-22 19:57 GMT+03:00 Bram Moolenaar :

This one too.


[...]
os_win32.c: In function 'read_console_input.constprop.22':
os_win32.c:299:28: warning: array subscript is above array bounds
[-Warray-bounds]
  s_irCache[i] = s_irCache[i + 1];
  ^


Not sure how to fix this.  Or even if this is a real problem.


I do not know whether this is a real problem, but such things are best
written with memmove:

 memmove(s_irCache + head, s_irCache + head + 1, (size_t) (tail -
head) * sizeof(s_irCache[0]));


The warning will be because ultimately i is limited by s_dwMax which is 
based on a value returned from ReadConsoleInputW() and the compiler 
cannot tell if this will be larger that IRSIZE although we know it from 
the API doc.  Limiting the range of s_dwMax with something like


  s_dwMax = min(dwEvents, IRSIZE);

may kill the warning without the code gymnastics above.

2ps worth. TTFN

Mike
--
The face of a child can say it all, especially the mouth part of the face.

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

--- 
You received this message because you are subscribed to the Google Groups "vim_dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Warnings in ex_cmds2.c, getchar.c, pathdef.c, undo.c, os_win32.c

[Mike Williams]

On 24/02/2016 22:06, Bram Moolenaar wrote:

Because they actually cause an overflow problem (potentionally):

-|| top >= bot
+|| top - bot >= 0

The existing line doesn't do any subtraction thus can't overflow, it's a
simple comparison.  The second one could have an overflow.
So we are just avoiding a bogus warning, not fixing a problem.


The warning is likely to be from in-lining u_save() into u_save_cursor() 
when using -O3.  The version of gcc being used sees that, assuming no 
signed integer overflow, top >= bot will always be false and the 
condition is redundant.


Mike
--
The face of a child can say it all, especially the mouth part of the face.

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

--- 
You received this message because you are subscribed to the Google Groups "vim_dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [bug] Compiling vim.exe fails

[Mike Williams]

On 15/02/2016 12:09, Bram Moolenaar wrote:


Mike Williams wrote:

Come on guys, if you're fixing code dependent on pp defines, check with
them both defined and undefined that everything still builds and links.


It appears Appveyor only builds one specific setup.  It would be useful
to run a few more combinations.  I can't possibly check more than a few
things, especially if it involves MS-Windows (with at least four
combinations: GUI/console * MSVC/MingW).


The only combination relevant here is if FEAT_CHANNEL is defined or not. 
 If someone writes code that depends on a PP symbol I would hope they 
would check compiles with it defined and undefined.  They should not be 
relying on a CI server to catch these basic mistakes IMHO.  (Sorry, it's 
a Monday.)



Anyway, I prefer the solution I sent in the patch with #else.  A bit
easier to see what's happening.


Technically, it is not to keep the compiler happy but to write correct C 
code.  There is a reason why goto has a bad reputation. ;-)


TTFN

Mike
--
This is certainly more fun than being hit with a hammer.

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

--- 
You received this message because you are subscribed to the Google Groups "vim_dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Diff to silence noise from VS tools

[Mike Williams]

On 10/02/2016 22:16, Bram Moolenaar wrote:


Kenny Wong wrote:


After applying patch 7.4.1240, I cannot build using Visual Studio 2005 because 
its rc.exe version does not support the /nologo option, e.g.

C:\>"C:\Program Files (x86)\Microsoft Visual Studio 8\VC\bin\rc.exe" /nologo
fatal error RC1106: invalid option: -ologo


I thought I was using an ancient compiler, but this is even older.
Any reason why you can't use the 2008 or 2010 version?  I have heard
several people say the 2010 version still builds for old systems (XP and
up).


rc.exe in VS2005 was a bit rogue.  rc in the previous release only 
showed the logo when the /verbose flag was used.  In VS2005 rc was 
"fixed" to show the logo by default, but didn't get a /nologo to turn it 
off again - this was added in the following release.


If changing the version of VS being used is not possible then I guess 
the /nologo for rc.exe should be removed and a comment put in noting 
that we are stuck with having it appear.


HTH - TTFN

Mike
--
This is certainly more fun than being hit with a hammer.

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

--- 
You received this message because you are subscribed to the Google Groups "vim_dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [bug] Compiling vim.exe fails

[Mike Williams]

On 15/02/2016 08:10, Axel Bender wrote:

Compiling vim.exe (Windows 7 64-bit, MinGW 64-bit) fails with:

gcc -c -Iproto -DWIN32 -DWINVER=0x0500 -D_WIN32_WINNT=0x0500 -DHAVE_PATHDEF 
-DFEAT_BIG -DMS_WIN64 -DHAVE_GETTEXT -DHAVE_LOCALE_H -DDYNAMIC_GETTEXT 
-DFEAT_OLE -DFEAT_CSCOPE -DFEAT_MBYTE -DFEA
T_MBYTE_IME -DDYNAMIC_IME -DDYNAMIC_ICONV -pipe -w -march=x86-64 -Wall 
-Id:/tools/perl/lib/Core -DFEAT_PERL -DPERL_IMPLICIT_CONTEXT -DPERL_IMPLICIT_SYS 
-DDYNAMIC_PERL -DDYNAMIC_PERL_DLL=\"pe
rl522.dll\" -DFEAT_PYTHON -DDYNAMIC_PYTHON 
-DDYNAMIC_PYTHON_DLL=\"python27.dll\" -O3 -fomit-frame-pointer -freg-struct-return 
-s os_win32.c -o objx86-64/os_win32.o
os_win32.c: In function 'mch_start_job':
os_win32.c:5102:1: error: label at end of compound statement
  failed:
  ^
Make_cyg_ming.mak:852: recipe for target 'objx86-64/os_win32.o' failed
make: *** [objx86-64/os_win32.o] Error 1



diff --git a/src/os_win32.c b/src/os_win32.c
--- a/src/os_win32.c
+++ b/src/os_win32.c
@@ -5101,8 +5101,9 @@ mch_start_job(char *cmd, job_T *job)

 failed:
 # ifdef FEAT_CHANNEL
-channel_free(channel);
+channel_free(channel)
 # endif
+  ;
 }


Come on guys, if you're fixing code dependent on pp defines, check with 
them both defined and undefined that everything still builds and links.


Mike
--
This is certainly more fun than being hit with a hammer.

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

--- 
You received this message because you are subscribed to the Google Groups "vim_dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Diff to silence noise from VS tools

[Mike Williams]

Hi,

Attached is a diff that suppresses the startup info from various Visual 
Studio tools used to build VIM.  They just add noise to the build log.


TTFN

Mike
--
I try to watch what I eat but my eyes aren't quick enough.

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

--- 
You received this message because you are subscribed to the Google Groups "vim_dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
diff --git a/src/GvimExt/Makefile b/src/GvimExt/Makefile
--- a/src/GvimExt/Makefile
+++ b/src/GvimExt/Makefile
@@ -52,7 +52,7 @@ gvimext.obj: gvimext.h
$(cc) $(cflags) -DFEAT_GETTEXT $(cvarsmt) $*.cpp

 gvimext.res: gvimext.rc
-   $(rc) $(rcflags) $(rcvars)  gvimext.rc
+   $(rc) /nologo $(rcflags) $(rcvars)  gvimext.rc

 clean:
- if exist gvimext.dll del gvimext.dll
diff --git a/src/Make_mvc.mak b/src/Make_mvc.mak
--- a/src/Make_mvc.mak
+++ b/src/Make_mvc.mak
@@ -1294,7 +1294,7 @@ lib$(MZSCHEME_MAIN_LIB)$(MZSCHEME_VER).l
 $(OUTDIR)/vim.res: $(OUTDIR) vim.rc gvim.exe.mnf version.h tools.bmp \
tearoff.bmp vim.ico vim_error.ico \
vim_alert.ico vim_info.ico vim_quest.ico
-   $(RC) /l 0x409 /Fo$(OUTDIR)/vim.res $(RCFLAGS) vim.rc
+   $(RC) /nologo /l 0x409 /Fo$(OUTDIR)/vim.res $(RCFLAGS) vim.rc

 iid_ole.c if_ole.h vim.tlb: if_ole.idl
midl /nologo /error none /proxy nul /iid iid_ole.c /tlb vim.tlb \
diff --git a/src/tee/Make_mvc.mak b/src/tee/Make_mvc.mak
--- a/src/tee/Make_mvc.mak
+++ b/src/tee/Make_mvc.mak
@@ -1,7 +1,7 @@
 # A very (if not the most) simplistic Makefile for MSVC

 CC=cl
-CFLAGS=/O2
+CFLAGS=/O2 /nologo

 tee.exe: tee.obj
$(CC) $(CFLAGS) /Fo$@ $**

build issues on BSD systems

[Mike Williams]

Hi,

I have been catching up with latest changes on a BSD system and their 
has been a regression in the build over the last month.  This seems to 
have started with 7.4.994 to replace gdk_pixbuf_new_from_inline().


Two issues

1) Makefile can no longer be used with BSD make, it requires gmake. 
This would be a new dependency when building on BSD systems.  The error 
message is:


Using $< in a non-suffix rule context is a GNUmake idiom (Makefile:2651)

which is the rule for auto/gui_gtk_gresources.h.  There will be the same 
issue for the .c version of the file.  Just need to manually expand $< 
which leads on to the next problem.


2) Build failure on BSD systems using older versions of gdk-pixbuf.  The 
same problem occurs with gmake but the build continues.  For these 
systems GLIB_COMPILE_RESOURCES does not get defined so when make runs 
the rule it attempts to run the arguments to glib-compile-resources. 
For BSD make this results in the following:


--target=auto/gui_gtk_gresources.h --sourcedir=../pixmaps --generate 
--c-name=gui_gtk --manual-register gui_gtk_res.xml

/bin/sh: /bin/sh: --: unknown option
*** Error 1 in src (Makefile:2651 'auto/gui_gtk_gresources.h')

With gmake:

target=auto/gui_gtk_gresources.h --sourcedir=../pixmaps --generate 
--c-name=gui_gtk --manual-register gui_gtk_res.xml

/bin/sh: --sourcedir=../pixmaps: not found
Makefile:2651: recipe for target 'auto/gui_gtk_gresources.h' failed
gmake[1]: [auto/gui_gtk_gresources.h] Error 127 (ignored)

Attached is a diff to fix these issues (overly long lines though), but I 
have not tested with a system with the required version of gdk-pixbuf. 
I also see that running make twice in a row builds gui_gtk_x11.c each 
time, although no code has changed.


I assume Unix systems with older versions gdk-pixbuf would continue work 
ok with the older API.  If so, then building current VIM on them has 
lost functionality which seems a shame.


TTFN

Mike
--
I'm discriminating. You're choosy. He's picky.

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

--- 
You received this message because you are subscribed to the Google Groups "vim_dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
diff --git a/src/Makefile b/src/Makefile
--- a/src/Makefile
+++ b/src/Makefile
@@ -2646,9 +2646,9 @@ GUI_GTK_RES_INPUTS = \
../pixmaps/stock_vim_window_split_vertical.png

 auto/gui_gtk_gresources.c: gui_gtk_res.xml $(GUI_GTK_RES_INPUTS)
-  $(GLIB_COMPILE_RESOURCES) --target=$@ --sourcedir=../pixmaps --generate --c-name=gui_gtk --manual-register $<
+  if test -n "$(GLIB_COMPILE_RESOURCES)"; then $(GLIB_COMPILE_RESOURCES) --target=$@ --sourcedir=../pixmaps --generate --c-name=gui_gtk --manual-register gui_gtk_res.xml; fi
 auto/gui_gtk_gresources.h: gui_gtk_res.xml $(GUI_GTK_RES_INPUTS)
-  $(GLIB_COMPILE_RESOURCES) --target=$@ --sourcedir=../pixmaps --generate --c-name=gui_gtk --manual-register $<
+  if test -n "$(GLIB_COMPILE_RESOURCES)"; then $(GLIB_COMPILE_RESOURCES) --target=$@ --sourcedir=../pixmaps --generate --c-name=gui_gtk --manual-register gui_gtk_res.xml; fi

 # All the object files are put in the "objects" directory.  Since not all make
 # commands understand putting object files in another directory, it must be

Re: build issues on BSD systems

[Mike Williams]

Hiya,

On 31/01/2016 11:10, Kazunobu Kuriyama wrote:

Hi,

Hopefully, the attached patch fixes the both issues.


Yep, much neater.  Many thanks.


Best regards,
Kazunobu Kuriyama

2016-01-31 18:37 GMT+09:00 Mike Williams
<mike.willi...@globalgraphics.com
<mailto:mike.willi...@globalgraphics.com>>:

Hi,

I have been catching up with latest changes on a BSD system and
their has been a regression in the build over the last month.  This
seems to have started with 7.4.994 to replace
gdk_pixbuf_new_from_inline().

Two issues

1) Makefile can no longer be used with BSD make, it requires gmake.
This would be a new dependency when building on BSD systems.  The
error message is:

Using $< in a non-suffix rule context is a GNUmake idiom (Makefile:2651)

which is the rule for auto/gui_gtk_gresources.h.  There will be the
same issue for the .c version of the file.  Just need to manually
expand $< which leads on to the next problem.

2) Build failure on BSD systems using older versions of gdk-pixbuf.
The same problem occurs with gmake but the build continues.  For
these systems GLIB_COMPILE_RESOURCES does not get defined so when
make runs the rule it attempts to run the arguments to
glib-compile-resources. For BSD make this results in the following:

--target=auto/gui_gtk_gresources.h --sourcedir=../pixmaps --generate
--c-name=gui_gtk --manual-register gui_gtk_res.xml
/bin/sh: /bin/sh: --: unknown option
*** Error 1 in src (Makefile:2651 'auto/gui_gtk_gresources.h')

With gmake:

target=auto/gui_gtk_gresources.h --sourcedir=../pixmaps --generate
--c-name=gui_gtk --manual-register gui_gtk_res.xml
/bin/sh: --sourcedir=../pixmaps: not found
Makefile:2651: recipe for target 'auto/gui_gtk_gresources.h' failed
gmake[1]: [auto/gui_gtk_gresources.h] Error 127 (ignored)

Attached is a diff to fix these issues (overly long lines though),
but I have not tested with a system with the required version of
gdk-pixbuf. I also see that running make twice in a row builds
gui_gtk_x11.c each time, although no code has changed.

I assume Unix systems with older versions gdk-pixbuf would continue
work ok with the older API.  If so, then building current VIM on
them has lost functionality which seems a shame.

TTFN

Mike
--
I'm discriminating. You're choosy. He's picky.

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

--- You received this message because you are subscribed to the
Google Groups "vim_dev" group.
To unsubscribe from this group and stop receiving emails from it,
send an email to vim_dev+unsubscr...@googlegroups.com
<mailto:vim_dev%2bunsubscr...@googlegroups.com>.
For more options, visit https://groups.google.com/d/optout.


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

---
You received this message because you are subscribed to the Google
Groups "vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send
an email to vim_dev+unsubscr...@googlegroups.com
<mailto:vim_dev+unsubscr...@googlegroups.com>.
For more options, visit https://groups.google.com/d/optout.



Mike
--
I'm discriminating. You're choosy. He's picky.

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

--- 
You received this message because you are subscribed to the Google Groups "vim_dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Patch 7.4.1134

[Mike Williams]

On 21/01/2016 01:26, Nikolay Aleksandrovich Pavlov wrote:

2016-01-19 21:52 GMT+03:00 Gary Johnson >:

On Unix, a space is a separator.  Spaces in file names require
quoting.  I don't think Vim should violate that convention here just
because it can.  It would be horribly inconsistent.

​Space is not a separator on *Unix*. This is a *shell* where space is a
separator and shells on windows *also* treat spaces as separators.​ Main
difference is that not *all* spaces are separators in cmd.exe (dunno
about powershell): basically the only place where it is guaranteed to
have space as a separator is a single space after the command name
because all other spaces (except those before and after operators like
`&` or `|`, which are not separators as well) are parsed by the program
itself and not the shell. But this is *in cmd.exe* (and, maybe, in
powershell) while you can install bash and other *nix shells on windows.
Also note that standard library used for parsing arguments to argument
list treats spaces as separators on windows as well, and it is used by
most of console applications, so you will hardly notice the difference
in most cases.


Just my $0.02.


Things are slightly murkier on Windows.  Each process only ever has a 
single command line string.  During process startup there are library 
calls to split the command line using space or tabs as argument 
delimiters.  This is then passed to the main entry point as the argv 
array (in the C world).  The rules for parsing the command line are:


https://msdn.microsoft.com/en-us/library/a1y7w461%28v=vs.110%29.aspx

I would think it would be safe to say that VIM on Windows (these days, 
can't speak to 3.1/9x) will do the expected thing wrt space separators.


Mike
--
No I don't need your help, I get in enough trouble all by myself.

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

--- 
You received this message because you are subscribed to the Google Groups "vim_dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: How to update with local changes

[Mike Williams]

On 19/01/2016 00:32, James McCoy wrote:

On Mon, Jan 18, 2016 at 08:36:47PM +0100, Bram Moolenaar wrote:

Let's face it, git is nice if you know how to use it, and otherwise it's
a very annoying tool.


s/git/Vim/ in that sentence and I'm sure many would agree with that too.
Any tool takes time to learn.  If one doesn't want to spend the time to
do that, then yes they're going to be annoyed with it.


I remember a lot of git users complaining about not understanding hg to 
which the answer was spend time learning it.  Now we have the git users 
complaining about people not learning git.


And so the cycle of software development turns.

I'm getting too old for all this ;)

Mike
--
You are in a maze of anonymous functions, all alike. Closures are west 
and east. You see here: $


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

--- 
You received this message because you are subscribed to the Google Groups "vim_dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: GVimExt 64bit builds with VS2015

[Mike Williams]

On 10/01/2016 16:17, Yukihiro Nakadaira wrote:

With "VS2015 X64 X86 Cross Tool" and "VS2015 X86 X64 Cross Tool", I got many
errors for compiling GvimExt.  And it was fixed by your patch.  Generated
binary seems correct (I just checked dll header with "dumpbin /headers
gvimext.dll").


Thank you for checking.  Indeed it was for cross compiling.  I will keep 
hold of this environment as it does seem to be highlighting errors like 
this at the moment.


TTFN

Mike
--
Why do drive-up ATMs have Braille keys?

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

--- 
You received this message because you are subscribed to the Google Groups "vim_dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Fix for pointer truncation warning on Windows.

[Mike Williams]

Hi,

On 13/12/2015 13:30, Mike Williams wrote:

Hi all,

VS2015 is raising a pointer cast truncation warning in gui_w32.c  On
64bit builds with VC HandleToLong() is a function but for 32bit builds
it is a macro.  The current VIM code defines a macro if one is not
defined so shadows the function call resulting in the warning.

Going through the source history this looks like it got broken when
coping with MingW warnings in 7.3.870.  The following patch copes with
old MS compilers (for the Win95 hold outs - are there still any?) and
MingW.  I don't have MingW so can someone please check the following
works for them, and if a 64bit MingW raises its own warning for the cast.


diff --git a/src/gui_w32.c b/src/gui_w32.c
--- a/src/gui_w32.c
+++ b/src/gui_w32.c
@@ -1769,9 +1769,11 @@ gui_mch_init(void)
   #endif

   #ifdef FEAT_EVAL
-# ifndef HandleToLong
-/* HandleToLong() only exists in compilers that can do 64 bit builds */
-#  define HandleToLong(h) ((long)(h))
+# if !defined(_MSC_VER) || (_MSC_VER < 1400)
+/* Define HandleToLong for old MS and none-MS compilers if not defined */
+#  ifndef HandleToLong
+#   define HandleToLong(h) ((long)(h))
+#  endif
   # endif
   /* set the v:windowid variable */
   set_vim_var_nr(VV_WINDOWID, HandleToLong(s_hwnd));



Has anyone tried this on MingW?  Any problems?

TTFN

Mike
--
So little to say and so much time to say 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

--- 
You received this message because you are subscribed to the Google Groups "vim_dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: GVimExt 64bit builds with VS2015

[Mike Williams]

Hi

On 13/12/2015 14:27, Mike Williams wrote:

Hi,

GVimEXT fails to build for me with VS2015, a large number of undefined
symbols from the Windows headers when compiling.  The Makefile is
missing some symbols defined that Win32.mak needs to set up the build
environment correctly.


Tweaked to be more consistent with the main msvc makefile.

diff --git a/src/GvimExt/Makefile b/src/GvimExt/Makefile
--- a/src/GvimExt/Makefile
+++ b/src/GvimExt/Makefile
@@ -12,6 +12,24 @@ APPVER=5.0
 NODEBUG = 1
 !endif

+TARGETOS = BOTH
+
+!ifdef PROCESSOR_ARCHITECTURE
+# On Windows NT
+! ifndef CPU
+CPU = i386
+!  ifdef PLATFORM
+!   if ("$(PLATFORM)" == "x64") || ("$(PLATFORM)" == "X64")
+CPU = AMD64
+!   elseif ("$(PLATFORM)" != "x86") && ("$(PLATFORM)" != "X86")
+!error *** ERROR Unknown target platform "$(PLATFORM)". Make aborted.
+!   endif
+!  endif
+! endif
+!else
+CPU = i386
+!endif
+

Anyone got any problems with GVimExt with this patch?

Mike
--
So little to say and so much time to say 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

--- 
You received this message because you are subscribed to the Google Groups "vim_dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Set maxmem options based on available memory on Windows

[Mike Williams]

Hiya

On 18/12/2015 09:15, Ken Takata wrote:

Hi Mike,

2015/12/18 Fri 17:45:27 UTC+9 Mike Williams wrote:

Attached is a patch that sets the maxmem options at startup on Windows
OSes based on reported memory availability.  It uses a simple heuristic
to derive a value to use.  The checks for limited memory systems from
the dark ages of last century may not be ideal, if anyone is still
nursing such a system it would be nice to try the patch on it to see if
the reserve numbers need to be tweaked.


I think we can drop support for win9x. But (if needed) we can still


Bram - any comment on finally dropping 95 support?  As in Win32s (ah, 
happy days) - I can no longer do builds or run them so cannot check the 
effect.



use GlobalMemoryStatus() just for old compilers like this:

#ifdef MEMORYSTATUSEX
  /* Use GlobalMemoryStatusEx() for recent compilers */
#else
  /* Use GlobalMemoryStatus() for old compilers */
#endif


Win2K does not support GlobalMemoryStatusEx().  The default Windows 
build sets WINVER to 0x0400 to support Win2K compatible builds and this 
excludes MEMORYSTATUSEX, so it is not new/compilers but old/new versions 
of NT.


Attached is an updated patch to fix the memory values for NT in default 
builds, and avoid a possible return of 0 bytes available!


TTFN

Mike
--
Anger is never without reason, but seldom with a good one.

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

--- 
You received this message because you are subscribed to the Google Groups "vim_dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
diff --git a/src/os_win32.c b/src/os_win32.c
--- a/src/os_win32.c
+++ b/src/os_win32.c
@@ -5858,6 +5858,66 @@ mch_breakcheck(void)
 #endif
 }
 
+/* Physical RAM to leave for the OS */
+#define WINNT_RESERVE_BYTES (256*1024*1024)
+#define WIN95_RESERVE_BYTES (8*1024*1024)
+
+/*
+ * How much main memory in KiB that can be used by VIM.
+ */
+/*ARGSUSED*/
+long_u
+mch_total_mem(int special)
+{
+PlatformId();
+#ifdef MEMORYSTATUSEX
+if (g_PlatformId == VER_PLATFORM_WIN32_NT)
+{
+MEMORYSTATUSEX  ms;
+
+/* Need to use GlobalMemoryStatusEx() when there is more memory than
+ * what fits in 32 bits. But it's not always available. */
+ms.dwLength = sizeof(MEMORYSTATUSEX);
+GlobalMemoryStatusEx();
+if (ms.ullAvailVirtual < ms.ullTotalPhys)
+{
+/* Process address space fits in physical RAM, use all of it */
+return (long_u)(ms.ullAvailVirtual/1024);
+}
+if (ms.ullTotalPhys <= WINNT_RESERVE_BYTES)
+{
+/* Catch old NT box or perverse hardware setup */
+return (long_u)((ms.ullTotalPhys/2)/1024);
+}
+/* Use physical RAM less reserve for OS + data */
+return (long_u)((ms.ullTotalPhys - WINNT_RESERVE_BYTES)/1024);
+}
+else
+#endif
+{
+/* Pre-XP or 95 OS handling */
+MEMORYSTATUSms;
+long_u os_reserve_bytes;
+
+ms.dwLength = sizeof(MEMORYSTATUS);
+GlobalMemoryStatus();
+if (ms.dwAvailVirtual < ms.dwTotalPhys)
+{
+/* Process address space fits in physical RAM, use all of it */
+return (long_u)(ms.dwAvailVirtual/1024);
+}
+os_reserve_bytes = (g_PlatformId == VER_PLATFORM_WIN32_NT)
+? WINNT_RESERVE_BYTES
+: WIN95_RESERVE_BYTES;
+if (ms.dwTotalPhys <= os_reserve_bytes)
+{
+/* Catch old boxes or perverse hardware setup */
+return (long_u)((ms.dwTotalPhys/2)/1024);
+}
+/* Use physical RAM less reserve for OS + data */
+return (long_u)((ms.dwTotalPhys - os_reserve_bytes)/1024);
+}
+}
 
 #ifdef FEAT_MBYTE
 /*
diff --git a/src/os_win32.h b/src/os_win32.h
--- a/src/os_win32.h
+++ b/src/os_win32.h
@@ -78,6 +78,8 @@
 # define BREAKCHECK_SKIP1	/* call mch_breakcheck() each time, it's fast */
 #endif
 
+#define HAVE_TOTAL_MEM
+
 #define HAVE_PUTENV		/* at least Bcc 5.2 and MSC have it */
 
 #ifdef FEAT_GUI_W32
diff --git a/src/proto/os_win32.pro b/src/proto/os_win32.pro
--- a/src/proto/os_win32.pro
+++ b/src/proto/os_win32.pro
@@ -43,6 +43,7 @@ void mch_write __ARGS((char_u *s, int le
 void mch_delay __ARGS((long msec, int ignoreinput));
 int mch_remove __ARGS((char_u *name));
 void mch_breakcheck __ARGS((void));
+long_u mch_total_mem __ARGS((int special));
 int mch_wrename __ARGS((WCHAR *wold, WCHAR *wnew));
 int mch_rename __ARGS((const char *pszOldFile, const char *pszNewFile));
 char *default_shell __ARGS((void));

Re: Set maxmem options based on available memory on Windows

[Mike Williams]

On 18/12/2015 09:41, Mike Williams wrote:

use GlobalMemoryStatus() just for old compilers like this:

#ifdef MEMORYSTATUSEX
   /* Use GlobalMemoryStatusEx() for recent compilers */
#else
   /* Use GlobalMemoryStatus() for old compilers */
#endif


Win2K does not support GlobalMemoryStatusEx().  The default Windows
build sets WINVER to 0x0400 to support Win2K compatible builds and this
excludes MEMORYSTATUSEX, so it is not new/compilers but old/new versions
of NT.


Rats, another silent regression in the code base.  The check #ifdef 
MEMORYSTATUSEX excludes the protected code when building with Visual C. 
 This is the second time in recent weeks I have stumbled into code that 
has checks for MingW builds that have ended up excluding code when built 
with VC.  I wonder how many other places in the code have the same 
problem.  Sigh, another general code review to do.


Anyway, patch v0.3 so that GlobalMemoryStatusEx() gets called when using 
VC.  Can someone check that it still compiles as expected with MingW please.


TTFN

Mike
--
AUTHORITY(n): someone who's guessed right more than once.

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

--- 
You received this message because you are subscribed to the Google Groups "vim_dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
diff --git a/src/os_win32.c b/src/os_win32.c
--- a/src/os_win32.c
+++ b/src/os_win32.c
@@ -5858,6 +5858,66 @@ mch_breakcheck(void)
 #endif
 }
 
+/* Physical RAM to leave for the OS */
+#define WINNT_RESERVE_BYTES (256*1024*1024)
+#define WIN95_RESERVE_BYTES (8*1024*1024)
+
+/*
+ * How much main memory in KiB that can be used by VIM.
+ */
+/*ARGSUSED*/
+long_u
+mch_total_mem(int special)
+{
+PlatformId();
+#if (defined(_MSC_VER) && (WINVER > 0x0400)) || defined(MEMORYSTATUSEX)
+if (g_PlatformId == VER_PLATFORM_WIN32_NT)
+{
+MEMORYSTATUSEX  ms;
+
+/* Need to use GlobalMemoryStatusEx() when there is more memory than
+ * what fits in 32 bits. But it's not always available. */
+ms.dwLength = sizeof(MEMORYSTATUSEX);
+GlobalMemoryStatusEx();
+if (ms.ullAvailVirtual < ms.ullTotalPhys)
+{
+/* Process address space fits in physical RAM, use all of it */
+return (long_u)(ms.ullAvailVirtual/1024);
+}
+if (ms.ullTotalPhys <= WINNT_RESERVE_BYTES)
+{
+/* Catch old NT box or perverse hardware setup */
+return (long_u)((ms.ullTotalPhys/2)/1024);
+}
+/* Use physical RAM less reserve for OS + data */
+return (long_u)((ms.ullTotalPhys - WINNT_RESERVE_BYTES)/1024);
+}
+else
+#endif
+{
+/* Pre-XP or 95 OS handling */
+MEMORYSTATUSms;
+long_u os_reserve_bytes;
+
+ms.dwLength = sizeof(MEMORYSTATUS);
+GlobalMemoryStatus();
+if (ms.dwAvailVirtual < ms.dwTotalPhys)
+{
+/* Process address space fits in physical RAM, use all of it */
+return (long_u)(ms.dwAvailVirtual/1024);
+}
+os_reserve_bytes = (g_PlatformId == VER_PLATFORM_WIN32_NT)
+? WINNT_RESERVE_BYTES
+: WIN95_RESERVE_BYTES;
+if (ms.dwTotalPhys <= os_reserve_bytes)
+{
+/* Catch old boxes or perverse hardware setup */
+return (long_u)((ms.dwTotalPhys/2)/1024);
+}
+/* Use physical RAM less reserve for OS + data */
+return (long_u)((ms.dwTotalPhys - os_reserve_bytes)/1024);
+}
+}
 
 #ifdef FEAT_MBYTE
 /*
diff --git a/src/os_win32.h b/src/os_win32.h
--- a/src/os_win32.h
+++ b/src/os_win32.h
@@ -78,6 +78,8 @@
 # define BREAKCHECK_SKIP1	/* call mch_breakcheck() each time, it's fast */
 #endif
 
+#define HAVE_TOTAL_MEM
+
 #define HAVE_PUTENV		/* at least Bcc 5.2 and MSC have it */
 
 #ifdef FEAT_GUI_W32
diff --git a/src/proto/os_win32.pro b/src/proto/os_win32.pro
--- a/src/proto/os_win32.pro
+++ b/src/proto/os_win32.pro
@@ -43,6 +43,7 @@ void mch_write __ARGS((char_u *s, int le
 void mch_delay __ARGS((long msec, int ignoreinput));
 int mch_remove __ARGS((char_u *name));
 void mch_breakcheck __ARGS((void));
+long_u mch_total_mem __ARGS((int special));
 int mch_wrename __ARGS((WCHAR *wold, WCHAR *wnew));
 int mch_rename __ARGS((const char *pszOldFile, const char *pszNewFile));
 char *default_shell __ARGS((void));

Re: Set maxmem options based on available memory on Windows

[Mike Williams]

On 18/12/2015 09:47, Christian Brabandt wrote:

On Fr, 18 Dez 2015, Mike Williams wrote:


Bram - any comment on finally dropping 95 support?  As in Win32s
(ah, happy days) - I can no longer do builds or run them so cannot
check the effect.


My opinion on that is to drop support for Windows versions older 2003,
since those are out of support for a very long time (except for 2003,
which went out of support this year).


A couple of years ago I proposed upping WINVER to at least 0x0500 
(Windows 2K!) since this enabled extra OS calls and features to be 
supported but at the exclusion of Win95/98/ME/NT4 support.  A couple of 
people piped up saying they still used such platforms and wanted VIM 
builds on them so it didn't change.  Perhaps this the time for another 
survey of the older versions of Windows VIM still needs to support. 
Windows XP most likely is the main older version to still support based 
on recent installation surveys.



This could be done with the upcoming 7.5 release.


I see a bandwagon gaining momentum ;)

Mike
--
AUTHORITY(n): someone who's guessed right more than once.

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

--- 
You received this message because you are subscribed to the Google Groups "vim_dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Set maxmem options based on available memory on Windows

[Mike Williams]

Hi,

Attached is a patch that sets the maxmem options at startup on Windows 
OSes based on reported memory availability.  It uses a simple heuristic 
to derive a value to use.  The checks for limited memory systems from 
the dark ages of last century may not be ideal, if anyone is still 
nursing such a system it would be nice to try the patch on it to see if 
the reserve numbers need to be tweaked.


HTH - TTFN

Mike
--
OPTIMISM - an optimist is someone who tells you to cheer up when things 
are going his way.


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

--- 
You received this message because you are subscribed to the Google Groups "vim_dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
diff --git a/src/os_win32.c b/src/os_win32.c
--- a/src/os_win32.c
+++ b/src/os_win32.c
@@ -5858,6 +5858,61 @@ mch_breakcheck(void)
 #endif
 }
 
+/* Physical RAM to leave for the OS */
+#define WINNT_RESERVE_BYTES (256*1024*1024)
+#define WIN95_RESERVE_BYTES (8*1024*1024)
+
+/*
+ * How much main memory in KiB that can be used by VIM.
+ */
+/*ARGSUSED*/
+long_u
+mch_total_mem(int special)
+{
+#ifdef MEMORYSTATUSEX
+PlatformId();
+if (g_PlatformId == VER_PLATFORM_WIN32_NT)
+{
+   MEMORYSTATUSEX  ms;
+
+   /* Need to use GlobalMemoryStatusEx() when there is more memory than
+* what fits in 32 bits. But it's not always available. */
+   ms.dwLength = sizeof(MEMORYSTATUSEX);
+   GlobalMemoryStatusEx();
+   if (ms.ullAvailVirtual < ms.ullTotalPhys)
+   {
+   /* Process address space fits in physical RAM, use all of it */
+   return (long_u)(ms.ullAvailVirtual/1024);
+   }
+   if (ms.ullTotalPhys < WINNT_RESERVE_BYTES)
+   {
+   /* Catch old NT box or perverse hardware setup */
+   return (long_u)((ms.ullTotalPhys/2)/1024);
+   }
+   /* Use physical RAM less reserve for OS + data */
+   return (long_u)((ms.ullTotalPhys - WINNT_RESERVE_BYTES)/1024);
+}
+else
+#endif
+{
+   MEMORYSTATUSms;
+
+   ms.dwLength = sizeof(MEMORYSTATUS);
+   GlobalMemoryStatus();
+   if (ms.dwAvailVirtual < ms.dwTotalPhys)
+   {
+   /* Process address space fits in physical RAM, use all of it */
+   return (long_u)(ms.dwAvailVirtual/1024);
+   }
+   if (ms.dwTotalPhys < WIN95_RESERVE_BYTES)
+   {
+   /* Catch old 95 box or perverse hardware setup */
+   return (long_u)((ms.dwTotalPhys/2)/1024);
+   }
+   /* Use physical RAM less reserve for OS + data */
+   return (long_u)((ms.dwTotalPhys - WIN95_RESERVE_BYTES)/1024);
+}
+}
 
 #ifdef FEAT_MBYTE
 /*
diff --git a/src/os_win32.h b/src/os_win32.h
--- a/src/os_win32.h
+++ b/src/os_win32.h
@@ -78,6 +78,8 @@
 # define BREAKCHECK_SKIP1	/* call mch_breakcheck() each time, it's fast */
 #endif
 
+#define HAVE_TOTAL_MEM
+
 #define HAVE_PUTENV		/* at least Bcc 5.2 and MSC have it */
 
 #ifdef FEAT_GUI_W32
diff --git a/src/proto/os_win32.pro b/src/proto/os_win32.pro
--- a/src/proto/os_win32.pro
+++ b/src/proto/os_win32.pro
@@ -43,6 +43,7 @@ void mch_write __ARGS((char_u *s, int le
 void mch_delay __ARGS((long msec, int ignoreinput));
 int mch_remove __ARGS((char_u *name));
 void mch_breakcheck __ARGS((void));
+long_u mch_total_mem __ARGS((int special));
 int mch_wrename __ARGS((WCHAR *wold, WCHAR *wnew));
 int mch_rename __ARGS((const char *pszOldFile, const char *pszNewFile));
 char *default_shell __ARGS((void));

Re: Set maxmem options based on available memory on Windows

[Mike Williams]

On 18/12/2015 10:35, Ken Takata wrote:

FYI, actually the official Vim 7.4 binary doesn't work on Win9x because
it is built by VC2008. (VC2005 is the last VC that supports Win9x.)
However I've never seen any complaint about this ;-)


It is more that it can be built for Win9x by those that still have the 
tools to do it and want to.  We rely on them reporting any issues 
introduced by the rest of us when modifying Windows specific code - I 
can't remember the last time this happened either.


Mike
--
AUTHORITY(n): someone who's guessed right more than once.

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

--- 
You received this message because you are subscribed to the Google Groups "vim_dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Sort corruption

[Mike Williams]

On 16/12/2015 23:13, Tony Mechelynck wrote:

In a running Vim (be it Huge gvim GUI, or Huge vim in console, or Tiny
"vi" Vim in console) I observe the following:
:verbose set maxmem? maxmemtot? maxmempattern?
   maxmem=4022316
   maxmemtot=4022316
   maxmempattern=1000

I suppose that the "4G" values (on this 64-bit system with 8G
installed and about 65% used), which are about twice the maximum
mentioned in the help, correspond to the vague couple of sentences "On
64 bit machines higher values might work.  But hey, do you really need
more than 2 Gbyte for text editing?" under 'maxmemtot' only (and yes,
I'm compiling my own gvim and vi for linux-x86_64).


From Christian's remark above I assume that the values compiled-in

will be _increased_ if possible during startup, to reach half the
installed memory size (1G on his 2G virtual machine, 4G in a 64-bit
Vim on my 8G machine). The values obtained above on my system don't
depend on whether or not SeaMonkey (which uses 3.7 GiB all by its
ownself, but I have more than 300 open tabs) is running or not at the
time of Vim startup.

Hmmm, I can't find HAVE_AVAIL_MEM in the config files (in the auto/
subdir of my shadowdir). The only HAVE_A* that I can find is
HAVE_ATTRIBUTE_UNUSED. I assume that Linux compile always behaves as
if HAVE_AVAIL_MEM were defined.


No, on unix HAVE_TOTAL_MEM is defined which can set the maxmem options 
based on detected available memory reported by the OS, not just total 
physical memory.  The HAVE_AVAIL_MEM is primarily used to limit memory 
allocations if it thinks there wont be any memory to allocate.  On 
systems like Amiga and MSDOS this makes sense, but on pre-emptive OSes 
this is not the case, hence the removal on Windows.


The logic in this area is confusing being a combination of PP defines, 
conditional logic, and platform specific default values.  I'll look some 
more into it to make the defaults on Windows more sensible and if the 
code can be simplified.


TTFN

Mike
--
If Satan ever loses his hair, there'll be hell toupee.

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

--- 
You received this message because you are subscribed to the Google Groups "vim_dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Sort corruption

[Mike Williams]

On 17/12/2015 12:30, Dominique Pellé wrote:

It is not a compiler optimisation bug.  I can reproduce the issue on linux
if I limit maxmem to 2048 and maxmemtot to 5120, the current Windows default
values for these options.  It is not Windows and/or compiler settings
specific.


I still can't reproduce the issue on Linux x86_64, even after setting maxmem
to 2048 and maxmemtot to 5120 as suggested.


I reproduced by setting these settings first, before following the rest 
of John's process for reproducing the corruption.  This is on 32bit 
Ubuntu 12.04, currently I don't have access to a 64bit unix to check for 
any difference.



I see no corruption and no errors reported by valgrind either. Yet, there must
be a bug since several people can see it.  If someone can reproduce it on
Linux, then use valgrind to tell what's wrong.


Out of interest what would you hope valgrind to report to indicate it 
can see a problem?  Should DrMemory be able to spot the issue?


Mike
--
Some people aren't hard of hearing, but hard of listening.

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

--- 
You received this message because you are subscribed to the Google Groups "vim_dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Sort corruption

[Mike Williams]

On 17/12/2015 12:30, Bram Moolenaar wrote:


John Beckett wrote:


Mike Williams:

I'll look some more into it to make the defaults on Windows
more sensible and if the code can be simplified.


Thanks all for the interesting progress. I'm trying to set up a test
system where I might be able to join in but it's a long time since I
worked in C. I don't know anything about the HAVE_xxx settings, but it
appears there is a condition where Vim's data can be corrupted and
that condition is being exposed by the particular tests being run.
However, the problem is potentially more general, and conceivably
corruptions could occur in other circumstances.

Have you reached a conclusion about whether the problem is related to
a compiler optimisation bug? My guess would be that it is not since I
don't think Steve Hall uses Visual Studio to build the
Vim-without-Cream that I mentioned, and it also shows the corruption.

There has to be a clue in the fact that I have only ever seen
corrupted text after executing :sort. Presumably Vim makes an array of
pointers and sorts them. That array is being clobbered, or Vim's
pointer to the array is being overwritten. Are any unchecked memory
allocations done in Vim's sort?


I can think of one reason for the corruption: When inserting the lines
in the sorted order, the pointer from ml_get() is passed to ml_append.
If the line is far away from where it came from, the pointer may become
invalid.  Copying the line into sortbuf1 would avoid that.  That's
already done when "unique" is true, but only afterwards.

It would be good to first be able to reproduce the problem, otherwise
we don't know if this change will actually fix the it.


--- ../../b/src/ex_cmds.c 2015-11-10 21:05:45.309028557 +0100
+++ ex_cmds.c   2015-12-17 13:00:53.896995875 +0100
@@ -540,10 +540,11 @@
 if (!unique || i == 0
 || (sort_ic ? STRICMP(s, sortbuf1) : STRCMP(s, sortbuf1)) != 0)
 {
-   if (ml_append(lnum++, s, (colnr_T)0, FALSE) == FAIL)
+   /* Copy the line into a buffer, it may become invalid in
+* ml_append(). And it's needed for "unique". */
+   STRCPY(sortbuf1, s);
+   if (ml_append(lnum++, sortbuf1, (colnr_T)0, FALSE) == FAIL)
 break;
-   if (unique)
-   STRCPY(sortbuf1, s);
 }
 fast_breakcheck();
 if (got_int)


Tried this on Linux where I have been able to reproduce the corrupt, and 
it fixed it for me.  I checked it twice in case of finger trouble.  Will 
try on Windows later.


Mike
--
Some people aren't hard of hearing, but hard of listening.

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

--- 
You received this message because you are subscribed to the Google Groups "vim_dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Sort corruption

[Mike Williams]

On 17/12/2015 15:26, Dominique Pellé wrote:

Mike Williams <mike.willi...@globalgraphics.com> wrote:

Out of interest what would you hope valgrind to report to indicate it can
see a problem?  Should DrMemory be able to spot the issue?


I suspect that in that case it would indicate access to freed memory
with stack where it's detected and stack where memory was previously freed.


There are a lot uninitialised reads but the callstacks are either in the 
NFS debug output functions (this is a debug build) or in the keyboard 
input handling functions.  Nothing which had a sort function in the 
callstack :(



But it can also report several other kinds of bugs that can explain
corruptions such as double free, access to uninitialized memory,
buffer overflows, ...


Yep, getting memory and handle leaks but at exit time - IIRC the policy 
for VIM is to just drop these all on the floor.



I'll try with 32-bits Linux later too.


Should DrMemory be able to spot the issue?


Probably, but I have not used it myself.


I'll continue using it to get a better handle on how it reports things. 
Yell if you'ld like to see the sort of output produced.


TTTFN

Mike
--
Youth would be an ideal state if it came a little later in life.

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

--- 
You received this message because you are subscribed to the Google Groups "vim_dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Sort corruption

[Mike Williams]

On 17/12/2015 10:50, JohnBeckett wrote:

Mike Williams:

I'll look some more into it to make the defaults on Windows
more sensible and if the code can be simplified.


Thanks all for the interesting progress. I'm trying to set up a test system 
where I might be able to join in but it's a long time since I worked in C. I 
don't know anything about the HAVE_xxx settings, but it appears there is a 
condition where Vim's data can be corrupted and that condition is being exposed 
by the particular tests being run. However, the problem is potentially more 
general, and conceivably corruptions could occur in other circumstances.


While paranoia is good in development in this case I think the simplest 
thing to say is that there seems to be corruption when using sort with 
low max mem settings.  Starting from there we'll see what any 
investigation shows up.  At least for now the workaround is to set 
maxmem values larger than the default.



Have you reached a conclusion about whether the problem is related to a 
compiler optimisation bug? My guess would be that it is not since I don't think 
Steve Hall uses Visual Studio to build the Vim-without-Cream that I mentioned, 
and it also shows the corruption.


It is not a compiler optimisation bug.  I can reproduce the issue on 
linux if I limit maxmem to 2048 and maxmemtot to 5120, the current 
Windows default values for these options.  It is not Windows and/or 
compiler settings specific.



There has to be a clue in the fact that I have only ever seen corrupted text 
after executing :sort. Presumably Vim makes an array of pointers and sorts 
them. That array is being clobbered, or Vim's pointer to the array is being 
overwritten. Are any unchecked memory allocations done in Vim's sort?


That is a good initial working theory.  The maxmem setting will cause 
VIM to recover memory and off the cuff it sounds like this is leaving 
dangling pointers which are then being used and just so happen to keep 
pointing to allocated memory so we don't see a crash, just random data.


This will be a 2 cups of tea problem ...

TTFN

Mike
--
Don't laugh at my coffee, you will be old and weak someday too.

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

--- 
You received this message because you are subscribed to the Google Groups "vim_dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Sort corruption

[Mike Williams]

On 16/12/2015 17:09, Mike Williams wrote:

On 16/12/2015 16:32, Christian Brabandt wrote:

Hi Mike!
For me it seems to be caused by patch 7.3.1141:
changeset:   4789:10673b3531eb
tag: v7.3.1141
user:Bram Moolenaar <b...@vim.org>
date:Fri Jun 07 19:17:14 2013 +0200
files:   src/os_win32.c src/os_win32.h src/version.c
description:
updated for version 7.3.1141
Problem:Win32: Check for available memory is not reliable and adds
  overhead.
Solution:   Remove mch_avail_mem(). (Mike Williams)


Yeah, I saw that and got a sinking feeling.  Double checked and got a
working build at the time and double checked.  It did not fail for me
originally which is why it now feels very sensitive to memory layout in
any particular build.  It may have been operator error.


I have checked 4789 with upped maxmem and it worked, and checked the 
previous change - 4787 with reduced maxmem and that failed.  So the 
issue is interaction of maxmem with the example process for reproducing 
the corruption.  I would imagine this means the issue can be forced on 
other systems as well and not just Windows.



While I don't know, if it is sensible to remove mch_avail_mem() on
windows, I believe this only triggers the bug, because when
HAVE_AVAIL_MEM is not set, vim internally sets the 'maxmem' and
'maxmemtot' options to much lower values and I think, high values of
those options just hide the bug.


The HAVE_AVAIL_MEM symbol controls two separate functions - setting of 
maxmem/maxmemtot and altering the memory allocator.  I removed it from 
Windows for the reasons in the commit - it slows the allocator and isn't 
accurate for how it was being used.  However, it does throw out the 
setting of maxmem/maxmemtot with it.  The setting of maxmem/maxmemtot 
should be under a separate control IMHO.


TTFN

Mike
--
But honey, I need a new Pentium server so I can reboot faster.

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

--- 
You received this message because you are subscribed to the Google Groups "vim_dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Sort corruption

[Mike Williams]

On 16/12/2015 16:32, Christian Brabandt wrote:

Hi Mike!
For me it seems to be caused by patch 7.3.1141:
changeset:   4789:10673b3531eb
tag: v7.3.1141
user:Bram Moolenaar <b...@vim.org>
date:Fri Jun 07 19:17:14 2013 +0200
files:   src/os_win32.c src/os_win32.h src/version.c
description:
updated for version 7.3.1141
Problem:Win32: Check for available memory is not reliable and adds
 overhead.
Solution:   Remove mch_avail_mem(). (Mike Williams)


Yeah, I saw that and got a sinking feeling.  Double checked and got a 
working build at the time and double checked.  It did not fail for me 
originally which is why it now feels very sensitive to memory layout in 
any particular build.  It may have been operator error.



While I don't know, if it is sensible to remove mch_avail_mem() on
windows, I believe this only triggers the bug, because when
HAVE_AVAIL_MEM is not set, vim internally sets the 'maxmem' and
'maxmemtot' options to much lower values and I think, high values of
those options just hide the bug.


That is possible - memory allocation pattern changes.  Comparing any 
malloc logs would show more info.  Something to investigate.



(a little bit later), yes, If I run vim 7.4.972 and
:set maxmem=1048575 maxmemtot=1048575
(old values since above patch was 2048 for maxmem and 5120 for
maxmemtot, before that patch, 1048575 was used) the corruption does not
occur.

This is probably the reason, the bug does not manifest itself on Linux
since there those options are a lot higher by default.


Hmm, no real reason why for modern Windows OS there should be any 
difference.  Are the lower numbers to cope with older Win95 machines 
that are unlikely to have as much memory available at all?  Should the 
value for Windows vary on the host OS?



So now we need to figure out, what is actually going wrong ;)


Mem allocator logs and binary chop maxmem values? ;) back at ya!

Mike
--
Mary had a little lamb... with mint jelly.

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

--- 
You received this message because you are subscribed to the Google Groups "vim_dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Sort corruption

[Mike Williams]

On 16 Dec 2015 10:17 pm, Christian Brabandt <cbli...@256bit.org> wrote:
>
> On Mi, 16 Dez 2015, Mike Williams wrote:
>
> > On 16/12/2015 19:14, Christian Brabandt wrote:
> > >[HAVE_AVAIL_MEM]
> > >>However, it does throw out the setting of maxmem/maxmemtot with it.
> > >>The setting of maxmem/maxmemtot should be under a separate control
> > >>IMHO.
> > >
> > >Yes that I thought as well.
> > >
> > >I remember when I debugged the blowfish corruption bug on Windows I
> > >wondered why the maxmem/maxmemtot setting was so much lower than on
> > >Linux. I wanted to suggest increasing that setting on Windows as well,
> > >but forgot about it.
> >
> > The simplest fix is to up the default values for maxmem and
> > maxmemtot on Win32 to match the values for unix:
> >
> >
> > diff --git a/src/os_win32.h b/src/os_win32.h
> > --- a/src/os_win32.h
> > +++ b/src/os_win32.h
> > @@ -123,11 +123,11 @@
> >  #define TEMPNAMELEN_MAX_PATH   /* length of temp file name path */
> >
> >  #ifndef DFLT_MAXMEM
> > -# define DFLT_MAXMEM   (2*1024)/* use up to 2 Mbyte for a buffer */
> > +# define DFLT_MAXMEM   (5*1024)/* use up to 5 Mbyte for a buffer */
> >  #endif
> >
> >  #ifndef DFLT_MAXMEMTOT
> > -# define DFLT_MAXMEMTOT(5*1024)/* use up to 5 Mbyte for Vim */
> > +# define DFLT_MAXMEMTOT(10*1024)   /* use up to 10 Mbyte for Vim */
> >  #endif
> >
> >  /*
>
> Considering that even on my test Linux virtual machine with 2 GB of
> memory the limit is about 1GB for maxmem and maxmemtot and considering
> the increasing popularity of plugins as well as features like editing
> multi GB logfiles and increasing complex undotree available, I still
> think that 10 Mbyte and 5 Mbyte for Windows are still a little, err,
> "limiting".

As I said, matching the unix defaults. In most cases these days there will be 
lots of memory available. Small system boards tend to come with custom built 
vi/vims, and you wouldn't try to do too much on them anyway. So yeah the 
default could be upped to say 64/512 but that is up to Bram. For now I set my 
preferred limits in my vimrc.

> Even before patch 7.3.1142 that limit was a lot higher.
> But I guess I can always script something in vimrc file with
> wmic os get TotalVisibleMemorySize

How about on Windows running a 32bit process on 64bit OS with 8GiB of RAM? Max 
mem usable is 4GiB, the limit for the virtual address space. Windows can report 
available virtual address for the process, what is left for the heap after the 
process is started which will be less than this. No point artificially limiting 
it to half of this is there? For a 64 bit process this is not practical, so 
what value should be used?  On recent Windows, physical RAM less 250MiB for OS 
and its data should be more than adequate for maxmemtot to avoid paging and not 
be limiting. This suggests pushing the logic for default values down into mch_ 
functions so they can OS specific rather than applying a rough heuristic to all 
of them.

TTFN

> or something like that.
>
> Best,
> Christian
> --
>  Ich habe es damals als Unix-DAU aus der Manpage rausgelesen.
> Wenn Du das heute nicht auf die Reihe bekommst, ist das peinlich.
> -- #LinuxGER
>
> --
> --
> You received this message from the "vim_dev" maillist.
> Do not top-post! Type your reply below the text you are replying to.
> For more information, visit http://www.vim.org/maillist.php
>
> ---
> You received this message because you are subscribed to the Google Groups 
> "vim_dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to vim_dev+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

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

--- 
You received this message because you are subscribed to the Google Groups 
"vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Sort corruption

[Mike Williams]

On 16/12/2015 19:14, Christian Brabandt wrote:

[HAVE_AVAIL_MEM]

However, it does throw out the setting of maxmem/maxmemtot with it.
The setting of maxmem/maxmemtot should be under a separate control
IMHO.


Yes that I thought as well.

I remember when I debugged the blowfish corruption bug on Windows I
wondered why the maxmem/maxmemtot setting was so much lower than on
Linux. I wanted to suggest increasing that setting on Windows as well,
but forgot about it.


The simplest fix is to up the default values for maxmem and maxmemtot on 
Win32 to match the values for unix:



diff --git a/src/os_win32.h b/src/os_win32.h
--- a/src/os_win32.h
+++ b/src/os_win32.h
@@ -123,11 +123,11 @@
 #define TEMPNAMELEN_MAX_PATH   /* length of temp file name path */

 #ifndef DFLT_MAXMEM
-# define DFLT_MAXMEM   (2*1024)/* use up to 2 Mbyte for a buffer */
+# define DFLT_MAXMEM   (5*1024)/* use up to 5 Mbyte for a buffer */
 #endif

 #ifndef DFLT_MAXMEMTOT
-# define DFLT_MAXMEMTOT(5*1024)/* use up to 5 Mbyte for Vim */
+# define DFLT_MAXMEMTOT(10*1024)   /* use up to 10 Mbyte for Vim */
 #endif

 /*


I had a look at resurrecting mch_avail_mem() and using the argument to 
just do something for initialisation, but there isn't any consistently 
reasonable value that can be returned as it depends what the machine is 
doing at the moment you start VIM.  Its most likely more effort than its 
worth.


HTH - TTFN

Mike
--
Any discipline for a cat that does not involve petting that cat will 
backfire.


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

--- 
You received this message because you are subscribed to the Google Groups "vim_dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Sort corruption

[Mike Williams]

On 16/12/2015 09:27, JohnBeckett wrote:

Dominique Pelle wrote:

Sorry, I forgot to check for plugins. I get no corruption when no plugins are 
loaded.

The following shows how to reproduce the corruption from scratch.

In a temp directory, make file auto.vim as follows.

--- Start of auto.vim ---

" Simplified LargeFile.vim
augroup LargeFile
   au BufReadPre *
   \ let f=expand("") |
   \  if getfsize(f) >= 100*1024*1024 |
   \  let b:eikeep=  |
   \  let b:ulkeep=  |
   \  set ei=FileType |
   \  setlocal noswf bh=unload |
   \  let f=escape(substitute(f,'\','/','g'),' ') |
   \  exe "au LargeFile BufEnter ".f." set ul=-1" |
   \  exe "au LargeFile BufLeave ".f." let =".b:ulkeep."|set ei=".b:eikeep |
   \  exe "au LargeFile BufUnload ".f." au! LargeFile * ". f |
   \  echomsg "***note*** handling a large file" |
   \ endif
augroup END

--- end ---

Execute the following two lines in Vim to create the big file in the temp 
directory:

:let x = [repeat('a',20), repeat('b',25), repeat('c',30), repeat('d',35), 
repeat('e',40)]
:call writefile(repeat(x, 100), 'big.tmp')

In the temp directory, start Vim with no plugins:

vim -N -u NONE -i NONE

Execute the following commands:

:source auto.vim
:e big.tmp
:1,2y
:vnew
:put
:%s/.*/\=strlen(submatch(0)) . "\t" . submatch(0)/
:nohlsearch

Sorting the buffer shows obvious corruption (many blank lines and junk):

:sort

John



Hi John

I tried to reproduce the corruption as you described,
but I did not see any problem on Linux x86_64.
I tried with both asan and valgrind.  Your bug might
be Win32 specific.

I don't have Windows, but I wonder whether someone
could try Vim with DrMemory. See http://www.drmemory.org/

asan may also work on Windows, but I'm not 100% sure.
See:
http://stackoverflow.com/questions/11806469/clang-with-faddress-sanitizer-on-windows

Using those tools on Windows would obviously be useful
to test Vim beyond this particular sort corruption bug.

Regards
Dominique


Thanks for investigating, and for the good ideas which I'll try to follow. I 
skipped the obvious stuff because it seemed unlikely to be an issue with the 
platform-specific code.

Here are my results on different systems I could find:

- Vim 7.4.972 win32 on 64-bit Windows 7 (my build): shows bug.


Vim 7.4.972 64bit optimised build on Win7 64-bit: shows bug.
Vim 7.4.972 64bit debug build on Win7 64-bit: no problem.

Looks like it may be a compiler optimizer issue.  My compiler on this 
machine is VS2012 fully patched.  I can check on VS2015 on my home 
machine tonight.



- Vim 7.4.827 on Windows XP (from cream): shows bug.
- Vim 7.3.266 on Windows XP (my build): no problem.
- Vim 7.3.415 on 32-bit Linux (my build): no problem.

The "cream" was from installing gvim-7-4-827.exe (Vim-without-Cream):
http://sourceforge.net/projects/cream/files/Vim/

It would be nice if others could report findings.

John




Mike
--
If you see only one film this year, then you need to get out more.

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

--- 
You received this message because you are subscribed to the Google Groups "vim_dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Sort corruption

[Mike Williams]

On 16/12/2015 12:45, Mike Williams wrote:

On 16/12/2015 12:22, Mike Williams wrote:

On 16/12/2015 09:27, JohnBeckett wrote:

Dominique Pelle wrote:

Sorry, I forgot to check for plugins. I get no corruption when no plugins are 
loaded.

The following shows how to reproduce the corruption from scratch.

In a temp directory, make file auto.vim as follows.

--- Start of auto.vim ---

" Simplified LargeFile.vim
augroup LargeFile
 au BufReadPre *
 \ let f=expand("") |
 \  if getfsize(f) >= 100*1024*1024 |
 \  let b:eikeep=  |
 \  let b:ulkeep=  |
 \  set ei=FileType |
 \  setlocal noswf bh=unload |
 \  let f=escape(substitute(f,'\','/','g'),' ') |
 \  exe "au LargeFile BufEnter ".f." set ul=-1" |
 \  exe "au LargeFile BufLeave ".f." let =".b:ulkeep."|set ei=".b:eikeep 
|
 \  exe "au LargeFile BufUnload ".f." au! LargeFile * ". f |
 \  echomsg "***note*** handling a large file" |
 \ endif
augroup END

--- end ---

Execute the following two lines in Vim to create the big file in the temp 
directory:

:let x = [repeat('a',20), repeat('b',25), repeat('c',30), repeat('d',35), 
repeat('e',40)]
:call writefile(repeat(x, 100), 'big.tmp')

In the temp directory, start Vim with no plugins:

vim -N -u NONE -i NONE

Execute the following commands:

:source auto.vim
:e big.tmp
:1,2y
:vnew
:put
:%s/.*/\=strlen(submatch(0)) . "\t" . submatch(0)/
:nohlsearch

Sorting the buffer shows obvious corruption (many blank lines and junk):

:sort

John



Hi John

I tried to reproduce the corruption as you described,
but I did not see any problem on Linux x86_64.
I tried with both asan and valgrind.  Your bug might
be Win32 specific.

I don't have Windows, but I wonder whether someone
could try Vim with DrMemory. See http://www.drmemory.org/

asan may also work on Windows, but I'm not 100% sure.
See:
http://stackoverflow.com/questions/11806469/clang-with-faddress-sanitizer-on-windows

Using those tools on Windows would obviously be useful
to test Vim beyond this particular sort corruption bug.

Regards
Dominique


Thanks for investigating, and for the good ideas which I'll try to follow. I 
skipped the obvious stuff because it seemed unlikely to be an issue with the 
platform-specific code.

Here are my results on different systems I could find:

- Vim 7.4.972 win32 on 64-bit Windows 7 (my build): shows bug.


Vim 7.4.972 64bit optimised build on Win7 64-bit: shows bug.
Vim 7.4.972 64bit debug build on Win7 64-bit: no problem.

Looks like it may be a compiler optimizer issue.  My compiler on this
machine is VS2012 fully patched.  I can check on VS2015 on my home
machine tonight.


Scratch that - got my .exes mixed up.  Debug build show bug as well.
Same happens with VS2010 as well FWIW.


hg bisect to the rescue!  The sort corruption starts with this commit of 
a one line change:


changeset:   4791:65cef998f860
tag: v7.3.1142
user:Bram Moolenaar <b...@vim.org>
date:Fri Jun 07 19:48:39 2013 +0200
files:   src/syntax.c src/version.c
description:
updated for version 7.3.1142
Problem:Memory leak in ":syntime report".
Solution:   Clear the grow array. (Dominique Pelle)



- Vim 7.4.827 on Windows XP (from cream): shows bug.
- Vim 7.3.266 on Windows XP (my build): no problem.
- Vim 7.3.415 on 32-bit Linux (my build): no problem.

The "cream" was from installing gvim-7-4-827.exe (Vim-without-Cream):
http://sourceforge.net/projects/cream/files/Vim/

It would be nice if others could report findings.

John




Mike




Mike




Mike
--
They say it is better to give than to receive; I say it depends on the gift.

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

--- 
You received this message because you are subscribed to the Google Groups "vim_dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Sort corruption

[Mike Williams]

On 16/12/2015 15:28, Dominique Pellé wrote:

Mike Williams <mike.willi...@globalgraphics.com> wrote:


hg bisect to the rescue!  The sort corruption starts with this commit of a
one line change:

changeset:   4791:65cef998f860
tag: v7.3.1142
user:Bram Moolenaar <b...@vim.org>
date:Fri Jun 07 19:48:39 2013 +0200
files:   src/syntax.c src/version.c
description:
updated for version 7.3.1142
Problem:Memory leak in ":syntime report".
Solution:   Clear the grow array. (Dominique Pelle)


Hi Mike

This looks strange to me:
- patch 7.3.1142 looks fine to me at first sight
- and the code changed in patch 7.3.1142 is not executed
   anyway in the case described by John Beckett.

Can you or someone else double-check the bisection?
Unfortunately, I still cannot reproduce the bug myself.


I have checked it through again and it now looks unreliable.  Builds I 
swear worked ok before now fail when built again, and this is with clean 
rebuilds each time.  I can't go back that far in VIM history due to 
limited compiler support in past years.  If nothing else that would seem 
to indicate the cause of the issue is not something recent.


I have started looking at DrMemory but there is a fair amount of 
background noise, not least due to the NFA logs produced with debug 
builds.  It will take a little while to learn this tool.



Maybe someone also has access to proprietary tools
on Windows like Purify or Insure++.


Sorry, I don't.  Anyone else?

Mike
--
Help support helpless victims of computer error.

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

--- 
You received this message because you are subscribed to the Google Groups "vim_dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Sort corruption

[Mike Williams]

On 16/12/2015 12:22, Mike Williams wrote:

On 16/12/2015 09:27, JohnBeckett wrote:

Dominique Pelle wrote:

Sorry, I forgot to check for plugins. I get no corruption when no plugins are 
loaded.

The following shows how to reproduce the corruption from scratch.

In a temp directory, make file auto.vim as follows.

--- Start of auto.vim ---

" Simplified LargeFile.vim
augroup LargeFile
au BufReadPre *
\ let f=expand("") |
\  if getfsize(f) >= 100*1024*1024 |
\  let b:eikeep=  |
\  let b:ulkeep=  |
\  set ei=FileType |
\  setlocal noswf bh=unload |
\  let f=escape(substitute(f,'\','/','g'),' ') |
\  exe "au LargeFile BufEnter ".f." set ul=-1" |
\  exe "au LargeFile BufLeave ".f." let =".b:ulkeep."|set ei=".b:eikeep |
\  exe "au LargeFile BufUnload ".f." au! LargeFile * ". f |
\  echomsg "***note*** handling a large file" |
\ endif
augroup END

--- end ---

Execute the following two lines in Vim to create the big file in the temp 
directory:

:let x = [repeat('a',20), repeat('b',25), repeat('c',30), repeat('d',35), 
repeat('e',40)]
:call writefile(repeat(x, 100), 'big.tmp')

In the temp directory, start Vim with no plugins:

vim -N -u NONE -i NONE

Execute the following commands:

:source auto.vim
:e big.tmp
:1,2y
:vnew
:put
:%s/.*/\=strlen(submatch(0)) . "\t" . submatch(0)/
:nohlsearch

Sorting the buffer shows obvious corruption (many blank lines and junk):

:sort

John



Hi John

I tried to reproduce the corruption as you described,
but I did not see any problem on Linux x86_64.
I tried with both asan and valgrind.  Your bug might
be Win32 specific.

I don't have Windows, but I wonder whether someone
could try Vim with DrMemory. See http://www.drmemory.org/

asan may also work on Windows, but I'm not 100% sure.
See:
http://stackoverflow.com/questions/11806469/clang-with-faddress-sanitizer-on-windows

Using those tools on Windows would obviously be useful
to test Vim beyond this particular sort corruption bug.

Regards
Dominique


Thanks for investigating, and for the good ideas which I'll try to follow. I 
skipped the obvious stuff because it seemed unlikely to be an issue with the 
platform-specific code.

Here are my results on different systems I could find:

- Vim 7.4.972 win32 on 64-bit Windows 7 (my build): shows bug.


Vim 7.4.972 64bit optimised build on Win7 64-bit: shows bug.
Vim 7.4.972 64bit debug build on Win7 64-bit: no problem.

Looks like it may be a compiler optimizer issue.  My compiler on this
machine is VS2012 fully patched.  I can check on VS2015 on my home
machine tonight.


Scratch that - got my .exes mixed up.  Debug build show bug as well. 
Same happens with VS2010 as well FWIW.



- Vim 7.4.827 on Windows XP (from cream): shows bug.
- Vim 7.3.266 on Windows XP (my build): no problem.
- Vim 7.3.415 on 32-bit Linux (my build): no problem.

The "cream" was from installing gvim-7-4-827.exe (Vim-without-Cream):
http://sourceforge.net/projects/cream/files/Vim/

It would be nice if others could report findings.

John




Mike




Mike
--
Everyone talks about apathy, but no one does anything about 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

--- 
You received this message because you are subscribed to the Google Groups "vim_dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

GVimExt 64bit builds with VS2015

[Mike Williams]

Hi,

GVimEXT fails to build for me with VS2015, a large number of undefined 
symbols from the Windows headers when compiling.  The Makefile is 
missing some symbols defined that Win32.mak needs to set up the build 
environment correctly.


I have tested the following patch with a VS2015 64bit and a VS2011 32bit 
build and both built without warning for me.  I don't use gvimext so can 
someone else try the patch and see if the resulting build works ok.



diff --git a/src/GvimExt/Makefile b/src/GvimExt/Makefile
--- a/src/GvimExt/Makefile
+++ b/src/GvimExt/Makefile
@@ -12,6 +12,24 @@ APPVER=5.0
 NODEBUG = 1
 !endif

+!ifdef PROCESSOR_ARCHITECTURE
+# On Windows NT
+TARGETOS = WINNT
+! ifndef CPU
+CPU = i386
+!  ifdef PLATFORM
+!   if ("$(PLATFORM)" == "x64") || ("$(PLATFORM)" == "X64")
+CPU = AMD64
+!   elseif ("$(PLATFORM)" != "x86") && ("$(PLATFORM)" != "X86")
+!error *** ERROR Unknown target platform "$(PLATFORM)". Make aborted.
+!   endif
+!  endif
+! endif
+!else
+TARGETOS = WIN95
+CPU = i386
+!endif
+


TTFN

Mike
--
If at first you don't succeed, so much for sky-diving.

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

--- 
You received this message because you are subscribed to the Google Groups "vim_dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Fix for pointer truncation warning on Windows.

[Mike Williams]

Hi all,

VS2015 is raising a pointer cast truncation warning in gui_w32.c  On 
64bit builds with VC HandleToLong() is a function but for 32bit builds 
it is a macro.  The current VIM code defines a macro if one is not 
defined so shadows the function call resulting in the warning.


Going through the source history this looks like it got broken when 
coping with MingW warnings in 7.3.870.  The following patch copes with 
old MS compilers (for the Win95 hold outs - are there still any?) and 
MingW.  I don't have MingW so can someone please check the following 
works for them, and if a 64bit MingW raises its own warning for the cast.



diff --git a/src/gui_w32.c b/src/gui_w32.c
--- a/src/gui_w32.c
+++ b/src/gui_w32.c
@@ -1769,9 +1769,11 @@ gui_mch_init(void)
 #endif

 #ifdef FEAT_EVAL
-# ifndef HandleToLong
-/* HandleToLong() only exists in compilers that can do 64 bit builds */
-#  define HandleToLong(h) ((long)(h))
+# if !defined(_MSC_VER) || (_MSC_VER < 1400)
+/* Define HandleToLong for old MS and none-MS compilers if not defined */
+#  ifndef HandleToLong
+#   define HandleToLong(h) ((long)(h))
+#  endif
 # endif
 /* set the v:windowid variable */
 set_vim_var_nr(VV_WINDOWID, HandleToLong(s_hwnd));


TTFN

Mike
--
If at first you don't succeed, so much for sky-diving.

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

--- 
You received this message because you are subscribed to the Google Groups "vim_dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Windows 64bit build in 32bit command prompt

[Mike Williams]

Hi,

Another week, another diff.  After some discussion with Ken and Taro I 
offer up the following diff to cope with and (attempt to) tidy up cross 
compilation across architectures with Visual Studio.



diff --git a/src/Make_mvc.mak b/src/Make_mvc.mak
--- a/src/Make_mvc.mak
+++ b/src/Make_mvc.mak
@@ -209,22 +209,25 @@ OBJDIR = $(OBJDIR)d
 !ifdef PROCESSOR_ARCHITECTURE
 # We're on Windows NT or using VC 6+
 ! ifdef CPU
-ASSEMBLY_ARCHITECTURE=$(CPU)
 # Using I386 for $ASSEMBLY_ARCHITECTURE doesn't work for VC7.
-!  if ("$(ASSEMBLY_ARCHITECTURE)" == "i386") || 
("$(ASSEMBLY_ARCHITECTURE)" == "I386")

-ASSEMBLY_ARCHITECTURE = x86
-!  endif
-! else
-CPU = $(PROCESSOR_ARCHITECTURE)
-ASSEMBLY_ARCHITECTURE = $(PROCESSOR_ARCHITECTURE)
-!  if ("$(CPU)" == "x86") || ("$(CPU)" == "X86")
+!  if "$(CPU)" == "I386"
 CPU = i386
 !  endif
+! else  # !CPU
+CPU = i386
+!  ifdef PLATFORM
+!   if ("$(PLATFORM)" == "x64") || ("$(PLATFORM)" == "X64")
+CPU = AMD64
+!   elseif ("$(PLATFORM)" != "x86") && ("$(PLATFORM)" != "X86")
+!error *** ERROR Unknown target platform "$(PLATFORM)". Make aborted.
+!   endif
+!  endif  # !PLATFORM
 ! endif
 !else  # !PROCESSOR_ARCHITECTURE
 # We're on Windows 95
 CPU = i386
 !endif # !PROCESSOR_ARCHITECTURE
+ASSEMBLY_ARCHITECTURE=$(CPU)
 OBJDIR = $(OBJDIR)$(CPU)

 # Build a retail version by default
@@ -415,7 +418,7 @@ CPUARG =
 !endif
 !else
 # VC8/9/10 only allows specifying SSE architecture but only for 32bit
-!if "$(ASSEMBLY_ARCHITECTURE)" == "x86" && "$(CPUNR)" == "pentium4"
+!if "$(ASSEMBLY_ARCHITECTURE)" == "i386" && "$(CPUNR)" == "pentium4"
 CPUARG = /arch:SSE2
 !endif
 !endif


In theory you can target ARM from Intel host but I don't a system to 
test that so I haven't tried to guess at the right code for it.


TTFN

Mike
--
Life is unfair but remember: sometimes it is unfair in your favour.

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

--- 
You received this message because you are subscribed to the Google Groups "vim_dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Windows 64bit build in 32bit command prompt

[Mike Williams]

Hi Ken (and Taro),

On 29/11/2015 15:13, Ken Takata wrote:

Hi Mike,

2015/11/29 Sun 20:06:42 UTC+9 Mike Williams wrote:

Hi,

Just done my first build of VIM on an old Windows 7 32bit machine
upgraded to Windows 10 using VC.  The link stage was failing due to
mixed machine targets being used in the make file - 32 and 64 bit!  I
tracked this down to some fun with the PROCESSOR_ARCHITECTURE in a 32bit
prompt on a 64bit machine, see -

http://blogs.msdn.com/b/david.wang/archive/2006/03/26/howto-detect-process-bitness.aspx

I guess no one has ever tried to do this until now.  It seems reasonable
to default to the host processor architecture and not the architecture
of the process being used to run the build.  The following diff solves
the build issue for me:

diff --git a/src/Make_mvc.mak b/src/Make_mvc.mak
--- a/src/Make_mvc.mak
+++ b/src/Make_mvc.mak
@@ -217,7 +217,11 @@ ASSEMBLY_ARCHITECTURE=$(CPU)
   ASSEMBLY_ARCHITECTURE = x86
   !  endif
   ! else
+!  ifdef PROCESSOR_ARCHITEW6432
+CPU = $(PROCESSOR_ARCHITEW6432)
+!  else
   CPU = $(PROCESSOR_ARCHITECTURE)
+!  endif
   ASSEMBLY_ARCHITECTURE = $(PROCESSOR_ARCHITECTURE)
   !  if ("$(CPU)" == "x86") || ("$(CPU)" == "X86")
   CPU = i386


HTH - TTFN

Mike
--
Accept that some days you're the pigeon, and some days you're the statue.


I currently build 32-bit and 64-bit Vim on 64-bit Win10 without changing the
Makefile. I use 32-bit compiler for 32-bit target and 64-bit compiler for
64-bit target, but you seem to use 32-bit cross compiler targeting 64-bit.
The current makefile assume that the bitness of nmake.exe is the same as the
target, and it doesn't support cross compiling.
We need another approach to support cross compiling.


I agree that my patch is the wrong solution.  As Taro points out using 
the Platform environment var should take into account the cross 
compilation target.  However it does not seem to be set for every 
architecture passed to vcvarsall.bat.  I'll try a few things and see 
where they leads.


TTFN

Mike
--
Accept that some days you're the pigeon, and some days you're the statue.

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

--- 
You received this message because you are subscribed to the Google Groups "vim_dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Windows 64bit build in 32bit command prompt

[Mike Williams]

On 29/11/2015 16:57, Taro MURAOKA wrote:

I wrote:

We may be able to use "Platform" environment variable for this purpose.
It get one of values: "x64", "X64", "X86" or "ARM" as cross compiling target,
in all of VS10, 11, 12, 14 environments.



Hi Mike and Ken.


I have wrote a patch to use PLATFORM for this purpose.
Please try https://gist.github.com/koron/c51efe584d0b4e5686a4


There is still a problem when building 32bit when PROCESSOR_ARCHITECTURE 
is amd64.  I think that if PLATFORM is not defined it should default CPU 
to i386 and not use PROCESSOR_ARCHITECTURE.


Mike
--
Accept that some days you're the pigeon, and some days you're the statue.

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

--- 
You received this message because you are subscribed to the Google Groups "vim_dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Windows 64bit build in 32bit command prompt

[Mike Williams]

On 29/11/2015 17:04, Mike Williams wrote:

Hi Ken (and Taro),

On 29/11/2015 15:13, Ken Takata wrote:

Hi Mike,

2015/11/29 Sun 20:06:42 UTC+9 Mike Williams wrote:

Hi,

Just done my first build of VIM on an old Windows 7 32bit machine
upgraded to Windows 10 using VC.  The link stage was failing due to
mixed machine targets being used in the make file - 32 and 64 bit!  I
tracked this down to some fun with the PROCESSOR_ARCHITECTURE in a 32bit
prompt on a 64bit machine, see -

http://blogs.msdn.com/b/david.wang/archive/2006/03/26/howto-detect-process-bitness.aspx

I guess no one has ever tried to do this until now.  It seems reasonable
to default to the host processor architecture and not the architecture
of the process being used to run the build.  The following diff solves
the build issue for me:

diff --git a/src/Make_mvc.mak b/src/Make_mvc.mak
--- a/src/Make_mvc.mak
+++ b/src/Make_mvc.mak
@@ -217,7 +217,11 @@ ASSEMBLY_ARCHITECTURE=$(CPU)
ASSEMBLY_ARCHITECTURE = x86
!  endif
! else
+!  ifdef PROCESSOR_ARCHITEW6432
+CPU = $(PROCESSOR_ARCHITEW6432)
+!  else
CPU = $(PROCESSOR_ARCHITECTURE)
+!  endif
ASSEMBLY_ARCHITECTURE = $(PROCESSOR_ARCHITECTURE)
!  if ("$(CPU)" == "x86") || ("$(CPU)" == "X86")
CPU = i386


HTH - TTFN

Mike
--
Accept that some days you're the pigeon, and some days you're the statue.


I currently build 32-bit and 64-bit Vim on 64-bit Win10 without changing the
Makefile. I use 32-bit compiler for 32-bit target and 64-bit compiler for
64-bit target, but you seem to use 32-bit cross compiler targeting 64-bit.
The current makefile assume that the bitness of nmake.exe is the same as the
target, and it doesn't support cross compiling.
We need another approach to support cross compiling.


I agree that my patch is the wrong solution.  As Taro points out using
the Platform environment var should take into account the cross
compilation target.  However it does not seem to be set for every
architecture passed to vcvarsall.bat.  I'll try a few things and see
where they leads.


My bad, too many command prompts with too many environments - Taro is on 
the right track.


Mike
--
Accept that some days you're the pigeon, and some days you're the statue.

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

--- 
You received this message because you are subscribed to the Google Groups "vim_dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Windows 64bit build in 32bit command prompt

[Mike Williams]

Hi,

Just done my first build of VIM on an old Windows 7 32bit machine 
upgraded to Windows 10 using VC.  The link stage was failing due to 
mixed machine targets being used in the make file - 32 and 64 bit!  I 
tracked this down to some fun with the PROCESSOR_ARCHITECTURE in a 32bit 
prompt on a 64bit machine, see -


http://blogs.msdn.com/b/david.wang/archive/2006/03/26/howto-detect-process-bitness.aspx

I guess no one has ever tried to do this until now.  It seems reasonable 
to default to the host processor architecture and not the architecture 
of the process being used to run the build.  The following diff solves 
the build issue for me:


diff --git a/src/Make_mvc.mak b/src/Make_mvc.mak
--- a/src/Make_mvc.mak
+++ b/src/Make_mvc.mak
@@ -217,7 +217,11 @@ ASSEMBLY_ARCHITECTURE=$(CPU)
 ASSEMBLY_ARCHITECTURE = x86
 !  endif
 ! else
+!  ifdef PROCESSOR_ARCHITEW6432
+CPU = $(PROCESSOR_ARCHITEW6432)
+!  else
 CPU = $(PROCESSOR_ARCHITECTURE)
+!  endif
 ASSEMBLY_ARCHITECTURE = $(PROCESSOR_ARCHITECTURE)
 !  if ("$(CPU)" == "x86") || ("$(CPU)" == "X86")
 CPU = i386


HTH - TTFN

Mike
--
Accept that some days you're the pigeon, and some days you're the statue.

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

--- 
You received this message because you are subscribed to the Google Groups "vim_dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Patch 7.4.944

[Mike Williams]

On 29/11/2015 21:01, Bram Moolenaar wrote:


Christian Brabandt wrote:


On So, 29 Nov 2015, Bram Moolenaar wrote:



Nikolay Pavlov wrote:


2015-11-29 19:36 GMT+03:00 Bram Moolenaar :



Patch 7.4.944
Problem:Writing tests for Vim script is hard.
Solution:   Add assertEqual(), assertFalse() and assertTrue() functions.
Add



Why `assert{upper case letter}`? I know exactly no functions that use this
naming convention.


Yes, it's different.  There are some other functions with a capital,


There are? Which ones?


hlID()
synID()
synIDattr()

diff_hlID() is nicely inconsistent..


but many more with an underscore, or just all lower case.

But I do think that assertEqual() is easier to read than assertequal()
and it's shorter than assert_equal().  So do we prefer consistency or
nicer names?


+1 for consistency and the underscore.


Counting votes...


+1 for consistency/predictability over inconsistency.  You may not like 
it but life is easier in the long run.


https://en.wikipedia.org/wiki/Principle_of_least_astonishment

Perhaps there also is a case for adding hl_id(), syn_id(), etc.  Or is 
the move to rename all existing functions in camelCase?  Or just new 
ones?  Or special ones, and if so how are special ones recognised?


Mike
--
Virtue is insufficient temptation.

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

--- 
You received this message because you are subscribed to the Google Groups "vim_dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Windows compilation warning

[Mike Williams]

Hi,

This is with 7.4p915 building on Win7 amd64.  I am getting the following 
warning:


ex_cmds.c(1861) : warning C4013: 'mch_ishidden' undefined; assuming 
extern returning int


This function was added with p906 but is missing a prototype.  Would the 
following do?


diff --git a/src/proto/os_win32.pro b/src/proto/os_win32.pro
--- a/src/proto/os_win32.pro
+++ b/src/proto/os_win32.pro
@@ -19,6 +19,7 @@ int mch_dirname __ARGS((char_u *buf, int
 long mch_getperm __ARGS((char_u *name));
 int mch_setperm __ARGS((char_u *name, long perm));
 void mch_hide __ARGS((char_u *name));
+int mch_ishidden __ARGS((char_u *name));
 int mch_isdir __ARGS((char_u *name));
 int mch_mkdir __ARGS((char_u *name));
 int mch_is_hard_link __ARGS((char_u *fname));

HTH - TTFN

Mike
--
Don't rush me - I'm dawdling as fast as I can!

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

--- 
You received this message because you are subscribed to the Google Groups "vim_dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: VIM console failure on Windows

[Mike Williams]

On 20/10/2015 21:40, Mike Williams wrote:

On my Windows boxes I use ConsoleZ (https://github.com/cbucher/console)
instead of the standard command or powershell prompts.  Using 7.4p889
when I start console VIM I get a brief flash of the VIM interface before
it switches back to the original command line display.  VIM is still
running (can be seen in task manager consuming CPU) but keyboard input
has no effect on - :q doesn't quit VIM and the command prompt doesn't
show any keyboard input.  This all started with patch 851, Saving and
restoring the console buffer does not work properly.

I have checked what happens with the command and powershell shells using
ConsoleZ and there is no difference in behaviour.  I am using version
1.15.0.15253 of ConsoleZ.  ConsoleZ is a fork of Console
(http://sourceforge.net/projects/console/).  I checked what happens with
Console version Console 2.00.148 and it behaves the same as ConsoleZ.

It may be an issue with the Console apps but I have been using both for
the last few years and until this patch have had no problems using
console VIM with them.  The finger pointing has to start somewhere so
let it be here.


Sorry, missed the usual required OS and build info.  This is on Windows 
7 amd64, fully patched, with a 64bit build of VIM using VS2012, debug 
and release.  Build line of:


nmake -f make_mvc.mak WINVER=0x0501 DIRECTX=yes PYTHON=h:\python27 
PYTHON_VER=27 DYNAMIC_PYTHON=yes


Hmm, ok, the DIRECTX=yes looks unnecessary for a console VIM.  Removed 
it and tried again.  Still hangs, but I don't get the flash of the VIM 
interface now.


HTH - TTFN

Mike
--
All the world's a stage, and I missed the rehearsal.

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

--- 
You received this message because you are subscribed to the Google Groups "vim_dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

VIM console failure on Windows

[Mike Williams]

Hi,

On my Windows boxes I use ConsoleZ (https://github.com/cbucher/console) 
instead of the standard command or powershell prompts.  Using 7.4p889 
when I start console VIM I get a brief flash of the VIM interface before 
it switches back to the original command line display.  VIM is still 
running (can be seen in task manager consuming CPU) but keyboard input 
has no effect on - :q doesn't quit VIM and the command prompt doesn't 
show any keyboard input.  This all started with patch 851, Saving and 
restoring the console buffer does not work properly.


I have checked what happens with the command and powershell shells using 
ConsoleZ and there is no difference in behaviour.  I am using version 
1.15.0.15253 of ConsoleZ.  ConsoleZ is a fork of Console 
(http://sourceforge.net/projects/console/).  I checked what happens with 
Console version Console 2.00.148 and it behaves the same as ConsoleZ.


It may be an issue with the Console apps but I have been using both for 
the last few years and until this patch have had no problems using 
console VIM with them.  The finger pointing has to start somewhere so 
let it be here.


TTFN

Mike
--
I hate mornings. They start too early in the day.

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

--- 
You received this message because you are subscribed to the Google Groups "vim_dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Warning in huge compile of eval.c

[Mike Williams]

On 07/02/2015 18:00, James McCoy wrote:

On Sat, Feb 07, 2015 at 03:42:50PM +, Mike Williams wrote:

I have looked through the potentially uninitialised variables reported for
my usual Windows builds and they all look benign.  It seems the compiler is
just spotting branches in the code where the variable is not assigned to but
is used later.  A simplistic example is:

   int foo, bar;

   if (a)
 foo = bar;
   else
 bar = 1;

   if (a)
 bar += 2*foo;

This generates a warning since it doesn't spot that foo is initialised and
referenced under the same condition.


Well, bar when a is true, then bar is uninitialized and when a is false,
foo is uninitialized.  Maybe that wasn't the example you meant.


Email in haste, bugs reported at leisure ;-)  Yep, I meant to initialise 
bar first.  I'll get my coat.


Mike
--
Just when you thought you were winning the rat race, along comes a 
faster rat.


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

--- 
You received this message because you are subscribed to the Google Groups vim_dev group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Fix potential NULL pointer dereference in if_py_both.h

[Mike Williams]

Hi,

In if_py_both.h there is code there is code that dereferences a pointer 
before checking if it is NULL.  Attached patch against .622 fixes.


Mike
--
Just when you thought you were winning the rat race, along comes a 
faster rat.


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

--- 
You received this message because you are subscribed to the Google Groups vim_dev group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
diff --git a/src/if_py_both.h b/src/if_py_both.h
--- a/src/if_py_both.h
+++ b/src/if_py_both.h
@@ -747,12 +747,13 @@ VimToPython(typval_T *our_tv, int depth,
 else if (our_tv-v_type == VAR_DICT)
 {
 
-	hashtab_T	*ht = our_tv-vval.v_dict-dv_hashtab;
-	long_u	todo = ht-ht_used;
+	hashtab_T	*ht;
+	long_u		todo;
 	hashitem_T	*hi;
 	dictitem_T	*di;
 	if (our_tv-vval.v_dict == NULL)
 	return NULL;
+	*ht = our_tv-vval.v_dict-dv_hashtab;
 
 	if (!(ret = PyDict_New()))
 	return NULL;
@@ -763,6 +764,7 @@ VimToPython(typval_T *our_tv, int depth,
 	return NULL;
 	}
 
+	todo = ht-ht_used;
 	for (hi = ht-ht_array; todo  0; ++hi)
 	{
 	if (!HASHITEM_EMPTY(hi))

Re: Fix potential NULL pointer dereference in if_py_both.h

[Mike Williams]

One asterisk too many, compilable patch now attached.

Mike
--
Just when you thought you were winning the rat race, along comes a 
faster rat.


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

--- 
You received this message because you are subscribed to the Google Groups vim_dev group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
diff --git a/src/if_py_both.h b/src/if_py_both.h
--- a/src/if_py_both.h
+++ b/src/if_py_both.h
@@ -747,12 +747,13 @@ VimToPython(typval_T *our_tv, int depth,
 else if (our_tv-v_type == VAR_DICT)
 {
 
-	hashtab_T	*ht = our_tv-vval.v_dict-dv_hashtab;
-	long_u	todo = ht-ht_used;
+	hashtab_T	*ht;
+	long_u		todo;
 	hashitem_T	*hi;
 	dictitem_T	*di;
 	if (our_tv-vval.v_dict == NULL)
 	return NULL;
+	ht = our_tv-vval.v_dict-dv_hashtab;
 
 	if (!(ret = PyDict_New()))
 	return NULL;
@@ -763,6 +764,7 @@ VimToPython(typval_T *our_tv, int depth,
 	return NULL;
 	}
 
+	todo = ht-ht_used;
 	for (hi = ht-ht_array; todo  0; ++hi)
 	{
 	if (!HASHITEM_EMPTY(hi))

Fix crash/memory leak in some low memory situations

[Mike Williams]

Hi,

There are some uses of vim_realloc() that can lead to a memory leak and 
possibly an immediate crash if the call to vim_realloc() fails.  A 
little ironic to be leaking memory when failing trying to allocate some.


Attached is a diff against 7.4.622.

There is one occurrence I didn't fix, in regexp_nfa.c in addstate().  I 
know this is very sensitive code with no obvious memory error handling 
for me to work off.  One for someone more comfortable in this file to fix.


Mike
--
I haven't lost it! It's been temporally mislaid.

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

--- 
You received this message because you are subscribed to the Google Groups vim_dev group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
diff --git a/src/if_cscope.c b/src/if_cscope.c
--- a/src/if_cscope.c
+++ b/src/if_cscope.c
@@ -1507,9 +1507,14 @@ cs_insert_filelist(fname, ppath, flags, 
 	}
 	else
 	{
+	csinfo_T *t_csinfo = csinfo;
 	/* Reallocate space for more connections. */
 	csinfo_size *= 2;
 	csinfo = vim_realloc(csinfo, sizeof(csinfo_T)*csinfo_size);
+	if (csinfo == NULL) {
+		vim_free(t_csinfo);
+		csinfo_size = 0;
+	}
 	}
 	if (csinfo == NULL)
 	return -1;
@@ -2059,6 +2064,7 @@ cs_print_tags_priv(matches, cntxts, num_
 int num_matches;
 {
 char	*buf = NULL;
+char	*t_buf;
 int		bufsize = 0; /* Track available bufsize */
 int		newsize = 0;
 char	*ptag;
@@ -2120,9 +2126,13 @@ cs_print_tags_priv(matches, cntxts, num_
 	newsize = (int)(strlen(csfmt_str) + 16 + strlen(lno));
 	if (bufsize  newsize)
 	{
+	t_buf = buf;
 	buf = (char *)vim_realloc(buf, newsize);
-	if (buf == NULL)
+	if (buf == NULL) {
 		bufsize = 0;
+		if (t_buf != NULL)
+		vim_free(t_buf);
+	}
 	else
 		bufsize = newsize;
 	}
@@ -2143,9 +2153,13 @@ cs_print_tags_priv(matches, cntxts, num_
 
 	if (bufsize  newsize)
 	{
+	t_buf = buf;
 	buf = (char *)vim_realloc(buf, newsize);
-	if (buf == NULL)
+	if (buf == NULL) {
 		bufsize = 0;
+		if (t_buf != NULL)
+		vim_free(t_buf);
+	}
 	else
 		bufsize = newsize;
 	}
diff --git a/src/memline.c b/src/memline.c
--- a/src/memline.c
+++ b/src/memline.c
@@ -5057,6 +5057,7 @@ ml_updatechunk(buf, line, len, updtype)
 	/* May resize here so we don't have to do it in both cases below */
 	if (buf-b_ml.ml_usedchunks + 1 = buf-b_ml.ml_numchunks)
 	{
+	chunksize_T *t_chunksize = buf-b_ml.ml_chunksize;
 	buf-b_ml.ml_numchunks = buf-b_ml.ml_numchunks * 3 / 2;
 	buf-b_ml.ml_chunksize = (chunksize_T *)
 		vim_realloc(buf-b_ml.ml_chunksize,
@@ -5064,6 +5065,7 @@ ml_updatechunk(buf, line, len, updtype)
 	if (buf-b_ml.ml_chunksize == NULL)
 	{
 		/* H, Give up on offset for this buffer */
+		vim_free(t_chunksize);
 		buf-b_ml.ml_usedchunks = -1;
 		return;
 	}
diff --git a/src/misc1.c b/src/misc1.c
--- a/src/misc1.c
+++ b/src/misc1.c
@@ -3431,10 +3431,13 @@ get_keystroke()
 	buf = alloc(buflen);
 	else if (maxlen  10)
 	{
+	char_u  *t_buf = buf;
 	/* Need some more space. This might happen when receiving a long
 	 * escape sequence. */
 	buflen += 100;
 	buf = vim_realloc(buf, buflen);
+	if (buf == NULL)
+		vim_free(t_buf);
 	maxlen = (buflen - 6 - len) / 3;
 	}
 	if (buf == NULL)
diff --git a/src/netbeans.c b/src/netbeans.c
--- a/src/netbeans.c
+++ b/src/netbeans.c
@@ -1080,10 +1080,16 @@ nb_get_buf(int bufno)
 {
 	if (bufno = buf_list_size) /* grow list */
 	{
+	nbbuf_T *t_buf_list = buf_list;
 	incr = bufno - buf_list_size + 90;
 	buf_list_size += incr;
 	buf_list = (nbbuf_T *)vim_realloc(
    buf_list, buf_list_size * sizeof(nbbuf_T));
+	if (buf_list == NULL) {
+		vim_free(t_buf_list);
+		buf_list_size = 0;
+		return NULL;
+	}
 	vim_memset(buf_list + buf_list_size - incr, 0,
 		  incr * sizeof(nbbuf_T));
 	}
@@ -3678,11 +3684,17 @@ addsigntype(
 	{
 		int incr;
 		int oldlen = globalsignmaplen;
+		char **t_globalsignmap = globalsignmap;
 
 		globalsignmaplen *= 2;
 		incr = globalsignmaplen - oldlen;
 		globalsignmap = (char **)vim_realloc(globalsignmap,
 	   globalsignmaplen * sizeof(char *));
+		if (globalsignmap == NULL) {
+		vim_free(t_globalsignmap);
+		globalsignmaplen = 0;
+		return;
+		}
 		vim_memset(globalsignmap + oldlen, 0, incr * sizeof(char *));
 	}
 	}
@@ -3708,11 +3720,17 @@ addsigntype(
 	{
 	int incr;
 	int oldlen = buf-signmaplen;
+	int *t_signmap = buf-signmap;
 
 	buf-signmaplen *= 2;
 	incr = buf-signmaplen - oldlen;
 	buf-signmap = (int *)vim_realloc(buf-signmap,
 	   buf-signmaplen * sizeof(int));
+	if (buf-signmap == NULL) {
+		vim_free(t_signmap);
+		

Re: Warning in huge compile of eval.c

[Mike Williams]

On 07/02/2015 13:38, Bram Moolenaar wrote:


Mike Williams wrote:


On 04/02/2015 16:19, Ben Fritz wrote:

It looks like I need to enable some compiler warning options on my
Windows build setup at home. :-(


Just turned up MSVC build from W3 to W4.  I had to turn off a bunch of
warnings through vim.h for the usual C coding slackness, but doesn't
catch them all since not all files include vim.h.  See attached diff for
details.

The build with VC11 throws up a pile more potentially un-intialised
before use variables, amongst a few other C hacks used in VIM that may
or may not be important to address.  I doubt VIM will ever default to W4
when building, but it is good to go through the exercise once in a while
to clean the worst things up, and then fall back to W3.

There is enough there to come a few people busy for a while so just dive
into issues you see.


I guess that compilers throw more warnings to avoid mistakes in C
programs, even though the code is OK.  I can include that patch, but I
don't think we can avoid some warnings without taking a penalty in
performance.


I have looked through the potentially uninitialised variables reported 
for my usual Windows builds and they all look benign.  It seems the 
compiler is just spotting branches in the code where the variable is not 
assigned to but is used later.  A simplistic example is:


  int foo, bar;

  if (a)
foo = bar;
  else
bar = 1;

  if (a)
bar += 2*foo;

This generates a warning since it doesn't spot that foo is initialised 
and referenced under the same condition.  There are various approaches 
that can be made to remove the warnings from simple initialisation 
through code refactoring.


The other common warning is for function and data pointer conversions. 
In standard C a function pointer is not compatible with void * but 
typically doesn't cause a problem, so not worth worrying about.


Based on this I don't see any point in using W4 with Visual C, you just 
get a pile of warnings you wont ever clear up.


There may be more used in looking at the output from ANALYZE=yes with 
VC.  More code reading ...


Mike
--
My computer's sick and I think my modem is a carrier.

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

--- 
You received this message because you are subscribed to the Google Groups vim_dev group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Warning in huge compile of eval.c

[Mike Williams]

On 04/02/2015 16:19, Ben Fritz wrote:

It looks like I need to enable some compiler warning options on my Windows 
build setup at home. :-(


Just turned up MSVC build from W3 to W4.  I had to turn off a bunch of 
warnings through vim.h for the usual C coding slackness, but doesn't 
catch them all since not all files include vim.h.  See attached diff for 
details.


The build with VC11 throws up a pile more potentially un-intialised 
before use variables, amongst a few other C hacks used in VIM that may 
or may not be important to address.  I doubt VIM will ever default to W4 
when building, but it is good to go through the exercise once in a while 
to clean the worst things up, and then fall back to W3.


There is enough there to come a few people busy for a while so just dive 
into issues you see.


HTH - TTFN

Mike
--
My other computer's a... er... well, it's a piece of junk too.

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

--- 
You received this message because you are subscribed to the Google Groups vim_dev group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
diff --git a/src/Make_mvc.mak b/src/Make_mvc.mak
--- a/src/Make_mvc.mak
+++ b/src/Make_mvc.mak
@@ -359,7 +359,7 @@ WINVER = 0x0400
 #VIMRCLOC = somewhere
 #VIMRUNTIMEDIR = somewhere
 
-CFLAGS = -c /W3 /nologo $(CVARS) -I. -Iproto -DHAVE_PATHDEF -DWIN32 \
+CFLAGS = -c /W4 /nologo $(CVARS) -I. -Iproto -DHAVE_PATHDEF -DWIN32 \
 		$(SNIFF_DEFS) $(CSCOPE_DEFS) $(NETBEANS_DEFS) \
 		$(NBDEBUG_DEFS) $(XPM_DEFS) \
 		$(DEFINES) -DWINVER=$(WINVER) -D_WIN32_WINNT=$(WINVER) \
diff --git a/src/vim.h b/src/vim.h
--- a/src/vim.h
+++ b/src/vim.h
@@ -2044,6 +2044,20 @@ typedef int VimClipboard;	/* This is req
 #ifdef _MSC_VER
 /* Avoid useless warning conversion from X to Y of greater size. */
  #pragma warning(disable : 4312)
+/* Avoid warning for old style function declarators */
+ #pragma warning(disable : 4131)
+/* Avoid warning for conversion to type with smaller range */
+ #pragma warning(disable : 4244)
+/* Avoid warning for conversion to larger size */
+ #pragma warning(disable : 4306)
+/* Avoid warning for unreferenced formal parameter */
+ #pragma warning(disable : 4100)
+/* Avoid warning for differs in indirection to slightly different base type */
+ #pragma warning(disable : 4057)
+/* Avoid warning for constant conditional expression */
+ #pragma warning(disable : 4127)
+/* Avoid warning for assignment within conditional */
+ #pragma warning(disable : 4706)
 #endif
 
 /* Note: a NULL argument for vim_realloc() is not portable, don't use it. */

Who will think of the children?

[Mike Williams]

And many died in the great systemd-emacs-vim war of 2014!

http://raymii.org/s/blog/Vim_as_PID_1_Boot_to_Vim.html

Mike
--
My mind isn't always in the gutter - sometimes it comes out to feed.

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

--- 
You received this message because you are subscribed to the Google Groups vim_dev group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.