[BUG] re=1 and re=2 differ with branches

The following search command with branches works differently depending on which RE engine is chosen: ^\C[a-z]\+\ze \\(\.exe\)\@! With re=1 the whole first word is selected. With re=2 only the first letter of the first word is selected. Test case included. -- -- You received this message

Re: [BUG] re=1 and re=2 differ with branches

Addendum: There's an error in run; it should read '...+so re1.so ...' (rsp. re2.so) in there. Sorry. -- -- 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 ---

Re: [BUG] re=1 and re=2 differ with branches

Uploaded new case files... -- -- 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

[Regression after 7.4.03x] Selection is kept after copying over it

Please compare the following case using the current (7.4.35) and a previous (7.4ß = the last I can return to) version of gvim (here: Windows 7 64 bit). In the current version a selection - after being copied over with the contents of a register - is kept (no deselection). In the previous

[Suggestion] Allow gvim to start with no file name after --remote-silent

At the moment, when starting gvim --remote-silent gvim would display an error message, indicating that no file name was provided. This is quite a nasty behavior if you - like me - at times just start gvim (using a macro including --remote-silent) w/o a file name just to get gvim up and running

Re: [RFC] Script line numbers in error messages

I'd also like this same feature when it comes to debugging: e.g. function Rename..SNR1_DoArea..S_Rename..SNR1_AnalyzeLine line 17: ... is less easy to read than (e.g.) function Rename..SNR1_DoArea..S_Rename..SNR1_AnalyzeLine line 173 (AnalyzeLine 17): ... -- -- You received this

--remote-silent ignores -R (and possibly other switches) if the server is already up

gvim 7.4.052, compiled with MinGW64 on Windows7, 64bit With an instance of the gvim server up, the following command line will not work as expected: gvim -R --remote-silent file The command will open file, but it will not set the RO attribute accordingly. The same command line, w/o the server

Re: [Suggestion] Allow gvim to start with no file name after --remote-silent

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

Re: --remote-silent ignores -R (and possibly other switches) if the server is already up

According to the todo list, the issue was reported by YOU back in May 2012 :-) Seems I'm getting old then ;-) -- -- 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

Pattern matching broken with re=2 and ignorecase

With (re=2 and ignorecase), a class of Unicode characters will match incorrect characters where it doesn't match with (re=1), or with (re=2 and noignorecase). -- -- You received this message from the vim_dev maillist. Do not top-post! Type your reply below the text you are replying to. For

Re: Pattern matching broken with re=2 and ignorecase

@LCD 47 Well, that's a good question. However, the behavior should be consistent between the two RE engines and should not depend on a setting like ignorecase. @Bram Lazy, hmm. Wouldn't believe that given the speed you deliver updates ;-) The test file contains some normal text (with is),

Re: Pattern matching broken with re=2 and ignorecase

Hi Tony, What does 64 bit have to do with it? (IOW, why hence?) Nothing - I referred to the Windows 7 Console which usually has problems with UTF-8 and special characters (even when changing to CP 65000). Also, I suppose using filenames re1.so and re2.so rather than re1.vim and re2.vim

Re: [Suggestion] Allow gvim to start with no file name after --remote-silent

A simple solution might be the one attached below. Don't know however, if there are any side effects. Works for me. --- x\main.c2013-12-30 13:27:49.756908800 +0100 +++ main.c 2013-12-30 13:22:35.739224000 +0100 @@ -3892,13 +3892,13 @@ } /* - * Build a :edit command to send to a Vim

Re: [Suggestion] Allow gvim to start with no file name after --remote-silent

@Bram I often just open GVim (Windows 7, 64 bit) w/o any file name. As I always use the OLE version of GVim, and only want/need one incarnation of GVim - so I have to start GVim with '--remote-silent ', resulting in the above mentioned error message; omitting the '' ('--remote-silent')

virtcol() subject to showbreak

virtcol() fails to deliver the correct screen column if showbreak is set to a value other than and wrap is on, i.e. it doesn't take into account the length of the string that showbreak is set to. To reproduce: 1) Start a bare gvim with a text containing a long line. 2) :set nowrap 3) Position

Re: virtcol() subject to showbreak

