Re: 'fileencodings': Why use ucs-2le for cp936 file?
"A.J.Mechelynck" <[EMAIL PROTECTED]> 写于 2007-06-06 10:30:54: > > 1. will vim write BOM when writing to unicode files? or is there any > > options for that? > >:setlocal bomb > > When opening a Unicode file, Vim will set or clear the buffer-local 'bomb' > option according to the presence or absence of a BOM. That option is > irrelevant for non-Unicode files. You can also set or clear it manually. When > creating a new Unicode file from scratch, a BOM will be set, or not,depending > on the corresponding global setting, so if you want your new Unicode files to > be created with a BOM, you may add > >:setglobal bomb > > to your vimrc. Thanks, it seems that BOM is not written by default and can be set only globally for all unicode encoding. But the problem is: my gcc 4.0 will complain about BOM for utf-8 source file, while ucs-2le must have a BOM so that vim can recognize it without adding the ucs-2le in fencs (ucs-2le should never be added into fencs though, since most characters in cpxxx are valid and it is likely to mess things up). Is there anyway to do BOM setting only for particular unicode encoding like the following? when write utf-8 files, do not write the BOM. when write ucs-2 files, write the BOM. (it should happen even if the file opend as utf-8 then :set fenc=ucs-2le and then :write) -- Sincerely, Pan, Shi Zhu. ext: 2606
Re: 'fileencodings': Why use ucs-2le for cp936 file?
"A.J.Mechelynck" <[EMAIL PROTECTED]> 写于 2007-06-06 09:51:51: > Unicode files may or may not have a BOM, depending on who (or which program) > created them and where they come from. If you remove "ucs-2le" from your > 'fileencodings', but leave "ucs-bom" at the start, any Unicode fileshaving a > BOM will still be recognised and the proper encoding set. > > > Best regards, > Tony. It seems that ucs-2le files with BOM will get recongized now. But I've got some other question: 1. will vim write BOM when writing to unicode files? or is there any options for that? 2. what is the correct way of converting a file encoding inside vim? I opened a file with cp936 encoding, then :set fenc=ucs-2le, then :w newfile.txt, close the vim and open the newfile.txt with a new vim, then I found everything in a mess. (gvim 7.1 winxp) -- Sincerely, Pan, Shi Zhu. ext: 2606
'fileencodings': Why use ucs-2le for cp936 file?
Hello, Recently I want to do some research about 'fileencodings', what I want is to recognize utf-8, ucs-2le, euc-cn and cp936 encodings. So I set the 'fencs' in my .vimrc: set fencs=ucs-bom,utf-8,ucs-2le,euc-cn,cp936 However, cp936 files are always recognized as ucs-2le and I got everything in a mess... If I remove the ucs-2le: set fencs=ucs-bom,utf-8,euc-cn,cp936 That would work, but ucs-2le files cannot get recognized at all. It is said that unicode files all have BOM, and obviously cp936 files do not have BOM, so I wonder why cp936 files get recognized as ucs-2le file without any BOM. I tried to change my 'encoding' setting, but it doesn't affect anything. Any hints? -- Sincerely, Pan, Shi Zhu. ext: 2606
RE: how to ..... compiler
"Jagpreet" <[EMAIL PROTECTED]> 写于 2007-06-04 15:46:54: > But again not much details mentioned in the doc file(csupport.txt) about > external make. To use the external make, just :set makeprg=make then you can use :make to call external make. > How can I run my makefile(external) within vim. Further How to check and add > ,if missing, compiler support in vim( say HP-UX xompiler aCC). if you want to open the error list, use :copen please see :help makeprg for more details > I'm using Console version of vim via putty. IMO console version works better than gui version, HTH. -- Sincerely, Pan, Shi Zhu. ext: 2606
Re: running vim on cygwin
Gary Johnson <[EMAIL PROTECTED]> 写于 2007-06-04 13:32:36: > If that's really the problem, all you have to do is install the > libncurses-devel package before running 'configure'. You certainly > can use the Cygwin source package, but it's not necessary. > > HTH, > Gary Probably you are right, installing cygwin source package or binary package will automatically install the required dependencies... and the dependencies might be a reason. -- Sincerely, Pan, Shi Zhu. ext: 2606
Re: running vim on cygwin
Kamaraju Kusumanchi <[EMAIL PROTECTED]> 写于 2007-06-04 11:56:39: > Hi > > I installed vim 7.1 via cygwin on Windows XP machine. However, > when I run vim on the bash shell of cygwin, I am getting the following error. > > E558: Terminal entry not found in terminfo > 'cygwin' not known. Available builtin terminals are: Generally, this will occur if you download vim source from vim "official" site and compile under cygwin by yourself. Use the version comes from cygwin will solve the problem. you can use the pre-compiled binary included in cygwin, or use the source package in cygwin. If you want to do it manually, just compare the cygwin vim-source to the official version. you will see the difference. -- Sincerely, Pan, Shi Zhu. ext: 2606
Re: OT: Vi in a browser...
"Edward L. Fox" <[EMAIL PROTECTED]> 写于 2007-06-04 10:38:30: > Hi Pan, > On 6/4/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > > [...] > > When this is just a pain, why not just map ^A to your 1GVG ? > > > > Well, personally I think the thing you should do is getting familiar > with Vi-like editing styles, not mapping Vim to adapter your existing > editing styles. This is just an example, since the "Gene Kwiecinski" feels selete all a pain. You may say he should not use "select-all", but it is very likely that the similar senaro occurs for other keystrokes. I had many other examples for that. > but to me, combination keys with Ctrl is much more > difficult to press than combination keys with Shift only. Your mind may vary, but I feel no difference between press Shift, Alt and Ctrl. I feel better only when I don't have to press any "chord" keys like "ctrl,alt,shift" at all. So what I had do is: nnoremap ; : With this map, I will not have to press the "Shift+:" to enter command-mode, just the ";", and this saves me "thousands of keystrokes" and I can use vim at least 30% faster. You may say: "you should not use semicolon for entering command-mode, you should follow the vi-way to entering command-mode by shift-colon." But frankly speaking I don't think there's any sensible reason not using semicolon as the shortcut of entering command-mode. In this case, following the vi rule has no advantage and use shift-colon is solely inefficient. Everyone may have a completely different set of preferences on using vim, since vim is designed to be a fullly-cumstomizable editor, if the user-preferences such as .vimrc and plugins and color-schemes are not loaded, chances are that the re-invented vi-clone inside browser has few supporters. -- Sincerely, Pan, Shi Zhu. ext: 2606
RE: OT: Vi in a browser...
"Gene Kwiecinski" <[EMAIL PROTECTED]> 写于 2007-06-02 00:01:21: > >Personally, I don't agree with you. When editing short text > >items on web pages, I feel that the overhead of copying/pasting > >back and forth from vim is too much. I am currently using the > > Speaking of which, is there any quicker way to visually select the > entire file, analogous to ^A in other systems? I have to essentially do > >1GVG > > to stick everything into the scratchpad/clipboard/whatever to dump it > back into the item from whence it originally came, and that's just a > pain. Well, not so much a pain as an annoying itch I can't quite reach. When this is just a pain, why not just map ^A to your 1GVG ? So this come back to the topic: If anyone approaching to emulate vim in a browser without actually calling vim, will it reads your .vimrc and to know you had mapped ^A to 1GVG ? unlikely. Then I don't think it makes too much sense reinventing a vi-like inside javascript. ―― After all, javascript *is* slow and I cannot afford to pay the overhead in any serious application. In most web-sites, disabling javascript is just something like upgrade my CPU from P4 to Core 2 Duo. -- Sincerely, Pan, Shi Zhu. ext: 2606
Re: plugins in vim 7.1
"Tushar Desai" <[EMAIL PROTECTED]> 写于 2007-05-31 13:51:28: > I recently upgraded from vim 7.0 to vim 7.1 (on ubuntu feisty) by > compiling the vim7.1 tarball. Did you "make install" from the tarball? If compiled from tarball, the prefix defaults to /usr/local, while the ubuntu official version will be in /usr > > The plugins are located at /usr/local/share/vim/vim71/plugins. This is not the right place to place your plugins, a better approach is to put it into your ~/.vim/plugins HTH. -- Sincerely, Pan, Shi Zhu. ext: 2606
Re: Is there a "xml formatter"?
wangxu <[EMAIL PROTECTED]> 写于 2007-05-31 01:17:41: > I want to have this function: > formatting my xml file automatically. > or,indent xml element and attributes. > > is there any plugin like this? > thanks! > did you set autoindent ? provide that there's $VIMRUNTIME/indent/xml.vim it should do automatic indent well. Or just try gg=G after you had opened your xml file. -- Sincerely, Pan, Shi Zhu. ext: 2606
Re: Why bottom-posting is prefered on Vim Mainling List?
Friedrich Strohmaier <[EMAIL PROTECTED]> 写于 2007-05-30 07:00:11: > btw. I join the voices that price the nice way people are discussing > even that (off-)topic on this list. Vimmers seem to be a special kind of > civilized people. :o)) > I think I could got some idea now: A mailing list is a list, where everyone could see all posts. So it is a good practise for trim, because those who want to see the original could go to the original message to check. That said, bottom-post messages has to be trimmed to retain a good view, so one often need to close the current message and find the orignal message in order to see what the thread is about. This is okay for a mailling list since everyone could see all posts, and bottom-post saves band-width. Office e-mail is very different: consider the e-mail may be replied several times and the fourth person decides to forward the e-mail to executive, he should include everything in it since the executive had not received the original message at all. This is the rule inside my company: e-mail should NEVER be trimmed unless we have a very good reason to omit or hide the trimmed part, interlined reply is not recommended in my office. So the quoted message might be very long, and top-posting is best for this case. Please do not blame Microsoft about the default-top-posting, Microsoft design software for money and for commercial use, the commercial may think top-posting easier to read and band-width is usually not a concern inside a company intranet. Okay, now I think its time to let new vim@vim.org subscribers know that bottom posting is prefered on Vim Mailing List. Will every new subscribers receive an e-mail when subscribe to vim list? is it possible to indicate the bottom-posting preference inside the welcoming e-mail? -- Sincerely, Pan, Shi Zhu. ext: 2606
Re: Why bottom-posting is prefered on Vim Mainling List?
Matthew Winn <[EMAIL PROTECTED]> 写于 2007-05-29 16:10:57: > > Write top-post or bottom-post makes no difference for me, the problem is > > that I found bottom-post is harder to read since I will have to skim all > > "original messages" before I could read the actual reply. > > If you have to skim a lot of text then you should be complaining about > people not trimming. If someone bottom-posts, leaves pages of lines > before their own message, and those lines are not necessary in order > to establish the context of their reply, then they're not trimming > properly. This get to my point: is it possible to ask EVERYONE to trim correctly? unlikely. See, though I always do trim, I still suffered from those who do not trim and use bottom-posting. If those who do not trim use top-posting, I'll not suffered from the poor trim, and I can do trim myself when I reply the message. > > Well, since no one could convice another, I'll stick to the "community > > rule". > That's the wrong attitude. This is the Internet. You're supposed to > insist that you know better than everyone else even if they've been > using the Internet for decades, and you have loads of lurkers who > support your point of view but they're all too scared of The Clique > to speak up, and when you're in charge you'll Show Us All. I feel you're talking friendly and for good. But due to my poor English proficiency I don't seem to catch what you said. The "community rule" in vim ML is to do bottom-posting, so I stick to the rule even if I don't accept it. What do you meant by "wrong attitude"? Do you mean I should insist my top-posting when I think it is right? PS: This Off-topic thread has been talked long and I'm sorry to bring excess load to vim mailing list, please mail directly to me if any vimmer friends wants to talk futher about it. Thanks. -- Sincerely, Pan, Shi Zhu. ext: 2606
Re: Why bottom-posting is prefered on Vim Mainling List?
Steve Hall <[EMAIL PROTECTED]> 写于 2007-05-29 12:19:43: > You could say that top posting is easier to write, but bottom posting > is easier to read. The extra effort of one poster saves all the > readers the same amount of effort. For a group, bottom posting keeps > everyone on track. And if done well, individual posts can stand alone > in an archive without a peruser having to go paging through a whole > thread. > Hi, It seems that top-posters and bottom-posters belongs to different party and no one can convice another. An explaination why top-post is easier to read: When I am viewing an e-mail, the reply is the main part of the message and I usually quite aware of what the original post is. So I should be able to see the reply when I open the message. If the message is bottom post, I will have to scroll down and down to find where the author really start to say something. If the reply starts on line 1000 while the messages ends on line 2000 it will be quite difficult to know line 1000 is the start of reply and I should read from that line. While for the top-post, I know the first line is the start of reply and I can read the reply without any difficulty. In an active forum, threads grown long quickly, with top-post, we focus on what the message saids and waste no time. Write top-post or bottom-post makes no difference for me, the problem is that I found bottom-post is harder to read since I will have to skim all "original messages" before I could read the actual reply. Well, since no one could convice another, I'll stick to the "community rule". -- Sincerely, Pan, Shi Zhu. ext: 2606
Why bottom-posting is prefered on Vim Mainling List?
Hi vimmers: Slightly Off-topic, but I'm still wondering why bottom-posting is prefered on Vim Mainling List. As far as I know, most e-mail clients defaults to top-posting (i.e. replied message shows before the original message), and I personally feel top-posting much much easier to read than bottom-posting. Is there any point (or historic reason) choosing bottom-post ? -- Sincerely, Pan, Shi Zhu. ext: 2606
Re: A performance question
"Yongwei Wu" <[EMAIL PROTECTED]> 写于 2007-05-24 11:28:06: > Who really want to edit TEXT files as large as that? I cannot think of > scenarios other than log files. Maybe Vim does not fit in this role. > > Best regards, > > Yongwei > -- Yes it fits in this role, and frankly speaking this was the reason I first choose Vim. (tail -h might be better for that, but if we want to do search, we may have to use vi.) Six years ago I often need to check the logs in the servers of my company (those are generally HP, DEC and IBM minicomputers with different Unixes without vim installed), we got more than 30 servers like that and the file is usually 2GB to 11GB. I open the log file in plain vi and it takes way too long to open. One day I happened to compile and installed Vim (it was 5.x or 6.x) on one of the servers, and found that the Vim opens those file about 10 to 20 times faster than the plain Vi, then I installed Vim on all of our servers and feel that Vim greatly speeds my work. After that I begin to learn Vim. So you see, if Vim could not handle Big text files, I would not have know and using vim now. Vim5 and Vim6 opens big file fast, if anyone opens 3GB text file for more than 60 seconds, I'll doubt if this is an issue of Vim7 or something wrong with his own configuration. -- Sincerely, Pan, Shi Zhu. ext: 2606
Re: A performance question
Charles E Campbell Jr <[EMAIL PROTECTED]> 写于 2007-05-23 21:38:27: > Sounds like the filesize is getting stored in a 32bit signed number, and > overflowing. > Is the negative number -1 (that would mean "file can't be found")? If > not, then perhaps > that fact could be used to "extend" the LargeFile's ability to catch > large files: trigger > when getfsize() returns a number < -1. Please let me know what > getfsize() is actually > returning when applied to that 3GB file. > > Regards, > Chip Campbell > Yes the getfsize() does return <-1 when filesize between 2G and 4G. But if the filesize is 4G to 6G, this may not work. Anyway, trigger when getfsize returns a number < -1 does help in 50% cases. It can't be wrong, so please just do it. -- Sincerely, Pan, Shi Zhu. ext: 2606
Re: A performance question
"John Beckett" <[EMAIL PROTECTED]> 写于 2007-05-23 19:32:25: > On many systems, the calculation could use 64-bit integers. > > John Yes, but on all systems, vim script could not take 64-bit integers: see eval.txt line 38: 1.1 Variable types ~ *E712* There are five types of variables: NumberA 32 bit signed number. Examples: -123 0x10 0177 The only integer which supported by vim script is 32-bit signed. So even if you can get 64-bit file size, you cannot save it in any variables in vim script. -- Sincerely, Pan, Shi Zhu. ext: 2606
Re: A performance question
"John Beckett" <[EMAIL PROTECTED]> 写于 2007-05-23 18:39:22: > The result was really ugly. The script failed to notice that 3GB > was large because the Vim function getfsize(f) returned a > negative number. > > I haven't checked getfsize() on 32-bit Linux yet, nor am I > sufficiently patient to try opening the 3GB file with Vim 7.1. > > John As far as I know, Windows does not support files larger than 4GB. So its okay to use unsigned 32-bit for filesize in windows. It is not that 32bit isn't enough, but the fsize should be *unsigned*. The problem is that vim script can use only *signed* 32-bit int as internel type, so there might be improvement of vim script engine ―― instead of get the 64-bit file size. -- Sincerely, Pan, Shi Zhu. ext: 2606
Re: Vim to Vi (Was: weird defaults in Feisty)
Micah Cowan <[EMAIL PROTECTED]> 写于 2007-05-23 09:11:54: > [EMAIL PROTECTED] wrote: > > All you need to do is to: sudo apt-get install vim-gtk, which installs a > > Big version of vim, and the vim will be replaced with that version. > > Well... not replaced. They will both be installed. You'll probably need > to run update-alternatives to ensure that /usr/bin/vim points at the one > you want. > > -- It doesn't really matter if it is replaced or both be installed. What I care is: when I installed a fresh version of Ubuntu Feisty, type vi, I got the Tiny version. After I apt-get installed the vim-gtk, then I type vi, I got the Big version. So, you see, vi is "replaced" from Tiny version to Big version, that's what I had observed. -- Sincerely, Pan, Shi Zhu. ext: 2606
Re: A performance question
AFAIK Vim 7 has a different way of handling undo levels. Have you tried with Vim 6 instead? I had used Vim 6 to edit a text file (3Gbytes) and do things within seconds. -- Sincerely, Pan, Shi Zhu. ext: 2606 Robert Maxwell Robinson <[EMAIL PROTECTED]> 写于 2007-05-23 05:59:20: > > ":set undolevels=-1" caused my test to run in less than 15 sec, with no > other options fiddled with. Thanks Tim, now I have a work-around! > > Now, does having the undo facility available _necessarily_ mean deleting a > large chunk of a file takes so long, or can that be added to the list of > desired performance enhancements? > > Max > > On Tue, 22 May 2007, Tim Chase wrote: > > > The issue of editing large files comes up occasionally. A few settings can > > be tweaked to vastly improve performance. Notably, the 'undolevels' > > setting can be reduced to -1 or 0 for improved performance. If your lines > > are long, it can also help to disable syntax highlighting as well. You can > > drop in on one such thread here: > >
Re: Vim to Vi (Was: weird defaults in Feisty)
fREW <[EMAIL PROTECTED]> 写于 2007-05-23 08:15:55: > Yeah, the really big problem is that the guy I am working with who I > am helping admin a few servers is at exactly step 1. In fact, it > wasn't until recently that he figured out (I told him) that Ctrl-Z is > not the same as :q!. And like you said, we upgraded and he was just > like, "vi got totally weird and now I use nano!" But after having > explained to him a couple things that might help him out (r for > replacing single characters and whatnot) I think he might start the > path to enlightenment ;-) > > -fREW It seems nature to have vim behave like vi, if the Linux distribution choose to do so. The distribution decides everything and it is non-related to vim developers themselves. All you need to do is to: sudo apt-get install vim-gtk, which installs a Big version of vim, and the vim will be replaced with that version. I don't see any problem now, in Feisty, I just run "vi" and everything is okay, I do *never* use command "vim" to run vim, runing vim with the command "vi" feels much better for me. Anyway, I don't think any experienced vim users will still think he need a plain "vi" after he had get used to "vim". So it is wield for me to have two different versions of vim on my single computer. -- Sincerely, Pan, Shi Zhu. ext: 2606
Re: C-X C-F completion and paths with spaces
"Yakov Lerner" <[EMAIL PROTECTED]> 写于 2007-05-21 05:50:03: > On 5/20/07, Matthew Winn <[EMAIL PROTECTED]> wrote: > > I can't begin to imagine why Microsoft thought it would be > > a good idea to put spaces in the names of system directories > > I have two theories about this. > 1) MS lifted the idea from Macintosh > 2) MS, long humiliated by inferiority complex of the 8+3 FAT16 filenames, > did it to subvert the idea of unix shell scripting powers. To create, > that is, the > files that break unix shell scripts (remember samba ? ). > > Yakov Interesting, it is said that MS uses '\' in paths (such as c:\foo\bar\) just to conteract the unix '/'. However, '\' in paths is very inconvenient in C programming so they use '/' in Windows internels. It is very likely that M$ set this just to "baffle" users. So my choice is just "never use filenames with spaces", Since I never put anything important into "Document and Settings" -- Sincerely, Pan, Shi Zhu. ext: 2606
Re: Vim71: undocumented change for netrw plugin.
Charles E Campbell Jr <[EMAIL PROTECTED]> 写于 2007-05-18 23:23:23: > That's an awful lot of text just to mention that there's an omission > from the help! > > > Regards, > Chip Campbell > Sorry I think I'm a bit nervous recently and it often takes several paragraphs to express my single idea, I'm going to see a doctor about this. (really, I mean it, it's my problem since ten years before) ;-) -- Sincerely, Pan, Shi Zhu. ext: 2606
Re: repeating up/down/delete commands
"A.J.Mechelynck" <[EMAIL PROTECTED]> 写于 2007-05-19 15:42:15: > This is true, but rather than an empty vimrc I suggest the following: > > runtime vimrc_example.vim > " if and when we want to further customize Vim, we'll add more lines below > Best regards, > Tony. > -- I always recommend include the contents of vimrc_example.vim instead of just source the file by :runtime. By including the contents of vimrc_example.vim we know all it has done and we can change it anyway. i.e. chang the .vimrc is a good way, changing the $VIMRUNTIME/vimrc_example.vim is NOT a good pratice. (vimrc_example fits the need of the author but it definetely do not fit everyone, so I suggest most users to change it and create their own .vimrc.) The second reason: vimrc_example.vim comes from the distribution and it may change, when it change it may silently break our existing scripts or configurations. include the contents into our .vimrc minimize the incompatible changes. So the better practise to create a new .vimrc may be: just copy the vimrc_example.vim to ~/.vimrc -- Sincerely, Pan, Shi Zhu. ext: 2606
Vim71: undocumented change for netrw plugin.
Hello vimmers: I am one of the users who want the default file explorer to be explorer.vim in Vim 6.x rather than netrw. And from line 78 of pi_netrw.txt I got the following: > You can avoid loading this plugin by setting the "loaded_netrw" variable > in your <.vimrc> file: > > :let loaded_netrw = 1 In Vim 7.0, this works, I add the above into .vimrc and put the explorer.vim of Vim 6.4 into ~/.vim/plugin and then :Explore launchs the old explorer instead. However, in Vim 7.1 this does not work, when I run :Explore it reports netrw#Explore not found. My explorer.vim does not launch. Done some research and I found that the $VIMRUNTIME/plugin/netrwPlugin.vim now use the loaded_netrwPlugin variable. So I should use the following in my .vimrc to effectively disable the netrw plugin: :let loaded_netrw = 1 :let loaded_netrwPlugin = 1 I don't want to argue now that netrw should be a new plugin instead of replace the existing explorer.vim. But if the new version of netrwPlugin in Vim 7.1 silently breaks the explorer.vim, should it be documented? My point is : The following should be added to line 81 of pi_netrw.txt version 2007 May 08. :let loaded_netrwPlugin = 1 If DrChip thinks the document should not change, then the netrwPlugin might have to be changed to still recognize the "loaded_netrw" variable. HTH -- Sincerely, Pan, Shi Zhu. ext: 2606
Re: Identify this Vim font for me, please
"A.J.Mechelynck" <[EMAIL PROTECTED]> 写于 2007-05-17 09:19:03: > I don't think that font is available on Motorola Macs (including Power PCs). > It may or may not be available in Intel Macs but I don't know how to get at > it. Maybe the same way on OS X as on Linux above, I'm not sure. > Best regards, > Tony. > -- I can confirm that intel-based Macs had this in full-screen text console. I can do this by boot MS-DOS or most flavors of Linux LiveCD on an intel-based Mac. -- Sincerely, Pan, Shi Zhu. ext: 2606
Re: Vim71: breaking change not mentioned in the document.
Gary Johnson <[EMAIL PROTECTED]> 写于 2007-05-17 00:35:42: > On 2007-05-16, [EMAIL PROTECTED] wrote: > > Gary Johnson <[EMAIL PROTECTED]> 2007-05-16 16:41:22: > > > On 2007-05-16, [EMAIL PROTECTED] wrote: > > > > Hi, vimmers: > > > > > > > > The line 1230 of editing.txt said: > > > > > > > > To change to the directory of the current file: > > > > :cd %:h > > > > > I don't think disabling E500 would help. The text of E500 is, > "E500: Evaluates to an empty string". That's warning you that there > is no head component of the file name. If you disabled the error, > and presumably allowed %:h to return an empty string, then your ":cd > %:h" command would be executing just ":cd", which on a Unix system > changes to the home directory--not what you want. > > Another way to fix your mapping would be to use > >:silent! cd %:h > > which allows the cd to fail silently. > > Regards, > Gary > > -- You certainly are right, disabling E500 would not help. However: > The line 1230 of editing.txt said: > > To change to the directory of the current file: > :cd %:h If I was tell that a script could change to the directory of the current file, I would think that it will always change to the directory of the current file, and it is absurd to see it will give an error when the pwd is already the directory of the current file. I'm sure most average users will take it for granted if the document says this. and they will not think the E500 is reasonable here. The document is aprently misleading. So, if :cd %:h must give E500 here, I think the document should change it to :cd %:p:h -- Sincerely, Pan, Shi Zhu. ext: 2606
Re: Vim71: breaking change not mentioned in the document.
Gary Johnson <[EMAIL PROTECTED]> 写于 2007-05-16 16:41:22: > On 2007-05-16, [EMAIL PROTECTED] wrote: > > Hi, vimmers: > > > > The line 1230 of editing.txt said: > > > > To change to the directory of the current file: > > :cd %:h > > > > This works for Vim 7.0 and before, but not for Vim 7.1. In Vim 7.1 when the > > pwd is the same as the directory of current file, the command will fail > > with E500. The failure will break the execution of a mapping, if one have a > > mapping to do :cd %:h and then continue to do something else. > > > > To reproduce the error, just at anytime, run :cd %:h twice. (I've got > > Windows gvim7.1.1, cygwin console vim 7.1.1) > > I would expect ":cd %:h" to give an error the second time it is > executed. Just to be sure, I repeated your experiment on 7.1, 7.0 > and 6.4 on Unix and 7.0 on Windows. I always got E500. Are you > sure that it "works" for you for Vim 7.0? Positive, I've got a mapping which do :cd %:h then :grep, this mapping works since Vim 6.3, 6.4 and 7.0, this is the mapping I used "Everyday" and I cannot use Vim without it, then suddenly it breaks after I installed Vim 7.1. Now I changed :cd %:h to :cd %:p:h and everything works. Anyway, I think there should be an option to disable E500, or "catch and throw". This is the Unix trend: if the caller feel necessary, a program should fail silently in order not to break a script.
Vim71: breaking change not mentioned in the document.
Hi, vimmers: The line 1230 of editing.txt said: To change to the directory of the current file: :cd %:h This works for Vim 7.0 and before, but not for Vim 7.1. In Vim 7.1 when the pwd is the same as the directory of current file, the command will fail with E500. The failure will break the execution of a mapping, if one have a mapping to do :cd %:h and then continue to do something else. To reproduce the error, just at anytime, run :cd %:h twice. (I've got Windows gvim7.1.1, cygwin console vim 7.1.1) So there's at least two issues IMHO: 1. the line 1230 of editing.txt should be changed to :cd %:p:h 2. somewhere in the document should mention: if we had used :cd %:h in our mappings or scripts, we should change them into %:p:h after upgraded to vim 7.1. Or did I missed anything? -- Sincerely, Pan, Shi Zhu. ext: 2606
Re: compiling vim7.1 (huge version) gets build with normal version
[EMAIL PROTECTED] 写于 2007-05-15 14:51:43: > Thanks Pan. Now it does say "Huge Version". But I'm seeing couple of > problems ... > > 1. It still doesn't show the menu's and toolbars. > 2. It tries to use my $HOME/.gvimrc (which works fine with the ubuntu > installed vim7.0) and complains that it can't find > /usr/local/share/vim/syntax/syntax.vim (It also can't find the > colorscheme that I've defined in my .gvimrc). On my system there is a > syntax.vim at /usr/share/vim/vim70/syntax/syntax.vim. > > The src/Makefile has make variables for defining locations; but I'm > not sure how to set them, if I want them to refer to the tar-ball > based dir tree. > > BTW, if I try to compile vim7.0 from the tar-ball, I get the same results. > > I'd like vim7.1 to first use the syntax.vim that came packaged with > the tar-ball (and is at $HOME/vim/vim71/runtime/syntax/syntax.vim. If > it works fine, I'd only then want to install it on my system. > > regards, > -tushar. 1. try see :version and can you find +menu? use :set go+=m to show the menu bar is its not present. 2. edit your Makefile and find the similar: #CONF_ARGS = --exec-prefix=/usr uncomment the line which set the prefix, then you got the prefix set to /usr instead of /usr/local. HTH. -- Sincerely, Pan, Shi Zhu. ext: 2606
Re: compiling vim7.1 (huge version) gets build with normal version
[EMAIL PROTECTED] 写于 2007-05-15 13:30:28: > I recently did a clean install of Ubuntu 7.04 and also installed all > vim related packages. That got me a gui version of vim (7.0.164/Big > compiled on 2007/03/11). > > I now want to compile and install the gui version of vim 7.1. So, I > downloaded the tar-ball for the 7.1 sources to my home dir > ($HOME/vim), untarred at ($HOME)/vim/vim71, enabled "CONF_OPT_FEAT = > --with-features=huge" in the src/Makefile. I also did "apt-get > build-dep vim" and finally ./configure followed by make (in > $HOME/vim/vim71). > > However, I'm ending up with the "Normal version" of vim and although > "vim -g" pops up a window, it doesn't show the menu and the toolbar. > > I tried the same on Fedora Core 6 and got the same results. I tried > vim7.0 on ubuntu and have the same situation. Strangely enough, I was > previously able to compile vim7.0 on my Fedora Core 6 box and it gave > the menu and toolbar. (I don't know what I did right in that case.). > > Any idea what I could be happening here? > > Thanks, > Tushar. AFAIK, Compiling vim is something different from other GNU sources. If you had manually edited the Makefile, you should not run ./configure. get a clean source and skip the ./configure step, try again, you will get the result. -- Sincerely, Pan, Shi Zhu. ext: 2606
Re: taglist plugin launch ctags fail in gvim windows.
"Yegappan Lakshmanan" <[EMAIL PROTECTED]> 写于 2007-05-14 22:52:58: > Hi, > > On 5/13/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > > > > "A.J.Mechelynck" <[EMAIL PROTECTED]> 写于 2007-05-14 > > 13:21:47: > > > >> If your shell is cmd.exe, "/usr/bin/ctags" will give "Unknown command > > or > > > > file > > > >> name". If you want to mix Dos shells and cygwin utilities, you will > > have > > > > to > > > >> juggle with the path formats: see "man cygpath" from within cygwin. > > > >> > > > >> > > > >> Best regards, > > > >> Tony. > > > >> -- > > > > > > > > My shell is c:/cygwin/bin/bash, since I do not want to mix dos shells > > with > > > > cygwin utilities. (I don't use any DOS utilities at all.) > > > > > > > > I had tried to replace the content of /usr/bin/ctags with something > > else, > > > > which proves that the ctags does get executed. Cygpath is not the issue > > > > here. > > > > > > > > -- > > > > Sincerely, Pan, Shi Zhu. ext: 2606 > > > > > > > > > > > > > > If your shell is bash and your ctags a cygwin version, you shouldn't pass > > > > > \"D:/panshizhu/blabla.cpp\" to the latter nor >D:/temp/VIo74.tmp to the > > > former. You may pass either /cygdrive/d/panshizu/blabla.cpp > > > >/cygdrive/d/temp/VIo74.tmp, or (IIUC) `cygpath -u > > D:\\panshizu\\blabla.cpp` > > > >`cygpath -u D:\\temp\\VI074.tmp` > > > > > > > > > Best regards, > > > Tony. > > > -- > > > > It does not matter, cygwin handles both POSIX path and windows paths with > > '/'s. > > > > In cygwin bash shell, paths like d:/foo/bar can be used instead of `cygpath > > -u d:\\foo\\bar` and it works better IMO. What is more, this kind of > > usage are generated by taglist.vim, the taglist script author has test that > > usage under cygwin and it works that way. > > > > That said, I had configured them right last year, but during the last year > > I upgraded my windows, cygwin, vim and taglist plugin, I now do not know > > where the problem is. (I use OSX and Linux at the same time, so it is > > normal that I had not use my WindowsXP for a long time) > > > > Note: my notebook uses the same configuration as my desktop, my notebook is > > still working that way (cygwin bash + ctags + windows gvim + windows path > > with '/' instead of '\\'), only my desktop has the issue. > > > > The exuberant ctags utility invokes the sort utility to sort the generated > output. Do you have cygwin version of sort installed on your system? > Can you check whether your notebook has cygwin sort installed? > > Exuberant ctags can use either external or internal sort depending on > the build time configuration. > > - Yegappan Great, the problem comes from WindowsXP itself, it has c:\windows\system32\sort.exe, which shows in the path before c:\cygwin\bin\sort.exe, I think I would change the PATH setting to make c:\cywin\bin apperas before c:\windows\system32, Or I should rebuild my ctags to do internal sort. It may be good to indicate this in the document of taglist. -- Sincerely, Pan, Shi Zhu. ext: 2606
Re: Project specific settings
"Marius Roets" <[EMAIL PROTECTED]> 写于 2007-05-14 16:05:14: > Hi All, > I know this has been covered before, but I can't seem to find it by > searching Vim tips, so please excuse me if this has been ask many times > before. > > I always uses spaces to indent my code, but a current project requires > me to use tabs. How could I make this setting only be in effect for this > one project, assuming that the project will always be a in a specific > directory. > > Thanks > Marius You can define autocommands to *, and check the full path of file name, then set or unset the expandtab option. If you want to edit with spaces while save file with tabs, then just create an event to do retab before saving the file (check the full path first). :h autocmd-define :h autocmd-events -- Sincerely, Pan, Shi Zhu. ext: 2606
Re: taglist plugin launch ctags fail in gvim windows.
"A.J.Mechelynck" <[EMAIL PROTECTED]> 写于 2007-05-14 13:45:24: > [EMAIL PROTECTED] wrote: > > "A.J.Mechelynck" <[EMAIL PROTECTED]> 写于 2007-05-14 13:21:47: > >> If your shell is cmd.exe, "/usr/bin/ctags" will give "Unknown command or > > file > >> name". If you want to mix Dos shells and cygwin utilities, you will have > > to > >> juggle with the path formats: see "man cygpath" from within cygwin. > >> > >> > >> Best regards, > >> Tony. > >> -- > > > > My shell is c:/cygwin/bin/bash, since I do not want to mix dos shells with > > cygwin utilities. (I don't use any DOS utilities at all.) > > > > I had tried to replace the content of /usr/bin/ctags with something else, > > which proves that the ctags does get executed. Cygpath is not the issue > > here. > > > > -- > > Sincerely, Pan, Shi Zhu. ext: 2606 > > > > > > If your shell is bash and your ctags a cygwin version, you shouldn't pass > \"D:/panshizhu/blabla.cpp\" to the latter nor >D:/temp/VIo74.tmp to the > former. You may pass either /cygdrive/d/panshizu/blabla.cpp > >/cygdrive/d/temp/VIo74.tmp, or (IIUC) `cygpath -u D:\\panshizu\\blabla.cpp` > >`cygpath -u D:\\temp\\VI074.tmp` > > > Best regards, > Tony. > -- It does not matter, cygwin handles both POSIX path and windows paths with '/'s. In cygwin bash shell, paths like d:/foo/bar can be used instead of `cygpath -u d:\\foo\\bar` and it works better IMO. What is more, this kind of usage are generated by taglist.vim, the taglist script author has test that usage under cygwin and it works that way. That said, I had configured them right last year, but during the last year I upgraded my windows, cygwin, vim and taglist plugin, I now do not know where the problem is. (I use OSX and Linux at the same time, so it is normal that I had not use my WindowsXP for a long time) Note: my notebook uses the same configuration as my desktop, my notebook is still working that way (cygwin bash + ctags + windows gvim + windows path with '/' instead of '\\'), only my desktop has the issue. -- Sincerely, Pan, Shi Zhu. ext: 2606
Always 1 instance-only mode for gvim?
Hi, vimmers, For some reason I'd like to have only one instances of gvim in my machine at most. launch gvim anyway when gvim has existing instance will switch to the existing one. (evenif no files are specified) But the --remote-silent do not fully meet my requirement since it requires an argument. It requires one file to be open. If I want to: start gvim without opening any file will switch focus to existing gvim if available, and start a new one if no gvim exists. possible to do that? -- Sincerely, Pan, Shi Zhu. ext: 2606
Re: taglist plugin launch ctags fail in gvim windows.
"A.J.Mechelynck" <[EMAIL PROTECTED]> 写于 2007-05-14 13:21:47: > > > > If your shell is cmd.exe, "/usr/bin/ctags" will give "Unknown command or file > name". If you want to mix Dos shells and cygwin utilities, you will have to > juggle with the path formats: see "man cygpath" from within cygwin. > > > Best regards, > Tony. > -- My shell is c:/cygwin/bin/bash, since I do not want to mix dos shells with cygwin utilities. (I don't use any DOS utilities at all.) I had tried to replace the content of /usr/bin/ctags with something else, which proves that the ctags does get executed. Cygpath is not the issue here. -- Sincerely, Pan, Shi Zhu. ext: 2606
taglist plugin launch ctags fail in gvim windows.
Hi vimmers, I have WinXPSP2 and installed gvim 7.1, taglist plugin 4.2, cygwin with the most up-to-date version DLL. The issue is: run gvim from windows will fail the taglist plugin, taglist plugin only works when I launch gvim from within cygwin bash, (Yes I am running the windows native gvim.exe from within cygwin bash shell) it has been a long time and I still cannot spot where the problem is. I set 'c:\cygwin\bin\bash' as my shell, the cygwin has /bin/ctags, which is Exuberant Ctags 5.6. Taglist plugin from within cygwin console vim works well. When I start gvim7 from start menu (or by any windows-way such as right-click or launch in explorer), and launch taglist with :Tlist, error reported such as: Taglist: Failed to generate tags for D:/panshizhu/blabla.cpp [EMAIL PROTECTED]@ctags: cannot sort tag file : No such file or directory^@ where “输入文件指定了两次。” in the above message means: "The input file is specified twice.". I then wonder if there's any difference running from within cygwin shell and startmenu shortcut. I found the following: near the error line: the verbose information is: line xx: let cmd_output = system(ctags_cmd) Calling shell to execute: "/usr/bin/ctags -f - --format=2 --excmd=pattern --fields=nks --sort=yes --language-force=vim --vim-types=avf \"D:/panshizhu/blabla.cpp\" >D:/temp/VIo74.tmp 2>&1" The ctags_cmd proves to be the same, either run gvim from cygwin shell or from startmenu shortcut. Then I think the system() function taking different options, but I checked that 'shell' 'shellcmdflag' 'shellxquote' 'shellredir' all are the same. At last, I think there may be multiple versions of ctags in my computer, but that's wrong, the only ctags is in my c:/cygwin/bin/ctags, which is equivalent to /bin/ctags inside cygwin bash shell. Then may be the environment variable are different? check my env by :!set inside gvim: Most things are the same except some settings in my .bashrc, the PATH, HOME and LS_COLORS, I don't think it can cause system() report an error. My question is: 1. where does the error [EMAIL PROTECTED]@ctags: cannot sort tag file : No such file or directory^@ come from? the system() function, or the bash shell, or the ctags program? It seems that the ctags are launched, so may be the arguments are passed wrong? or I may have missed something? 2. if the problem cannot be identified, anybody has a solution to keep using cygwin bash as gvim shell and use cygwin ctags inside taglist for windows gvim? ―― I did make them work the last year, but when I reinstalled my WindowsXP I cannot remember how to get them work that way. -- Sincerely, Pan, Shi Zhu. ext: 2606
Re: what "feature" is required to return to last editing position?
Vincent BEFFARA <[EMAIL PROTECTED]> 写于 2007-05-09 23:54:27: > Hi, > > >Recently I installed Ubuntu Feisty and the "feature" seems to have gone (I > > >installed vim-gnome version 7.0.135). Since I use the same .vimrc in all > > >platform, it is unlikely to be the fault of my .vimrc script, the problem > > >is I do not know how to debug vim script, and I don't know why that > > >autocommand does not work. > Just in case - might it be that you don't have right permissions to your > own ~/.viminfo ? I had a similar problem : on a new install, typically > you might go and edit some files using "sudo vim /etc/whatever", this > creates .viminfo belonging to root, and then vim as a normal user cannot > use it, and fails silently. > > Only happens if there is no .viminfo to start with, vim does the sane > thing and does not overwrite, but still might be considered a bug ... > hth, > /vincent > -- > Vincent Beffara Wonderful, the problem really is about permission of .viminfo! I noticed that you considered this to be a bug, but is this bug belongs to "sudo" or "vim"? i.e. for non-interactive "su" of "root", vim will save at user $HOME with root permission. -- Sincerely, Pan, Shi Zhu. ext: 2606
what "feature" is required to return to last editing position?
When opening a file in vim, the cursor will move to the last position when the file was saved. The "feature" is enabled by some autocommands in vimrc_example.vim, I copied the code into my .vimrc and use it in all platform. It really does work in my WindowsXP gvim, cygwin vim, MacOSX vim, and Ubuntu Dapper vim. Recently I installed Ubuntu Feisty and the "feature" seems to have gone (I installed vim-gnome version 7.0.135). Since I use the same .vimrc in all platform, it is unlikely to be the fault of my .vimrc script, the problem is I do not know how to debug vim script, and I don't know why that autocommand does not work. Any idea where is the problem, or any hint on how to find where the problem is? -- Sincerely, Pan, Shi Zhu. ext: 2606
Re: VimWin
"Zhichao Hong" <[EMAIL PROTECTED]> 写于 2007-04-22 22:55:47: > If the topic is about fonts, I would like to make some comment. The > Bitstream Vera Sans Mono looks ugly with subpixel hints. You can say > the same thing about Consolas. But if the hinting are turned on and > compared on the Windows, Consolas beats the BVSM easily. Just try to > compare the zero character. There is only one size in BVSM looks sort > of O.K.. It might be my personal taste again. But I think one thing > Microsoft did well in the Vista is about fonts. I use YaHei for > Chinese and Segoe UI or calibri for English. I don't read Chinese a > lot (only some websites). So Chinese fonts poor rendering in Linux > don't bother me a lot. > > In Linux, I use blackblox or windowsmaker. The KDE or GNOME don't > attract me in general. I know about tuning the fonts in Ubuntu and > RedHat. I still think in Linux the Terminus bitmap font beats every > true type fonts. First I must say your work is welcome and your work might be useful for many people. However, the font-rendering engine has nothing to do with the fonts-itself. I agree that Microsoft's ClearType is better but Linux is now closing the gap. If you like Microsoft's "ClearType" to do the sub-pixel hinting, then just install the "ClearType", there're plenty of topics discussing this on ubuntu china forum, or linuxsir.org, or something else. You can get exactly the same look in Linux and Windows, since every Windows font can be used as a Linux font, including the Microsft's rendering engine. Then the font issure is nothing to argue about... Okay now lets saying the Visual C++ compiler. (Call it VC for the following) I agree that VC dominates (especially in china) and I am one of the "professionals" using VC at my work. But I personally had done comparations for vc vesus gcc. The comparision is easy to do, just get the latest version of lame (the "almost-industry-standard" mp3 encoder), which compiles fluently under VC or under GCC, use maximum optimization and see the results. which lame.exe is faster? To be fair with the OS, I compared using cygwin version of gcc and the latest VC and run both programs within Windows XP, gcc unexpectedly wins. I'm not saying VC is inferior since I use VC everyday, just saying that VC does not necessarily faster than gcc in all aspects, there may be somewhere that VC does better, but for compiling C programs gcc might be better. VC has good ANSI C++98 support, however, VC does not have full ANSI C99 support, the standard C support of VC is not quite up-to-date, so that C sources that requires ANSI C99 cannot compile under VC. This bothers me a lot, since many C99 source must be amended before it can be compiled with VC. And I don't want to come back to the obsoleted C89 standard any more... GCC, however, has the best support for C99 and some exclusively useful extension for C. Let's assume VC is good in C++, but will it be that good for C? My painful experiences tells me, it is better not use VC for pure-C programs, since many shortcomings of C are overcomed in C99 and I cannot live without C99 if some application must use C. -- Sincerely, Pan, Shi Zhu. ext: 2606
Re: Two different versions of Vim...
"Marv Boyes" <[EMAIL PROTECTED]> 写于 2007-04-20 23:09:11: > I removed all Vim-related Ubuntu packages and re-ran the AAP install > with "--enable-gui=gtk2" in my config.arg file. That's evidently not > the correct syntax, since I ended up with no GUI available. > This is the correct syntax, but you may not have X-related dev packages installed. try the following: sudo apt-get build-dep vim The above will install all related development packages into your system so that vim can be compiled into gui version. And install the packages, configure and make vim again, this may give you the gui version. -- Sincerely, Pan, Shi Zhu. ext: 2606
Re: RAM issues
fREW <[EMAIL PROTECTED]> 写于 2007-04-19 09:07:42: > > Are there any general tools that will do this? I don't use KDE or Gnome. > > -fREW use the command-line tool: top it should be available on most Unix platforms. -- Sincerely, Pan, Shi Zhu. ext: 2606
Re: how to avoid deleting the auto-indent in a new empty line when i press
sun <[EMAIL PROTECTED]> wrote on 2007-04-16 15:57:21: > What I need is to always keep the auto-indented spaces. So next time > I can start to insert from the spaced cursor. > > The typing S is a reasonable way although I really want to know how to > change indent-deleting behavior for a empty line in vim. > > Best Regards, > sun Few people need that "feature", so it is not there, I believe more than 99% of vim users think it is better to just delete the trailing blanks. If you still insist that the indent-deleting should be changed, then you can do-it-yourself. The indent script and vim source are all open to you and please feel free to change them (for your own custimized version, of course). -- Sincerely, Pan, Shi Zhu. ext: 2606
Re: gvim: menu disappeared
Guido Milanese <[EMAIL PROTECTED]> 写于 2007-04-16 05:08:14: > I am sorry to ask such a stupid question, but I'm really puzzled. > I have been using vim for ages now, and for some tasks, not always, > I prefer a > GUI. I use a Mandriva Linux distribution and it's all right. > Suddendly the menu bar (not the toolbar with icons, the menu bar with texts: > File, Edit, and so on) disappeared. I tried several options of the "set > guioptions" command, but to no success. I also deleted the .vimrc file, but > again no change. Then, installed vim-X11 again, but nothing happened. > > May I ask your kind help? > > Thank you! > guido, from Italy > > Will the :se go+=g show your menu? If not, then your menu may have some error and vim delete it while loading. -- Sincerely, Pan, Shi Zhu. ext: 2606
Re: how to avoid deleting the auto-indent in a new empty line when i press
sun <[EMAIL PROTECTED]> 写于 2007-04-15 17:27:28: > Dear all, > > The question is: > > When I insert a line then to edit other place, vim of C filetype > delete the auto-indented space. But i want to keep the indent there > for the future editing? Then how to make the auto-indent always insert > the indent-space regardless whether the line is empty or not? > > I read the help file about the 'cpoption' option, it says 'set > cpoption+=I' can avoid the indent deleting when move the cursor > updown, but I can't let that work. > > Best Regards, > sun If you insert a line, and then go somewhere else, and then come back, you can just type dd to delte the newly inserted line and type o to insert a new line again. This is only 3 keystrokes and it solves all problem, your indent come back. Anyway, this behavior is good for avoid trailing blanks. -- Sincerely, Pan, Shi Zhu. ext: 2606
Re: Vimrc blues.
"Ananya M (RBIN/ECM1)" <[EMAIL PROTECTED]> 写于 2007-04-13 17:02:11: > Hi, > I m very new to Vim. But I'm smitten by it nevertheless. > I use Gvim 7.0. I also have cygwin installed in my winnt system. > Cygwin defines $HOME to a network drive and places its own .vimrc file in it. > I don’t want gvim to use this rc file since it sits on a server. > How do I force gvim to always consider the _vimrc file in $VIM? > Is there a command line or registry option? > - > The gvim docs say that gvim looks for $HOME/_vimrc file first(in > Windows environment). > However why is my gvim even considering a .vimrc file within $HOME? > Shouldn’t it have failed its search for _vimrc in $HOME, and moved > on to $VIM to look for the _vimrc file? > -- > I tried setting $MYVIMRC to $VIM/_vimrc . But this failed, since > gvim always overwrites it to $HOME/.vimrc . > -- > Thanks for all your answers. > Best regards, > Ananya M > //I'm sorry to have sent this mail directly to you. > //My mailer daemon failed to deliver the mail to vim@vim.org . Hi, I don't think it's possible to use directories other than $HOME while HOME is defined. But you can redefine the $HOME in your Windows. (System|Properties|Advanced|Environment Variables|User variables) so that the HOME environment variable has a different value, this is the best way IMO. Or you can specify the init file manually. try launch vim by vim --help, you'll see that vim -u can override any .vimrc file. -- Sincerely, Pan, Shi Zhu. ext: 2606
Re: Wish: need a way to reverse 'cterm=inverse' highlight command
Spencer Collyer <[EMAIL PROTECTED]> 写于 2007-04-13 15:55:48: > Typically, just after I sent my message I realised how to do it - just > use 'cterm=NONE'. > > Spencer This is not perfect, since it removes ALL properties. Suppose something is highlighted as cterm=reverse,underline,bold The cterm=NONE, removes all. And, there seems to have to word around to remove the "reverse" properties ONLY. -- Sincerely, Pan, Shi Zhu. ext: 2606
Re: Troubles configuring vim (multi-questions)
OnionKnight <[EMAIL PROTECTED]> 写于 2007-04-13 10:05:10:
> Couldn't find anything about command-mode. How is it different from
normal
> mode? Is each line treated as one command? Like g0w is treated as "g0w"
> instead of "g0" and "w"?
Vim is a multi-mode editor, in different mode, it accepts completely
different set of commands.
So, commands accept in insert-mode may have completely different meaning in
normal-mode.
When you use normal-mode commands inside command-mode, vim will be crazy,
since the meaning of the command is completely different in command-mode
and normal-mode.
Inside vim, you can see :help index
then you'll got the idea what is the commands available in different mode.
(use Ctrl-] to follow a link in help, use Ctrl-O to jump back)
> elseif expand("%:p:h") == "C:\\Program Files\\Apache\\htdocs"
> It looks sorta like that right now. I want to check if the left side of
the
> == operator begins with the right side. In Perl or Ruby it would be done
as
> elseif expand("%:p:h") =~ /^C:\\Program Files\\Apache\\htdocs/
>
What you need to see may be :help eval
if you want to do regexp matching, you could use =~ instead of ==
see :help expression-syntax
|expr4| expr5 == expr5 equal
expr5 != expr5 not equal
expr5 > expr5 greater than
expr5 >= expr5 greater than or equal
expr5 < expr5 smaller than
expr5 <= expr5 smaller than or equal
expr5 =~ expr5 regexp matches
expr5 !~ expr5 regexp doesn't match
expr5 ==? expr5 equal, ignoring case
expr5 ==# expr5 equal, match case
etc.As above, append ? for ignoring case, # for
matching case
you can use regexp match to do your match.
--
Sincerely, Pan, Shi Zhu. ext: 2606
OT: [Help]How can I add some char before a block?
陈方荣 <[EMAIL PROTECTED]> 写于 2007-04-13 09:08:49: > Hi all， > How can I add some char before a block? > Just like C++ comment. > > Before： > Comment line1 > After： > //Comment line1 > Thanks. Offtopic: Generally, use comment character to comment out real code is not considered a good programming style. because "comment should be comments", and there should be only real "comments" inside the comments. use #if 0 and #endif to comment out your code is a prefered way. -- Sincerely, Pan, Shi Zhu. ext: 2606
Re: Troubles configuring vim (multi-questions)
OnionKnight <[EMAIL PROTECTED]> 写于 2007-04-13 08:22:06: > I've been thinking of migrating to using vim (gvim) but I'm running into lots > of difficulties on the road I just can't solve, and the documentation is... > well, strange at best. It seems that Vim had a longer learning curve than other editors (the only exception is emacs, which has takes more than a life time to learn...). So, when you've got used to it, you'll no longer found it strange, and it will be powerful for you. > * At the beginning of an indented line, why does normal mode put the cursor > at the end of the first tab whereas insert mode is position at the beginning > of the line like I think it should? It's annoying to move around in code > like that. The answer is probably: "VI" do it in that way, and vim need to be compatible with VI. > * Is it possible to enter insert mode for files that aren't modifiable? > Obviously any changes can't be saved but the buffer shouldn't be any > problems to modify. Sure, this is the default behavior. If yours are not, maybe you've been affected by system-wide startup scripts. try :set modifiable > * I wanted the Home-button to act so that it first jumps to the first > non-whitespace character of the current line (i.e. skip the indentation) and > the beginning of the horizontal scroll. A problem, but it doesn't explain > why the code is acting crazy. inside a script you're in "command-mode", and the command "w" you've meant to should be in "normal-mode", the correct way might be :normal w, :normal g0w, etc... > > * In gvim, is it possible to have a drag-and-drop action open the dragged > file into a new tab instead of a new buffer? Using the menu is just tedious, > and you can't select multiple files either. I don't use the mouse too often. I can use the vim buit-in file explorer and open files inside vim, which have no interaction with the menu at all. Remember: most vim features are invoked by command, not the menu. > > * I want to check a string if it begins with something but I have no clue > why. I was thinking of a regexp but the only way to use matching regexps is > for highlights and substition regexps seems to operate on the whole file or > a selection and no way to use them on strings. What do you meant by "string"?, if you think a string should begin with quotation mark, then begin your search regexp with the quotation mark. -- Sincerely, Pan, Shi Zhu. ext: 2606
Re: how to replace ESC to some other key?
map something to , and it will insert a real tab character for you. for example: inoremap will map F6 for you, replace it with anything you want. I always need such a map, since I've set 'expandtab' all the time. -- Sincerely, Pan, Shi Zhu. ext: 2606 wangxu <[EMAIL PROTECTED]> 写于 2007-04-11 23:16:08: > That's a very good tip: ) > I also wanna know how to insert a "Tab" when I editing files like > /etc/hosts? > Can I? > > [EMAIL PROTECTED] wrote: > > wangxu <[EMAIL PROTECTED]> 写于 2007-04-05 21:08:43: > > > >> but in this situation,is there any way to auto-indent *.py? > >> > >> > > > > << is "decrease indent" (hold on Shift, then '<' twice) > > >> is "increase indent" > > You can use << or >> command in Normal mode and Visual mode. which is as > > good as, if no better than, the key. > > > > -- > > Sincerely, Pan, Shi Zhu. ext: 2606 >
***SPAM*** Re: Vim70's highlighting
"李长青" <[EMAIL PROTECTED]> 写于 2007-04-10 10:14:07: > hi,all: > thank you. > I install vim70 as a new software ,not update from other version. > And there is not a file named vimrc_example.vim at the path > /usr/share/vim/vim70,just a file named debian.vim.And when I install > vim70 completely,Thers is only one file like *.vim,and only one file > named "vimrc" "vimrc.tiny". How do you installed vim70? By make install from source or by apt-get install or something else? What's the version? type :version inside vim will tell you the exact version, maybe you had a tiny version of vim which has no highlighting features? If you compiled from source, then the default will be installed into /usr/local instead of /usr. -- Sincerely, Pan, Shi Zhu. ext: 2606
Re: how to replace ESC to some other key?
wangxu <[EMAIL PROTECTED]> 写于 2007-04-05 21:08:43: > but in this situation,is there any way to auto-indent *.py? > << is "decrease indent" (hold on Shift, then '<' twice) >> is "increase indent" You can use << or >> command in Normal mode and Visual mode. which is as good as, if no better than, the key. -- Sincerely, Pan, Shi Zhu. ext: 2606
Re: how to replace ESC to some other key?
"Yakov Lerner" <[EMAIL PROTECTED]> 写于 2007-04-04 22:22:43: > On 4/4/07, wangxu <[EMAIL PROTECTED]> wrote: > > ESC is so far from the center of the keyboard. > > Can I replace this key to Caps Lock,for example? > > I heard some people use Tab as a substitute for Esc. Weird. > But it's easier to do in platform-independent way. > > Yakov It's not weird IMO, Tab key is rarely required inside Vim, thanks to the powerful auto-indent feature of Vim (you don't need the tab key even when editing Makefile!), I never feel a need to use key in vim during the last 3 years. Personaly, I think it is easier to train my fingers to reach the so-called-far-away-ESC-key. (Imagine that the piano players often need to reach keys in the piano much farther than ESC, and they do that precisely.) -- Sincerely, Pan, Shi Zhu. ext: 2606
Re: how to replace ESC to some other key?
wangxu <[EMAIL PROTECTED]> 写于 2007-04-04 23:55:55: > ESC is so far from the center of the keyboard. > Can I replace this key to Caps Lock,for example? > Thanks. This was well discussed on vim online. Search for tips in vim.sf.net. You'll got all things you need to assign CapsLock to ESC. -- Sincerely, Pan, Shi Zhu. ext: 2606
Re: completion menu colors
fREW <[EMAIL PROTECTED]> 写于 2007-04-03 10:56:11: > > Are these things that should be set in the colorschemes, but just > aren't yet because the names are new, or what? > > -fREW This should be set in colorscheme, however, if you're using the default colorschme it is buit-in with Vim and you cannot change the source code of colorscheme. If you are not using the default colorscheme, then you can just edit the colorscheme and set those settings. Note: a colorscheme does not have to set all the highlight settings, the settings which are not set inside a colorscheme will use the default. -- Sincerely, Pan, Shi Zhu. ext: 2606
Re: Customizing vim: How to change the char before commands
Some user <[EMAIL PROTECTED]> 写于 2007-03-22 05:14:30: > I'm new to Vim. I want to change the character before commands. For example > saving is done by: > > :w > > Can it be made slightly easier by just pressing 'g' or some other key that's > not taken? I don't know why every command has to be pre-pended by a > difficult to reach character like colon. Sure, I think many Vim users may found this useful: noremap ; : then you could use ;w instead of :w I'm in the same boat, I don't want to press any "chord-combination-keys" since I can type much faster if there're no s or s or s If you want to change the character into 'g', it may not be a good idea IMO, since the left hand need to move a bit to reach the 'g' key, while the ';' key is right at the right hand. -- Sincerely, Pan, Shi Zhu. ext: 2606
Re: Consistently exit "message display" with 'q'?
John Orr <[EMAIL PROTECTED]> 写于 2007-03-22 12:43:51: > Thanks for the clarification Brett. At least if you have external > commands you use regularly though, you could wrap them in a vim > function, thereby making them effectively internal, making g< useful. > > Just an update - I promised I'd investigate extending my "patch" to > help those people who complained about losing their commands if they > pressed one too many keys. > I tried the most obvious approach, and whilst it sort of worked, > there was some unhandled complexity to do with reverting to "more- > prompt" mode which I couldn't easily work out. > I think it was because vim thought we had alreday exited "more- > prompt" mode, when in fact we shouldn't have (so you couldn't scroll > back up when you reached the end). > Since this g< command works somewhat (or can be made to work by > using a wrapper function for external commands), I think I might > give up on this and just be satisfied with the simpler "q exits the > Press Enter prompt" change. > Cheers, > John Just done some experiment, if I use j/k or / to scroll within the "more-prompt" the message will never quit. Seems good but not quite useful to me since I always use "f"/"b" or / to view the message. So the only issue is the lack of "f"/"b" or support for the "more-prompt" and "hit-enter-prompt". key "f" and "b" is the standard page-scrolling key for less and more, it seems strange that the "more-prompt" and "hit-enter-prompt" do not have support the "f" and "b" key. Let's hope it will be available in future versions. -- Sincerely, Pan, Shi Zhu
Re: Consistently exit "message display" with 'q'?
"A.J.Mechelynck" <[EMAIL PROTECTED]> 写于 2007-03-20 11:58:26: > > After hitting once at the Hit-Enter prompt you're back to the > More-prompt > so _then_ you can use again. > > IMHO it is advantageous to have a different prompt at the end of the message > because it tells you that there's nothing to scroll _forward_ to. > > > Best regards, > Tony. > -- It is not hurt to have a different prompt, but in the Hit-Enter prompt, hit *any-key* will close the message display. This is different from the Vim "state", we know that press the ESC twice will go into normal mode. If I pressed the ESC 3 times (by mistake) it does not hurt. Press will scroll down in 'more-prompt', and the prompt may silent change into 'hit-enter-prompt', if I then pressed the for one more time, the messages may lost forever and I may not have chance to see the message at all. Such kind of unrecoverable "destructive" command like "close the message" should be explicitly defined like 'q' and should not be *any-key*. -- Sincerely, Pan, Shi Zhu. ext: 2606
Re: Consistently exit "message display" with 'q'?
"A.J.Mechelynck" <[EMAIL PROTECTED]> 写于 2007-03-20 11:18:06: > To go back in the scrolling display, in Vim 7 (but not in Vim 6 or earlier) > you can use or depending on how far you want to go back. > > > Best regards, > Tony. > -- Hi Tony, Anyway to prevent 'more-prompt' from changing into 'hit-enter-prompt' at the last line? When you scroll down and see the 'hit-enter-prompt', anykey will close the message display, and the does not work under that circumstance. -- Sincerely, Pan, Shi Zhu. ext: 2606
Re: Consistently exit "message display" with 'q'?
John Orr <[EMAIL PROTECTED]> 写于 2007-03-19 21:23:59: > Hi all, > > I'm a bit frustrated by a particular behaviour of vim, and today I > modified the source code to 'fix' it. I'd be very grateful for some > opinions if you > a) agree with my thoughts, or > b) have a better solution. > > The problem - is when you run a command that outputs "messages" to > vim - over multiple lines. For example, > :!ls > or > :set > > They scroll messages up the screen, and a kind of Unix 'less' > function is effectively invoked (since it steals it's scrolling > commands from vi(m)). > In Unix "less" (and also Unix "more"), a simple, close-to-the- > fingers way to exit is to type the letter 'q'. This works no matter > whether you're at the start, middle or end of the file. > In vim, if only a part of the messages would fit on the screen, you > get the prompt '-- More --' - and if you press 'q', it will exit > message display. If you press Enter, it will just scroll one line. > However, if all the messages would fit on the screen, you get the > prompt 'Press ENTER or type command to continue'. Now the 'q' and > 'Enter' keys do totally different things - q heads you towards macro > recording, and Enter exits message display. > > Often, the line I want to see is at the top of the message output - > and I don't care whether all the messages fitted on the screen, or > whether there are more - I just want to exit message display. > To me, it makes perfect sense that, just as with the unix 'less' > program, pressing 'q' should exit message display - regardless of > whether there are more lines to display or not. > Sure, I can press Escape, but it's much harder to press than 'q'. > Yes, I can press Ctrl-[ - but that's also much harder than 'q'. > (Both of these options will also trigger the 'error bell' (audible > or visual) - which seems rather unnecessary to me in this situation.) > Otherwise - I have to look to the bottom of the screen to see > whether vim wants 'q' or Enter to exit message display. > Is it just me that finds this open for improvement? > > I've tried finding good mappings to solve this problem, but it's not > at all easy. > > The source code change I made today was to change line 1004 of message.c from > if (vim_strchr((char_u *)"\r\n ", c) == NULL && c != Ctrl_C) > to > if (vim_strchr((char_u *)"\r\n ", c) == NULL && c != Ctrl_C && c != 'q') > It seems to work fine I think. > > If I'm the only one who finds this a problem, how do all of you exit > from message display? Do you do different things depending on the > message at the bottom? Use Escape? > Otherwise, would anyone else like to see this tiny change accepted into vim? > > Thanks for your thoughts, > John Hi, I don't know how other people quits the message display but I do feel unhappy since the first day I use vim and have no good work around unless having a big screen (so that most messages could fit in my screen)... The more frustrating thing is: if I continuously scroll down in the 'more-prompt' mode, the 'more-prompt' will eventually quits the display and the message are disappeared forever, so I must be careful NOT to press any key when the last line of message are shown. What I expect is: press "Enter" or "space" will always do scroll ONLY, and do never quit the message display, this is consistent with the Unix "less" command. If you just eat the 'q' after the message display, it will work if you want to just quit all message, but when you want to view the last lines of the message, the 'more-prompt' is still inconsistent since it will change into "Press Enter or type command to continue" on the last line. So I think a better way is to change the code for the 'less' mode, (in Vim document, it is called 'more-prompt'), the 'more-prompt' should always require 'q' 'ESC' to exit, even if the last line of text are shown. And there should be an option to turn the 'more-prompt' always on. i.e. All message will show 'more-prompt' regardless of the message 'lines'. To conclude: 1. an option to "always show" the 'more-prompt' 2. 'more-prompt' will never fall into "Press Enter or type command to continue" state even if on the last line, so we always require 'q' or ESC to quit the 'more-prompt'. this is consistent with the Unix 'less' command. -- Sincerely, Pan, Shi Zhu. ext: 2606
Re: replace upper-case with lower-case
"Theerasak Photha" <[EMAIL PROTECTED]> 写于 2007-03-09 11:39:13: > > Suppose I want to replace "start" to "stop" without changing the > > capitalization, this will be: > > > > START -> STOP > > start -> stop > > > > My prior question is wrong, sorry. > > Oh, well in that case: > > :%s/START/STOP/g > :%/start/stop/g This does not seem to be a good way, consider if we want to change: START -> STOP Start -> Stop start -> stop STart -> STop sTART -> sTOP ... then we may need to have too many lines... Or imagine if we need to change ABCDEFG into HIJKLMN: ABCDEFG -> HIJKLMN aBCDEFG -> hIJKLMN abCDEFG -> hiJKLMN abcDEFG -> hijKLMN ... how many lines should you write? write a function and change each character seem to be a more sensible approach. -- Sincerely, Pan, Shi Zhu. ext: 2606
Re: GVim colours
I've written a script to remove all the gui=bold properties, please be ware that it isn't easy, since you cannot just set all the highlighting to gui=NONE. For those who had a default value of gui=reverse, you should NOT set it to gui=NONE, for those who had gui=reverse,bold, you should first set gui=NONE and then set gui=reverse again. Well, I really HATE the way to do that since it seems to be a "dirty" and "hacked" way, but unfortuanately it is the only way for gvim now, I strongly hope the next Vim version will have a much "clean" way to disable all the bold font. An alternative solution, is to use a bold font for the default font of gVim. And then all text will be highlight as the same thickness. Again, this is not a very satisfying approach but it might work for some people. -- Sincerely, Pan, Shi Zhu. ext: 2606 news <[EMAIL PROTECTED]> wrote on 2007-02-04 20:00:18: > I've been using Vim with colorscheme evening, run in gnome-terminal set > to disallow bold text and to use the Rxvt colour palette, and it's been > working great for me. > > So great, in fact, that now, when I want to give GVim a chance, > I can't stand its default interpretation of the evening colorscheme, > but I have no idea how to make it drop the bold text and use the Rxvt > colour palette. Is it at all doable? If so, how? > > Or, to rephrase my question, how to make GVim (below) look the same as > Vim (above) in the following screenshot? http://shot.pl/gvim-colours.png > > -- Shot > -- > It is not yet possible to change operating system by writing > to /proc/sys/kernel/ostype. -- man 2 sysctl >
Re: How to maximize my vim window when I start it?
Hi,
The :set lines=9 columns=9 does not really maxmize the Vim window.
Since there's still borders for the window, a maximized window have no
borders (AFAIK this is true for WinXP and KDE).
Since you are highly unlikely to use a Windows version other than English
and Chinese. The following method works:
if has("gui_win32") " NT Windows
autocmd GUIEnter * :simalt ~x
endif
Tony think the method is non-portable, that is true, if there's a portable
way to do the job, I will prefer the portable way. However, the :set
lines=9 columns=9 cannot do the same job as the :simalt can do, so
their must be a compromize. I would recommend the ":simalt" way until there
is a nature way for vim to cope with that.
--
Sincerely, Pan, Shi Zhu. ext: 2606
[EMAIL PROTECTED] wrote on 2007-02-05 07:26:38:
> Hi, everyone:
> I am now using gvim7.0 on WIN XP; I have several questions:
>
> 1. How to setup my gvim to open to the maximal size when I start it?
>
Re: Administrator never hears the beep
Spencer Lu <[EMAIL PROTECTED]> 写于 2007-01-18 13:45:29: > I'm running Vim 6.4 on Windows 2000. When I'm using GVim as a normal > user, I can hear the beeping noises (for example, if I'm on the last > line and then press 'j'). However, when I'm logged in as Administrator, > I never hear any beeping noises. > > I made a few changes to my _vimrc file, but the file is shared by all > users, and none of the changes have to do with the beep, so I don't know > why Administrator can't hear the beep. > > Anyone know what's going on? Thanks. Beeps are controled by t_ settings, those settings may be reset *after* .vimrc. So you should set those in .gvimrc again. Check if there's a .gvimrc for Administrator? HTH. -- Sincerely, Pan, Shi Zhu. ext: 2606
Re: change syntax highlighting
"Geue, Stephan" <[EMAIL PROTECTED]> 写于 2007-01-10 17:34:03: > Hello, I would like to change the VIM colors, i.e. the C/C++ mapping of > VIM colors to Xterm colors. First, I changed a few lines within Hi, A better approach is to use the GUI version of Vim, and you could set the color scheme, see :help :colo or just find the colors in the menu. If you want to use the terminal version of VIM, the possibility is generally quite limited. For 8-color or 16-color terminals, chances are that you have to change term color in order to obtain an elegant color of syntax highlight. Things would be better for a 256-color terminal, however, few color schemes are designed for 256-color terminal. Anyway, the $VIMRUNTIME/colors/*.vim is the files you should look first, it may have what you want most. HTH -- Sincerely, Pan, Shi Zhu. ext: 2606
Re: Questions about syntax highlight script.
"A.J.Mechelynck" <[EMAIL PROTECTED]> wrote on 2007-01-04 18:18:39: > [EMAIL PROTECTED] wrote: > > Hi vimmers, I've got some question when writing my syntax highlight script. > > > > Q1. > > The language requires a ^M character as a keyword. The ^M character is by > > default highlighted but I want to highlight it to some other color, at > > least it should be different from ^L and ^N... > > > > It seems impossible to match the ^M by > > :syn match Testgroup "^M" > > (Note the ^M is obtained by press C-K, release, then press C-M, release, > > then press ) > > When using double quotes, you can match "\r" instead, but beware: ^M is the > carriage-return character, which has special meaning on Mac (where is is the > end-of-line character) and on Dos/Windows (where it, plus ^J [line feed] > together make an and-of-line). In general, using any character below0x20 as a > "text" character is a bad choice. The fact is that the script language requires the source be in Unix format on all platforms, so there should not be problem using ^M. (AFAIK Mac is using FreeBSD kernel, isn't FreeBSD using Unix format?) However, your solution does not seem to work. Changing "^M" to "\r" does not get it highlighted correctly. -- Sincerely, Pan, Shi Zhu. ext: 2606
Questions about syntax highlight script.
Hi vimmers, I've got some question when writing my syntax highlight script. Q1. The language requires a ^M character as a keyword. The ^M character is by default highlighted but I want to highlight it to some other color, at least it should be different from ^L and ^N... It seems impossible to match the ^M by :syn match Testgroup "^M" (Note the ^M is obtained by press C-K, release, then press C-M, release, then press ) and :hi def link Testgroup Number does not highlight it as desired. It seems always highlighted to some other color. Q2. The string for the script language can be as long as 50-100 lines, when I write a ":syn region" for string, it works but sometimes when I go page down and page up, the lines of the string are highlighted as "Normal" instead of "String", seems that the context are not concerned. Any work around? Q3. The first occurence of colon and the following occurences in a line have different meanings. So, if there are text: :::; I want to highlight the first colon as GroupA, and highlight all following occurences of colon in the same line as GroupB. Is that possible? Thanks in advance. -- Sincerely, Pan, Shi Zhu. ext: 2606
Re: i_CTRL-Y on Windows
Try to see if you sourced mswin.vim somewhere. (it may be in your .vimrc, or $VIMRUNTIME/vimrc_example.vim, or anywhere in the $VIM.) An easy way may be: delete the mswin.vim file, restart vim and the script souceing that file will report an error, then you'll know where you had sourced it. If you runs vim on both Windows and *nix platform, it is highly recommended that you remove the call of the mswin.vim. It might be helpful for those who had never used VI before and knows only Windows platform. But for *nix users, it create many incompatibilities. Hope that helps. -- Sincerely, Pan, Shi Zhu. ext: 2606 striker <[EMAIL PROTECTED]> 写于 2006-12-27 19:52:01: > I frequently use i_CTRL-Y on my *nix box to insert the character > above. How can I make i_CTRL-Y work on Windows? > i_CTRL-E does however work. > > TIA, > Kevin
Re: on *nix vim
C-S is used for terminal flow control in Unix. So, try s instead of , i.e. release the after and press a single "S". -- Sincerely, Pan, Shi Zhu. ext: 2606 "Manu Hack" <[EMAIL PROTECTED]> 写于 2006-12-29 02:15:16: > It works in Vim7 on WinXP but not on *nix (I tried solaris and linux). > On *nix, it just stopped until I press . Why was it happened? > Thanks.
Re: Upgrading From Vim 6.4 to Vim 7.0
"Roy Fulbright" <[EMAIL PROTECTED]> wrote on 2006.12.16 10:42:02: > I am preparing to upgrade from Vim 6.4 to Vim 7.0 on Windows XP. I > downloaded 'gvim70.exe' from the Vim site, but also noticed a reference to > the latest binary with all the most recent patches, which currently is > 'gvim-7-0-178.exe', which I also downloaded. My question is, must I first > install 'gvim70.exe' before installing 'gvim-7-0-178.exe'? > > Thanks, > Roy Fulbright > > _ > All-in-one security and maintenance for your PC.?Get a free 90-day trial! > http://clk.atdmt.com/MSN/go/msnnkwlo005002msn/direct/01/? > href=http://clk.atdmt.com/MSN/go/msnnkwlo005001msn/direct/01/? > href=http://www.windowsonecare.com/?sc_cid=msn_hotmail > Hi, if you mean here: http://sourceforge.net/project/showfiles.php?group_id=43866&package_id=39721 It seems to have included everything, so you don't need to install gvim70.exe prior to that. HTH. -- Sincerely, Pan, Shi Zhu. ext: 2606
Re: vim-display problem?!
"dong wang" <[EMAIL PROTECTED]> 写于 2006-12-11 18:10:03: > I found a problem ( sorry , here i just call it problem ) when i edit > a csv file. > That is the vim don't display the last line as a seperate line when i > do " set nu" > > For exmaple , > use Notepad.exe (or some other Editor) to create a file , and do input : > > abc > abc > > save the file. > > After that , use vim to open the file and "set nu" > Well , i found that , the vim just displays the line number as this > > 1 abc > 2 abc > > which i thought it should be : > > 1 abc > 2 abc > 3 > > Does this a problem ? > Or i can use some option to control this? > > Why did vim not display the last line number ? > in my option i thought the fine should have three line > but not just TWO line , Right ? No, this is not a "problem". This is a "feature"... ;-) Vi treat text files in "Unix" way. i.e. all lines should have a line break. So if you want : 1 abc 2 abc 3 then the stream on disk should be something like: abcabc If you have 3 lines you should have 3 s, if you had 2 s you will got 2 lines. That's it. Hope that helps. -- Sincerely, Pan, Shi Zhu. ext: 2606
Re: finding extra { braces
"Yakov Lerner" <[EMAIL PROTECTED]> 写于 2006-12-01 07:45:02:
> It is easy to identify extra '}' in the .c source, compiler
> points us to the exact line. Rarely, I have the opposite error,
> the extra '{' somewhere in the source. For example
> int foo() {
> {
>
> }
> In this case, gcc points me to the end of file. This is not helpful.
> Can anyone suggest quick method of finding the function
> that contains extra '{' brace ?
At the last line:
press o, insert }, press , press %
this may not found exact the place, but it will go to the function which
has the extra '{'
if the '{' is inside the function, you may then find it within the
function.
goto the end of the function and press % at the last '}' of the function to
find where the extra '{' lies..
--
Sincerely, Pan, Shi Zhu. ext: 2606
possible bug for syntax/vim.vim?
if I had the following in a vim script:
call FooBar('xxx'
\ 'yyy')
then the last character ')' will be highlight as Error.
It seems that the '\' continued line are not recognized well.
My :version
VIM - Vi IMproved 7.0 (2006 May 7, compiled Sep 15 2006 16:06:30)
Included patches: 1-76
--
Sincerely, Pan, Shi Zhu. ext: 2606
Anyway to reduce the spaces in TagList Window for Taglist plugin?
Hi, I'd been used the taglist plugin for times but found it useful. The issue is it is too agressive on screen space. There are 4 spaces before all identifiers and 2 spaces before each group name. Normally I'll set the font size so that the screen can take up 80 to 100 columns and leave the Taglist as 20-columns in width, I don't think the 4 spaces before the identifiers are useful anyway, and it wastes 1/5 of the window space. Also, the 2 spaces before groupname are not as desired. Anyway to disable the preceding spaces on all lines? -- Sincerely, Pan, Shi Zhu. ext: 2606
Re: How to avoid highlighting identifiers as misspelt words?
news <[EMAIL PROTECTED]> 写于 2006-11-28 21:18:55:
> I'd like to know if there is a way to tell Vim to recognize identifiers
> occurring inside the comments/strings in source code as being valid
words.
> E.g. if I have
>
> // function foo() does whatever it does
> ~~~
> void foo() { ... }
>
> and "spell" option is on, the first "foo" is highlighted as a misspelt
word
> as indicated above (the second one isn't as spell checking is done only
inside
> comments and strings (which is good, but not quite enough)). Is there any
way
> to ignore all identifiers for spell checking? E.g. ignore all words
occurring
> outside of comments/strings in the same buffer or maybe all identifiers
from
> the tags file or maybe something even better which I didn't think of?
>
> Thanks in advance for any ideas,
Generally, it is not a good practice to use // or /* */ to comment out
codes. (a better approach might be "#if 0" and "#endif"), so if you use #if
0 there would not be problem.
If you just want all identifiers to be valid word, there has been somewhere
a method to permenantly add all identifiers in a tags file to your
dictionary. But it is inconvinient, since tags file will change frequently,
and you may want to use different tags file with different project.
--
Sincerely, Pan, Shi Zhu. ext: 2606
Re: an uncomfortable thing
Ronald <[EMAIL PROTECTED]> 写于 2006-11-28 13:30:27: > I am new. > Usually when I am in command mode (I mean when I pressed ESC), the > cursor shape becomes a block, it is well that when I press `i' or `a' > the cursor will become a bar at the left or right side of the block. > But here is a problem, when I want to enter something like: > (test) > I will enter the parentheses first, then I need simple key stokes to > back one letter like: > > control oh or control oi Just press the key will to the trick. So you may want to map () to () HTH -- Sincerely, Pan, Shi Zhu. ext: 2606
Re: compile code from within vim
"atstake atstake" <[EMAIL PROTECTED]> 写于 2006-11-27 09:37:40: > I'm using vim 6.4.7 on Fedora Core 5. I would like to compile C, > Perl, ruby & bash script from within vim. I want vim to recognize a file > by extenstion and if I map it to, say, vim would be able to compile > the code based on the extension; eg. if it's a .pl file it would do > "perl filename", show the result and if there's any error it would take > me to the line where the error is. > > Is there any easy way to do this with functions? Any example would be > greatly appreciated. > > Thanks. The feature is already supported by Vim, and I bet that's the Vim native way to do that. See: :h :make_makeprg If you would like to know how this works, See also: $VIMRUNTIME/compiler/*.vim For example: $VIMRUNTIME/compiler/perl.vim In gerneral, each language has a "compiler script" describing which external compiler to use to compile the file and has the regexp patterns to parse the error message. If a file does not has compiler script by default or if you want to override something, you can write you own one in your ~/.vim/compiler/ After all, all you need to do is to :make, it will find the right compiler for current language and compile, and parse the output, move to the line of first error. And if you want , just do the following: :map :w:make -- Sincerely, Pan, Shi Zhu. ext: 2606
Re: Can't change search background color
Larry Alkoff <[EMAIL PROTECTED]> 写于 2006-11-21 17:25:13: > I'm using Vim64 in Kubuntu and cannot change the color background when > doing a search. The background color is a kind of darkish orange - I > _think_ it's numbe 3. I'd like to have LightYellow but nothing I have > done so far changes it. > " result of :hi search is > " xxx term=reverse ctermbg=3 (orangy) 14 is ltyellow Usually, it is impossible to set a ctermbg to 8 or above for terminals, especially when you have t_Co=8, i.e. your terminal is 8-color terminal. Sometimes, manually :set t_Co=16 does the trick, if that works for you, then just do it. But it may not work. If you still want a light background, there're several solutions: 1. Get a terminal emulator with fully 16-color support, or even 256-color terminal emulator which has support for ctermbg >= 8. --- this works for yourself. 2. Do not use ctermbg >= 8 when designing color schemes. Note this is important if you want your color scheme portable, because many terminal emulators cannot have light background. --- this works for everyone. HTH. -- Sincerely, Pan, Shi Zhu. ext: 2606
Re: vim encryption
"Noah Spurrier" <[EMAIL PROTECTED]> 写于 2006-11-22 04:14:52: > I am not so concerned with strong encryption > (although, I'd be sad if the encryption turned out to be trivial). > At the moment my main goal is to be able to write > VIM compatible encrypted files from a PHP or Python script. > Just :h :X and looked down for one or two pages you will found the text, and I guess that's what you're looking for . editing.txt line 1379: - Pkzip uses the same encryption, and US Govt has no objection to its export. Pkzip's public file APPNOTE.TXT describes this algorithm in detail. -- Sincerely, Pan, Shi Zhu. ext: 2606
Re: question on using vim with cscope & ctags
tux <[EMAIL PROTECTED]> 写于 2006-11-15 12:47:07: > Is there any way by which I can redirect the matching tag list or > matching cscope entries to a buffer? > If so, is it possible to open the buffer with the tags list/cscope > similar to file explorer? That is, pressing enter when the cursor is > under tag entry should open the source file containing the tag/cscope > entry in another buffer. Will that really be faster? If there're multiple matches you'll always need to choose. If you want the entries in a buffer, simply open the tags file (yes, the file named 'tags'), and you've got all tag entries in the file, find the entry you want and press Ctrl-] will get you want. It is possible if you want to map to that. -- Sincerely, Pan, Shi Zhu. ext: 2606
Re: vim7: why does patchmode create 0-byte files?
David Thompson <[EMAIL PROTECTED]> 写于 2006-11-15 14:56:15: > I'm using 'patchmode=.orig' in my ~/.vimrc, > when I edit a new file such as xxx that does > not exist, then save that file, I also get a > 0-byte file called xxx.orig. This 0-byte > file seems rather pointless. > > To recreate, > > vim -u NONE xxx > :set patchmode=.orig > iHello World > :wq > > then 'ls -l' and it shows, > > -rw-r--r-- 1 davidt core 12 Nov 14 22:47 xxx > -rw-r--r-- 1 davidt core0 Nov 14 22:47 xxx.orig > > I don't understand why vim cannot avoid creation of > the 0-byte xxx.orig upon first creation of xxx. > > IMHO, this is a bug. Anyone agree? > > My 'vim --version' output is, > >VIM - Vi IMproved 7.0 (2006 May 7, compiled Oct 24 2006 17:24:02) >Included patches: 1-4, 6-26, 29-31, 33-44, 46-56, 58-64, 66-73, 75-91 >[snip] > > Regards, > > David I can't see this to be a bug, Vim is doing exactly what it is told to and everything is well documented. see :help 'patchmode' in options.txt line 4919: If there was no file to be backed up, an empty file is created. HTH. -- Sincerely, Pan, Shi Zhu. ext: 2606
Re: Your best text/code formatting trick
Kim Schulz <[EMAIL PROTECTED]> 写于 2006-11-13 04:29:53: > I am currently looking into different tricks for formatting text, > code, etc. in Vim. > I guess most users know the format-paragraph command gqq or the > reindent entire code 1G=G > But are there any other neat tricks - which ones are your favorites? > -- Hi, I use GNU indent some time, it should come with most Linux distribution (or you could just install the 'indent' package) and act as a filter. In Windows you could found it in Cygwin. so the command should be :%!indent, or you could just select a paragraph with the visual mode and !indent. GNU indent is fully customizable (write you own rc in ~/.indent.pro), it can reformat the long paragraphs and add/remove spaces between tokens. Develop your own .indent.pro file and it may save huge time in the future for you. The only issue for GNU indent: it supports only Unix text file, so you should :set ff=unix before calling the GNU indent from within Vim. -- Sincerely, Pan, Shi Zhu. ext: 2606
Re: Running own script when editing MATLAB files
"A.J.Mechelynck" <[EMAIL PROTECTED]> 写于 2006-11-09 17:17:05: > > Filetype plugins are sourced if ":filetype plugin on" has been used. > Indent plugins are sourced if ":filetype indent on" has been used. > Syntax scripts are run if both ":filetype on" and ":syntax on" have been used. > > > Best regards, > Tony. So, it seems that the right place to override something is the ~/.vim/after/indent ? (if all he want is to set tabstop shiftwidth expandtab ...) -- Sincerely, Pan, Shi Zhu. ext: 2606
Re: Running own script when editing MATLAB files
Luc Hermitte <[EMAIL PROTECTED]> 写于 2006-11-09 16:35:45: > > Save these commands into your $VIM\vimfiles\after\syntax\matlab.vim > > (Windows platform) > > or ~/.vim/after/syntax/matlab.vim > > This is not the right place to do that. ftplugins are the right > solution. > => ~/.vim/ftplugin/matlab.vim > > And BTW, don't use :set, but :setlocal when you want filetype specific > settings. > > -- I don't know if there's any difference between ftplugin directory and syntax directory. But I did know that you should use ~/.vim/after/xxx instead of ~/.vim/xxx if you want to overwrite something existing (here the matlab exists in the vim standard distribution). Having a ~/.vim/ftplugin/matlab.vim is good only when the $VIMRUNTIME/ftplugin/matlab.vim does not exist. If it exists, you have risk of lose the settings there. The difference is: if you put into ~/.vim/ftplugin, you will overwrite the system default, if the system default does something else than set the options you will lose those settings. so, put into ~/.vim/after/ftplugin (In my practise it should be ~/.vim/after/syntax) seems to be always a better choice. -- Sincerely, Pan, Shi Zhu. ext: 2606
Re: Running own script when editing MATLAB files
"Zachary Leung" <[EMAIL PROTECTED]> 写于 2006-11-09 15:19:29: > Hi, > > I'd like to run these commands everytime I edit a MATLAB file. How > do I do that? > > set shiftwidth=4 > set tabstop=4 > set expandtab > > Thanks! > Zac > > -- > Jesus said, "I am the door of the sheep. If anyone enters by me, he > will be saved and will go in and out and find pasture." > John 10:9 Save these commands into your $VIM\vimfiles\after\syntax\matlab.vim (Windows platform) or ~/.vim/after/syntax/matlab.vim -- Sincerely, Pan, Shi Zhu. ext: 2606
Re: Spurious "undefined variable" error generated for certain valid ternary expressions
"Stahlman Family" <[EMAIL PROTECTED]> 写于 2006-11-09 09:40:49: > > 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. > By the way, you should also know that "you should never add a space before [ ]". the abc [1] works in Vim6, but in Vim 7 there should not be a space so there must be abc[1]. I don't know why there is such a requirement in Vim 7, but it breaks one of my script. -- Sincerely, Pan, Shi Zhu. ext: 2606
Re: Command line tab completion
Benji Fisher <[EMAIL PROTECTED]> 写于 2006-11-02 22:21:36: > I agree with Gary. I tried > $ vim -u NONE > :set nocp wildmenu wildmode=longest:list > :help termi > :help preser > > I was hoping for "termin" in the first case and "preserve" in the > second, but I was stuck with "termi" and "preser". > > HTH --Benji Fisher > > P.S. Has there been a patch that affects this? I am still using vim > 7.0.000 . No, yours are different from Gary. Your completion does not seem to be working at all and you should check your settings, Gary's completeion works but not as he expected. What Gary has said is: when :help preser expands to :help :preserve, it will fail to expand :help :preservi to :help 'preservindent'. My suggestion to Gary: if you want a completion of 'preserveindent', type :help 'pres and it will complete to :help 'preserveindent' immediately. that is much easier than :help presi... Don't expect the completion to work perfectly when you had ommited the colon or quotation mark. -- Sincerely, Pan, Shi Zhu. ext: 2606
Re: Command line tab completion
Gary Johnson <[EMAIL PROTECTED]> 写于 2006-11-02 15:55:34: > > This behavior might be affected by 'wildmode'. Mine is set to > "longest,list". I also tried "longest,list:longest", but the > behavior was the same. > > Regards, > Gary To make things clear, I had just tried: vim -u NONE -U NONE then :set nocp (Must set nocompatible or the tab completion will be disabled.) and then :help pre followed by It works well, so the completion should be okay on default. You can try that also, if that works for you, then you may need to check your ~/.vimrc and your ~/.vim directories to see what's different from the default. Then reset the suspected option to default. -- Sincerely, Pan, Shi Zhu. ext: 2606
Re: Command line tab completion
Gary Johnson <[EMAIL PROTECTED]> 写于 2006-11-02 09:26:41: > > I don't think that's the issue, as I understand it. As another > example, if I type > > This has bothered me for some time--it just never rose above my > posting threshold until someone else brought it up first. What is your 'completeopt' setting? I do never have the problem like yours. If I type :help termi followed by , it complete things as I'd expected. -- Sincerely, Pan, Shi Zhu. ext: 2606
Re: Command line tab completion
"A. S. Budden" <[EMAIL PROTECTED]> 写于 2006-11-01 23:46:04: > Is this because of the quotes (due to it being a setting) or the 'no' > variation or is it because of something else? Is there any way to get > round it? > > Many thanks in advance, > > Al Yes this is because of the quote. you should type :help 'preserv then press TAB, and you'll get what you want. -- Sincerely, Pan, Shi Zhu. ext: 2606
Re: Cygwin defaced Vim. Help.
"Ananya M (RBIN/ECM1)" <[EMAIL PROTECTED]> 写于 2006-10-31 12:28:23: > Hi, > I am a very new to vim, and am absolutely smitten by it. > I installed cygwin on my comp. > Now gVim is showing up with '$' symbols at the end of every line, > and ugly '>-' headless arrows at the start of every line. > Also while in INSERT mode each press of the spacebar results in a $ > sign showing up at the cursor. Even my favorite "Crisp" font is not > being used by vim despite of having an entry in _vimrc. > I tried to tweak _vimrc but it didn’t help. > Attached is copy of my _vimrc file. (text version, my fwall blocks > unknown extensions!) How did you get your gVim? in Windows there can be several versions: 1. Compiled in Cygwin by make -f Makefile, this could run in cygwin/X 2. Compiled in Cygwin by make -f Make_cyg.mak, this is Windows native version compiled by cygwin 3. Compiled with VC by nmake -f Make_mvc.mak, this is Windows native version compiled by vc If you want gVim, I recommend a Windows native version in Windows, not the cygwin/X version. -- Sincerely, Pan, Shi Zhu. ext: 2606
Re: VIM 7.0 under Windows and Unicode fonts
"Yongwei Wu" <[EMAIL PROTECTED]> 写于 2006-10-30 10:41:21: > Alex, if you cannot display Chinese while choosing Courier New, you > may try setting your default locale (Control Panel > Regional and > Language Options > Advanced > Language for non-Unicode programs) to > Chinese (PRC). It should work. And then you will be able to edit > English, French, Greek, Russian, Chinese, Japanese, and Arabic > simultaneously. > > Best regards, > > Yongwei A little off-topic, but AFAIK this works perfect in Windows but not identical in Linux, since Windows do not connect the internal processing locale to the locale of user interfaces. The UI will never change when you change the locale. (That's a good design IMO) When you change the locale in Linux, the messages, menu texts are all changed to the targeting locale after reboot. So it is hard to have a Chinese UI and retain English locale, and it might be more difficult to have a Chinese locale while retain English UI. Alex's case is an example, if what he want is to display chinese correctly, set locale to chinese is an easy way, but he might be troubled if all the messages in the UI also changed into chinese. -- Sincerely, Pan, Shi Zhu. ext: 2606
Re: tags with abc::efg?
Beware, add the colon to 'iskeyword' works but it may mess up one thing:
the switch-case statement and the label:
switch (foo) {
case bar:
}
here the "bar" will be recognized as "bar:", and of course the "bar:" does
not exist. It will be inconvinient to search "bar" using the "*" or the
"", pretty annoying.
Unless we could add "::" to 'iskeyword' instead of the single colon, it
seems to be difficult to cope with this.
Any hints?
--
Sincerely, Pan, Shi Zhu. ext: 2606
Henry <[EMAIL PROTECTED]> 写于 2006-10-28 08:59:38:
>
>
> AJ,
>
> Thank you very much. This is what I was looking for.
>
> Sincerely,
> Henry
>
> --- "A.J.Mechelynck" <[EMAIL PROTECTED]>
> wrote:
>
> > Henry wrote:
> > > Hi,
> > >
> > > I have a bunch TCL procs defined with :: in the
> > name.
> > > ie: abc::efg.
> > >
> > > I created a tags file, inside the tag file, it has
> > > abc::efg
> > >
> > > When I try to jump to this proc "abc::efg" in vim,
> > > using CTRL-], it can't find it. If cursor is under
> > > abc, then I get an message "E426: tag not found:
> > abc"
> > > If the cursor is under efg, then I get a message
> > > "E426: tag not found: efg". So it seems that vim
> > can't
> > > trace the tag properly. It should use the entire
> > > string "abc::efg" to search for the tag.
> > >
> > > Anybody has a solution??
> > >
> > > Thanks.
> >
> > I think it has something to do with your 'iskeyword'
> > option. Try using
> >
> >:setlocal isk+=:
> >
> > (adding the colon to the 'iskeyword' option) on the
> > files which have that kind
> > of tags. Or, if it is for any TCL files, you might
> > want to add the above
> > command (without the initial colon) in a file named
> > (on Unix-like systems)
> > ~/.vim/after/ftplugin/tcl.vim or (on other systems)
> > ~/vimfiles/after/ftplugin/tcl.vim (in both cases in
> > "vim" notation).
> >
> > Create the file and any directories in its path if
> > they don't exist yet. You
> > might for instance paste the following lines as a
> > *.vim script and source it
> > (this is untested):
> >
> >if has("unix")
> > !mkdir -p ~/.vim/after/ftplugin
> > let s:vimdir = ".vim"
> >else
> > silent! !mkdir $HOME/vimfiles
> > silent! !mkdir $HOME/vimfiles/after
> > silent! !mkdir $HOME/vimfiles/after/ftplugin
> > let s:vimdir = "vimfiles"
> >endif
> >exe 'new ~/' . s:vimdir . '/after/ftplugin/tcl.vim'
> >$put ='setlocal isk+=:'
> >wq
> >
> > See
> >:help 'iskeyword'
> >:help after-directory
> >etc.
> >
> >
> >
> > Best regards,
> > Tony.
> >
>
>
>
>
>
>
>
> Low, Low, Low Rates! Check out Yahoo! Messenger's cheap PC-to-Phone
> call rates
> (http://voice.yahoo.com)
>
Re: Bold font in OS X GUI?
Peter Hodge <[EMAIL PROTECTED]> 写于 2006-10-25 14:54:16: > > I can use guifont=*, and have tried many different fonts which have bold and > italic glyphs. The problem is that no matter which font I choose, Vim refuses > to show text in Bold (Unless I choose a font which has only a bold glyph). I > get the impression it's a shortcoming of the OS X GUI, because underlined text > doesn't work either (Vim reverses the bg/fg colors instead). > Really? Do you mean: you selected a bold font as the gui font but the gui displayed it as the corresponding "regular" font for that bold font? If that's true, I'd wonder how this version is compiled...Any clue for :version? I guess it's not the shortcoming of the OSX gui, but the vim need to be recompiled with different settings. -- Sincerely, Pan, Shi Zhu. ext: 2606
Anyway to sort scripts by last update date?
Hi, The vim.sf.net has a script search feature which can sort by Rating, Downloads, Name and Creation date. And can be filtered by type. If we want to see in the specified category which scripts has been updated (or created) recently, the only way seems to choose the creation date and decending order. However this will only show scripts recently "created" not the scripts recently "updated". For example, there're 374 syntax scripts and I want to see which has been updated or created since January 1st 2006. This seems to be a reasonable query but I've got no idea how to do it. Any hints? Thanks. -- Sincerely, Pan, Shi Zhu. ext: 2606
Re: Fighting with comments - Close the gap between vimtutor and :help
vim <[EMAIL PROTECTED]> 写于 2006-10-20 15:50:36: > Hi everobody, > > I believe that there is room between vimtutor and :help to have some > beginner to intermediate tutorial that will take you by the hand and > bring you through the Vim universe in a nice and easy way. There already is one close to your description. (Is it an official one? I don't know.) It's a PDF document and can be downloaded somewhere... I forget the name but it might be Vim Tutorial... When I've found it I'll post it again. -- Sincerely, Pan, Shi Zhu. ext: 2606
Re: Anybody can tell me how to use "auto add "
"李 俊燕" <[EMAIL PROTECTED]> 写于 2006-10-20 14:17:55: > hi,all > > I don't know how to say that. > I just remember that I can type [ control - a ] before a number > to let it add 1, for example let 1 change to 2. > But it doesn't work in gvim 7.0 for windows. > Is there any other method to do that? > > thank you very much. > Li If you had sourced the vimrc_example.vim, the mswin.vim might be sourced, then the Ctrl-A will be mapped to something else. So, you have to choices: 1. remove the reference to the mswin.vim, you can search and find which script call the mswin.vim and remove it. or just: 2. unmap all the remappings to Add the following to the end of your .vimrc: " CTRL-A is the default unmap unmap! -- Sincerely, Pan, Shi Zhu. ext: 2606
Re: What's the exact meaning of the set 'background'?
Peter Hodge <[EMAIL PROTECTED]> 写于 2006-10-19 13:44:19: > Hello, > > If you change the background=light, Vim reloads the colorscheme so it has a > chance to give you new colors. But if the colorscheme changes background=dark > again, then Vim knows that the colorscheme isn't capable of picking colors for > a light background. In that case, Vim will just ignore whatever the > colorscheme says and will use default colors instead. > > regards, > peter This is a good choice anyway, if the colorscheme can only do bg=dark and the user want bg=light, the defaults are loaded... However, this "feature" seems to be buggy: When I'm using a dark-background scheme, I want a light background and type :set bg=light. It tries to load the color scheme and found the color scheme set bg=dark, then it ignores the color scheme then loads the default. If all you said is true, I expect the bg=light now and the light-background version of the default should be loaded. however the bg=dark now, and the dark-background version of the default color scheme is loaded. A bug ? -- Sincerely, Pan, Shi Zhu. ext: 2606
Re: What's the exact meaning of the set 'background'?
"A.J.Mechelynck" <[EMAIL PROTECTED]> 写于 2006-10-19 13:42:46: > (I "think" I read the help correctly in > understanding that ctermbg=NONE and ctermfg=NONE are not syntactically valid > settings, but I'm not 100% sure that I understood it correctly.) > > > Best regards, > Tony. Hi Tony, Thanks very much for your through explanation, I'll read it for some more time. What I can confirm is that you have not correctly understand one thing: ctermbg=NONE is valid and this setting is very important for most color-scheme developers. It means the background being transparent. i.e. when the ctermbg=NONE, the background color will be the same as the terminal background, if your terminal can have a semi-transparent background, then the background color of the highlight group will be semi-transparent. Note that the ctermfg=bg and ctermbg=bg is not possible when ctermbg=NONE. And the ctermbg=NONE is the Vim default setting for most highlight groups! You must override all those defaults if you don't want the background be determined by the terminal instead of your Vim colorscheme. If you set the ctermbg=Black, then it will always be black, even if your terminal has a light background by default. So generally you don't need to worry about the default background of your terminal. What you need to do is to set ctermbg=Black for Normal highlight group and set ctermbg=bg for all the rest of highlight groups which you expect the same background as the Normal highlight group. If I had not misunderstood the Vim Help document, I should have this: when the color scheme overrides all the default values, the 'background' option will have no effect since it only changes the default highlight and they are all overriden by the color scheme. This seems to be a "frozen" way but it works better for me. Consider that the gvim will always have the background="light" and the cterm will have this determined by the terminal. Many 8-color terminal cannot have a bright color as the background so it is not be very portable to design a light-background scheme for color terminal. I forced dark background for color terminal then nothing need to be detected. -- Sincerely, Pan, Shi Zhu. ext: 2606
