Re: completion menu
On 4/20/06, Linsong <[EMAIL PROTECTED]> wrote: > I also think here is a little confusing. Since the user are > selecting menu items with /, and at this time, Enter is > normally assumed as a confirm of the selection. And I think it is very > common a user interface convention. I disagree, using Enter to select an item from a menu which has been reached using / is not a common user interface convention which I have seen. Using Enter to select something from a menu selected with the arrow keys, however, is. I think this adapts nicely to the expectations of both the more advanced and less advanced users. Those who wish to do a minimum of reaching can do so, and those who like lots of hand waving can have their fill. >I think it is worth breaking the compatibility between vim6.x and > vim7 since there is no completion menu in vim6.x. This would break compatibility with itself as well, though, as the behaviour of / then varies depending on the value of completeopt. Currently the value can be ignored and that makes it backwards compatible with the expectations of the users (showing the menu is now the default, so changing the behaviour would not obey the principle of least surprise). >From a personal perspective, getting used to hitting enter twice at the ends of lines is a very hard thing to do. Regards, Chris Allen
omni-completion: info bug
Just a "heads up": Using an omni-completion dictionary, a single completion entry (for which no menu is displayed) does not update the info preview window. Thanks, Aaron Griffin
Re: completion menu
Bram Moolenaar wrote: Georg Dahn wrote: Ok, let's assume there are several completions, such that you get a menu with . Then if you move the selection with the cursor keys and press , the selected item is being chosen. If you do the same with (instead of using cursor keys), inserts a new line. I think, this is confusing. Is this behavior intentional or is it a bug? This is intentional, it was discussed recently. This is a compromise between different expectations from different users. People who used CTRL-N/CTRL-P in Vim 6.4 expect the to be inserted, since that is what happened in older versions. People who are using cursor keys to select an item in the popup menu mostly expect to accept the selected match. That's why the behavior of depends on what you did earlier. Hi, I also think here is a little confusing. Since the user are selecting menu items with /, and at this time, Enter is normally assumed as a confirm of the selection. And I think it is very common a user interface convention. I think it is worth breaking the compatibility between vim6.x and vim7 since there is no completion menu in vim6.x. Best regards, Vincent
Re: suggestions for omni-completion
Alan Briolat wrote: On Wed, 19 Apr 2006 14:25:42 +0800 Linsong <[EMAIL PROTECTED]> wrote: Alan Briolat wrote: On Wed, 19 Apr 2006 11:51:31 +0800 Linsong <[EMAIL PROTECTED]> wrote: Hi, I have tried the omni competion, it is very cool! But there is still one thing that I think is not very convenient. For example, when I input part of a function name(foobar): foo| (| is the position of the cursor) then I invoke the omnicompletion by pressing , consider the completion list like this: fooblah fooblahblah fooblahblah foobar ... ... then the strings inputed will be replaced by the first matched item(here it is fooblah). If I want to get foobar, I need to press several times. It is not very convenient. I think it would be better like the following: After , the inputed string will not be replaced, only the completion menu shows up, then I can choose the item that I want by pressing ; Or, I can go on to input more characters and the completion menu will update its menu items based on the new input when I input. So the items in completion menu will become less and less and it is easier to select the matched item. Inputing more characters is better than pressing several times. I *believe* this is the purpose of (someone please correct me if I am wrong...) Yes, that is just what I mean. I need to go over the online help :) Do you know how to make it as the default action, that is make works like ? Well, what I do is map a different key sequence to it. My preference (doesn't work in terminals though) is: :imap There appears to be only one problem with using , which is that it makes omni-complete useless when there is only one match (doesn't replace, and doesn't give a list of options). If someone knows how to overcome this, please let me know :( I suggest vim to provide a option that don't modify the inputed character when pressing . BR Vincent
vim7: request for new autocommands
On the lines of InsertEnter and InsertLeave, can we please have CommandEnter and CommandLeave that will get triggered when the user starts one of the :, /, ?, = etc. modes? The reason I ask is, with the addition of getcmdtype(), it is now possible to create maps and abbreviations dynamically that only apply to a particular type of prompt, provided we can know when the mode starts and when it ends. -- Thanks a lot, Hari __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Re: changing cursor position from search prompt doesn't work
Hi Hari, On 4/19/06, Hari Krishna Dara <[EMAIL PROTECTED]> wrote: > > If you execute a function that changes the cursor position from the > search prompt, vim completely ignores it, but the same works fine from > the command prompt. Say, you have something like this: > > function! TT() > call cursor(1,1) > return "" > endfunction > > and you execute it as: > > :=TT() > > the cursor position gets changed to the start of the file, but the same > doesn't work if you do the below: > > /=TT() > > Is this a bug or intended behavior? I can't find a way to get this to > work without coming out of the search prompt, go into the command > prompt to execute the function, and return back to the search prompt. > Any help is apprecaited. > This is the intended behavior. After you hit enter at the search prompt, the cursor is repositioned to the original cursor location and the pattern is searched again. So you cannot change the cursor location from the search prompt. - Yegappan
Moderator for Vim Tips
A few weeks (months?) ago a suggestion was made that the submissions to Vim tips be moderated. This is due to the address being used by spammers. Apparently nobody volunteered to do this because there are still inappropriate "tips" being submitted. I am willing to do this, but I don't have the expertise required to test all the tips. I can screen them to make sure they are appropriate. Would that agree with anyone? Jeremy Conlin
Re: "dns"/"bindzone" (zonefile) syntax highlighting
Julian Mehnle wrote:
> [...] I looked at the bindzone.vim in the Vim7 Subversion repo, and, lo
> and behold, it is still the old version from Vim6. Please replace it
> with the new one from:
>
> http://www.mehnle.net/svn/odds+ends/vim/syntax/bindzone.vim
...or better the attached one, which has the $Id$ Subversion keyword
properly filled in.
Julian.
" Vim syntax file
" Language: BIND zone files (RFC1035)
" Maintainer: Julian Mehnle <[EMAIL PROTECTED]>
" URL: http://www.mehnle.net/source/odds+ends/vim/syntax/
" Last Change: Mon 2006-03-20 15:34:23 UTC
"
" Based on an earlier version by Вячеслав Горбанев (Slava Gorbanev), with
" heavy modifications.
"
" $Id: bindzone.vim 6 2006-03-26 17:08:03Z julian $
" For version 5.x: Clear all syntax items
" For version 6.x: Quit when a syntax file was already loaded
if version < 600
syntax clear
elseif exists("b:current_syntax")
finish
endif
syn case match
if version >= 600
setlocal iskeyword=.,-,48-58,A-Z,a-z,_
else
set iskeyword=.,-,48-58,A-Z,a-z,_
endif
" Directives
syn region zoneRRecord start=/^/ end=/$/
contains=zoneOwnerName,zoneSpecial,zoneTTL,zoneClass,zoneRRType,zoneComment,zoneUnknown
syn match zoneDirective /^\$ORIGIN\s\+/
nextgroup=zoneOrigin,zoneUnknown
syn match zoneDirective /^\$TTL\s\+/
nextgroup=zoneNumber,zoneUnknown
syn match zoneDirective /^\$INCLUDE\s\+/ nextgroup=zoneText,zoneUnknown
syn match zoneDirective /^\$GENERATE\s/
syn match zoneUnknown contained /\S\+/
syn match zoneOwnerName contained
/^[^[:space:]!"#$%&'()*+,\/:;<=>[EMAIL PROTECTED]|}~]\+\(\s\|;\)[EMAIL
PROTECTED]/ nextgroup=zoneTTL,zoneClass,zoneRRType skipwhite
syn match zoneOrigin contained
/[^[:space:]!"#$%&'()*+,\/:;<=>[EMAIL PROTECTED]|}~]\+\(\s\|;\|$\)[EMAIL
PROTECTED]/
syn match zoneDomain contained
/[^[:space:]!"#$%&'()*+,\/:;<=>[EMAIL PROTECTED]|}~]\+\(\s\|;\|$\)[EMAIL
PROTECTED]/
syn match zoneSpecial contained /[EMAIL PROTECTED]/
syn match zoneTTL contained /\<\d[0-9HhWwDd]*\>/
nextgroup=zoneClass,zoneRRType skipwhite
syn keyword zoneClass contained IN CHAOS
nextgroup=zoneRRType,zoneTTL skipwhite
syn keyword zoneRRType contained A CNAME HINFO MX NS PTR SOA SRV
TXT nextgroup=zoneRData skipwhite
syn match zoneRData contained /[^;]*/
contains=zoneDomain,zoneIPAddr,zoneIP6Addr,zoneText,zoneNumber,zoneParen,zoneUnknown
syn match zoneIPAddr contained
/\<[0-9]\{1,3}\(\.[0-9]\{1,3}\)\{,3}\>/
" Plain IPv6 address IPv6-embedded-IPv4 address
" :2:3:4:5:6:7:8 :2:3:4:5:6:127.0.0.1
syn match zoneIP6Addr contained
/\<\(\x\{1,4}:\)\{6}\(\x\{1,4}:\x\{1,4}\|\([0-2]\?\d\{1,2}\.\)\{3}[0-2]\?\d\{1,2}\)\>/
" ::[...:]8 ::[...:]127.0.0.1
syn match zoneIP6Addr contained
/\s\@<=::\(\(\x\{1,4}:\)\{,6}\x\{1,4}\|\(\x\{1,4}:\)\{,5}\([0-2]\?\d\{1,2}\.\)\{3}[0-2]\?\d\{1,2}\)\>/
" ::[...:]8 ::[...:]127.0.0.1
syn match zoneIP6Addr contained
/\<\(\x\{1,4}:\)\{1}:\(\(\x\{1,4}:\)\{,5}\x\{1,4}\|\(\x\{1,4}:\)\{,4}\([0-2]\?\d\{1,2}\.\)\{3}[0-2]\?\d\{1,2}\)\>/
" :2::[...:]8 :2::[...:]127.0.0.1
syn match zoneIP6Addr contained
/\<\(\x\{1,4}:\)\{2}:\(\(\x\{1,4}:\)\{,4}\x\{1,4}\|\(\x\{1,4}:\)\{,3}\([0-2]\?\d\{1,2}\.\)\{3}[0-2]\?\d\{1,2}\)\>/
" :2:3::[...:]8 :2:3::[...:]127.0.0.1
syn match zoneIP6Addr contained
/\<\(\x\{1,4}:\)\{3}:\(\(\x\{1,4}:\)\{,3}\x\{1,4}\|\(\x\{1,4}:\)\{,2}\([0-2]\?\d\{1,2}\.\)\{3}[0-2]\?\d\{1,2}\)\>/
" :2:3:4::[...:]8 :2:3:4::[...:]127.0.0.1
syn match zoneIP6Addr contained
/\<\(\x\{1,4}:\)\{4}:\(\(\x\{1,4}:\)\{,2}\x\{1,4}\|\(\x\{1,4}:\)\{,1}\([0-2]\?\d\{1,2}\.\)\{3}[0-2]\?\d\{1,2}\)\>/
" :2:3:4:5::[...:]8 :2:3:4:5::127.0.0.1
syn match zoneIP6Addr contained
/\<\(\x\{1,4}:\)\{5}:\(\(\x\{1,4}:\)\{,1}\x\{1,4}\|\([0-2]\?\d\{1,2}\.\)\{3}[0-2]\?\d\{1,2}\)\>/
" :2:3:4:5:6::8 -
syn match zoneIP6Addr contained /\<\(\x\{1,4}:\)\{6}:\x\{1,4}\>/
" [:...]::-
syn match zoneIP6Addr contained
/\<\(\x\{1,4}:\)\{1,7}:\(\s\|;\|$\)[EMAIL PROTECTED]/
syn match zoneTextcontained /"\([^"\\]\|\\.\)*"\(\s\|;\|$\)[EMAIL
PROTECTED]/
syn match zoneNumber contained /\<[0-9]\+\(\s\|;\|$\)[EMAIL
PROTECTED]/
syn match zoneSerial contained /\<[0-9]\{9,10}\(\s\|;\|$\)[EMAIL
PROTECTED]/
syn match zoneErrParen/)/
syn region zoneParen contained start="(" end=")"
contains=zoneSerial,zoneNumber,zoneComment
syn match zoneComment /;.*/
" Define the default highlighting.
" For version 5.7 and earlier: only when not done already
" For version 5.8 and later: only when an item doesn't have highlighting yet
if version >= 508 || !exists("did_bind_zone_syn_inits
Re: "dns"/"bindzone" (zonefile) syntax highlighting
Bram, I see that you applied a modified version of my patch regarding bindzone-vs-dns syntax highlighting to the filetype.vim, scripts.vim, and synmenu.vim runtime files. Your changes are probably better than what I could have come up with (given your superior knowledge of how filetype.vim and scripts.vim work and interact), so thank you for finishing the job! Bram Moolenaar wrote: > Julian Mehnle wrote: > > Please also remove the "dns" entry from the "Vim script links" page[1] > > and update the "bindzone" entry to point to... > > > > http://www.mehnle.net/source/odds+ends/vim/syntax/ > > This list of links is updated automatically. When the syntax files are > changed the list will follow. I'll start using the Vim 7 files for > this. I assume that this has already happened, because the obsolete "dns" script is already no longer listed. But as "bindzone" still has the old URL, I looked at the bindzone.vim in the Vim7 Subversion repo, and, lo and behold, it is still the old version from Vim6. Please replace it with the new one from: http://www.mehnle.net/svn/odds+ends/vim/syntax/bindzone.vim Thanks, Julian. pgpkvIE5QMY00.pgp Description: PGP signature
Feature request: for abbreviations
In Vim7, I see that maps can now have argument to indicate that the RHS is an expression that should be evaluated. I think this is cool, and though I don't have a need yet, I am pretty sure it will come to good use soon. But meanwhile, I think the same should be extended to abbreviations too. I know you can already use = for the same, but the method is going to be useful specifically for the cabbr case. Currently if you need to define a cabbr that uses the = construct to evaluate an expression, this causes trouble when typing the abbreviation (even if it is accidental) at the expression register prompt. An example might help (please don't get into specifics of the use case, it is meant only to demonstrate the problem). Suppose you want CD to expand to "cd " and the value of needs to be determined dynamically (for whatever reason), you would do it something like: :cabbr CD cd =GetDir() :function! GetDir() : " Determine somedir. : return somedir :endfun This will work as expected while using it on say, : prompt, but the problem is you might type the word "CD" while you are in the expression register prompt, and this completely fails. In fact, you might actually want to restrict the abbreviation only to the : prompt (not even to the search prompts). One way to do this is to use the new getcmdtype(): :cabbr CD =ExpandCD() :function! ExpandCD() : if getcmdtype() == ":" : " Determine somedir. : return "cd ".somedir : else : return "CD" : endif :endfunc This works very nicely, as you will see it expands only when you are at the : prompt, not / or ? prompt, but fails while in expression register prompt. If :abbr supports option, then this can nicely be changed as: :cabbr CD ExpandCD() and it will work even in the expression register case. Further the return value of the function should be treated just like the return value of =, i.e., if the expression returns Vim normal commands, they should be executed. This allows us to completely manipulate the command-line using cabbr's with a combination of the ^\e command and a few left arrow keys (unfortunately, we can't use setcmdpos() here) functions. E.g., it is will be possible to return the string "\e\"cd somedir\" to replace the current command line with "cd somedir" instead of appending it. The use case might not be appealing, but I hope I conveyed the possibilities. Comments or alternatives are welcome. -- Thank you, Hari __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Re: visual selection invisible in default color scheme when
Hi! In case it helps you track down the problem: I don't see this behavior on Vim 7.0d02 BETA (12 april 2006). This behavior has been introduced after Vim 7.0e BETA, because I did not see it in Vim 7.0e BETA, either. Why do I know this? I see this behavior when doing colo in my vimrc file and doing colo default in the started gVim 7.0e02 BETA (and now in gVim 7.0e03 BETA). In gVim 7.0e BETA I remember that this worked. Best wishes, Georg Send instant messages to your online friends http://uk.messenger.yahoo.com
Re: request for / termcap entries in vim
On Wed, Apr 19, 2006 at 10:57:44PM +0200, Bram Moolenaar wrote: > Gautam Iyer wrote: > > > I was wondering if it would be possible to add the termcap entries > > , , and and to Vim 7 (for keypad > > keys)? > > > > I really like the '*' form of entering key codes. I hacked mrxvt so that > > modified cursor, function or keypad keys produce escape sequences > > consistent with Vim 7's "*" form modifier termcap sequences. (Now most > > modified keypad / function keys work out of the box with mrxvt-0.5.0 and > > vim 7. Call me biased, but I really don't care so much if these keys > > don't work with other text editors ...) > > > > Unfortunately Vim 7 has termcap sequences for all keypad keys EXCEPT the > > five listed above. Thus I can get my keypad home/end to work, but not > > left/right, up/down and insert. > > > > Additionally, would it also be possible to change the default termcap > > sequences of the keypad keys to use Vim7's wonderful "*" form? > > > > E.g. should be "^[O*y" and not "^[Oy" by default. > > > > Finally, I notice that on my system is '^[[1;*~' by default and > > not '^[Ow'. The remainder of the keypad keys produce a '^[Ox' escape > > sequence (where x is some lower case letter), so shouldn't be > > '^[Ow' by default? The '^[Ow' is the sequence produced by all rxvt > > forks, and xterm with the VT220 keyboard (with numlock on while pressing > > shift). > > > > I'd recommend setting and to '^[O*w' and '^[O*q' > > respectively, and adding and for the sequences '^[[1;*~' > > and '^[[4;*~' respectively. (On some system I think that the linux > > console generates theses sequences by default, so you can call them > > and if you like :) > > > > Just one of my pipe dreams to get all my keypad keys *with* modifiers > > working perfectly under Vim 7 & mrxvt-0.5. I don't really use the keypad > > keys too much though, so it's not crucial. However every once in a while > > I attempt moving using the keypad keys and get strange characters > > entered into my buffer ... :) > > I think it's too close to the Vim 7 release to risc breaking something > with the termcap codes. In the past there have been problems with > some combinations of escape sequences. I'll add a remark to the todo > list. That's too bad. I'll be sure to ask you about it after Vim 7 is released. However, will *adding* the etc sequences be possible? I've a feeling this won't conflict with anything else ... Once added, I can set them to whatever I please in my .vimrc, and happily use my fully functional keypad ;). Thanks, GI -- 'Bachelor' -- One who treats all women as sequels.
Re: QuickFixCmdPost
Eric Van wrote: > When issuing a quickfix command the QuickFixCmdPost auto commands fire > after vim has loaded the first quickfix result. I was hoping that > this could be modified so that vim loads the first result after the > auto commands fire. This way the auto command can modify the quickfix > results if necessary. Makes sense. Ciaran, what do you think? -- The CIA drives around in cars with the "Intel inside" logo. /// 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://www.ICCF.nl ///
Re: request for / termcap entries in vim
Gautam Iyer wrote: > I was wondering if it would be possible to add the termcap entries > , , and and to Vim 7 (for keypad > keys)? > > I really like the '*' form of entering key codes. I hacked mrxvt so that > modified cursor, function or keypad keys produce escape sequences > consistent with Vim 7's "*" form modifier termcap sequences. (Now most > modified keypad / function keys work out of the box with mrxvt-0.5.0 and > vim 7. Call me biased, but I really don't care so much if these keys > don't work with other text editors ...) > > Unfortunately Vim 7 has termcap sequences for all keypad keys EXCEPT the > five listed above. Thus I can get my keypad home/end to work, but not > left/right, up/down and insert. > > Additionally, would it also be possible to change the default termcap > sequences of the keypad keys to use Vim7's wonderful "*" form? > > E.g. should be "^[O*y" and not "^[Oy" by default. > > Finally, I notice that on my system is '^[[1;*~' by default and > not '^[Ow'. The remainder of the keypad keys produce a '^[Ox' escape > sequence (where x is some lower case letter), so shouldn't be > '^[Ow' by default? The '^[Ow' is the sequence produced by all rxvt > forks, and xterm with the VT220 keyboard (with numlock on while pressing > shift). > > I'd recommend setting and to '^[O*w' and '^[O*q' > respectively, and adding and for the sequences '^[[1;*~' > and '^[[4;*~' respectively. (On some system I think that the linux > console generates theses sequences by default, so you can call them > and if you like :) > > Just one of my pipe dreams to get all my keypad keys *with* modifiers > working perfectly under Vim 7 & mrxvt-0.5. I don't really use the keypad > keys too much though, so it's not crucial. However every once in a while > I attempt moving using the keypad keys and get strange characters > entered into my buffer ... :) I think it's too close to the Vim 7 release to risc breaking something with the termcap codes. In the past there have been problems with some combinations of escape sequences. I'll add a remark to the todo list. > PS: I'm still using the anonymous CVS version of Vim from sourceforge. > If any of this has changed since then, please let me know and I'll > attempt to persuade by 56.6kbps modem to use the ftp / SVN server. No, this is stable code. -- hundred-and-one symptoms of being an internet addict: 177. You log off of your system because it's time to go to work. /// 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://www.ICCF.nl ///
ezmlm: Is 4 months long enough to wait for someone to unsubscribe me, since ezmlm cannot?
Would some human please do a simple act of maintenance on the vim-dev list? Can it be much more difficult than opening a text file and deleting (hey, use vim!) a line saying: Eben Oldmixon <[EMAIL PROTECTED]> ? And yes, I've tried everything else. Sorry to be a little snappish, but it's one of those days, and I am tired of dredging through the vim-dev flood for my few personal emails. Thank you. Eben Oldmixon -- No virus found in this outgoing message. Checked by AVG Anti-Virus. Version: 7.1.385 / Virus Database: 268.4.4/319 - Release Date: 4/19/2006
Re: visual selection invisible in default color scheme when
Georg Dahn skrev: Hi! Vim 7.0e02 / Windows XP: 1. gvim -u NONE 2. colo desert 3. colo default Then the visual selection is invisible and the error message "Warning: terminal cannot highlight" is shown. This behavior is reproducible with other color schemes than desert (like morning, evening...). However, doing 'colo desert' is not necessary. Just do 1. gvim -u NONE 2. colo default and visual selection is invisible, too, and the error message is shown again. Best wishes, Georg Send instant messages to your online friends http://uk.messenger.yahoo.com In case it helps you track down the problem: I don't see this behavior on Vim 7.0d02 BETA (12 april 2006). -- Stefan
Re: ezmlm is broken; it can't unsibscribe me, it seems
M. Winn says below, "I think you are going to have to be removed from the list manually." I think so too, and have asked vim-owner to do so, but no one has acted, apparently. WILL SOMEONE PLEASE DO THIS SIMPLE ACT OF MAINTENANCE? THANK YOU! Eben Oldmixon At 03:16 AM 4/13/2006, Matthew Winn wrote: On Wed, Apr 12, 2006 at 02:26:43PM -0400, Eben Oldmixon wrote: > Here's the very top of the "blah-blah" (Eudora's term for it ...) > material in the header: > === > Return-path: <[EMAIL PROTECTED]> > Received: from mta30.srv.hcvlny.cv.net > (mta30.srv.hcvlny.cv.net [167.206.5.101]) by mstr8.srv.hcvlny.cv.net > (Sun Java System Messaging Server 6.2-4.03 (built Sep 22 2005)) > with ESMTP id <[EMAIL PROTECTED]> for > [EMAIL PROTECTED]; Wed, 12 Apr 2006 03:15:51 -0400 (EDT) > Received: from foobar.math.fu-berlin.de > (foobar.math.fu-berlin.de [160.45.45.151]) by mta30.srv.hcvlny.cv.net > (Sun Java System Messaging Server 6.2-4.03 (built Sep 22 2005)) > with SMTP id <[EMAIL PROTECTED]> for > [EMAIL PROTECTED] (ORCPT [EMAIL PROTECTED]); Wed, > 12 Apr 2006 03:15:50 -0400 (EDT) > === > > I do not know how to interpret email headers --- let me admit that up > front. However, does that ORCPT term suggest something along the > lines you mention? Note, though, that there is no other account > involved now except for <[EMAIL PROTECTED]>. Those headers look correct to me, so it does seem as though the mailing list thinks your address is the one you're currently using. Oh well, it was just an idea and it turned out to be wrong :-( I think you're going to need to be removed from the list manually. -- Matthew Winn ([EMAIL PROTECTED]) -- No virus found in this incoming message. Checked by AVG Anti-Virus. Version: 7.1.385 / Virus Database: 268.4.4/319 - Release Date: 4/19/2006 -- No virus found in this outgoing message. Checked by AVG Anti-Virus. Version: 7.1.385 / Virus Database: 268.4.4/319 - Release Date: 4/19/2006
visual selection invisible in default color scheme when
Hi! Vim 7.0e02 / Windows XP: 1. gvim -u NONE 2. colo desert 3. colo default Then the visual selection is invisible and the error message "Warning: terminal cannot highlight" is shown. This behavior is reproducible with other color schemes than desert (like morning, evening...). However, doing 'colo desert' is not necessary. Just do 1. gvim -u NONE 2. colo default and visual selection is invisible, too, and the error message is shown again. Best wishes, Georg Send instant messages to your online friends http://uk.messenger.yahoo.com
request for / termcap entries in vim
Hi Bram, I was wondering if it would be possible to add the termcap entries , , and and to Vim 7 (for keypad keys)? I really like the '*' form of entering key codes. I hacked mrxvt so that modified cursor, function or keypad keys produce escape sequences consistent with Vim 7's "*" form modifier termcap sequences. (Now most modified keypad / function keys work out of the box with mrxvt-0.5.0 and vim 7. Call me biased, but I really don't care so much if these keys don't work with other text editors ...) Unfortunately Vim 7 has termcap sequences for all keypad keys EXCEPT the five listed above. Thus I can get my keypad home/end to work, but not left/right, up/down and insert. Additionally, would it also be possible to change the default termcap sequences of the keypad keys to use Vim7's wonderful "*" form? E.g. should be "^[O*y" and not "^[Oy" by default. Finally, I notice that on my system is '^[[1;*~' by default and not '^[Ow'. The remainder of the keypad keys produce a '^[Ox' escape sequence (where x is some lower case letter), so shouldn't be '^[Ow' by default? The '^[Ow' is the sequence produced by all rxvt forks, and xterm with the VT220 keyboard (with numlock on while pressing shift). I'd recommend setting and to '^[O*w' and '^[O*q' respectively, and adding and for the sequences '^[[1;*~' and '^[[4;*~' respectively. (On some system I think that the linux console generates theses sequences by default, so you can call them and if you like :) Just one of my pipe dreams to get all my keypad keys *with* modifiers working perfectly under Vim 7 & mrxvt-0.5. I don't really use the keypad keys too much though, so it's not crucial. However every once in a while I attempt moving using the keypad keys and get strange characters entered into my buffer ... :) Thanks in advance, GI PS: I'm still using the anonymous CVS version of Vim from sourceforge. If any of this has changed since then, please let me know and I'll attempt to persuade by 56.6kbps modem to use the ftp / SVN server. -- It's a good thing Linux is under GNU General Public Lisense or Microsoft would buy them out too!
QuickFixCmdPost
Version: 70b When issuing a quickfix command the QuickFixCmdPost auto commands fire after vim has loaded the first quickfix result. I was hoping that this could be modified so that vim loads the first result after the auto commands fire. This way the auto command can modify the quickfix results if necessary. -- eric
Re: Coulpe of odd [repeatable] crashes in vim 7
Neil Bird wrote: > Around about 19/04/06 12:07, Bram Moolenaar typed ... > > Apparently your FileChangedRO autocommand does something nasty. I > > suspect we need to detect that nastyness and disallow it. Any idea what > > the nasty bit could be? > >I tried making a cut down fake version, but that always worked. It's > essentially doing a couple of system() [vim] calls, one's a 'cat' of a config > file, the next is the actual remote sourcesafe checkout command (via rsh), of > each of which it parses the output. > >Then it does a :edit to reload the buffer and a 'syntax on'. ISTRT if I > comment out the :syntax on' it stops crashing, but I then get a file with no > syntax highlighting (even though it was on before). Maybe that in itself is > the issue. Main issue is: Do you open another buffer or window? I guess the basic sequence is: - you do "z=" and select a suggestion, this is to be inserted - your file is RO, thus the FileChangedRO autocmd is triggered - your FileChangedRO autocmd uses sourcesafe to get the file Hmm, does this then trigger the timestamp check and trigger a FileChangedShell autocmd? - your FileChangedRO autocmd reloads the file > > After some pointers go wrong anything can happen, thus how it crashes > > exactly is not interesting. It could help to use a library that forbids > > access to freed memory, like efence. Then the error is detected much > > earlier and a stack trace may provide more useful info. > >ef is not reporting anything [except its banner], although it does make it > not crash fatally [locked after crash], albeit with the corrupted text as a > spell replacement. Any other recommended tools? Efence should make your application crash as soon as it accesses memory that it shouldn't access. -- hundred-and-one symptoms of being an internet addict: 169. You hire a housekeeper for your home page. /// 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://www.ICCF.nl ///
Re: suggestions for omni-completion
On Wed, 19 Apr 2006 14:25:42 +0800 Linsong <[EMAIL PROTECTED]> wrote: > Alan Briolat wrote: > > >On Wed, 19 Apr 2006 11:51:31 +0800 > >Linsong <[EMAIL PROTECTED]> wrote: > > > > > > > >>Hi, > >>I have tried the omni competion, it is very cool! > >>But there is still one thing that I think is not very convenient. > >>For example, when I input part of a function name(foobar): > >> foo| (| is the position of the cursor) > >>then I invoke the omnicompletion by pressing , consider > >>the completion list like this: > >> > >> fooblah > >> fooblahblah > >> fooblahblah > >> foobar > >> ... > >> ... > >> > >>then the strings inputed will be replaced by the first matched item(here > >>it is fooblah). If I want to get foobar, I need to press several > >>times. It is not very convenient. > >> > >> I think it would be better like the following: > >> After , the inputed string will not be replaced, only the > >>completion menu shows up, then I can choose the item that I want by > >>pressing ; Or, I can go on to input more characters and the > >>completion menu will update its menu items based on the new input when I > >>input. So the items in completion menu will become less and less and it > >>is easier to select the matched item. Inputing more characters is better > >>than pressing several times. > >> > >> > > > >I *believe* this is the purpose of (someone please correct me > >if I am wrong...) > > > > > Yes, that is just what I mean. I need to go over the online help :) > Do you know how to make it as the default action, that is make > works like ? Well, what I do is map a different key sequence to it. My preference (doesn't work in terminals though) is: :imap There appears to be only one problem with using , which is that it makes omni-complete useless when there is only one match (doesn't replace, and doesn't give a list of options). If someone knows how to overcome this, please let me know :( > > Thanks a lot! > > BR > Vincent > > > > > > >> Hope I have described my idea clearly. In fact, it is not my idea, > >>it is the design of Visual Assistant(visit http://www.wholetomato.com/ > >>for more details, there are some animations ), you can try it if you > >>have a windows box and visual studio installed. > >> > >>BR > >>Vincent > >> > >> > >> > >> > > > > > > > > > -- Alan Briolat <[EMAIL PROTECTED]>http://www.dotphp.org/ Haha, I just wasted 76 bytes of your bandwidth! How does that make you feel?
Re: Coulpe of odd [repeatable] crashes in vim 7
On Wed, 19 Apr 2006 13:07:12 +0200, Bram Moolenaar wrote: > After some pointers go wrong anything can happen, thus how it crashes > exactly is not interesting. It could help to use a library that forbids > access to freed memory, like efence. Then the error is detected much > earlier and a stack trace may provide more useful info. Can Vim be run with Valgrind? -- Giuseppe "Oblomov" Bilotta "I weep for our generation" -- Charlie Brown
Re: Coulpe of odd [repeatable] crashes in vim 7
Around about 19/04/06 12:07, Bram Moolenaar typed ... Apparently your FileChangedRO autocommand does something nasty. I suspect we need to detect that nastyness and disallow it. Any idea what the nasty bit could be? I tried making a cut down fake version, but that always worked. It's essentially doing a couple of system() [vim] calls, one's a 'cat' of a config file, the next is the actual remote sourcesafe checkout command (via rsh), of each of which it parses the output. Then it does a :edit to reload the buffer and a 'syntax on'. ISTRT if I comment out the :syntax on' it stops crashing, but I then get a file with no syntax highlighting (even though it was on before). Maybe that in itself is the issue. After some pointers go wrong anything can happen, thus how it crashes exactly is not interesting. It could help to use a library that forbids access to freed memory, like efence. Then the error is detected much earlier and a stack trace may provide more useful info. ef is not reporting anything [except its banner], although it does make it not crash fatally [locked after crash], albeit with the corrupted text as a spell replacement. Any other recommended tools? -- [EMAIL PROTECTED] ~]# rm -f .signature [EMAIL PROTECTED] ~]# ls -l .signature ls: .signature: No such file or directory [EMAIL PROTECTED] ~]# exit
Re: algorithmic problem when deleting ranges of lines?
Ulrich Lauther wrote: > I observe extremely long respnse times when I try to delete a large > range of lines, say ".,$d" > > I suspect, the following happens: > > The first line of the range (n lines) is deleted, the other lines up to the > end of the buffer (at least n-1) are renumbered. > Then the second line is deleted, the remaining ones are renumbered, and so on. > This gives n**2 complexity. > Deleting the n lines first an renumbering the remaing ones only once would > be much faster. > Am I right? Why do you think this happens? It's probably because the lines are saved for undo. Try setting 'undolevels' to -1 and check the speed then. -- "Hit any key to continue" is a lie. /// 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://www.ICCF.nl ///
Re: Coulpe of odd [repeatable] crashes in vim 7
Neil Bird wrote: > Around about 07/04/06 13:56, Bram Moolenaar typed ... > >>> The check for the current buffer to be locked was a bit too generic. > >>> I'll explicitly allow using ":edit" without an argument. > >>What about :checktime ? Says it's postponed till after the autocmd, so > >> should it be OK too? > > Hmm, it seems so. I'll add an exception for that too. > >Well, I no longer get the two errors about not being able to edit, but I'm > back to crashes :-( [vim 7.0e] > >The original problem (crashing when checking out a file during diff mode > 'dp') seems to have actually been fixed, or, at least, it now hasn't crashed > for me. > >However, the newer instance (a checkout triggered by 'z=' spell checking) > has gotten worse. I get an error (sometmies SEGV, sometimes ABRT) and then > vim hangs: > > *** glibc detected *** free(): invalid next size (fast): 0x09926868 *** > Vim: Caught deadly signal ABRT > Vim: preserving files... Apparently your FileChangedRO autocommand does something nasty. I suspect we need to detect that nastyness and disallow it. Any idea what the nasty bit could be? After some pointers go wrong anything can happen, thus how it crashes exactly is not interesting. It could help to use a library that forbids access to freed memory, like efence. Then the error is detected much earlier and a stack trace may provide more useful info. -- "Hit any key to continue" does _not_ mean you can hit the on/off button! /// 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://www.ICCF.nl ///
algorithmic problem when deleting ranges of lines?
Hi, I observe extremely long respnse times when I try to delete a large range of lines, say ".,$d" I suspect, the following happens: The first line of the range (n lines) is deleted, the other lines up to the end of the buffer (at least n-1) are renumbered. Then the second line is deleted, the remaining ones are renumbered, and so on. This gives n**2 complexity. Deleting the n lines first an renumbering the remaing ones only once would be much faster. Am I right? Kind regards, -ulrich lauther Ulrich Lauther ph: +49 89 636 48834 fx: ... 636 42284 Siemens CT SE 6 Internet: [EMAIL PROTECTED]
Re: Omni-completion fails when the screen space is too small
What is your name???
> The omni-completion feature is good, but it does require a certain
> amount of screen space. This is reasonable. However, it doesn't
> directly refuse to work, and doesn't work properly when lines = 6.
>
> Steps to reproduce:
> 1. Use gvim to open a file named `test.c' and write the following lines:
> void testfunc(void);
> void testfunc2(void);
>
> void testfunc(void)
> {
> }
>
> void testfunc2(void)
> {
> }
> 2. Run `ctags -R .'.
> 3. Execute command `set lines=6'.
> 4. In the body of testfunc, type `test', and then press Ctrl+X, Ctrl+O.
>
> Result:
> Gvim seems to have fallen into an endless loop.
>
> Expected result:
> Gvim refuses to do omni-completion and complain about the available
> screen space.
>
> p.s. During the endless loop, repeatative flashing of the title bar of
> gvim can be observed. However, when I pressed Ctrl+C, it stops
> responding any more.
I see the problem. I'll look into it.
--
hundred-and-one symptoms of being an internet addict:
163. You go outside for the fresh air (at -30 degrees) but open the
window first to hear new mail arrive.
/// 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://www.ICCF.nl ///
Re: Vim 70 and multibyte printing
Valery Kondakoff did utter on 13/04/2006 21:20: Hello, Yegappan! Thursday, April 13, 2006, 10:42:31 PM, you wrote: At least all my experiments were unsuccsessfull. I'm using gVim 7.0d under WinXP SP2. YL> According to version7.txt, multi-byte printing is now supported: YL> Printing multi-byte text *new-print-multi-byte* YL> -- YL> The |:hardcopy| command now supports printing multi-byte characters. YL> The 'printmbcharset' and 'printmbfont' options are used for this. YL> Also see |postscript-cjk-printing|. (Mike Williams) As you can see in my initial message I was trying to play with the new 'printmbcharset' and 'printmbfont' options, but I was unable to force gVim to print the file in correct encoding. So I was asking for some help: if there is some happy gVim 7.0 user, who set 'encoding' to 'utf-8' and still was able to print multibyte text? Can you, please, share your encoding-related settings? The multi-byte printing support was only for PostScript printing from VIM. I don't believe there is support for multi-byte printing using Windows printing yet. The conversion from the buffer encodinf to the print encoding has not yet been added to VIM. Mike -- Taglines temporarily suspended - sorry.
Re: Coulpe of odd [repeatable] crashes in vim 7
Around about 19/04/06 09:38, Neil Bird typed ...
If I come up with any more info., I'll let you know.
OK, spoke too soon, I seem to be able to subtly change the behaviour by
which spell option I select. I'd always been selecting '1', the first, to get
the crashes before; selecting others seems to behave 'better'. I just did 1
again and caught a crash in I think the same place as before (I'll check in a
sec.):
*** glibc detected *** free(): invalid next size (fast): 0x0a5e7368 ***
Program received signal SIGABRT, Aborted.
#0 0xb7f8d402 in __kernel_vsyscall ()
#1 0x009597d5 in raise ()
#2 0x0095b149 in abort ()
#3 0x0098d40a in __libc_message ()
#4 0x00993b3f in _int_free ()
#5 0x00993eba in free ()
#6 0x08127476 in vim_free (x=0xa5e7368) at misc2.c:1463
#7 0x0810edd2 in ml_flush_line (buf=0xa271bd0) at memline.c:3096
#8 0x0810d56c in ml_get_buf (buf=0xa271bd0, lnum=1, will_change=0) at
memline.c:2065
#9 0x080e38f2 in move_lines (frombuf=0xa271bd0, tobuf=0xa590910) at
fileio.c:6139
#10 0x080e421a in buf_reload (buf=0xa271bd0, orig_mode=33133) at fileio.c:6494
#11 0x080e409a in buf_check_timestamp (buf=0xa271bd0, focus=0) at fileio.c:6419
#12 0x080e3831 in check_timestamps (focus=0) at fileio.c:6095
#13 0x080fd5de in main_loop (cmdwin=0, noexmode=0) at main.c:993
#14 0x080fd4cb in main (argc=4, argv=0xbf88cec4) at main.c:930
vim_free(x)
void *x;
{
if (x != NULL && !really_exiting)
{
#ifdef MEM_PROFILE
mem_pre_free(&x);
#endif
free(x);<-- here --|
}
}
x is 0xa5e7368 FWIW.
Would this MEM_PROFILE be of help?
--
[EMAIL PROTECTED] ~]# rm -f .signature
[EMAIL PROTECTED] ~]# ls -l .signature
ls: .signature: No such file or directory
[EMAIL PROTECTED] ~]# exit
Re: Coulpe of odd [repeatable] crashes in vim 7
Around about 07/04/06 13:56, Bram Moolenaar typed ... The check for the current buffer to be locked was a bit too generic. I'll explicitly allow using ":edit" without an argument. What about :checktime ? Says it's postponed till after the autocmd, so should it be OK too? Hmm, it seems so. I'll add an exception for that too. Well, I no longer get the two errors about not being able to edit, but I'm back to crashes :-( [vim 7.0e] The original problem (crashing when checking out a file during diff mode 'dp') seems to have actually been fixed, or, at least, it now hasn't crashed for me. However, the newer instance (a checkout triggered by 'z=' spell checking) has gotten worse. I get an error (sometmies SEGV, sometimes ABRT) and then vim hangs: *** glibc detected *** free(): invalid next size (fast): 0x09926868 *** Vim: Caught deadly signal ABRT Vim: preserving files... ^C doesn't get out of that, I have to 'kill -9' it. Annoyingly, it doesn't crash (per se) running under ddd. I did once get: E341: Internal error: lalloc(0, ) ... but it seemed to recover. It /does/, however, insert a smattering of random text instead of the selected word (from z=), seemingly as small bit of the current file, only a few characters [but not the same length as the spell word]. This is better for me, as it was the diff mode thing I was hitting a lot, and I can avoid the spelling one, but it's still worrying ... If I come up with any more info., I'll let you know. -- [EMAIL PROTECTED] ~]# rm -f .signature [EMAIL PROTECTED] ~]# ls -l .signature ls: .signature: No such file or directory [EMAIL PROTECTED] ~]# exit
