Re: Problem with patch 274
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. My OS is FreeBSD 7.1-RELEASE-p9. [...] You will find as attachment to this mail my syntax file and a php file to reproduce the bug. Just put syntax file in you ~/.vim/syntax directory, open the php file with vim with patch 274, go to line 24 on word ogoUnitTest and do cw and insert something. All is ok without patch 274, so i'm sure that the problem is in this patch. Best regards, Fred I haven't observed the behaviour you describe using the syntax file you attached, but I should note that the fold you at line 24 only has 63 lines, which I wouldn't call large. Perhaps this isn't the file you intended to attach. However, Vim indeed gets very slow if I use the default syntax file and set php_folding=1. This certainly is a consequence of applying the 274 patch, which itself IMHO does not seem to be wrong. The patch causes Vim to update folds in all the lines from the beginning of the modified area to the end of the fold in which the modification is being done. It will take a significant amount of time for large folds but this seems a must if the folds are to be updated correctly. I am afraid the whole problem is an example of what I complained about recently: the slowness of Vim when folding is syntax-based. Speaking of which, this does not seem to be an issue which can be easily solved (at least I am unable to come up with a simple solution): I've been trying to optimise the folding code using a profiler but the results are less than promising. Syntax HL can be slow. It works best when continously moving forward. When asking for the state before the last requested position it has to re-sync, which can be very slow. Does this happen for syntax folding? I haven't looked at the details, but if the problem is that folding is being updated while inserting text, we could postpone the updating until Insert mode is ended. The cursor line won't be folded anyway, and typing more text is likely to change folds again. Moving the cursor also is counted as leaving Insert mode, this is in stop_insert(). This won't be easy and there might be border cases where we do need to update folds. E.g., when inserting a line break. But I assume the speed gain is worth it. -- From know your smileys: :^[/ mean-smiley-with-cigarette /// Bram Moolenaar -- b...@moolenaar.net -- http://www.Moolenaar.net \\\ ///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\ \\\download, build and distribute -- http://www.A-A-P.org/// \\\help me help AIDS victims -- http://ICCF-Holland.org/// -- You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php
Re: promising items in the latest todo.txt
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 sweet if Bram could track and pull from repository where I would be maintaining all the runtime files that I maintain (177). Github makes this very easy and explicit. I’m not going to push choosing Git over Mercurial, but I really want to have a say in this and I want this stuff to be as simple as possible. The current set-up, where I basically check out a Git mirror of the Subversion repository, edit files, and then send them whole to Bram is not very engaging. You can send Bram a bundle of your changes, see 'bundle' command at: http://www.selenic.com/mercurial/hg.1.html#bundle For example using the command: hg bundle nikolai.hg http://vim.hg.sourceforge.net/hgweb/vim/vim The 'nikolai.hg' bundle file includes all the changesets not in Bram sourceforge repository. Assuming all your changes are in a branch, Bram may unbundle the 'nikolai.hg' file into his repository (or another working clone) and merge your branch into his code. Xavier -- You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php
Re: 2010 new features
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 from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php
Re: Scheme language: why is ? not in word definition
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 ident? won't.
Below is a patch to fix that.
*** ../vim72.323/src/normal.c Thu Dec 24 19:20:14 2009
--- src/normal.cTue Jan 5 16:19:38 2010
***
*** 5409,5414
--- 5409,5415
char_u*aux_ptr;
int isman;
int isman_s;
+ int tag_cmd = FALSE;
if (cap-cmdchar == 'g') /* g*, g#, g] and gCTRL-] */
{
***
*** 5515,5520
--- 5516,5522
break;
case ']':
+ tag_cmd = TRUE;
#ifdef FEAT_CSCOPE
if (p_cst)
STRCPY(buf, cstag );
***
*** 5526,5535
default:
if (curbuf-b_help)
STRCPY(buf, he! );
- else if (g_cmd)
- STRCPY(buf, tj );
else
! sprintf((char *)buf, %ldta , cap-count0);
}
/*
--- 5528,5541
default:
if (curbuf-b_help)
STRCPY(buf, he! );
else
! {
! tag_cmd = TRUE;
! if (g_cmd)
! STRCPY(buf, tj );
! else
! sprintf((char *)buf, %ldta , cap-count0);
! }
}
/*
***
*** 5562,5567
--- 5568,5575
aux_ptr = (char_u *)(p_magic ? /.*~[^$\\ : /^$\\);
else if (cmdchar == '#')
aux_ptr = (char_u *)(p_magic ? /?.*~[^$\\ : /?^$\\);
+ else if (tag_cmd)
+ aux_ptr = (char_u *)\\|\\n[;
else
/* Don't escape spaces and Tabs in a tag with a backslash */
aux_ptr = (char_u *)\\|\\n*?[;
--
You received this message from the vim_dev maillist.
For more information, visit http://www.vim.org/maillist.php
[patch] has(win64) returns 0 in 64-bit Vim
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 # end of choices ### + !if ($(CPU) == AMD64) || ($(CPU) == IA64) + CFLAGS=$(CFLAGS) -DWIN64 + !endif + !ifdef OS OS_TYPE = winnt DEL_TREE = rmdir /s /q -- Sergey Khorev http://sites.google.com/site/khorser Can anybody think of a good tagline I can steal? -- You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php
Re: 2010 new features
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 http://www.vim.org/scripts/script.php?script_id=687 regards, Christian I have already tried this dll. But I would like to set transparency only on buffer -- You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php
Re: [patch] has(win64) returns 0 in 64-bit Vim
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 2010 *** *** 314,319 --- 314,323 # end of choices ### + !if ($(CPU) == AMD64) || ($(CPU) == IA64) + CFLAGS=$(CFLAGS) -DWIN64 + !endif + !ifdef OS OS_TYPE = winnt DEL_TREE = rmdir /s /q -- Sergey Khorev http://sites.google.com/site/khorser Can anybody think of a good tagline I can steal? 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? I'm not sure what has(win64) should be returning based only on reading the help, but I'd imagine it should either be a) whether the vim binary itself is a 64 bit binary, or b) whether the OS that the binary is running on is a 64-bit version of windows. The latter seems more useful, but I'm not sure just from the help. If I'm right, though, it would have to be a runtime test; nothing at compile time could do the trick. ~Matt -- You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php
Re: [patch] has(win64) returns 0 in 64-bit Vim
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 out to source code we are targeting x64 or IA64. I'm not sure what has(win64) should be returning based only on reading the help, but I'd imagine it should either be a) whether the vim binary itself is a 64 bit binary, or b) whether the OS that the binary is running on is a 64-bit version of windows. The latter seems more useful, but I'm not sure just from the help. If I'm right, though, it would have to be a runtime test; nothing at compile time could do the trick. Source code clearly states it was meant as a compile-time check: #ifdef WIN64 win64, #endif Honestly, I'm not sure what's the point in knowledge what OS version we are running. -- Sergey Khorev http://sites.google.com/site/khorser Can anybody think of a good tagline I can steal? -- You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php
Re: [patch] has(win64) returns 0 in 64-bit Vim
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. -DWIN64 passed to compiler does nothing besides pointing out to source code we are targeting x64 or IA64. OK, then. I'm not sure what has(win64) should be returning based only on reading the help, but I'd imagine it should either be a) whether the vim binary itself is a 64 bit binary, or b) whether the OS that the binary is running on is a 64-bit version of windows. The latter seems more useful, but I'm not sure just from the help. If I'm right, though, it would have to be a runtime test; nothing at compile time could do the trick. Source code clearly states it was meant as a compile-time check: #ifdef WIN64 win64, #endif Honestly, I'm not sure what's the point in knowledge what OS version we are running. 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 argument either way. It should obviously be consistent with whatever win16 and win32 do, so if they're compile-time architecture checks, all is fine. ~Matt -- You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php
Re: [patch] has(win64) returns 0 in 64-bit Vim
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 argument either way. It should obviously be consistent with whatever win16 and win32 do, so if they're compile-time architecture checks, all is fine. I'm afraid you cannot load 64-bit DLL into 32-bit process even in x64 Windows. In fact, that was why I looked into has(win64) -- Sergey Khorev http://sites.google.com/site/khorser Can anybody think of a good tagline I can steal? -- You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php
Re: [patch] has(win64) returns 0 in 64-bit Vim
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 :) What about changing all occurrences of _WIN64 to WIN64 and defining WIN64 in makefile? On second thought, I don't like either ways. It seems more consistent to change the single occurrence of WIN64 in eval.c to _WIN64. Anyway, 64-bit binary returns 1 for has(win32) so we don't have to make WIN64 to behave like another WIN32. -- Sergey Khorev http://sites.google.com/site/khorser Can anybody think of a good tagline I can steal? -- You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php
Re: conf check in ftplugin.vim slightly broken (?)
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 recognized as the conf filetype (or any other filetype for that matter) and even when i force the conf filetype on by adding # comment to the first line of the file, the C-style comments don't get any syntax hilighting. The filetype detection seems to be around line 2405 (or possibly 2445) in the filetype.vim runtime file, it seems to be looking for a # on any one of the first 5 lines of the file. Perhaps some additional detection for C-style comments as well there? Also somewhere in probably the filetype plugin or possibly the filetype syntax file, it'd be nice if support for C-style comments in config files was there too. The usual conf files don't have C-style comments. What file are you talking about? -- hundred-and-one symptoms of being an internet addict: 86. E-mail Deficiency Depression (EDD) forces you to e-mail yourself. /// Bram Moolenaar -- b...@moolenaar.net --http://www.Moolenaar.net \\\ ///sponsor Vim, vote for features --http://www.Vim.org/sponsor/\\\ \\\download, build and distribute --http://www.A-A-P.org /// \\\help me help AIDS victims --http://ICCF-Holland.org /// Here's a link to the one the was failing (on the project's hgweb for laziness): http://hg.atheme.org/atheme/atheme/file/c110172a3601/dist/atheme.conf.example Here's an example of a .conf from a different project (still IRC related...hmm...) that uses C-style comments from their cvsweb: http://cvsweb.unrealircd.com/cgi-bin/cvsweb/~checkout~/unreal/doc/example.conf?rev=1.1.1.1.6.1.2.53.2.15;content-type=text%2Fplain Those are not using the conf filetype. These need a different syntax file. Perhaps there is an existing one that is close (there are so many). Do not confuse the filetype name with the file name extension. xxx.conf doesn't mean it's a conf filetype. -- From know your smileys: ;-0Can't find shift key ,-9Kann Umschalttaste nicht finden /// Bram Moolenaar -- b...@moolenaar.net -- http://www.Moolenaar.net \\\ ///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\ \\\download, build and distribute -- http://www.A-A-P.org/// \\\help me help AIDS victims -- http://ICCF-Holland.org/// -- You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php
:compiler command doesn't work in function
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 the following:
- Delete the current_compiler and b:current_compiler variables.
...
But current_compiler variable is not deleted and compiler plugin do
nothing by the following check:
if exists(current_compiler)
finish
endif
let current_compiler = foo
The following patch fixes this problem.
Index: ex_cmds2.c
===
--- ex_cmds2.c (revision 1711)
+++ ex_cmds2.c (working copy)
@@ -2497,13 +2497,13 @@
* used. A user's compiler plugin may set it, the distributed
* plugin will then skip the settings. Afterwards set
* b:current_compiler and restore current_compiler. */
- old_cur_comp = get_var_value((char_u *)current_compiler);
+ old_cur_comp = get_var_value((char_u *)g:current_compiler);
if (old_cur_comp != NULL)
old_cur_comp = vim_strsave(old_cur_comp);
do_cmdline_cmd((char_u *)
command -nargs=* CompilerSet setlocal args);
}
- do_unlet((char_u *)current_compiler, TRUE);
+ do_unlet((char_u *)g:current_compiler, TRUE);
do_unlet((char_u *)b:current_compiler, TRUE);
sprintf((char *)buf, compiler/%s.vim, eap-arg);
@@ -2514,7 +2514,7 @@
do_cmdline_cmd((char_u *):delcommand CompilerSet);
/* Set b:current_compiler from current_compiler. */
- p = get_var_value((char_u *)current_compiler);
+ p = get_var_value((char_u *)g:current_compiler);
if (p != NULL)
set_internal_string_var((char_u *)b:current_compiler, p);
@@ -2523,12 +2523,12 @@
{
if (old_cur_comp != NULL)
{
- set_internal_string_var((char_u *)current_compiler,
+ set_internal_string_var((char_u *)g:current_compiler,
old_cur_comp);
vim_free(old_cur_comp);
}
else
- do_unlet((char_u *)current_compiler, TRUE);
+ do_unlet((char_u *)g:current_compiler, TRUE);
}
}
}
--
Yukihiro Nakadaira - yukihiro.nakada...@gmail.com
--
You received this message from the vim_dev maillist.
For more information, visit http://www.vim.org/maillist.php
