Was this issue ever resolved (I still observe it...)?
On Friday, February 7, 2020 at 11:18:58 PM UTC+1 ktakat...@gmail.com wrote:
> Hi Bram,
>
>
> 2020/2/8 Sat 7:03:24 UTC+9 Bram Moolenaar wrote:
>>
>>
>> Ken Takata wrote:
>>
>> > `:help :!` says:
>> >
>> > Vim redraws the screen a
Hi. I opened a new issue (#10324) but I don't seem to be able to set the
assignee.
On Saturday, April 30, 2022 at 12:22:13 AM UTC+2 Bram Moolenaar wrote:
>
> Axel Bender wrote:
>
> > > > Using gvim 8.2.4845 (Windows 7, 64-bit) with -U none -u none -n
> > > &
Hello Bram,
thx for looking into this.
a) yes it's gvim, and
b) no, the issue persists in 8.2.4847.
On Friday, April 29, 2022 at 7:21:22 PM UTC+2 Bram Moolenaar wrote:
>
> Axel Bender wrote:
>
> > Using gvim 8.2.4845 (Windows 7, 64-bit) with -U none -u none -n
> --noplu
Using gvim 8.2.4845 (Windows 7, 64-bit) with -U none -u none -n --noplugin,
the following mapping does no longer work (I found that issue only now, but
the issue is already in version 8.2.4815): inoremap °1 #34523.
In contrast, the following mapping: inoremap !1 #34523 works...
--
--
You rec
After recompiling gvim (8.2.4835) some minutes ago (Windows 7, MSys2,
64-bit) I found that all mappings based on Alt-Ctrl-F are no longer
functional. The said combinations work in 8.2.4815.
Instead of e.g. , is displayed in the command line on pressing
Alt-Ctrl-F8.
--
--
You received this m
Hm, sorry for this... After having a closer look at the file, I found that
the file got corrupted on disk. Removing it and doing a "git reset --hard"
solved the problem.
Sorry for the noise...
On Sunday, February 13, 2022 at 3:12:59 PM UTC+1 Axel Bender wrote:
> On compiling vim (
On compiling vim (Windows 7, 64 bit, gcc 11.2.0 using the vanilla
make_cyg_ming.mak) I run into the following error:
[image: 1098.png]
--
--
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
Thx for the explanation, Tony. Obviously I looked in the wrong place(s)...
On Monday, November 8, 2021 at 11:55:29 PM UTC+1 Tony Mechelynck wrote:
> On Mon, Nov 8, 2021 at 7:46 PM 'hebar...@googlemail.com' via vim_dev
> wrote:
> >
> > After adding a line with "o" (on an indented line with "autoi
Me don't.
Bisecting, I found that 851 broke a lot of my mappings. Please, fix this
regression ASAP!
--
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
Hi Ben,
thanks for looking into this!
After copying in syntax\2html.vim, and plugin\tohtml.vim the highlighed items
are now correctly tabbed.
--
--
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,
Using GVim 8.1. (Windows 10 64-bit), after applying a syntax scheme,
2html.vim fails to correcly expand the tabs contained in the base document.
Sample files:
- sample.lang# The source file
- lang.vim # The syntax file
- [sample.htm] # Resulting output file
--
--
You received this
@Bram
Although you qualified the problem as "tricky", I would like to push this issue
again.
Having lots of source code in directories whose path contains a "#", I'm not
able to open any of these files with --remote-silent (which I apply to use the
same gvim server for all my edits). Not using
Both commands behave identically. Sometimes they just stop working (no output
at all), at other times they create a Windows MiniDump (i.e. Werfault shows up).
This used to work with 292.
--
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the tex
@Tony
It crashes (WerFault comes up) (so it finishes not quite so silently ;-),
producing a Windows MiniDump file...
This used to work with 292.
--
--
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 informati
Probably correlated with this patch (did not bisect, but must have happened
between 292 and 296 inclusively), but the following command stopped to work for
me on Windows:
gvim.exe --servername GVX --remote-silent +"silent! bwipeout 1" ""
The command fails silently...
--
--
You received this
Compiling gVim 8.1 (latest) on Windows 7 64-bit with MinGW gcc 7.30 64-bit I
receive the following compiler warning in file userfunc.c:
gcc -c -Iproto -DWIN32 -DWINVER=0x0600 -D_WIN32_WINNT=0x0600 -DHAVE_PATHDEF
-DFEAT_BIG -DHAVE_STDINT_H -DMS_WIN64 -DHAVE_GETTEXT -DHAVE_LOCALE_H
-DDYNAMIC_GETT
Compiling gVim 8.1 (latest) on Windows 7 64-bit with MinGW gcc 7.30 64-bit I
receive the following compiler warning in file undo.c:
gcc -c -Iproto -DWIN32 -DWINVER=0x0600 -D_WIN32_WINNT=0x0600 -DHAVE_PATHDEF
-DFEAT_BIG -DHAVE_STDINT_H -DMS_WIN64 -DHAVE_GETTEXT -DHAVE_LOCALE_H
-DDYNAMIC_GETTEXT
Sorry, mate:
- As for the patch level: 8.1.5
- Compiler: gcc.exe (Rev2, Built by MSYS2 project) 7.3.0 => MinGW
- The below set of files compiles gvim w/o problems using the same compiler
- git diff shows (changed files):
=== a) Make_cyg_ming.mak ===
Since a few dozen patches (haven't been able to identify excactly the
responsible one) I receive the following linker error on vim (Windows 7 64-bit,
GNU-C 7.30):
objx86-64/os_win32.o:os_win32.c:(.text+0x1757): undefined reference to
`syn_id2cterm_bg'
objx86-64/os_win32.o:os_win32.c:(.text+0x18
I found the error: it turned out to be a setting in my .vimrc:
autocmd BufEnter * lcd %:p:h
which I use in place of autochdir (which doesn't work for me with
--remote-silent). So (besides I should have checked that beforehand) I will
have to find a workaround for this.
Sorry for the noise...
I use gvim as git's difftool, defined via .gitconfig as
gvim -d "LOCAL" "REMOTE"
>From time to time new local files are created or old local files are deleted.
>In the latter case (or when new remote files are introduced), git would call
>gvim like so:
gvim -d "nul" ""
which (independent of t
I'd like to push this issue as it's giving me some hard time to define my
syntax items appropiately.
As fas as I can see it, there's no way that GVim interprets NONE as
transparent, thus requiring the user to repeat syntax definitions where that
should not be necessary.
Would appreciate any co
Thanks, Yegappan!
This one looks even better, and I think, it should be pushed.
There are still some "differences" though (which are not due to your efforts):
a) In :clist the separator is ":" (hard-coded obviously), in :copen it's "|".
b) A user's qf.vim syntax file is ignored in terms of highl
@Christian
Thanks, Christian, that worked! Was not aware of that variable (and obviously
hadn't read the docs carefully enough...).
The above variable can be used in the appropriate syntax file (qf.vim);
however, it is not available in the QuickFixCmdPre/Post events.
--
--
You received this
@Yeggapan
Hm, this is sad, and prevents my from doing what I intended to do. Somehow I
need to get hold of the expression used to create the qf window...
--
--
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 i
@Yeggapan
Thank you for looking into this.
The patch partly solves the issue (please see attached image).
Now the colors from my qf.vim are used (probably because I used the same names
for the syntax items) but the syntax is still from the default qf.vim (or
built-in - please note the differen
Having
:autocmd QuickFixCmdPre helpgrep let g:grep_pat = getreg(":")
and running
:helpgrep BEGIN
g:grep_pat would always be empty. I would have thought that everything after
"helpgrep" is evaluated when the event triggers - in which case register ":"
should contain "helpgrep BEGIN".
--
--
@Tony
Thanks for your reply.
However, I use both, my own colorscheme, and my own syntax file for quickfix
(qf.vim).
However, as I tried to convey, when I use
- :copen, my colorscheme/syntax file combination is used, which is ok
- :clist, only my colorscheme - together with the hard-coded settin
Two "issues":
a) :cl uses hard-coded values for the various syntax items (cmp. the default
qf.vim - which btw. is not used (verify by renaming it)), and completely
ignores any user-defined qf.vim syntax file.
b) When using e.g. helpgrep to produce a quickfix list, the pattern searched
for is n
Window's vim.exe (running in the Windows Console) exhibits the following odd
behavior with "termguicolors" set: all color settings (only gui* defintions are
used) are honored except for "StatusLine"'s.
Given the following definition:
>>> highlight! StatusLine guifg=#66 guibg=#E0E0E0
Could anybody please look into 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 Goo
The following problem only exists on Windows 10, it cannot be reproduced in
Windows 7. Using the latest build of gvim (this doesn't seem to be a version
problem though), 64-bit, MinGW 7.1.0.
I added the following to the Registry to use Vim nearly everywhere (yes I'm an
aficionado ;-):
A "{" added after "foreach ..." in the following file will not get indented
correctly (no variables regarding to PHP indenting were modified):
-
$d_val)
{ << brace should be left-aligned with the beginning of "foreach"
foreach ...
{
xxx << the next line feed
Gvim compiled with DirectX=yes (64-bit, 8.0.1-426, Windows 7) doesn't display
character U+0095 correctly. Compiled with DirectX=no, there are no problems.
1) COPY r.txt to e.g. r.bat (an extension with syntax)
2) Open BOTH files as follows:
gvim r.*
The problem may be related to the render
@Christian, Bram
Thx for fixing 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 G
Will this get fixed?
--
--
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
No comments?
--
--
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" gr
Using the attached file (Windows 7, 64-bit, GCC 6.3.0, 8.0-1.324), and
scrolling to the right with the horizontal scrollbar, tabs are no longer
aligned.
I haven't done a bisect, but I think this is a relatively new problem (8.0-x).
--
--
You received this message from the "vim_dev" maillist.
Will this get fixed?
The prob is really annoying when you work with {C#|F#} etc...
--
--
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 thi
The following command (Windows 7, 64-bit, 8.0-1.318 with GCC 6.3.0):
G:\IT\Languages\C#> Z:\bin\vim\gvim.exe --remote-silent info.txt
gives me the following error:
E194: No alternate file name to substitute for '#'
and will not open the file.
Using the very same command from a directory whose
@Christian
Thanks for the answer; however I know why this happens technically (the DLL
just happens not to be in Explorer's PATH - but in cmd's) - I should have
detailed that beforehand... (sorry for that).
So FMPOV, the question should probably be refined as: "Why do we need
libwinpthread.dll
When compiling GVim (Win 7, 64-bit, GCC 6.3.0) with DIRECTX=yes
(make_cyg_ming.mak), starting it from Explorer gives me the attached error
message.
Compiling with DIRECTX=no correctly starts the application w/o errors.
--
--
You received this message from the "vim_dev" maillist.
Do not top-po
Using "rop=type:directx" gives me the following (01.png) distorted display (Win
7 64-bit, gcc 6.3.0) with the attached file (test.txt). Turning rop off (set
rop=) has the display return to normal...
--
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply b
Using the attached TXT file, and the keystrokes given below, gvim (8.0.1-225,
compiled with GNU 6.2.0 64-bit on Windows 7) crashes.
> gvim.exe -i NONE -u NONE --noplugin -U NONE x.txt
2whvtuy2j9j2wpuu
Can anyone else confirm this?
--
--
You received this message from the "vim_dev" maillist.
Hi Ken,
thanks for looking into this. Changing the order helps, but now KOI8-R texts
are displayed as Latin-1 (=> visual garbage). Obviously there's no general
solution to this...
I've resorted to defining some commands that will read/re-read a/the file with
a specified encoding set (via "++en
Hi Ken,
thanks for replying. As of your questions:
a) I can verify (procmon) that libicon-2.dll (64-bit) is loaded when
d:\gnu\mingw64 is in %PATH%.
b) has('iconv') prints "1" in that case.
When I remove d:\gnu\mingw64 from %PATH% (or change it to d:\gnu\mingw32),
has('iconv') shows "0", and
No ideas?
--
--
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
1) Using MSys2 on Windows 7, 64-bit, latest 64-bit build of gvim.exe.
2) .vimrc with "set fileencodings=ucs-bom,utf-8,koi8-r,latin1", and "setglobal
fileencoding=utf-8"
This is probably not a gvim problem, but a MSys/MinGW problem...
However,
A) When opening a Latin-1 file with %PATH% containi
@ Christian
Thanks for your reply. I know that the mode cannot be possibly guessed from the
positions used with setpos() (although some rough guesses could be made).
That's why I proposed to have an extra parameter to setpos() or visualmode()
(instead of calling e.g. execute "normal v\") some p
There's no direct connection. It was however the origin of my "troubles". The
main problem - meanwhile - is the behavior of setpos()/getpos(). When setting
"'<" and "'>" vim takes into consideration the last Visual mode, which is not
what I would have expected (and haven't found any documentatio
Thanks for your reply.
>From my point of view this a joint problem of getpos()/setpos() - unless the
>docs state it's not (I haven't found any info on that though; I found
>something (inofficial) here however:
>http://learnvimscriptthehardway.stevelosh.com/chapters/15.html).
Maybe there should
IS the conclusion I made in my previous post correct?
Can we generally NOT assume to start in CHARWISE Visual mode when entering
operator-pending mode?
If so, where would that be described in the docs?
--
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your rep
Addendum 2:
The problem also shows up when the setpos() is fed with the correct List (i.e.
four elements).
@Jürgen
It seems that this is the trigger, you're right. However, as I take it from the
docs, the mode - when entering operator-pending mode - should be charwise
Visual mode.
That said, t
Addendum:
Looking into the code, I found that a possible location for this to happen
might be list_find_nr() in list.c.
I have to add that, revising my use of setpos(), I called the function like
this: setpos("'<", [0, 532, 83]), i.e. I left out the "off" list member.
As this did not result in
A line like this (the parens are in the right position):
--- cut here ---
When you're trying to think about how to define a new operator- ()
movement, you can think of it like this:
--- cut here ---
The function was called in operator-pending mode via "cib" (replacement
function for the sta
Cannot confirm this. Please look at the two setpos() statements - both
returning 0 (green = successfull). The statements were given in a debug
session; no cursor movement in between. The desired positions were not set
(yellow and blue). The '< register is set to the first column, the '> register
The following image shows an erratical behavior of setpos() that I cannot
explain. When calling setpos("'<", ...), setpos("'>", ...) for that matter, the
behavior is OK for the first calls to setpos(). However, from a certain
number of calls (cannot specify), or triggered by some event (that I
The issue hasn't gone as of 7.2254 (Windows, 64-bit). The description of Dan
Church still holds for the part of the ":pwd" command, i.e. autochdir is not
effective here.
--
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replyin
I'm getting the following compilation error after recompiling gvim and vim
today (last "good" compilation was on 17.07. = 2060; environment unchanged
here):
gcc -c -Iproto -DWIN32 -DWINVER=0x0501 -D_WIN32_WINNT=0x0501 -DHAVE_PATHDEF
-DFEAT_BIG -DHAVE_STDINT_H -DMS_WIN64 -DHAVE_GETTEXT -
DHAVE_L
For my MinGW installation "gcc -dumpmachine" returns "x86_64-w64-mingw32"; the
build fails with:
Compiling gvim.exe...
mkdir -p gobjx86_64
gcc -c -Iproto -DWIN32 -DWINVER=0x0501 -D_WIN32_WINNT=0x0501 -DHAVE_PATHDEF
-DFEAT_BIG -DHAVE_STDINT_H -DHAVE_GETTEXT -DHAVE_LOCALE_H -DDYNAMIC_GETTEXT
-DFE
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 subscr
@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 top-pos
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
@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:
@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
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 rece
Opening a markdown file while having an own syntax file for HTML in another
directory (but accessible via ("runtime") gives me some errors.
This is due to using "runtime! syntax/html.vim" command in markdown.vim (line
15).
Changing this to "runtime! html.vim" fixes this.
--
--
You received th
Docs
"The global commands work by first scanning through the [range] lines and
marking each line where a match occurs (for a multi-line pattern, only the
start of the match matters).
In a second scan the [cmd] is executed for each marked line with its line
number prepended."
Fact
Andy Wo
With the following settings
:set isk=48-57,_,192-255
:set cabbrev _dts %substitute/\s\+$//e
using
:_dts
works.
After
:set isk-=_
using
:_dts
fails with "E492 - Not an editor command".
I stumbled upon this, when a syntax file (concrete: cobol.vim) reset isk, which
broke some of
Please refer to my post in vim_use. Should the docs be corrected?
--
--
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
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 subsc
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 subs
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
PYTHON3=d:/t
@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 you
@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 a
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 -march=x86-
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 -DDYN
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 -march=x86
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
"vim_d
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 b
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
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 -DFEA
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 -DF
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 -DFEAT
Compiling gvim (Windows 7, gcc (x86_64-win32-seh-rev0, Built by MinGW-W64
project) 4.8.4) the following warning appears in get_char.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 -D
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 be
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
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 http://
Using after "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://g
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 G
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 -
@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"
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) )
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 http://www.vim.org/maill
Another sample would be the attached file with (failure on "s"):
fbds
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 http://www.vim.org/
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 me
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|
2j
<.
Thanks for replying!
--
--
You received this message from the "vim_dev" maillist
Given the attached file, do the following:
:set ts=3 wrap showbreak=(cnt)
/Sombrav2eUn.
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
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 sub
Given the attached file, use
:set enc=utf-8
25|
2j
<<
to reproduce the 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 thi
1 - 100 din 168 matches
Mail list logo