I'd already be happy if virtcol() would take into account the length of the showbreak string. I'm otherwise prepared to work with UTF-8 characters... I consider this a flaw (well maybe a bug?) that should be fixed. -- -- You received this message from the vim_dev maillist. Do not top-post!

Re: virtcol() subject to showbreak

I cannot follow your argumentation. The docs say: The result is a Number, which is the screen column of the file position given with {expr}. That is, the last screen position occupied by the character at that position, *when the screen would be of unlimited width*. The last sentence clearly

Off-topic (or not) :sort

Does anyone know a UTF-8-aware (respecting $LC_ALL and/or $LANGUAGE) sort tool for Windows (GNUWin32's doesn't work), preferably a working GNU sort that does the job? [OFF-TOPIC] It would be a nice idea [NO LONGER OFF-TOPIC] to add the possibility to add sort columns (like in GNU's

Re: Off-topic (or not) :sort

@Ben Fritz As I see it, you can use a search pattern (r) for certain tasks, but it isn't a solution. Please, consider the following sample: 19500623 # ÖST # USA # Curitiba 19500621 # ÖST # MEX # Macapa 19500825 # AND # FRA # Curitiba 19500620 # MEX # BRA # Recife 19500625 # BEL # FRA # Curitiba

Suggestion: Highlight the search pattern in :g/.../# or :g/.../p

How about implementing a hightlighting of the pattern searched for in :g/.../ expressions? At times the resulting list is quite long and it is difficult to identify the pattern. Highlighting it would be of great benefit (at least for me...). -- -- You received this message from the vim_dev

Re: Suggestion: Highlight the search pattern in :g/.../# or :g/.../p

Thanks all! Based on your input my final version (taking into account vim's number setting): command! -nargs=? P :call PrintHighlighted(q-args) function! PrintHighlighted(arg) echo if a:arg == # || number let l:lnum = line(.) echohl LineNr echon . repeat( ,

[Req] Add an option to statically compile winpthread

When compiling gvim.exe libwinpthread is linked to dynamically. Please add an option to compile the library statically (or did I miss 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,

Re: Error using A with wrap on

Sorry, forgot to start with -i NONE -N -u NONE --noplugin -U NONE when I provided the sample. Using the above arguments, set columns=54 number wrap showbreak=(cnt) can be used to reproduce the problem (which also presents itself when using a with the cursor being in the last column) with the

Re: Error using A with wrap on

Hm, where was your cursor after A? Did you get a new line before entering a character? Here the cursor would be positioned in the second line (the one with the numbers), at column 5 in INSERT mode. Only after I enter a character I would get a new line... -- -- You received this message from

Re: Error using A with wrap on

Ok, I take that, but what about the incorrect offset in the second line? -- -- 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

Python error: E448 (Py_InitModule4) and E263

I'm using gvim 7.3 (64 bits, 1036) with dynamic python 2.7 support on Windows 7 (64 bits). Python 2.7 (64 bits) works from the command line. :py print hello gives me E448: Could not load library function Py_InitModule4 E263: Sorry, this command is disabled, ... Also, :ec has(python) returns

Re: Python error: E448 (Py_InitModule4) and E263

Hi Andrei, where would I put that directive? I tried various places (make_ming.mak:330:DEFINES ([not]replacing -DWIN32), gcc -DMS_WIN64), but I always end up with (:ve): ... -Iproto -DWIN32 ... Could anyone provide a working make_ming.mak? -- -- You received this message from the vim_dev

Re: Python error: E448 (Py_InitModule4) and E263

Forget my last post. I use to keep a backup file of make_ming.mak which is called make_ming.bak. It was this last file that I - stupidly - changed... I added -DMS_WIN64 in line 330 (DEFINES=), now python2 works. Thanks for the tip, Andrei! -- -- You received this message from the vim_dev

Latest changes to regexengine have made vim really slow

Comparing versions 7.3.1078 and 7.3.1090 (both compiled by myself) show a very slow behavior of the latest(?) version e.g. when paging through a file, independent of the regexpengine chosen. See attached sample. -- -- You received this message from the vim_dev maillist. Do not top-post! Type

Re: Latest changes to regexengine have made vim really slow

I could probably live with the slowing down if it only affected re=2. But it also affects re=1 which is not acceptable. The effect is quite noticeable, 13 to 20 secs that's a lot. I hope that Bram goes into that... -- -- You received this message from the vim_dev maillist. Do not top-post!

Re: Latest changes to regexengine have made vim really slow

Sorry Bram, I wasn't aware of this (... Note that you need to set 'regexpengine' before opening a file ...) - maybe this should go into the docs? Anyway, making the above mentioned setting in .vimrc brings back the 'good old times' ;-) Just for curiosity: 1) What ist NFA good for if it is so

Re: Latest changes to regexengine have made vim really slow

Thanks for the clarification, Bram. Chances that the NFA engine will take up speed? -- -- 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

Error when compiling 1129

When compiling 7.3.1129 (Windows 7 64 bit, MinGW), I get the following error message (7.3.1128 compiled with no errors): gcc -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

Re: Error when compiling 1129

Same with 1130... -- -- 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

Re: Error when compiling 1129

Ok after new pull with 1130. -- -- 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

File expansion error (E220) when expanding into directory whose name begins with '{'

When I try to expand into a directory whose name starts with '{', like in w d:\temp\{tab I receive error message E220. Although the error is described in the docs, it's quite nasty on Windows where having a directory name like the one described above isn't very common but also not uncommon for

Re: File expansion error (E220) when expanding into directory whose name begins with '{'

Addendum: If I use merely '/'s in the file name the error does not occur; however, if I press tab once, all '/'s get converted into '\'s, leaving me at the problem described above. -- -- You received this message from the vim_dev maillist. Do not top-post! Type your reply below the text you

Syntax broken with 1137

I noticed, that with 1137 (or lower?) my (own) vim.vim syntax file (maybe others too) is broken (right now I'm at 1156). Starting with re=0 or re=2 some items don't get highlighted any more, with re=1 everything's fine. -- -- You received this message from the vim_dev maillist. Do not

Re: Syntax broken with 1137

Hi Bram, the break is still evident in 1156; however, I was able to track the issue back to 1138 (backup version). Are you saying that this vim file is not highlighted properly? No, using my own vim.vim (the one I submitted) with re=1 as both, the syntax file and the source file, the

Re: Syntax broken with 1137

Ok with 1157. Thanks, Bram! -- -- 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

Highlighting broken with re=2

Being at 1163 the highlighting with re=2 is broken for the following use case (using the attached files): vi -U NONE -u NONE -i NONE --noplugin -N spanish.txt gg^ :set re=1 :so lang.vim 6j$a abcESCkok! gg^ :syn off :set re=2 :so lang.vim 6j$a abcESCkNOK! -- -- You received this

Re: Highlighting broken with re=2

Yes, a) I'm using gvim (this is due an alias: vi=gvim ;-), and b) I forgot one command; the correct sequence is as follows: gvim -U NONE -u NONE -i NONE --noplugin -N spanish.txt gg^ :set re=1 :so lang.vim 6j$a abcESCkok! u gg^ :syn off :set re=2 :so lang.vim 6j$a abcESCkNOK! You should

Re: Highlighting broken with re=2

Hi, Bram, you may as well elimitate the inverted question mark (I just forgot to replace it in the example - in the base document there are no xs), the result is the same. Also, the effect is independent from enc (I tested it with both, utf8 and latin1). In both cases fenc was empty. -- --

Re: Highlighting broken with re=2

Created a vid: http://youtu.be/z4DPiNVddjg -- -- 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

re=2 not matching

The following RE doesn't match with re=2 where it matches with re=1: ^\(.\)\(.*\)\n\1\@! Intention: Find all lines whose successor lines start with a different letter. -- -- You received this message from the vim_dev maillist. Do not top-post! Type your reply below the text you are replying

Re: re=2 not matching

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

[REQ] Provide a separate highlight occasion for the showbreak option

It would be helpful to be able to highlight the indicator for continuation lines (showbreak) differently from that of the EOT markers (~, @). While the first indicator usually profits from a good visibility, the latter preferably uses some dim colors. At the moment there exists only one

gp vs p

I'm wondering if the behavior of normal mode p is correct in respect to the cursor position? The docs state for gp: Just like p, but leave the cursor just after the new text. which suggests/implies that after p the cursor should stay in its current position (which - unfortunately - is not

Re: gp vs p

Hi Christian, thanks for the answer. It goes along with my perception. I consider this a bug which needs a fix. Also, at times it would come very handy to have p's functionality being different from gp's. -- You received this message from the vim_dev maillist. Do not top-post! Type your

mode() and VREPLACE

mode() (used in 'statusline') doesn't return Rv but R when entering Visual Replace Mode with gR. 'showmode' correctly displays VREPLACE. Using gvim 7.3.773 64-bit on Windows 7. -- You received this message from the vim_dev maillist. Do not top-post! Type your reply below the text you are

Re: mode() and VREPLACE

@Bram Thanks for the answer, and sorry for not having read the docs carefully 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

Re: New feature: absolute line number in relativenumber for the current line

I think the current line number (rnu) should be idented like the rest (even if LineNr should be identical to CursorLineNr). Right now it looks a little bit ragged on the left side. What speaks against right-aligning the current line number? -- -- You received this message from the vim_dev

gvim.exe doesn't compile with DIRECTX=yes

Compiling gvim.exe (64bit) on Windows 7 using gcc results in the following error - which doesn't show up with DIRECTX=no: 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

Re: gvim.exe doesn't compile with DIRECTX=yes

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

Re: Patch 7.4.479

Won't compile on Windows 7 (ming64): 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 -DFEAT_MBYTE_IME -DDYNAMIC_IME -DDYNAMIC_ICONV -pipe -w -march=x86-64

[QUESTION] noautochdir plus --remote-silent

Using autochdir in .vimrc together with the --remote-silent start option works fine: the first edited file's path is set correctly. However, the manuals suggest not to use autochdir: This option is provided for backward compatibility with the Vim released with Sun ONE Studio 4 Enterprise

Re: Regeression in RE (\%)somewhere after 7.4.560

Addendum: Typo: Gesamtausabe = Gesamtausgabe -- -- 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

Regeression in RE (\%)somewhere after 7.4.560

1) Open the attached file test.txt. 2) set ts=80 3) /\%80vGesamtausabe Contrary to the behavior in 560 (Windows 7, MinGW64), only the term Gesamtausgabe in the second line is marked. -- -- You received this message from the vim_dev maillist. Do not top-post! Type your reply below the text you

ga shows more information than b or B in statusline

Information on a combined character (insert e.g. hc-vu0300) is displayed correctly with ga (here: Hex 68 ..., ... Hex 0300); a statusline containing a b or B item however, only just shows the first character. Could that be changed? -- -- You received this message from the vim_dev maillist.

autochdir + encoding=utf8 messes up diff

Given the following .vimrc: --- set autochdir set encoding=utf-8 --- and the following directory/file structure: -- a\aa b\bb -- diffing aa and bb with -- gvim -d a\aa b\bb -- will not perform a diff. Instead message b\bb [NEW

Re: Spell correction ignores certain characters

I'd like to renew my request to solve this bug... -- -- 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

Re: Windows incorrect rendering of international characters

What's the status here? I (Win7 64-bit) still see rendering issues e.g. with Hebrew text. Put the following lines in a file an move the cursor over them: ירושלים של זהב ושל נחושת ושל אור הלא לכל שירייך אני כינור... -- -- You received this message from the vim_dev maillist. Do not

[CR] guibg=NONE is not transparent

The docs state: There are a few special names: ... NONE no color (transparent) however NONE is always interpreted as background, not as transparent. This prohibits us from using the current (the most interior) background (or foreground) colors of enclosing syntax items (see attached files;

Re: NFA regex engine bug

Unless this is a principal question, a solution working with re=2 is %s/\(^\d\+\)\(.*\)\n\1.*$/\1\2/ -- -- 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 ---

Re: Regression after ~ 7.4.75x

Hm, well this is strange. Can't reproduce it with 7.4.761. Thanks! -- -- You received this message from the vim_dev maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because

Regression after ~ 7.4.75x

The following used to work in my Perl syntax file since a long time (re=1 and re=2), but now (as of ~ 7.4.75x) gives me error E66 (\z( not allowed here) when I scroll over a text area containing matching text: syntax region perlHere start=\(\@!\z([a-zA-Z_]\+\).*;\)\@=$

Re: [BUG] Using to align lines containing Unicode characters

Hi Christian, I can confirm it's gone between 797 and 802. Thanks for testing! -- -- 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

Re: Issue 389 in vim: 'linebreak' breaks c% if the last visual selection was block

Will this get fixed, or did I miss something? Not ok here with 7.4.811. This is not a push, just a question :() -- -- 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

Re: Issue 389 in vim: 'linebreak' breaks c% if the last visual selection was block

Another sample would be the attached file with (failure on s): CTRL-vfbds Version here: 7.4.803 on Windows 7 (MinGW-64). -- -- 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

Re: [BUG] Using to align lines containing Unicode characters

Hi Christian, the text right of column 25 doesn't align with column 25 after multiple repetitions of (the .s). But oh, upps - I got sth wrong here :( The correct sequence is: :set enc=utf-8 25| CTRL-v 2j . Thanks for replying! -- -- You received this message from the vim_dev maillist.

Re: [BUG] Using to align lines containing Unicode characters

Can anyone confirm this with Windows 7 64-bit (MinGW)? -- -- 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

[BUG] Repeating U gets character count wrong with showbreak set

Given the attached file, do the following: :set ts=3 wrap showbreak=(cnt) /SombraCRv2eUn. Here (Windows 7 64-bit, MinGW), only the letters until ...NOC in the file's last line are converted to uppercase, urna. is not converted. -- -- You received this message from the vim_dev maillist. Do

Re: [bug] Syntax file for markdown uses semi-absolute path

@ZyX The layout of my files is as follows: Z:\bin\vim\syntax\html.vim Z:\bin\vim\syntax\markdown.vim Still, I get the following error message when editing a MD file: "readme.md" [unix] 136L, 5524C Error detected while processing z:\bin\vim\syntax\html.vim: line 209: E409: Unknown group name:

Re: [bug] Syntax file for markdown uses semi-absolute path

Thanks for the answer. I'll have to cope with 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

Re: [bug] Syntax file for markdown uses semi-absolute path

Attached a patch for the above problem, after the author hasn't reported back for a month. -- -- 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

Re: htmlcomplete#CompleteTags() incorrectly returns upper case completion

@Marius This is only about tag matching, no locales should be involved here. @ After the author hasn't reported back for three months now, could one of the above fixes be integrated? -- -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text

Re: [bug] Syntax file for markdown uses semi-absolute path

@Christian well, that's easy: I don't use it ;-) I usually don't amend sth. to existing syntax files, but I rewrite them completely, so "runtime!" probably doesn't work in this case (while "syntax include" would...). -- -- You received this message from the "vim_dev" maillist. Do not

Re: [bug] Syntax file for markdown uses semi-absolute path

Tracing the startup process, reading a MD file ("gvim -V readme.md") I noticed that two HTML files were sourced: my own one in %VIM\.vim\syntax, plus the original (unchanged) one in %VIM\syntax (rtp only contains the stems of these two paths). This is due to the "runtime!" (mind the exclamation

Matching group prevents match

Given the following two files, it seems that a "\(...\)" matching group prevents the pattern from matching: [man.txt] (please note that this is supposed to be a man page, so the special chars are really 0x8s! --- ( (M M- -T TA AB B) )

Re: Matching group prevents match

@ZyX In fact it should go to the bin. The pattern I provided [\(...\)] was deliberately incomplete for the sample [it was supposed to be [\(...\)\@<= in the end], so this was kind of misleading. The problem - and therefore thanks again! - was not using "\%" for the matching group having a "\1"

Compiling 1202 with OLE=yes 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_CHANNEL -DF EAT_GUI_W32 -DFEAT_CLIPBOARD -DFEAT_MBYTE -DFEAT_MBYTE_IME -DDYNAMIC_IME -DDYNAMIC_ICONV -pipe -w

Re: Compiling 1202 with OLE=yes fails

Addendum: Windows 7 64bit MinGW -- -- 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

Re: Compilation warning in getchar.c

@James No - I just didn't remember me having posted this specific error before... @Bram You're rigtht - sorry for the noise (btw. the warning keeps showing up in 5.3.0-win32-seh). -- -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you

Re: Compilation warning in os_win32.c

@Bram The error's gone after updating to MinGW 5.3.0-w32-seh. -- -- 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

Compilation warning in undo.c

Windows 7 64-bit, MinGw 64 >>>GUI<<< gcc -c -Iproto -DWIN32 -DWINVER=0x0501 -D_WIN32_WINNT=0x0501 -DHAVE_PATHDEF -DFEAT_BIG -DMS_WIN64 -DHAVE_GETTEXT -DHAVE_LOCALE_H -DDYNAMIC_GETTEXT -DFEAT_CSCOPE -DFEAT_CHANNEL -DFEAT_GUI_W32 -DFEAT_CLIPBOARD -DFEAT_MBYTE -DFEAT_MBYTE_IME -DDYNAMIC_IME

Compilation warning in getchar.c

Windows 7 64-bit, MinGw 64 >>>CONSOLE<<< gcc -c -Iproto -DWIN32 -DWINVER=0x0501 -D_WIN32_WINNT=0x0501 -DHAVE_PATHDEF -DFEAT_BIG -DMS_WIN64 -DHAVE_GETTEXT -DHAVE_LOCALE_H -DDYNAMIC_GETTEXT -DFEAT_CSCOPE -DFEAT_CHANNEL -DFEAT_MBYTE -DFEAT_MBYTE_IME -DDYNAMIC_IME -DDYNAMIC_ICONV -pipe

Compilation warning in os_win32.c

Windows 7 64-bit, MinGw 64 >>>CONSOLE<<< gcc -c -Iproto -DWIN32 -DWINVER=0x0501 -D_WIN32_WINNT=0x0501 -DHAVE_PATHDEF -DFEAT_BIG -DMS_WIN64 -DHAVE_GETTEXT -DHAVE_LOCALE_H -DDYNAMIC_GETTEXT -DFEAT_CSCOPE -DFEAT_CHANNEL -DFEAT_MBYTE -DFEAT_MBYTE_IME -DDYNAMIC_IME -DDYNAMIC_ICONV -pipe

[bug] Binding fails when setting the Perl path in make_ming.mak

Binding gvim.exe (Windows 7 64-bit, MinGW 64-bit) fails when setting the Perl path in make_ming.mak instead fo make_cyg_ming.mak. -- -- 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

[bug] Compiling vim.exe fails

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

make_cyg_ming.mak contains trailing spaces

Just a "cosmetical" change: make_cyg_ming.mak contains trailing spaces. -- -- 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

Warnings in undo.o

Compiling gvim (Windows 7, gcc (x86_64-win32-seh-rev0, Built by MinGW-W64 project) 4.8.4) the following warning appears in undo.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

Warnings in gui_w32.o

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

Warnings in if_ole.cpp

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 vim.exe fails

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

Setting autochdir AND encoding=utf-8 has gvim -d fail

Windows 7 64-bit, with MinGW 64 Being in z:\lib\vim, and d:\temp\.vimrc only containing: set autochdir set encoding=utf-8 gvim -d x86\make_cyg_ming.mak x64\make_cyg_ming.mak -u d:\temp\.vimrc (sample) fails, as gvim doesn't find the first file. The name of the first

Re: Setting autochdir AND encoding=utf-8 has gvim -d fail

Yup, at 1379 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

htmlcomplete#CompleteTags() incorrectly returns upper case completion

Using after "

Compiling with Python 3.5.1 on Windows

Windows 7 64-bit, MinGW 64, Python 3.5.1 in "d:\tools\python3" w/o Python 2 I don't get vim to work with Python 3.5.1 here. Python 2 is installed, but not enabled vim-wise. What am I doing wrong? Changes --- 1) src/make_cyg_ming.mak FEATURES=BIG PYTHON_VER=35 2) src/make_ming.mak

Re: Compiling with Python 3.5.1 on Windows

Oh man! *SCHÄHM* Thanks, and sorry for the noise... -- -- 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

Re: Compiling with Python 3.5.1 on Windows

Oh man! *SCHÄM* Thanks, and sorry for the noise... -- -- 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

  1   2   >