Lech Lorens wrote:
On 30-Dec-2009 Frederic Hardy frederic.ha...@mageekbox.net wrote:
Hello !
I have a problem with patch 274 about syntax highlighting.
If i'm apply this patch, syntax highlighting become very very very slow
when i'm modifying text in the start of a large fold.
On Mon, Jan 4, 2010 at 9:16 PM, Nikolai Weibull wrote:
SourceForge does provide Mercurial repositories. code.google.com only
allows a small set of open source licenses, and Vim's isn't among them.
Do either support tracking branches and similar stuff in a simple way?
I mean, it would be
Hi epanda!
On Mo, 04 Jan 2010, epanda wrote:
Gvim more on Windows OS
[…]
4. Just for Effect, implements transparency on buffer we are editing
in order to let user see document below GVim
http://www.vim.org/scripts/script.php?script_id=687
regards,
Christian
--
You received this message
Hi,
It does that for C-], too, but as you say, it seems to do the right
thing for *. I don't know why. Maybe a bug?
Yes, for some reason Vim always escapes some special characters even
if we are not going to pass them to a shell or regexp-using command.
So :tag ident? will work but ^] on
Hi,
has(win64) returns 0 even for x64 version of Vim. It seems we need
to define WIN64 for this to work. Something like that:
*** ../vim72.323/src/Make_mvc.mak Wed Dec 23 09:36:54 2009
--- src/Make_mvc.makTue Jan 5 16:46:26 2010
***
*** 314,319
--- 314,323
#
On 5 jan, 14:21, Christian Brabandt cbli...@256bit.org wrote:
Hi epanda!
On Mo, 04 Jan 2010, epanda wrote:
Gvim more on Windows OS
[…]
4. Just for Effect, implements transparency on buffer we are editing
in order to let user see document below GVim
On Tue, Jan 5, 2010 at 8:52 AM, Sergey Khorev wrote:
Hi,
has(win64) returns 0 even for x64 version of Vim. It seems we need
to define WIN64 for this to work. Something like that:
*** ../vim72.323/src/Make_mvc.mak Wed Dec 23 09:36:54 2009
--- src/Make_mvc.mak Tue Jan 5 16:46:26
Well,
Isn't that only checking the type of CPU that the vim binary was built
with, instead of whether it was built as an x64 binary? Or does
defining WIN64 cause an x64 binary to be built instead?
CPU in makefile defines target CPU.
-DWIN64 passed to compiler does nothing besides pointing
On Tue, Jan 5, 2010 at 2:17 PM, Sergey Khorev wrote:
Well,
Isn't that only checking the type of CPU that the vim binary was built
with, instead of whether it was built as an x64 binary? Or does
defining WIN64 cause an x64 binary to be built instead?
CPU in makefile defines target CPU.
Matt,
I can conceive of a plugin that dynamically loads a DLL - or another
program - that requires a 64-bit windows, which would need to know
that the host OS supports it. In this case, you'd want to know that
the OS is 64 bit, even if the vim binary is 32-bit. But as I said, I
can see the
Hi,
In many places in the code _WIN64 is checked for, but the list for has()
uses WIN64.
Perhaps we should change them all to WIN64 to be consistent with WIN32,
and then define WIN64 in vim.h when _WIN64 is defined.
That will be inconsistent with WIN32 because it is defined in Makefile :)
JD wrote:
On Jan 4, 4:10 pm, Bram Moolenaar b...@moolenaar.net wrote:
JD wrote:
I was having some fun earlier today, going through some .conf files in
Vim and i noticed that conf file that are bind-style (conf filetype in
vim) that use C-style comments like: /* comment */ are not
Steps to reproduce:
function F()
compiler ant
compiler bcc
Now, 'makeprg' is ant
echo makeprg
endfunction
:help current_compiler says:
To support older Vim versions, the plugins always use current_compiler and
not b:current_compiler. What the command actually does is
13 matches
Mail list logo
