Re: echo question
On 5/14/2006 1:37 AM, Gerald Lai wrote: > On Sun, 14 May 2006, Yakov Lerner wrote: >> Try 2 things >> (1) add :redraw before the :echo in question >> (2) if that doesn't help, make message shorter. >> I noticed that if message is longer than screen width-15, >> it cases the prompt. > > You could also readjust the height of the command-line dynamically: > > let msg = "str" > let len = strlen(substitute(msg, ".", "x", "g")) > let t_ch = &cmdheight > let &cmdheight = len / (&columns - 15) + 1 > echo msg > let &cmdheight = t_ch > > See ":help 'cmdheight'" & ":help strlen()". I tried adding :redraw, but that didn't seem to work. As for making the message shorter or the changing the height, I don't think those are applicable. The line is not longer than the window width. In fact, this is the function: function Toggle_spell() if &spell exec "set nospell" else exec "set spell" echo "]s to skip to word, zg to add word, z= to suggest word" endif endfunction nmap :call Toggle_spell() I just want to display a message in the status reminding me of the commands when I enable the spell checker. Any other ideas? Thanks. -- Jared
Re: scrolling in vim7 on winxp?
when you say scrolling, do you mean with a mouse wheel? Or moving dragging the scroll bar? Or something else? I tried to duplicate this behavior, but was unable to do so. Vim's working fine on my copy of Windows XP. This is the stock version, though. -- Jared Breland [EMAIL PROTECTED] http://www.legroom.net/ On 5/13/2006 12:35 PM, oystercatcher wrote: > I am running vim 7 on winxp compiled with mingw 7.0223 > > I have noticed that when I am scrolling through text (postscript source) > that I lose focus on the vim window. I thought at first that I was > simple bumping another key or the mouse. Then I thought that > maybe some running application was somehow taking focus > to another window. > > Since I am not sure of the cause and will continue to monitor > what might be happening, I thought I would just ask the list > if anyone might have noticed the same problem? > > Thanks
Re: echo question
On 5/14/06, Jared <[EMAIL PROTECTED]> wrote: On 5/14/2006 1:37 AM, Gerald Lai wrote: > On Sun, 14 May 2006, Yakov Lerner wrote: >> Try 2 things >> (1) add :redraw before the :echo in question >> (2) if that doesn't help, make message shorter. >> I noticed that if message is longer than screen width-15, >> it cases the prompt. > > You could also readjust the height of the command-line dynamically: > > let msg = "str" > let len = strlen(substitute(msg, ".", "x", "g")) > let t_ch = &cmdheight > let &cmdheight = len / (&columns - 15) + 1 > echo msg > let &cmdheight = t_ch > > See ":help 'cmdheight'" & ":help strlen()". I tried adding :redraw, but that didn't seem to work. As for making the message shorter or the changing the height, I don't think those are applicable. The line is not longer than the window width. In fact, this is the function: function Toggle_spell() if &spell exec "set nospell" else exec "set spell" echo "]s to skip to word, zg to add word, z= to suggest word" endif endfunction nmap :call Toggle_spell() I just want to display a message in the status reminding me of the commands when I enable the spell checker. Doesn't cause "Hit Enter" prompt for me. In any case, try to add to your nmap: nmap :call Toggle_spell() Yakov
Re: Slow startup
In cygwin rxvt works without X server. In your case, it's not case of X server being slow. It's either X not running at all, or $DISPLAY not set correctly. You can check for yourself if you try any other X app like xterm. It will take same 60 sec of timeout and won't start. Correct ? Yakov On 5/12/06, Jeffrey Pratt <[EMAIL PROTECTED]> wrote: It works; thanks. So, I assume it was trying to connect to the X server. Maybe offtopic, but can you tell me why X is slow, or point me somewhere that could tell me? On 5/11/06, Yakov Lerner <[EMAIL PROTECTED]> wrote: > On 5/12/06, Jeffrey Pratt <[EMAIL PROTECTED]> wrote: > > Hi: > > > > I just built Vim 7 on Cygwin, linked with ncurses, and it takes 54 sec > > to start in rxvt! (It starts normally if done from the regular Cygwin > > Bash Prompt.) I've built it on two other machines with the same > > configuration options, and neither of them take so much time in rxvt. > > Does anyone know what might be causing this? > > Try vim -X > > Yakov
Re: echo question
I forgot CC:[EMAIL PROTECTED] Then I'll send you twice. Jared wrote: > On 5/14/2006 1:37 AM, Gerald Lai wrote: >> On Sun, 14 May 2006, Yakov Lerner wrote: >>> Try 2 things >>> (1) add :redraw before the :echo in question >>> (2) if that doesn't help, make message shorter. >>> I noticed that if message is longer than screen width-15, >>> it cases the prompt. >> >> You could also readjust the height of the command-line dynamically: >> >> let msg = "str" >> let len = strlen(substitute(msg, ".", "x", "g")) >> let t_ch = &cmdheight >> let &cmdheight = len / (&columns - 15) + 1 >> echo msg >> let &cmdheight = t_ch >> >> See ":help 'cmdheight'" & ":help strlen()". > > > I tried adding :redraw, but that didn't seem to work. As for making the > message shorter or the changing the height, I don't think those are > applicable. The line is not longer than the window width. In fact, this is > the function: > > function Toggle_spell() >if &spell > exec "set nospell" >else > exec "set spell" > echo "]s to skip to word, zg to add word, z= to suggest word" >endif > endfunction > nmap :call Toggle_spell() > > I just want to display a message in the status reminding me of the commands > when I enable the spell checker. > > Any other ideas? Thanks. I think that your 'cmdheight' is 1 and 'showcmd' or 'ruler' is on and perhaps 'laststatus' is 0 or 1. How about this let ru_save = &ruler let sc_save = &showcmd set noruler noshowcmd echo "]s to skip to word, zg to add word, z= to suggest word" let &showcmd = sc_save let &ruler = ru_save But the message may be truncated when there is no space for showcmd and ruler. It seems that showcmd and ruler require some spaces on the right side of cmdline area. -- Yukihiro Nakadaira <[EMAIL PROTECTED]>
Re: echo question
Hi Jared, On 5/14/06, Jared <[EMAIL PROTECTED]> wrote: On 5/14/2006 1:37 AM, Gerald Lai wrote: > On Sun, 14 May 2006, Yakov Lerner wrote: >> Try 2 things >> (1) add :redraw before the :echo in question >> (2) if that doesn't help, make message shorter. >> I noticed that if message is longer than screen width-15, >> it cases the prompt. > > You could also readjust the height of the command-line dynamically: > > let msg = "str" > let len = strlen(substitute(msg, ".", "x", "g")) > let t_ch = &cmdheight > let &cmdheight = len / (&columns - 15) + 1 > echo msg > let &cmdheight = t_ch > > See ":help 'cmdheight'" & ":help strlen()". I tried adding :redraw, but that didn't seem to work. As for making the message shorter or the changing the height, I don't think those are applicable. The line is not longer than the window width. In fact, this is the function: function Toggle_spell() if &spell exec "set nospell" else exec "set spell" echo "]s to skip to word, zg to add word, z= to suggest word" endif endfunction nmap :call Toggle_spell() I just want to display a message in the status reminding me of the commands when I enable the spell checker. Any other ideas? Thanks. You can try adding the following echo statement before the above echo statement: echo "\r" - Yegappan
Re: CVS service resumed?
On Sat, May 13, 2006 at 06:38:51PM -0400, Chris Sutcliffe wrote: > > In terms of getting the latest and greatest source, is the Subversion > repository generally the 'main' source with the cvs repository being > updated from there? Or is it now that CVS is more or less in working > order again at SF will it become the 'main' source? > > Cheers! > > Chris I believe there is no definitive answer to this question. Bram is on vacation now, so (1) The CVS vs. SVN question will not be settled for another month or two. (2) In the mean time, it makes little difference because no more patches will be released until Bram finishes vacation, starts his new job with Google, and catches up on his e-mail backlog. I think the most official version of the vim sources is ftp.vim.org . I plan to update my vim 7.0 code from ftp://ftp.vim.org/pub/vim/patches/7.0/ There is a README file there with instructions. HTH --Benji Fisher
Re: Is there a way to move tabs around via the mouse?
On 5/9/06, Eric Arnold <[EMAIL PROTECTED]> wrote: On 5/9/06, Hari Krishna Dara <[EMAIL PROTECTED]> wrote: > > On Tue, 9 May 2006 at 10:29am, Yegappan Lakshmanan wrote: > > > Hi Scot, > > > > On 5/9/06, Scot P. Floess <[EMAIL PROTECTED]> wrote: > > > Is there anyway to move the tabs in a tabbed window around using the > > > mouse? I see the menu options for a tab when I right click on the tab. > > > I also saw the tabm [N] option I can set. > > > > > > However, is it possible to set an option that will allow me to click on > > > a tab and drag it either right or left? > > > > > > > No. Moving the GUI tabs (re-ordering) using the mouse is not yet supported. > > > > - Yegappan > > It should be possible to save the current windows (something like the > way ZoomWin does), and open the windows as they are in a new tab page, > and close the old tab (note the order, this works with modified buffers > with 'nohidden' set). Sorry, I have no code that can make this work, > just an idea. I'm not sure if you're still talking about mouse usage. Remember :tabmove I'm working on a patch now which would allow you to move the non-GUI tabs around using the mouse. I've uploaded the patch. It's at proof-of-concept stage.
Re: keymaps in vim7.0, where are they?
On Thu, May 11, 2006 at 09:22:37AM +0200, Andrei A. Voropaev wrote: > On Wed, May 10, 2006 at 10:02:59PM -0400, Benji Fisher wrote: > > On Wed, May 10, 2006 at 10:36:52AM +0200, Andrei A. Voropaev wrote: > > > Hi! > > > > > > I've installed vim 7 from sources. This did the installation for the RT, > > > but somehow the keymaps directory is missing. I've copied it from the > > > old 6.3 installation, but maybe I should simply obtain some additional > > > file? > > > > I have a keymap/ subdirectory of $VIMRUNTIME. Yes, it is in the > > standard archive, verified by > > > > $ bzcat vim-7.0.tar.bz2 | tar tf - | grep key > > Hm. Actually it is really there. But why is it not installed then? > Guessing, during installation I've added FEAT_LANGMAP by modifying > feature.h file, looks like Makefile didn't know about that > and didn't install the keymap when I did make install. My vim has "normal" features, including -keymap -langmap , and I still have $VIMRUNTIME/keymap/ . Maybe it works differently depending on the OS. I am using Linux. Are you using Windows? If you want to figure out what is going wrong, you can either study src/Makefile or else read the messages when you do "make install". You might also try running $ configure --with-features=big (or un-commenting the appropriate line in src/Makefile) when building vim. HTH --Benji Fisher
Re: Syntax Highlighting problem
On Wed, May 10, 2006 at 04:06:38PM +0530, Jerin Joy wrote: > Hi, > > I use gvim as my default editor. My source files are in a non standard > language whose syntax is similar to Verilog. When I open files from > command line in independent gvim windows the syntax highlighting uses > the verilog syntax which is what I want. The only thing is when I use > the split command to split an existing gvim window between 2 files, > the new file opened does not have the syntax highlighting or colour. > Does anyone know why its not using the verilog syntax for the second > file? Is there a way to add this file type so that gvim recognizes it? > It works fine for Verilog/C++ source files. > I wanted to use the split command instead of multiple gvim windows to > reduce clutter on my desktop. > > Jerin How is it that the first file you open is detected properly. For example, have you added something to your vimrc file to make verilog syntax the default? Probably you should read :help new-filetype (and perhaps some of the preceding docs for context). The goal is to have vim set the 'filetype' option automatically each time you open one of these files, and then to load the verilog syntax. HTH --Benji Fisher
Re: Is there a way to move tabs around via the mouse?
On Sun, 14 May 2006, Eric Arnold wrote: On 5/9/06, Gerald Lai <[EMAIL PROTECTED]> wrote: On Tue, 9 May 2006, Hari Krishna Dara wrote: > > On Tue, 9 May 2006 at 10:29am, Yegappan Lakshmanan wrote: > >> Hi Scot, >> >> On 5/9/06, Scot P. Floess <[EMAIL PROTECTED]> wrote: >>> Is there anyway to move the tabs in a tabbed window around using the >>> mouse? I see the menu options for a tab when I right click on the tab. >>> I also saw the tabm [N] option I can set. >>> >>> However, is it possible to set an option that will allow me to click on >>> a tab and drag it either right or left? >>> >> >> No. Moving the GUI tabs (re-ordering) using the mouse is not yet supported. >> >> - Yegappan > > It should be possible to save the current windows (something like the > way ZoomWin does), and open the windows as they are in a new tab page, > and close the old tab (note the order, this works with modified buffers > with 'nohidden' set). Sorry, I have no code that can make this work, > just an idea. Vim 8 - detachable tabs? ;) -- Gerald I'm not sure I got all that right, but I think WinWalker.vim does similar things. I was thinking about the Opera browser and how its tabs can be dragged and placed around with the mouse. Firefox can do the same too, but Opera's drag and drop is more visually stunning. Also, detachable tabs could be flexible enough to even be dragged and attached to another instance of Vim. Just some ideas :) Fancy stuff, nothing we can't do without. -- Gerald
Re: echo question
On 5/14/2006 8:44 AM, Yukihiro Nakadaira wrote: > I think that your 'cmdheight' is 1 and 'showcmd' or 'ruler' is on and > perhaps 'laststatus' is 0 or 1. > How about this > > let ru_save = &ruler > let sc_save = &showcmd > set noruler noshowcmd > echo "]s to skip to word, zg to add word, z= to suggest word" > let &showcmd = sc_save > let &ruler = ru_save I think it was the ruler option that was causing the problem. I still can't figure out why echo would behave differently depending on whether it's called interactively or as part of a function, but by adding the three ruler lines you suggested above I was able to make it work correctly. Thanks! -- Jared
Re: standard distribution of win32 consolve vim
Hari Krishna Dara wrote: On Thu, 11 May 2006 at 9:03am, Bram Moolenaar wrote: Hari Krishna Dara wrote: I observed that the vim7 distribution of console vim for win32 is not compiled with perl and python bindings. This I think is unlike the previous releases when both gvim and vim had the same set of features. Is this a mistake? It has always been like this. Perhaps you got an executable from elsewhere. Right, I seem to have compiled it myself at some point :) When I had Windows (at the moment I don't; I hope it's only temporary even though I prefer Linux) I used to compile Vim with support for all possible interpreters. Of course, to use any interpreter with Vim, it must be installed before compiling on the machine where Vim was compiled, and the same version must be present when using it. (I'm assuming dynamic linking of interpreter libraries.) See my http://users.skynet.be/antoine.mechelynck/vim/compile.htm for a step-by-step "howto" about compililng Vim on Windows. Best regards, Tony.
Re: Is there a way to move tabs around via the mouse?
On Sun, May 14, 2006 at 03:28:23PM -0600, Eric Arnold wrote: > > I've uploaded the patch. It's at proof-of-concept stage. Eric, I noticed you've made a few patches. I especially like the one where you introduced the "GetChar" event. This is a fantastic idea because the "getchar()" function itself is very limiting, disabling normal Vim behavior during its use. Something like this "GetChar" event will allow some extremely powerful plugins to be made. Have you proposed the patch to Bram? --Matt P.S. Maybe a GetCharPre/GetCharPost scheme would be useful, since because of mappings and what not, you might not know what's going to happen when the char is processed. You could use GetCharPost to see what happens after it was processed. Just a thought.
Re: I'm up and running again (sort of)
Mark Woodward wrote: Hi Tony, On Thu, 11 May 2006 18:35:31 +0200 "A.J.Mechelynck" <[EMAIL PROTECTED]> wrote: [...] - It may take some (unspecified) time before I'm satisfied that I can compile Vim for i86 Linux. Piece of cake! I've done it.. oooh 3 or 4 times now ;-) What distro are you using? Maybe someone can throw you some pointers. Required libraries etc You'll probably want to get your laptop back soon though or you might find yourself more than happy with the Penguin and not want to go back!! Happy Vimming! Tony. Now I've done it too, and it's good enough for my own use though I'm not yet ready to release it for public use. I'm on Novell-SuSE 9.3 Professional and here's the "version" listing I got (though I'm soon going to recompile with the latest patches): VIM - Vi IMproved 7.0 (2006 May 7, compiled May 12 2006 04:25:58) Included patches: 1-12 Compiled by [EMAIL PROTECTED] Huge version with GTK2 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: "/usr/local/share/vim" Compilation: gcc -c -I. -Iproto -DHAVE_CONFIG_H -DFEAT_GUI_GTK -DXTHREADS -D_REENTRANT -DXUSE_MTSAFE_API -I/opt/gnome/include/gtk-2.0 -I/opt/gnome/lib/gtk-2.0/include -I/usr/X11R6/include -I/opt/gnome/include/atk-1.0 -I/opt/gnome/include/pango-1.0 -I/usr/include/freetype2 -I/usr/include/freetype2/config -I/opt/gnome/include/glib-2.0 -I/opt/gnome/lib/glib-2.0/include -O2 -fno-strength-reduce -Wall -I/usr/X11R6/include -D_REENTRANT -D_GNU_SOURCE -DTHREADS_HAVE_PIDS -DDEBUGGING -pipe -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -I/usr/lib/perl5/5.8.6/i586-linux-thread-multi/CORE -I/usr/include -D_LARGEFILE64_SOURCE=1 -I/usr/lib/ruby/1.8/i686-linux Linking: gcc -L/opt/gnome/lib -L/usr/X11R6/lib -rdynamic -Wl,-E -Wl,-rpath,/usr/lib/perl5/5.8.6/i586-linux-thread-multi/CORE -L/usr/local/lib -o vim -L/opt/gnome/lib -lgtk-x11-2.0 -lgdk-x11-2.0 -latk-1.0 -lgdk_pixbuf-2.0 -lpangoxft-1.0 -lpangox-1.0 -lpango-1.0 -lgobject-2.0 -lgmodule-2.0 -lglib-2.0 -lXt -lncurses -lgpm -Wl,-E -Wl,-rpath,/usr/lib/perl5/5.8.6/i586-linux-thread-multi/CORE /usr/lib/perl5/5.8.6/i586-linux-thread-multi/auto/DynaLoader/DynaLoader.a -L/usr/lib/perl5/5.8.6/i586-linux-thread-multi/CORE -lperl -lutil -lc -L/usr/lib -ltcl8.4 -lieee -lruby -lm The way I did it was to leave the Makefile unchanged but source (not run) the following bash script before the make (or make reconfig while tweaking the script to eliminate errors): #!/bin/bash export CONF_OPT_PERL='--enable-perlinterp' export CONF_OPT_PYTHON='--enable-pythoninterp' export CONF_OPT_TCL='--enable-tclinterp --with-tcl=tclsh8.4' export CONF_OPT_RUBY='--enable-rubyinterp' export CONF_OPT_MZSCHEME='--enable-mzschemeinterp' export CONF_OPT_CSCOPE='--enable-cscope' export CONF_OPT_MULTIBYTE='--enable-multibyte' export CONF_OPT_OUTPUT='--enable-fontset' export CONF_OPT_FEAT='--with-features=huge' export CONF_OPT_COMPBY='"[EMAIL PROTECTED]"' Best regards, Tony.
Re: Is there a way to move tabs around via the mouse?
On 5/14/06, Gerald Lai <[EMAIL PROTECTED]> wrote: On Sun, 14 May 2006, Eric Arnold wrote: > On 5/9/06, Gerald Lai <[EMAIL PROTECTED]> wrote: >> On Tue, 9 May 2006, Hari Krishna Dara wrote: >> >> > >> > On Tue, 9 May 2006 at 10:29am, Yegappan Lakshmanan wrote: >> > >> >> Hi Scot, >> >> >> >> On 5/9/06, Scot P. Floess <[EMAIL PROTECTED]> wrote: >> >>> Is there anyway to move the tabs in a tabbed window around using the >> >>> mouse? I see the menu options for a tab when I right click on the tab. >> >>> I also saw the tabm [N] option I can set. >> >>> >> >>> However, is it possible to set an option that will allow me to click on >> >>> a tab and drag it either right or left? >> >>> >> >> >> >> No. Moving the GUI tabs (re-ordering) using the mouse is not yet >> supported. >> >> >> >> - Yegappan >> > >> > It should be possible to save the current windows (something like the >> > way ZoomWin does), and open the windows as they are in a new tab page, >> > and close the old tab (note the order, this works with modified buffers >> > with 'nohidden' set). Sorry, I have no code that can make this work, >> > just an idea. >> >> Vim 8 - detachable tabs? ;) >> >> -- >> Gerald > > I'm not sure I got all that right, but I think WinWalker.vim does > similar things. > I was thinking about the Opera browser and how its tabs can be dragged and placed around with the mouse. Firefox can do the same too, but Opera's drag and drop is more visually stunning. The 'mousefunc' patch can move the tabs amongst themselves now. Moving to another Vim will be left for another day :-) Also, detachable tabs could be flexible enough to even be dragged and attached to another instance of Vim. Just some ideas :) Fancy stuff, nothing we can't do without. -- Gerald
Re: Is there a way to move tabs around via the mouse?
On 5/14/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: On Sun, May 14, 2006 at 03:28:23PM -0600, Eric Arnold wrote: > > I've uploaded the patch. It's at proof-of-concept stage. Eric, I noticed you've made a few patches. I especially like the one where you introduced the "GetChar" event. This is a fantastic idea because the "getchar()" function itself is very limiting, disabling normal Vim behavior during its use. Something like this "GetChar" event will allow some extremely powerful plugins to be made. Have you proposed the patch to Bram? I've posted it to the vim-dev group, but I haven't heard from him. Maybe he was too busy to think about it. I don't have a feel for what's it takes to have an enhancement patch accepted, yet. Maybe I'll ask for some conceptual input from him. --Matt P.S. Maybe a GetCharPre/GetCharPost scheme would be useful, since because of mappings and what not, you might not know what's going to happen when the char is processed. You could use GetCharPost to see what happens after it was processed. Just a thought. I'm not sure where I could put the trap that would make sense. Do you have examples in mind? I've added an 'o'=="OP_PENDING" return from mode() which tells you when a char is received in operator-pending mode. I.e. for "cw", "c" would be normal mode, and "w" would be operator-pending. I'm not sure if there's a good way to know ahead of time whether something is going to require additional keystrokes (op-pending) without a comprehensive list of commands and a full scan of all mappings, in the script. As far as I can tell, in the code, by the time you know about op-pending, the processing is well under way, and could be in any of the evaluation branches. There might be a function that says "start_of_op_pending_sequence()", but I can't find it. I'm currently playing around with just keeping an input stack, and seeing if it seems Ok to always be a key or two behind, waiting to see if op-pending keys appear. P.S. Yehaa, I've wrapping tabs now! No more chopped file names :-)
sourcing vimrc files
I'd like to map a hotkey to re-source my vimrc files (system + user). I originally tried this simple approach: nmap :source $VIM\vimrc \ :source $VIM\_vimrc \ :source $HOME\_vimrc But that failed because source aborts when the file doesn't exist. I then modified it to a function call, like so: function! Source_vimrc() if filereadable($VIM.'\vimrc') source $VIM\vimrc endif if filereadable($VIM.'\_vimrc') echo "test1" source $VIM\_vimrc echo "test2" endif if filereadable($HOME.'\_vimrc') source $HOME\_vimrc endif endfunction nmap :call Source_vimrc() Longer and more complicated, but now I can check to see if the file exists before sourcing it. However, this also causes a problem: when I try to source the file containing this function, it gives me an error saying that it cannot replace the function because it is currently in use. If I remove the !, it still gives me an error because it already exists. Any ideas how to work around this? Or if you have a different/better way of doing this, I'm certainly open to suggestions. :-) This is on Windows XP. Thanks. -- Jared
Re: sourcing vimrc files
On 5/14/06, Jared <[EMAIL PROTECTED]> wrote: I'd like to map a hotkey to re-source my vimrc files (system + user). I originally tried this simple approach: nmap :source $VIM\vimrc \ :source $VIM\_vimrc \ :source $HOME\_vimrc Try :silent! source But that failed because source aborts when the file doesn't exist. I then modified it to a function call, like so: function! Source_vimrc() if filereadable($VIM.'\vimrc') source $VIM\vimrc endif if filereadable($VIM.'\_vimrc') echo "test1" source $VIM\_vimrc echo "test2" endif if filereadable($HOME.'\_vimrc') source $HOME\_vimrc endif endfunction nmap :call Source_vimrc() Longer and more complicated, but now I can check to see if the file exists before sourcing it. However, this also causes a problem: when I try to source the file containing this function, it gives me an error saying that it cannot replace the function because it is currently in use. If I remove the !, it still gives me an error because it already exists. You're asking for an inf. recursion having it source itself. Put it in a file in your plugin directory. Any ideas how to work around this? Or if you have a different/better way of doing this, I'm certainly open to suggestions. :-) This is on Windows XP. Thanks. -- Jared
Re: sourcing vimrc files
On Sun, 14 May 2006, Jared wrote: [snip] Longer and more complicated, but now I can check to see if the file exists before sourcing it. However, this also causes a problem: when I try to source the file containing this function, it gives me an error saying that it cannot replace the function because it is currently in use. If I remove the !, it still gives me an error because it already exists. Any ideas how to work around this? Or if you have a different/better way of doing this, I'm certainly open to suggestions. :-) This is on Windows XP. Thanks. Encase your function like this: if !exists("*Source_vimrc") function Source_vimrc() ... endfunction endif The reason you're getting the error is because you're sourcing the file (vimrc) that produced/will override the function (Source_vimrc) you're using at the moment. A few words of advice to source your vimrc cleanly: 1. Define your functions in vimrc with "function!" so that when sourced again, the functions will be overwritten. 2. Keep your autocmds in an augroup so that if it's sourced again, you can delete the augroup and redefine it instead of adding more of the same autocmds. 3. If you're using the FuncUndefined autocmd, delete those functions that have been defined before. For examples 2 & 3, augroup vimrc "delete augroup autocmd! ... silent! delfunction MyFuncInOtherFile autocmd FuncUndefined MyFuncInOtherFile source $HOME/.vim/autoload/MyFuncInOtherFile.vim ... autocmd ... ... augroup END HTH :) -- Gerald
Re: gVim no longer added to Open With...
Donal brewich.com> writes: > > Why is gVim not being added during installation to the list of > programs a file may be associated with? > Additionally, if I use Browse to select gVim MS seems to ignore the > selection and opens .prg files using Visual Foxpro instead of > gvim.exe. I cannot seem to get WinXP to accept the change! I had the same problem. I ran regedit and navigated to this key: HKEY_CLASSES_ROOT\Applications\gvim.exe\shell\open\command It was still pointing at the earlier version of vim. I updated it to point at the vim70 folder instead, and then things worked properly again. Check the edit\command key as well, as long as you're there. gvim appears in the "open with" list now and all is well.