Re: Mapping doesn't work in putty.
J A G P R E E T wrote: Hi There, I have these mappings defined in my .vimrc file. map :tabnew map :tabp map :tabn I'm using putty(terminal emulator) to access the unix server. The fist mapping works absolutely fine. The other two doesn't work at all and gives the error(E388: Couldn't find definition). Furthermore I checked shows the definition for the variable under cursor. No clues why its not overridden from my mapping. When I changed map : tabp to Map : tabp It works. Another point is the mapping(, ) works if I use Exceed or x-Manager. I have no clue at all why its not working in putty. As far as I know for mapping at least; graphics support is not a must. Whats missing for this mapping in putty. Regards, Jagpreet This is the kind of error that could be the result of a bad or incomplete termcap/terminfo entry. In console Vim, you can see what codes any key or keychord sends to Vim by hitting it in Insert mode, prefixed by Ctrl-V (or by ctrl-Q if your Ctrl-V is the "paste" key). In gvim the same procedure (on a non-printable key or keychord) gives you the <> notation for what gvim "thinks" you have pressed. By the above method you can check, for instance, if Vim can tell the difference between Left and Ctrl-Left, Right and Ctrl-Right. (When I run Vim in GUI mode, it can; when I run the same executable in console mode, either in a konsole "xterm" or in /dev/tty with no access to X-windows, it cannot). If it cannot tell the difference, then you must use something else for the {lhs} of your mappings -- and are likely candidates. If Vim can tell the difference, it still mightn't know that what you've hit is Ctrl-Left. In that case, one method (there are others) is to use the raw keycode sequence as the {lhs} of the mapping. You may have to bracket the mapping definition by a test on &term since different terminals give different keycodes. Example (in the vimrc): if has("gui_running") || (&term == "win32") || (&term == "pcterm") " we're either on our way to a GUI session " or on a terminal where etc. are defined correctly map :tabprev map :tabnext elseif &term =~ '^xterm' " local xterm console " and are the same " map Backslash-Left instead map OD :tabprev map OC :tabprev elseif &term == "linux" " non-X text console " here too, map Backslash-Left map [D :tabprev map [C :tabnext elseif &term == "putty" " putty connection " ... etc. ... else " unknown type of console terminal " assume that is OK but isn't map :tabprev map :tabnext endif Note: The expression (&term == "putty") is a guess on my part. You may have to use something else depending on what Vim sees as the terminal type when in a putty session. Best regards, Tony
Automatically adding header into file with specific extension
Hi, I want to be able to have VIM automatically insert this line: #!/usr/bin/python Whenever I open a NEW file with *.py or *.egg extension for example under bash $ vi mycode.py or $ vi mycode.egg or under VI : e mycode.py Is it possible? -- Gundala Viswanath
Re: Automatically adding header into file with specific extension
On 10/18/06, Gundala Viswanath <[EMAIL PROTECTED]> wrote: Hi, I want to be able to have VIM automatically insert this line: #!/usr/bin/python Whenever I open a NEW file with *.py or *.egg extension How about this (in your ~./vimrc): au BufNewFile *.py,*.egg :call setline(1, "#!/usr/bin/python") Yakov
Re: Automatically adding header into file with specific extension
hi, please take a look at vim tip #434 the example there is for *.h and *.cpp files but you might find some idea from it. hth, ymc - Original Message - From: "Gundala Viswanath" <[EMAIL PROTECTED]> To: Sent: Wednesday, October 18, 2006 4:19 PM Subject: Automatically adding header into file with specific extension > Hi, > > I want to be able to have VIM automatically > insert this line: > > #!/usr/bin/python > > Whenever I open a NEW file with *.py or *.egg extension > for example > > under bash > $ vi mycode.py > > or > > $ vi mycode.egg > > or under VI > > : e mycode.py > > Is it possible? > > -- > Gundala Viswanath >
Re: (2) Mapping doesn't work in putty.
J A G P R E E T wrote: [...] Furthermore I checked shows the definition for the variable under cursor. [...] Oh! I missed this. The default action for Ctrl-Left is to go to the previous word in the file. Maybe the mapping which "shows the definition for the variable" is defined after the one in your vimrc (in a plugin maybe)? That is easy to check in Vim 7 (but not so easy in Vim 6): :verbose map will (in Vim 7) tell you which script (if any) defined the mapping. If the mapping is set in a plugin, the trick is to define your own mapping after it. For a global plugin, autocmd VimEnter * map :tabprev autocmd VimEnter * map :tabnext (in your vimrc) will do the trick. For a filetype-plugin (let's assume $VIMRUNTIME/ftplugin/c.vim for the sake of argument) you need to create an after-plugin: --- start ~/.vim/after/ftplugin/c.vim --- map:tabprev map :tabprev --- end ~/.vim/after/ftplugin/c.vim --- Your after-plugin should have the same name and be at the same location in a directory tree later in 'runtimepath' than the culprit. (~/.vim/after is for Unix; on Windows use ~/vimfiles/after instead.) Create the file and its directory if they don't already exist. Note that a well-behaved filetype-plugin should use "map " and not just "map", "setlocal" and not just "set" etc. to avoid interference with files of other filetypes which could be edited in split windows. Best regards, Tony.
Re: Automatically adding header into file with specific extension
Thanks Yakov, It works! au BufNewFile *.py,*.egg :call setline(1, "#!/usr/bin/python") But, how can we insert more than 1 lines? For example I want: #!/usr/bin/python import os import sys To be inserted. -- Gundala Viswanath
RE: Mapping doesn't work in putty.
Hi Peter, It doesn't work in this case either. But I got the solution from Tony. Thanks a lot for your efforts. Regards, Jagpreet -Original Message- From: Peter Hodge [mailto:[EMAIL PROTECTED] Sent: Wednesday, October 18, 2006 12:18 PM To: J A G P R E E T; Vim mailing list Subject: Re: Mapping doesn't work in putty. Perhaps you could use: map [ctrl-v][ctrl-left] :tabp map [ctrl-v][ctrl-right] :tabn Except instead of typing 'ctrl-v' and 'ctrl-left' literally, you type those combinations instead. This will map the exact escape sequences that your terminal is sending. regards, Peter --- J A G P R E E T <[EMAIL PROTECTED]> wrote: > Hi There, >I have these mappings defined in my .vimrc file. > > map :tabnew > map :tabp > map :tabn > > I'm using putty(terminal emulator) to access the unix server. > > The fist mapping works absolutely fine. > The other two doesn't work at all and gives the error(E388: Couldn't find > definition). > Furthermore I checked shows the definition for the variable under > cursor. > No clues why its not overridden from my mapping. > > When I changed map : tabp to > Map : tabp > It works. > > Another point is the mapping(, ) works if I use Exceed or > x-Manager. > I have no clue at all why its not working in putty. > As far as I know for mapping at least; graphics support is not a must. > > Whats missing for this mapping in putty. > > Regards, > Jagpreet > > > > On Yahoo!7 Men's Health: What music do you want to hear on Men's Health Radio? http://www.menshealthmagazine.com.au/
RE: Mapping doesn't work in putty.
Thanks a ton Tony. I checked how putty is treating to left and . The new settings which is working(for putty and xterm as well) in my case is. map :tabnew if has("gui_running") || (&term == "win32") || (&term == "pcterm") || (&term == "xterm") map : tabprev map : tabnext else map [D :tabprev map [C :tabnext endif It was tough for me but your valuable input made it easy. Regards, Jagpreet -Original Message- From: A.J.Mechelynck [mailto:[EMAIL PROTECTED] Sent: Wednesday, October 18, 2006 1:38 PM To: J A G P R E E T Cc: Vim mailing list Subject: Re: Mapping doesn't work in putty. J A G P R E E T wrote: > Hi There, >I have these mappings defined in my .vimrc file. > > map :tabnew > map :tabp > map :tabn > > I'm using putty(terminal emulator) to access the unix server. > > The fist mapping works absolutely fine. > The other two doesn't work at all and gives the error(E388: Couldn't find > definition). > Furthermore I checked shows the definition for the variable under > cursor. > No clues why its not overridden from my mapping. > > When I changed map : tabp to > Map : tabp > It works. > > Another point is the mapping(, ) works if I use Exceed or > x-Manager. > I have no clue at all why its not working in putty. > As far as I know for mapping at least; graphics support is not a must. > > Whats missing for this mapping in putty. > > Regards, > Jagpreet > > > > This is the kind of error that could be the result of a bad or incomplete termcap/terminfo entry. In console Vim, you can see what codes any key or keychord sends to Vim by hitting it in Insert mode, prefixed by Ctrl-V (or by ctrl-Q if your Ctrl-V is the "paste" key). In gvim the same procedure (on a non-printable key or keychord) gives you the <> notation for what gvim "thinks" you have pressed. By the above method you can check, for instance, if Vim can tell the difference between Left and Ctrl-Left, Right and Ctrl-Right. (When I run Vim in GUI mode, it can; when I run the same executable in console mode, either in a konsole "xterm" or in /dev/tty with no access to X-windows, it cannot). If it cannot tell the difference, then you must use something else for the {lhs} of your mappings -- and are likely candidates. If Vim can tell the difference, it still mightn't know that what you've hit is Ctrl-Left. In that case, one method (there are others) is to use the raw keycode sequence as the {lhs} of the mapping. You may have to bracket the mapping definition by a test on &term since different terminals give different keycodes. Example (in the vimrc): if has("gui_running") || (&term == "win32") || (&term == "pcterm") " we're either on our way to a GUI session " or on a terminal where etc. are defined correctly map :tabprev map :tabnext elseif &term =~ '^xterm' " local xterm console " and are the same " map Backslash-Left instead map OD :tabprev map OC :tabprev elseif &term == "linux" " non-X text console " here too, map Backslash-Left map [D :tabprev map [C :tabnext elseif &term == "putty" " putty connection " ... etc. ... else " unknown type of console terminal " assume that is OK but isn't map :tabprev map :tabnext endif Note: The expression (&term == "putty") is a guess on my part. You may have to use something else depending on what Vim sees as the terminal type when in a putty session. Best regards, Tony
Re: Automatically adding header into file with specific extension
au BufNewFile *.py,*.egg :call setline(1, "#!/usr/bin/python") But, how can we insert more than 1 lines? For example I want: #!/usr/bin/python import os import sys To build on Yakov's suggestion, you should be able to put whatever lines you want in a file (called, say ~/.python_template) and then use au BufNewFile *.py,*.egg :0r ~/.python_template which should then read the contents of that file into the top of the new buffer. -tim
Re: search visual block
Jean-Rene David wrote: * Lev Lvovsky [2006.10.17 17:15]: Is it possible to search for a string by selecting that string in visual mode? Meaning, if I highlight something, and then want to search for that thing which is highlighted in the rest of the doc? You already got lots of good answers. Here's another one. I've had this in my vimrc for years, and use it when the string I'm searching for is not a keyword. It works both forward and backward, puts the searched pattern in the search history and doesn't screw up any register. "--< cut here >--- " Search for visually selected text {{{ " From an idea by Michael Naumann, Jürgen Krämer. function! VisualSearch(direction) range let l:saved_reg = @" execute "normal! vgvy" let l:pattern = escape(@", '\\/.*$^~[]') let l:pattern = substitute(l:pattern, "\n$", "", "") if a:direction == 'b' execute "normal ?" . l:pattern . " " else execute "normal /" . l:pattern . " " endif let @/ = l:pattern let @" = l:saved_reg endfunction vnoremap * :call VisualSearch('f') vnoremap # :call VisualSearch('b') "--< cut here >--- HTH, This sounds brilliant Jean-Rene, I put it into my .vimrc, but it doesn't seem to work, I did notice that between the if and else there are " which just act as comments as they are on newlines, didn't know if this was just my text wrapping, so I tried putting them on the line above, both with a space between or not, didn't know if that might be cause but that didn't seem to help either. Sorry I may be missing something obvious, but I'd like to get this to work as it seems very useful. I was selecting text in visual mode, then pressing / or ? and I just get the normal action of pressing / or ? Thanks, Rob.
Wrapping by substitution
I'm having a mental block, how can I wrap a string via substitute() ? I've been trying something like: let str = "123456789012345678901234567890" let str = substitute(str, '\n\([[:print:]]\{-10,}\)', '\n\1\n', '') echo str to produce: 1234567890 1234567890 1234567890 -- Steve Hall [ digitect dancingpaper com ]
Re: Wrapping by substitution
I'm having a mental block, how can I wrap a string via substitute() ? I've been trying something like: let str = "123456789012345678901234567890" let str = substitute(str, '\n\([[:print:]]\{-10,}\)', '\n\1\n', '') echo str to produce: 1234567890 1234567890 1234567890 The following seems to do the trick for me: echo substitute(str, '[[:print:]]\{,10}', '&\n', 'g') which should also gracefully handle "123456789012345678901234567890123" (with the extra trailing 123 at the end, making it a non-even multiple of 10) -tim
Re: Wrapping by substitution
On 10/18/06, Steve Hall <[EMAIL PROTECTED]> wrote: I'm having a mental block, how can I wrap a string via substitute() ? I've been trying something like: let str = "123456789012345678901234567890" let str = substitute(str, '\n\([[:print:]]\{-10,}\)', '\n\1\n', '') echo str to produce: 1234567890 1234567890 1234567890 Try echo substitute(str,'\(.\{-10}\)','\1\n','g') Yakov
RE: Wrapping by substitution
From: Tim Chase, Wed, October 18, 2006 6:46 am > > > I'm having a mental block, how can I wrap a string via > > substitute() ? > > The following seems to do the trick for me: > > echo substitute(str, '[[:print:]]\{,10}', '&\n', 'g') This nearly works, but is doubling existing line breaks. The application is this :version pretty-fier: function! Str_wrap(str, len) return substitute(a:str, '[[:print:]]\{,'.a:len.'}','&\n','g') endfunction function! Version() redir @x silent! version redir END " add some line breaks between major sections let @x = substitute(@x, '\n\([+\-]arabic\)', '\n\n\1', '') let @x = substitute(@x, '\n\(\s\+system\)', '\n\n\1', '') let @x = substitute(@x, '\n\(Compilation\)', '\n\n\1', '') let @x = substitute(@x, '\n\(Linking\)', '\n\n\1', '') " wrap echo Str_wrap(@x, 70) endfunction command! Version call Version() -- Steve Hall [ digitect dancingpaper com ]
Re: Contextual 'iskeyword'?
On Tue, Oct 17, 2006 at 04:54:21PM -0500, Tim Chase wrote: > > Let's think big and look for a generic solution. IMHO, it is way > >too restrictive to insist that a word is anything matching the pattern > >/\k\+/ . I want a new option, 'wordpat', with a default value of > >'\k\+', that specifies what should be recognized as a word, for purposes > >of search patterns, Normal-mode commands such as w and b, and maybe > >other uses. (Oh, yes: Insert-mode completion.) > > > >Examples: > > > >:let &l:wordpat = '\k\+\(-\k\+\)*' > > In the general, I like it! In the implementation, I don't know > if there are snags that one will encounter. One might have to > include the cursor position to anchor it in the search text. I have not thought about implementation. I have been wondering for a while what a good solution to the TeX \long\def\foo problem, where I am not entirely happy with isk+=\ nor with isk-=\ . This is the first idea I have had that might be workable from a user's point of view. I am not sure why you think including the cursor position is important. > Funky conditions could occur if patterns contain certain atoms > (for better or worse). Could things like using \%<9c enforce > that words are only contained before column 9 (makes me think of > my cobol days)? Or even something like '\%>0l\%<42l\k*\%#\k*' > enforce that keywords are only found in the first 41 lines of > your file? Or can keywords only be duplicate-part words like > "mahimahi" using a pattern like '\(\k\+\)\1'? Or keywords are > only ever preceeded by "int" like 'int\_s\+\zs\k+'? Or alter the > behavior of the "*" and "#" commands to find the word that > *preceeds* the word under the cursor with something like > '\k\+\ze\K\+\k*\%#' > > All these seem like sensible (for cases where "sensible" may be a > subset of as "pathological") potential use-cases for such a thing. That is the way generic solutions work. Once you give users the flexibility of specifying any regular expression as an option, they will come up with applications that did not occur to you. Sometimes, they will shoot themselves in the foot. I would expect this option to affect the * and # commands, and also the \< and \> regular expressions. Also the iw text object. HTH --Benji Fisher
Re: Automatically adding header into file with specific extension
Dnia środa, 18 października 2006 10:19, Gundala Viswanath napisał: > Hi, > > I want to be able to have VIM automatically > insert this line: :help skeleton m.
Re: Slightly OT: HELP! IDE ahead !
Dnia środa, 18 października 2006 05:13, A.J.Mechelynck napisał: > Well, I guess if you can configure gvim as your "embedded editor" for > kdevelop, you will be able to edit your files with Vim and "make > believe" that you're using kdevelop, so everyone'll be happy. (My SuSE > system came with kvim set up as the embedded editor for any KDE > applications that use one; but that means a Vim version 6.2.14 -- you > bet I changed that to my homemade 7.0 ! ) If someone want to have Vim7 kvim, he should dig CVS. There was time in alpha state when kvim was in main Vim tree. AFAIK that was before omnicompletion but already with spelling. Application was stable. It was removed because no one was eager to maintain those features. m. ps. With release of Qt4.2 with supported glib event loop I hope someone will try again with qvim (before KDE4 there is no sense to start kvim). But it would require writing from scratch...
Re: Contextual 'iskeyword'?
On Wed, Oct 18, 2006 at 01:21:31AM +0200, A.J.Mechelynck wrote: > > After reading this thread, I've seen "requests for improvement" to the Vim > source; but let's try to find (for the time being) something which works in > the current Vim version. > > 1. Em dashes should normally be set apart from the neighbouring words by > blank spaces -- like this -- and if they are, they won't be mistaken for > part of a word regardless of whether 'iskeyword' includes the dash. [snip] That depends on your style manual. The one I read, back in my typewriter days, insisted on dashes without spaces on either side--like this. Also, vim will recognize your "--" as a word if 'isk' includes "-", and that might cause problems. HTH --Benji Fisher
Re: search visual block
On Wed, Oct 18, 2006 at 12:28:28PM +0200, Robert Cussons wrote: > Jean-Rene David wrote: [snip] > > > >"--< cut here >--- > >" Search for visually selected text {{{ > >" From an idea by Michael Naumann, Jürgen Krämer. > >function! VisualSearch(direction) range > > let l:saved_reg = @" > > execute "normal! vgvy" > > let l:pattern = escape(@", '\\/.*$^~[]') > > let l:pattern = substitute(l:pattern, "\n$", "", "") > > if a:direction == 'b' > > execute "normal ?" . l:pattern . " > >" > > else > > execute "normal /" . l:pattern . " > >" > > endif > > let @/ = l:pattern > > let @" = l:saved_reg > >endfunction > > > >vnoremap * :call VisualSearch('f') > >vnoremap # :call VisualSearch('b') > >"--< cut here >--- > > This sounds brilliant Jean-Rene, I put it into my .vimrc, but it doesn't > seem to work, I did notice that between the if and else there are " > which just act as comments as they are on newlines, didn't know if this > was just my text wrapping, so I tried putting them on the line above, > both with a space between or not, didn't know if that might be cause but > that didn't seem to help either. Sorry I may be missing something > obvious, but I'd like to get this to work as it seems very useful. > I was selecting text in visual mode, then pressing / or ? and I just get > the normal action of pressing / or ? I think the original included raw CR characters in the two :execute lines. Both are intended to end with "^M" (which is how they appeared in my copy of Jean-Rene's note). I think your e-mail client broke the lines, leading to syntax errors. I try to avoid such problems by not including raw CR, ESC, etc. characters in my vim scripts. I suggest replacing the two :execute lines with execute "normal ?" . l:pattern . "\" and execute "normal /" . l:pattern . "\" HTH --Benji Fisher
Re: search visual block
* Robert Cussons [2006.10.18 06:30]: > I did notice that between the if and else there > are " which just act as comments as they are on > newlines, Sorry, I should have known that wouldn't come out right. There's a literal newline between the quotes. You can enter it by pressing . Here's that section of code with the literal newline entered as two separate characters: if a:direction == 'b' execute "normal ?" . l:pattern . "^M" else execute "normal /" . l:pattern . "^M" endif > I was selecting text in visual mode, then > pressing / or ? and I just get the normal action > of pressing / or ? Well you could do it with "/" and "?" but I like to keep their behavior intact as it is useful to extend the visual region. I remapped "*" and "#" instead, as shown in these lines: vnoremap * :call VisualSearch('f') vnoremap # :call VisualSearch('b') I prefer that because these don't have any special meaning in visual mode and it ties in nicely with the "search next/previous word" function they have in normal mode. -- JR
Re: Wrapping by substitution
Steve Hall wrote: From: Tim Chase, Wed, October 18, 2006 6:46 am I'm having a mental block, how can I wrap a string via substitute() ? The following seems to do the trick for me: echo substitute(str, '[[:print:]]\{,10}', '&\n', 'g') This nearly works, but is doubling existing line breaks. The application is this :version pretty-fier: function! Str_wrap(str, len) return substitute(a:str, '[[:print:]]\{,'.a:len.'}','&\n','g') endfunction function! Version() redir @x silent! version redir END " add some line breaks between major sections let @x = substitute(@x, '\n\([+\-]arabic\)', '\n\n\1', '') let @x = substitute(@x, '\n\(\s\+system\)', '\n\n\1', '') let @x = substitute(@x, '\n\(Compilation\)', '\n\n\1', '') let @x = substitute(@x, '\n\(Linking\)', '\n\n\1', '') " wrap echo Str_wrap(@x, 70) endfunction command! Version call Version() What about this? redir! > version.txt silent version redir END new version.txt setlocal textwidth=70 " remove empty lines at top 1,/Vi IMproved/-1d " add empty line before /Features included/ " MUST use single quotes, "" is Vim comment /Features included/-1put ='' " put cursor on 1st +/- features lines norm jj " join all +/- features lines together .,/system vimrc/-1j " reformat features to 'textwidth' norm gqq " add empty line between +/- features and /system vimrc/ put ='' " add empty line before /Compilation/ /^Compilation:/-1put ='' " reformat Compilation line norm jgqq " add empty line before /Linking/ put ='' " reformat Linking line norm jgqq " save wq I just tested it. It will write (as version.txt in the current directory, overwritten if existing) the "beautified" text ready for upload to your "Release Notes" page on sourceforge. (I think it won't work on Tiny and Small builds.) ;-) Just paste the above code as a script (e.g. ~/.build/vim/vim70/beautyversion.vim). If you replace "new" by "edit" at line 4, you can (IIUC) use something like version.txt: src/gvim.exe src/gvim -u NONE -i NONE -N -S beautyversion.vim as a makefile rule to produce the beautified text in batch mode. Best regards, Tony.
Re: search visual block
Benji Fisher wrote: On Wed, Oct 18, 2006 at 12:28:28PM +0200, Robert Cussons wrote: Jean-Rene David wrote: [snip] "--< cut here >--- " Search for visually selected text {{{ " From an idea by Michael Naumann, Jürgen Krämer. function! VisualSearch(direction) range let l:saved_reg = @" execute "normal! vgvy" let l:pattern = escape(@", '\\/.*$^~[]') let l:pattern = substitute(l:pattern, "\n$", "", "") if a:direction == 'b' execute "normal ?" . l:pattern . " " else execute "normal /" . l:pattern . " " endif let @/ = l:pattern let @" = l:saved_reg endfunction vnoremap * :call VisualSearch('f') vnoremap # :call VisualSearch('b') "--< cut here >--- I think the original included raw CR characters in the two :execute lines. Both are intended to end with "^M" (which is how they appeared in my copy of Jean-Rene's note). I think your e-mail client broke the lines, leading to syntax errors. That may well be, don't know too much about how mozilla -mail works I try to avoid such problems by not including raw CR, ESC, etc. characters in my vim scripts. I suggest replacing the two :execute lines with execute "normal ?" . l:pattern . "\" and execute "normal /" . l:pattern . "\" HTH --Benji Fisher Everything seems to work fine now, except the searched for items aren't highlighted like they normally are when I search, is there a simple reason or am I just asking for too much, sorry I can't sort this out myself, but I don't understand the function well enough to see a possilbe reason, the only thing I could think of that might cause it would be this in my .vimrc " Clears search highlighting by just hitting a return. " The clears the command line. " (From Zdenek Sekera [EMAIL PROTECTED] on the vim list.) " I added the final to restore the standard behaviour of " to go to the next line and the mz and `z to return the cursor to its " precommand position :nnoremap mz:nohlsearch/`z However, if this were interfering it would clear the command line as well and I don't see that so it can't be the cause. Thanks, Rob.
Re: search visual block
Jean-Rene David wrote: * Robert Cussons [2006.10.18 06:30]: I did notice that between the if and else there are " which just act as comments as they are on newlines, Sorry, I should have known that wouldn't come out right. There's a literal newline between the quotes. You can enter it by pressing . [...] Instead of "^M", you can use "\r", which is more readable and defines the same string (see ":help expr-string") Best regards, Tony.
Re: search visual block
Jean-Rene David wrote: * Robert Cussons [2006.10.18 06:30]: I did notice that between the if and else there are " which just act as comments as they are on newlines, Sorry, I should have known that wouldn't come out right. There's a literal newline between the quotes. You can enter it by pressing . Here's that section of code with the literal newline entered as two separate characters: if a:direction == 'b' execute "normal ?" . l:pattern . "^M" else execute "normal /" . l:pattern . "^M" endif I was selecting text in visual mode, then pressing / or ? and I just get the normal action of pressing / or ? I agree with what you say below completely, I just didn't express myself clearly enough in the paragraph above, I was just telling you the actions I had performed and it appears I should have been pressing * or # not / or ? as I originally thought, but the lack of the literal newline was causing it not to work too. Well you could do it with "/" and "?" but I like to keep their behavior intact as it is useful to extend the visual region. I remapped "*" and "#" instead, as shown in these lines: vnoremap * :call VisualSearch('f') vnoremap # :call VisualSearch('b') I prefer that because these don't have any special meaning in visual mode and it ties in nicely with the "search next/previous word" function they have in normal mode. Thanks for your help, Rob.
Re: www.vim.org down?
Preben Randhol wrote: > I get a blank page when I go to www.vim.org. If I go to vim.sf.net I > get the vim pages. > > A problem with the alias? The SourceForge VHOST service appears to be down. Maybe someone close to them can go over there and wake them up? So you'll have to use vim.sf.net for now. Sorry, nothing I can do directly. -- hundred-and-one symptoms of being an internet addict: 60. As your car crashes through the guardrail on a mountain road, your first instinct is to search for the "back" button. /// Bram Moolenaar -- [EMAIL PROTECTED] -- http://www.Moolenaar.net \\\ ///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\ \\\download, build and distribute -- http://www.A-A-P.org/// \\\help me help AIDS victims -- http://ICCF-Holland.org///
Re: search visual block
* Benji Fisher [2006.10.18 09:15]: > I try to avoid such problems by not including raw CR, ESC, etc. > characters in my vim scripts. I suggest replacing the two :execute > lines with > execute "normal ?" . l:pattern . "\" > and > execute "normal /" . l:pattern . "\" I was looking for a way to avoid the literals. Thanks for that. That's definitely better. -- JR
Re: split vertically at a tag
Kamaraju Kusumanchi wrote: If I do ctrl-W ctrl-] in normal mode, vim splits the current window horizontally. Is there any way to achieve the same functionality but with window being split vertically instead of horizontally? Here's another solution: nmap:exe 'vert sta '.expand("") Regards, Chip Campbell
Re: problem compiling vim70.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Ajay Gupta wrote: > On 10/18/06, Gary Johnson <[EMAIL PROTECTED]> wrote: >> >> Note that the messages say that configure is checking for tgetent in >> termlib, termcap and curses. They say nothing about checking in >> ncurses. If you want to use ncurses, you have to tell configure >> that: >> >> ./configure --with-tlib=ncurses [] >> >> As long as you installed ncurses in a standard place, you don't need >> to say where you put it. > > Yeah, I tried this too. Since I installed ncurses with Yum, I am > assuming that it must be installed in the right place. I get the > following error with the above mentioned command: > > > checking --with-tlib argument... ncurses > checking for linking with ncurses library... configure: error: FAILED > > > It surely looks like libncurses is in the wrong place. Does anyone > know what are the exact library files and where they need to be? > Here is the uname -a output from my machine: > > Linux altair 2.6.11-1.1369_FC4smp #1 SMP Thu Jun 2 23:08:39 EDT 2005 > i686 i686 i386 GNU/Linux > > TIA, > Ajay > It seems your curses is not installed in the place where VIM is looking for it. May be it is not installed correctly. Have you checked it? Try to do this. locate curses.h (or ncurses.h) locate libncurses (or libcurses) If out of any of this commans is nothing, your installation is faulty. The directory of first output should go into CPPFLAGS and other should go into LDFLAGS like this: anda=`locate curses.h` export CPPFLAGS=-I`dirname $anda` anda=`locate libncurses` export LDFLAGS=-I`dirname $anda` and then do ./configure - -- Anupam Srivastava Scientific Coworker Universität Stuttgart Get my public keys: gpg --keyserver subkeys.pgp.net --recv-keys DF8B2AFE 99F8BB81 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org iD8DBQFFNiyx7GZ7yN+LKv4RAttzAJoCoMezvH3I+D2JZ8qkRjbAT/lvlQCfb+cV mGKcM4dffyzMCSnX53WZ5C4= =QCIM -END PGP SIGNATURE-
Re: www.vim.org down?
On 10/18/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: I don't think it is happen recently. During the past two years I'd never sucess in visiting www.vim.org, only vim.sf.net works -- Sincerely, Pan, Shi Zhu. ext: 2606 Really? A year ago or so www.vim.org was blocked from China, but that changed later. The current issue is not blocking, but the server itself has some problems. Best regards, Yongwei -- Wu Yongwei URL: http://wyw.dcweb.cn/
Re: search visual block
* Robert Cussons [2006.10.18 09:29]: > Everything seems to work fine now, except the > searched for items aren't highlighted like they > normally are when I search Whether or not search items are highlighted depends on the value of the 'hlsearch' option. The search item gets highlighted on my end when the option is set. Is yours set? :set hls? -- JR
Possible feature request
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi All, Was playing with the new built in sort this morning. Found what I thought was an inconsistency. Forgive the stilted explanation, I had trouble putting this in words. I often work out my pattern match using /mypattern/ and observe the highlighting to make sure it's doing what I want it to. Then I use %s//newpattern/ or whatever I'm going to do and the // is the previously tested pattern match. Quite handy. That doesn't work with :sort // r I think it should to be consistent. Am I wrong? Missing something? Comments appreciated Brian McKee -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (Darwin) iD8DBQFFNjF2GnOmb9xIQHQRAgCQAJ403/IwHu/i6MCmVWrhKW2L+jP+hgCg7fqx l5SsqTxUiFfXIeL4HBRq7oI= =NRVn -END PGP SIGNATURE-
Re: Contextual 'iskeyword'?
Benji Fisher wrote: On Wed, Oct 18, 2006 at 01:21:31AM +0200, A.J.Mechelynck wrote: After reading this thread, I've seen "requests for improvement" to the Vim source; but let's try to find (for the time being) something which works in the current Vim version. 1. Em dashes should normally be set apart from the neighbouring words by blank spaces -- like this -- and if they are, they won't be mistaken for part of a word regardless of whether 'iskeyword' includes the dash. [snip] That depends on your style manual. The one I read, back in my typewriter days, insisted on dashes without spaces on either side--like this. Also, vim will recognize your "--" as a word if 'isk' includes "-", and that might cause problems. HTH --Benji Fisher Oh? Apparently styles differ. All em dashes that I remember seeing in printed books had spaces around them; but that's mostly in French (where the em dash is used not only as a kind of "super-parenthese" but also to mark change of locutor in direct speech) and in Russian (where it can replace the nonexistent present tense of the verb "to be"). I think it's rarer in English. As for recognising "--" as a word, IMHO it'll cause fewer problems than recognising "spaces--like" "this--and" "side--like" etc. as (misspelled) words. If I were using the spell checker, I might even add "--" to my "user" wordlist. Best regards, Tony.
Re: search visual block
Jean-Rene David wrote: * Robert Cussons [2006.10.18 09:29]: Everything seems to work fine now, except the searched for items aren't highlighted like they normally are when I search Whether or not search items are highlighted depends on the value of the 'hlsearch' option. The search item gets highlighted on my end when the option is set. Is yours set? :set hls? This is quite strange, it is set, i.e. :set hls? returns hlsearch If I use your visual selection when I first launch gvim, then it works with the highlighting. If I then use to clear the highlighting according to this line in my .vimrc that I gave before: :nnoremap mz:nohlsearch/`z then the highlighting is no longer displayed as is expected. If I then do :set hls? again, I get again: hlsearch but if I use your visual selection tool again then this time I get no highlighting. Of course if I set hls again using :set hls then it works fine again until I press enter. So what I was thinking was just to add a :set hls at the start of your function, then it should alway highlight the searched for items, however I tried variations on including it but no nothing about scripting so they didn't work, can you tell me how I should add it? I tried the below but it didn't work. Thanks, Rob. " Search for visually selected text {{{ " From an idea by Michael Naumann, Jürgen Krämer. function! VisualSearch(direction) range set hlsearch let l:saved_reg = @" execute "normal! vgvy" let l:pattern = escape(@", '\\/.*$^~[]') let l:pattern = substitute(l:pattern, "\n$", "", "") if a:direction == 'b' execute "normal ?" . l:pattern . "\r" else execute "normal /" . l:pattern . "\r" endif let @/ = l:pattern let @" = l:saved_reg endfunction vnoremap * :call VisualSearch('f') vnoremap # :call VisualSearch('b')
Re: problem compiling vim70.
Anupam Srivastava wrote: [...] (Vim does compile on my system) Try to do this. locate curses.h (or ncurses.h) locate curses.h /usr/include/curses.h /usr/include/curses/curses.h /usr/include/ncurses.h /usr/include/python2.4/py_curses.h /usr/include/slcurses.h locate libncurses (or libcurses) locate libncurses /lib/libncurses.so.5 /lib/libncurses.so.5.4 /usr/lib/libncurses++.a /usr/lib/libncurses++w.a /usr/lib/libncurses.a /usr/lib/libncurses.so /usr/lib/libncurses.so.4 /usr/lib/libncurses.so.4.2 /usr/lib/libncursesw.so /usr/lib/libncursesw.so.5 /usr/lib/libncursesw.so.5.5 If out of any of this commans is nothing, your installation is faulty. The directory of first output should go into CPPFLAGS and other should go into LDFLAGS IIUC, only one of each should go into CPPFLAGS and LDFLAGS like this: anda=`locate curses.h` export CPPFLAGS=-I`dirname $anda` dirname `locate curses.h` dirname: extra operand `/usr/include/curses/curses.h' Try `dirname --help' for more information anda=`locate libncurses` export LDFLAGS=-I`dirname $anda` dirname `locate libncurses` dirname: extra operand `/lib/libncurses/so.5.4' Try `dirname --help' for more information and then do ./configure - -- Anupam Srivastava Scientific Coworker Universität Stuttgart Best regards, Tony.
Re: VIM as C++ IDE
On 10/15/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: "Peng Yu" <[EMAIL PROTECTED]> 写于 2006-10-14 05:59:29: > > map :w:make > Can some body provide some script to satisfy my more general > requirement? I want press , then make is called. The error window > will not be closed unless I do so. When I brower the error, the file > where the error is from will be open automatically and the cursor is > put in the error line? > > Thanks, > Peng for that simple, don't need any plugin: map :w:make:cope You see, just add the :cope will do the trick. Note that the cursor will be in :cope window then, you may need to press an enter key to go into the first error. But what to do when there's no error? then does nothing. Is it possible to not to press the last enter key? It is not very convenient. Thanks, Peng
keymap files for Bulgarian
Hello all, To most of you this is of no interest, but anyway ... :) I've created keymap files for the two keyboard layouts used in Bulgaria: http://www.math.bas.bg/softeng/bantchev/misc/vim/bulgarian-phonetic.vim and http://www.math.bas.bg/softeng/bantchev/misc/vim/bulgarian-bds.vim . Both can be used also for Russian, esp. the first one. Some details on which is what are written as comments inside each file. Bram, With 7.0 (and probably older releases as well) there is distributed a keymap file bulgarian.vim. Unfortunately, its mapping is none of the ones really used in Bulgaria. I have no idea how many people use Vim in my country, but I guess that including the above two mappings standardly in Vim will be of help to them. Regards, Boyko
Re: problem compiling vim70.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 A.J.Mechelynck wrote: > Anupam Srivastava wrote: >> -BEGIN PGP SIGNED MESSAGE- >> Hash: SHA1 >> >> 1. Forget that shortcut dirname `locate curses.h` thing. It was just to >> give the idea to Ajay about how to compile by redefinign CPPFLAGS and >> LDFALGS. > > Well, you made it sound like an actual shell script that ought to work. > I am a n00b. Bear with me. That script works on my computer! :) >> anda=`locate libncurses` export LDFLAGS=-I`dirname $anda` >>> dirname `locate libncurses` >>> dirname: extra operand `/lib/libncurses/so.5.4' >>> Try `dirname --help' for more information >> >> 2. Atleast your out put is not 'nothing' :p > > No, I get several lines of output for each of them, including (IIUC) a > number of lines which bear no relation to what should be searched by > compile or link > That is very well explained in en.wikipedia.org/wiki/Humor >> >>> IIUC, only one of each should go into CPPFLAGS and LDFLAGS >> >> 3. Sorry didn't get you. Here is the actual mail from which I got helped: >> >> Gary Johnson wrote: I downloaded and installed ncurses under /home/garyjohn/src/SunOS/ncurses-5.4. Here is how I build vim: export CPPFLAGS="-I/home/garyjohn/src/SunOS/ncurses-5.4/include/ncurses" > > only one directory, not the directories of everything that "locate > ncurses.h" did output > export LDFLAGS="-L/home/garyjohn/src/SunOS/ncurses-5.4/lib" > > only one directory, not the directories of everything that "locate > libncurses" did output > ./configure --prefix=/home/garyjohn/src/SunOS/vim-7.0 --with-tlib=ncurses --enable-cscope make make install >> >> Yeah I know :) > I'm re-adding the vim-dev list to the CC -- I wonder why you removed it. > > (Disclaimer: I don't know everything about Vim, and I'm not paid to > answer queries. I'm just another user like any of them.) > > > Best regards, > Tony. Yeah I know :) - -- Anupam Srivastava Scientific Coworker Universität Stuttgart Get my public keys: gpg --keyserver subkeys.pgp.net --recv-keys DF8B2AFE 99F8BB81 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org iD8DBQFFNkeL7GZ7yN+LKv4RAlQVAJ917NEDO244GgQDuQEE10t7nKqwjACdG4QL 7kZoHP2FcRwJuWHmNhKTa5U= =0WmQ -END PGP SIGNATURE-
color schemes same fg and bg on vimdiff
Vimmers, I use vimdiff in gnome-terminal and sometimes in GUI, but the default color scheme (I found somehow it's not the same as the "colors/default.vim") sometimes use the same color for both foreground and background. Most of the color schemes in the colors directory do the same (same or indiscernible fg and bg colors) I spent some time and found corresponding set the following for the c files I have at hand, so I add these lines in my .vimrc, but I guess I'll have to do the same for php and other languages I use. highlight cConstant ctermfg=white guifg=white highlight cString ctermfg=white guifg=white highlight cNumber ctermfg=white guifg=white Do these have something in common? I had to try a few times to find what they are... P.S.) Also, :help colorscheme says :colo[rscheme] {name} Load color scheme {name}. This searches 'runtimepath' for the file "colors/{name}.vim. The first one that is found is loaded. but somehow, none of my installations do that, if the first means alphabetically the first. Probably it'll be understandable if I look at the code, but just wanted to note here - in case someone has a ready answer. Happy vimming, Ben K. Developer http://benix.tamu.edu
Re: Wrapping by substitution
I'm having a mental block, how can I wrap a string via substitute() ? The following seems to do the trick for me: echo substitute(str, '[[:print:]]\{,10}', '&\n', 'g') This nearly works, but is doubling existing line breaks. The application is this :version pretty-fier: function! Str_wrap(str, len) return substitute(a:str, '[[:print:]]\{,'.a:len.'}','&\n','g') endfunction I must be missing something...in your original post, you didn't have any linebreaks in your sample str...thus my answer didn't deal with them. ;) If you have a multi-line string and want to do a wrapping as something sorta like "gqip" would do (minus its internal smartness about things like comment-leaders or mail-quote characters), echo substitute(@", '\([[:print:]]\{,10}\)\>[^[:cntrl:]]', '&\n', 'g') seems to do something fairly reasonably kinda sorta close to what I understand you to be describing. :) -tim
follow up - colorscheme on vimdiff
The previous setting gave me white on white in some cases so I added guibg. highlight cConstant ctermfg=white ctermbg=grey guifg=white guibg=grey highlight cString ctermfg=white ctermbg=grey guifg=white guibg=grey highlight cNumber ctermfg=white ctermbg=grey guifg=white guibg=grey Regards, Ben K. Developer http://benix.tamu.edu
Re: color schemes same fg and bg on vimdiff
Ben K. wrote: Vimmers, I use vimdiff in gnome-terminal and sometimes in GUI, but the default color scheme (I found somehow it's not the same as the "colors/default.vim") sometimes use the same color for both foreground and background. Most of the color schemes in the colors directory do the same (same or indiscernible fg and bg colors) Since $VIMRUNTIME/colors/default.vim includes no explicit highlights, but only resets everything to the defaults, it should be the same as no colorscheme at all... unless hi clear Normal set bg& hi clear doesn't "guess" correctly whether your background is "light" or "dark". In that case, here's how to reset the defaults, assuming you're running Vim in a dark-background color-xterm: hi clear Normal set bg=dark hi clear " the rest of default.vim shouldn't change Don't modify $VIMRUNTIME/colors/default.vim "in place", because any upgrade may (and, on Unix, probably will) overwrite it without warning. Place your own colourscheme (the modified version) in ~/.vim/colors/ (on Unix) or ~/vimfiles/colors/ (on Windows); I recommend that you also give it another name, but ending in .vim I spent some time and found corresponding set the following for the c files I have at hand, so I add these lines in my .vimrc, but I guess I'll have to do the same for php and other languages I use. highlight cConstant ctermfg=white guifg=white highlight cString ctermfg=white guifg=white highlight cNumber ctermfg=white guifg=white I expect that "guifg=white" will set it to white-on-white in most cases when using the GUI Do these have something in common? I had to try a few times to find what they are... P.S.) Also, :help colorscheme says :colo[rscheme] {name} Load color scheme {name}. This searches 'runtimepath' for the file "colors/{name}.vim. The first one that is found is loaded. but somehow, none of my installations do that, if the first means alphabetically the first. Probably it'll be understandable if I look at the code, but just wanted to note here - in case someone has a ready answer. Happy vimming, Ben K. Developer http://benix.tamu.edu It's not alphabetically the first, it's the first in 'runtimepath', as follows: Let's say you use the command :colorscheme foobar on Unix, with 'runtimepath' at its default setting. This is what happens: If "~/.vim/colors/foobar.vim" is found, use that; otherwise if "$VIM/vimfiles/colors/foobar.vim" is found, use that; otherwise if "$VIMRUNTIME/colors/foobar.vim" is found, use that; otherwise if "$VIM/vimfiles/after/colors/foobar.vim" is found, use that; otherwise if "~/.vim/colors/foobar.vim" is found, use that; otherwise don't change anything, and if 'verbose' is nonzero give a message. Best regards, Tony.
automatically going from header file to implementation file
Hi, Does any body know a way of automatically going from header file to its implementation file?! and vice versa?!
Fighting with comments
Hello I´m PHP programmer and I started programming in gVim last weak, and I´m liking it very much But I got a trouble... When I´m commenting (// or /* or #) and I type it breaks the line automatically. Always I start a comment, i have to go to normal mode and type :set nosta :set noai :set nosi I find that only nosta or nosi is enought to make it stop breaking the line automatically, but I want to configure to it stop doing it forever... I took a look in syntax/php.vim but I just don´t know where correct it... Do you have any idea of how I fix it? -- View this message in context: http://www.nabble.com/Fighting-with-comments-tf2467964.html#a6880708 Sent from the Vim - General mailing list archive at Nabble.com.
RE: Wrapping by substitution
From: Tim Chase, Wed, October 18, 2006 12:00 pm > > > The application is this :version pretty-fier: > > > > function! Str_wrap(str, len) > > return substitute(a:str, '[[:print:]]\{,'.a:len.'}','&\n','g') > > endfunction > > I must be missing something...in your original post, you didn't > have any linebreaks in your sample str...thus my answer didn't > deal with them. ;) Flagrant error on my part in not posting a proper test case. :) > If you have a multi-line string and want to do a wrapping as > something sorta like "gqip" would do (minus its internal > smartness about things like comment-leaders or mail-quote > characters), > > echo substitute(@", '\([[:print:]]\{,10}\)\>[^[:cntrl:]]', '&\n', 'g') > > seems to do something fairly reasonably kinda sorta close to what I > understand you to be describing. :) I'm still baffled with what is happening to returns when this ends up in a function: function! Str_wrap(str, len) return substitute(a:str, '\([[:print:]]\{,' . a:len . \ '}\)\>[^[:cntrl:]]', '&\n', 'g') endfunction function! Version() redir @x silent! version redir END echo Str_wrap(@x, 70) endfunction call Version() Tony's previous approach is a work-around, but I'm trying to write a more generic substitution for wrapping. -- Steve Hall [ digitect dancingpaper com ]
Re: automatically going from header file to implementation file
* Naim Far [2006.10.18 13:00]: > Does any body know a way of automatically going > from header file to its implementation file?! > and vice versa?! a.vim : Alternate Files quickly (.c --> .h etc) http://vim.sourceforge.net/scripts/script.php?script_id=31 -- JR
Re: Fighting with comments
On 10/18/06, eric1235711 <[EMAIL PROTECTED]> wrote: Hello I´m PHP programmer and I started programming in gVim last weak, and I´m liking it very much But I got a trouble... When I´m commenting (// or /* or #) and I type it breaks the line automatically. Always I start a comment, i have to go to normal mode and type :set nosta :set noai :set nosi I find that only nosta or nosi is enought to make it stop breaking the line automatically, but I want to configure to it stop doing it forever... I took a look in syntax/php.vim but I just don´t know where correct it... Do you have any idea of how I fix it? Does this help: :set tw=0 ? Yakov
Re: Fighting with comments
Hello Yakov I can fix it when I´m programming, i´m doing it... but I´m getting tired of doing that. I want to alter the syntax file (or what ever else) to fix it permanently. Yakov Lerner-3 wrote: > > On 10/18/06, eric1235711 <[EMAIL PROTECTED]> wrote: >> >> Hello >> >> I´m PHP programmer and I started programming in gVim last weak, and I´m >> liking it very much >> >> But I got a trouble... >> >> When I´m commenting (// or /* or #) and I type it breaks the line >> automatically. Always I start a comment, i have to go to normal mode and >> type :set nosta :set noai :set nosi >> >> I find that only nosta or nosi is enought to make it stop breaking the >> line >> automatically, but I want to configure to it stop doing it forever... >> >> I took a look in syntax/php.vim but I just don´t know where correct it... >> >> Do you have any idea of how I fix it? > > Does this help: >:set tw=0 > ? > > Yakov > > -- View this message in context: http://www.nabble.com/Fighting-with-comments-tf2467964.html#a6884075 Sent from the Vim - General mailing list archive at Nabble.com.
Re: Fighting with comments
On 2006-10-18, eric1235711 <[EMAIL PROTECTED]> wrote: > Yakov Lerner-3 wrote: > > > > On 10/18/06, eric1235711 <[EMAIL PROTECTED]> wrote: > >> > >> Hello > >> > >> I´m PHP programmer and I started programming in gVim last weak, and I´m > >> liking it very much > >> > >> But I got a trouble... > >> > >> When I´m commenting (// or /* or #) and I type it breaks the line > >> automatically. Always I start a comment, i have to go to normal mode and > >> type :set nosta :set noai :set nosi > >> > >> I find that only nosta or nosi is enought to make it stop breaking the > >> line > >> automatically, but I want to configure to it stop doing it forever... > >> > >> I took a look in syntax/php.vim but I just don´t know where correct it... > >> > >> Do you have any idea of how I fix it? > > > > Does this help: > >:set tw=0 > > ? > I can fix it when I´m programming, i´m doing it... but I´m getting tired of > doing that. > > I want to alter the syntax file (or what ever else) to fix it permanently. First of all, don't alter any of the files that are in the $VIMRUNTIME directory. For Vim-7.0 on Windows, this is commonly C:\Program Files\Vim\vim70 Doing so will cause you to lose those changes when you upgrade your vim installation. The way to fix this problem is to create two new directories: $VIM\vimfiles\after $VIM\vimfiles\after\ftplugin on Windows or ~/.vim/after ~/.vim/after/ftplugin on Unix. Then create a new file in the after/ftplugin directory named php.vim and put in it those commands that fix the problem, e.g., setlocal nosta setlocal noai setlocal nosi Note the use of "setlocal" instead of "set". This will keep those changes local to your PHP buffer(s) so that you can use other settings in other buffers you might have open at the same time. See: :help ftplugin-overrule :help ftplugin HTH, Gary -- Gary Johnson | Agilent Technologies [EMAIL PROTECTED] | Wireless Division | Spokane, Washington, USA
locked window
Hi I was wondering if there is a way to lock a window such that the content can only be changed by scripting/commands. Like a preview window or somthing like that. is that possible to make in Vim or should I make a feature request to get it :-) -- Kim Schulz| Private : http://www.schulz.dk [EMAIL PROTECTED] | Business: http://www.devteam.dk +45 5190 4262 | Sparetime: http://www.fundanemt.com
Re: locked window
I was wondering if there is a way to lock a window such that the content can only be changed by scripting/commands. Like a preview window or somthing like that. is that possible to make in Vim or should I make a feature request to get it :-) Well, as an atrocious hack, assuming you have a filename assigned to this given window (no_touch.txt), you could do something like :au WinEnter no_touch.txt wincmd x (which kinda pushes the "locked" window out of the way by preventing you from entering it) or :au WinEnter no_touch.txt wincmd p which simply prevents you from entering the window unless/until it's the last window available. Beware of crazy behavior that might ensue from this. It would serve well for either of these to remember that one can prefix window-selection commands with a count, so you can do ^W2k to move up *two* windows rather than one, so that you can jump over the offending "locked" window if needed. Just a long day here...experiment, have fun, and hopefully it will give you some crazy ideas too. :) -tim
Re: keymap files for Bulgarian
Boyko Bantchev wrote: > To most of you this is of no interest, but anyway ... :) > I've created keymap files for the two keyboard layouts > used in Bulgaria: > http://www.math.bas.bg/softeng/bantchev/misc/vim/bulgarian-phonetic.vim > and > http://www.math.bas.bg/softeng/bantchev/misc/vim/bulgarian-bds.vim . > Both can be used also for Russian, esp. the first one. > Some details on which is what are written as > comments inside each file. > > Bram, > > With 7.0 (and probably older releases as well) there is > distributed a keymap file bulgarian.vim. Unfortunately, > its mapping is none of the ones really used in Bulgaria. > I have no idea how many people use Vim in my country, > but I guess that including the above two mappings > standardly in Vim will be of help to them. I can include these files. I'll leave discussion about what keymaps to use for Bulgarian to Bulgarians. Did you contact the maintainer of bulgarian.vim? -- hundred-and-one symptoms of being an internet addict: 63. You start using smileys in your snail mail. /// Bram Moolenaar -- [EMAIL PROTECTED] -- http://www.Moolenaar.net \\\ ///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\ \\\download, build and distribute -- http://www.A-A-P.org/// \\\help me help AIDS victims -- http://ICCF-Holland.org///
www.vim.org
SourceForge has fixed the VHOST service, www.vim.org is back! -- hundred-and-one symptoms of being an internet addict: 72. Somebody at IRC just mentioned a way to obtain full motion video without a PC using a wireless protocol called NTSC, you wonder how you never heard about it /// Bram Moolenaar -- [EMAIL PROTECTED] -- http://www.Moolenaar.net \\\ ///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\ \\\download, build and distribute -- http://www.A-A-P.org/// \\\help me help AIDS victims -- http://ICCF-Holland.org///
vimdiff same bg and fg colors
Thanks Tony and Brady. I got sufficient answers. Happy vimming, Ben K. Developer http://benix.tamu.edu
Re: search visual block
--- Robert Cussons <[EMAIL PROTECTED]> wrote: > Jean-Rene David wrote: > > * Robert Cussons [2006.10.18 09:29]: > > > >>Everything seems to work fine now, except the > >>searched for items aren't highlighted like they > >>normally are when I search > > > > > > Whether or not search items are highlighted > > depends on the value of the 'hlsearch' option. > > > > The search item gets highlighted on my end when the > > option is set. Is yours set? [snip] I have learned a lot from this thread! I changed the function slightly (see below) because I also didn't understand the missing ^M was causing my problem. I like to use * and # for searching for a string in highlight mode, then I press F10 to turn off highlighting. However, pressing F10 with nohls highlights the word under the cursor without searching for it, which was is a modification of some comments at the bottom of vimtip #1. Between this thread and the discussions in vimtip #1 I now have the following which works really *really* nicely: "begin " disabled initially since it distracts me set nohlsearch " in normal mode, make * highlight the search string nnoremap * *:set hls nnoremap # #:set hls " in visual mode, use highlighted selection for search pattern vnoremap * :call VisualSearch('f'):set hls vnoremap # :call VisualSearch('b'):set hls function! VisualSearch(direction) let l:saved_reg = @" execute "normal! vgvy" let l:pattern = escape(@", '\/.*$^~[]') let l:pattern = substitute(l:pattern, "\n$", "", "") let @/ = l:pattern let @" = l:saved_reg if a:direction == 'f' normal n else normal N endif endfunc " map to toggle the highlight search mode " if hlsearch is on then simply turn it off " if hlsearch is off then highlight word under cursor only nnoremap :call SetSearchReg():set invhls function! SetSearchReg() if &hlsearch == 0 let @/ = expand('') endif endfunc " my mind/fingers think of as highlight search mode " so make visual mode and work like * and # vnoremap :call VisualSearch('f'):set hls vnoremap :call VisualSearch('b'):set hls "-end- Regards, David __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Re: Fighting with comments
--- Gary Johnson <[EMAIL PROTECTED]> wrote: > On 2006-10-18, eric1235711 <[EMAIL PROTECTED]> wrote: > > > Yakov Lerner-3 wrote: > > > > > > On 10/18/06, eric1235711 <[EMAIL PROTECTED]> wrote: > > >> > > >> Hello > > >> > > >> I´m PHP programmer and I started programming in gVim last weak, and I´m > > >> liking it very much > > >> > > >> But I got a trouble... > > >> > > >> When I´m commenting (// or /* or #) and I type it breaks the > line > > >> automatically. Always I start a comment, i have to go to normal mode and > > >> type :set nosta :set noai :set nosi > > >> > > >> I find that only nosta or nosi is enought to make it stop breaking the > > >> line > > >> automatically, but I want to configure to it stop doing it forever... > > >> > > >> I took a look in syntax/php.vim but I just don´t know where correct > it... > > >> > > >> Do you have any idea of how I fix it? > > > > > > Does this help: > > >:set tw=0 > > > ? > > > I can fix it when I´m programming, i´m doing it... but I´m getting tired of > > doing that. > > > > I want to alter the syntax file (or what ever else) to fix it permanently. > > First of all, don't alter any of the files that are in the > $VIMRUNTIME directory. For Vim-7.0 on Windows, this is commonly > > C:\Program Files\Vim\vim70 > > Doing so will cause you to lose those changes when you upgrade your > vim installation. > > The way to fix this problem is to create two new directories: > > $VIM\vimfiles\after > $VIM\vimfiles\after\ftplugin > > on Windows or > > ~/.vim/after > ~/.vim/after/ftplugin > > on Unix. Then create a new file in the after/ftplugin directory > named php.vim and put in it those commands that fix the problem, > e.g., > > setlocal nosta > setlocal noai > setlocal nosi I wouldn't have thought those options would make a difference? You should be able to just use (in after/ftplugin/php.vim): " don't auto-wrap text setlocal formatoptions-=t " don't auto-wrap comments either. setlocal formatoptions-=c regards, Peter On Yahoo!7 Men's Health Radio: Chill out or work out, or just tune in http://au.launch.yahoo.com/mens-health-radio/index.html
Re: locked window
Hello, On 10/18/06, Kim Schulz <[EMAIL PROTECTED]> wrote: Hi I was wondering if there is a way to lock a window such that the content can only be changed by scripting/commands. Like a preview window or somthing like that. is that possible to make in Vim or should I make a feature request to get it :-) You can clear the 'modifiable' option to disable unintended modifications to a buffer. setlocal nomodifiable - Yegappan
BUG: formatoptions+=t makes comments wrap (incorrectly) when they shouldn't
Hello, When I have formatoptions=t, it makes comment lines wrap when they shouldn't, and it also ignores whatever comment leader is defined in 'comments'. To reproduce: :set formatoptions=roc :set comments=b:% :set textwidth=30 % type these lines of text % as one line, and notice % how Vim automatically % wraps the lines and adds % '%' at the start of each % line. Now remove 'c' from formatoptions and add 't'. :set formatoptions-=c :set formatoptions+=t >From the help pages (:help fo-table) t Auto-wrap text using textwidth (does not apply to comments) c Auto-wrap comments using textwidth, inserting the current comment leader automatically. With 'formatoptions' now set to 'rot', Vim should wrap normal text, but not comments. % but when you type this next set of comments, Vim will wrap them (when it shouldn't, because they are comments), and it will also miss out the comment leader. I hope it's clear what's going on here. I'm running Vim 7 with patches 1-101. regards, Peter Do you Yahoo!? Cars: Buy and sell, news, reviews, videos and more http://yahoo.drive.com.au/
Match something that not in the pattern
Hi, I have the following file segments. I want to concatenate all the lines with their next lines, except that it ends with "}}". I want to use the pattern "\(}}\)[EMAIL PROTECTED]". It seems not working. Would you please help me to figure out how to match the lineend without "}}"? Thanks, Peng 2.3766829304614354*^-12*d^3*Ith^2*z^6 - 9.163340710959959*^-10*Ith^3*z^6 - 3.0207696015850803*^-10*d* Ith^3*z^6 + 8.760261318791164*^-11*d^2*Ith^3*z^6 - 3.492315374248676*^-12*d^3*Ith^3*z^6}} fw100s200[d_,z_,Ith_] := 0.01515647826357657, 0.08956492396538135, 246.40722214248873 - 0.48219974209354677*d + 0.07494738483672195*d^2 - 0.0007155767500598704*d^3 - 778.7338684688602*Ith + 5.330667362452238*d*Ith - 0.6096508973274091*d^2*Ith + 0.00429237191519287*d^3*Ith + 1465.675721942*Ith^2 - 15.92585633547399*d*Ith^2 +
Re: Match something that not in the pattern
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Peng Yu wrote: > Hi, > > I have the following file segments. I want to concatenate all the > lines with their next lines, except that it ends with "}}". I want to > use the pattern "\(}}\)[EMAIL PROTECTED]". It seems not working. > > Would you please help me to figure out how to match the lineend without > "}}"? > > Thanks, > Peng > > > 2.3766829304614354*^-12*d^3*Ith^2*z^6 - > 9.163340710959959*^-10*Ith^3*z^6 - 3.0207696015850803*^-10*d* >Ith^3*z^6 + 8.760261318791164*^-11*d^2*Ith^3*z^6 - > 3.492315374248676*^-12*d^3*Ith^3*z^6}} > fw100s200[d_,z_,Ith_] := 0.01515647826357657, 0.08956492396538135, > 246.40722214248873 - 0.48219974209354677*d + > 0.07494738483672195*d^2 - 0.0007155767500598704*d^3 - > 778.7338684688602*Ith + 5.330667362452238*d*Ith - > 0.6096508973274091*d^2*Ith + 0.00429237191519287*d^3*Ith + > 1465.675721942*Ith^2 - 15.92585633547399*d*Ith^2 + Well, I am still learning VIM but these 3 commands could do your job, if they are acceptable to you (they work for me!): :1,10s/\n/ \r/g :1,10s/}} /}}/g :1,10s/ \n//g :) - -- Anupam Srivastava Scientific Coworker Universität Stuttgart Get my public keys: gpg --keyserver subkeys.pgp.net --recv-keys DF8B2AFE 99F8BB81 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org iD8DBQFFNtE27GZ7yN+LKv4RAgBQAJ9kEt5G99gxO1eZh9Rs+3XeZDVixQCfSj8p H2FzBiSjkjRSbby//mVRf94= =eR5i -END PGP SIGNATURE-
Re: VIM as C++ IDE
"Peng Yu" <[EMAIL PROTECTED]> 写于 2006-10-18 23:18:14: > On 10/15/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > > for that simple, don't need any plugin: > > > > map :w:make:cope > > > > You see, just add the :cope will do the trick. > > > > Note that the cursor will be in :cope window then, you may need to press an > > enter key to go into the first error. But what to do when there's no error? > > then does nothing. > > Is it possible to not to press the last enter key? It is not very convenient. > > Thanks, > Peng try this instead: map :copep:w:make Hope that helps. -- Sincerely, Pan, Shi Zhu. ext: 2606
RE: search visual block
> -Original Message- > From: Lev Lvovsky [mailto:[EMAIL PROTECTED] > Sent: Tuesday, October 17, 2006 5:04 PM > To: vim@vim.org > Subject: search visual block > > Is it possible to search for a string by selecting that > string in visual mode? Meaning, if I highlight something, > and then want to search for that thing which is highlighted > in the rest of the doc? > > otherwise, is there a way to copy that string so that I can > later put it into the :/ command? I know you have had lots of different reponses on this thread. This is what I keep in my vimrc, which doesn't use a function. Simply highlight the text and hit * or #, just like you would for a given work in normal mode. " Courtesy of Michael Naumann, Jürgen Krämer " Visually select text, then search for it if version >= 602 " Here are two enhanced versions of these mappings which use VIM 6.2's " getregtype() function to determine whether the unnamed register contains " a characterwise, linewise or blockwise selection. After the search has " been executed, the register *and* its type can then be restored with " setreg(). vnoremap * : \let old_reg=getreg('"') \let old_regmode=getregtype('"') \gvy/=substitute(substitute( \escape(@", '\\/.*$^~[]' ), "\n$", "", ""), \"\n", '\\_[[:return:]]', "g") \:call setreg('"', old_reg, old_regmode) vnoremap # : \let old_reg=getreg('"') \let old_regmode=getregtype('"') \gvy?=substitute(substitute( \escape(@", '\\/.*$^~[]' ), "\n$", "", ""), \"\n", '\\_[[:return:]]', "g") \:call setreg('"', old_reg, old_regmode) else " If you use both VIM 6.2 and older versions these mappings " should be defined depending on the current version. vnoremap * :let old_reg=@" \gvy/=substitute(substitute( \escape(@", '\\/.*$^~[]' ), "\n$", "", ""), \"\n", '\\_[[:return:]]', "g") \:let @"=old_reg vnoremap # :let old_reg=@" \gvy?=substitute(substitute( \escape(@", '\\/.*$^~[]' ), "\n$", "", ""), \"\n", '\\_[[:return:]]', "g") \:let @"=old_reg endif
Re: Match something that not in the pattern
On Wed 18-Oct-06 8:03pm -0600, Peng Yu wrote: > I have the following file segments. I want to concatenate all the > lines with their next lines, except that it ends with "}}". I want to > use the pattern "\(}}\)[EMAIL PROTECTED]". It seems not working. > > Would you please help me to figure out how to match the lineend without "}}"? You're fairly close. Assuming you visually marked those lines, this solution is magic: '<,'>s/\%(}}\)\@s/\v%(}})@
Re: VIM as C++ IDE
On 10/18/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: "Peng Yu" <[EMAIL PROTECTED]> 写于 2006-10-18 23:18:14: > On 10/15/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > > for that simple, don't need any plugin: > > > > map :w:make:cope > > > > You see, just add the :cope will do the trick. > > > > Note that the cursor will be in :cope window then, you may need to press an > > enter key to go into the first error. But what to do when there's no error? > > then does nothing. > > Is it possible to not to press the last enter key? It is not very convenient. > > Thanks, > Peng try this instead: map :copep:w:make I still have to type Enter at the end.
Fwd: Match something that not in the pattern
-- Forwarded message -- From: Peng Yu <[EMAIL PROTECTED]> Date: Oct 18, 2006 9:19 PM Subject: Re: Match something that not in the pattern To: Bill McCarthy <[EMAIL PROTECTED]> On 10/18/06, Bill McCarthy <[EMAIL PROTECTED]> wrote: On Wed 18-Oct-06 8:03pm -0600, Peng Yu wrote: > I have the following file segments. I want to concatenate all the > lines with their next lines, except that it ends with "}}". I want to > use the pattern "\(}}\)[EMAIL PROTECTED]". It seems not working. > > Would you please help me to figure out how to match the lineend without "}}"? You're fairly close. Assuming you visually marked those lines, this solution is magic: '<,'>s/\%(}}\)\@s/\v%(}})@ Could you please explain what these commands mean? Thanks, Peng
Re: Match something that not in the pattern
--- Peng Yu <[EMAIL PROTECTED]> wrote: > Hi, > > I have the following file segments. I want to concatenate all the > lines with their next lines, except that it ends with "}}". I want to > use the pattern "\(}}\)[EMAIL PROTECTED]". It seems not working. [EMAIL PROTECTED] is the look-ahead assersion, you want the look-behind assertion which is \@http://www.totalgirl.com.au/slumberparty
Can the mailing list owner set "Reply-to" field be [EMAIL PROTECTED]
Hi, Can the mailing list owner set "Reply-to" field in every mail forward from this mailing list be "vim@vim.org"? I replied some mails to the original poster. But sometime I forget to reply the mails to the mailing list. Thanks, Peng
Re: search visual block
* David Fishburn [2006.10.18 22:00]: > " Courtesy of Michael Naumann, Jürgen Krämer > " Visually select text, then search for it > if version >= 602 > " Here are two enhanced versions of these mappings which use VIM 6.2's > " getregtype() function to determine whether the unnamed register > contains > " a characterwise, linewise or blockwise selection. After the search has > > " been executed, the register *and* its type can then be restored with > " setreg(). > vnoremap * : > \let old_reg=getreg('"') > \let old_regmode=getregtype('"') > \gvy/=substitute(substitute( > \escape(@", '\\/.*$^~[]' ), "\n$", "", ""), > \"\n", '\\_[[:return:]]', "g") > \:call setreg('"', old_reg, old_regmode) > vnoremap # : > \let old_reg=getreg('"') > \let old_regmode=getregtype('"') > \gvy?=substitute(substitute( > \escape(@", '\\/.*$^~[]' ), "\n$", "", ""), > \"\n", '\\_[[:return:]]', "g") > \:call setreg('"', old_reg, old_regmode) > else > " If you use both VIM 6.2 and older versions these mappings > " should be defined depending on the current version. > vnoremap * :let old_reg=@" > \gvy/=substitute(substitute( > \escape(@", '\\/.*$^~[]' ), "\n$", "", ""), > \"\n", '\\_[[:return:]]', "g") > \:let @"=old_reg > vnoremap # :let old_reg=@" > \gvy?=substitute(substitute( > \escape(@", '\\/.*$^~[]' ), "\n$", "", ""), > \"\n", '\\_[[:return:]]', "g") > \:let @"=old_reg > endif This is where I got my inspiration. Note the exact same credits. But I found the mappings so illegible that I rewrote them as functions. I don't find using a function to be much of a "con" compare to the "pro" of legibility. The function I posted today has already been hacked and made better. It would take much more time and thought to modify these monsters... Reading the comments at the top, I thought for a minute that the mapping could search for a blockwise visual region. That would be pretty neat. -- JR
Re: VIM as C++ IDE
"Peng Yu" <[EMAIL PROTECTED]> 写于 2006-10-19 10:17:55: > On 10/18/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > > "Peng Yu" <[EMAIL PROTECTED]> 写于 2006-10-18 23:18:14: > > > Is it possible to not to press the last enter key? It is not very > > convenient. > > > > > > Thanks, > > > Peng > > > > try this instead: > > > > map :copep:w:make > > I still have to type Enter at the end. I don't have the same problem as you, and the mapping works for me. You'll have to be more specific and give more details, what did you see and why you must press Enter, and what you have configured for you vim (.vimrc might help). -- Sincerely, Pan, Shi Zhu. ext: 2606
Re: www.vim.org
Bram Moolenaar wrote: SourceForge has fixed the VHOST service, www.vim.org is back! I confirm that. If anyone cannot reach this address, it means there is a block somewhere else along the line; and if (wherever you are) http://www.vim.org/ still draws a blank for you, you might be able to circumvent the block by browsing to http://vim.sourceforge.net/ Best regards, Tony.
Re: Can the mailing list owner set "Reply-to" field be [EMAIL PROTECTED]
Peng Yu wrote: Hi, Can the mailing list owner set "Reply-to" field in every mail forward from this mailing list be "vim@vim.org"? I replied some mails to the original poster. But sometime I forget to reply the mails to the mailing list. Thanks, Peng If they do, you won't be able to (easily) reply privately to the author. "Reply to Sender" is meant to reply only to the author of an email. "Reply to All" is meant to reply to the author and all other recipients. This is exactly what happens when I use these two mailer functions on a vim-list post. I want _NO_ change. Is it so much of a trouble to train your fingers to use the "Reply to All" button whenever you're not restricting your reply to _only_ the author of an email? Best regards, Tony.
Re: VIM as C++ IDE
Hi, On 10/18/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: "Peng Yu" <[EMAIL PROTECTED]> 写于 2006-10-18 23:18:14: > On 10/15/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > > for that simple, don't need any plugin: > > > > map :w:make:cope > > > > You see, just add the :cope will do the trick. > > > > Note that the cursor will be in :cope window then, you may need to press an > > enter key to go into the first error. But what to do when there's no error? > > then does nothing. > > Is it possible to not to press the last enter key? It is not very convenient. > > Thanks, > Peng try this instead: map :copep:w:make You can also use the following map: nnoremap :update:make:copen:wincmd p - Yegappan
Re: Match something that not in the pattern
Peng Yu wrote: Hi, I have the following file segments. I want to concatenate all the lines with their next lines, except that it ends with "}}". I want to use the pattern "\(}}\)[EMAIL PROTECTED]". It seems not working. Would you please help me to figure out how to match the lineend without "}}"? Thanks, Peng To join every line not ending in }} with the following line, use the ":j[oin]" command on every line _not_ matching the pattern /}}$/ which means "two closing braces at end of line". As a cherry on the cake, you can avoid joining the last line in the file (which has no following line): :1,$-1v/}}$/j See :help multi-repeat :help :join Best regards, Tony.
Re: Can the mailing list owner set "Reply-to" field be [EMAIL PROTECTED]
"Peng Yu" <[EMAIL PROTECTED]> 写于 2006-10-19 10:22:31: > Hi, > > Can the mailing list owner set "Reply-to" field in every mail forward > from this mailing list be "vim@vim.org"? > > I replied some mails to the original poster. But sometime I forget to > reply the mails to the mailing list. > > Thanks, > Peng Just use "Reply to All" when reply your mail. -- Sincerely, Pan, Shi Zhu. ext: 2606
What's the exact meaning of the set 'background'?
Hi Vimmers, Recently, I've been thinking what this option is designed for. The document saids that: when 'background' is set Vim will adjust the default color groups for the new value. But the colors used for syntax highlighting will not change. But in fact, I had tested and found that when I set the 'background' option, Vim will source the color scheme script again. The idea seems to be good, if the color scheme script reads the 'background' option and set a different color according to the option everything should work... However, we could imagine... what will happen if I set background=light while the color scheme set background=dark inside the script? When we set background=light in command line, the script will be launched, and the background set to dark. then we will never be able to set background=light. Then, if another color scheme wants the value, it will always get background=dark even if the user set background=light. (Okay the "System" will try to set the 'background' option too, and that will more more confusing...) So, is 'background' option designed so that the color scheme should not read or write it at all? In my opinion it is introducing more confusing than good if it works this way. Could anyone explains what this option "exactly" means and what it is designed to and how should we use it? I've been quite confused now. -- Sincerely, Pan, Shi Zhu. ext: 2606
Re: Can the mailing list owner set "Reply-to" field be [EMAIL PROTECTED]
* A.J.Mechelynck [2006.10.18 23:30]: > "Reply to Sender" is meant to reply only to the author of an email. > > "Reply to All" is meant to reply to the author and all other recipients. "Reply to All" usually results in the author receiving duplicates. However since most mailers offer nothing but those two choices, it's probably the lesser of evils. Most mail clients suck. Decent mailers have "Reply to list" which avoids sending replies to both the mailing list and the author. Some mail clients suck less. ;-) -- JR
Re: Can the mailing list owner set "Reply-to" field be [EMAIL PROTECTED]
On Wednesday 18 October 2006 22:22, Peng Yu wrote: > Hi, > > Can the mailing list owner set "Reply-to" field in every mail forward > from this mailing list be "vim@vim.org"? > > I replied some mails to the original poster. But sometime I forget to > reply the mails to the mailing list. > Use a decent email client like kmail, mutt etc., which are "mailing list aware". That way if you hit 'L', the reply will be sent to the list. Of course, the letter 'L' can be configured to other letters if it is a decent email client. raju
Re: What's the exact meaning of the set 'background'?
[EMAIL PROTECTED] wrote: Hi Vimmers, Recently, I've been thinking what this option is designed for. The document saids that: when 'background' is set Vim will adjust the default color groups for the new value. But the colors used for syntax highlighting will not change. But in fact, I had tested and found that when I set the 'background' option, Vim will source the color scheme script again. The idea seems to be good, if the color scheme script reads the 'background' option and set a different color according to the option everything should work... However, we could imagine... what will happen if I set background=light while the color scheme set background=dark inside the script? When we set background=light in command line, the script will be launched, and the background set to dark. then we will never be able to set background=light. Then, if another color scheme wants the value, it will always get background=dark even if the user set background=light. (Okay the "System" will try to set the 'background' option too, and that will more more confusing...) So, is 'background' option designed so that the color scheme should not read or write it at all? In my opinion it is introducing more confusing than good if it works this way. Could anyone explains what this option "exactly" means and what it is designed to and how should we use it? I've been quite confused now. -- Sincerely, Pan, Shi Zhu. ext: 2606 'background' _tells_ vim whether the current default background is _currently_ dark or light. When gvim starts, it sets the default colors (for the Normal group and for any other group not having guibg= guifg= ) to guibg=white guifg=black, and 'backgound' to "light". When console Vim starts, it's not so easy. The current background and foreground are set by the underlying OS or terminal-emulator, and Vim tries to find out what they are set to. Depending on the underlying OS and terminal, it may or may not be possible to determine exactly what the current background is set to. If it cannot find out, Console Vim assumes that it is loaded in what used to be the "hardware" default colors of text terminals -- light grey on black for a color console, amber or green or grey on black for a monochrome console -- and sets 'background' to "dark". When creating a colorscheme, the following philosophies are possible: a) Set the Normal group to always the same defaults, and set 'background' accordingly. This is the simplest possibility, but it does _not_ let the user choose between "dark" and "light" versions of a single colorscheme, and it may look ugly on some console displays, depending on how the author's choices "marry" with the terminal's capabilities. b) Accept the current user-set setting of 'background' (and possibly the user-set highlight for the Normal group), and define the highlight groups accordingly: - some highlight groups may have both ctermbg/guibg and ctermfg/guifg set - if setting ctermbg/guibg for the Normal group, it should be set to a "brighter" colour if 'background' is "light", and to a "darker" colour if 'background' is "dark". - when not setting ctermbg/guibg for some group, ctermfg/guifg should be set to a relatively "darker" colour if 'background' is set to "light", or to a relatively "brighter" colour if 'background' is set to "dark". This second method is the most versatile, but in effect it doubles the workload of the colorscheme author, since the single colorscheme script must contain two sets of settings for cterm and also two sets for gui. c) Start the colorscheme with hi clear Normal set bg& hi clear to reset every color not set by the colorscheme to the program-startup defaults. Then proceed as in (b) above. When used in a cterm, this third method assumes that when "set bg&" 'guesses' whether the current Normal background is light or dark, the result can be accepted. This is what the "default" colorscheme does (and some others like my "almost-default" which has been circulated as an attachment to some of my posts in this list); it may be off on some terminal emulators, if they start with a dark-on-bright setting and don't (or can't) respond properly to a program's query about "what are the current display colors set to?". This third method is less versatile than the second but less frozen than the first one. It lies more or less halfway between them in terms of workload for the colorscheme author, since in most cases it must take into account the possibilities cterm/dark cterm/light and gui/light (and possibly term/dark if it wants compatibility with monochrome text displays). The user has no choice over whether a dark or light background is used, except by changing the cterm colours before starting console Vim. This third method is also the only one of the three where Vim may have to "guess" what the system colours are set to, and this introduces the risk of guessing wrong. If the colorscheme
Re: What's the exact meaning of the set 'background'?
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. Therefore, your colorscheme could just read the value of 'background' and choose appropriate colors, or it could set it the value of background to light or dark, and choose those colors, because if Vim sees the colorscheme trying to set 'dark' when you have just selected 'light', it ignores your colorscheme. regards, peter --- [EMAIL PROTECTED] wrote: > > Hi Vimmers, > > Recently, I've been thinking what this option is designed for. > > The document saids that: > > when 'background' is set Vim will adjust the default color groups for the > new value. But the colors used for syntax highlighting will not change. > > But in fact, I had tested and found that when I set the 'background' > option, Vim will source the color scheme script again. The idea seems to be > good, if the color scheme script reads the 'background' option and set a > different color according to the option everything should work... > > However, we could imagine... what will happen if I set background=light > while the color scheme set background=dark inside the script? When we set > background=light in command line, the script will be launched, and the > background set to dark. then we will never be able to set background=light. > Then, if another color scheme wants the value, it will always get > background=dark even if the user set background=light. (Okay the "System" > will try to set the 'background' option too, and that will more more > confusing...) > > So, is 'background' option designed so that the color scheme should not > read or write it at all? In my opinion it is introducing more confusing > than good if it works this way. > > Could anyone explains what this option "exactly" means and what it is > designed to and how should we use it? I've been quite confused now. > > -- > Sincerely, Pan, Shi Zhu. ext: 2606 > > Do you Yahoo!? Spring Racing Carnival - Check out Sonia Kruger's blog http://au.sports.yahoo.com/racing/
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
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: Match something that not in the pattern
On Wed 18-Oct-06 9:20pm -0600, Peng Yu wrote: > On 10/18/06, Bill McCarthy <[EMAIL PROTECTED]> wrote: >> You're fairly close. Assuming you visually marked those >> lines, this solution is magic: >> >> '<,'>s/\%(}}\)\@> >> but this solution is very magic: >> >> '<,'>s/\v%(}})@> >> :h /\@> :h /\v > Could you please explain what these commands mean? Sure, let's use the first one: '<,'>s/\%(}}\)\@s/pattern After you mark the text to be modified, hitting ":" gives you, on the command line, ":'<,'>". So all you type is ":s/pattern" - the "'<,'>" is typed by Vim. This command deletes the first occurrence of "pattern" on each line in the range. (2) Instead of "pattern" I used pat1\@j|s/}}/&\r/g This is equivalent to type two commands: (1) '<,'>j That joins all the lines in the range to just one line. (2) s/}}/&\r/g That substitute command operates on the single resulting line of the join command command. Every '}}' will be replaced by '}}\r'. Where the '&' is replaced by the whole matched pattern and '\r' is an EOL (although '\n' is an EOL in a pattern). -- Best regards, Bill
Re: What's the exact meaning of the set 'background'?
[EMAIL PROTECTED] wrote: > "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 > > This is my (a) method for colorschemes: decide everything. It has the advantage (to the colorscheme writer) of needing only one set of cterm colours and one set of gui colours. Thanks for the clarification about ctermbg=NONE (and, I suppose, ctermfg=NONE). Best regards, Tony.