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: Problems with netrw directory listing
Gary Johnson wrote: On 2007-06-03, Seth Mason [EMAIL PROTECTED] wrote: 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. Please try netrw v110g available from my website: http://mysite.verizon.net/astronaut/vim/index.html#NETRW I've tested the fix under Linux; please try it out under XP. Regards, Chip Campbell
Re: Problems with netrw scp
David Rennalls wrote: Hi, I'm having some trouble getting netrw v109(vim 7.1 win WinXP) working with scp. :Nread scp://[EMAIL PROTECTED]:/etc/hosts ..results in the following errors. **warning** (netrw) unable to comply with your requestscp://[EMAIL PROTECTED]:/etc/hosts Enclosing the URL with double quotes makes no difference either. :messages NetrwMessage --No lines in buffer-- Error detected while processing function netrw#NetRead: line 91: E121: Undefined variable: b:netrw_fname E116: Invalid arguments for function s:GetTempfile(b:netrw_fname) apply correct suffix E15: Invalid expression: s:GetTempfile(b:netrw_fname) apply correct suffix line 360: E108: No such variable: b:netrw_fname I get the same error no matter what g:netrw_scp_cmd is set to. There's no command window popping up when the Nread is done so I don't think it's even attempting to run the scp executable (which is pscp in my case). Here's some pointers: * Did you know that you don't need to use :Nread? Just :r ... would be fine. * Drop the second colon from scp://[EMAIL PROTECTED]:/etc/hosts AND I suspect you want /etc/hosts, not /root/etc/hosts (/root generally acts as the home directory for root), so try using: scp://[EMAIL PROTECTED]//etc/hosts * Did you read :help netrw-pscp, :help netrw-p8 for how to set netrw up to use pscp? Regards, Chip Campbell
Re: Problems with netrw scp
On 5/17/07, Charles E Campbell Jr [EMAIL PROTECTED] wrote: Here's some pointers: * Did you know that you don't need to use :Nread? Just :r ... would be fine. no I didn't. Thanks. * Drop the second colon from scp://[EMAIL PROTECTED]:/etc/hosts AND I suspect you want /etc/hosts, not /root/etc/hosts (/root you're right.. I did want /etc/hosts that's why I didn't put ~/etc/hosts (/root/etc/hosts) :) I was thinking of the usual scp path syntax. generally acts as the home directory for root), so try using: scp://[EMAIL PROTECTED]//etc/hosts * Did you read :help netrw-pscp, :help netrw-p8 for how to set netrw up to use pscp? yes, like I said I had set g:netrw_scp_cmd. I missed the lack of a colon in the netrw-ref section though, assuming that the normal scp syntax would work. After getting rid of the colon *and* getting rid of the double-quotes it works (for :r at least). :r doesn't work with the quotes (E32: no file name), :Nread does. Thanks, David
Re: problems with vim
Nageshwar M wrote: Hello, I compiled the vim 7.1 source for unix and installed it in my fedora core 4 pc. When I pressed arrows its printing A,B,C,D's(in insert mode) , backspace is not working and when I pressed delete continuously the gvim is closing down. Someone please help me. The information that vim is showing for :version is Normal version with GTK2 GUI. Features included (+) or not (-): [...] This is usually due to a termcap problem. In which case(s) do you see the problem (among the following)? - in GUI mode (e.g. Alt-F2 then gvim) - in console mode in a terminal displaying through X (and which one: xterm? konsole? gnome-terminal? other[and which one]?) - in the pure text linux console (hit Ctrl-Alt-Fn with n in the range [1..6], log in if necessary, then invoke vim) Best regards, Tony. -- A nymph hits you and steals your virginity.
Re: problems with vim
On 5/15/07, A.J.Mechelynck [EMAIL PROTECTED] wrote: Nageshwar M wrote: Hello, I compiled the vim 7.1 source for unix and installed it in my fedora core 4 pc. When I pressed arrows its printing A,B,C,D's(in insert mode) , backspace is not working and when I pressed delete continuously the gvim is closing down. Someone please help me. The information that vim is showing for :version is Normal version with GTK2 GUI. Features included (+) or not (-): [...] This is usually due to a termcap problem. In which case(s) do you see the problem (among the following)? - in GUI mode (e.g. Alt-F2 then gvim) - in console mode in a terminal displaying through X (and which one: xterm? konsole? gnome-terminal? other[and which one]?) - in the pure text linux console (hit Ctrl-Alt-Fn with n in the range [1..6], log in if necessary, then invoke vim) :set esckeys may also help. nikolai
Re: problems with vim
Hello, I tried in xterm, konsole, and yakuake but got the same problem. I guess the problem is with compilation options... When I used :set esckeys arrow keys working properly but not backspace (in gvim also i faced the same problem). Also the command completion is not working .. i typed :he and pressed tab.. it didn't give me available commands On 5/15/07, A.J.Mechelynck [EMAIL PROTECTED] wrote: Nageshwar M wrote: Hello, I compiled the vim 7.1 source for unix and installed it in my fedora core 4 pc. When I pressed arrows its printing A,B,C,D's(in insert mode) , backspace is not working and when I pressed delete continuously the gvim is closing down. Someone please help me. The information that vim is showing for :version is Normal version with GTK2 GUI. Features included (+) or not (-): [...] This is usually due to a termcap problem. In which case(s) do you see the problem (among the following)? - in GUI mode (e.g. Alt-F2 then gvim) - in console mode in a terminal displaying through X (and which one: xterm? konsole? gnome-terminal? other[and which one]?) - in the pure text linux console (hit Ctrl-Alt-Fn with n in the range [1..6], log in if necessary, then invoke vim) Best regards, Tony. -- A nymph hits you and steals your virginity. -- -- Best Regards, Nageshwar M
Re: problems with vim
Thanks, The problem was sloved by keeping these two lines in .vimrc set backspace=2 set nocompatible Thanks once again.. -- Nageshwar M
Re: problems compiling on solaris
Hi all, On 3/7/07, Paul Stuart [EMAIL PROTECTED] wrote: Hi there, I'm having some problems compiling vim 7 on solaris 8, and I'd really appreciate it if someone could point me in the right direction. Here is the error I'm getting : make[1]: Entering directory `/export/home/pstuart/R42014/src/vim70/src' gcc -c -I. -Iproto -DHAVE_CONFIG_H -DFEAT_GUI_MOTIF -I/usr/dt/include -g -O2 -I/usr/openwin/include-o objects/buffer.o buffer.c In file included from buffer.c:28: vim.h:41: parse error before `:' In file included from /usr/include/stdio.h:22, from os_unix.h:21, from vim.h:233, from buffer.c:28: /usr/include/iso/stdio_iso.h:186: parse error before `__va_list' /usr/include/iso/stdio_iso.h:187: parse error before `__va_list' /usr/include/iso/stdio_iso.h:188: parse error before `__va_list' In file included from os_unix.h:21, from vim.h:233, from buffer.c:28: /usr/include/stdio.h:227: parse error before `__va_list' In file included from /usr/include/wchar.h:11, from /usr/include/wctype.h:20, from vim.h:435, from buffer.c:28: /usr/include/iso/wchar_iso.h:191: parse error before `__va_list' /usr/include/iso/wchar_iso.h:192: parse error before `__va_list' /usr/include/iso/wchar_iso.h:193: parse error before `__va_list' I am also seeing the above build error with the latest Vim7 on Solaris 8. I am able to build successfully on Linux. It looks like some recent changes to the configure script broke this. I was able to compile Vim 7.0.174 successfully on Solaris 8. - Yegappan
Re: problems compiling vim 7 on solaris
Paul Stuart wrote: Hi there, I'm having some trouble compiling vim 7 on solaris 8, and I wonder if someone could point me in the right direction. This is what I see when I compile it : gcc -c -I. -Iproto -DHAVE_CONFIG_H -DFEAT_GUI_MOTIF -I/usr/dt/include -g -O2 -o objects/buffer.o buffer.c In file included from buffer.c:28: vim.h:41: parse error before `:' In file included from /usr/include/stdio.h:22, from os_unix.h:21, from vim.h:233, from buffer.c:28: /usr/include/iso/stdio_iso.h:186: parse error before `__va_list' /usr/include/iso/stdio_iso.h:187: parse error before `__va_list' /usr/include/iso/stdio_iso.h:188: parse error before `__va_list' In file included from os_unix.h:21, from vim.h:233, from buffer.c:28: /usr/include/stdio.h:227: parse error before `__va_list' In file included from /usr/include/wchar.h:11, from /usr/include/wctype.h:20, from vim.h:435, from buffer.c:28: /usr/include/iso/wchar_iso.h:191: parse error before `__va_list' /usr/include/iso/wchar_iso.h:192: parse error before `__va_list' /usr/include/iso/wchar_iso.h:193: parse error before `__va_list' make: *** [objects/buffer.o] Error 1 When I look in the config.log, I can see that there are errors there too, but I really don't know what to do about them. Here's (part of) the config.log. I haven't included all of it, cause it's quite long. This file contains any messages produced by compilers while running configure, to aid debugging if configure makes a mistake. It was created by configure, which was generated by GNU Autoconf 2.59. Invocation command line was $ auto/configure redis --srcdir=. --cache-file=auto/config.cache ## - ## ## Platform. ## ## - ## hostname = openview1 uname -m = sun4u uname -r = 5.8 uname -s = SunOS uname -v = Generic_117350-30 /usr/bin/uname -p = sparc /bin/uname -X = System = SunOS Node = openview1 Release = 5.8 KernelID = Generic_117350-30 Machine = sun4u BusType = unknown Serial = unknown Users = unknown OEM# = 0 Origin# = 1 NumCPU = 2 /bin/arch = sun4 /usr/bin/arch -k = sun4u /usr/convex/getsysinfo = unknown hostinfo = unknown /bin/machine = unknown /usr/bin/oslevel = unknown /bin/universe = unknown PATH: /usr/bin PATH: /bin PATH: /usr/sbin PATH: /sbin PATH: /usr/local/bin PATH: /opt/oracle/product/9.2.0/bin PATH: /usr/contrib/bin PATH: /usr/ccs/bin PATH: /usr/local/bin PATH: /export/home/pstuart/bin ## --- ## ## Core tests. ## ## --- ## configure:1266: creating cache auto/config.cache configure:1353: checking whether make sets $(MAKE) configure:1373: result: yes configure:1391: checking for redis-gcc configure:1420: result: no configure:1429: checking for gcc configure:1445: found /usr/local/bin/gcc configure:1455: result: gcc configure:1699: checking for C compiler version configure:1702: gcc --version /dev/null 5 2.95.3 configure:1705: $? = 0 configure:1707: gcc -v /dev/null 5 Reading specs from /usr/local/lib/gcc-lib/sparc-sun-solaris2.8/2.95.3/specs gcc version 2.95.3 20010315 (release) configure:1710: $? = 0 configure:1712: gcc -V /dev/null 5 gcc: argument to `-V' is missing configure:1715: $? = 1 configure:1738: checking for C compiler default output file name configure:1741: gccconftest.c 5 configure:1744: $? = 0 configure:1790: result: a.out configure:1795: checking whether the C compiler works configure:1801: ./a.out configure:1804: $? = 0 configure:1821: result: yes configure:1828: checking whether we are cross compiling configure:1830: result: no configure:1833: checking for suffix of executables configure:1835: gcc -o conftestconftest.c 5 configure:1838: $? = 0 configure:1863: result: configure:1869: checking for suffix of object files configure:1890: gcc -c conftest.c 5 configure:1893: $? = 0 configure:1915: result: o configure:1919: checking whether we are using the GNU C compiler configure:1943: gcc -c conftest.c 5 configure:1949: $? = 0 configure:1953: test -z || test ! -s conftest.err configure:1956: $? = 0 configure:1959: test -s conftest.o configure:1962: $? = 0 configure:1975: result: yes configure:1981: checking whether gcc accepts -g configure:2002: gcc -c -g conftest.c 5 configure:2008: $? = 0 configure:2012: test -z || test ! -s conftest.err configure:2015: $? = 0 configure:2018: test -s conftest.o configure:2021: $? = 0 configure:2032: result: yes configure:2049: checking for gcc option to accept ANSI C configure:2119: gcc -c -g -O2 conftest.c 5 configure:2125: $? = 0 configure:2129: test -z || test ! -s conftest.err configure:2132: $? = 0 configure:2135: test -s conftest.o configure:2138: $? = 0
Re: problems compiling on solaris
On 3/7/07, A.J.Mechelynck [EMAIL PROTECTED] wrote: The first error mentioned (at vim:h:41) is part of the following: # if (SIZEOF_INT == 0) Error: configure did not run properly. Check auto/config.log. # endif Shouldn't that be: # if (SIZEOF_INT == 0) # error Configure did not run properly. Check auto/config.log. # endif -- Rodolfo Borges
Re: Problems with AutoIndenting comment lines in VHDL files
David le Comte wrote: This is my 2nd attempt, but with smaller sample vhdl file, The mail handler rejected my last email due to its being too large. Problem Description: When editing VHDL files, autoindent mode does not behave as expected with comment lines. I suggest that there is a problem with GetVHDLInsert(). I can not find function with name GetVHDLInsert in my vim source. Maybe you mean GetVHDLindent?. The problem may have something to do with how tabstop and softtabstop are set. Detailed Description: - With tabstop=4, when either opening a new comment line, or continuing in text insert mode from one comment line to the next, the new comment line will autoindent as one expects, ie it will start in-line with the previous comment line, BUT, after typing some text, the line will suddenly re-indent itself, usually a couple of spaces from the beginning of the line. I can not reproduce this behavior. But I can see that indentation is incorrect when tabstop is not 1. Maybe we have different versions of an indent file? I have version 1.36 by Gerald Lai laigera+vim?gmail.com. I can see that there is an updated version - 1.40 on vim.org, but it does not differ in the indentation logic from 1.36. After changing from tabstop=4 to tabstop=8, and setting softabstop=4, a new comment line will autoindent itself a long way in to the right from the previous line. This is purely a guess, but it seems to be treating spaces as though they were tabs? I have attached bugreport.txt as created by bugreport.vim, and also one of my VHDL files. Except for the vim version this bugreport is useless as for me. You shall use bugreport.vim just after you've reproduced the bug. Otherwise it contains rather general information, while your bug is very specific. In any case, automatically generated bug report does not contain script versions, so you shall include them in order to ensure we are on the same page. And the file you have attached it is so huge. Can the bug be reproduced on a small file? One or two lines length. Anyway, I have fixed a bug in my version of a VHDL indent script. Maybe this is the same bug you are experiencing. Please, try it. You should put the attached file into a $HOMEPATH\vimfiles\indent folder. vhdl.vim Description: application/octetstream
Re: problems with vim.org/scripts
Kim Schulz wrote: I just did a search for game in scripts on vim.org, but was returned a site saying: Vim Online Error script: hmmm...strange result_ptr. Did you get here from a vim online link? The link it gave me was: http://www.vim.org/scripts/script_search_results.php?keywords=gamescript_type=order_by=ratingdirection=descendingsearch=search There might be a problem with the site. I broke it and now fixed it. Sorry for the inconvenience! -- hundred-and-one symptoms of being an internet addict: 46. Your wife makes a new rule: The computer cannot come to bed. /// Bram Moolenaar -- [EMAIL PROTECTED] -- http://www.Moolenaar.net \\\ ///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\ \\\download, build and distribute -- http://www.A-A-P.org/// \\\help me help AIDS victims -- http://ICCF-Holland.org///
Re: problems with vim.org/scripts
On Mon, 22 Jan 2007 23:04:14 +0100 Bram Moolenaar [EMAIL PROTECTED] wrote: I broke it and now fixed it. Sorry for the inconvenience! No problem... thanks for the info. -- Kim Schulz| Private : http://www.schulz.dk [EMAIL PROTECTED] | Business: http://www.devteam.dk +45 5190 4262 | Sparetime: http://www.fundanemt.com
Re: Problems with Align.vim
Diwaker Gupta wrote: I'm using Vim 7.0.122 on Debian Unstable. I can send output of :version if needed. I've recently started having problems using Align.vim: Error detected while processing function AlignWrapperStart: line 28: E117: Unknown function: Align#AlignPush I've tried installing the script from both vim.sf.net as well as Dr. Chip's astro-page. Both of them fail with the same error. Infact, when I extract the files from the vimball using ':so %', it generates weird file names: AlignMaps.vim?[[[1 AlignPlugin.vim?[[[1 cecutil.vim?[[[1 As both places mention: you need v18 or later of the vimball plugin: * remove plugin/vimballPlugin.vim from the distribution * remove autoload/vimball.vim from the distribution * install new vimball plugin You then need to extract the files from the Align.vba.gz file. Regards, Chip Campbell
Re: Problems with Align.vim
On Tue, Oct 24, 2006 at 03:29:25PM -0700, Diwaker Gupta wrote: I'm using Vim 7.0.122 on Debian Unstable. I can send output of :version if needed. I've recently started having problems using Align.vim: Error detected while processing function AlignWrapperStart: line 28: E117: Unknown function: Align#AlignPush I've tried installing the script from both vim.sf.net as well as Dr. Chip's astro-page. Both of them fail with the same error. In the future, please give a link, such as http://mysite.verizon.net/astronaut/vim/vbafiles/Align.vba.gz Infact, when I extract the files from the vimball using ':so %', it generates weird file names: AlignMaps.vim?[[[1 AlignPlugin.vim?[[[1 cecutil.vim?[[[1 Any ideas? Thanks in advance, Diwaker There are a few problems here. First, it is too easy to miss the warning BE SURE TO GET THE LATEST VIMBALL PLUGIN BEFORE ATTEMPTING TO USE SCRIPTS UPLOADED ON OR AFTER AUG 1, 2006 posted on http://mysite.verizon.net/astronaut/vim/index.html . Ideally, all links to recent plugins would redirect to a page line http://mysite.verizon.net/astronaut/vim/newvimball.html?file=Align.vba.gz and this page would give links to the new version of vimball and the desired plugin. Second, the link to the new version of vimball is broken: http://mysite.verizon.net/astronaut/vim/tarfiles/vimball.vba.gz This does work: http://mysite.verizon.net/astronaut/vim/tarfiles/vimball.tar.gz The point is that the newest version cannot be extracted by the older version, so it is distributed as a tarball instead of a vimball. You can also get the new version of vimball from http://www.vim.org/scripts/script.php?script_id=1502 . The installation instructions there do not mention that the latest version should be extracted using tar. When installing vimball, do it in your $VIMRUNTIME directory. (For me, this means /usr/local/share/vim/vim70 , and I need to use su or sudo to install.) There may be an even newer version distributed with vim 7.1 or later, and you do not want this version in your personal runtime directory to be used when you upgrade. Third problem. This may have been my fault, but when I installed the vimball plugin, with $ cd /usr/local/share/vim/vim70 $ sudo tar xzf path/to/vimball.tar.gz some of the files had the wrong permissions, so I had to fix it with $ sudo chmod a+r autoload/vimball.vim doc/pi_vimball.txt plugin/vimballPlugin.vim Like you, I had some wrong files installed at this point. I cleaned up with $ cd ~/.vim $ rm -i */*[[[* HTH --Benji Fisher
Re: Problems with Align.vim
Benji Fisher wrote: There are a few problems here. First, it is too easy to miss the warning BE SURE TO GET THE LATEST VIMBALL PLUGIN BEFORE ATTEMPTING TO USE SCRIPTS UPLOADED ON OR AFTER AUG 1, 2006 posted on http://mysite.verizon.net/astronaut/vim/index.html . Ideally, all links to recent plugins would redirect to a page line... Every entry under the #VimFuncs label now has a sentence directing folks to the vimball entry, where improved directions for extracting it may be found. I've also fixed up several links and labels. Thank you for the feedback! As you may guess, I seldom download files and extract 'em from my own website... Regards, Chip Campbell
Re: Problems with
Max Dyckhoff wrote: For some reason, using to indent a line of code no longer works correctly! Repro steps: 1. Press 2. Observe appear in the command line where pending commands live 3. Watch nothing happen 4. Press another key (esc, a, whatever) and watch the indent happen 5. It looks like the is waiting for something else! Also in visual mode: 1. Visual select two lines 2. Press 3. Observe two lines indent correctly 4. Observer first line indent AGAIN 5. Cry gently I have no idea what's going on, and I can't work out how to find what could be waiting for . Can anyone help me please? Thanks in advance! Max -- Max Dyckhoff AI Engineer Bungie Studios It sounds like something starting with has been mapped to something else. Does Vim (version 7) answer anything to :verbose map ? Best regards, Tony.
Re: Problems with
On 10/20/06, Max Dyckhoff [EMAIL PROTECTED] wrote: For some reason, using to indent a line of code no longer works correctly! Repro steps: 1. Press 2. Observe appear in the command line where pending commands live 3. Watch nothing happen 4. Press another key (esc, a, whatever) and watch the indent happen 5. It looks like the is waiting for something else! Also in visual mode: 1. Visual select two lines 2. Press 3. Observe two lines indent correctly 4. Observer first line indent AGAIN 5. Cry gently Do you have mapping for ?? Try :map Yakov
RE: Problems with
Re-including the list. I only have about 30 maps, and none of them start with . The only thing that I can see which might be affecting anything are these two: ,,b :%s/\(^\t*\):/\1/ecr:%s/\(^\t*\) /\1: /ecr:let @/=cr ,,B :%s/\(^\t*\):/\1/ecr:let @/=cr Now ,, is the localleader for vo_base, the vimoutliner plugin. This is in a C file, so it looks like the mappings have leaked over from a different buffer in a different tab. I recently saved a session, quit and sourced that session; perhaps something exploded then? HAH. I just realised that the mapping in vo_base.vim ISN'T buffer. I shall make them buffer and see if that fixes it :) Still, why would trigger ,,? And yes, I know that is shift-, :) Max -Original Message- From: David Thompson [mailto:[EMAIL PROTECTED] Sent: Friday, October 20, 2006 11:28 AM To: Max Dyckhoff Subject: Re: Problems with interesting, probably some kind of map is interfering what does this show? :verbose map otherwise try using :map and look for map definitions where is the prefix of some 3+ letter mapping. also what does this show? :echo mapleader --- Max Dyckhoff [EMAIL PROTECTED] wrote: For some reason, using to indent a line of code no longer works correctly! Repro steps: 1. Press 2. Observe appear in the command line where pending commands live 3. Watch nothing happen 4. Press another key (esc, a, whatever) and watch the indent happen 5. It looks like the is waiting for something else! Also in visual mode: 1. Visual select two lines 2. Press 3. Observe two lines indent correctly 4. Observer first line indent AGAIN 5. Cry gently I have no idea what's going on, and I can't work out how to find what could be waiting for . Can anyone help me please? Thanks in advance! Max -- Max Dyckhoff AI Engineer Bungie Studios __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Re: Problems with
Max Dyckhoff wrote: Re-including the list. I only have about 30 maps, and none of them start with . The only thing that I can see which might be affecting anything are these two: ,,b :%s/\(^\t*\):/\1/ecr:%s/\(^\t*\) /\1: /ecr:let @/=cr ,,B :%s/\(^\t*\):/\1/ecr:let @/=cr Now ,, is the localleader for vo_base, the vimoutliner plugin. This is in a C file, so it looks like the mappings have leaked over from a different buffer in a different tab. I recently saved a session, quit and sourced that session; perhaps something exploded then? HAH. I just realised that the mapping in vo_base.vim ISN'T buffer. I shall make them buffer and see if that fixes it :) Still, why would trigger ,,? And yes, I know that is shift-, :) Did you ever try :verbose map and see what popped up? Also, IMHO, plugins should not be setting the localleader; that's inherently a user's choice as to what s/he prefers. In other words, the map should be map LocalLeaderb ... map LocalLeaderB ... Regards, Chip Campbell
RE: Problems with
Hi all, :verbose map shows nothing. I have no mappings with at the start (or in fact, anywhere in the mapping). Removing the two ,, mappings did nothing useful. The only interesting map that I have is one right at the end of the list which is some non-printing character duplicating another mapping I have for C-S-+. I have no idea how to identify this character. I agree that plugins shouldn't set the localleader, but in fairness I don't ever use the local leader for anything other than the vimoutliner plugin so I'm not too worried. Any more ideas as to what I could try? Cheers, Max -Original Message- From: Charles E Campbell Jr [mailto:[EMAIL PROTECTED] Sent: Friday, October 20, 2006 12:11 PM To: Max Dyckhoff Cc: vim@vim.org Subject: Re: Problems with Max Dyckhoff wrote: Re-including the list. I only have about 30 maps, and none of them start with . The only thing that I can see which might be affecting anything are these two: ,,b :%s/\(^\t*\):/\1/ecr:%s/\(^\t*\) /\1: /ecr:let @/=cr ,,B :%s/\(^\t*\):/\1/ecr:let @/=cr Now ,, is the localleader for vo_base, the vimoutliner plugin. This is in a C file, so it looks like the mappings have leaked over from a different buffer in a different tab. I recently saved a session, quit and sourced that session; perhaps something exploded then? HAH. I just realised that the mapping in vo_base.vim ISN'T buffer. I shall make them buffer and see if that fixes it :) Still, why would trigger ,,? And yes, I know that is shift-, :) Did you ever try :verbose map and see what popped up? Also, IMHO, plugins should not be setting the localleader; that's inherently a user's choice as to what s/he prefers. In other words, the map should be map LocalLeaderb ... map LocalLeaderB ... Regards, Chip Campbell
Re: Problems with
On 10/20/06, Max Dyckhoff [EMAIL PROTECTED] wrote: Hi all, :verbose map shows nothing. I have no mappings with at the start (or in fact, anywhere in the mapping). Removing the two ,, mappings did nothing useful. The only interesting map that I have is one right at the end of the list which is some non-printing character duplicating another mapping I have for C-S-+. I have no idea how to identify this character. I agree that plugins shouldn't set the localleader, but in fairness I don't ever use the local leader for anything other than the vimoutliner plugin so I'm not too worried. Any more ideas as to what I could try? 1. Try with 'vim --noplugin' 2. If works, then disable plugins one-by-one to find offending plugin. 3. if still doesn't work, then attach your complete vimrc so others can repro it, and chase the culprit. What's your OS and vim version ? Maybe you posted it already, but I don't see it in the thread. Yakov
Re: Problems with
On 2006-10-20, Max Dyckhoff [EMAIL PROTECTED] wrote: Hi all, :verbose map shows nothing. I have no mappings with at the start (or in fact, anywhere in the mapping). Removing the two ,, mappings did nothing useful. The only interesting map that I have is one right at the end of the list which is some non-printing character duplicating another mapping I have for C-S-+. I have no idea how to identify this character. I agree that plugins shouldn't set the localleader, but in fairness I don't ever use the local leader for anything other than the vimoutliner plugin so I'm not too worried. Any more ideas as to what I could try? You could try determining which plugin is causing the problem. 1. Choose a file that you've been editing when you've seen the problem and start vim as you normally would, e.g., vim somefile, and verify that you see the problem. 2. Using the same file, start vim as vim -N -u NONE somefile and verify that you don't see the problem. 3. Start vim as vim --noplugin somefile and see if you see the problem. (You may have to comment-out any filetype lines in your .vimrc as well.) If you do see the problem, the cause is in your .vimrc; otherwise, the problem is in a plugin. The best strategy for tracking down the problematic plugin depends on how many private plugins you have and of which kinds. I would start by turning off all filetype detection in your .vimrc so that only ordinary plugins are loaded, then try vim somefile and see what happens. If you still see the problem, then I would rename half the files in your ~/.vim/plugin directory with a dummy extension (.hide?) and repeat the experiment, doing a binary search on the file sets until you narrow it down to the problematic plugin. You can use the :scriptnames command during this process to see which plugins are actually being sourced. HTH, Gary -- Gary Johnson | Agilent Technologies [EMAIL PROTECTED] | Wireless Division | Spokane, Washington, USA
RE: Problems with
Hi Gary, and Yakov, I'm sorry, I'm feeling terrible today so my bug reports aren't very comprehensive. More information! WinXP, GVIM 7.0 compiled by Bram. I don't have many plugins, the major ones being Lookupfile and associated plugins and vimoutliner. I seriously suspect vimoutliner is the culprit. But that is actually only half of the story. The bad mapping doesn't exist in a clean vim, even with all my plugins running, it only exists in the current session of vim that I am using. I run vim with 7 tabs open, each containing at least two files. I have three tabs full of .cpp files that I am working on, a tab with some AI scripting files, a tab with some HTML docs that I am writing, a tab with some init files, a tab with my .vimrc and a tab with my todo.otl file for vimoutliner. When I reboot I do a :mksession ~/work_session.vim, and when I come back I :so ~/work_session.vim so I can continue where I left off. This saves me loads of time reopening the 20 or so C files that I am working on at any one time, as well as all the various supporting files listed above. This session has been around for a few weeks, and I keep :mksession-ing and :so-ing it. When I :so it I get an error in one of my HTML docs, but it doesn't seem to fail so I'm not worrying. Do you think the session is somehow corrupted? It happens if I make the session again cleanly (open all the files in a new vim session, :mksession, :so session, observe strange behaviour), so just trashing the session and starting again isn't really an option, as the problem will come back within a couple of days. Max -Original Message- From: Gary Johnson [mailto:[EMAIL PROTECTED] Sent: Friday, October 20, 2006 2:01 PM To: vim@vim.org Subject: Re: Problems with On 2006-10-20, Max Dyckhoff [EMAIL PROTECTED] wrote: Hi all, :verbose map shows nothing. I have no mappings with at the start (or in fact, anywhere in the mapping). Removing the two ,, mappings did nothing useful. The only interesting map that I have is one right at the end of the list which is some non-printing character duplicating another mapping I have for C-S-+. I have no idea how to identify this character. I agree that plugins shouldn't set the localleader, but in fairness I don't ever use the local leader for anything other than the vimoutliner plugin so I'm not too worried. Any more ideas as to what I could try? You could try determining which plugin is causing the problem. 1. Choose a file that you've been editing when you've seen the problem and start vim as you normally would, e.g., vim somefile, and verify that you see the problem. 2. Using the same file, start vim as vim -N -u NONE somefile and verify that you don't see the problem. 3. Start vim as vim --noplugin somefile and see if you see the problem. (You may have to comment-out any filetype lines in your .vimrc as well.) If you do see the problem, the cause is in your .vimrc; otherwise, the problem is in a plugin. The best strategy for tracking down the problematic plugin depends on how many private plugins you have and of which kinds. I would start by turning off all filetype detection in your .vimrc so that only ordinary plugins are loaded, then try vim somefile and see what happens. If you still see the problem, then I would rename half the files in your ~/.vim/plugin directory with a dummy extension (.hide?) and repeat the experiment, doing a binary search on the file sets until you narrow it down to the problematic plugin. You can use the :scriptnames command during this process to see which plugins are actually being sourced. HTH, Gary -- Gary Johnson | Agilent Technologies [EMAIL PROTECTED] | Wireless Division | Spokane, Washington, USA
Re: Problems with
On 2006-10-20, Max Dyckhoff [EMAIL PROTECTED] wrote: Hi Gary, and Yakov, I'm sorry, I'm feeling terrible today so my bug reports aren't very comprehensive. More information! WinXP, GVIM 7.0 compiled by Bram. I don't have many plugins, the major ones being Lookupfile and associated plugins and vimoutliner. I seriously suspect vimoutliner is the culprit. But that is actually only half of the story. The bad mapping doesn't exist in a clean vim, even with all my plugins running, it only exists in the current session of vim that I am using. I run vim with 7 tabs open, each containing at least two files. I have three tabs full of .cpp files that I am working on, a tab with some AI scripting files, a tab with some HTML docs that I am writing, a tab with some init files, a tab with my .vimrc and a tab with my todo.otl file for vimoutliner. When I reboot I do a :mksession ~/work_session.vim, and when I come back I :so ~/work_session.vim so I can continue where I left off. This saves me loads of time reopening the 20 or so C files that I am working on at any one time, as well as all the various supporting files listed above. This session has been around for a few weeks, and I keep :mksession-ing and :so-ing it. When I :so it I get an error in one of my HTML docs, but it doesn't seem to fail so I'm not worrying. Do you think the session is somehow corrupted? It happens if I make the session again cleanly (open all the files in a new vim session, :mksession, :so session, observe strange behaviour), so just trashing the session and starting again isn't really an option, as the problem will come back within a couple of days. If you can do everything up through :mksession without observing the problem, then :so session and observe the problem, then you've narrowed it down to something funny happening during the :so session operation. As for the error in one of your HTML docs, that may be another manifestation of this problem. When you observe an error and you don't know what it's caused by, it is very difficult to say for sure what the error has and has not affected. Posting the error message here may give someone an idea of what could be happening. Another idea would be open the session file and look around, perhaps searching for . Still another idea would be to look at :help bugreport and generate a bugreport.txt file as described there, then search that file for . You could also create a bugreport.txt file at the last possible moment before the onset of this problem, then create another bugreport.txt file after the problem appears, then diff the two. Gary -- Gary Johnson | Agilent Technologies [EMAIL PROTECTED] | Wireless Division | Spokane, Washington, USA
RE: Problems with
Hi Gary, Thanks for the tip. I actually dived in and opened up the session file and compared it to an identically generated (same files and everything) session file which didn't exhibit the problem. There were no occurrences of in the session file, however I did find these lines which for whatever reason were not being displayed in :map map ^VC-« :call ChangeFontSize(up) map ^VC- :call ChangeFontSize(down) map ^VC-ª :call ChangeFontSize() Now these are duplicates of the following: map C-S-kPlus :call ChangeFontSize(up)CR map C-S-kMinus:call ChangeFontSize(down)CR map C-S-kMultiply :call ChangeFontSize()CR Removing the offending mappings fixed which now works as expected. My only worry is how these were generated in the first place, and if they will come back. I shall keep the list informed if I can find anything else useful. Thanks for everyone's suggestions and help! Max -Original Message- From: Gary Johnson [mailto:[EMAIL PROTECTED] Sent: Friday, October 20, 2006 3:22 PM To: vim@vim.org Subject: Re: Problems with On 2006-10-20, Max Dyckhoff [EMAIL PROTECTED] wrote: Hi Gary, and Yakov, I'm sorry, I'm feeling terrible today so my bug reports aren't very comprehensive. More information! WinXP, GVIM 7.0 compiled by Bram. I don't have many plugins, the major ones being Lookupfile and associated plugins and vimoutliner. I seriously suspect vimoutliner is the culprit. But that is actually only half of the story. The bad mapping doesn't exist in a clean vim, even with all my plugins running, it only exists in the current session of vim that I am using. I run vim with 7 tabs open, each containing at least two files. I have three tabs full of .cpp files that I am working on, a tab with some AI scripting files, a tab with some HTML docs that I am writing, a tab with some init files, a tab with my .vimrc and a tab with my todo.otl file for vimoutliner. When I reboot I do a :mksession ~/work_session.vim, and when I come back I :so ~/work_session.vim so I can continue where I left off. This saves me loads of time reopening the 20 or so C files that I am working on at any one time, as well as all the various supporting files listed above. This session has been around for a few weeks, and I keep :mksession-ing and :so-ing it. When I :so it I get an error in one of my HTML docs, but it doesn't seem to fail so I'm not worrying. Do you think the session is somehow corrupted? It happens if I make the session again cleanly (open all the files in a new vim session, :mksession, :so session, observe strange behaviour), so just trashing the session and starting again isn't really an option, as the problem will come back within a couple of days. If you can do everything up through :mksession without observing the problem, then :so session and observe the problem, then you've narrowed it down to something funny happening during the :so session operation. As for the error in one of your HTML docs, that may be another manifestation of this problem. When you observe an error and you don't know what it's caused by, it is very difficult to say for sure what the error has and has not affected. Posting the error message here may give someone an idea of what could be happening. Another idea would be open the session file and look around, perhaps searching for . Still another idea would be to look at :help bugreport and generate a bugreport.txt file as described there, then search that file for . You could also create a bugreport.txt file at the last possible moment before the onset of this problem, then create another bugreport.txt file after the problem appears, then diff the two. Gary -- Gary Johnson | Agilent Technologies [EMAIL PROTECTED] | Wireless Division | Spokane, Washington, USA
Re: Problems with configure after patch 123
Bram Moolenaar wrote: Tony Mechelynck wrote: At patchlevel 125 (123-124-125 newly patched), make reconfig and make distclean both fail as follows (beware of mailer beautification: all lines from GUI_INC_LOC= (included) to --enable-mzschemeinterp (excluded) end in a backslash): Starting make in the src directory. If there are problems, cd to the src directory and run make there I don't know how you start this, but you apparently didn't do make distclean in the src directory. I invoked it in the top directory, and the only rule it executed there was cd src $(MAKE) $@ No variables set at that point. It's possible that when the timestamp of src/auto/configure changes the scripts get confused a bit. The current autoconf implementation isn't very user friendly when it comes to patching. I don't think I can do anything to avoid this. make distclean works fine for me and doesn't run configure first. It works fine for me too, _except_ when the configure source files have just been patched (as by patch 7.0.123) and the configure output files are older. I suspect the configure run happens because make distclean is trying to make the auto/config.mk which is to be included at line 289 of src/Makefile (note: make is a two-pass process). I suggest the distclean target rules (at least) be moved to the top Makefile in order to avoid including config.mk when making that target. The place of the include should not matter. The Makefile is first read completely before dependencies are followed. distclean does not depend on auto/config.mk. Perhaps your make program implies this dependency when including a file? I would call that a bug (some might call it a feature...). I'm using GNU make, version 3.80. From info make, under Include, I read the following (about two-thirds of the way down): [...] Once it has finished reading makefiles, `make' will try to remake any that are out of date or don't exist. *Note How Makefiles Are Remade: Remaking Makefiles. Only after it has tried to find a way to remake a makefile and failed, will `make' diagnose the missing makefile as a fatal error. [...] In this case, since there is a rule to make auto/config.mk, with auto/configure, config.mk.in and config.h.in as prerequisites, and one or more of the latter are newer than the included file config.mk, the latter is an out-of-date makefile and make tries to remake it -- by running configure. IOW this is a documented feature of GNU make. Since the include is in src/Makefile and not in vim70/Makefile, by placing the distclean rule in the latter (explicitly, not as a call to src/Makefile) we would avoid the include altogether, and thus the check on whether the included makefile is out of date. Best regards, Tony.
Re: Problems with configure after patch 123
Tony Mechelynck wrote: The place of the include should not matter. The Makefile is first read completely before dependencies are followed. distclean does not depend on auto/config.mk. Perhaps your make program implies this dependency when including a file? I would call that a bug (some might call it a feature...). I'm using GNU make, version 3.80. From info make, under Include, I read the following (about two-thirds of the way down): [...] Once it has finished reading makefiles, `make' will try to remake any that are out of date or don't exist. *Note How Makefiles Are Remade: Remaking Makefiles. Only after it has tried to find a way to remake a makefile and failed, will `make' diagnose the missing makefile as a fatal error. [...] In this case, since there is a rule to make auto/config.mk, with auto/configure, config.mk.in and config.h.in as prerequisites, and one or more of the latter are newer than the included file config.mk, the latter is an out-of-date makefile and make tries to remake it -- by running configure. IOW this is a documented feature of GNU make. But I don't want to update auto/config.mk. I can understand that it's build when it does not exist, otherwise the only alternative is giving an error message and die. But when it exists it should be used as-is. I would rather call this a bug than a feature, I didn't specify the file should be updated. Isn't there a way to disable this feature? Since the include is in src/Makefile and not in vim70/Makefile, by placing the distclean rule in the latter (explicitly, not as a call to src/Makefile) we would avoid the include altogether, and thus the check on whether the included makefile is out of date. make distclean should work in the src directory, like everything else. -- The startling truth finally became apparent, and it was this: Numbers written on restaurant checks within the confines of restaurants do not follow the same mathematical laws as numbers written on any other pieces of paper in any other parts of the Universe. This single statement took the scientific world by storm. So many mathematical conferences got held in such good restaurants that many of the finest minds of a generation died of obesity and heart failure, and the science of mathematics was put back by years. -- Douglas Adams, The Hitchhiker's Guide to the Galaxy /// Bram Moolenaar -- [EMAIL PROTECTED] -- http://www.Moolenaar.net \\\ ///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\ \\\download, build and distribute -- http://www.A-A-P.org/// \\\help me help AIDS victims -- http://ICCF-Holland.org///
Re: Problems with configure after patch 123
Bram Moolenaar wrote: Tony Mechelynck wrote: The place of the include should not matter. The Makefile is first read completely before dependencies are followed. distclean does not depend on auto/config.mk. Perhaps your make program implies this dependency when including a file? I would call that a bug (some might call it a feature...). I'm using GNU make, version 3.80. From info make, under Include, I read the following (about two-thirds of the way down): [...] Once it has finished reading makefiles, `make' will try to remake any that are out of date or don't exist. *Note How Makefiles Are Remade: Remaking Makefiles. Only after it has tried to find a way to remake a makefile and failed, will `make' diagnose the missing makefile as a fatal error. [...] In this case, since there is a rule to make auto/config.mk, with auto/configure, config.mk.in and config.h.in as prerequisites, and one or more of the latter are newer than the included file config.mk, the latter is an out-of-date makefile and make tries to remake it -- by running configure. IOW this is a documented feature of GNU make. But I don't want to update auto/config.mk. I can understand that it's build when it does not exist, otherwise the only alternative is giving an error message and die. But when it exists it should be used as-is. I would rather call this a bug than a feature, I didn't specify the file should be updated. Isn't there a way to disable this feature? [...] Apparently the make philosophy is that one wants to use the most up-to-date makefiles possible. I'm not sure I understand fully from the make info text if and how you can avoid to remake an existing makefile if it's present but out-of-date. One method would of course be to drop the make rules for config.mk -- but what would happen when doing make the first time without a target? Another possibility would be to touch the config.mk file to make it newer than the rest -- but is it possible to do that other than manually? It says in the info text for make that a makefile target with two colons and no prerequisites will never be remade to avoid an endless loop (unlike a non-makefile target with two colons and no prerequisites, which is remade unconditionally IIUC). But double-colon rules are somewhat esoteric and I'm not sure whether this property is usable. Best regards, Tony.
Re: problems with containedin=
On 6/28/06, Mojca Miklavec [EMAIL PROTECTED] wrote: \startpublication \author % highlited differently ... \stoppublication \author % highlited just as every other command. syn match contextBibField '\\\(artauthor\|author\|editor\)\' display containedin=contextBib syn region contextBib transparent start='\\startpublication\' skip='%.*stoppublication' end='\\stoppublication\' keepend contains=TOP hi def link contextBibField Special But now \author outside of \startpublication ... \stoppublication is also highlited as Special, while it should remain the old hyghligting. How can I fix that? Your problem is that you're missing option 'contained' in the first 'syn' command. This syn command line shall be: syn match contextBibField '\\\(artauthor\|author\|editor\)\' display containedin=contextBib contained This fixes your problem. You're missing the option 'contained'. Yakov
Re: problems with containedin=
On 6/29/06, Yakov Lerner wrote: On 6/28/06, Mojca Miklavec wrote: \startpublication \author % highlited differently ... \stoppublication \author % highlited just as every other command. syn match contextBibField '\\\(artauthor\|author\|editor\)\' display containedin=contextBib syn region contextBib transparent start='\\startpublication\' skip='%.*stoppublication' end='\\stoppublication\' keepend contains=TOP hi def link contextBibField Special But now \author outside of \startpublication ... \stoppublication is also highlited as Special, while it should remain the old hyghligting. How can I fix that? Your problem is that you're missing option 'contained' in the first 'syn' command. This syn command line shall be: syn match contextBibField '\\\(artauthor\|author\|editor\)\' display containedin=contextBib contained This fixes your problem. You're missing the option 'contained'. Thank you a lot! That one solved it. I thought that containedin implied contained automatically (now I see that it does make sense to have two separate keywords and after rereading the documentation carefully I also see how stupid I was because that case was clearly explained). I'm sorry for that and thank you a lot for taking your time to look into it, Mojca Miklavec
Re: Problems Closing The Quickfix Window
I forgot to mention that I also tested this in vim with the following vim version and got the same results: VIM - Vi IMproved 6.4 (2005 Oct 15, compiled Feb 12 2006 15:22:23) Included patches: 1-7
Re: Problems Closing The Quickfix Window
On 4/17/06, Tom Purl [EMAIL PROTECTED] wrote: os - Linux vim - VIM - Vi IMproved 7.0d02 BETA ant_menu - 0.5.4 I'm a bit of a newbie when it comes to quickfix, so any help you can give me would be greatly appreciated. I'm using vim with the ant_menu plugin, which integrates the Apache Ant tool with vim. Basically, by using the ,ttarget key combo, I can execute a build.xml file and have its output redirected to a quickfix window at the bottom of my screen. So after executing the plugin, the screen is split into two, with the quickfix screen at the bottom. Naturally, if there's a problem uncovered by ant, I would like to close the quickfix window so I can devote all of my screen to a single vim window containing my code. The problem is that I can't. If I move the cursor out of the quickfix window (it's in there by default after executing ant_menu), then I can't put it back in there. It's as if VI doesn't know that the quickfix window exists. Please note that I am *not* asking how to move my cursor from window to window; I know how to do that. I just can't move it into the quickfix window after moving it out. Well, naturally, if I can't navigate to the quickfix window, then I can't close it. Is this normal for quickfix? Is there some other command that I should use to navigate to the window? Is there some quickfix-only command for closing the window? If you have only one non-quickfix window open, how about :on! command issued while you are in the non-quickfix window ? :on! See :he :only Yakov
