Re: Consistently exit message display with 'q'?
- Original Message - From: Jean-Rene David [EMAIL PROTECTED] To: vim@vim.org Sent: Tuesday, March 20, 2007 9:56 AM Subject: Re: Consistently exit message display with 'q'? * Bram Moolenaar [2007.03.20 11:45]: How many times did I repeat a command just because I had pressed Space one time too many... You can type g to go back to the messages. Thanks! Didn't know about that. Reading the help, this only brings back the last viewed page of messages though. Not quite the same thing as bringing up the complete output of the last command. Also note that it works only for internal commands. The original post gave both an internal (set) and external (!ls) command in his example... Brett Stahlman -- JR
Re: grep and regular expression
- Original Message -
From: Naim Far [EMAIL PROTECTED]
To: vim@vim.org
Sent: Thursday, December 14, 2006 8:06 AM
Subject: grep and regular expression
Hi,
I'm writing C++ code, I'm trying to search for all class declaration via the
following command:
:grep 'class\s*\w\+{' *.hpp
The command fails! although if I do search for the same expression, the search
succeeds (in a specific file)!
When you invoke Vim's :grep command, Vim's regular expression engine is not used at all. Vim invokes the external grep command
specified with the 'grepprg' option and parses the stdout from the grep command according to the 'grepformat' option.
:help grepprg
:help grepformat
If you want the matching to use Vim's regular expression dialect, you need to
use :vimgrep.
:help vimgrep
Hope this helps,
Brett S.
Y?!
Thanx...
Re: Spurious undefined variable error generated for certain valid ternary expressions
- Original Message - From: Bram Moolenaar [EMAIL PROTECTED] To: Stahlman Family [EMAIL PROTECTED] Cc: vim@vim.org Sent: Wednesday, November 08, 2006 2:00 PM Subject: Re: Spurious undefined variable error generated for certain valid ternary expressions Brett Stahlman wrote: The following expression var10?var:10 generates the following errors: E121: Undefined variable: var:10 E15: Invalid expression: var10?var:10 The reason is that find_name_end uses eval_isnamec unconditionally to decide whether a character is a valid variable name character, with the result that `:' is always gobbled up as part of the variable name, even if it's not the second character in the name string (ie, even if it doesn't separate the scope prefix from the variable name). find_var_ht, on the other hand, will not permit a colon anywhere but at character index 1 in the variable name; hence, E121, and ultimately, E15. Since `:' is part of a valid VimL operator, and is not valid anywhere other than at index 1 in a non-curly-brace variable name, there is no ambiguity in the expression shown above. For expressions such as b10?b:a the ambiguity would be resolved according to the relative precedence of the ternary operator and the variable scope separator (`:'). I would assume that the precedence of the scope operator would be higher (since Vim treats it as part of 'variable', whose precedence is much higher than that of the ternary operator); hence, in the preceding example, the expression would be evaluated as (b10)?(b:a) which would indeed be a syntax error... Should eval_isnamec (or perhaps its caller) take into consideration the character index when deciding whether `:' is to be considered part of the variable name? The docs clearly state: You should always put a space before the ':', otherwise it can be mistaken for use in a variable such as a:1. Hmm. Ok. I didn't find that text with helpgrep, but I've got Vim7 beta version still on this computer. Perhaps it was added since then... Thanks, Brett S. In some cases var:10 can be recognized as not being a variable name, but this leads to undetected mistakes and makes it difficult to add more scopes later. It's a good habit to put spaces around ? and : anyway. Unless you never read back what you've written perhaps. -- hundred-and-one symptoms of being an internet addict: 182. You may not know what is happening in the world, but you know every bit of net-gossip there is. /// Bram Moolenaar -- [EMAIL PROTECTED] -- 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///
Re: gvim cut paste selection
Ujjal, Although it fixed the problem (or perhaps only masked it, as the underlying problem is with Cygwin X), the patch I submitted to Vim was rejected. Bram maintained that since the bug pertained to Cygwin XWindows, so should the fix. I actually did not disagree with him on this point. The reason I had started with Vim rather than XWindows was that I was more familiar with Vim's source code. However, since Bram refused to incorporate the patch, I proceeded to post to the XWindows list. It was suggested that I write a patch and submit it. I wrote a patch, and Colin Harrison (who was more familiar with the patch submission process) tested the patch and submitted it to the Bugzilla bug tracking database. I also tested on my own PC running Cygwin X and gVim compiled from unix sources. Months after patch submission, the patch was accepted and the issue changed to FIXED / RESOLVED. I have not yet checked to see whether the patch has actually been rolled into the most recently released version of XWin. You can see a full description of the bug and how I fixed it by reading the thread below. Also, I've included the link to the Bugzilla submission page, so you can obtain and apply the Xwin patch if you like. Alternatively, you could obtain and apply the Vim patch, but since it's not likely ever to find its way into Vim (and really is kind of a kludge anyways), I'd recommend the former approach... Hope this helps, Brett Stahlman Thread subject: Serious flaw in Cygwin X clipboard integration prevents paste from X to Windows app http://www.cygwin.com/ml/cygwin-xfree/2006-01/msg00030.html Bugzilla entry 5375: https://bugs.freedesktop.org/show_bug.cgi?id=5735 - Original Message - From: Ujjal Bose To: [EMAIL PROTECTED] Sent: Tuesday, November 07, 2006 3:16 AM Subject: Fwd: gvim cut paste selection Hi, I saw ur patch that you have posted to the URL mentioned below. So will the same patch work for a unix vim or is it only for Win32 ? As you can see from the thread below that I am also facing similar problems , but from Unix Gvim Windows Apps. Thanks, Ujjal Forwarded Conversation Subject: gvim cut paste selection From: Ujjal Bose [EMAIL PROTECTED] To: vim@vim.org Date: Sat, Nov 4, 2006 at 9:30 PM Hi , I was having problem with cut-paste selections from X - Windows for gvim (6.2) , and this is the reply I got from the RealVNC team . So is there a way to solve this in gvim ? Thanks in advance ! -Ujjal -- Forwarded message -- From: James Weatherall [EMAIL PROTECTED] Date: Nov 3, 2006 9:59 PM Subject: RE: Xvnc cut paste problem To: Ujjal Bose [EMAIL PROTECTED], [EMAIL PROTECTED] Hi Ujjal, It sounds like gvim doesn't set the timestamp on the X selection correctly when it sets it, so vncconfig doesn't think it's changed. Selecting text in another X application, then selecting the desired text in gvim should cause vncconfig to see the selection ownership change and to then send the gvim text to the viewer. Cheers, Wez @ RealVNC Ltd. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] ] On Behalf Of Ujjal Bose Sent: 01 November 2006 19:09 To: [EMAIL PROTECTED] Subject: Xvnc cut paste problem For the laste few days my cut paste selections from Unix-Windows is not working properly but Windows-Unix works perfectly. I was using autocutsel to enable cut-paste between various X11 selections, and also had a line for vncconfig -nowin -iconic in my VNC xstartup file but nothing seems to help. 0) I am using Xvnc 4.2.1 server in my Linux m/c and TightVNC viewer on Windows XP side. 1) A Copy selection from a unix application (gvim) seems to work intermittently. 2) If I do a mouse based visual selection (also called PRIMARY selection in X11) from my gvim windows , and paste it in Windows notepad, only a partial paste happens for the first time, and then onwards , the same stuff is pasted over and over again, in spite of selecting some other text in gvim. 3) Pasting from xterm-Notepad(Windows) seems to work correctly. 4) I even started a new VNC session on another Linux m/c (same xstartup file) but didnt help. 5) Another thing I observed : from gvim , irrespective of my selection method (copy or mouse based) , the paste in Notepad seems to work only (partially in case of mouse selection and fully in case of Copy) for the first time. If I select something else now and then try to paste , the last stuff only gets pasted. BUT IF I COPY BACK SOME TEXT FROM WINDOWS-UNIX and then try again , IT WORKS FOR THE NEW SELECTION , but again , only for once, till I repeat the process. 6) Again, pasting from xterm always works perfectly. Any help appreciated. -Ujjal # My xstartup file vncconfig -nowin if ($OSTYPE == Linux) then # Linux xrdb $HOME/.Xresources \xterm -geometry 80x24+10+10 -ls -title $VNCDESKTOP Desktop #/usr/bin/gnome-session #/usr/bin/startkde #fvwm2
Re: gvim cut paste selection
- Original Message - From: Ujjal Bose [EMAIL PROTECTED] To: vim@vim.org Sent: Tuesday, November 07, 2006 1:19 PM Subject: Re: gvim cut paste selection On 11/8/06, Stahlman Family [EMAIL PROTECTED] wrote: Ujjal, Although it fixed the problem (or perhaps only masked it, as the underlying problem is with Cygwin X), the patch I submitted to Vim was rejected. Bram maintained that since the bug pertained to Cygwin XWindows, so should the fix. I actually did not disagree with him on this point. The reason I had started with Vim rather than XWindows was that I was more familiar with Vim's source code. However, since Bram refused to incorporate the patch, I proceeded to post to the XWindows list. It was suggested that I write a patch and submit it. I wrote a patch, and Colin Harrison (who was more familiar with the patch submission process) tested the patch and submitted it to the Bugzilla bug tracking database. I also tested on my own PC running Cygwin X and gVim compiled from unix sources. Months after patch submission, the patch was accepted and the issue changed to FIXED / RESOLVED. I have not yet checked to see whether the patch has actually been rolled into the most recently released version of XWin. You can see a full description of the bug and how I fixed it by reading the thread below. Also, I've included the link to the Bugzilla submission page, so you can obtain and apply the Xwin patch if you like. Alternatively, you could obtain and apply the Vim patch, but since it's not likely ever to find its way into Vim (and really is kind of a kludge anyways), I'd recommend the former approach... Hope this helps, Brett Stahlman Thread subject: Serious flaw in Cygwin X clipboard integration prevents paste from X to Windows app http://www.cygwin.com/ml/cygwin-xfree/2006-01/msg00030.html Bugzilla entry 5375: https://bugs.freedesktop.org/show_bug.cgi?id=5735 - Original Message - From: Ujjal Bose To: [EMAIL PROTECTED] Sent: Tuesday, November 07, 2006 3:16 AM Subject: Fwd: gvim cut paste selection Hi, I saw ur patch that you have posted to the URL mentioned below. So will the same patch work for a unix vim or is it only for Win32 ? As you can see from the thread below that I am also facing similar problems , but from Unix Gvim Windows Apps. Thanks, Ujjal Hi Brett, I tested your vim patch on my machine and its working for me in Unix, after removing the ifdef WIN32 macros from the patch. Now cut/paste across gvim (unix) -- Windows apps is perfect ! As noted earlier by Brett, this may not be the best approach, but it pretty much solves my problem :) Ujjal, I'm glad you got it working. Although the XWin patch is probably the ideal solution, building Vim is probably easier than building XWin, and a working non-ideal solution is always better than none at all. However, I am meaning to download the latest XWin source distribution to see whether my patch is in it yet. When I see that it is, I'll notify the list, since there are probably other Vim users who have been affected by this... Brett Stahlman Thanks to Brett and Yakov ! -Ujjal
Spurious undefined variable error generated for certain valid ternary expressions
The following expression var10?var:10 generates the following errors: E121: Undefined variable: var:10 E15: Invalid expression: var10?var:10 The reason is that find_name_end uses eval_isnamec unconditionally to decide whether a character is a valid variable name character, with the result that `:' is always gobbled up as part of the variable name, even if it's not the second character in the name string (ie, even if it doesn't separate the scope prefix from the variable name). find_var_ht, on the other hand, will not permit a colon anywhere but at character index 1 in the variable name; hence, E121, and ultimately, E15. Since `:' is part of a valid VimL operator, and is not valid anywhere other than at index 1 in a non-curly-brace variable name, there is no ambiguity in the expression shown above. For expressions such as b10?b:a the ambiguity would be resolved according to the relative precedence of the ternary operator and the variable scope separator (`:'). I would assume that the precedence of the scope operator would be higher (since Vim treats it as part of 'variable', whose precedence is much higher than that of the ternary operator); hence, in the preceding example, the expression would be evaluated as (b10)?(b:a) which would indeed be a syntax error... Should eval_isnamec (or perhaps its caller) take into consideration the character index when deciding whether `:' is to be considered part of the variable name? Thanks, Brett Stahlman
Re: Why not use binary search for wildmode tag completion in case of fixed-start, non-regex pattern?
- Original Message -
From: A.J.Mechelynck [EMAIL PROTECTED]
To: Stahlman Family [EMAIL PROTECTED]
Cc: vim@vim.org
Sent: Saturday, September 23, 2006 1:59 AM
Subject: Re: Why not use binary search for wildmode tag completion in case of
fixed-start, non-regex pattern?
Stahlman Family wrote:
Recently, I've begun building tags for a very large development project. The time required by Vim to build the list prior to
displaying the first match after I hit wildchar for a :tag command has become noticeably long. I researched it a bit in both the
help and the source code, and I'm wondering why Vim always does a linear search for tag completions that could return more than
one match. I mean, I understand why in a case like this
:ta /[a-z]_funwildchar
linear search would be necessary. But what about in the much more common case
:ta ProcessAwildchar
For such fixed start patterns, all possible matches will be clustered together (and usually will span no more than a handful of
lines) in a sorted tags file. Thus, the beginning of the range of possibilities could be found via binary search, then the
remaining matches could be found by traversing the tags file linearly until the last match is found. For tags files containing
tens of thousands of tags, as mine does, this would result in a dramatic improvement in responsiveness when wildchar is hit.
Thanks,
Brett Stahlman
Does your tags file start with one of the lines
!_TAG_FILE_SORTEDTab1Tab{anything}
or
!_TAG_FILE_SORTEDTab2Tab{anything}
and if yes, which one?
the former
.
And what is the reply to :verbose set ignorecase?
ignorecase is off
see :help tagsrch.txt then search for /!_TAG_
I know the binary search is being used in cases where only a single match can
be found.
e.g.,
:ta MyFuncEnter
In such cases, the tag location is jumped to practically instantaneously. It is obvious, however, that the linear search is employed
when I do something like this instead:
:ta MyFuncwildchar
This is in accordance with the help on 'tagbsearch' option:
This option doesn't affect commands that find all matching tags (e.g.,
command-line completion and :help).
I understand why this is done in the case in which the tag pattern being completed is a regex, but it seems to increase the search
time significantly and unnecessarily in what I believe is the more common case of a completion on a fixed string pattern.
Thanks,
Brett Stahlman
Best regards,
Tony.
Why not use binary search for wildmode tag completion in case of fixed-start, non-regex pattern?
Recently, I've begun building tags for a very large development project. The time required by Vim to build the list prior to displaying the first match after I hit wildchar for a :tag command has become noticeably long. I researched it a bit in both the help and the source code, and I'm wondering why Vim always does a linear search for tag completions that could return more than one match. I mean, I understand why in a case like this :ta /[a-z]_funwildchar linear search would be necessary. But what about in the much more common case :ta ProcessAwildchar For such fixed start patterns, all possible matches will be clustered together (and usually will span no more than a handful of lines) in a sorted tags file. Thus, the beginning of the range of possibilities could be found via binary search, then the remaining matches could be found by traversing the tags file linearly until the last match is found. For tags files containing tens of thousands of tags, as mine does, this would result in a dramatic improvement in responsiveness when wildchar is hit. Thanks, Brett Stahlman
