omnicpp very slow under windows XP
Hi, I have done two tests and I have two bugreports.txt but I don't know how to search the difference which make that omnicpp is very slow under windows and fast under virtual Linux CentOS. configuration Windows XP or Linux CentOS : > the same project (same cpp same headers) > same vimfiles > same _vimrc .vimrc > more than that, I used the same database tags the copy of the one made under > windows into linux linux : 0.25 after the CTRL+X CTRL+O windows : > 1 or 2 min after the CTRL+X CTRL+O I don't how to attach my two bugreports, if somoene can help it will be nice. Thanks Best Regards Epanda --~--~-~--~~~---~--~~ You received this message from the "vim_dev" maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: RFC: Gatekeeper - control which plugins are loaded
Hello,
Meikel Brandmeyer <[EMAIL PROTECTED]> wrote:
> > Which doesn't help us, script maintainers to reload a plugin.
> > Well, to be honest, it not really a problem as we can always comment
> > the finish line (as long as we don't forget to restore it later).
> > However, now my plugins checks a exists("g:force_reload_{plugin}") in
> > the first test.
> I disagree. Obviously instead of modifying your plugin*s*, you would
> just have to add the force flag to the central Guard function and *all*
> your scripts support your flag immediately.
Well, if gatekeeper could also propose a way to force reloading (multiple times)
a plugin, that would be nice.
> > Moreover, all my headers are generated with a template-files expander
> > that provides the adequate anti-reinclusion guards for plugins (1
> > global guard), ftplugins (1 global + 1 local guards), local_vimrcs
> > (1local + 1 global), or whatever other vim script (0 guard).
> This sound like a very special setup. It is hard (if not futile) to try
> to cover all cases. What's of course possible, is to replace the central
> Guard function. So there also some flexibility into this direction.
> This is limited by the public API of course...
It is not that special at all. ftplugins are very close to plugins except that:
- they require a local guard
- sometimes they can need a global guard, for global definitions which can be
moved to autoload plugins now.
> > What is hidden in this last sentence, is that gatekeeper does not
> > help with ftplugins. When the ftplugin is just one file, blocking it
> > is easy. When it is a suite made of many plugins, and ftplugins,
> > blocking it with one assignment in the .vimrc becomes a much more
> > complex task, and the call cannot even be used as an anti-reinclusion
> > guard (see for instance LaTeX-Suite (or my C&C++ suite, which I don't
> > distributed in any distribution before a very long time)).
> Hmm.. This is another point, which needs some thought. I didn't think
> about multi-file scripts.
BTW, did you read David "2 cents" about storing the version of a plugin in its
anti-reinclusion guard ?
This is a good practice that, I think, should indeed be generalized -- and I
have a lot of work to do on this one. This is something the Guard function from
Gatekeeper should take into account (may be with an optional parameter receiving
the current version of the script?) At terms, it could help to implement
dependency checks when a particular version of another script is required.
--
Luc Hermitte
http://lh-vim.googlecode.com/
http://hermitte.free.fr/vim/
--~--~-~--~~~---~--~~
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---
Re: RFC: Gatekeeper - control which plugins are loaded
Hello, > Actually, I like Debian's approach (thanks Debian Vim Maintainers and [...] > make it think it is already loaded). Here are some comments about this way of doing things... * I read the word "symlink" several times. This most likely disqualifies this solution for Windows. * It most likely also doesn't work well with heterogeneous environments where Linux (Debian in this case) lives together with other systems like HPUX, where the file system layout is probably different. If the installation directory of vim is in a different place, then the symlinks won't work well. * One needs Ruby. (IIRC it is a Ruby script) The first two issues could be solved by copying the files. So my main concern with this solution is: it is probably not portable without serious drawbacks (copying is a serious drawback) and it needs an extra non-trivial prerequisite. My requirements for a solution to this problem are ... * It needs only vim. * It works where vim works. * It is easy to use (especially for the user). As was said before: the environment is like it is. There is the way vim works and there is the way the plugins are written. Given that you probably cannot easily change either one, the Debian way is a feasible solution. But I doubt, that it's universally applicable. I thank for all the rich feedback (also in the other mails of this thread). However there were no real no-go arguments, besides that the scripts have to be cooperative for the full support. With loadplugins option one can possibly also take care of not so cooperative plugins, although the possible control is restricted to the choice of loading or not loading. Supporting reloads is then probably not easily possible. So in general the idea seems to be feasible. Although there are certainly areas, where more investigations are due, eg. multi-file plugins. > More kudos to the Debian Vim Maintainers: They seem to do a good job. Chapeau. :) Sincerely Meikel -- |\ _,,,---,,_ /,`.-'`'-. ;-;;,_ |,4- ) )-,_..;\ ( `'-' '---(_/--' `-'\_) fL http://ec.kotka.de --~--~-~--~~~---~--~~ You received this message from the "vim_dev" maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
[PATCH] lscscope command (2nd attempt)
Hello,
This is attempt #2 at getting this feature/patch into vim. It was
originally submitted almost one year back. There was some feedback
from Gary Johnson and Yegappan Lakshmanan and I reworked the patch
based on that; and then the discussion petered out. The original
thread can be found here:
http://tech.groups.yahoo.com/group/vimdev/message/46634
The proposed patch is attached to this mail. I believe it addresses
all the issues that were raised the last time. Feedback is welcome.
I have been using it for the last year without any problems at all
and would like to see it integrated into the official vim.
Recap: This patch implements a new ex mode command "lscscope",
which is the same as scscope but uses the location list instead of
the quickfix list.
Regards,
Navdeep
Be a better friend, newshound, and
know-it-all with Yahoo! Mobile. Try it now.
http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ
--~--~-~--~~~---~--~~
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---
Index: runtime/doc/if_cscop.txt
===
--- runtime/doc/if_cscop.txt (revision 997)
+++ runtime/doc/if_cscop.txt (working copy)
@@ -213,6 +213,11 @@
'cscopequickfix' option is set, the location list for the current window is
used instead of the quickfix list to show the cscope results.
+ *:lscscope* *:lsc*
+This command is same as the ":scscope" command, except when the
+'cscopequickfix' option is set, the location list for the current window is
+used instead of the quickfix list to show the cscope results.
+
*:cstag* *E257* *E562*
If you use cscope as well as ctags, |:cstag| allows you to search one or
the other before making a jump. For example, you can choose to first
Index: runtime/doc/index.txt
===
--- runtime/doc/index.txt (revision 997)
+++ runtime/doc/index.txt (working copy)
@@ -1280,6 +1280,7 @@
|:lpfile| :lpf[ile] go to last location in previous file
|:lrewind| :lr[ewind] go to the specified location, default first one
|:ls| :ls list all buffers
+|:lscscope| :lsc[scope] like ":scscope" but uses location list
|:ltag| :lt[ag] jump to tag and add matching tags to the
location list
|:lunmap| :lu[nmap] like ":unmap!" but includes Lang-Arg mode
Index: src/ex_cmds.h
===
--- src/ex_cmds.h (revision 997)
+++ src/ex_cmds.h (working copy)
@@ -581,6 +581,8 @@
RANGE|NOTADR|COUNT|TRLBAR),
EX(CMD_ls, "ls", buflist_list,
BANG|TRLBAR|CMDWIN),
+EX(CMD_lscscope, "lscscope", do_scscope,
+ EXTRA|NOTRLCOM|SBOXOK),
EX(CMD_move, "move", ex_copymove,
RANGE|WHOLEFOLD|EXTRA|TRLBAR|CMDWIN|MODIFY),
EX(CMD_mark, "mark", ex_mark,
Index: src/if_cscope.c
===
--- src/if_cscope.c (revision 997)
+++ src/if_cscope.c (working copy)
@@ -971,7 +971,7 @@
}
return cs_find_common(opt, pat, eap->forceit, TRUE,
- eap->cmdidx == CMD_lcscope);
+ eap->cmdidx == CMD_lcscope || eap->cmdidx == CMD_lscscope);
} /* cs_find */
@@ -1113,23 +1113,23 @@
{
cs_file_results(f, nummatches);
fclose(f);
+# ifdef FEAT_WINDOWS
+ if (postponed_split != 0)
+ {
+ win_split(postponed_split > 0 ? postponed_split : 0,
+ postponed_split_flags);
+# ifdef FEAT_SCROLLBIND
+ curwin->w_p_scb = FALSE;
+# endif
+ postponed_split = 0;
+ }
+# endif
if (use_ll) /* Use location list */
wp = curwin;
/* '-' starts a new error list */
if (qf_init(wp, tmp, (char_u *)"%f%*\\t%l%*\\t%m",
*qfpos == '-') > 0)
{
-# ifdef FEAT_WINDOWS
- if (postponed_split != 0)
- {
- win_split(postponed_split > 0 ? postponed_split : 0,
- postponed_split_flags);
-# ifdef FEAT_SCROLLBIND
- curwin->w_p_scb = FALSE;
-# endif
- postponed_split = 0;
- }
-# endif
if (use_ll)
/*
* In the location list window, use the displayed location
Re: Nested 'first line only' comments fail
On Apr 23, 1:23 pm, "A.Politz" <[EMAIL PROTECTED]> wrote: > Gary Johnson wrote: > > On 2008-04-23, fritzophrenic <[EMAIL PROTECTED]> wrote: > > >>On Apr 17, 1:12 pm, fritzophrenic <[EMAIL PROTECTED]> wrote: > > >>>See the vim_use > >>>thread:http://groups.google.com/group/vim_use/browse_thread/thread/863a0ce08... > > >>>It seems that a nested first line only comment will incorrectly > >>>prepend the comment leader on the next line if it occurs in the middle > >>>of a multiline comment or in a single-line comment. > > > [...] > > >>Any comments on this? I'm pretty sure it is a bug, but if it isn't, > >>I'd certainly like to know why! > > > As I said in the vim_use thread, from my experiments at the time I > > think it's a bug, but I haven't looked at it further and I would > > like someone else's take on it. > > Maybe this is the defined behaviour, but only the help is not very clear > about it? > > " n Nested comment. Nesting with mixed parts is allowed. If > 'comments' > is "n:),n:>" a line starting with "> ) >" is a comment." > > -ap Right, so the above creates a single-line comment from two single-line comment headers. The observed behavior makes sense for single-line comments, but I still fail to see why the behavior occurs in multi- line comments, especially because it depends on which line of the multi-line comment you enter text on. --~--~-~--~~~---~--~~ You received this message from the "vim_dev" maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: Nested 'first line only' comments fail
Gary Johnson wrote: > On 2008-04-23, fritzophrenic <[EMAIL PROTECTED]> wrote: > >>On Apr 17, 1:12 pm, fritzophrenic <[EMAIL PROTECTED]> wrote: >> >>>See the vim_use >>>thread:http://groups.google.com/group/vim_use/browse_thread/thread/863a0ce08... >>> >>>It seems that a nested first line only comment will incorrectly >>>prepend the comment leader on the next line if it occurs in the middle >>>of a multiline comment or in a single-line comment. > > > [...] > > >>Any comments on this? I'm pretty sure it is a bug, but if it isn't, >>I'd certainly like to know why! > > > As I said in the vim_use thread, from my experiments at the time I > think it's a bug, but I haven't looked at it further and I would > like someone else's take on it. > Maybe this is the defined behaviour, but only the help is not very clear about it? " nNested comment. Nesting with mixed parts is allowed. If 'comments' is "n:),n:>" a line starting with "> ) >" is a comment." -ap --~--~-~--~~~---~--~~ You received this message from the "vim_dev" maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: Nested 'first line only' comments fail
On Apr 23, 11:00 am, Tony Mechelynck <[EMAIL PROTECTED]> wrote: > On 23/04/08 17:40, fritzophrenic wrote: > > > > > > > On Apr 17, 1:12 pm, fritzophrenic<[EMAIL PROTECTED]> wrote: > >> See the vim_use > >> thread:http://groups.google.com/group/vim_use/browse_thread/thread/863a0ce08... > > >> It seems that a nested first line only comment will incorrectly > >> prepend the comment leader on the next line if it occurs in the middle > >> of a multiline comment or in a single-line comment. > > >> For example, in a new buffer: > > >> :set tw=20 comments=ns1:/*,nmb:*,nex:*/,nfb:NOTES: fo=tcqr cindent > > >> Type: > > >> /* NOTES: mary had a little lamb */ > > >> The comments wrap exactly as expected, i.e. > > >> /* NOTES: mary had a > >> * little > >> * lamb */ > > >> Now type: > > >> /*NOTES: Mary had a little lamb */ > > >> This gives: > > >> /* > >> * NOTES: Mary had a > >> * NOTES: little > >> * NOTES: lamb */ > > >> The same thing happens if you go into a pre-existing multiline comment > >> and start typing. If the first-line-only comment is inserted on the > >> first line of the multiline comment, it is fine. Otherwise, it fails. > > >> In addition: > > >> :set comments+=n:// > > >> Type: > > >> // NOTES: mary had a little lamb > > >> to get: > > >> // NOTES: Mary had a > >> // NOTES: little > >> // NOTES: lamb > > >> I'm using gvim 7.1.293, 'Big' compile on MS Windows (I got it off the > >> 'cream' sourceforge page). > > > Any comments on this? I'm pretty sure it is a bug, but if it isn't, > > I'd certainly like to know why! > > /* > * This is a three-piece comment > * with start, middle and end: > * a single comment starts at > * slash-star and ends at star-slash > */ > > // This is a set of successive > // single-line comments: > // each double slash > // starts a new comment, > // which ends at the end of the line. > > NOTE: This kind of comment > can be nested within > the above two kinds. > But nesting does not > overlap. > > By "overlapping", I mean like brackets or HTML tags: ([]) is valid but > ([)] isn't. > So, I think I understand the behavior for single-line (//) comments now. // starts a comment NOTES: starts a nested comment end of line ends the outer comment, therefore ending the contained comment started with NOTES: But I'm still puzzled about the multi-line comment. From what I see: /* starts the comment */ ends the comment putting NOTES: anywhere between the two should allow it to continue as normal until the end of the containing comment (*/) is encountered. Do I misunderstand something? Also, why the inconsistent behavior between NOTES: on the first line and NOTES: on in-between lines of the multi-line comment? --~--~-~--~~~---~--~~ You received this message from the "vim_dev" maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: Nested 'first line only' comments fail
On 2008-04-23, fritzophrenic <[EMAIL PROTECTED]> wrote: > On Apr 17, 1:12 pm, fritzophrenic <[EMAIL PROTECTED]> wrote: > > See the vim_use > > thread:http://groups.google.com/group/vim_use/browse_thread/thread/863a0ce08... > > > > It seems that a nested first line only comment will incorrectly > > prepend the comment leader on the next line if it occurs in the middle > > of a multiline comment or in a single-line comment. [...] > Any comments on this? I'm pretty sure it is a bug, but if it isn't, > I'd certainly like to know why! As I said in the vim_use thread, from my experiments at the time I think it's a bug, but I haven't looked at it further and I would like someone else's take on it. Regards, Gary --~--~-~--~~~---~--~~ You received this message from the "vim_dev" maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: Nested 'first line only' comments fail
On 23/04/08 18:00, Tony Mechelynck wrote: > On 23/04/08 17:40, fritzophrenic wrote: >> >> On Apr 17, 1:12 pm, fritzophrenic<[EMAIL PROTECTED]> wrote: >>> See the vim_use >>> thread:http://groups.google.com/group/vim_use/browse_thread/thread/863a0ce08... >>> >>> It seems that a nested first line only comment will incorrectly >>> prepend the comment leader on the next line if it occurs in the middle >>> of a multiline comment or in a single-line comment. >>> >>> For example, in a new buffer: >>> >>> :set tw=20 comments=ns1:/*,nmb:*,nex:*/,nfb:NOTES: fo=tcqr cindent >>> >>> Type: >>> >>> /* NOTES: mary had a little lamb */ >>> >>> The comments wrap exactly as expected, i.e. >>> >>> /* NOTES: mary had a >>>*little >>>*lamb */ >>> >>> Now type: >>> >>> /*NOTES: Mary had a little lamb */ >>> >>> This gives: >>> >>> /* >>>* NOTES: Mary had a >>>* NOTES: little >>>* NOTES: lamb */ >>> >>> The same thing happens if you go into a pre-existing multiline comment >>> and start typing. If the first-line-only comment is inserted on the >>> first line of the multiline comment, it is fine. Otherwise, it fails. >>> >>> In addition: >>> >>> :set comments+=n:// >>> >>> Type: >>> >>>// NOTES: mary had a little lamb >>> >>> to get: >>> >>> // NOTES: Mary had a >>> // NOTES: little >>> // NOTES: lamb >>> >>> I'm using gvim 7.1.293, 'Big' compile on MS Windows (I got it off the >>> 'cream' sourceforge page). >> Any comments on this? I'm pretty sure it is a bug, but if it isn't, >> I'd certainly like to know why! > > /* > * This is a three-piece comment > * with start, middle and end: > * a single comment starts at > * slash-star and ends at star-slash > */ > > // This is a set of successive > // single-line comments: > // each double slash > // starts a new comment, > // which ends at the end of the line. > > NOTE: This kind of comment > can be nested within > the above two kinds. > But nesting does not > overlap. > > By "overlapping", I mean like brackets or HTML tags: ([]) is valid but > ([)] isn't. Maybe I should have said that ([)()()()(]) isn't; and I didn't address the case of NOTES starting on the middle line of a three-piece comment. > > > Best regards, > Tony. -- Here is the fact of the week, maybe even the fact of the month. According to probably reliable sources, the Coca-Cola people are experiencing severe marketing anxiety in China. The words "Coca-Cola" translate into Chinese as either (depending on the inflection) "wax-fattened mare" or "bite the wax tadpole". Bite the wax tadpole. There is a sort of rough justice, is there not? The trouble with this fact, as lovely as it is, is that it's hard to get a whole column out of it. I'd like to teach the world to bite a wax tadpole. Coke -- it's the real wax-fattened mare. Not bad, but broad satiric vistas do not open up. -- John Carrol, San Francisco Chronicle --~--~-~--~~~---~--~~ You received this message from the "vim_dev" maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: Nested 'first line only' comments fail
On 23/04/08 17:40, fritzophrenic wrote: > > > On Apr 17, 1:12 pm, fritzophrenic<[EMAIL PROTECTED]> wrote: >> See the vim_use >> thread:http://groups.google.com/group/vim_use/browse_thread/thread/863a0ce08... >> >> It seems that a nested first line only comment will incorrectly >> prepend the comment leader on the next line if it occurs in the middle >> of a multiline comment or in a single-line comment. >> >> For example, in a new buffer: >> >> :set tw=20 comments=ns1:/*,nmb:*,nex:*/,nfb:NOTES: fo=tcqr cindent >> >> Type: >> >> /* NOTES: mary had a little lamb */ >> >> The comments wrap exactly as expected, i.e. >> >> /* NOTES: mary had a >> *little >> *lamb */ >> >> Now type: >> >> /*NOTES: Mary had a little lamb */ >> >> This gives: >> >> /* >> * NOTES: Mary had a >> * NOTES: little >> * NOTES: lamb */ >> >> The same thing happens if you go into a pre-existing multiline comment >> and start typing. If the first-line-only comment is inserted on the >> first line of the multiline comment, it is fine. Otherwise, it fails. >> >> In addition: >> >> :set comments+=n:// >> >> Type: >> >> // NOTES: mary had a little lamb >> >> to get: >> >> // NOTES: Mary had a >> // NOTES: little >> // NOTES: lamb >> >> I'm using gvim 7.1.293, 'Big' compile on MS Windows (I got it off the >> 'cream' sourceforge page). > > Any comments on this? I'm pretty sure it is a bug, but if it isn't, > I'd certainly like to know why! > > > /* * This is a three-piece comment * with start, middle and end: * a single comment starts at * slash-star and ends at star-slash */ // This is a set of successive // single-line comments: // each double slash // starts a new comment, // which ends at the end of the line. NOTE: This kind of comment can be nested within the above two kinds. But nesting does not overlap. By "overlapping", I mean like brackets or HTML tags: ([]) is valid but ([)] isn't. Best regards, Tony. -- ARTHUR: What does it say? BROTHER MAYNARD: It reads ... "Here may be found the last words of Joseph of Aramathea." "He who is valorous and pure of heart may find the Holy Grail in the arrggghhh..." ARTHUR: What? BROTHER MAYNARD: "The Arrggghhh..." "Monty Python and the Holy Grail" PYTHON (MONTY) PICTURES LTD --~--~-~--~~~---~--~~ You received this message from the "vim_dev" maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: Nested 'first line only' comments fail
On Apr 17, 1:12 pm, fritzophrenic <[EMAIL PROTECTED]> wrote: > See the vim_use > thread:http://groups.google.com/group/vim_use/browse_thread/thread/863a0ce08... > > It seems that a nested first line only comment will incorrectly > prepend the comment leader on the next line if it occurs in the middle > of a multiline comment or in a single-line comment. > > For example, in a new buffer: > > :set tw=20 comments=ns1:/*,nmb:*,nex:*/,nfb:NOTES: fo=tcqr cindent > > Type: > > /* NOTES: mary had a little lamb */ > > The comments wrap exactly as expected, i.e. > > /* NOTES: mary had a > * little > * lamb */ > > Now type: > > /*NOTES: Mary had a little lamb */ > > This gives: > > /* > * NOTES: Mary had a > * NOTES: little > * NOTES: lamb */ > > The same thing happens if you go into a pre-existing multiline comment > and start typing. If the first-line-only comment is inserted on the > first line of the multiline comment, it is fine. Otherwise, it fails. > > In addition: > > :set comments+=n:// > > Type: > > // NOTES: mary had a little lamb > > to get: > > // NOTES: Mary had a > // NOTES: little > // NOTES: lamb > > I'm using gvim 7.1.293, 'Big' compile on MS Windows (I got it off the > 'cream' sourceforge page). Any comments on this? I'm pretty sure it is a bug, but if it isn't, I'd certainly like to know why! --~--~-~--~~~---~--~~ You received this message from the "vim_dev" maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
