On Thursday, February 18, 2016 at 4:55:22 AM UTC+9, Bram Moolenaar wrote:
> There are still a few files for Win 16 GUI:
> src/gui_w16.c
> src/gui_w48.c (16 bit parts)
> src/guiw16rc.h
> src/Make_w16.mak
> src/proto/gui_w16.pro
>
> Vince Negri worked on this, but I haven't heard from him for five
On Monday, February 15, 2016 at 5:09:17 AM UTC+9, Bram Moolenaar wrote:
> Marcin Szamotulski wrote:
>
> > > > > > That's a really great feature. I am trying to implemented a gulp
> > > > > > plugin
> > > > > > (gulp is a node package used to build web apps) based on channels
> > > > > > and
>
On Wednesday, February 17, 2016 at 8:48:46 PM UTC+1, Bram Moolenaar wrote:
> Does anyone know how to avoid these warnings?
This should help:
https://gcc.gnu.org/wiki/VerboseDiagnostics#delete-non-virtual-dtor
PS: you also have this one:
gui_dwrite.cpp:348:13: warning: deleting object of
By compiling vim on Windows 7 with MinGW I get the following warnings:
[...]
pathdef.c:6:32: warning: unknown escape sequence: '\l' [enabled by default]
[...]
if_mzsch.c: In function 'startup_mzscheme':
if_mzsch.c:1104:2: warning: pointer targets in passing argument 1 of
Hi Bram,
2016/2/18 Thu 4:55:22 UTC+9 Bram Moolenaar wrote:
> There are still a few files for Win 16 GUI:
> src/gui_w16.c
> src/gui_w48.c (16 bit parts)
> src/guiw16rc.h
> src/Make_w16.mak
> src/proto/gui_w16.pro
>
> Vince Negri worked on this, but I haven't heard from him for five years.
>
>
Bram Moolenaar schrob am Mittwoch, 17. Februar 2016 um 20:55 Zeit:
> Does this even still build?
I could set up a VM to test if this is what its future depends on. Why
do we have a restriction to "Windows XP onwards" at all?
--
--
You received this message from the "vim_dev" maillist.
Do not
On Mi, 17 Feb 2016, Bram Moolenaar wrote:
> Thanks. I think we should also build a console version. Since testing
> appears to the take bulk of the time we can run the tests once with
> HUGE-console features. So perhaps we can build TINY-console with MSVC
> and HUGE-console with MingW and then
There are still a few files for Win 16 GUI:
src/gui_w16.c
src/gui_w48.c (16 bit parts)
src/guiw16rc.h
src/Make_w16.mak
src/proto/gui_w16.pro
Vince Negri worked on this, but I haven't heard from him for five years.
Does this even still build? I guess we can now remove it, since we only
really
Patch 7.4.1345
Problem:A few more compiler warnings. (Axel Bender)
Solution: Add type casts.
Files: src/gui_w32.c, src/gui_w48.c
*** ../vim-7.4.1344/src/gui_w32.c 2016-02-17 12:30:12.024840359 +0100
--- src/gui_w32.c 2016-02-17 20:45:36.413316682 +0100
***
***
Axel Bender wrote:
> Compiling gvim (Windows 7, gcc (x86_64-win32-seh-rev0, Built by MinGW-W64 p=
> roject) 4.8.4) the following warning appears in if_ole.cpp:
>
> gcc -Iproto -DWIN32 -DWINVER=3D0x0500 -D_WIN32_WINNT=3D0x0500 -DHAVE_PATHDE=
> F -DFEAT_BIG -DMS_WIN64 -DHAVE_GETTEXT
Ken Takata wrote:
> I wrote a patch for the documents:
>
> * Mention |dos-standard-mappings| in *v_CTRL-X*.
> v_CTRL-X can be used after 7.4.754 except on Windows. If we want to use
> this on Windows, we need ":vunmap ". (If someone want to use the same
> .vimrc on Windows and Unix,
I wrote:
> Yasuhiro Matsumoto wrote:
>
> > After Patch 7.4.1323, mingw vomit too many compilation warnings which is
> > hidden by -w flag. Below is a patch to remove them.
> >
> > https://gist.github.com/mattn/6542c52e98dce6923fc3
>
> Thanks. There are a few where I don't understand what
Christian Brabandt wrote:
> On Mi, 17 Feb 2016, Bram Moolenaar wrote:
>
> > Thanks. Not sure if it's all that useful to build all five feature
> > sets. huge + normal for GUI and console covers quite a bit already.
> >
> > It seems the reltime test is a bit flaky. Perhaps also caused by
On Wed, Feb 17, 2016 at 05:32:38PM +0900, Kazunobu Kuriyama wrote:
> Thank you for giving a try.
>
> The cursor issue you've just pointed out is rather expected results and I
> know the cause.
>
> That said, I can't put my hands on the cursor issue till the redraw issue
> is resolved.
>
> The
Updated patch attached which adds a missing autocmd feature check.
--
:wq
--
--
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
On Mi, 17 Feb 2016, Bram Moolenaar wrote:
> Thanks. Not sure if it's all that useful to build all five feature
> sets. huge + normal for GUI and console covers quite a bit already.
>
> It seems the reltime test is a bit flaky. Perhaps also caused by giving
> AppVeyor so much work.
Okay,
Forgot to add version info:
VIM - Vi IMproved 7.4 (2013 Aug 10, compiled Feb 16 2016 22:23:42)
MS-Windows 32-bit GUI version with OLE support
Included patches: 1-1342
Compiled by hp@HP-PC
Huge version with GUI. Features included (+) or not (-):
+acl+cmdline_compl +digraphs
Christian Brabandt wrote:
> Hi Bram!
>
> On Mo, 15 Feb 2016, Bram Moolenaar wrote:
>
> > This should not be part of the daily build but the one that's triggered
> > by a submit. Then we get a warning email five minutes later.
>
> That's what I meant.
>
> >
> > The one we currently have
Axel Bender wrote:
> Just a "cosmetical" change: make_cyg_ming.mak contains trailing spaces.
I'll remove them, but not send out a patch now. Will be included in any
next patch that touches this file.
--
GALAHAD turns back. We see from his POV the lovely ZOOT standing by him
smiling
Hi,
I get this error message on the latest build of gVim for Windows when trying to
open a root folder:
"C:\" Illegal file name
The command I use is simply:
:e C:
Anyone have an idea to fix this issue? I'm I the only one with this issue?
Thanks a lot!
Pascal
--
--
You received this
Hi,
2016/2/17 Wed 18:00:10 UTC+9 Ken Takata wrote:
> I don't think the following hunk should be applied:
>
> --- a/src/os_win32.c
> +++ b/src/os_win32.c
> @@ -5175,8 +5175,10 @@ mch_stop_job(job_T *job, char_u *how)
> return TerminateProcess(job->jv_proc_info.hProcess, 0) ? OK : FAIL;
Christian Brabandt wrote:
> Bram,
> this patch fixes a tiny build link problem, by adding some ifdefs
Thanks. I suppose a tiny GUI build is a bit unusual.
> Also I just noticed there is another problem with the windows builds:
>
Patch 7.4.1344
Problem:Can't compile Win32 GUI with tiny features.
Solution: Add #ifdef. (Christian Brabandt)
Files: src/gui_w32.c
*** ../vim-7.4.1343/src/gui_w32.c 2016-02-16 20:09:07.869342551 +0100
--- src/gui_w32.c 2016-02-17 12:27:42.262418050 +0100
***
Hi,
I wrote a patch for the documents:
* Mention |dos-standard-mappings| in *v_CTRL-X*.
v_CTRL-X can be used after 7.4.754 except on Windows. If we want to use
this on Windows, we need ":vunmap ". (If someone want to use the same
.vimrc on Windows and Unix, ":silent! vunmap " might be
> > However, since this builds MSVC and Mingw gvim and vim.exe for
> > FEATURES=tiny, small, normal, big and huge and runs the test it will
> > take a while to finish, probably around 50 Minutes.
> >
> > Feedback appreciated.
>
> I don't think the following hunk should be applied:
> MinGW is
Patch 7.4.1343
Problem:Can't compile with +job but without +channel. (Andrei Olsen)
Solution: Move get_job_options up and adjust #ifdef.
Files: src/eval.c
*** ../vim-7.4.1342/src/eval.c 2016-02-16 22:01:23.822490218 +0100
--- src/eval.c 2016-02-17 10:03:58.272325666 +0100
Andrei Olsen wrote;
> Console version fails to compile.
>
> eval.c:14539: undefined reference to `get_job_options'
>
> because it's defined inside #ifdef FEAT_CHANNEL
Thanks for reporting, I'll send out a fix.
--
Facepalm statement #8: "Drive faster, the petrol is running out"
/// Bram
Hi Christian,
2016/2/17 Wed 17:35:20 UTC+9 Christian Brabandt wrote:
> Hi Bram!
>
> On Mo, 15 Feb 2016, Bram Moolenaar wrote:
>
> > This should not be part of the daily build but the one that's triggered
> > by a submit. Then we get a warning email five minutes later.
>
> That's what I meant.
Hi Bram!
On Mo, 15 Feb 2016, Bram Moolenaar wrote:
> This should not be part of the daily build but the one that's triggered
> by a submit. Then we get a warning email five minutes later.
That's what I meant.
>
> The one we currently have only tests the GUI. We should at least have
> one
Thank you for giving a try.
The cursor issue you've just pointed out is rather expected results and I
know the cause.
That said, I can't put my hands on the cursor issue till the redraw issue
is resolved.
The Vim core draws text and cursor(s) simultaneously.
But that drawing model don't work
Compiling vim.exe (Windows 7, gcc (x86_64-win32-seh-rev0, Built by MinGW-W64
project) 4.8.4) with make -f Make_ming.mak vim.exe GUI=no fails, although PERL
is not defined in neither Make_ming.mak nor Make_cyg_ming.mak (gvim compiles):
gcc -c -Iproto -DWIN32 -DWINVER=0x0500 -D_WIN32_WINNT=0x0500
On Mon, Feb 15, 2016 at 05:05:39PM +0900, Kazunobu Kuriyama wrote:
> Thank you for the comment.
>
> To me, the cursor draw issue is another side of the redraw issue; one issue
> is tried to be fixed, another manifests then :)
>
> To fix those two issues simultaneously and make the code portable,
Compiling gvim (Windows 7, gcc (x86_64-win32-seh-rev0, Built by MinGW-W64
project) 4.8.4) the following warning appears in if_ole.cpp:
gcc -Iproto -DWIN32 -DWINVER=0x0500 -D_WIN32_WINNT=0x0500 -DHAVE_PATHDEF
-DFEAT_BIG -DMS_WIN64 -DHAVE_GETTEXT -DHAVE_LOCALE_H -DDYNAMIC_GETTEXT
-DFEAT_OLE
Compiling gvim (Windows 7, gcc (x86_64-win32-seh-rev0, Built by MinGW-W64
project) 4.8.4) the following warning appears in gui_w32.c:
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
34 matches
Mail list logo
