Re: buffer local autocmd
On 2007-06-05, Markus Schulz [EMAIL PROTECTED] wrote: hello, i want to setup some things only for php-source files. But i don't get the autocmd local to buffer. The setup was also applied to opened c++ files after the first php file. currently i have this inside my .vimrc (php.vim sets some tabulator options) autocmd FileType php source ~/.vim/php.vim i've tried something like: autocmd FileType buffer php source ~/.vim/php.vim without luck. Any hints how i can achieve this? The problem may be in your ~/.vim/php.vim file. Make sure any options are set there using setlocal, not just set. set applies most options globally while setlocal applies most options to only the current buffer. See :help setlocal To make mappings local to the current buffer, see :help map-buffer HTH, Gary -- Gary Johnson | Agilent Technologies [EMAIL PROTECTED] | Mobile Broadband Division | Spokane, Washington, USA
Re: vim apparently ignoring -c nomodeline cmdline option
On 2007-06-05, Rodolfo Borges [EMAIL PROTECTED] wrote:
When opening a file that ends with
# vim:fdm=marker:
vim keeps doing the folding, even if I call it with -c nomodeline (I
also tried -c modelines=0).
Is it vim fault's, or (more likely) mine?
Note that :help -c says:
-c {command}{command} will be executed after the first file
has been read (and after autocommands and
modelines for that file have been processed).
Try using --cmd instead of -c. See
:help --cmd
Regards,
Gary
--
Gary Johnson | Agilent Technologies
[EMAIL PROTECTED] | Mobile Broadband Division
| Spokane, Washington, USA
Re: [Cygwin] Configure Detects Incorrect Ruby Version
On 2007-06-03, Taylor Venable [EMAIL PROTECTED] wrote: Hello, When I compile Vim 7.1.2 under Cygwin (on Windows XP), the configure script incorrectly identifies the version of my Ruby interpreter. The output from the configure script is as follows: checking --enable-rubyinterp argument... yes checking for ruby... /usr/bin/ruby checking Ruby version... too old; need Ruby version 1.6.0 or later But running `ruby --version` yields: ruby 1.8.6 (2007-03-13 patchlevel 0) [i386-cygwin] Any ideas? Thanks. I don't know anything about Ruby and not much about the inner workings of configure, but it appears that the ruby version is being checked at line 881 of vim71/src/configure.in: if $vi_cv_path_ruby -e '(VERSION rescue RUBY_VERSION) = 1.6.0 or exit 1' /dev/null 2/dev/null; then where I think $vi_cv_path_ruby is /usr/bin/ruby. That doesn't tell me anything other than that the version is not being determined by executing ruby --version, but maybe it tells you something useful. HTH, Gary -- Gary Johnson | Agilent Technologies [EMAIL PROTECTED] | Mobile Broadband Division | Spokane, Washington, USA
Re: Problems with netrw directory listing
On 2007-06-03, Seth Mason [EMAIL PROTECTED] wrote: Hi -- I'm running version 7.1 under cygwin on a windows xp machine. I'm trying to cd to the current directory with the directory browser (via the 'c' key) but I get the error message: E172: Only one file name allowed: cd /cygdrive/c/Documents and Settings/smason/projec ts/ It seems like the spaces in the directory name is causing problems. If I open a file in the directory and then use ':cd %:h' everything works fine so it seems like the problem is not with vim(?). Any help or direction to go from here would be greatly appreciated. I see the problem. I believe it is a bug in autoload/netrw.vim (at line 1593 in version 109) in the definition of the c command: nnoremap buffer silent c :exe cd .b:netrw_curdircr Any spaces in b:netrw_curdir are not escaped and the directory name is not in quotes, so the cd command sees any spaces as separators. I don't know at the moment what the right solution is. The following workaround seems to fix this particular problem, but it may introduce other problems especially when running vim in a pure Unix or pure Windows environment. nnoremap buffer silent c :exe cd ''.b:netrw_curdir.''cr Dr. Chip probably has some preferred solution for this sort of problem. Regards, Gary -- Gary Johnson | Agilent Technologies [EMAIL PROTECTED] | Mobile Broadband Division | Spokane, Washington, USA
Re: running vim on cygwin
On 2007-06-04, [EMAIL PROTECTED] wrote: Gary Johnson [EMAIL PROTECTED] 2007-06-04 13:32:36: If that's really the problem, all you have to do is install the libncurses-devel package before running 'configure'. You certainly can use the Cygwin source package, but it's not necessary. HTH, Gary Probably you are right, installing cygwin source package or binary package will automatically install the required dependencies... and the dependencies might be a reason. Installing a Cygwin source package doesn't seem to automatically install dependencies. I had to track down and install the libncurses-devel package myself the first time I built vim from Cygwin sources and discovered that it didn't have color. Regards, Gary -- Gary Johnson | Agilent Technologies [EMAIL PROTECTED] | Mobile Broadband Division | Spokane, Washington, USA
Re: how to ..... compiler
On 2007-05-31, Jagpreet [EMAIL PROTECTED] wrote: Hi There, I can't make use of built-in compiler facility in vim. Tried the help files(quickfix and FAQ) as well but couldn't get much about the same. I want to compile a project, where the files are distributed among different directories. I have my own makefile but want to make use of vim's facility for the same ( much like turbo C where U get a spilte window where errors are marked). Further I came across a script http://www.vim.org/scripts/script.php?script_id=213 which provides similar kinda utility about the same. But again not much details mentioned in the doc file(csupport.txt) about external make. How can I run my makefile(external) within vim. Further How to check and add ,if missing, compiler support in vim( say HP-UX xompiler aCC). Everything you need to know should be here, :help quickfix and especially here, :help make_makeprg If you already have a working Makefile, and you build your code from the shell prompt by executing make, then you should be able to start vim in the directory where you execute make in the shell and simply execute :make within vim. If that doesn't work, then tell us exactly what you tried and exactly what the results were. As for support for HP's aCC, there is a compiler plugin already for that compiler, $VIMRUNTIME/compiler/hp_acc.vim. You can invoke the settings in that file by executing :compiler! hp_acc Do that before you execute :make. See :help :compiler Regards, Gary -- Gary Johnson | Agilent Technologies [EMAIL PROTECTED] | Mobile Broadband Division | Spokane, Washington, USA
Re: running vim on cygwin
On 2007-06-04, Kamaraju Kusumanchi [EMAIL PROTECTED] wrote: Quoting Gary Johnson [EMAIL PROTECTED]: I think 'infocmp' is part of the default cygwin installation, so you should have it. Execute it in the same bash shell you used to run vim and see what you get. The first three lines should look like this. # Reconstructed via infocmp from file: /usr/share/terminfo/c/cygwin cygwin|ansi emulation for Cygwin, am, hs, mir, msgr, xon, colors#8, it#8, pairs#64, That will verify that your terminfo database is properly installed and readable. If you get something else, it may indicate what the problem is. bash-3.2$infocmp infocmp: couldn't open terminfo file . So this could be a problem. But I dont know how to solve it. The termcap 20050421-1, terminfo 5.5_20061104-1 are already installed on this system via cygwin. Is there anything else I could do? Yep, that's a problem all right. However, I don't know enough about the Cygwin installation process to know what could have gone wrong. To pursue this further, I'd have to ask the folks on the cygwin mailing list. I would suggest you go to the Cygwin web site and see what you can find about this in the FAQ (http://cygwin.com/faq.html) or in the mailing list archives (http://cygwin.com/ml/cygwin/). If that doesn't get you anywhere, then read http://cygwin.com/lists.html and http://cygwin.com/problems.html, join the cygwin mailing list and post your question there. Something else you might do is execute vim --version [...] Linking: gcc -L/usr/local/lib -o vim.exe -lncurses -liconv -lintl and will show whether or nor your vim was linked with the ncurses library. It was, so that's further evidence that vim itself is OK and that your problem is in your Cygwin installation. I have also installed the libncurses-devel 5.5-3 packages. But that did not change anything... No, that won't change anything unless your are compiling an application that uses ncurses. Regards, Gary -- Gary Johnson | Agilent Technologies [EMAIL PROTECTED] | Mobile Broadband Division | Spokane, Washington, USA
Re: running vim on cygwin
On 2007-06-03, Kamaraju Kusumanchi [EMAIL PROTECTED] wrote: Hi I installed vim 7.1 via cygwin on Windows XP machine. However, when I run vim on the bash shell of cygwin, I am getting the following error. E558: Terminal entry not found in terminfo 'cygwin' not known. Available builtin terminals are: builtin_riscos builtin_amiga builtin_beos-ansi builtin_ansi builtin_pcansi builtin_win32 builtin_vt320 builtin_vt52 builtin_xterm builtin_iris-ansi builtin_debug builtin_dumb defaulting to 'ansi' Can anyone help me get rid of this error. This error stays on the screen for about 3 seconds. Then it disappears and the vim screen appears. Any ideas? Something seems to be wrong with your Cygwin installation. I have installed the vim 7.0 packages from Cygwin, built vim 7.0 from Cygwin sources, and recently built vim 7.1 from vim.sf.net sources on Cygwin and I have never seen that error. I think 'infocmp' is part of the default cygwin installation, so you should have it. Execute it in the same bash shell you used to run vim and see what you get. The first three lines should look like this. # Reconstructed via infocmp from file: /usr/share/terminfo/c/cygwin cygwin|ansi emulation for Cygwin, am, hs, mir, msgr, xon, colors#8, it#8, pairs#64, That will verify that your terminfo database is properly installed and readable. If you get something else, it may indicate what the problem is. Something else you might do is execute vim --version and report here what you get. Seeing the whole thing might be useful, but I am particularly interested in the last line, which should look something like this, Linking: gcc -L/use/local/lib -o vim.exe -lncurses -liconv and will show whether or nor your vim was linked with the ncurses library. HTH, Gary -- Gary Johnson | Agilent Technologies [EMAIL PROTECTED] | Mobile Broadband Division | Spokane, Washington, USA
Re: running vim on cygwin
On 2007-06-04, [EMAIL PROTECTED] wrote: Kamaraju Kusumanchi [EMAIL PROTECTED] 2007-06-04 11:56:39: Hi I installed vim 7.1 via cygwin on Windows XP machine. However, when I run vim on the bash shell of cygwin, I am getting the following error. E558: Terminal entry not found in terminfo 'cygwin' not known. Available builtin terminals are: Generally, this will occur if you download vim source from vim official site and compile under cygwin by yourself. Use the version comes from cygwin will solve the problem. you can use the pre-compiled binary included in cygwin, or use the source package in cygwin. If that's really the problem, all you have to do is install the libncurses-devel package before running 'configure'. You certainly can use the Cygwin source package, but it's not necessary. HTH, Gary -- Gary Johnson | Agilent Technologies [EMAIL PROTECTED] | Mobile Broadband Division | Spokane, Washington, USA
Re: :scriptfiles
On 2007-06-01, Tushar Desai [EMAIL PROTECTED] wrote: I was previously able to do :scriptfile for vim 7.1 (on Fedora Core 6), when I was debugging why my plugins won't work. Then to check if plugins would work in vim 7.0, I did a make install from vim 7.0. Since they didn't seem to work in vim 7.0, I reverted back to vim 7.1, by doing a make install from vim 7.1 directory. Now, if I type :scriptfile, vim complains that it is not an editor command. (I'm seeing the same issue on Ubuntu Feisty with vim 7.1.) Any ideas why it would stop working? (Probably that will also explain why my plugins are not working.) I don't think there has ever been a :scriptfile command, but there is a :scriptnames command. HTH, Gary -- Gary Johnson | Agilent Technologies [EMAIL PROTECTED] | Mobile Broadband Division | Spokane, Washington, USA
Re: VimWiki - referring to vimdoc
On 2007-05-23, Sebastian Menge [EMAIL PROTECTED] wrote: Im tweaking the import script right now, and noticed that there are many references to the :help. I would like to replace all the occurrences of sth. like (:help some-text) by a reference to vimdoc. Does someone know how what URL could be used instead of :help sometext ?? I think I'd keep the :help sometext so that people can access the topic locally if they want to. This is especially important if someone prints a paper copy of the tip. The official on-line help files seem to be at http://vimdoc.sourceforge.net/htmldoc/. For example, the :help i_CTRL-W entry is found at http://vimdoc.sourceforge.net/htmldoc/insert.html#i_CTRL-W These URLs may have to be found manually, since they consist of the file name as well as the tag. I found the link http://vimdoc.sourceforge.net/htmldoc/tags.html#help-tags but the page is not available. (404) Executing :help tags.txt shows there is no tags.txt help file, so I wouldn't expect there to be a tags.html file, and :help help-tags shows there is no such tag, either. However, :help helptab shows :helptags, which is found in various.txt, so this URL should work: http://vimdoc.sourceforge.net/htmldoc/various.html#:helptags and it does. HTH, Gary -- Gary Johnson | Agilent Technologies [EMAIL PROTECTED] | Mobile Broadband Division | Spokane, Washington, USA
Re: Opening files matching tags in another window
On 2007-05-23, cupaxe [EMAIL PROTECTED] wrote: Hello, This is a newbie question. I want to have a functionality similar to g CTRL-] which implements the command :stj [ident]. Is there something like that? I wasn't able to find it in :help tags. Do you mean like either of these? I'm not very familiar with all the various tag commands. :help CTRL-W_] :help CTRL-W_g_CTRL-] For a list of similar functions, see :help window-tag HTH, Gary -- Gary Johnson | Agilent Technologies [EMAIL PROTECTED] | Mobile Broadband Division | Spokane, Washington, USA
Re: How to alter the cscope search results in the vim so that they refer to the right files.
On 2007-05-22, Natesh Kedlaya [EMAIL PROTECTED] wrote: From: Gary Johnson [EMAIL PROTECTED] Sent: Monday, May 21, 2007 5:30:52 PM On 2007-05-21, Natesh Kedlaya [EMAIL PROTECTED] wrote: Hi, I am using Vim6.3 My cscope db was built on a source directory structure 'src1' which was mounted on /dir1. If I use this cscope db in my vim, my cscope query would yeild following results. [...] Any pointers appreciated. You asked this question before on May 3 and May 7 and I replied with a suggestion. Did you try that? Hi Gray, Yes, I have tried it. But, no luck. No luck in that cscope commands still tried opening the /dir1 files? No luck in that cscope commands didn't work at all? Vim has no way that I know of of altering the names it gets from cscope, so I think the only alternatives are: 1. correct the cscope database (e.g., apply a sed command to change /dir1 to /dir2 when copying the database), 2. insert a filter between cscope and vim (e.g., with a wrapper script around cscope), 3. execute cscope as a quickfix command (instead of using the :cs commands) and filter its output before being read by vim. If you would like help in getting any of those to work, we're going to have to know exactly what you tried and exactly what happened when it didn't work. It will also help to keep the conversation on the list (I cc'd vim@vim.org) so that others can follow the discussion and contribute. Regards, Gary -- Gary Johnson | Agilent Technologies [EMAIL PROTECTED] | Mobile Broadband Division | Spokane, Washington, USA
Re: How to alter the cscope search results in the vim so that they refer to the right files.
On 2007-05-22, Natesh Kedlaya [EMAIL PROTECTED] wrote:
Hi Gary,
I apologize for my earlier email. I should have given the full details.
I would like to provide it now.
I have tried your suggestion of setting the cscopeprg to a script that
contained
/usr/local/bin/cscope $@ | sed s@/dir1/@/dir2/@
But the cscope results still contained the directory /dir1 reference.
While doing this test, I have observed a strange behavior. If the cscopeprg
is set to anything other than /usr/bin/cscope and /usr/local/bin/cscope,
somewhow
the vim resets them back to /usr/bin/cscope.
So, I tried replacing the /usr/bin/cscope itself with the script mentioned
above and
got the following errors while opening any source files.
Error detected while processing /etc/vimrc:
line 35:
cs_read_prompt EOF: Interrupted system call
Interrupted
Error detected while processing /home/myname/.vimrc:
line1:
Interrupted
Interrupt: Hit ENTER or type command to continue
That is indeed strange behavior. Let's take one behavior at a time.
If setting 'cscopeprg' to the name of your script left the /dir1
references unchanged, then either that setting is being overwritten
or the sed command is failing. You can check the former by
executing
:verbose set cscopeprg?
which will return the current value of 'cscopeprg' and where it was
set last. You can check the sed script by changing it to
cat $@ | sed s@/dir1/@/dir2/@
and executing it from a shell prompt with the name of your cscope
database (cscope.out?) as the only argument. This will ensure that
the sed command is being executed in the same environment as when it
filters the output of cscope, helps catch quoting issues and avoids
copy-and-paste issues.
From what you said about the errors and the renaming of 'cscopeprg',
though, it looks more like something changing 'cscopeprg' than a
problem with the sed command.
I don't have an explanation for the errors from /etc/vimrc or
/home/myname/.vimrc yet. I don't know how the contents of
/usr/bin/cscope would affect the behavior of vim so early in vim's
startup. Unless, of course, either of those files executed a
:cscope command, which would also be unusual. You might take a look
at the lines where those errors are reported for a clue to what's
happening.
Out of the three solutions that you have suggested, would you please
elaborate on the third one, ie. execute cscope as a quickfix command
(instead of using the :cs
commands) and filter its output before being read by vim. This looks
very promising to me.
When the cscope feature was first added to vim, its results could
not be sent to the quickfix error list as they can now. I really
wanted to use the quickfix interface with cscope, so I wrote a
function to behave just like :cs find but to send the cscope
output to the quickfix list by setting 'grepprg' to cscope plus
some arguments. I've attached the function (actually a pair of
functions) to this message. You can invoke it from the command line
as, e.g.,
:Csfind g somevar
or bind it to a mapping, e.g.,
map silent ,g :Csfind g C-RC-WCRzv
to search for the definition of the symbol under the cursor.
Regards,
Gary
--
Gary Johnson | Agilent Technologies
[EMAIL PROTECTED] | Mobile Broadband Division
| Spokane, Washington, USA
if v:version 602
Csfind
Usage:
:Csfind {querytype} {name}
Example:
:Csfind s myvar
finds all occurrences of the C symbol myvar.
command! -nargs=+ Csfind call Csfind(f-args)
function! Csfind(querytype, name)
Check the validity of the querytype argument.
if strlen(a:querytype) != 1 || stridx(01234678sgdctefi, a:querytype)
== -1
echohl ErrorMsg
echo Usage: :Csfind {querytype} {name}
echo See \:help cs\
echohl None
return
endif
Save previous 'grep' options.
let gf = grepformat
let gp = grepprg
Set new 'grep' options for running cscope.
set grepformat=%f\ %[%^\ ]%#\ %l\ %m
let grepprg = csprg . -L -f . s:cscope_database
Find the numerical form of the querytype.
if a:querytype =~ '\d'
let num = a:querytype
else
let num = stridx(sgdct?efi, a:querytype)
endif
Do it.
execute grep - . num . a:name
Restore previous 'grep' options.
let grepprg = gp
let grepformat = gf
endfunction
else
Csfind()
This function uses :try and related commands which were first introduced
at vim-6.2, so any application should check for v:version = 602 before
calling it.
When errors occur within a function, vim prints the function name and
line number as well as the error message
Re: A performance question
On 2007-05-22, Robert Maxwell Robinson [EMAIL PROTECTED] wrote: :set undolevels=-1 caused my test to run in less than 15 sec, with no other options fiddled with. Thanks Tim, now I have a work-around! Now, does having the undo facility available _necessarily_ mean deleting a large chunk of a file takes so long, or can that be added to the list of desired performance enhancements? Not in my experience. In both experiments I reported earlier I hadn't done anything special with 'undolevels' and checking them now shows undolevels=1000. I repeated the experiment on the Linux system staring vim as vim -u NONE two_million_lines :.,$d took 13 seconds. I did notice that the CPU was railed at 100% during that time, so loading of your CPU by other tasks may have an effect, as might the actual physical memory available to vim. :set undolevels=-1 did reduce the time to 10 seconds. Regards, Gary -- Gary Johnson | Agilent Technologies [EMAIL PROTECTED] | Mobile Broadband Division | Spokane, Washington, USA
Re: A performance question
On 2007-05-22, Robert Maxwell Robinson [EMAIL PROTECTED] wrote: Hmm, interesting. I've noticed before that the CPU is pegged when I'm deleting, but I don't think my machine's behavior is due to CPU load; the machine has two CPUs, I'm typically the only (serious) user, as top has confirmed is the case now, and I get the same behavior whether I'm running another large job or not. My other large job takes about 1 Gb leaving almost 2 Gb of memory free, so I don't think I'm running out of physical memory, either. Given the difference between your results and mine, I finally checked my software versions, which are old: Red Hat 3.4.6, vim 6.3.82. Unfortunately I don't have permission to update this system, and the administrator hasn't been willing to do so in the past. It turns out that this Red Hat installation also has vim 6.3.82 in /usr/bin/vim, so I tried that, too. /usr/bin/vim -u NONE two_million_lines 50% :.,$d 2 minutes 30 seconds! Eureka! According to the System Monitor CPU bar color, that was almost all User time, whereas with vim 7.1, it was a more balanced mix of User and Kernel time. (Kudos to Bram for such a performance improvement from vim 6 to 7!) I'm not allowed to update anything under /usr on this system, either, so I build the latest and greatest versions of tools under $HOME/src and put the binaries in $HOME/bin. Building vim under Linux is really easy. I do the following. mkdir ~/src/Linux/vim-7.1 cd ~/src/Linux/vim-7.1 Download vim-7.1.tar.bz2 from vim.sf.net. tar jxf vim-7.1.tar.bz2 cd vim71 ./configure --prefix=$HOME/src/Linux/vim-7.1 --enable-cscope make make install ln -s $HOME/src/Linux/vim-7.1/bin/vim ~/bin/Linux/vim My PATH includes $HOME/bin/Linux and that directory contains most of the symbolic links to vim that you will find in $HOME/src/Linux/vim-7.1/bin; the ones I use. That is, $ cd ~/bin/Linux $ ls -l | grep vim lrwxrwxrwx 1 garyjohn fw 3 Nov 14 2005 gvim - vim lrwxrwxrwx 1 garyjohn fw 3 Nov 14 2005 gvimdiff - vim lrwxrwxrwx 1 garyjohn fw 3 Sep 23 2005 vi - vim lrwxrwxrwx 1 garyjohn fw 3 Sep 23 2005 view - vim lrwxrwxrwx 1 garyjohn fw 40 May 17 18:45 vim - /home/garyjohn/src/Linux/vim-7.1/bin/vim lrwxrwxrwx 1 garyjohn fw 3 Sep 23 2005 vimdiff - vim That makes it really easy to update and to test different versions of vim with only a change to one symbolic link. But that's just a matter of taste. The point is that however you choose to install it, it's easy to build and maintain your own vim installation without having to bother or bother with your system administrator. I went looking for release notes for vim, but the announcements I found didn't go into detail about what bugs were fixed in which version. Can someone point me in the right direction? Go to the vim home page, vim.sf.net, click on the link to Documentation, then help files online, then main help file, and finally, version7.txt. Or you can just go that page directly, http://vimdoc.sourceforge.net/htmldoc/version7.html This describes all the changes from version 6 to version 7, including bug fixes. Regards, Gary -- Gary Johnson | Agilent Technologies [EMAIL PROTECTED] | Mobile Broadband Division | Spokane, Washington, USA
Re: Wish: col(^)
On 2007-05-21, Andy Wokula [EMAIL PROTECTED] wrote: ... get position of first non-blank character in the line. If there is col($), there should also be col(^). In some situations (e.g. :imap expr) :normal ^ is not allowed. indent(.)? HTH, Gary -- Gary Johnson | Agilent Technologies [EMAIL PROTECTED] | Mobile Broadband Division | Spokane, Washington, USA
Re: How to alter the cscope search results in the vim so that they refer to the right files.
On 2007-05-21, Natesh Kedlaya [EMAIL PROTECTED] wrote: Hi, I am using Vim6.3 My cscope db was built on a source directory structure 'src1' which was mounted on /dir1. If I use this cscope db in my vim, my cscope query would yeild following results. [...] Any pointers appreciated. You asked this question before on May 3 and May 7 and I replied with a suggestion. Did you try that? Gary -- Gary Johnson | Agilent Technologies [EMAIL PROTECTED] | Mobile Broadband Division | Spokane, Washington, USA
Re: repeating up/down/delete commands
On 2007-05-18, David Pike [EMAIL PROTECTED] wrote: Uh oh... I spoke slightly too soon. Although the up/down/delete functions that I first asked about now behave normally, the vim -N -u NONE -i NONE option now results in 999 dspace deleting 999 characters, often well beyond those of the present line. I had been used to this deleting up to 999 characters, but only up to the end of the present line. It appears that the set compatible option had been helping me to get the desired 'this line only' functionality, but the -N option above now overrides that. As others have written, there are more efficient ways to get the motion you want than to use a 999 prefix. Nevertheless, I know how it is when your fingers are used to certain ways of doing things and besides, it ought to work right. You said in your first post that you were using vim, so I assumed you had been using it in non-compatible mode. Since the 999 prefix used to work for you, and since it works for me in non-compatible mode, I think that is a safe assumption. I just tried another experiment and think I found the answer. I invoked vim as vim -u NONE which puts it into compatible mode. When I tried those commands, e.g., 999down and 999dd, I got a beep and no cursor motion! So your new installation of vim appears to be putting you in compatible mode whereas your previous installation put you in non-compatible mode. Now the question is, why. Take a look at :help compatible-default :help compatible and see if you can figure out from that what might have changed with this new installation. One way to make sure that vim starts in non-compatible mode is to make sure you have a .vimrc file in your HOME directory, even if the file is empty. You may also want to have a talk with the person who performed your vim upgrade and see if he can explain how and why the new configuration differs from the old one. He may appreciate knowing that something appears to have gone wrong and having the opportunity to fix it at the system level so that each user doesn't have to fix it for himself. This would also save you from troubleshooting this and possibly continuing to find things that no longer work as they used to. As for the 999dspace deleting characters beyond the current line, that behavior is affected by the 'whichwrap' option. If you get the 'compatible' thing fixed and 999dspace still deletes beyond the current line, put this in your ~/.vimrc file: set whichwrap-=s See :help whichwrap Regards, Gary -- Gary Johnson | Agilent Technologies [EMAIL PROTECTED] | Mobile Broadband Division | Spokane, Washington, USA
Re: Subject: Re: vim on cygwin using win32 clipboard
On 2007-05-17, Gary Johnson [EMAIL PROTECTED] wrote: On 2007-02-15, Frodak Baksik [EMAIL PROTECTED] wrote: On 2/15/07, Chris Sutcliffe wrote: Also, is there anything I can do to help get the original patch accepted? Ask a few people to try it out and report their results here. I'll give it a shot. Is there somewhere I can grab the patch from, or should I go through the list archives to find it? Here are all the changes in a single patch. I'm also posting this to the cygwin-apps mailing list, so if anyone over there could try it out would be nice. I just applied this patch to the 7.1 source. The patch to proto/os_mswin.pro failed, but it was easy to fix manually. The problem was that the extern prefix has been removed from the 7.1 declarations. Hunk #2 of the patch to os_win32.c failed, apparently because that change was already made to the 7.1 source, so I left that file with only hunk #1 applied. It looks like I goofed when applying the patch that way. I just applied the patch to another system, but edited the patch first to get rid of the failures instead of trying to edit the files afterwards. All I had to do to the proto/winclip.pro section was to remove extern from the start of all the lines. While editing the os_win32.c section, I discovered that 'patch' was missing the first hunk in the target and applying the first hunk of the patch to the second hunk in the target, causing the application of the second hunk of the patch to fail. This was cause by the reformatting of a comment from 7.0 to 7.1. I changed the comment in the patch to match the comment in the 7.1 source and the entire patch applied successfully. Regards, Gary -- Gary Johnson | Agilent Technologies [EMAIL PROTECTED] | Mobile Broadband Division | Spokane, Washington, USA
Re: repeating up/down/delete commands
On 2007-05-18, David Pike [EMAIL PROTECTED] wrote: This will hopefully be an easy question or two... An upgraded version of vim was installed on our systems recently, and some tricks that I'm used to are no longer functional, such as: [a large integer, say N] up to quickly get to the top of the file that I am editting, [N] down to quickly get to the last line of the file (similarly, PageUp and PageDown could be used). Also, while part way through a file, [N] dd or [N] d Enter was a handy way of deleting all remaining lines in the file. The new version of vim does not seem to let me do this anymore. Specifically, if the N value that I enter (typically ) is larger than the number of lines involved, then vim now just beeps to signal that it won't do what I would like to do. Is there some easy way of getting vim to accept these commands once again? I just tried this with a new installation of vim 7.1 on Linux and all of the examples you gave worked for me. This was true whether I invoked vim as just vim or as vim -N -u NONE -i NONE. I suspect some configuration file in your upgrade has botched this for you. Try invoking vim as vim -N -u NONE -i NONE as see if it still misbehaves. It might help us to know the operating system you are using and the complete output from vim --version, too. Regards, Gary -- Gary Johnson | Agilent Technologies [EMAIL PROTECTED] | Mobile Broadband Division | Spokane, Washington, USA
Re: Subject: Re: vim on cygwin using win32 clipboard
On 2007-02-15, Frodak Baksik [EMAIL PROTECTED] wrote: On 2/15/07, Chris Sutcliffe wrote: Also, is there anything I can do to help get the original patch accepted? Ask a few people to try it out and report their results here. I'll give it a shot. Is there somewhere I can grab the patch from, or should I go through the list archives to find it? Here are all the changes in a single patch. I'm also posting this to the cygwin-apps mailing list, so if anyone over there could try it out would be nice. I just applied this patch to the 7.1 source. The patch to proto/os_mswin.pro failed, but it was easy to fix manually. The problem was that the extern prefix has been removed from the 7.1 declarations. Hunk #2 of the patch to os_win32.c failed, apparently because that change was already made to the 7.1 source, so I left that file with only hunk #1 applied. The code compiled without problem and seems to work fine. The patch seemed to work fine with 7.0, too, but I wasn't able to test it very much since I haven't had to do much work on Windows recently. Regards, Gary -- Gary Johnson | Agilent Technologies [EMAIL PROTECTED] | Mobile Broadband Division | Spokane, Washington, USA
Re: Vim71: breaking change not mentioned in the document.
On 2007-05-16, [EMAIL PROTECTED] wrote: Hi, vimmers: The line 1230 of editing.txt said: To change to the directory of the current file: :cd %:h This works for Vim 7.0 and before, but not for Vim 7.1. In Vim 7.1 when the pwd is the same as the directory of current file, the command will fail with E500. The failure will break the execution of a mapping, if one have a mapping to do :cd %:h and then continue to do something else. To reproduce the error, just at anytime, run :cd %:h twice. (I've got Windows gvim7.1.1, cygwin console vim 7.1.1) I would expect :cd %:h to give an error the second time it is executed. Just to be sure, I repeated your experiment on 7.1, 7.0 and 6.4 on Unix and 7.0 on Windows. I always got E500. Are you sure that it works for you for Vim 7.0? So there's at least two issues IMHO: 1. the line 1230 of editing.txt should be changed to :cd %:p:h I disagree. If you want to _change_ directory to that of the current file, the command :cd %:h is correct. If the working directory is already that of the current file, such that executing :cd %:h would give E500, then there is no reason to change directory. 2. somewhere in the document should mention: if we had used :cd %:h in our mappings or scripts, we should change them into %:p:h after upgraded to vim 7.1. I don't see that this behavior has changed. Regards, Gary -- Gary Johnson | Agilent Technologies [EMAIL PROTECTED] | Mobile Broadband Division | Spokane, Washington, USA
Re: Vim71: breaking change not mentioned in the document.
On 2007-05-16, [EMAIL PROTECTED] wrote: Gary Johnson [EMAIL PROTECTED] 2007-05-16 16:41:22: On 2007-05-16, [EMAIL PROTECTED] wrote: Hi, vimmers: The line 1230 of editing.txt said: To change to the directory of the current file: :cd %:h This works for Vim 7.0 and before, but not for Vim 7.1. In Vim 7.1 when the pwd is the same as the directory of current file, the command will fail with E500. The failure will break the execution of a mapping, if one have a mapping to do :cd %:h and then continue to do something else. To reproduce the error, just at anytime, run :cd %:h twice. (I've got Windows gvim7.1.1, cygwin console vim 7.1.1) I would expect :cd %:h to give an error the second time it is executed. Just to be sure, I repeated your experiment on 7.1, 7.0 and 6.4 on Unix and 7.0 on Windows. I always got E500. Are you sure that it works for you for Vim 7.0? Positive, I've got a mapping which do :cd %:h then :grep, this mapping works since Vim 6.3, 6.4 and 7.0, this is the mapping I used Everyday and I cannot use Vim without it, then suddenly it breaks after I installed Vim 7.1. Now I changed :cd %:h to :cd %:p:h and everything works. That's very strange. Your observations certainly don't match mine. I wonder what's going on. Anyway, I think there should be an option to disable E500, or catch and throw. This is the Unix trend: if the caller feel necessary, a program should fail silently in order not to break a script. I don't think disabling E500 would help. The text of E500 is, E500: Evaluates to an empty string. That's warning you that there is no head component of the file name. If you disabled the error, and presumably allowed %:h to return an empty string, then your :cd %:h command would be executing just :cd, which on a Unix system changes to the home directory--not what you want. Another way to fix your mapping would be to use :silent! cd %:h which allows the cd to fail silently. Regards, Gary -- Gary Johnson | Agilent Technologies [EMAIL PROTECTED] | Mobile Broadband Division | Spokane, Washington, USA
Re: Vim71: breaking change not mentioned in the document.
On 2007-05-17, [EMAIL PROTECTED] wrote: Gary Johnson [EMAIL PROTECTED] 2007-05-17 00:35:42: On 2007-05-16, [EMAIL PROTECTED] wrote: Gary Johnson [EMAIL PROTECTED] 2007-05-16 16:41:22: On 2007-05-16, [EMAIL PROTECTED] wrote: Hi, vimmers: The line 1230 of editing.txt said: To change to the directory of the current file: :cd %:h I don't think disabling E500 would help. The text of E500 is, E500: Evaluates to an empty string. That's warning you that there is no head component of the file name. If you disabled the error, and presumably allowed %:h to return an empty string, then your :cd %:h command would be executing just :cd, which on a Unix system changes to the home directory--not what you want. Another way to fix your mapping would be to use :silent! cd %:h which allows the cd to fail silently. Regards, Gary -- You certainly are right, disabling E500 would not help. However: The line 1230 of editing.txt said: To change to the directory of the current file: :cd %:h If I was tell that a script could change to the directory of the current file, I would think that it will always change to the directory of the current file, and it is absurd to see it will give an error when the pwd is already the directory of the current file. I'm sure most average users will take it for granted if the document says this. and they will not think the E500 is reasonable here. The document is aprently misleading. I see what you mean. Not everyone would read change to the directory of the current file as literally as I did in my initial reply. While the manual is correct, it could be more clear here. So, if :cd %:h must give E500 here, I think the document should change it to :cd %:p:h Yes, that seems reasonable. Regards, Gary -- Gary Johnson | Agilent Technologies [EMAIL PROTECTED] | Mobile Broadband Division | Spokane, Washington, USA
Re: Vim Wiki - Tip Page Formatting Deadline
On 2007-05-15, Tom Purl [EMAIL PROTECTED] wrote: Task: Wiki Format Sign-Off Deadline: Monday, May 21st (arbitrary, I know) Overview We've had some great, constructive discussions lately regarding how we will be creating and editing tips in the future. Before we can finally decide how this is going to work, however, we need to decide upon a page format for tips. The most recently-updated wiki tip examples can be found at the following URL: * http://scratchpad.wikia.com/wiki/VimTest The following tips should stand out: * http://scratchpad.wikia.com/wiki/VimTip1 * http://scratchpad.wikia.com/wiki/VimTip1_v2 This first tip uses the Template:Tip template (http://scratchpad.wikia.com/wiki/Template:Tip), and the second tip uses the Template:Tip2 template (http://scratchpad.wikia.com/wiki/Template:Tip2). Requested Actions = Please take a look at these tips, decide which one you prefer, and then provide constructive criticism for that tip's format. There's no such thing as a dumb comment. I much prefer VimTip1 v2. Whether just browsing tips or reading tips I've searched for, I want to be able to read it quickly without having to scan through a bunch of boilerplate. I would even advocate a Synopsis line that would summarize the tip if the title didn't already do so. I like having the meta data collected as it is in one line at the bottom of the tip: it's concise and in an unobtrusive yet consistent and easy-to-find location. In the table of contents, each tip really needs to have the title alongside its number. The first page, http://scratchpad.wikia.com/wiki/VimTest, is lacking that, unless the names there (e.g., VimTip123) are just place holders for real titles. I really don't want to have to load each tip page one at a time to browse the latest contributions. My $0.02. Regards, Gary -- Gary Johnson | Agilent Technologies [EMAIL PROTECTED] | Mobile Broadband Division | Spokane, Washington, USA
Re: Multiple commands from Fkey
On 2007-05-14, John R. Culleton [EMAIL PROTECTED] wrote: Gary wrote in part: nmap silent F2 :call DoSub()CR function DoSub() %s/^/``/e %s/ / ``/ge %s/$/''/e %s/ /'' /ge endfunction For my other F keys I have used noremap instead of nmap, thus: inoremap F3 C-O:!pdftex book.texCr nnoremap F3 :!pdftex book.texCr inoremap F4 C-O:!texexec book.tex /dev/nullCr nnoremap F4 :!texexec book.tex /dev/nullCr inoremap F5 C-O:!acroread book.pdfCr nnoremap F5 :!acroread book.pdfCr nnoremap F2 1GgqG Which is the better usage? I have read but do not understand fully the help item suggested previousely. Without the nore part, when the use presses the mapped key, vim executes the rhs of the mapping including executing any mappings it finds on the rhs. For example, if you define the following mapping, nmap D dj to delete the current line and the line below, and some plugin has redefined 'j' with nmap j k then when you type 'D', your macro will delete the current line and the line _above_. Adding nore tells vim to ignore any mappings on the rhs and to execute any commands on the rhs with their default actions. Continuing the example above, changing the 'D' mapping to nnoremap D dj will ensure that (as long as D itself is not remapped) typing 'D' will delete the current line and the line below regardless of any mapping of 'd' or 'j'. Including nore is then the safer usage since it protects the rhs of the macro from being affected by any mappings of the functions on the rhs. I didn't use 'nnoremap' in the F2 mapping above because I thought there was no possibility of a remapping of anything on the rhs, so that the nore would be superfluous, but now I see that the macro would be affected if someone defined ':' as a macro (a really poor choice). Regards, Gary -- Gary Johnson | Agilent Technologies [EMAIL PROTECTED] | Mobile Broadband Division | Spokane, Washington, USA
Re: Project specific settings
On 2007-05-14, [EMAIL PROTECTED] wrote: Hello, Marius Roets [EMAIL PROTECTED] wrote: I know this has been covered before, but I can't seem to find it by searching Vim tips, so please excuse me if this has been ask many times before. It is covered three times in vim scripts. I always uses spaces to indent my code, but a current project requires me to use tabs. How could I make this setting only be in effect for this one project, assuming that the project will always be a in a specific directory. Another solution is to use plugins like local_vimrc.vim (there are two similiar plugins with this name) or plugin.vim My search of scripts for local_vimrc yielded only one result, script #727. Searching for plugin or plugin.vim yields over 600 results. I don't see any way to perform a binary search of the results and paging through the list at 20 results per page is ridiculous. Using the Google search plugin.vim site:vim.sourceforge.vim yielded only 6 results, none of them doing what you described. Do you have the script numbers of those other scripts or know of a better way to find them? Regards, Gary -- Gary Johnson | Agilent Technologies [EMAIL PROTECTED] | Mobile Broadband Division | Spokane, Washington, USA
Re: Project specific settings
On 2007-05-14, Larson, David [EMAIL PROTECTED] wrote: From: Gary Johnson [mailto:[EMAIL PROTECTED] Sent: Monday, May 14, 2007 12:41 PM On 2007-05-14, [EMAIL PROTECTED] wrote: Another solution is to use plugins like local_vimrc.vim (there are two similiar plugins with this name) or plugin.vim My search of scripts for local_vimrc yielded only one result, script #727. Searching for plugin or plugin.vim yields over 600 results. I don't see any way to perform a binary search of the results and paging through the list at 20 results per page is ridiculous. Using the Google search plugin.vim site:vim.sourceforge.vim yielded only 6 results, none of them doing what you described. Do you have the script numbers of those other scripts or know of a better way to find them? Gary, Make sure that when you search for scripts on vim.sf.net, that you select utility for the type. Doing that produces 66 results, and project.tar.gz is the first result... http://vim.sourceforge.net/scripts/script.php?script_id=69 I did that. Here are the results (the headings of the first search results pages) from searching for the plugin.vim script that Luc suggested. Search Results Searched utility scripts for plugin.vimShowing 1 to 20 of 649 results Search Results Searched utility scripts for pluginShowing 1 to 20 of 649 results If one searches instead for project, one does indeed get 66 results. Search Results Searched utility scripts for project Showing 1 to 20 of 66 results Maybe that's what Luc intended, but it isn't what he wrote. Regards, Gary -- Gary Johnson | Agilent Technologies [EMAIL PROTECTED] | Mobile Broadband Division | Spokane, Washington, USA
Re: formatoptions: is there a way to disable a for a range?
On 2007-05-12, Allan Wind [EMAIL PROTECTED] wrote: I would like to auto-wrap emails and set formatoptions to tcqlaqw with: autocmd FileType mail set formatoptions+=aw Other than missing the mentioned j in vim 7.0 to make join remove comment leaders this works great for the body of the message. Trouble is that I have mutt configured to pass in headers, and obviously do not want header lines wrapped. Any ideas on how to configure vim to not wrap the header but do wrap the body of a mail automatically? mail syntax already knows what a header looks like including quoted headers, so perhaps there is a way to use that? I've played with this a little, with mixed success. My solution works well enough most of the time that I haven't taken the time to make it better, but it doesn't work well enough that I would post it as a plugin. I use this autocommand, au CursorHold * if ft == 'mail' | call SIDflowed_context() | endif and a function, s:flowed_context(), that attempts to determine which part of the message the cursor is in by executing let syn_name = synIDattr(synID(line(.), col(.), 1), name) if syn_name =~ ^mailHeader || syn_name == mailEmail || syn_name == mailSubject let l:msg_part = header let in_body = 0 elseif syn_name == mailSignature let l:msg_part = signature let in_body = 0 else let l:msg_part = body let in_body = 1 endif and then sets 'formatoptions' with or without 'aw' depending on the value of 'in_body'. One of the problems with it is that sometimes, as I'm editing the header, the text is no longer identified by the syntax rules as part of the header, so 'aw' gets added to 'formatoptions' and the header text gets messed up. If I were to work on this more, I think I would search the buffer to find the boundaries between parts instead of using the syntax highlighting and use the new winsaveview() and winrestview() functions to more completely save and restore the window and cursor states at the start and end of the flowed_context() function. Those functions weren't available when I first wrote the function, which is why I used syntax highlighting to determine where the cursor was in order to avoid moving the cursor during the autocommand. HTH, Gary -- Gary Johnson | Agilent Technologies [EMAIL PROTECTED] | Mobile Broadband Division | Spokane, Washington, USA
Re: Vim 7 show current column
On 2007-05-10, Brian E. Lozier [EMAIL PROTECTED] wrote: In vim 6, a line at the bottom would show the column the cursor is over, so I could see like, colymn 79 or whatever. On vim 7 (gvim, more specifically), the status line at the bottom doesn't show up. Is there a way to enable it? If you want the full status line, set laststatus=2 If you just want to see the cursor position, set ruler I don't know why it was there for you in vim 6 but not in vim 7 unless your upgrade process did more than just change the vim binaries and runtime files. Perhaps your new installation changed the system vimrc as well. HTH, Gary -- Gary Johnson | Agilent Technologies [EMAIL PROTECTED] | Mobile Broadband Division | Spokane, Washington, USA
Re: [PATCH] vim_is_xterm() and screen
On 2007-05-09, Micah Cowan [EMAIL PROTECTED] wrote: Towards a better solution: how straightforward do you think it'll be to talk the ncurses guys into adding support for some of screen's extensions? AFAIK, the only one I care about is the xterm mouse support; another interesting one is a boolean supports ansi setforeground/setbackground codes; but I usually infer this (if necessary) from the presence of setaf/setbf (not a given, but...). The ncurses guys is Thomas Dickey, who frequents a number of lists and newsgroups, and who would probably be willing to discuss it with you. Contact information is here: http://www.gnu.org/software/ncurses/ Look for Who's Who and What's What. You might also consider joining the bug-ncurses-request mailing list, which is open to anyone interested in helping with the development and testing of this package. I would imagine the process would be more a matter of convincing Thomas to accept the concept, the design, and any patches you would submit, rather than the ncurses guys adding this support themselves. Regards, Gary -- Gary Johnson | Agilent Technologies [EMAIL PROTECTED] | Mobile Broadband Division | Spokane, Washington, USA
Re: omni-completion
On 2007-05-09, Normandie Azucena [EMAIL PROTECTED] wrote: hi all! this will seem to be a dumb question. what is omni-completion? How can I use it in vim? How can I create my own? :help compl-omni :help 24.3 HTH, Gary -- Gary Johnson | Agilent Technologies [EMAIL PROTECTED] | Mobile Broadband Division | Spokane, Washington, USA
Re: VimWiki - again - but with a brand new option
On 2007-05-08, Ian Tegebo [EMAIL PROTECTED] wrote: On 5/8/07, Bram Moolenaar [EMAIL PROTECTED] wrote: Ian Tegebo wrote: I would like to make another implementation independent suggestion; one could make a VimWiki more valuable by importing the _extremely_ valuable vim helpfiles into it. Please don't do this. It might sound like a nice idea, but it means making a branch that will be very hard to merge back into the help files of the distribution. I feel misunderstood but it serves me right for not saying what I mean... Synchronizing data is no fun, I agree. While I was up in the clouds I was imaging that the wiki would be the authoritative source for the helpfiles after doing an initial _import_. Then the text version would be exported as needed, e.g. end user runtime update or for a new release. This seems like a bad idea. The vim help files are an authoritative source because their content is under the control of an authority: Bram. Others are encouraged to submit patches that correct errors or clarify wording, but before any of those patches are applied, Bram looks at them to be sure they are correct and consistent with the help files' style. A wiki allows every Tom, Dick and Harry to make changes to it, whether they know what they're talking about or not. Wikis are useful, but it's difficult to ensure their correctness. Requiring Bram to vet every page before it is included in vim's help files would be an undue burden on him as well as a poor use of his time. A wiki is a good idea, but the content should be separate from the help files. Regards, Gary -- Gary Johnson | Agilent Technologies [EMAIL PROTECTED] | Mobile Broadband Division | Spokane, Washington, USA
Re: VimWiki - again - but with a brand new option
On 2007-05-08, Ian Tegebo [EMAIL PROTECTED] wrote: On 5/8/07, Bram Moolenaar [EMAIL PROTECTED] wrote: Ian Tegebo wrote: I would like to make another implementation independent suggestion; one could make a VimWiki more valuable by importing the _extremely_ valuable vim helpfiles into it. Please don't do this. It might sound like a nice idea, but it means making a branch that will be very hard to merge back into the help files of the distribution. I feel misunderstood but it serves me right for not saying what I mean... Synchronizing data is no fun, I agree. While I was up in the clouds I was imaging that the wiki would be the authoritative source for the helpfiles after doing an initial _import_. Then the text version would be exported as needed, e.g. end user runtime update or for a new release. This seems like a bad idea. The vim help files are an authoritative source because their content is under the control of an authority: Bram. Others are encouraged to submit patches that correct errors or clarify wording, but before any of those patches are applied, Bram looks at them to be sure they are correct and consistent with the help files' style. A wiki allows every Tom, Dick and Harry to make changes to it, whether they know what they're talking about or not. Wikis are useful, but it's difficult to ensure their correctness. Requiring Bram to vet every page before it is included in vim's help files would be an undue burden on him as well as a poor use of his time. A wiki is a good idea, but the content should be separate from the help files. Regards, Gary -- Gary Johnson | Agilent Technologies [EMAIL PROTECTED] | Mobile Broadband Division | Spokane, Washington, USA
Re: Vim version 7.1a BETA has been released
On 2007-05-06, Bram Moolenaar [EMAIL PROTECTED] wrote: Gary Johnson wrote: I noticed that filetype.vim does not include the patch that I submitted to this list 2006-07-25 to fix the recognition of mutt temporary files on SunOS. Is there something else I can do to have this patch accepted? It was still in the todo list. There are many items I still didn't have time for, unfortunately. I assume you have properly tested this change. I'll include this one now. Thank you. I was concerned that it hadn't made it onto the list. I didn't realize you had such a backlog of changes. I've been using it in my $VIMRUNTIME/filetype.vim since July without any problems or errors that I know of. Best regards, Gary -- Gary Johnson | Agilent Technologies [EMAIL PROTECTED] | Mobile Broadband Division | Spokane, Washington, USA
Re: Vim version 7.1a BETA has been released
On 2007-05-06, Gary Johnson [EMAIL PROTECTED] wrote: On 2007-05-05, A.J.Mechelynck [EMAIL PROTECTED] wrote: Compiles as a breeze :-). Yes indeed. I've compiled it so far on SunOS 5.8 and HP-UX 10.20. I may try Cygwin if I'm feeling adventurous enough. I've never done that except from Cygwin sources. Well, that was really easy. I built just the console version for Cygwin and it seems to work fine in PuTTY over an ssh connection. Regards, Gary -- Gary Johnson | Agilent Technologies [EMAIL PROTECTED] | Mobile Broadband Division | Spokane, Washington, USA
Re: Error while opening the cscope referenced file in vim
On 2007-05-03, Natesh Kedlaya [EMAIL PROTECTED] wrote: Hi, I have built a cscope db of a source tree which was mounted on /mnt. Now, I want to use the same cscope db on the same source tree but mounted on a different mount point /scratch. I could achieve this using the standard cscope and EDITOR env variable trick as shown below. 1. set the EDITOR to a shell script of my own. The shell script contains the following lines in it. #!/bin/sh offset=$1 fname=`echo $2 | sed s@/mnt/@/scratch/@` xterm -e /usr/bin/vim $offset $fname 2. Run cscope and when it tries to open a file, it goes through my EDITOR script and does the right job. How do I achieve the same in vim6.3? I have the necessary settings in my .vimrc to work with cscope : if has(cscope) set cscopeprg=/usr/local/bin/cscope set csto=0 set cst set nocsverb add any database in current directory if filereadable(cscope.out) cs add cscope.out else add database pointed to by environment elseif $CSCOPE_DB != cs add $SRCHOME/$NDE_PRODUCT/utl/ $SRCHOME -U endif set cspc=5 set csverb endif Here's an idea, untested. Create a wrapper script around cscope, as you did before for EDITOR. The script contains just this line: /usr/local/bin/cscope $@ | sed s@/mnt/@/scratch/@ Change your .vimrc to set cscopeprg to the name of this script. HTH, Gary -- Gary Johnson | Agilent Technologies [EMAIL PROTECTED] | Mobile Broadband Division | Spokane, Washington, USA
Re: Vim version 7.1a BETA has been released
On 2007-05-05, Bram Moolenaar [EMAIL PROTECTED] wrote: Announcing: Vim (Vi IMproved) version 7.1a BETA This is a BETA release of Vim 7.1. It consists of Vim 7.0 plus all patches and updated runtime files. I expect this to be stable, since the patches have been used by many people already. This BETA is mainly to check that the files has been setup properly. It's been almost a year since the last one! Please report every problem you find! It will only be a few days until the 7.1 release, so please take a little time right now to check it out. I noticed that filetype.vim does not include the patch that I submitted to this list 2006-07-25 to fix the recognition of mutt temporary files on SunOS. Is there something else I can do to have this patch accepted? Regards, Gary -- Gary Johnson | Agilent Technologies [EMAIL PROTECTED] | Mobile Broadband Division | Spokane, Washington, USA
Re: how to enable mouse in vim of cygwin
On 2007-05-04, Albie Janse van Rensburg [EMAIL PROTECTED] wrote: A.J.Mechelynck wrote: sun wrote: I'm using cygwin and rxvt. It works quite well, since you don't need to start an X server for the application - it just runs. Put the following in your cygwin launcher (cygwin_rxvt.bat for me): @echo off C: chdir C:\cygwin\bin set SHELL=/bin/bash rxvt -ls -sr -sl 1500 -fn Lucida ConsoleP-12 -bg black -fg grey and in your .bashrc: export TERM=rxvt-cygwin-native your mouse should work fine with rxvt (mine does!) Cheers Now I can use mouse to jump from one split window to another under rxvx, but how to resize one? I can't do it by mouse in my case, can you? You should be able to drag the status lines and vertical dividers to resize the split windows. I can confirm that this seems to not work, using the cygwin Vim version when run in rxvt. Tab-switching and window selection does work, however. First, thank you to Yakov for the set mouse=a suggestion. I've had that in my Unix .vimrc for so long and didn't need in it in my Windows _vimrc for gvim that I forgot about needing it when the mouse didn't work in my Cygwin vim. That fixed the problem completely for the case where I run an xterm on a Linux machine, ssh to my Windows machine, and run Cygwin vim on that Windows machine through that xterm. However, as Sun and Albie have reported, it doesn't fix the whole problem when running Cywin vim in a non-X rxvt running on the Windows machine: I can split a window and select the active window with the mouse, but I still cannot drag the status line. Regards, Gary -- Gary Johnson | Agilent Technologies [EMAIL PROTECTED] | Mobile Broadband Division | Spokane, Washington, USA
Re: moving virual rectange about in virtualedit mode
On 2007-05-02, Charles E Campbell Jr [EMAIL PROTECTED] wrote: Yakov Lerner wrote: I 'set ve=all' and selected a rectangle with Ctrl-V. How can I move this rectangle up/down left/right with arrows ? With DrawIt v8d, you can move a selected rectangle about with your mouse. Here's the relevant portion of the help for DrawIt: ctrl-leftmouse One may drag and move a selection with ctrl-leftmouse. First, select the region using the leftmouse. Release the mouse button, then press ctrl and the leftmouse button; while continuing to press the button, move the mouse. The selected block of text will then move along with the cursor. Unfortunately, this works only for gvim, not vim. ctrl-leftmouse in an xterm opens the Main Options menu. Here's how to get install DrawIt (when 7.1 comes out, this will become lots easier - just steps 34) 3) Get DrawIt: http://vim.sourceforge.net/scripts/script.php?script_id=40 http://mysite.verizon.net/astronaut/vim/index.html#DRAWIT 4) Install an up-to-date version of Drawit: vim DrawIt.vba.gz :so % :q One may need to uninstall (i.e., delete) any earlier version of DrawIt, too, specifically the file ~/.vim/plugin/DrawIt.vim. The symptoms of needing to do this include vim complaining at startup that \di has been defined twice. I use the line-drawing capability of DrawIt all the time. I haven't done much with the visual-block commands, so I thought I'd try one. I think I found a bug in the version of DrawIt from the astronaut site. I inserted the following two paragraphs of text into a buffer, started DrawIt by typing \di, left-clicked the mouse on the character in the upper left corner of the region (the 'e' in everywhere, no longer visible below), dragged the visual selection to the lower right corner, and typed \b to draw a box. Mary had a little lamb, Its fleece was white as snow, And +--+ went, The |amb was sure to go| || It f|llowed her to scho|l one day, Whic+--+le, And made the children laugh and play To see a lamb at school. Note that the two bars between the paragraphs are in columns 1 and 2 instead of 8 and 27. Regards, Gary -- Gary Johnson | Agilent Technologies [EMAIL PROTECTED] | Mobile Broadband Division | Spokane, Washington, USA
Re: [PATCH] new ex command :lscscope
On 2007-04-26, Navdeep Parhar [EMAIL PROTECTED] wrote: Hello, Currently :cscope has a variant :lcscope that allows the use of the location list instead of the quickfix list. However, :scscope has no equivalent that uses the location list. Please note that :scs splits only if cscope returns some results, so :scs is not the same as :split cs. Due to this reason :split lcscope can not be used to get the same behaviour as the proposed :lscscope. I was looking for a way to open the results of a cscope query in a new tab, and use the location list at the same time. That's when I realized the need for :lscsope. :tab lsc ... does what I need. Here is a patch to add :lscscope to vim. I have tested it on Solaris and Linux and it works for me. Feedback is welcome. Wonderful! Thank you. I have applied it to vim on SunOS 5.8 and am testing it now. The lack of this feature has kept me from using location lists until now, so I'm not sure yet how this _should_ work. I'll also have to remember to use the location-list form of several commands. I use a combination of tags, :grep and :scscope find to search the code I'm working on. I often find myself in the process of traversing one quickfix list when I'd like to follow some other quickfix list in another window, but be able to easily come back to the original quickfix list just by changing to the original window. I'll let you know how this works out. Regards, Gary -- Gary Johnson | Agilent Technologies [EMAIL PROTECTED] | Mobile Broadband Division | Spokane, Washington, USA
Re: [PATCH] new ex command :lscscope
On 2007-04-27, Gary Johnson [EMAIL PROTECTED] wrote: On 2007-04-26, Navdeep Parhar [EMAIL PROTECTED] wrote: Hello, Currently :cscope has a variant :lcscope that allows the use of the location list instead of the quickfix list. However, :scscope has no equivalent that uses the location list. Please note that :scs splits only if cscope returns some results, so :scs is not the same as :split cs. Due to this reason :split lcscope can not be used to get the same behaviour as the proposed :lscscope. I was looking for a way to open the results of a cscope query in a new tab, and use the location list at the same time. That's when I realized the need for :lscsope. :tab lsc ... does what I need. Here is a patch to add :lscscope to vim. I have tested it on Solaris and Linux and it works for me. Feedback is welcome. Wonderful! Thank you. I have applied it to vim on SunOS 5.8 and am testing it now. The lack of this feature has kept me from using location lists until now, so I'm not sure yet how this _should_ work. I'll also have to remember to use the location-list form of several commands. I use a combination of tags, :grep and :scscope find to search the code I'm working on. I often find myself in the process of traversing one quickfix list when I'd like to follow some other quickfix list in another window, but be able to easily come back to the original quickfix list just by changing to the original window. I'll let you know how this works out. I'm confused. I tried exercising this patch and I'm not getting the results I expect, but I don't know if it's the patch, the behavior of location lists, or me. Here's an example. I cd'd to the src directory of my vim installation which is currently at patch level 208. Then I built a cscope database. $ cscope -b Then I opened one of the source files, $ view +3725 buffer.c added the cscope database, :cs add cscope.out moved the cursor to the get_fileformat symbol and opened a new window containing a location list of the places where that function is called. :lscscope find c ^R^W (1 of 10): build_stl_str_hl else if (num == CAR get_fileformat(wp-w_buffer) == EOL_MAC) That happens to be the same line in buffer.c that the cursor had been on. Then I went to the third location in the list, :3ll (3 of 10): readfile fileformat = get_fileformat(curbuf); which is line 925 of fileio.c. I moved the cursor to the top of this function, readfile (line 209), and opened a new window containing a location list of the places where this function is called. :lscscope find c ^R^W (1 of 12): open_buffer retval = readfile(curbuf-b_ffname, curbuf-b_fname, This window contains buffer.c, which is also being viewed in the bottom window. The location list is new. We can check the location list stack state as follows: :lold error list 1 of 2; 10 errors :lnew error list 2 of 2; 12 errors Then I went to the 5th location in this list. :5ll (5 of 12): do_filter if (readfile(otmp, NULL, line2, (linenr_T)0, (linenr_T)MAXLNUM, This is line 1209 of ex_cmds.c. At this point, I wanted to stop following this location list, close this window and return to the place where I executed the :lscscope command, then pick up where I was in the first location list. :q This closed the top window and made the second window active with the cursor on the first line of the readline() function. So far so good. When I left this window, I had been at location 3 of 10 in the first location list. Therefore, I expected that executing :ll would put the cursor back on line 925 of this file, fileio.c. :ll (1 of 12): open_buffer retval = readfile(curbuf-b_ffname, curbuf-b_fname, Not only did the :ll command use the wrong (i.e., unexpected) location list, but it jumped to the first location in that list instead of the last location used, which was number 5. Checking the location list stack state, :lold error list 1 of 2; 10 errors :lnew error list 2 of 2; 12 errors shows that there are still two location lists. I would have expected that closing that top window would have deleted the newest list. So is this a bug, or am I just not getting it? $ vim --version VIM - Vi IMproved 7.0 (2006 May 7, compiled Apr 27 2007 14:19:23) Included patches: 1-208 Compiled by [EMAIL PROTECTED] Normal version with GTK GUI. Features included (+) or not (-): -arabic +autocmd +balloon_eval +browse +builtin_terms +byte_offset +cindent +clientserver +clipboard +cmdline_compl +cmdline_hist +cmdline_info +comments +cryptv +cscope +cursorshape +dialog_con_gui +diff +digraphs +dnd -ebcdic -emacs_tags +eval +ex_extra +extra_search -farsi +file_in_path +find_in_path +folding -footer +fork() -gettext -hangul_input -iconv +insert_expand +jumplist -keymap -langmap +libcall +linebreak +lispindent +listcmds +localmap +menu +mksession
Re: divvying up split windows
On 2007-04-25, Lev Lvovsky [EMAIL PROTECTED] wrote: Is there a way for vim to resize windows automatically after a terminal has been resized (or reattached from a different computer as in the case of 'screen')? It depends on how you want them resized. The following will make all the windows the same size after a resize of the terminal. au VimResized * wincmd = See :help VimResized :help autocommand :help wincmd :help window-resize HTH, Gary -- Gary Johnson | Agilent Technologies [EMAIL PROTECTED] | Mobile Broadband Division | Spokane, Washington, USA
Re: [OT] Toolbars in Windows
On 2007-04-22, Suresh Govindachar [EMAIL PROTECTED] wrote: In the thread titled VimWin, Gary Johnson recently wrote: [snip] Plus, KDE allows me to put menus of often-used programs in the task bar. The Windows Quick Launch menu is similar, but there's only one of them so it quickly becomes cluttered and no longer quick to access. Right-click on any (even if tiny) blank spot in the Main Windows Toolbar (the thing that has the Start button). Then pick Toolbars - New Toolbar. In the pop-up, pick any directory, say the desktop directory. A new button appears on the Main Windows Toolbar. This button can be dragged onto the desktop -- do so to see what happens. Then drag this button to one of the edges (say the top edge) of the desktop -- see what happens. Right click on this and again pick Toolbars - New Toolbar. This will allow you to add any directory to this toolbar. Also try right click and Toolbars - Address. Etc. http://www.windowsitpro.com/Windows/Article/ArticleID/42524/42524.html That's exactly what I wanted! Thank you for the tip and for the tutorial. I had turned on and off the pre-defined toolbars before but had never investigated New Toolbar Regards, Gary -- Gary Johnson | Agilent Technologies [EMAIL PROTECTED] | Mobile Broadband Division | Spokane, Washington, USA
Re: What plugin is the one that does the following ...
On 2007-04-23, Andrew Falanga [EMAIL PROTECTED] wrote: On 4/23/07, Taylor Venable [EMAIL PROTECTED] wrote: Do you mean the ability to edit a directory and read its contents? yes The documentation says that it's distributed with vim. However, I installed vim using the FreeBSD ports system on my FreeBSD system and this pluglin, apparently, isn't installed along with the rest of vim. That's odd. The FreeBSD ports build method for Vim is simply to download the patches, apply them, and do a standard build. To my knowledge, nothing is removed. One possibility I can think of: did you build a LITE version? (Using `make -DLITE install` for example.) What leads you to believe that this functionality isn't present? Do you get some sort of error messages when you try to do something? Every time I do something like, gvim . or vim ., when vim loads on the bottom of the screen I get . is a directory and there's nothing in the window to actually edit. I did do some searching on the install I did. I did not do a -lite version in the ports tree. I did my install from /usr/ports/editors/vim (there's a .../vim-lite in the same directory of editors). I also found the netrw plugin referenced by Chip to exist in /usr/local/share/vim/vim70/plugin. According to what I've been able to determine, this should be sourced by vim when vim is executed. However, try as I have to remember, I do not recall the command to list the files vim sourced on startup. Can you provide that for me? :scriptnames Make sure you have a _current_ version of the netrw plugin and that you have installed it according to Dr. Chip's instructions (earlier in this thread). Depending on the versions of the runtime files you originally installed, it may not be sufficient to download and install netrw.vba--you may also have to disable the current netrw files under the $VIMRUNTIME directory. I install vim on a variety of different machines and every now and then I forget to properly update netrw. When I do, the symptoms are as you describe. Regards, Gary -- Gary Johnson | Agilent Technologies [EMAIL PROTECTED] | Mobile Broadband Division | Spokane, Washington, USA
Re: Multiple commands.
On 2007-04-22, John R. Culleton [EMAIL PROTECTED] wrote: I want to activate a whole string of substitute commands by a single F key, perhaps 6 or 8. Can I call a script from an F key? How? Alternatively, can I string them together in a line or multiple lines in gvimrc? How? I asked this question earlier but it never appeared on the list. Yes it did. It appeared on the 19th and I answered it on the 19th. Regards, Gary -- Gary Johnson | Agilent Technologies [EMAIL PROTECTED] | Mobile Broadband Division | Spokane, Washington, USA
Re: how to enable mouse in vim of cygwin
On 2007-04-23, sun [EMAIL PROTECTED] wrote: If it's a Cygwin build, you may need to make sure that Cygwin can get mouse actions (which may need running the gpm daemon, or something) and that Vim has the corresponding feature (such as +mouse_gpm or +mouse_xterm) compiled-in. Best regards, Tony. hi, but how do I know whether my Cygwin support the mouse or how to make it support. You can find out either by executing :version within vim or by executing vim --version at the bash prompt. My Cygwin vim :version report includes the following: +mouse -mouseshape +mouse_dec -mouse_gpm -mouse_jsbterm +mouse_netterm +mouse_xterm and the mouse doesn't work for me, either, in neither rxvt locally nor in xterm over an ssh connection. Unfortunately, I don't have the time to investigate it further at the moment. The :version command reports features that are enabled or disabled at compile time. The only way to enable or disable any of these features is to recompile vim. To find out more about any of those features, execute :help followed by the + version of the feature name, e.g., :help +mouse HTH, Gary -- Gary Johnson | Agilent Technologies [EMAIL PROTECTED] | Mobile Broadband Division | Spokane, Washington, USA
Re: Lost in Space -- extended approach
On 2007-04-24, [EMAIL PROTECTED] wrote: Hi, A similiar problem I had was solved previously. Now I got stuck in the advanced version of this. Suppose I have the following text (:set list) : ljdh $ laskjdl $ sdj $ aslkdjldjlad$ a $ askdj $ askdjlsd $ aks $ lkasjdsdjjadl $ and I want this with less plugins, keystrokes, function definitions etc as possible ljdh = spacequest( vim, text );$ laskjdl= spacequest( vim, text );$ sdj= spacequest( vim, text );$ aslkdjldjlad = spacequest( vim, text );$ a = spacequest( vim, text );$ askdj = spacequest( vim, text );$ askdjlsd = spacequest( vim, text );$ aks= spacequest( vim, text );$ lkasjdsdjjadl = spacequest( vim, text );$ I (with set ve=all or set ve=block) to marked a column with a visual block and tried r (which works only for one character to be inserted) and R (which kills ALL my text). How can I solve this problem ? This particular case of all the added text being the same is pretty easy to solve. Start the way you did before, by typing Ctrl-V and highlighting a column. Then instead of typing 'r' to replace a single character, type 's' to substitute the selected text with an arbitrarily-long string and follow the 's' with = spacequest( vim, text ); and finish by typing Esc. See :help visual-operators for more operations you can perform on visually-selected areas. Regards, Gary -- Gary Johnson | Agilent Technologies [EMAIL PROTECTED] | Mobile Broadband Division | Spokane, Washington, USA
Re: Problem with spaces in the makeprg command
On 2007-04-21, Chris Sutcliffe [EMAIL PROTECTED] wrote: Hey All, I'm having an issue with spaces in the makeprg command. When setting it to: :setlocal mp=C:\Program\ Files\NSIS\makensis.exe I get an error: shell returned 1 (1 of 2): 'C:\Program' is not recognized as an internal or external command Can someone please let me know how I go about getting this to work? Here's one way to quote/escape it: :setlocal mp=\C:\\Program\ Files\\NSIS\\makensis.exe\ The command name seen by cmd.exe needs to look like this: C:\Program Files\NSIS\makensis.exe Windows doesn't recognize the backslash as an escape character, so the only way that I know of to execute a command containing a space in its path name is to enclose the path name in double quotes. You can't quote the rhs of a set or setlocal command--you can only backslash-escape problematic characters such as backslashes, spaces and double quotes. Hence the backslashes in the solution above. HTH, Gary -- Gary Johnson | Agilent Technologies [EMAIL PROTECTED] | Mobile Broadband Division | Spokane, Washington, USA
Re: VimWin
On 2007-04-21, Dimitar [EMAIL PROTECTED] wrote: I have nothing against Linux at all.(I'm using it as my standard operating system). But I must admit that Windows and MacOS are far ahead from Linux in the graphics area. The X server is somehow not worthy to compare with the graphic environments of the other two. OpenOffice is usable and has a lot of futures but it just looks bad. Free Software is in the most cases not as good as proprietary, especially when the X server is involved. I don't know what you meant by graphics area, but the usability of an X window manager such as KDE on Linux far exceeds that of Windows XP. Things you can do on Linux that you can't do on Windows include - setting the focus policy to focus follows mouse instead of click to focus, - setting the focus/raise policy so that you can change the keyboard focus to a window without raising it, - lowering a window by clicking on the title bar, and - moving a maximized window. Plus, KDE allows me to put menus of often-used programs in the task bar. The Windows Quick Launch menu is similar, but there's only one of them so it quickly becomes cluttered and no longer quick to access. I use both Linux and Windows machines at work with one keyboard, mouse and dual-monitor display. Windows is OK for some things, but using it extensively drives me batty. Especially when working with several programs running in various windows, KDE is much easier to use. Regards, Gary -- Gary Johnson | Agilent Technologies [EMAIL PROTECTED] | Mobile Broadband Division | Spokane, Washington, USA
Re: Lost in Space
On 2007-04-22, [EMAIL PROTECTED] wrote: Hi, Suppose I have a text like this (:set list) Hello $ this $ is$ a $ text with $ spaces $ and want it to become this one: Hello = this = is = a = text with = spaces = . I tried different cpoptions combined with blcok-seelcting in visual mode, but I failed and ended up adding spaces by hand in each line, which isn't efficent that much ;) I set virtualedit=block. What do I have to tell vim that it will recognize missing spaces and add it according to a block select? What I would do is this: - set ve=all (ve=block may work, but the only two 've' settings I ever use are and all.) - Move the cursor to the first line and the column where you want your =s. - Type Ctrl-V - Type j enough times to highlight the column down to the last line. - Type r= You might also look at Dr. Chip's Align plugin for such tasks as aligning all the =s in a block of assignments to the same column. HTH, Gary -- Gary Johnson | Agilent Technologies [EMAIL PROTECTED] | Mobile Broadband Division | Spokane, Washington, USA
Re: current file name to apped to an ex command
On 2007-04-20, darkwalk [EMAIL PROTECTED] wrote: Hi: I am trying to send a command to shell that invoke cleartools to checkout/in files that I am currently working on. unfortunatly, I am pretty new to vim and I've tried searching throught the man pages, but I cant' seem to figure out how to do so. Any help would be appreciated. Thanks! If you're using ClearCase, I'd recommend Doug Potts's ccase.vim script, http://vim.sourceforge.net/scripts/script.php?script_id=15 HTH, Gary -- Gary Johnson | Agilent Technologies [EMAIL PROTECTED] | Mobile Broadband Division | Spokane, Washington, USA
Re: wish: collaboration of N vim instances editing same file
On 2007-04-11, Yakov Lerner [EMAIL PROTECTED] wrote: Hello Bram, Is it possible to add this item to the vim voting list ?: collaboration of N vim instances editing same file -- Ability of N instances of vim to absorb, merge and show changes to the same file made by other running vim instances [ either by reading other vim's swapfiles, or somehow else ] ? Can this be added to SOC ? If you want this collaboration to occur in real time, then I would recommend that you use a screen session in multi-user mode. This solution already exists; it works with applications other than vim; it avoids complicating the vim code. See the screen(1) man page and search for multi. HTH, Gary -- Gary Johnson | Agilent Technologies [EMAIL PROTECTED] | Mobile Broadband Division | Spokane, Washington, USA
Re: Multiple commands from Fkey
On 2007-04-19, John R. Culleton [EMAIL PROTECTED] wrote: I want a single F key assignment via user's gvimrc to activate several commands in order, e.g.: %s/^/``/ %s/ / ``/g %s/$/''/ %s/ /'' /g (The left hand part contains an inch sign and the right hand part contains either two back ticks or two apostrophes.) I may add more such commands to the same F key. Can I string them all together in a gvimrc command or would it be handier to have the F key call a script somehow? This will be for a naive user. (I am pretty naive myself :) You can certainly string them together in a single mapping using bar as a separator and CR as a terminator, e.g., nmap F2 :%s/^/``/ bar %s/ / ``/g bar %s/$/''/ bar %s/ /'' /gCR However, that mapping will fail as soon as one of the substitutions fails, so a better mapping would include the 'e' flag at the end of each substitution, e.g., nmap F2 :%s/^/``/e bar %s/ / ``/ge bar %s/$/''/e bar %s/ /'' /geCR That mapping will leave the command visible in the command line after the user presses the function key, and if the command is long or the window is narrow, the user will also get the Press ENTER or type a command to continue prompt when the command is done. To avoid that, you can add silent to the mapping, e.g., nmap silent F2 :%s/^/``/e bar %s/ / ``/ge bar %s/$/''/e bar %s/ /'' /geCR Such a long mapping can be difficult to maintain. One way to make that easier is to put the commands in a function and have the mapping just call that function, e.g., nmap silent F2 :call DoSub()CR function DoSub() %s/^/``/e %s/ / ``/ge %s/$/''/e %s/ /'' /ge endfunction See also :help :bar :help map_bar :help :s_flags :help map-silent :help user-functions HTH, Gary -- Gary Johnson | Agilent Technologies [EMAIL PROTECTED] | Mobile Broadband Division | Spokane, Washington, USA
Re: Cscope find: help
On 2007-04-17, Ashwin Bharambe [EMAIL PROTECTED] wrote: Hi, I would like to filter the results that cscope find sends using some pipe. For example, here's what I would like to do :cs find e word | grep -w word This way I can easily add in some things which cscope find doesn't do, sadly. What would be the best way to achieve this? Changing vim code? Or writing vim functions? Sorry, I am new to hacking vim, but I have a lot of experience using vim... I'm in a little bit of a hurry, so this will be short on details. You can run cscope like grep, executing it once for each search instead of having it run in the background as it does when you use the :cs commands. Using it that way, you can set 'grepprg' to a pipeline something like this: cscope arguments $* | grep $* and just invoke it within vim as: :grep word See :help grepprg I did something like this for a while to get the output of certain cscope commands into the quickfix list before the 'cscopequickfix' option was added to vim. On the machine I was using, I didn't even notice any performance degradation over the equivalent search using :cs find. HTH, Gary -- Gary Johnson | Agilent Technologies [EMAIL PROTECTED] | Mobile Broadband Division | Spokane, Washington, USA
Re: how to avoid deleting the auto-indent in a new empty line when i press Esc
On 2007-04-16, sun [EMAIL PROTECTED] wrote: The idea of the comment shown above was to leave something to remind you that you had to come back later, since, as you said, you want to leave the indent there for future use; also, the comment would be sure to stay in place even if the bare indent didn't. But if just adding, let's say, a period, then backspacing over it, makes the indent remain, then you don't have to type a lengthy comment unless you need it. You may even try (untested) :inoremap CRCR.BS Note: Next time, please use Reply to all rather than Reply to sender, unless you're straying off-topic. Best regards, Tony. Do I need always type a char then BS? Is there a better solution? I wander whether the vim option can do this automatically. A better solution to what problem? If vim automatically indents properly when you add a new line, what difference does it make whether it leaves leading spaces in that line you left or not? If you want to leave a blank line and add properly indented text to it later, you can resume editing that line by typing S which should automatically move your cursor to the proper indentation. Regards, Gary -- Gary Johnson | Agilent Technologies [EMAIL PROTECTED] | Mobile Broadband Division | Spokane, Washington, USA
Re: let loaded_matchparen = 1
On 2007-04-15, fREW [EMAIL PROTECTED] wrote: On 4/13/07, A.J.Mechelynck [EMAIL PROTECTED] wrote: Andre Majorel wrote: Are there any plans to make the highlight-the-matching-thing feature disabled by default in a future release of Vim ? AFAIK, there isn't; for one thing, it would break all the vimrc's which rely on its being set by default (and therefore don't force-set it). As your Subject line shows, you know how to remove that feature. Personally I like this feature, but I do get lost every now and then and forget which one is my cursor. Is there any way that I can say, make the cursor have a red background and make the matched paren (or whatever) have a blue background? And is there a way to do this that won't break if the background is already red/blue? I had this same problem, so I added this line to my color scheme. It may be sufficient to just put something like this in your .vimrc. highlight MatchParen ctermbg=4 HTH, Gary -- Gary Johnson | Agilent Technologies [EMAIL PROTECTED] | Mobile Broadband Division | Spokane, Washington, USA
Re: hilight blocks
On 2007-04-12, Kirk [EMAIL PROTECTED] wrote:
Is there any simple way to have custom blocks of code highlighted and the
remaining code outside the blocks not highlighted?
For example:
# file.txt
some plain text
[my-custom-tag] some custom text [/my-custom-tag]
Some more plain text
...
# end of file
So the idea would be to open VIM using file.txt and the code inside the
custom tags would be highlighted.
How about this?
match Todo '\[my-custom-tag]\zs\_.\{-}\ze\[/my-custom-tag]'
where you can certainly choose some highlight group other than Todo.
You can put that line just as it is into your .vimrc, or put it in
an after/ftplugin/txt.vim file, or create an autocommand to invoke
it on just the files you want.
HTH,
Gary
--
Gary Johnson | Agilent Technologies
[EMAIL PROTECTED] | Mobile Broadband Division
| Spokane, Washington, USA
Re: hilight blocks
On 2007-04-12, Kirk [EMAIL PROTECTED] wrote:
-Original Message-
From: Gary Johnson [mailto:[EMAIL PROTECTED]
Sent: Thursday, April 12, 2007 12:05 PM
To: [EMAIL PROTECTED]
Subject: Re: hilight blocks
On 2007-04-12, Kirk [EMAIL PROTECTED] wrote:
Is there any simple way to have custom blocks of code highlighted and
the
remaining code outside the blocks not highlighted?
For example:
# file.txt
some plain text
[my-custom-tag] some custom text [/my-custom-tag]
Some more plain text
...
# end of file
So the idea would be to open VIM using file.txt and the code inside the
custom tags would be highlighted.
How about this?
match Todo '\[my-custom-tag]\zs\_.\{-}\ze\[/my-custom-tag]'
where you can certainly choose some highlight group other than Todo.
You can put that line just as it is into your .vimrc, or put it in
an after/ftplugin/txt.vim file, or create an autocommand to invoke
it on just the files you want.
HTH,
Gary
I like this one, I put it in my local ~/.vimrc file and it works
for VIM (v6.1.3). But when I load this on another machine running
VIM (v6.3) I get this error:
bash-2.05$ vi file
Error detected while processing /export/home/me/file:
line6:
E28: No such highlight group name: Comment '\[perl]\zs\_.\{-}\ze\[/perl]'
Hit ENTER or type command to continue
What am I missing?
Contents of .vimrc:
:set number
:set hlsearch
:set incsearch
:set ignorecase
:set shiftwidth=3
match Comment '\[perl]\zs\_.\{-}\ze\[/perl]'
I don't know. :help hicolors and :help group-name in vim 7.0
both include the Comment group. The Comment group is used in so
many examples in the vim help files and comments are such common
aspects of programming languages that I would think that that group
has existed since vim first had highlight groups.
I see that if I start vim as 'vim -u NONE' and execute
:verbose hi Comment
I get the error message
E411: highlight group not found: Comment
but if I then execute
:syn manual
:verbose hi Comment
I get the response
Commentxxx term=bold ctermfg=4 guifg=Blue
Last set from
~/src/Linux/vim-7.0/share/vim/vim70/syntax/syncolor.vim
So from that I conclude that you have to execute a :syn command of
some sort in some initialization file before before referring to any
of the highlight groups in your .vimrc. I'll bet the machine
running vim 6.1.3 has an initialization file that includes :syn on
and the machine running vim 6.3 does not.
This is probably discussed in the vim manual someplace, but I didn't
go looking for it.
HTH,
Gary
--
Gary Johnson | Agilent Technologies
[EMAIL PROTECTED] | Mobile Broadband Division
| Spokane, Washington, USA
Re: replace word from buffer
On 2007-04-06, [EMAIL PROTECTED] wrote: Hi, is there a way to do this more effectively? I often get in the situation of yanking a word into the buffer, search another word I want to replace with the contents of the buffer, delete the found word and paste the contents of the buffer at the place of the previously found word. Despite the fact, that -- without the yank-ring script -- you have to keep an eye on what is in what buffer, it would be more effective if one could do the following: ywyank replacement word /word find word (word) to be replaced cwchange word under cursor with that in buffer I know, that cw is another command, which is wrong in this case...I only needed a name for what I want to do and cw keeps track of the length of the replaced word and the replacement. Thank you very much for any helpful hint :) ! Actually, cw isn't wrong, it's just incomplete. Yanked but not deleted text goes automatically into the 0 (zero, not oh) register unless you specified some other register. So yw yanks the replacement word into both the unnamed register and register 0. Then all you have to do is specify register 0 as the source of the replacement text when you type cw by following cw with ^R0 where by ^R I means Ctrl-R. You can read more about these registers under :help registers sections 1. and 2., and about using Ctrl-R under :help i_CTRL-R HTH, Gary -- Gary Johnson | Agilent Technologies [EMAIL PROTECTED] | Mobile Broadband Division | Spokane, Washington, USA
Re: using command gf or map to other key for matlab function
On 2007-04-04, frank wang [EMAIL PROTECTED] wrote: Hi, I am a lot of matlab function files. the function name is the same as file name without the file extension .m. In the Vim, if I use command gf trying to find the file under the cursor, it could not find it since it missed the extension .m. Could someone help me to create a map to solve this problem? You don't even need a map to solve this one. Just put this setting in your .vimrc or _vimrc: set suffixesadd+=.m See :help suffixesadd Regards, Gary -- Gary Johnson | Agilent Technologies [EMAIL PROTECTED] | Mobile Broadband Division | Spokane, Washington, USA
Re: How can I pass the full path of the current buffer to a command line script?
On 2007-03-30, ben lieb [EMAIL PROTECTED] wrote: I want to send the full path of the current buffer to a command line script like this: :!command thisFile What symbol do I use to represent thisFile, meaning the current buffer? This seems like an easy one, but I can't figure it out. :!command %:p See :help :_% :help filename-modifiers Gary -- Gary Johnson | Agilent Technologies [EMAIL PROTECTED] | Mobile Broadband Division | Spokane, Washington, USA
Re: gVim and Cygwin
On 2007-03-30, Charles E Campbell Jr [EMAIL PROTECTED] wrote: Waters, Bill wrote: Does anyone have experience with running gVim and using Cygwin commands (ex. indent)? I would prefer not to run vim in a Cygwin terminal, unless someone has all of the configurations needed (syntax highlighting, etc) to have that act like gVim. I generally compile both gvim and vim under cygwin, and haven't run into any problems. I haven't used indent, though. The problems I generally have had have been with Windows' paths and trying to get netrw to understand them properly, but that's not because of gvim and cygwin. If you already have cygwin, just get vim 7.0 source, and go to its source directory. gmake -f Make_cyg.mak will make gvim.exe by default. Edit Make_cyg.mak, and change GUI=yes to GUI=no, and type the same command above. That way you'll get vim.exe. Its really quite straightforward! To build a console vim that used color, I had to also install the Cygwin libncurses-devel package. HTH, Gary -- Gary Johnson | Agilent Technologies [EMAIL PROTECTED] | Mobile Broadband Division | Spokane, Washington, USA
Re: gVim and Cygwin
On 2007-03-30, David Fishburn [EMAIL PROTECTED] wrote:
-Original Message-
From: A.J.Mechelynck [mailto:[EMAIL PROTECTED]
Sent: Friday, March 30, 2007 6:42 PM
To compile a Unix-like Vim for Cygwin you must use the
top-level Makefile or the src/Makefile which will invoke a
configure step. If configure finds the necessary headers and
libraries it may compile a GUI version of Vim, which will
need Cygwin to run, and X11 to display a GUI.
Hmm, based on your response and Gary's (libncurses-devel) and this post:
http://www.cygwin.com/ml/cygwin/2003-06/msg00886.html
I ran the following:
cd /c/OpenSrc/vim7/src
./configure \
--prefix=/usr \
--sysconfdir=/etc \
--libexecdir='$(sbindir)' \
--localstatedir=/var \
--datadir='$(prefix)/share' \
--enable-multibyte \
--without-x \
--enable-gui=no
This results in:
./configure: line 3: $'\r': command not found
auto/configure: line 11: $'\r': command not found
auto/configure: line 19: syntax error near unexpected token `elif'
auto/configure: line 19: `elif test -n ${BASH_VERSION+set} (set -o
posix) 'dev/null 21; then
./configure: line 6: $'\r': command not found
./configure: line 11: syntax error: unexpected end of file
I have never tried this before, I am wondering if it is related to dos line
endings?
I pulled the source from a win32 SVN client. It is the same directory I
compile for win32 from.
Any suggestions?
I haven't had this problem myself, but from what I've seen posted to
the cygwin list, this looks like a line-ending problem. You can be
pretty sure it didn't come from any file installed with setup.exe
unless you edited some file with WordPad, for example, that changes
LF endings to CR-LF.
Something else that can mess you up is using WinZip to unzip a
package. While the option can be changed, WizZip's default behavior
is to change all text file line endings to CR-LF.
The 'file' command will show you the type of line endings that each
file has, and 'd2u' will convert CR-LF endings to LF.
Regards,
Gary
--
Gary Johnson | Agilent Technologies
[EMAIL PROTECTED] | Mobile Broadband Division
| Spokane, Washington, USA
Re: Vim Help for deleting alternate lines in text
On 2007-03-31, Auro Ashish Saha [EMAIL PROTECTED] wrote:
Hello Antoine,
Thanks for your post. I tried both the options but i could not get any
result. I am using gvim. Please help.
Regards,
Auro Ashish Saha.
Auro Ashish Saha wrote:
Hello,
Please help me to remove alternate lines from a text file.
00 0
123456 9
99 9
123445 9
I want to delete the line 1, 3, 5 and so on. What are the commands to be
used. Thanks for help in advance.
Regards,
Auro Ashish Saha.
Method I:
qddjjq
count@
where count is equal to the number of lines still to be deleted
One problem with this is that it attempts to store a sequence of
normal-mode commands into the register, which is the unnamed
register, but then deletes the first line into this same register.
The other problem with it is that it moves the cursor too many
times: once the first line has been deleted with dd, the cursor
automatically moves to the next line, so only one j is needed to get
to the next line to be deleted.
This version will work:
qqddjq
count@q
Note that it uses the q register instead of the register. Also,
if you don't want to try to figure out what count should be, and
if you don't want to remove a huge number of lines, you can execute
the recorded commands the first time after you record them with this
command:
@q
and every subsequent time with this command:
@@
That way, once you've recorded the command and executed it once from
the q register, you can just hold your finger on the @ key and watch
the lines disappear. As you get close to the bottom of your file,
you can start slowing down and typing just two @'s at a time.
Method II (all on one line if typed on the Vim command-line):
:let i=1 | while i = line('$') | if (i % 2) | exe i . delete |
endif |
endwhile
It looks as though Tony left out part of Method II: i is never
incremented. I modified it as shown below (added let i += 1 |)and
verified that it works.
:let i=1 | while i = line('$') | if (i % 2) | exe i . delete | endif |
let i += 1 | endwhile
HTH,
Gary
--
Gary Johnson | Agilent Technologies
[EMAIL PROTECTED] | Mobile Broadband Division
| Spokane, Washington, USA
Re: search upward of cscope.out file
On 2007-03-29, A.J.Mechelynck [EMAIL PROTECTED] wrote: Sergey Khorev wrote: You need to run a script, e.g. if filereadable(cscope.out) cs add cscope.out endif if filereadable(../cscope.out) cs add ../cscope.out endif etc :) function GetCscopeFileName() let curdir = fnamemodify(getcwd(), ':p') while 1 let f = curdir . (curdir =~ '[\\/]$' ? '' : '/') . 'cscope.out' if filereadable(f) found return f endif try one level up let d = fnamemodify(curdir, ':h') if d == curdir trying to go past top level: not found return '' endif let curdir = d endwhile endfunction let csfn = GetCscopeFileName() if csfn != '' exe 'cs add' csfn endif How about using findfile()? command -nargs=1 CsAdd call CsAdd(args) function CsAdd(file) let path = findfile(a:file, .;) if path != '' exe 'cs add' path else echo a:file not found endif endfunction Usage: :CsAdd cscope.out Regards, Gary -- Gary Johnson | Agilent Technologies [EMAIL PROTECTED] | Mobile Broadband Division | Spokane, Washington, USA
Re: Jump to tag opens VIM in a new Microsoft Windows XP window
On 2007-03-23, Waters, Bill [EMAIL PROTECTED] wrote: When I jump to a tag reference in a different file, can I have VIM open that file in a new Microsoft Window? As it works now, I jump to the new file in the same VIM session. I have three problems with that: 1. VIM will not jump to the tag unless all of the changes in my current file have been saved. You can fix this by making the current buffer hidden before executing the jump. See :help hidden :help bufhidden :help hide 2. When I jump to the new file, I loose the undo buffer for the previous file. Making the buffer hidden will fix that, too. 3. I would prefer to look at the new file in a separate, side-by-side Microsoft Window. In that case, you could map your jump to tag key to a command that would execute gvim -t cword I'll leave that to you to figure out since it may require :!start gvim ... instead of just :!gvim ... and I don't do Windows that much. See :help :! :help :!start :help -t :help map.txt HTH, Gary -- Gary Johnson | Agilent Technologies [EMAIL PROTECTED] | Mobile Broadband Division | Spokane, Washington, USA
Re: How to remove all indenting features on Windows GVIM
On 2007-03-23, Kiernan Holland [EMAIL PROTECTED] wrote: This is the most annoying of the features on GVIM.. I like GVIM because it had syntax highlighting, but my fingers are programmed to handle indenting with just the basic indenting that is standard even on the elder vi implementation. I assume you're running gvim on Windows so I'll assume you have indenting enabled because your _vimrc has source $VIMRUNTIME/vimrc_example.vim at the top, which contains this line: filetype plugin indent on To turn indenting off for all file types, just put this line in your _vimrc below that source line: filetype indent off See :help filetype-indent-off HTH, Gary -- Gary Johnson | Agilent Technologies [EMAIL PROTECTED] | Mobile Broadband Division | Spokane, Washington, USA
Re: highlighting weird characters...
On 2007-03-19, Mitch Wiedemann [EMAIL PROTECTED] wrote: Hi all, I use VIM - Vi IMproved 7.0 (2006 May 7, compiled Feb 23 2007 22:17:23) to write mainly XHTML/PHP and I sometimes have to get content from word processed documents and paste it into Vim for HTML markup. This usually results in having non-visually detectable characters (which I assume are high ASCII) which display strangely on the Web. Is there a way I can have my Vim highlight these characters so I can see them and replace them with their HTML counterparts? I've searched Google, the Vim e-mail archive, and I've helped Ugandan children :), but I'm no closer to the answer. Any hints? One way to do this would be to :set isprint= which will tell vim that only the characters in the range 32 - 126 are printable. Vim will then highlight all the other characters as SpecialKey. You can then search for these non-printable characters with /[^[:print:]] Another, probably better, way would be to simply search for /[^Vx80-^Vxff] where ^V means a literal Ctrl-V. That will search for any character in the range 0x80 - 0xff and will highlight them all with the Search highlight if 'hlsearch' is set. I think this way is better because it preserves vim's rendering of the non-ASCII characters, which may make it easier for you to choose their replacements. HTH, Gary -- Gary Johnson | Agilent Technologies [EMAIL PROTECTED] | Mobile Broadband Division | Spokane, Washington, USA
Re: highlighting weird characters...
On 2007-03-19, Gary Johnson [EMAIL PROTECTED] wrote: On 2007-03-19, Mitch Wiedemann [EMAIL PROTECTED] wrote: Hi all, I use VIM - Vi IMproved 7.0 (2006 May 7, compiled Feb 23 2007 22:17:23) to write mainly XHTML/PHP and I sometimes have to get content from word processed documents and paste it into Vim for HTML markup. This usually results in having non-visually detectable characters (which I assume are high ASCII) which display strangely on the Web. P.S. See :help ga HTH, Gary -- Gary Johnson | Agilent Technologies [EMAIL PROTECTED] | Mobile Broadband Division | Spokane, Washington, USA
Re: how to setup gvim as view source editor for Opera?
On 2007-03-17, zzapper [EMAIL PROTECTED] wrote: Hi, I've forgotten how to setup gvim as view source editor for Opera (got a new Vista PC). Also can anyone recommend the best solution for FireFox, I've only got the one where viewing source with vim is an additional option The Firefox plugin that does this is ViewSourceWith. It works for any Firefox from 1.0 to 2.0.0.*. It includes a setting that makes the selected editor the default for the View Page Source menu item, so you don't need to mess with about:config. It's not just for viewing source, either; it also allows you to use your favorite editor to edit text areas. https://addons.mozilla.org/firefox/394/ I use the same plugin on both my Linux and Windows installations of Firefox. HTH, Gary -- Gary Johnson | Agilent Technologies [EMAIL PROTECTED] | Mobile Broadband Division | Spokane, Washington, USA
Re: Netrw go up dir command
On 2007-03-16, A.J.Mechelynck [EMAIL PROTECTED] wrote: Here is how to avoid modifying system files: Since there is a test at the start of the netrw scripts to avoid double sourcing, you can test them by unvimballing them under $VIM/vimfiles, $HOME/vimfiles or $HOME/.vim, without removing the older files under $VIMRUNTIME (I know the latter is contrary to Dr. Chip's recommendations, but it works). You will just have to watch out and remove the user versions of the scripts if and when the normal Vim upgrade process installs a newer version under $VIMRUNTIME. In my experience, installing the newer netrw files under $VIM/vimfiles or $HOME/.vim does _not_ work unless you also delete the corresponding system netrw files under $VIMRUNTIME. I have installed vim 7.0 on several systems: - HP-UX 10.20 from source; - SunOS 5.8 from source; - Red Hat Linux 9 from source; - Cygwin pre-compiled; - Cygwin from source; - Windows XP pre-compiled from vim.sf.net; - Windows XP pre-compiled from Cream; and in every case, when the new private netrw files were used without deleting the system netrw files, an edit of a directory would fail, showing only an empty buffer. I would have thought that the usual anti-double-sourcing checks would work for netrw, too, but apparently they don't. Regards, Gary -- Gary Johnson | Agilent Technologies [EMAIL PROTECTED] | Mobile Broadband Division | Spokane, Washington, USA
Re: How to show path?
On 2007-03-16, Richard England [EMAIL PROTECTED] wrote: Peng Yu wrote the following on 03/16/2007 01:16 PM: Hi, Can somebody let me know how to show the current value of path? Thanks, Peng Inside or outside of vim? Unix/Linux or Windows? Programatically in vim or just as a command? Try: :!echo $PATH inside vim on the command line on a Unix/Linux machine ?? :echo $PATH See :help expr-env HTH, Gary -- Gary Johnson | Agilent Technologies [EMAIL PROTECTED] | Mobile Broadband Division | Spokane, Washington, USA
Re: How to paste while keep the cursor at the same place?
On 2007-03-13, Peng Yu [EMAIL PROTECTED] wrote: Hi, Suppose I use p to paste something, the cursor always goes to the end of the pasted text. Is there any other key to paste will keep the cursor before the pasted text? See :help `[ You could either type `[ after the p to move the cursor, or you could remap p like this :noremap p p`[ to have it behave that way all the time. HTH, Gary -- Gary Johnson | Agilent Technologies [EMAIL PROTECTED] | Mobile Broadband Division | Spokane, Washington, USA
Re: after compile VIM 7.0, I get error in running it...
On 2007-03-09, lin q [EMAIL PROTECTED] wrote: Hi, I downloaded the vim 7.0 package to my RedHat Enterprise 3 machine. I do not have administrator previlidge, so I setup the env like this: export DESTDIR=my_dir export prefix=my_dir Then I run make make install But when I run vim, my_dir/usr/local/bin/vim, I get this error: Error detected while processing /home/linq/.vimrc: line 10: E484: Can't open file /usr/local/share/vim/syntax/syntax.vim Press ENTER or type command to continue Line 10 of my vimrc is: syntax on I am wondering why it still goes to /usr/local to look for data files. Is there a way I can control this? I've never built vim using environment variables; I always use options to configure. However, from my experience building vim on systems for which I do not have administrator privileges, and from reading the output of ./configure --help, I believe that export prefix=my_dir is incorrect and should instead be export PREFIX=my_dir Also, since you want DESTDIR to be set to the same directory as PREFIX, I think that export DESTDIR=my_dir is unnecessary. So I would suggest executing the following: export PREFIX=my_dir make reconfig make make install Tony Mechelynck has some tips on using this technique to build vim on his web page, http://users.skynet.be/antoine.mechelynck/vim/compunix.htm. For what it's worth, I build it this way: cd vim70 ./configure --prefix=my_dir make make install By the way, in throwing the above error message, VIM starts, but it is not GUI mode even though I have -g in the command, is that because of the above problem? I don't think so. It may be a configuration problem, though. Execute vim --version and verify that you're running the version that you just built (the first line has the compile time and date) and that it contains the features you want, such as graphics. The vim I built on Red Hat Linux 9 has on the third line: Normal version with X11-Motif GUI. HTH, Gary -- Gary Johnson | Agilent Technologies [EMAIL PROTECTED] | Mobile Broadband Division | Spokane, Washington, USA
Re: Using right ctags file depending where Vim is started from - how?
On 2007-03-07, Zarko Coklin [EMAIL PROTECTED] wrote: Hi all! I am trying to automate my Vim setup as much as possible. On my PC I have 2 directories for 2 different releases. C:\Code_Rel1 C:\Code_Rel2 At a very top level in each of these directories I have ctags files. How can I setup Vim so that it sources right ctags file depending from I started Vim. For example, if I go under Code_Rel1 and in Windows use right click to open file in one of subdirectories, ctags should be picked up from C:\Code_Rel1 and not from C:\Code_Rel2. Hard coding path to ctags in .vimrc is not an option, cause it will not work well if I right-click to open file from another release directory. Any thoughts on how this can be achieved? If you don't mind adding a command to your .vimrc for each ctags file, you could do this: au BufRead,BufNewFile C:/Code_Rel1/* set tags=C:/Code_Rel1/tags au BufRead,BufNewFile C:/Code_Rel2/* set tags=C:/Code_Rel2/tags HTH, Gary -- Gary Johnson | Agilent Technologies [EMAIL PROTECTED] | Mobile Broadband Division | Spokane, Washington, USA
Re: Using right ctags file depending where Vim is started from - how?
On 2007-03-07, A.J.Mechelynck [EMAIL PROTECTED] wrote: Gary Johnson wrote: On 2007-03-07, Zarko Coklin [EMAIL PROTECTED] wrote: Hi all! I am trying to automate my Vim setup as much as possible. On my PC I have 2 directories for 2 different releases. C:\Code_Rel1 C:\Code_Rel2 At a very top level in each of these directories I have ctags files. How can I setup Vim so that it sources right ctags file depending from I started Vim. For example, if I go under Code_Rel1 and in Windows use right click to open file in one of subdirectories, ctags should be picked up from C:\Code_Rel1 and not from C:\Code_Rel2. Hard coding path to ctags in .vimrc is not an option, cause it will not work well if I right-click to open file from another release directory. Any thoughts on how this can be achieved? If you don't mind adding a command to your .vimrc for each ctags file, you could do this: au BufRead,BufNewFile C:/Code_Rel1/* set tags=C:/Code_Rel1/tags au BufRead,BufNewFile C:/Code_Rel2/* set tags=C:/Code_Rel2/tags HTH, Gary ...and if the directory trees can have more than one level, then use instead au BufRead,BufNewFile C:/CodeRel1/**/* \ setlocal tags=C:/CodeRel1/tags au BufRead,BufNewFile C:/CodeRel2/**/* \ setlocal tags=C:/CodeRel2/tags etc. Notice the use of :setlocal to avoid clobbering the 'tags' setting for other windows opened in the same Vim instance. Thanks for pointing out the setlocal issue--I had forgotten that 'tags' could be made local. However, the **/* is not necessary. The pattern C:/Code_Rel1/* will match any file under the C:/Code_Rel1 directory, including, for example, C:/Code_Rel1/foo/bar/thingy.txt. Regards, Gary -- Gary Johnson | Agilent Technologies [EMAIL PROTECTED] | Mobile Broadband Division | Spokane, Washington, USA
Re: Subject: Re: vim on cygwin using win32 clipboard
On 2007-03-01, Frodak Baksik [EMAIL PROTECTED] wrote: On 2/28/07, Matthew Woehlke [EMAIL PROTECTED] wrote: Gary Johnson wrote: It appears that I may need to install the ncurses package and reconfigure vim in order to get color. That would be likely; ncurses is (AFAIK) *much* better than termcap. Try getting ncurses and gettext libraries. Both are available packages in cygwin. There are several ncurses packages to choose from, but I finally figured out that I needed libncurses-devel, so I installed that, reconfigured and rebuilt vim and voila: color! It's not as clear to me what I need to resolve these differences: 36c36 +gettext --- -gettext 111c111 Linking: gcc -L/usr/local/lib -o vim.exe -lncurses -liconv -lintl --- Linking: gcc -L/usr/local/lib -o vim.exe -lncurses -liconv My Cygwin installation already has /usr/include/libintl.h /usr/lib/libintl.a /usr/lib/libintl.dll.a /usr/lib/libintl.la which appear to be what /usr/src/vim-7.0.122-1/src/auto/configure is looking for, so I don't understand what is missing and therefore which of the following likely-looking Cygwin packages I should install: gettext gettext-devel if either. On the other hand, I don't think I ever use any of vim's internationalization features, so it probably doesn't matter, especially for the purpose of evaluating this patch. In fact, I just checked the vims I use on HP-UX, SunOS and Linux and none of them have +gettext or -lintl. Thanks again for your help. I'll let you know if I find any issues with the clipboard. Regards, Gary -- Gary Johnson | Agilent Technologies [EMAIL PROTECTED] | Mobile Broadband Division | Spokane, Washington, USA
Re: can't source a file inside my _vimrc
On 2007-03-01, kib2 [EMAIL PROTECTED] wrote: Try ':filetype on' Yakov filetype on is already inside my mimrc. In fact, I've made a special function for the different languages I use : au BufEnter *.pyexe Fpython() function Fpython() au FileType python source C:\Program Files\vim\vim70\scripts\python.vim autocmd BufRead,BufNewFile *.py syntax on autocmd BufRead,BufNewFile *.py set ai filetype on les tabs sont des espaces pour Python: au BufNewFile,BufRead *.py set expandtab au BufNewFile,BufRead *.py set tabstop=4 au BufNewFile,BufRead *.py set shiftwidth=4 etc... endfunction Where do I go wrong ? If you want vim to automatically detect the file type, filetype on must be executed _before_ any buffer is loaded, that is, before the BufNewFile or BufRead events, and certainly before the BufEnter event. Executing filetype on is like arming the file detection mechanism, but the code above arms the detection _after_ the triggering events have occurred. So first of all, the filetype on line should be in the main body of the _vimrc so that it is executed when _vimrc is sourced, not later when an autocommand is triggered. Secondly, if you want syntax on, et al. to be executed when you enter a buffer containing a Python file, you should either execute Fpython() in an autocommand and remove all the autocommands from within Fpython(), or you should execute Fpython() unconditionally and leave the autocommands within Fpython() as they are. Otherwise, the settings within Fpython() won't be executed until the second Python file is loaded and vim's behavior will appear to be inconsistent. Your whole approach is really more complicated and error-prone than it needs to be. I would recommend that you take all the settings now in Fpython() (except filetype on), remove the autocommand parts, and put them all in a separate file, C:\Program Files\vim\vim70\after\ftplugin\python.vim. Then change all the set commands to setlocal, like this: source C:/Program Files/vim/vim70/scripts/python.vim syntax on setlocal ai les tabs sont des espaces pour Python: setlocal expandtab setlocal tabstop=4 setlocal shiftwidth=4 Vim's filetype detection will cause this file to be sourced whenever you open a Python file. Using setlocal will cause those settings to apply only to the current buffer, that is, only to buffers containing Python files, rather that to every buffer in the current vim instance. Lastly, if you execute syntax on like this, you enable syntax highlighting for every buffer, regardless of file type. If you want syntax highlighting for only certain file types, I would recommend putting syntax manual in your _vimrc and setlocal syntax=ON in the C:\Program Files\vim\vim70\after\ftplugin\ file for each filetype for which you want highlighting enabled. HTH, Gary -- Gary Johnson | Agilent Technologies [EMAIL PROTECTED] | Mobile Broadband Division | Spokane, Washington, USA
Re: Subject: Re: vim on cygwin using win32 clipboard
On 2007-02-28, Frodak Baksik [EMAIL PROTECTED] wrote: On 2/27/07, Gary Johnson wrote: On 2007-02-15, Frodak Baksik wrote: Here are all the changes in a single patch. I'm also posting this to the cygwin-apps mailing list, so if anyone over there could try it out would be nice. I just applied this patch to the latest Cygwin vim source package, vim-7.0.122-1, and configured it with ./configure --prefix=/usr/local --without-x --enable-gui=no However, after successfully building a number of .o files, make fails as follows: $ make Starting make in the src directory. If there are problems, cd to the src directory and run make there cd src make first make[1]: Entering directory `/usr/src/vim-7.0.122-1/src' make[1]: *** No rule to make target `proto/winclip.pro', needed by `objects/winclip.o'. Stop. make[1]: Leaving directory `/usr/src/vim-7.0.122-1/src' make: *** [first] Error 2 I'm sorry I don't have time to look into it further before I leave for the day. I hope it's obvious to someone what I've done wrong. Regards, Gary The problem appears to be with applying the patch. The file proto/winclip.pro should have been created by the patch command. I've just reinstalled fresh cygwin sources vim-7.0.122-1. Here is the command and output I get when applying the patch. The patch appeared to apply correctly except for auto/configure, which I was able to resolve, but not the way I should have. The way I applied the patch, which was to execute patch vim_cygwin_clip_patch_2007-02-13.diff in the /usr/src/vim-7.0.122-1/src directory, resulted in winclip.pro being created in that directory instead of in the proto subdirectory. $ pwd /usr/src/vim-7.0.122-1/src $ patch -p0 /usr/src/vim_cygwin_clip_patch_2007-02-13.diff patching file term.c [...] Hunk #1 succeeded at 759 (offset -5 lines). Using -p0 worked _much_ better, with the same results as yours. I thought it was probably something stupid like that. Thank you very much. I used the same configuration in your email and didn't have any issues. BTW, This is the configuration I normally use for compiling vim on cygwin. This is based upon the configuration options on the cygwin website and the feature set that vim is normally compiled with. ./configure \ --prefix=/usr \ --sysconfdir=/etc \ --libexecdir=/usr/sbin \ --localstatedir=/var \ --datadir=/usr/share \ --mandir=/usr/share/man \ --infodir=/usr/share/info \ --with-features=huge \ --without-x --enable-gui=no I wanted to keep the patched version separate from the official Cygwin version for comparison and backup in case I encountered any problems with the patched version. 'make' and 'make install' worked fine, but the resulting vim didn't use color in an rxvt. I ran configure again, this time including --with-features=huge: ./configure \ --prefix=/usr/local \ --with-features=huge \ --without-x --enable-gui=no However, I still don't see any color and there are still differences in :version between the original Cygwin vim and this patched version: $ diff vim_version_cygwin vim_version_patched_huge 1c1 VIM - Vi IMproved 7.0 (2006 May 7, compiled Oct 10 2006 10:07:11) --- VIM - Vi IMproved 7.0 (2006 May 7, compiled Feb 28 2007 15:32:26) 3c3 Compiled by [EMAIL PROTECTED] --- Compiled by [EMAIL PROTECTED] 13c13 -clipboard --- +clipboard 36c36 +gettext --- -gettext 84c84 +terminfo --- -terminfo 109c109 fall-back for $VIM: /usr/share/vim --- fall-back for $VIM: /usr/local/share/vim 111c111 Linking: gcc -L/usr/local/lib -o vim.exe -lncurses -liconv -lintl --- Linking: gcc -L/usr/local/lib -o vim.exe -ltermcap -liconv (I edited the outputs of :version to put each feature on a separate line.) :set termcap shows t_Co=8 in the original Cygwin vim and t_Co= in the patched version. It appears that I may need to install the ncurses package and reconfigure vim in order to get color. I don't know how to account for the other differences. (I wish there was a /usr/share/doc/vim-7.0.122-1/README or a /usr/src/vim-7.0.122-1/README_cygwin.txt that explained how the official Cygwin vim was built and a list of other packages needed.) Regards, Gary -- Gary Johnson | Agilent Technologies [EMAIL PROTECTED] | Mobile Broadband Division | Spokane, Washington, USA
Re: Visual block in version 7.0
On 2007-03-01, Tien Pham [EMAIL PROTECTED] wrote: Hi I have changed from an old Vim5.7 to Vim7.0. I want to use Visual block (Ctrl v) to copy a column using Vim7.0 but this does not work as previously in version 5.7, it actually pastes stuff down from the buffer. I thought that changing behave mswin to behave xterm in the _vimrc would allow me to use CTRL v for normal visual block again but apparently I could not get it work. Can someone help me with this? (ie use different key for visual block or different command in the _vimrc) The problem is not the behave mswin line but the source $VIMRUNTIME/mswin.vim line in your _vimrc. If you want more Unix-like behavior, comment that line out. HTH, Gary -- Gary Johnson | Agilent Technologies [EMAIL PROTECTED] | Mobile Broadband Division | Spokane, Washington, USA
Re: Subject: Re: vim on cygwin using win32 clipboard
On 2007-02-15, Frodak Baksik wrote: Here are all the changes in a single patch. I'm also posting this to the cygwin-apps mailing list, so if anyone over there could try it out would be nice. I just applied this patch to the latest Cygwin vim source package, vim-7.0.122-1, and configured it with ./configure --prefix=/usr/local --without-x --enable-gui=no However, after successfully building a number of .o files, make fails as follows: $ make Starting make in the src directory. If there are problems, cd to the src directory and run make there cd src make first make[1]: Entering directory `/usr/src/vim-7.0.122-1/src' make[1]: *** No rule to make target `proto/winclip.pro', needed by `objects/winclip.o'. Stop. make[1]: Leaving directory `/usr/src/vim-7.0.122-1/src' make: *** [first] Error 2 I'm sorry I don't have time to look into it further before I leave for the day. I hope it's obvious to someone what I've done wrong. Regards, Gary -- Gary Johnson | Agilent Technologies [EMAIL PROTECTED] | Wireless Division | Spokane, Washington, USA
Re: vim with shell
On 2007-02-24, Subramanian Ramaswamy [EMAIL PROTECTED] wrote: (2) My terminal is in vi mode, since that makes me the most productive i.e. I have set set -o vi in my .bashrc. How can one enable this mode within vim's : or shell ! commands - this will be very useful, if I can navigate that with vi commands... If I understand your question correctly, you can't do that while editing the command line itself, but you can use vi commands to edit the command line in the command window. See :help cmdwin I also have this in my ~/.vimrc so that typing Esc on the vim command line behaves similarly to typing Esc on the shell command line. set cedit=Esc HTH, Gary -- Gary Johnson | Agilent Technologies [EMAIL PROTECTED] | Wireless Division | Spokane, Washington, USA
Re: Mapping to search Google Code
On 2007-02-21, Sean Hubbell [EMAIL PROTECTED] wrote: Hello, I seem to be oblivious to what I am doing wrong. I have the following mapping I would like to execute from vim: nmap F2 :!/usr/bin/firefox 'http://www.google.com/codesearch?hl=enq=+'cword I can execute the following from ex, but I am missing something from the mapping, does anyone have an ideas? 1. Get rid of the double-quotes (). They make the argument appear to the shell to be part of the command name. 2. Add CR to the end. nmap F2 :!/usr/bin/firefox 'http://www.google.com/codesearch?hl=enq=+'cwordCR HTH, Gary -- Gary Johnson | Agilent Technologies [EMAIL PROTECTED] | Wireless Division | Spokane, Washington, USA
Re: Enabling gvim?
On 2007-02-20, [EMAIL PROTECTED] wrote: It's in HPUX, and 10.20 at that. but I'll try your --with-features option. I don't know how standard the HP-UX 10.20 installation I use is, but I built vim-7.0 without any problems using these commands: cd ~/src/vim-7.0 bzcat vim-7.0.tar.bz2 | tar xf - cd vim70 ./configure --prefix=$HOME/src/vim-7.0 --with-tlib=curses --enable-cscope make make install The output of 'vim --version' is: VIM - Vi IMproved 7.0 (2006 May 7, compiled Aug 28 2006 11:48:07) Included patches: 1-66 Compiled by [EMAIL PROTECTED] Normal version with GTK GUI. Features included (+) or not (-): -arabic +autocmd +balloon_eval +browse +builtin_terms +byte_offset +cindent +clientserver +clipboard +cmdline_compl +cmdline_hist +cmdline_info +comments +cryptv +cscope +cursorshape +dialog_con_gui +diff +digraphs +dnd -ebcdic -emacs_tags +eval +ex_extra +extra_search -farsi +file_in_path +find_in_path +folding -footer +fork() -gettext -hangul_input -iconv +insert_expand +jumplist -keymap -langmap +libcall +linebreak +lispindent +listcmds +localmap +menu +mksession +modify_fname +mouse +mouseshape -mouse_dec -mouse_gpm -mouse_jsbterm -mouse_netterm +mouse_xterm -multi_byte +multi_lang -mzscheme +netbeans_intg -osfiletype +path_extra -perl +postscript +printer -profile -python +quickfix +reltime -rightleft -ruby +scrollbind +signs +smartindent -sniff +statusline -sun_workshop +syntax +tag_binary +tag_old_static -tag_any_white -tcl +terminfo +termresponse +textobjects +title +toolbar +user_commands +vertsplit +virtualedit +visual +visualextra +viminfo +vreplace +wildignore +wildmenu +windows +writebackup +X11 -xfontset +xim +xsmp_interact +xterm_clipboard -xterm_save system vimrc file: $VIM/vimrc user vimrc file: $HOME/.vimrc user exrc file: $HOME/.exrc system gvimrc file: $VIM/gvimrc user gvimrc file: $HOME/.gvimrc system menu file: $VIMRUNTIME/menu.vim fall-back for $VIM: /home/garyjohn/src/vim-7.0-patched/share/vim Compilation: gcc -c -I. -Iproto -DHAVE_CONFIG_H -DFEAT_GUI_GTK -I/opt/TWWfsw/gtk+12/include/gtk-1.2 -I/opt/TWWfsw/glib12/include/glib-1.2 -I/opt/TWWfsw/glib12/lib/glib/include -I/usr/contrib/X11R6/include -I/usr/include/X11R6 -g -O2 Linking: gcc -L/usr/local/lib -o vim -L/opt/TWWfsw/gtk+12/lib -Wl,+s,+b,/opt/TWWfsw/gtk+12/lib -L/usr/contrib/X11R6/lib -lgtk -lgdk -L/opt/TWWfsw/glib12/lib -Wl,+s,+b,/opt/TWWfsw/glib12/lib -Wl,-E -lgmodule -lglib -ldld -lXext -lm -lXt -lcurses Note that I have omitted the steps necessary to bring the original source up to patch level 66, but that should have no effect on being able to build a GUI version. Note also that --prefix and --enable-cscope shouldn't affect your build, but it may be necessary to use --with-tlib=curses in order to use a color terminal. In other words, I didn't have to do anything special to get a working gvim. HTH, Gary -- Gary Johnson | Agilent Technologies [EMAIL PROTECTED] | Wireless Division | Spokane, Washington, USA
Re: Missing configuration commands in vim 7?
On 2007-02-16, Larry Alkoff [EMAIL PROTECTED] wrote: Charles E Campbell Jr wrote: Larry Alkoff wrote: I have a desktop and newly configured laptop with different versions of vim. The desktop has vim 6.4.6 which contains the lines in ~/.vimrc set mouse=a syntax on They show in :help The laptop has vim 7.0.35 and gives an error on the above two vimrc commands. Also they don't show in :help. What has happened in vim 7? Are there replacements for syntax on and set mouse? These commands are fine. So, bring up your new vim and type: :version What does that show? Tony has already addressed most of your issues, so I'll just add this. The error I get is: [EMAIL PROTECTED] X11 # vi xorg.conf Error detected while processing /home/lba/.vimrc: line 52: E319: Sorry, the command is not available in this version: syntax on line 121: E538: No mouse support: mouse=a Press ENTER or type command to continue Where line 52 says: syntax on and line 121 says: set mouse=a That explains a lot. You're executing vi, not vim, and apparently on a Linux system. Some Linux system vendors put a very limited version of vim in /bin/vi so that there is some editor that doesn't take much disk space or RAM available for troubleshooting systems that may not be able to mount /usr. I get similar errors when I execute /bin/vi on a Red Hat 9 system. Executing :version shows that none of the mouse-related features were included. :version VIM - Vi IMproved 6.1 (2002 Mar 24, compiled Feb 12 2003 07:44:25) Included patches: 1, 3-15, 17-18, 20-22, 24-34, 36-43, 45-49, 51-72, 74-75, 77-8 3, 85-87, 89-92, 94-99, 101-118, 120-146, 150, 152-153, 157-183, 185-189, 191-19 5, 197, 200-201, 203-227, 231-239, 241-242, 244-252, 254-258, 260-289, 293-295, 297-299, 301-302, 305-310, 312-320 Compiled by [EMAIL PROTECTED] Tiny version without GUI. Features included (+) or not (-): -autocmd -balloon_eval -browse +builtin_terms -byte_offset -cindent -clientserver -clipboard -cmdline_compl -cmdline_hist -cmdline_info -comments -cryptv -cscope -dialog -diff -digraphs -ebcdic -emacs_tags -eval -ex_extra -extra_search -farsi -file_in_path -find_in_path -folding -footer +fork() -gettext -hangul_input +iconv -insert_expand -jumplist -keymap -langmap -libcall -linebreak -lispindent -listcmds -localmap -menu -mksession -modify_fname -mouse -mouse_dec -mouse_gpm -mouse_jsbterm -mouse_netterm -mouse_xterm +multi_byte -multi_lang -osfiletype -path_extra -perl -printer -python -quickfix -rightleft -ruby -scrollbind -signs -smartindent -sniff -statusline -sun_workshop -syntax -tag_binary -tag_old_static -tag_any_white -tcl +terminfo -termresponse -textobjects -title -toolbar -user_commands -vertsplit -virtualedit -visual -viminfo -vreplace +wildignore -wildmenu -windows +writebackup -X11 -xfontset -xim -xterm_clipboard -xterm_save system vimrc file: /usr/share/vim/vim61/macros/vimrc user vimrc file: $HOME/.vimrc user exrc file: $HOME/.exrc fall-back for $VIM: /usr/share/vim Compilation: gcc -c -I. -Iproto -DHAVE_CONFIG_H -O2 -march=i386 -mcpu=i686 - g -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -fno-strength-reduce Linking: gcc -L/usr/local/lib -o vim -ltermcap -lacl -ldl The easiest solution is to use vim and not vi. That should run /usr/bin/vim which is built with many more features than /bin/vi. If your fingers are too accustomed to vi for that, you could put an alias in your ~/.bashrc file: alias vi=vim Regards, Gary -- Gary Johnson | Agilent Technologies [EMAIL PROTECTED] | Wireless Division | Spokane, Washington, USA
Re: entering copied text into command mode?
On 2007-02-15, Theerasak Photha [EMAIL PROTECTED] wrote: On 2/15/07, Lev Lvovsky [EMAIL PROTECTED] wrote: I often find myself copy/pasting via my GUI text that I might have on the screen, and then pasting it into the command to be performed - is there any way to cut/paste text into the command area when I have it highlighted with just the keyboard? Assuming you're talking about ex commands, yes. You can type Ctrl-R to insert a register, then the name of any register, including the expression register, =. In your case, the name would probably be '+', so Ctrl-R+. I tried this on a Sun machine running vim in an xterm and running just gvim. In both cases, '+' didn't work but '*' did. HTH, Gary -- Gary Johnson | Agilent Technologies [EMAIL PROTECTED] | Wireless Division | Spokane, Washington, USA
Re: tips project
On 2007-02-16, Bram Moolenaar [EMAIL PROTECTED] wrote: Hi all, Google code has now added support for a wiki. This means open source projects can have a wiki that's free, fast and reliable (hopefully :-). http://code.google.com/hosting/ During my presentation last Tuesday the idea came up (again) to move the Vim tips to a wiki. The big advantage is that instead of having to read the notes below the tip to find out about improvements, the notes can be added in the right place, or even correct mistakes in the tip. I would like to ask for volunteers who want to take the current tips and notes, write some kind of script to move them to the wiki and set it up for use. If this works well we can delete the tips from the Vim website. They are currently closed for updates anyway, thus this is a good time to try it. Can one get an RSS feed from a wiki? Gary -- Gary Johnson | Agilent Technologies [EMAIL PROTECTED] | Wireless Division | Spokane, Washington, USA
Re: entering copied text into command mode?
On 2007-02-16, A.J.Mechelynck [EMAIL PROTECTED] wrote: Theerasak Photha wrote: On 2/15/07, Lev Lvovsky [EMAIL PROTECTED] wrote: I often find myself copy/pasting via my GUI text that I might have on the screen, and then pasting it into the command to be performed - is there any way to cut/paste text into the command area when I have it highlighted with just the keyboard? Assuming you're talking about ex commands, yes. You can type Ctrl-R to insert a register, then the name of any register, including the expression register, =. In your case, the name would probably be '+', so Ctrl-R+. Of course, you should first copy the text to the clipboard in whatever program you're pasting from. Under X11, at least on my system, you don't have to explicitly yank or copy the text: text highlighted by the mouse automatically goes into the cut buffer (or the selection--I can't keep the two straight). The last text highlighted with the mouse is immediately available in the * register. Regards, Gary -- Gary Johnson | Agilent Technologies [EMAIL PROTECTED] | Wireless Division | Spokane, Washington, USA
Re: searching for a string that has many '/' characters
On 2007-02-02, [EMAIL PROTECTED] wrote: I have a string that has lots of forward slashes. I need to search it and delete it (e.g. unix path name). I could use a backslash for everything forward slash and find it in vim. Is there a way I need not do that? For now, I use 'grep -n' to get the line number and then delete it. I don't actually type the string, I just use cut-and-paste! In addition to the techniques mentioned by others, you could just search backwards instead of forwards, e.g., ?/path/to/file If searching backwards bothers you, you can change that to a forward search by just typing // Another technique would be to use the :grep command, e.g., :grep /path/to/file % to search the current file, and use the quickfix commands such as :cn to traverse the list of matches. HTH, Gary -- Gary Johnson | Agilent Technologies [EMAIL PROTECTED] | Wireless Division | Spokane, Washington, USA
Re: test and question
On 2007-02-05, John Doe [EMAIL PROTECTED] wrote: No no, the options is local to a buffer. The only way I can think of is to create a hook of some sort (events) and do 'set tw=0' after a file loads, but gurus might know better. There are several ways to do this. If this is a problem for only a few file types, then the standard solution is to create your own plugin file for each file type for which this is a problem and put them in ~/.vim/after/ftplugin/ on Unix or $VIM\vimfiles\after\ftplugin on Windows. Each file would contain just this line: setlocal tw=0 If you want to do this for all file types, you might be better off putting this in your ~/.vimrc: au FileType * setlocal tw=0 It's important to put this towards the end of your ~/.vimrc, after any :filetype command(s), so that this autocommand is executed _after_ any filetype plugins are loaded. HTH, Gary -- Gary Johnson | Agilent Technologies [EMAIL PROTECTED] | Wireless Division | Spokane, Washington, USA
Error in eval.txt (:help let-option)
There appears to be an error in one of the tag names given to the
help entry for let-option:
:let {option-name} = {expr1} *:let-option* *:let-star*
The second tag should be *:let-* rather than :let-star*. This
is in the 2006 May 06 version of doc/eval.txt. A patch follows.
- cut here -
*** eval.txt.orig Sun May 7 05:16:44 2006
--- eval.txtWed Jan 31 11:21:19 2007
***
*** 5684,5690
Append {expr1} to register {reg-name}. If the
register was empty it's like setting it to {expr1}.
! :let {option-name} = {expr1} *:let-option* *:let-star*
Set option {option-name} to the result of the
expression {expr1}. A String or Number value is
always converted to the type of the option.
--- 5684,5690
Append {expr1} to register {reg-name}. If the
register was empty it's like setting it to {expr1}.
! :let {option-name} = {expr1} *:let-option* *:let-*
Set option {option-name} to the result of the
expression {expr1}. A String or Number value is
always converted to the type of the option.
- cut here -
Regards,
Gary
--
Gary Johnson | Agilent Technologies
[EMAIL PROTECTED] | Wireless Division
| Spokane, Washington, USA
Re: Conditional autocmd question
On 2007-01-29, Evan Klitzke [EMAIL PROTECTED] wrote: Hi everyone, I have the F2 key mapped as a compile function for the programs I write, e.g. if I am editing a .tex file I have an autocmd to execute pdflatex, if I am editing a .py file I have an autocmd to execute python. The case of .c files is somewhat trickier: I want to use autocmd to map F2 to :make if a Makefile exists in the current directory, otherwise it should try to compile the file with gcc. For example, if I am editing foo.c, hitting F2 should execute gcc -o foo foo.c. Do you have any recommendations on how to do this? See: :help filereadable() Example: if filereadable(Makefile) let makeprg = make else let makeprg = gcc -o foo foo.c endif See also: help let-option help make help makeprg help 30.1 Particularly I am confused on how to have a conditional autocmd, and how to extract a substring from the current buffer/file name. See: :help afile :help fnamemodify() :help expand() :help filename-modifiers :help extension-removal Example 1: let basename = expand(afile:t:r) Example 2: :set makeprg=make\ -o\ %\ % HTH, Gary -- Gary Johnson | Agilent Technologies [EMAIL PROTECTED] | Wireless Division | Spokane, Washington, USA
Re: How to filter only portion of a line, and not the whole line?
On 2007-01-28, ben lieb [EMAIL PROTECTED] wrote: I have decided to write some perl filters for vim, but was disappointed that it seems I can only filter WHOLE LINES (and not selected parts of lines). Is this true? I found that... :','!my_filter.pl ...is given the whole line, even when only two words in the middle of the line are selected. Is there any way to send only parts of lines and not the whole line(s). There is a plugin that lets you do this, vis.vim. You can find it here: http://vim.sourceforge.net/scripts/script.php?script_id=1195 HTH, Gary -- Gary Johnson | Agilent Technologies [EMAIL PROTECTED] | Wireless Division | Spokane, Washington, USA
Re: help writing syntax file
On 2007-01-27, Muddassirali Mirzani [EMAIL PROTECTED] wrote:
Hi,
I'd like to write a simple syntax file for a file
type that is a transcript( contains only printed
messages from a simulation) .
I wanted to do the following :
e.g. a) Search for string [TRACE] and colour the whole
line in yellow
b) Search for string [WARNING] and colour the
whole line in green.. and so on...
Are there any examples scripts out there.. Any
help/pointers appreciated..
Here's a simple one that I did to highlight a similar type of file,
the transcript of a system build script. The types of lines
highlighted are:
- Comments, beginning with '#' and ending at the end of the line.
- Commands, lines beginning with 'CMD: '.
- Warning messages, lines containing the word 'warning' in any
capitalization.
- Error messages, lines containing the word 'Error'.
- Build summaries, multiple lines beginning with the line 'b
'=== Build Complete ===' and ending with a blank line or the end
of the file.
To set the colors, I gave each pattern a syntax group name,
following what appears to be the standard vim naming convention of
using the plugin or language name followed by a description of the
syntax element. I then assigned each of my syntax groups to an
existing vim syntax group. I chose the colors by executing :hi
and selecting the syntax groups whose color I liked rather than by
any logical association between the group names.
HTH,
Gary
--
Gary Johnson | Agilent Technologies
[EMAIL PROTECTED] | Wireless Division
| Spokane, Washington, USA
Vim syntax file
Language: Build Manager output
Maintainer: Gary Johnson [EMAIL PROTECTED]
Last Change: 2004-10-04 13:05:53
Quit when a syntax file was already loaded.
if exists(b:current_syntax)
finish
endif
syn match bldmgrComment /#.*/
syn match bldmgrCmd /^CMD: .*/
syn match bldmgrWarning /.*\warning\.*\c/
syn match bldmgrError /.*\Error\.*/
syn match bldmgrComplete/^=== Build Complete
===\n\_.\{-}\(\(\_^\s*$\)\|\%$\)/
Terminated by a blank line or
end of file.
Define the default highlighting.
hi def link bldmgrComment Comment
hi def link bldmgrCmd MoreMsg
hi def link bldmgrWarning Directory
hi def link bldmgrError WarningMsg
hi def link bldmgrComplete Title
let b:current_syntax = bldmgr
vim: ts=8 sw=2
Re: vim.sf.net and subscribing to comments/scripts on Google's front page
On 2007-01-17, Denis Perelyubskiy [EMAIL PROTECTED] wrote: hello, does anyone subscribe to comments/tips from vim.sf.net on Google's home page? Every time I try, I get very weird comments: e.g.: Tip #1473 - pics of amateur videos nude Tip #1472 - VIMRC Tip #1471 - spanish shemale sex homemade Basically, I think even the spammed tips get published to the RSS. I don't know if there is a way to refresh RSS when the comments are removed, but it sure would be nice to get that! Slightly OT, but are you subscribed to the scripts as well as the tips? If so, does the scripts feed work for you? It hasn't for me since the scripts server had problems a month or so ago. Regards, Gary -- Gary Johnson | Agilent Technologies [EMAIL PROTECTED] | Wireless Division | Spokane, Washington, USA
Re: Upgrading or enabling features in vim
On 2007-01-15, Erin Spiceland [EMAIL PROTECTED] wrote: I just got a new server and vim wasn't installed. I installed 7.0 from scratch, but there are some problems with missing features or features not working: 1. syntax highlighting doesn't work. It is turned on in vimrc but I haven't checked anything else. 2. using the arrows on the keyboard in insert mode puts A, B, C, or D and newline into the file instead of moving up, down, left, or right. 3. doesn't remember my command history 4. doesn't remember where I was in the file when I closed it. 5. only remembers 1 change, so I can't use the u command to undo more than 1 change. What can I do to fix these problems or enable these features? #5 indicates that, as Tim said, you have 'cp' set. But vim sets 'nocp' automatically when it detects and sources an initialization file named .vimrc or _vimrc. Therefore, it appears that your vimrc file is not being sourced, which would explain #1. Executing :version will show you where your vim is looking for its initialization files and :scriptnames will show you the initialization files vim actually sourced. Reading :help initialization will also help you understand what should be happening when you start vim and may help you track down the root problem. HTH, Gary -- Gary Johnson | Agilent Technologies [EMAIL PROTECTED] | Wireless Division | Spokane, Washington, USA
Re: Upgrading or enabling features in vim
On 2007-01-15, Erin Spiceland [EMAIL PROTECTED] wrote: On Mon, 2007-01-15 at 14:55 -0800, Gary Johnson wrote: On 2007-01-15, Erin Spiceland [EMAIL PROTECTED] wrote: I just got a new server and vim wasn't installed. I installed 7.0 from scratch, but there are some problems with missing features or features not working: 1. syntax highlighting doesn't work. It is turned on in vimrc but I haven't checked anything else. 2. using the arrows on the keyboard in insert mode puts A, B, C, or D and newline into the file instead of moving up, down, left, or right. 3. doesn't remember my command history 4. doesn't remember where I was in the file when I closed it. 5. only remembers 1 change, so I can't use the u command to undo more than 1 change. What can I do to fix these problems or enable these features? #5 indicates that, as Tim said, you have 'cp' set. But vim sets 'nocp' automatically when it detects and sources an initialization file named .vimrc or _vimrc. Therefore, it appears that your vimrc file is not being sourced, which would explain #1. Executing :version will show you where your vim is looking for its initialization files and :scriptnames will show you the initialization files vim actually sourced. Reading :help initialization will also help you understand what should be happening when you start vim and may help you track down the root problem. system vimrc file: $VIM/vimrc $VIM is set to /usr/local/share/vim but /usr/local/share/vim/vimrc doesn't exist, and a vimrc does exist in /etc. How can I change it to use /etc? There is something wrong with your installation. If vim had never before been installed on that server, then the only way for /etc/vimrc to have appeared was for your installation process to have created it. But if you configured vim to look for vimrc in /usr/local/share/vim, then that's where your installation process should have put it. The right place to put it depends on your system and where you want to put stuff and, if you are not the system administrator, where you are allowed to put stuff. You'll have to give us more details of your system and how you configured vim for us to sort this out properly. You wrote originally that there were some features missing or not working in this installation. That implies that you have used them before where they did work. How did you get them to work then? Did you have your own ~/.vimrc or just a system vimrc? If you had just a system vimrc and that is the file now in /etc, I would just move that file to /usr/local/share/vim. On the Unix systems where I have installed vim, I don't even have a system vimrc--I just use ~/.vimrc. There are also ways to set environment variables to get vim to look in other places for initialization files, but since you built this vim from scratch, it would be better for you to reconfigure and rebuild it to get it right, or at least self-consistent. The preferred replying style in the vim list is to put the quoted text on top and your reply underneath, so I have reformatted your reply to that style. Also, don't forget to reply to the list rather than to just the author of the message to which you are replying, so that everyone in the list can follow the discussion and help in solving the problem, or see that it has been solved. Regards, Gary -- Gary Johnson | Agilent Technologies [EMAIL PROTECTED] | Wireless Division | Spokane, Washington, USA
Re: Upgrading or enabling features in vim
On 2007-01-15, Erin Spiceland [EMAIL PROTECTED] wrote:
On 2007-01-15, Erin Spiceland [EMAIL PROTECTED] wrote:
On Mon, 2007-01-15 at 14:55 -0800, Gary Johnson wrote:
On 2007-01-15, Erin Spiceland [EMAIL PROTECTED] wrote:
I just got a new server and vim wasn't installed. I installed 7.0 from
scratch, but there are some problems with missing features or features
not working:
1. syntax highlighting doesn't work. It is turned on in vimrc but I
haven't checked anything else.
2. using the arrows on the keyboard in insert mode puts A, B, C, or D
and newline into the file instead of moving up, down, left, or right.
3. doesn't remember my command history
4. doesn't remember where I was in the file when I closed it.
5. only remembers 1 change, so I can't use the u command to undo
more
than 1 change.
What can I do to fix these problems or enable these features?
#5 indicates that, as Tim said, you have 'cp' set. But vim sets
'nocp' automatically when it detects and sources an initialization
file named .vimrc or _vimrc. Therefore, it appears that your vimrc
file is not being sourced, which would explain #1.
Executing :version will show you where your vim is looking for its
initialization files and :scriptnames will show you the
initialization files vim actually sourced. ...
system vimrc file: $VIM/vimrc
$VIM is set to /usr/local/share/vim but /usr/local/share/vim/vimrc
doesn't exist, and a vimrc does exist in /etc. How can I change it to
use /etc?
[...]
Thanks for the tips. This server was supposedly a fresh install of RHE.
I say that vim was not installed only because I tried to use it and got
the bash command not found message. I downloaded the source from
vim.org and did ./configure; make; make install. The machines I have
used vim on before were always preinstalled with vim. I use FC6 at home
and RHE on my other 4 servers. I've never worked with a vimrc
or .viminfo before, except very minimally. The five things I listed in
my original email were things that always just worked. I was very
surprised to find vim was not installed this time. rpm -qa | grep vim
shows that vim 6.3 minimal is also installed, but that isn't the one my
system is using, because vim --version shows 7.0. Are there any
configure options that I can use or is there an enhanced version that I
might be used to? Should I reinstall? from source or rpm?
Thanks for the extra info. I think I understand what's going on a
little better now. I just logged on to a system running Red Hat
Enterprise Linux ES release 3 (Taroon Update 8). It happens to have
vim installed on it in /usr/bin, but it also has /bin/vi. I ran
/bin/vi -u NONE (to keep it from choking on my ~/.vimrc), saw that
it was Vim-6.3.81, and executed :version. There I saw this:
Compiled by [EMAIL PROTECTED]
Tiny version without GUI.
...
system vimrc file: /etc/vimrc
user vimrc file: $HOME/.vimrc
user exrc file: $HOME/.exrc
fall-back for $VIM: /usr/share/vim
I think this is Red Hat's minimal vi that they include so that the
user has something to edit with even if /usr is not mounted. So
that's where your /etc/vimrc came from. I would just leave that one
alone.
I then ran /usr/bin/vim -u NONE, also Vim-6.3.81, and again
executed :version with this result:
Compiled by [EMAIL PROTECTED]
Huge version without GUI.
...
system vimrc file: /etc/vimrc
user vimrc file: $HOME/.vimrc
user exrc file: $HOME/.exrc
fall-back for $VIM: /usr/share/vim
So it appears that Red Hat uses the same initialization file for
both /bin/vi and /usr/bin/vim. I took a look at /etc/vimrc and
found that it contained the commands to set 'nocompatible' ('nocp'),
to restore the last cursor position when editing a file, and to set
the color commands for an xterm, among others.
The features you are used to having are not part of the default
installation of vim from vim.org. They are usually compiled into
the binary by the default configure and make process, but they must
also be configured and enabled in your initialization file(s). Red
Hat's vim rpm includes an initialization file but the default
installation of vim from vim.org does not. You have to provide
those yourself.
So, to get a vim with these features enabled, you could either:
- remove your current vim install and install the Red Hat vim
rpm instead, which knows to look in /etc/vimrc; or
- retain your current vim install and copy /etc/vimrc to
/usr/local/share/vim/vimrc.
HTH,
Gary
--
Gary Johnson | Agilent Technologies
[EMAIL PROTECTED] | Wireless Division
| Spokane, Washington, USA
