(addend As Integer)
Static Integer accumulator
accumulator = accumulator + addend
TestFriend = accumulator
End Function
Sub TestTypeKeyword()
Type EmployeeRecord ' Create user-defined type.
ID As Integer ' Define elements of dat
Chris,
Thank you for the explanation but I don't think it explains everything.
See below.
On 05/13/2024 4:15 PM, Christian Brabandt wrote:
On Mo, 13 Mai 2024, Michael Soyka wrote:
Yes, your are right- the bwipeout command succeeds without the double
quotes in vim9script. Thanks fo
ation!
On 05/13/2024 4:15 PM, Christian Brabandt wrote:
On Mo, 13 Mai 2024, Michael Soyka wrote:
Yes, your are right- the bwipeout command succeeds without the double
quotes in vim9script. Thanks for the solution!
Given that, what feature of vim9script causes the error when double
quotes ar
this should be added to vim9-differences
documentation.
On Monday, May 13, 2024 at 1:16:25 PM UTC-4 Christian J. Robinson wrote:
Try it without the quotes:
bwipeout %
On Mon, May 13, 2024 at 10:55 AM Michael Soyka wrote:
In the process of converting a file from vimscript to vim9script, I
In the process of converting a file from vimscript to vim9script, I came
across the following inconsistent behavior with the ex-command bwipeout
"%". I'm running gvim 9.1.136 in Windows 10. The problem is demonstrated
by the two scripts below.
bwipeoutBug.vim:
" Source this script, then e
Vim developers,
I am in the process of adding a "test" target to Make_cyg_ming.mak so that
the test suite can be run from src.
That makefile supports cygwin builds as well as mingw builds.
My question is which makefile in testdir is used when testing the cygwin
build? I looks like it would
On 09/22/2020 4:34 AM, Bram Moolenaar wrote:
Michael Soyka wrote:
I do not see any reference to testdir/Make_ming.mak from any of the
Makefiles in the src directory.
The src/Make_cyg_ming.mak file does not even have a "test" target.
Only src/Make_mvc.mak refers to testdir/Make_dos.
On Wednesday, September 16, 2020 at 9:42:14 AM UTC-4, Bram Moolenaar wrote:
>
>
> Michael Soyka wrote:
>
> > Using Make_ming.mak, the "tinytests" collection of build tests will fail
> if
> > the associated .ok file has Windows line endings. This happens
Vim developers,
Using Make_ming.mak, the "tinytests" collection of build tests will fail if
the associated .ok file has Windows line endings. This happens because the
test.out file is explicitly set to have unix/linux line endings but the .ok
file has not been converted and so "diff" concludes
Vim developers,
The following statement
if not exist $@ $(DEL) $@
on line 98 in testdir/Make_ming.mak has two errors:
1. it attempts to delete a non-existing file and
2. the path that is substituted for $@ includes unix/linux path separators.
The attached patch fixes both.
Regards,
On Sunday, May 17, 2020 at 11:15:56 PM UTC-4, Ken Takata wrote:
>
> Hi,
>
> 2020/5/18 Mon 9:37:10 UTC+9 Michael Soyka wrote:
>>
>> Vim developers,
>>
>> When I try to build gvim on Wiindows XP using mingw with FEATURES=SMALL,
>> I get "windowsVer
Vim developers,
When I try to build gvim on Wiindows XP using mingw with FEATURES=SMALL, I
get "windowsVersion undeclared" on line 839 of file os_win32.c. This
variable is instantiated in globals.h but only if FEAT_EVAL is defined and
this happens only for NORMAL builds.
The compilation err
On Thursday, March 19, 2020 at 7:39:20 AM UTC-4, Bram Moolenaar wrote:
>
>
> Michael Soyka wrote:
>
> > Feature +autochdir is not included in the +feature-list topic in
> > runtime/doc/various.txt. The attached patch adds it. Feel free to
> rewrite
> >
Bram / Vim developers:
Feature +autochdir is not included in the +feature-list topic in
runtime/doc/various.txt. The attached patch adds it. Feel free to rewrite
as necessary.
-mike
--
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text
On Tuesday, January 28, 2020 at 7:17:27 AM UTC-5, Ken Takata wrote:
>
> Hi,
>
> I also faced the same issue.
>
> 2020/1/28 Tue 19:18:26 UTC+9 Bram Moolenaar wrote:
>>
>>
>> Michael Soyka wrote:
>>
>> > Builtin function feedinput is called i
Bram, et al,
Builtin function feedinput is called in Test_range, file
testdir/test_functions.vim. This function works only with +unix or GUI is
running. Calling this function will cause vim.exe (without GUI) to lockup
(Windows 10).
I've not used "CheckUnix" and "CheckGui" in the attached p
On Friday, December 27, 2019 at 7:50:18 AM UTC-5, Bram Moolenaar wrote:
>
>
> Michael Soyka wrote:
>
> > When the DIRECTX feature is enabled at compilation, the setting of
> option
> > 'renderoptions' to "type:directx" causes gvim to load &
On Friday, December 27, 2019 at 7:50:18 AM UTC-5, Bram Moolenaar wrote:
>
>
> Michael Soyka wrote:
>
> > When the DIRECTX feature is enabled at compilation, the setting of
> option
> > 'renderoptions' to "type:directx" causes gvim to load &
Vim developers,
When the DIRECTX feature is enabled at compilation, the setting of option
'renderoptions' to "type:directx" causes gvim to load "dwrite.dll" which is
not available from Microsoft for Windows XP systems. The load attempt
generates error E474 which causes the test script "opt_tes
The clean target in the cygwin/ming makefile does not delete map files
created by the linker. The attached patch is my proposed fix.
--
--
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 htt
On 11/08/2019 5:00 PM, Bram Moolenaar wrote:
Michael Soyka wrote:
In function Test_script_local_func ,defined in test_vimscript.vim, the
'compatible' option is turned off. This has the side effect of turning the
'more' option on which can cause test execution to be halte
In function Test_script_local_func ,defined in test_vimscript.vim, the
'compatible' option is turned off. This has the side effect of turning the
'more' option on which can cause test execution to be halted by the more
prompt. The attached patch prevents this by setting 'nomore' after
'nocp'.
In my version of git-for-windows, bash defines that environment variable as
ProgramW6432.
On Tuesday, September 17, 2019 at 6:10:01 PM UTC-4, CrispyDrone wrote:
>
> *Describe the bug*
> I've exhausted all options and followed the documentation but am unable to
> get :! {cmd} to work with the f
Since patch 474 places if_perl.c in "auto", the following patch is
suggested. I can't test the Visual C changes but it looks like it
should work.
diff --git a/src/Make_cyg_ming.mak b/src/Make_cyg_ming.mak
index e213b803d..05725e988 100644
--- a/src/Make_cyg_ming.mak
+++ b/src/Make_cyg_ming.ma
On 10/10/2018 4:54 AM, K.Takata (Vim Github Repository) wrote:
Hm, isn't it the same for the |Makefile| for unix like systems?
I can't respond to this. There are several implementations of the ctags
utility. I don't know how one could programatically distinguish between
them.
P.S. It seem
On 10/10/2018 4:54 AM, K.Takata (Vim Github Repository) wrote:
Hm, isn't it the same for the |Makefile| for unix like systems?
P.S. It seems that you are not familiar with markdown. Use a pair of
triple backquotes to surround your code.
E.g.
|```diff (Paste your diff code here) ```|
|I agre
Problem Statement.
Unasked-for vertical split created in second tabbed window
Test Environment.
gVim, patch 413 (https://www.vim.org/download.php#pc)
Windows 10, 64-bit
Windows XP, 32-bit
Problem Demonstration.
There are two requirements to demonstrate the problem:
1. an autocmd
On 8/7/2018 1:26 PM, Ken Takata wrote:
Hi,
2018/8/8 Wed 1:46:02 UTC+9 Michael Soyka wrote:
On 8/7/2018 11:46 AM, Ken Takata wrote:
Hi,
2018/8/8 Wed 0:39:08 UTC+9 Bram Moolenaar wrote:
Ken Takata wrote:
2018/8/7 Tue 10:48:19 UTC+9 Michael Soyka wrote:
On 8/6/2018 8:45 PM, Ken Takata wrote
On 8/7/2018 11:46 AM, Ken Takata wrote:
Hi,
2018/8/8 Wed 0:39:08 UTC+9 Bram Moolenaar wrote:
Ken Takata wrote:
2018/8/7 Tue 10:48:19 UTC+9 Michael Soyka wrote:
On 8/6/2018 8:45 PM, Ken Takata wrote:
[...]
It appears src/Make_cyg_ming.mak also does this:
ifneq (sh.exe, $(SHELL
On 8/6/2018 8:45 PM, Ken Takata wrote:
Hi,
2018/8/7 Tue 5:58:56 UTC+9 Bram Moolenaar wrote:
Problem
---
The if-tests in the makefile src/po/Make_ming.mak do not do what is
intended. Furthermore, they do not allow for the possibility that the
value of the make variable SHELL might include a
On 8/6/2018 5:10 PM, Michael Soyka wrote:
On 8/6/2018 4:58 PM, Bram Moolenaar wrote:
Problem
---
The if-tests in the makefile src/po/Make_ming.mak do not do what is
intended. Furthermore, they do not allow for the possibility that the
value of the make variable SHELL might include a path
On 8/6/2018 4:58 PM, Bram Moolenaar wrote:
Problem
---
The if-tests in the makefile src/po/Make_ming.mak do not do what is
intended. Furthermore, they do not allow for the possibility that the
value of the make variable SHELL might include a path specification.
Issues
--
1. The if-tes
On 5/21/2018 4:50 PM, Bram Moolenaar wrote:
Michael Soyka wrote:
On 5/20/2018 12:30 PM, Bram Moolenaar wrote:
I want to try debugging on MS-Windows with gdb. I normally build with
MSVC, but I don't see a way to use that executable with gdb (perhaps
it's possible with some com
On 5/20/2018 12:30 PM, Bram Moolenaar wrote:
I want to try debugging on MS-Windows with gdb. I normally build with
MSVC, but I don't see a way to use that executable with gdb (perhaps
it's possible with some compiler flag?).
So I'll use MinGW for compiling. MinGW provides gcc and make, so I
exp
On 10/9/2017 4:46 PM, Bram Moolenaar wrote:
Michael Soyka wrote:
Vim Developers:
In the file src/Make_cyg_ming.mak, the variable ICONV is given the value
"yes" on line 51, suggesting it is intended to be boolean valued. It is
tested as a boolean on line 847 but is also used,
Vim Developers:
In the file src/Make_cyg_ming.mak, the variable ICONV is given the value
"yes" on line 51, suggesting it is intended to be boolean valued. It is
tested as a boolean on line 847 but is also used, I believe incorrectly,
on lines 848 and 849:
847 ifneq (yes, $(ICONV))
848 LIB +
Vim developers,
Build test numbers 71 and 74 have been deleted from the git repository
but are still referenced in the ming makefile. The following diff
illustrates the proposed change:
diff --git a/src/testdir/Make_ming.mak b/src/testdir/Make_ming.mak
index 3330691..ab6a60b 100644
--- a/src
Hi Ken,
On 9/5/2016 12:26 AM, Ken Takata wrote:
Hi mike,
2016/9/5 Mon 10:07:00 UTC+9 Michael Soyka wrote:
The makefile testdir/Make_ming.mak contains statements of the form:
if exist test.ok $(DEL) test.ok
which can only be executed by one of the DOS/Windows command shells such
as
The makefile testdir/Make_ming.mak contains statements of the form:
if exist test.ok $(DEL) test.ok
which can only be executed by one of the DOS/Windows command shells such
as command.com or cmd.exe
My version of make, gnu 3.82.90, sets the SHELL make variable to the
value "C:/MinGW/msys/1
The Vim test "test_getcwd" creates a temporary directory "Xtopdir" that
should be deleted at test conclusion but is not. This directory is not
deleted because the test has created swap files that apparently are open
when the test attempts to cleanup before terminating.
Setting the noswapfile o
On 8/19/2016 4:05 PM, Charles E Campbell wrote:
Hello:
I'm having a problem with using git and making local changes to files I
maintain. In particular: I make changes to syntax/sh.vim (locally), and
then
git fails:
runtime/syntax/sh.vim: needs merge
runtime/syntax/sh.vim: needs merge
runtime/s
On 4/3/2016 10:01 PM, Tony Mechelynck wrote:
On Mon, Apr 4, 2016 at 1:10 AM, Michael Soyka wrote:
Vim developers,
Currently the Vim test scripts can only be run using the
testdir/Make_ming.mak makefile. I propose adding a "test" target to
src/Make_cyg_ming.mak to make it possi
Vim developers,
Currently the Vim test scripts can only be run using the
testdir/Make_ming.mak makefile. I propose adding a "test" target to
src/Make_cyg_ming.mak to make it possible to run those tests from the
"src" directory. If this is done, the instructions for running these
test using
Hi Ken,
On 12/30/2015 12:35 PM, Ken Takata wrote:
Hi Michael,
2015/12/31 Thu 2:10:14 UTC+9 Michael Soyka wrote:
On 12/30/2015 11:40 AM, Bram Moolenaar wrote:
Ken Takata wrote:
2015/12/30 Wed 22:46:09: UTC+9 Bram Moolenaar wrote:
I wrote:
Ken Takata wrote:
2015/12/29 Tue 21:59:54 UTC+9
On 12/30/2015 11:40 AM, Bram Moolenaar wrote:
Ken Takata wrote:
2015/12/30 Wed 22:46:09: UTC+9 Bram Moolenaar wrote:
I wrote:
Ken Takata wrote:
2015/12/29 Tue 21:59:54 UTC+9 Bram Moolenaar wrote:
Ken Takata wrote:
2015/12/29 Tue 6:25:06 UTC+9 Bram Moolenaar wrote:
Christian Brabandt wr
On 12/7/2015 5:45 AM, Nikolay Aleksandrovich Pavlov wrote:
2015-12-07 1:35 GMT+03:00 Michael Soyka <mailto:mso...@cox.net>>:
On 12/6/2015 4:41 PM, Bram Moolenaar wrote:
Michael Soyka wrote:
On 12/5/2015 1:47 PM, Bram Moolenaar wrote:
Mich
On 12/6/2015 4:41 PM, Bram Moolenaar wrote:
Michael Soyka wrote:
On 12/5/2015 1:47 PM, Bram Moolenaar wrote:
Michael Soyka wrote:
On 12/4/2015 5:27 PM, Bram Moolenaar wrote:
Michael Soyka wrote:
On 12/3/2015 4:13 PM, Bram Moolenaar wrote:
I have added "new style" testing for
On 12/5/2015 1:47 PM, Bram Moolenaar wrote:
Michael Soyka wrote:
On 12/4/2015 5:27 PM, Bram Moolenaar wrote:
Michael Soyka wrote:
On 12/3/2015 4:13 PM, Bram Moolenaar wrote:
I have added "new style" testing for Unix. It appears to work well, so
now we also need this for other
On 12/4/2015 5:27 PM, Bram Moolenaar wrote:
Michael Soyka wrote:
On 12/3/2015 4:13 PM, Bram Moolenaar wrote:
I have added "new style" testing for Unix. It appears to work well, so
now we also need this for other platforms. The Unix Makefile only
needed a few extra lines, hopefully
On 12/3/2015 4:13 PM, Bram Moolenaar wrote:
I have added "new style" testing for Unix. It appears to work well, so
now we also need this for other platforms. The Unix Makefile only
needed a few extra lines, hopefully it's also simple for others.
I would prefer someone who knows the platform to
Vim developers,
I am trying to build 32-bit Vim using a mingw compiler that generates
64-bit output files by default. I specify ARCH=i686 on the make command
line. Compilation fails with the first file because -m64 is the
compiler default. This problem would not occur if the makefile
src/M
On 11/29/2015 3:26 PM, Christian Brabandt wrote:
On So, 29 Nov 2015, Bram Moolenaar wrote:
Michael Soyka wrote:
As of patch 942, the build-test "listchars" fails under Windows when
using the mingw compiler. Specifically, the command "diff test.out
test_listchars.ok" fa
Vim developers,
Many ming makefiles contain the following statement:
ifneq (sh.exe,$(SHELL))
A review of each Makefile shows that the intention is that when the
condition is true, the execution environment is unix-like and when
false, it is dos-like.
Let's assume we're using the mingw too
Vim developers,
Build test #17 creates a scratch subdirectory "Xdir1" which it does not
delete at the end of the test script src/testdir/test17.in.
I'm running these tests using the Make_ming.mak makefile. In that file,
the command "-$(DEL) X*" is run after each test completes and it fails
Vim developers,
As of patch 942, the build-test "listchars" fails under Windows when
using the mingw compiler. Specifically, the command "diff test.out
test_listchars.ok" fails because test.out file is in unix format and
test_listchars.ok" is in DOS format.
As I see it, there are two ways t
Hello all.
A while back, the mingw Makefile was split into two: Make_ming.mak and
Make_cyg_ming.mak. The first of the two files has definitions for
CFLAGS and WINRES_FLAGS; Make_cyg_ming.mak is then included and those
two make variables are reinitialized (just below "end of choices"). In
e
While trying to build a 32-bit version of gvim using 64-bit mingw under
32-bit Windows XP, I've come across some problems with the Makefiles
(Make_ming.mak) that prevent a successful build. These problems are due
to my attempt to build a 32-bit app using a 64-bit capable compiler.
In this envi
57 matches
Mail list logo
