Re: Time to remove naming restrictions?
On 10/4/06, Peter Hodge [EMAIL PROTECTED] wrote: There's about 4 lines of vim source code which you need to remove so that you can have lower-case user commands. You're not interested in making your own patch? Seeing as you've identified the location and apparent fix, why not you? Anyway, I felt there was no need to provide a patch before a we had discussion on the merit (or acceptance) of such a patch. nikolai
Re: compilation of regular expressions/ enhancement?
On 10/4/06, Peter Hodge [EMAIL PROTECTED] wrote: --- Nikolai Weibull [EMAIL PROTECTED] wrote: On 10/3/06, Marc Weber [EMAIL PROTECTED] wrote: parsed, it's just executed line-by-line. What /would/ make sense is to cache the compiled regexes so that regexes used in a loop won't have to be compiled as often. That's a fairly trivial fix, although I'm not going to perform it. Great idea, Nikolei! ^- gaah! nikolai iabbrev Nikolei Nikolai match Error /Nikol[^a]i/ I'd extended to match Error /\Ni[^k]ol[^a][^i]\/ You'd be surprised how often people come up with their very own spelling of my name. nikolai
Re: compilation of regular expressions/ enhancement?
--- Nikolai Weibull [EMAIL PROTECTED] wrote: On 10/4/06, Peter Hodge [EMAIL PROTECTED] wrote: --- Nikolai Weibull [EMAIL PROTECTED] wrote: Great idea, Nikolei! ^- gaah! nikolai iabbrev Nikolei Nikolai match Error /Nikol[^a]i/ I'd extended to match Error /\Ni[^k]ol[^a][^i]\/ You'd be surprised how often people come up with their very own spelling of my name. It's alright, once your name has been out there for a couple thousand years (like mine), people will start getting it right more often. - Peter On Yahoo!7 Fuel Price Watch: Find the cheapest petrol in your area http://au.maps.yahoo.com/fuelwatch/
Re: Time to remove naming restrictions?
Seeing as you've identified the location and apparent fix, why not you? Because I don't want to maintain my own set of patches, that would be more tiring than using upper-case commands. On Yahoo!7 Messenger - IM with Windows Live Messenger friends. http://au.messenger.yahoo.com
Re: compilation of regular expressions/ enhancement?
Nikolai Weibull wrote: match Error /\Ni[^k]ol[^a][^i]\/ But that will only matches entries that mispell all three letters. You probably want something like: match Error /\Ni[^k]ol..\/ match Error /\Ni.ol[^a].\/ match Error /\Ni.ol.[^i]\/ David Brown
Re: compilation of regular expressions/ enhancement?
On 10/4/06, Peter Hodge [EMAIL PROTECTED] wrote: --- Nikolai Weibull [EMAIL PROTECTED] wrote: On 10/4/06, Peter Hodge [EMAIL PROTECTED] wrote: --- Nikolai Weibull [EMAIL PROTECTED] wrote: Great idea, Nikolei! ^- gaah! nikolai iabbrev Nikolei Nikolai match Error /Nikol[^a]i/ I'd extended to match Error /\Ni[^k]ol[^a][^i]\/ You'd be surprised how often people come up with their very own spelling of my name. It's alright, once your name has been out there for a couple thousand years (like mine), people will start getting it right more often. Given that both names are Greek in origin, I wouldn't say that either has been around longer than the other, see, for example: http://en.wikipedia.org/wiki/Nikolai http://en.wikipedia.org/wiki/Peter_%28name%29 nikolai
Missing CursorHold after return from insert to normal ?
CursorHold is suppsed to be triggered in normal mode after updatetime, correct ? But in the scenario below, when vim gets into normal mode after insert mode, CursorHold is not triggered: 1. vim -u NONE -U NONE 2. :let x=0 3. :let ut=200 just some low value 3. :au CursorHold * let x=x+1 | echo x 4. C-EC-EC-E -- watch CursorHold working 5. iiesc wait there's not CursorHold iiesc wait there's not CursorHold iiesc wait there's not CursorHold Why ? Bug or feature ? Yakov
Re: Patch 7.0.118
Nikolai Weibull wrote: On 10/3/06, Bram Moolenaar [EMAIL PROTECTED] wrote: Problem:printf() does not do zero padding for strings. Just a quick question: Wasn't printf a bit of a misnomer? Why? formattedprinting() would be a bit long, thus using the C library name sounds logical to me. It's too late to change anyway. -- The process for understanding customers primarily involves sitting around with other marketing people and talking about what you would to if you were dumb enough to be a customer. (Scott Adams - The Dilbert principle) /// 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: Patch 7.0.111
Fan Decheng wrote: Bram Moolenaar wrote: Patch 7.0.111 Problem:The gzip plugin can't handle filenames with single quotes. Solution: Add and use the shellescape() function. (partly by Alexey Froloff) Files: runtime/autoload/gzip.vim, runtime/doc/eval.txt, src/eval.c, src/mbyte.c, src/misc2.c, src/proto/misc2.pro [...] I wonder whether it is possible to use execv() instead of escaping the command and then sending it to the shell. How do you think? Vim doesn't have an execv() function. Implementing this properly for all systems isn't that simple. At least you would need to take care of $PATH. -- For society, it's probably a good thing that engineers value function over appearance. For example, you wouldn't want engineers to build nuclear power plants that only _look_ like they would keep all the radiation inside. (Scott Adams - The Dilbert principle) /// 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: [macvim] modifiers should be applied to special keys too (patch)
Nicolas - I tried the patch, but it appears that CTRL-F and CTRL-B no longer work in Normal mode. They do something in Insert mode after CTRL-V. CTRL-F and CTRL-B work for me in Normal mode (they scroll forward/ backward). I'm using mac gvim svn (patches 1-110) and the second version of my patch. Can you give more detailed instructions on how to reproduce the problem? I verified I had used your second patch and found a difference. CTRL-F and CTRL-B are working now. It looks like this patch needs more careful testing. Perhaps you should make a list of keys with various modifiers that need to be tried to verify the code works correctly. I made a small list ( http://macvim.blogspot.com/2006/10/keyboard- handling-patch.html ), I'll add further items as problems arise. Here is one key that doesn't work for me: Shift-Tab. Most notably when doing command line completion, where Tab gets the next match and Shift-Tab goes to the previous match. Note that in Insert mode you can use CTRL-K and then a key to find out what Vim gets. - Bram -- A consultant is a person who takes your money and annoys your employees while tirelessly searching for the best way to extend the consulting contract. (Scott Adams - The Dilbert principle) /// 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: Patch 7.0.118
On 10/4/06, Bram Moolenaar [EMAIL PROTECTED] wrote: Nikolai Weibull wrote: Just a quick question: Wasn't printf a bit of a misnomer? Why? formattedprinting() would be a bit long, thus using the C library name sounds logical to me. Sprintf() would have been more logical to me, given that printf() in C prints a formatted string to stdout, while printf() in Vim returns a formatted string to its caller. Format() is another name used in some languages for this function. It's too late to change anyway. I realize that. nikolai
Re: [macvim] modifiers should be applied to special keys too (patch)
Here is one key that doesn't work for me: Shift-Tab. Most notably when doing command line completion, where Tab gets the next match and Shift-Tab goes to the previous match. I can see it, I'll try to fix it tomorrow. I always use C-P for previous match (much easier to type imho ;-) ), so I didn't notice this... Bye, Nico
win32 gvim 7.0 (1-118) hang on has(tcl) with cygwin
Hi All, i was having problems with gvim hanging when i tried to edit my vimrc. After a bit of sleuthing, i tracked it down to has(tcl) hanging (called from syntax/vim.vim). If i :echo has(tcl), the gvim window stops responding, and clicking the close box pops up the windows program not responding dialog, etc. A bit more sleuthing revealed that the culprit is the cygwin tcl84.dll which (in my setup) is in the path visible to gvim. If i hide that (e.g. by putting an empty file called tcl84.dll earlier in the path, or in the directory containing gvim.exe), has(tcl) reports 0 as expected. Note that i don't actually want tcl support, and certainly don't expect the cygwin tcl84.dll to work - if i want tcl i can download the windows version and put it earlier in my path. The workaround of an empty tcl84.dll in the vim directory works fine for me. I just figured this was worth reporting, since hangs are annoying, and i couldn't find anything in the archives about this (or the workaround). I'm a little curious that the empty file hack worked - i guess the cygwin dll looks enough like the real one that vim tries to call something in it and gets hosed ? Sorry i haven't had a chance to compile my own and take a look at it in a debugger yet. I'm using the gvim-7-0-118.exe installer from the cream soruceforge site. Note that i've not installed cream, just one of their plain vim installers, as this seemed the easiest way to get a compiled, patched, win32 vim. The download site i used was http://sourceforge.net/project/showfiles.php?group_id=43866package_id=39721 - robbie
Re: Gvim closing unexpectedly
[cross-posting to connect threads] On Thu, 2006-10-05 at 10:04 +1000, Robbie Gates wrote: Hi All, i was having problems with gvim hanging when i tried to edit my vimrc. After a bit of sleuthing, i tracked it down to has(tcl) hanging (called from syntax/vim.vim). It appears your post and one on the vim list are related: http://tech.groups.yahoo.com/group/vim/message/74227 http://tech.groups.yahoo.com/group/vimdev/message/45215 I'm not on a Windows box tonight to track this down, can anyone help us figure out if this is in the binary or runtime? 1. Verify syntax/vim.vim is not corrupt 2. Test the binary: :echo has(tcl) Greg, do you have Cygwin installed? Interesting that this just cropped up twice in two hours, these packages have been downloaded nearly 300 times over 8 days. -- Steve Hall [ digitect dancingpaper com ]
Re: Patch 7.0.111
On Wed, 4 Oct 2006 at 10:30pm, Bram Moolenaar wrote: Fan Decheng wrote: Bram Moolenaar wrote: Patch 7.0.111 Problem:The gzip plugin can't handle filenames with single quotes. Solution: Add and use the shellescape() function. (partly by Alexey Froloff) Files: runtime/autoload/gzip.vim, runtime/doc/eval.txt, src/eval.c, src/mbyte.c, src/misc2.c, src/proto/misc2.pro [...] I wonder whether it is possible to use execv() instead of escaping the command and then sending it to the shell. How do you think? Vim doesn't have an execv() function. Implementing this properly for all systems isn't that simple. At least you would need to take care of $PATH. How about using the underlying execv() where it is supported, and when it is not support just behave like system() does? This approach will probably cover more than 95% of the vim users. The problems that exist with using system() and different shells and environments is a huge usability issue (this will also avoid the minimized window on windows that most people feel bothered), and it might even make big difference in the performance when external commands are executed often (like using external commands to find matches for popup completion, everytime a character is typed). One caceat is that currently, if the external command execution takes a lot of time, you want to terminate it, you can un-minimize the window and kill it. If this window is avoided, Vim should still provide a means to kill it (like doing an explicit kill() when user presses ^C while waiting for the process). -- Thanks, Hari __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Vim 7.0 (1-109 patches) completion bug.
Hi, i think i have found a bug in vim 7.0 Patch level 1-109. Windows version +perl +python (i don't think this matters in this case) here is how to reproduce: gvim -u NONE -U NONE :set complete-=tdon't want complete from tags file - it's not important, just to switch off message :set complete+=longest that's important i now we in insert mode one two oC-N:tC-Nnow trying to complete second time - no completion, nothing i.e. i've got resulting text in buffer like this: one two one:t and no 'two' on second C-N when trying to complete 'two' and message Back at original (First completion works as expected, but second didn't shown and not complete at all) if remove 'longest' from 'complete' then everything works as expected. Can you reproduce that bug? Or it's intended behaviour? --- [EMAIL PROTECTED]
Re: BUG? getchar(0) and getchar(1) do not detect ESC
Peter Hodge wrote: Hello all, I am having trouble with getchar() detecting ESC. If I use getchar(0) or getchar(1), it will not pick up an ESC keystroke. You can replicate this by using the command: :sleep 3 | echo getchar(0) ... and pressing ESC quickly before the getchar() function is called. In GUI Vim, I correctly see 27 returned by getchar(0), but in Terminal Vim, getchar(0) is returning '0', even though ESC has been pressed. Is this a bug in Vim? regards, Peter Here, it depends of the number of keypresses: In gvim, :sleep 10 | echo getchar(0) followed by Esc returns 27 with no beep after 10 seconds. If Esc is pressed twice during the sleep period, it returns 27 with one beep after 10 seconds. In console Vim (with the same executable), :sleep 10 | echo getchar(0) followed by Esc returns 0 with one beep after 10 seconds. If Esc is hit twice during the sleep period, it returns 27 with one beep after 10 seconds. I suspect the difference may be due to the fact that many special keys generate (in console terminals but not in gvim) byte sequences starting with Esc, so the Esc key is not really seen until the next byte has been input. Hitting Del in konsole during the sleep period gives me 80kD with no beep, not the raw keycode, which would have been ^[[3~ :set timeout timeoutlen=5000 ttimeoutlen=250 apparently doesn't make any difference. Best regards, Tony.
Re: php online help in windowsXP
You should be able to do the same type of thing with firefox, eg firefox_doc.bat: c:\mozilla\firefox.exe $1 Maybe you can even get links for MSWin. On Tue, 3 Oct 2006, Vu The Cuong wrote: So I have set keywordprg=/home/marcel/php_doc and php_doc looks like: ### #!/usr/bin/bash links http://www.php.net/$1 ### And now I have the online help == This worked for me in FC5 and FreeBSD 6.1. How about WindowsXP How can I refer PHP online function in WindowsXP. -- .
Re: How to directly enter visual mode from insert mode ?
Ivan Vecerina [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] : This is a problem I am occasionally stumbling on: : as I am done typing some new next in insert mode, I want : to highlight and erase some text ahead of the insert point. I'm adding i_Ctrl-O to my list of must use commands. C-OD , C-Ow and C-Of) look like promising timesavers. (e.g. I'll be using C-OD often for sure I'm also checking :set inclusive and whichwrap+=, Many thanks for your insights, Ivan -- http://ivan.vecerina.com/
Re: toggling keymap
Hi, Sven Brueggemann schrieb: where do I find CTRL-^ on a German keyboard? I know that I can map it, but I'd like to see if the standard keystroke fits my needs before changing it. on my keyboard and with Windows XP it's CTRL-6. Regards, Jürgen -- Sometimes I think the surest sign that intelligent life exists elsewhere in the universe is that none of it has tried to contact us. (Calvin)
Copy between windows
Hello folks, I'm a begginer in the use of the vi, and I have a bit question: How can I copy a text between differents windows ? Thanks in advance. -- Thiago Nascimento #!/usr/bin/perl $_=tMM naaCt Feocmama_itpUilucoGa;$_.=$1,print $2 while s/(..)(.)//;print substr$_,1,1;
Re: Copy between windows
On 04.10.06,09:32, tnas wrote: Hello folks, I'm a begginer in the use of the vi, and I have a bit question: How can I copy a text between differents windows ? Thanks in advance. http://www.oualline.com/vim-cook.html#copy_block http://vim.sourceforge.net/tips/tip.php?tip_id=312 - Jostein -- Thiago Nascimento #!/usr/bin/perl $_=tMM naaCt Feocmama_itpUilucoGa;$_.=$1,print $2 while s/(..)(.)//;print substr$_,1,1; -- Jostein Berntsen [EMAIL PROTECTED]
Re: Copy between windows
I'm a begginer in the use of the vi, and I have a bit question: How can I copy a text between differents windows ? You'll want to specify the * (or +) register in your yank/deletes, such as *yy to yank the current line into the system clipboard, or *dap to cut the current paragraph into the system clipboard. This is also then used for pasting, as in *p The distinction between the * and + register is only significant (AFAIK) on X-Window systems, with the * being the selection (what usually gets pasted with the middle-mouse-button) and the + being the clipboard (what's available for pasting in most apps with control+V). If you always want every change to go into the system clipboard without manually specifying it, you can change your 'clipboard' option to include unnamed, as described in :help 'clipboard' In addition, the material at :help clipboard :help gui-clipboard :help quotestar may prove enlightening. -tim
Stack trace - omni completion
Vim 7.0 patches 1-106 WinXP SP2 In an attempt to debug one of my scripts, I added some debug statements in my VimL. When I did that, Vim will crash and produce the stack trace listed below. I can reproduce this every time, and I know the person who reported the problem (with my script) also gets the crash. I fired up gvimd.exe (which I compiled) and grabbed the stack trace. If you need more information, just let me know. :ver VIM - Vi IMproved 7.0 (2006 May 7, compiled Sep 14 2006 14:00:05) MS-Windows 32 bit GUI version with OLE support Included patches: 1-106 Compiled by [EMAIL PROTECTED] Big version with 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 +gettext/dyn -hangul_input +iconv/dyn +insert_expand +jumplist +keymap +langmap +libcall +linebreak +lispindent +listcmds +localmap +menu +mksession +modify_fname +mouse +mouseshape +multi_byte +multi_lang -mzscheme +netbeans_intg +ole -osfiletype +path_extra +perl/dyn -postscript +printer -profile +python/dyn +quickfix +reltime +rightleft -ruby +scrollbind +signs +smartindent -sniff +statusline -sun_workshop +syntax +tag_binary +tag_old_static -tag_any_white -tcl -tgetent -termresponse +textobjects +title +toolbar +user_commands +vertsplit +virtualedit +visual +visualextra +viminfo +vreplace +wildignore +wildmenu +windows +writebackup -xfontset -xim -xterm_save +xpm_w32 system vimrc file: $VIM\vimrc user vimrc file: $HOME\_vimrc 2nd user vimrc file: $VIM\_vimrc user exrc file: $HOME\_exrc 2nd user exrc file: $VIM\_exrc system gvimrc file: $VIM\gvimrc user gvimrc file: $HOME\_gvimrc 2nd user gvimrc file: $VIM\_gvimrc system menu file: $VIMRUNTIME\menu.vim Compilation: cl -c /W3 /nologo -D_MT -MT -I. -Iproto -DHAVE_PATHDEF -DWIN32 -DFEAT_CSCOPE -DFEAT_NETBEANS_INTG -DFEAT_XPM_W32 -DWINVER=0x0400 - D_WIN32_WINNT=0x0400 /Fo.\ObjGOLY/ /Ox -DNDEBUG -DFEAT_OLE -DFEAT_GUI_W32 -DDYNAMIC_ICONV -DDYNAMIC_GETTEXT -DFEAT_PYTHON -DDYNAMIC_PYTHON -DDYNAMI C_PYTHON_DLL=\python24.dll\ -DFEAT_PERL -DDYNAMIC_PERL -DDYNAMIC_PERL_DLL=\perl58.dll\ -DFEAT_BIG /Zi /Fd.\ObjGOLY/ Linking: link /RELEASE /nologo /subsystem:windows /incremental:no /nodefaultlib:libc advapi32.lib shell32.lib gdi32.lib comdlg32.lib ole32.lib uuid.li b oldnames.lib kernel32.lib gdi32.lib version.lib winspool.lib comctl32.lib advapi32.lib shell32.lib /machine:i386 /nodefaultlib libcmt.lib oleaut3 2.lib user32.lib /nodefaultlib:python24.libWSock32.lib C:\download\OpenSrc\vim\XPM_support_for_Netbeans\xpm-4.2.0\lib\libXpm.lib /PDB:.\ObjGO LY/gvim.pdb -debug AppName: gvimd.exe AppVer: 7.0.262.0 ModName: gvimd.exe ModVer: 7.0.262.0Offset: 00072f23 gvimd.exe!AppendToRedobuffLit(unsigned char * str=0x01938acc, int len=-1) Line 546 + 0x9 C gvimd.exe!ins_compl_prep(int c=67) Line 3410 + 0xe C gvimd.exe!edit(int cmdchar=105, int startln=0, long count=1) Line 773 + 0x12 C gvimd.exe!invoke_edit(cmdarg_S * cap=0x001268ac, int repl=0, int cmd=105, int startln=0) Line 8713 + 0x14 C gvimd.exe!nv_edit(cmdarg_S * cap=0x001268ac) Line 8686 + 0x14 C gvimd.exe!normal_cmd(oparg_S * oap=0x00126900, int toplevel=0) Line 1137 + 0x10 C gvimd.exe!exec_normal_cmd(unsigned char * cmd=0x0176e180, int remap=-1, int silent=0) Line 9029 + 0xbC gvimd.exe!ex_normal(exarg * eap=0x00126a14) Line 8932 + 0x2c C gvimd.exe!do_one_cmd(unsigned char * * cmdlinep=0x00126e90, int sourcing=1, condstack * cstack=0x00126b1c, unsigned char * (int, void *, int)* getline=0x00437530, void * cookie=0x0012784c) Line 2613 + 0x16 C gvimd.exe!do_cmdline(unsigned char * cmdline=0x0176e1d0, unsigned char * (int, void *, int)* getline=0x00437530, void * cookie=0x0012784c, int flags=3) Line 1099 + 0x1f C gvimd.exe!ex_execute(exarg * eap=0x00126f38) Line 18186 + 0x19 C gvimd.exe!do_one_cmd(unsigned char * * cmdlinep=0x001273b4, int sourcing=1, condstack * cstack=0x00127040, unsigned char * (int, void *, int)* getline=0x00437530, void * cookie=0x0012784c) Line 2613 + 0x16 C gvimd.exe!do_cmdline(unsigned char * cmdline=0x, unsigned char * (int, void *, int)* getline=0x00437530, void * cookie=0x0012784c, int flags=7) Line 1099 + 0x1f C gvimd.exe!call_user_func(ufunc * fp=0x012d68a0, int argcount=2, typval_T * argvars=0x00127d80, typval_T * rettv=0x00127e7c, long firstline=1, long lastline=1, dictvar_S * selfdict=0x) Line 19853 + 0x15C gvimd.exe!call_func(unsigned char * name=0x01713d60, int len=26, typval_T * rettv=0x00127e7c, int argcount=2, typval_T * argvars=0x00127d80, long
Re: Copy between windows
tnas wrote: Hello folks, I'm a begginer in the use of the vi, and I have a bit question: How can I copy a text between differents windows ? Thanks in advance. Yank it in one and put it in the other: e.g., 5yy to yank five lines, Ctrl-W w to switch to the next (split) window, move the cursor to where you want to insert, p to put after the cursor line or P to put before it. See :help change.txt :help windows.txt If by different window you mean another program (including a different instance of Vim) you'll have to use the system clipboard, which Vim sees as register + : +5yy to yank 5 lines into the clipboard, +p to paste after the cursor, from the system clipboard. On Unix this means you need both a version of Vim which is aware of the X clipboard, and a terminal which has access to it. To see if Vim is aware of the clipboard: :echo has(clipboard) zero means no (not compiled with clipboard support) nonzero means yes (clipboard support compiled-in). A terminal which has access to it means (on Unix) an xterm, konsole, or similar terminal emulator displaying through the X server. The pure text /dev/tty console has no access to X. Best regards, Tony.
Test and some help
Everything bounced back yesterday, my first day of signup. What I was trying to ask When a file changes, external to gvim/vim, I have it where it will tell me it has changed, but I would like to to tequest for it to be reloaded. This works on gvim, but not on vim.
RE: Test and some help
Got that problem solved. I was sending html from word -Original Message- From: Billy Patton [mailto:[EMAIL PROTECTED] Sent: Wednesday, October 04, 2006 9:37 AM To: vim@vim.org Subject: Test and some help Everything bounced back yesterday, my first day of signup. What I was trying to ask When a file changes, external to gvim/vim, I have it where it will tell me it has changed, but I would like to to tequest for it to be reloaded. This works on gvim, but not on vim.
Key remapping doesn't work
I'm not sure what my problem is, so I will try to give all the details that
could be relavant.
I'm using vim 6.3 on a solaris box. I am connecting through putty (ssh)
from a wintel box with a 104+ keyboard (US).
Scripts like supertab don't work, and when I try to remap tab manually, it
doesn't work either...like so:
function CleverTab()
let col = col('.') - 1
if !col || getline('.')[col - 1] !~ '\k'
return \tab
else
return \c-p
endif
endfunction
inoremap tab c-r=CleverTab()cr
---
Tab just acts like normal. even doing 'inoremap tab c-p' doesn't work.
Any ideas?
THANKS!!
--
View this message in context:
http://www.nabble.com/Key-remapping-doesn%27t-work-tf2382854.html#a6641190
Sent from the Vim - General mailing list archive at Nabble.com.
Re: Test and some help
Billy Patton wrote: Everything bounced back yesterday, my first day of signup. What I was trying to ask When a file changes, external to gvim/vim, I have it where it will tell me it has changed, but I would like to to tequest for it to be reloaded. This works on gvim, but not on vim. :set autoread Best regards, Tony.
Font rendering on Mac
Hi all I've been using the new 'Consolas' font from the Vista font pack for my vim editing on my Mac for a month or so without problems. This font looks amazing, but _only_ when anti-aliased, otherwise it looks like a mess. The other day, I setup a second mac here, and was trying to get it to render Consolas the same as on my first machine. It simply refuses to render properly. See http://dagsolutions.ca/vim_brokenfonts1.png and http://dagsolutions.ca/vim_brokenfonts2.png for the working and non-working screenshots respectively. I've got a terminal running top in the background, using Consolas as well, to show that the font works equally well on both machines in Terminal.app. I'm also showing my .gvimrc in those screenshots; it is identical. The output of :set is identical as well. Anyone have suggestions? The only thing that I can think of is that my second mac doesn't support CoreImage, but I am not familiar with what method vim uses for font rendering so don't know whether or not that would have any effect. Thanks Dave -- Dave Goodlad [EMAIL PROTECTED] or [EMAIL PROTECTED] http://david.goodlad.ca/
Gvim closing unexpectedly
I recently grabbed an updated gvim binary (7.0 with patches 1-110) from the cream sf site and now gvim closes without warning whenever I try to open a .vim script. It seems to have something to do with syntax highlighting: $ gvim -u NONE -U NONE :filetype on :e foo.vim :redir vim.txt :se verbose=10 :syntax on Vim closes at this point the redirect was intended to see what was happening before it closes, but the file never gets written to before vim closes. Any ideas? :version VIM - Vi IMproved 7.0 (2006 May 7, compiled Sep 26 2006 11:09:51) MS-Windows 32 bit GUI version with OLE support Included patches: 1-110 Compiled by [EMAIL PROTECTED] Big version with GUI. Features included (+) or not (-): +arabic +autocmd +balloon_eval +browse ++builtin_terms +byte_offset +cindent +cl ientserver +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 +gettext/dyn -hangul_input +iconv/dyn +insert_expand +jumplist +keymap +langmap +libcall +linebreak +lispindent +listcmds +localmap +menu +mksession +modify_fname +mouse +mouseshape +multi_byte_ime/dyn +multi_lang +mzs cheme/dyn +netbeans_intg +ole -osfiletype +path_extra +perl/dyn -postscript +printer -profile +python/dyn +quickfix +reltime +rightleft +ruby/dyn +scrollbin d +signs +smartindent -sniff +statusline -sun_workshop +syntax +tag_binary +tag_old_static -tag_any_white +tcl/dyn -tgetent -termresponse +textobjects +tit le +toolbar +user_commands +vertsplit +virtualedit +visual +visualextra +viminfo +vreplace +wildignore +wildmenu +windows +writebackup -xfontset -xim -x term_save -xpm_w32 system vimrc file: $VIM\vimrc user vimrc file: $HOME\_vimrc 2nd user vimrc file: $VIM\_vimrc user exrc file: $HOME\_exrc 2nd user exrc file: $VIM\_exrc system gvimrc file: $VIM\gvimrc user gvimrc file: $HOME\_gvimrc 2nd user gvimrc file: $VIM\_gvimrc system menu file: $VIMRUNTIME\menu.vim Compilation: gcc -O3 -fomit-frame-pointer -freg-struct-return -fno-strength-redu ce -DWIN32 -DHAVE_PATHDEF -DFEAT_BIG -DWINVER=0x0400 -D_WIN32_WINNT=0x0400 -DFEA T_PERL -DDYNAMIC_PERL -DDYNAMIC_PERL_DLL=perl58.dll -DFEAT_PYTHON -DDYNAMIC_PY THON -DDYNAMIC_PYTHON_DLL=python24.dll -DFEAT_RUBY -DDYNAMIC_RUBY -DDYNAMIC_RU BY_DLL=msvcrt-ruby18.dll -DDYNAMIC_RUBY_VER=18 -DFEAT_MZSCHEME -DDYNAMIC_MZSCH EME -DDYNAMIC_MZSCH_DLL=libmzsch352.dll -DDYNAMIC_MZGC_DLL=libmzgc352.dll -D FEAT_TCL -DDYNAMIC_TCL -DDYNAMIC_TCL_DLL=tcl84.dll -DDYNAMIC_GETTEXT -DDYNAMIC _ICONV -DFEAT_MBYTE -DFEAT_MBYTE_IME -DDYNAMIC_IME -DFEAT_CSCOPE -DFEAT_NETBEANS _INTG -DFEAT_GUI_W32 -DFEAT_CLIPBOARD -DFEAT_OLE -march=i386 -Iproto -I/cygdrive /c/PERL/lib/CORE -I/cygdrive/c/PYTHON24/include -I/cygdrive/c/RUBY/lib/ruby/1.8/ i386-mswin32 -I/cygdrive/c/PROGRA~1/MzScheme/include -I/cygdrive/c/Tcl/include - s -mno-cygwin Linking: gcc -s -o gvim.exe -luuid -lole32 /cygdrive/c/Tcl/lib/tclstub84.lib -l wsock32 -mwindows -lcomctl32 -lversion -loleaut32 -lstdc++
Re: Key remapping doesn't work
On 10/4/06, VetteVert [EMAIL PROTECTED] wrote:
I'm not sure what my problem is, so I will try to give all the details that
could be relavant.
I'm using vim 6.3 on a solaris box. I am connecting through putty (ssh)
from a wintel box with a 104+ keyboard (US).
Scripts like supertab don't work, and when I try to remap tab manually, it
doesn't work either...like so:
function CleverTab()
let col = col('.') - 1
if !col || getline('.')[col - 1] !~ '\k'
return \tab
else
return \c-p
endif
endfunction
inoremap tab c-r=CleverTab()cr
---
Tab just acts like normal. even doing 'inoremap tab c-p' doesn't work.
Any ideas?
Is your 'nocp' option properly set ? (it must be 'nocp') ?
Yakov
Re: BUG? getchar(0) and getchar(1) do not detect ESC
Peter Hodge wrote: I am having trouble with getchar() detecting ESC. If I use getchar(0) or getchar(1), it will not pick up an ESC keystroke. You can replicate this by using the command: :sleep 3 | echo getchar(0) ... and pressing ESC quickly before the getchar() function is called. In GUI Vim, I correctly see 27 returned by getchar(0), but in Terminal Vim, getchar(0) is returning '0', even though ESC has been pressed. Is this a bug in Vim? It's because Esc is the start of a key sequence and it's incomplete. Vim can't know you pressed the Esc key instead of having received the first byte of a key sequence. -- Imagine a world without hypothetical situations. /// 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: Forms highlighting
Dnia środa, 4 października 2006 05:06, Hari Krishna Dara napisał: No. They are inserting some version of keycode: OA, OB, OC, OD. In gui everything works well. In menus enabled Doesn't that just mean your term is not properly setup? I tried it on win32 console vim and it worked just fine. It is normal setup. Arrows doesn't work in xterm, konsole, rxvt. Bug: When completely remove value, leave field and later return to it default value is forgotten, Esc is going to Normal mode. This is not a bug. When you leave the field, the value is immediately saved, which means the new empty value overwrote the old value. When you return back to the field, this empty value becomes your new default value. Hmm. Not sure if this is expected behavior, maybe other users could tell more? Bug: Form is creating swap file which makes hard to use simultaneously the same form in various Vims when editing files in the same directory. Solution: Add 'setl noswapfile' after 'setl nomodified' in SetupBuf function (this is local option and but it is easier to read when explicitly declaring as local). This is really not a bug. Since the user is creating the buffer, it is his responsibility to set noswapfile if he is intending to open the same form multiple times. We could set noswapfile in forms, but then if the Vim crashes in the middle of the form entry, the user could loose some important data :) OK. At least for demo use just new instead of new Form. I don't know if this is more intuitive, but I know Java Swing/AWT framework (the only GUI framework that I am familiar with) doesn't have separate widgets. OK. We have to be careful in doing this. E.g., if you change the height while there is only one window, Vim will behave strangely. Yes. I don't know if there is any similar side effect of changing the width when there is only one window. No. Again, since user is creating the window for now I think we should leave this to the user. When buffer management is implemented in forms, we can set these parameters. Problem with current implementation is that user cannot influence dimensions of buffer. Before calling ShowForm he don't know them later it doesn't work. Don't know why, when placing above lines after ShowForm call formwidth is computed but it only places _ in first field. Unfortunately it goes wild when form will be opened in vertical window... What do you mean? Status lines goes up. One bug: On X11 @* (you are using to store form in clipboard) is selection, which means that it will be overwritten by [OK] (visually selected with normal navigation). At least on Unix systems you should use @+ clipboard (don't know how it works on Windows). BTW - you don't have to play with if/endif:: let @* = address let @+ = address will do. Another thing. Until now I was only playing with demo. Now I tried to do my own form and have one thing to say: Listener stuff is complicated. Can it be done simpler? m.
problem mapping Ctrl-Space (?)
I found the tutorial on using cscope with vim and am having trouble with the split screen commands. The Ctrl-\ variants map correctly to their cscope equivalents but Ctrl-Space just advances the cursor one position and performs the command associated with the letter (i.e. instead of Ctrl-Space,s opening a window with all references to the symbol, it advances the cursor one position to the right and starts a s[ubstitute]). Has anyone seen this problem before? OS: Ubuntu Linux 6.06.1 VIM - Vi IMproved 6.4 cscope_maps.vim : dated 2002/3/7 cscope: version 16.0a Thanks! ---chuck
RE: Gvim closing unexpectedly
From: Greg Dunn, Wed, October 04, 2006 1:51 pm I recently grabbed an updated gvim binary (7.0 with patches 1-110) from the cream sf site and now gvim closes without warning whenever I try to open a .vim script. It seems to have something to do with syntax highlighting: $ gvim -u NONE -U NONE :filetype on :e foo.vim :redir vim.txt :se verbose=10 :syntax on Vim closes at this point the redirect was intended to see what was happening before it closes, but the file never gets written to before vim closes. Any ideas? I'm unable to reproduce this in our 7.0.118 build from same site (and used 7.0.110 daily prior). Do you see anything more if you prepend :debug to that last command? -- Steve Hall [ digitect dancingpaper com ]
Re: problem mapping Ctrl-Space (?)
Chuck Tuffli wrote:
I found the tutorial on using cscope with vim and am having trouble
with the split screen commands. The Ctrl-\ variants map correctly to
their cscope equivalents but Ctrl-Space just advances the cursor one
position and performs the command associated with the letter (i.e.
instead of Ctrl-Space,s opening a window with all references to the
symbol, it advances the cursor one position to the right and starts a
s[ubstitute]). Has anyone seen this problem before?
OS: Ubuntu Linux 6.06.1
VIM - Vi IMproved 6.4
cscope_maps.vim : dated 2002/3/7
cscope: version 16.0a
Thanks!
---chuck
There was a thread about this yesterday. Control-Space is not portably
mappable. Ctrl + printable key is defined when locase(printable_key) is in
the range 0x3F..0x5F (and it that case the result is locase(printable_key) xor
0x40). Ctrl + other printable keys is not defined: Vim may see it or not, or
see it as something else. In SuSE 9.3 + kde, my gvim sees Ctrl-Space as just a
plain space, and it looks like yours does too.
If Ctrl-Space dosen't work for you in the {lhs} of mappings, use something
else, such as F9 instead of C-Space and S-F9 instead of C-SpaceC-Space
Best regards,
Tony.
Re: Forms highlighting
On Wed, 4 Oct 2006 at 10:37pm, Mikolaj Machowski wrote: Dnia ¶roda, 4 pa¼dziernika 2006 05:06, Hari Krishna Dara napisa³: No. They are inserting some version of keycode: OA, OB, OC, OD. In gui everything works well. In menus enabled Doesn't that just mean your term is not properly setup? I tried it on win32 console vim and it worked just fine. It is normal setup. Arrows doesn't work in xterm, konsole, rxvt. I have 6.3 version of cygwin and arrows work fine in rxvt. I stil think your term settings are not right. But this is not really concern forms plugin, though it means we might have to support some other maps that will reliably work in all the terms. Bug: When completely remove value, leave field and later return to it default value is forgotten, Esc is going to Normal mode. This is not a bug. When you leave the field, the value is immediately saved, which means the new empty value overwrote the old value. When you return back to the field, this empty value becomes your new default value. Hmm. Not sure if this is expected behavior, maybe other users could tell more? Who? No one seems to be interested, it is just us :) Bug: Form is creating swap file which makes hard to use simultaneously the same form in various Vims when editing files in the same directory. Solution: Add 'setl noswapfile' after 'setl nomodified' in SetupBuf function (this is local option and but it is easier to read when explicitly declaring as local). This is really not a bug. Since the user is creating the buffer, it is his responsibility to set noswapfile if he is intending to open the same form multiple times. We could set noswapfile in forms, but then if the Vim crashes in the middle of the form entry, the user could loose some important data :) OK. At least for demo use just new instead of new Form. I intended that as a clue on the usage (suggesting a nice name for the buffer). Setting 'noswapfile' is not sufficient if you create multiple buffers with the same name (Vim will essentially open the same buffer in new windows). If we have to demo the ability to create multiple forms then some buffer management will need to be done there (creating unique buffers, tracking which form is shown in which buffer etc.). Again, since user is creating the window for now I think we should leave this to the user. When buffer management is implemented in forms, we can set these parameters. Problem with current implementation is that user cannot influence dimensions of buffer. Before calling ShowForm he don't know them later it doesn't work. Don't know why, when placing above lines after ShowForm call formwidth is computed but it only places _ in first field. I don't know why it wouldn't work later, but I can certainly add functions to determine the widthPreference and heightPreference of the form. One bug: On X11 @* (you are using to store form in clipboard) is selection, which means that it will be overwritten by [OK] (visually selected with normal navigation). At least on Unix systems you should use @+ clipboard (don't know how it works on Windows). BTW - you don't have to play with if/endif:: let @* = address let @+ = address will do. I will make this change. Another thing. Until now I was only playing with demo. Now I tried to do my own form and have one thing to say: Listener stuff is complicated. Can it be done simpler? Do you mean simplify the listener interface, or completely do away with them? - If you mean the former, then the alternative is to accept a function name (this is what my previous version worked). But a big problem with this is that the function has to be global and I hate defining global functions without intending them to be part of API, and I know several others feel the same. The current scheme of expecting a dict object should be more familiar to many, who worked with the newer GUI frameworks (such as Swing and Flex). While not having to define a global dict variable, it also provides a way to create more contextual listeners (you can e.g., put the form that the listener is attached to, without having to modify the listener interface to also expect the form object). - If you mean the later, then I don't know how we can do that. If you have any ideas, you can throw them on me. May be a scriptlet can be passed in as a string instead of a dict object, but I don't know if this can always make it simple. It may however be possible to support both. What do you think are the next priority TODO items before making the first release (or a beta release)? I am thinking if I fix the known issues and implement the items that improve the overall feel of a static form, it will be good enough. Right now, there are too many ways the user can end up in 'modifiable' mode and just remove/change anything, giving the impression that the plugin is not robust). -- Thanks, Hari
Re: Gvim closing unexpectedly
[cross-posting to connect threads] On Thu, 2006-10-05 at 10:04 +1000, Robbie Gates wrote: Hi All, i was having problems with gvim hanging when i tried to edit my vimrc. After a bit of sleuthing, i tracked it down to has(tcl) hanging (called from syntax/vim.vim). It appears your post and one on the vim list are related: http://tech.groups.yahoo.com/group/vim/message/74227 http://tech.groups.yahoo.com/group/vimdev/message/45215 I'm not on a Windows box tonight to track this down, can anyone help us figure out if this is in the binary or runtime? 1. Verify syntax/vim.vim is not corrupt 2. Test the binary: :echo has(tcl) Greg, do you have Cygwin installed? Interesting that this just cropped up twice in two hours, these packages have been downloaded nearly 300 times over 8 days. -- Steve Hall [ digitect dancingpaper com ]
