Re: formatexpr, append() and undo
On Mon, May 15, 2006 at 06:26:55PM -0400, Benji Fisher wrote: Please do post the script you use, simplified as much as possible, so we can test it. I tried :call append(line($), This line brought to you by append()) and then (in Normal mode) u and it worked fine. This is with vim 7.0. Here are the scripts and the test case. It is relatively complicated, but I did not find a simpler one. It works in vim 7.0 (Included patches: 1-17) 1. First you need the script that I wrote and a small test file. They attached to this email. Put it into files format.vim and foo 2. vim -U NONE -u NONE foo :set nocompatible :source format.vim :set tw=20 this is not necessary, it only saves some typing 3. now go to the first line of , type o (open line) and start to type something like the text below between the two lines of =. Do not hit Enter, let the vim format the text. lajsdf lkjfd lkasjfd alskjdf aslkjfd ;laskdjf salkjfd one needs first to l;askjdf ;alskjdf write some normal lines ;lsajdf lsakjdf aslkjfd $laskjdf dfsaf$ lsdk (*) fasldkfj asdlkjf asdflj $laksjdf asfldkj (**) (*) this formula is important, it was started at the previous line but was moved by the formatting mechanism to this line (**) this formula was also started one line above 4. Now hit ESC and 'u'. I do not get back two lines of ===. The last three (or two, it depends what exactly did you type) lines of the text remain (partially with different formatting). Moreover, when I hit 'u' again vim says 'Already at oldest change' It is not possible to undo to the original state. I hope the description is good enough and the bug is reproducible. Regards, Jiri == == if exists(b:did_my_tex_format_pluggin) finish endif let b:did_my_tex_format_pluggin = 1 setlocal formatoptions=tcqr setlocal formatexpr=MyTeXFormat(v:lnum,v:count) fun! MyTeXFormat(lnum,count) if tw 10 let the vim do the job if tw is to small return 1 endif if mode()==i return SIDMyFormatInsert(a:lnum,a:count) elseif mode()==R return SIDMyFormatReplace(a:lnum,a:count) else return SIDMyFormatGQ(a:lnum,a:count) endif endfun fun! s:MyFormatInsert(lnum,count) if a:count!=1 echoerr Assertion failed: count1 return 1 endif if col(.) tw return 0 endif let line = getline(a:lnum) let curlineindent = indent(a:lnum) let aftercursor = line[col(.)-1:] let beforecursor = line[:col(.)-2] let dolarpos = SIDFindDolar(beforecursor,0) if dolarpos == -1 no dolars, vim do the job return 1 endif let evendolars = 0 let newpos = dolarpos while newpos != -1 count dollars find the last one let olddolarpos = dolarpos let dolarpos = newpos let evendolars = 1 - evendolars let newpos = SIDFindDolar(beforecursor,dolarpos + 1) endwhile if evendolars == 0 if dolarpos tw vim can do the job return 1 elseif olddolarpos curlineindent let dolarpos = olddolarpos break at the start of the formula else call append(a:lnum,XX) let newline = aftercursor call setline(a:lnum+1,newline) call cursor(a:lnum+1,1) return 0 endif endif if beforecursor[dolarpos-1]=='$' double dollars let dolarpos = dolarpos - 1 endif if beforecursor[dolarpos-1] != ' ' no space before $ let dolarpos = strridx(beforecursor,' ',dolarpos-1) let dolarpos = dolarpos + 1 endif if dolarpos != curlineindent formula does not start at first char call setline(a:lnum,strpart(beforecursor,0,dolarpos)) call append(a:lnum,XX) let newline = strpart(beforecursor,dolarpos) . aftercursor call setline(a:lnum+1,newline) call cursor(a:lnum+1,strlen(beforecursor)-dolarpos+1) return 0 endif return 0 endfun fun! s:MyFormatReplace(lnum,count) FIXME make something useful I never use replace mode return 1 endfun fun! s:MyFormatGQ(lnum,count) probably useles, vim does not know about ''latex type paragraphs'' return 1 endfun fun! s:FindDolar(s, pos) let i = match(a:s,'\%(^\|[^\\]\)\$',a:pos) if i == -1 return -1 endif if a:s[i] != '$'
Re: :cw messes with C-W_ C-W=
On Mon, May 15, 2006 at 10:24:33PM -0700, Yegappan Lakshmanan wrote: This is because the quickfix window has the 'winfixheight' option set. So when you try to make the height of all the windows equal, the windows with the 'winfixwidth' option set are skipped. If you reset the 'winfixheight' option for the quickfix window then CTRL-W_= will work. - Yegappan Thanks, that helps. The docs for 'winfixheight' mention behavior with 'equalalways' but not with C-W= . If 'winfixheight' is supposed to affect both, I think the docs should mention this. --Benji Fisher
Re: [vim7] a strange behavior of completeopt
On Tue, May 16, 2006 at 04:06:27PM +0800, Linsong wrote: Hi, all I encounter a strange problem when use vim7, the following steps will reproduce the problem: 1. run vim with command: vim -u NONE -U NONE 2. set the follwoing options: :set nocompatible :set completeopt+=longest 3. input some text into the buffer like this: foo.bar bet better 4. then input foC-P, fo will completed as foo, that is expected, input '.b' after foo, now the text becomes foo.b, then press C-P, it will become fo. Is it expected or maybe a bug? Any explanation is welcomed! Best regards, Vincent I can confirm this. It looks like a bug to me. I have run into similar problems before, but have not figured out how to reproduce them. Thanks for the reproducible example. HTH --Benji Fisher
Re: formatexpr, append() and undo
On Tue, May 16, 2006 at 08:33:43AM +0200, Jiří Černý wrote: Here are the scripts and the test case. It is relatively complicated, but I did not find a simpler one. It works in vim 7.0 (Included patches: 1-17) I have simplified the example somewhat. I may look at it some more later, or maybe someone else will take it from here. Save the attached files foo (unchanged) and format.vim (simplified) and start vim with $ vim -u NONE +source format.vim foo On the first (blank) line, start Insert mode and type 12345 $67890 1234$ 5678 9012 letting vim do the line breaks. Then Esc back to Normal mode and u to undo: the 9012 line is left and 'modified' is not set. Curiously, if I *do* add the line break myself after the first line, the problem seems to go away. The bug seems to surface only when two lines have been changed by the function. HTH --Benji Fisher == == set nocp tw=20 set laststatus=2 so I can watch the 'modified' flag setlocal formatoptions=tcqr setlocal formatexpr=MyTeXFormat(v:lnum,v:count) fun! MyTeXFormat(lnum,count) let line = getline(a:lnum) let curlineindent = indent(a:lnum) let aftercursor = line[col(.)-1:] let beforecursor = line[:col(.)-2] let numdollars = len(substitute(beforecursor, '[^$]', '', 'g')) let evendolars = numdollars % 2 let dolarpos = matchend(beforecursor, '.*\$') if evendolars == 0 if dolarpos tw vim can do the job return 1 endif endif if beforecursor[dolarpos-1] != ' ' no space before $ let dolarpos = strridx(beforecursor,' ',dolarpos-1) let dolarpos = dolarpos + 1 endif if dolarpos != curlineindent formula does not start at first char call setline(a:lnum,strpart(beforecursor,0,dolarpos)) call append(a:lnum,XX) let newline = strpart(beforecursor,dolarpos) . aftercursor call setline(a:lnum+1,newline) call cursor(a:lnum+1,strlen(beforecursor)-dolarpos+1) return 0 endif return 0 endfun
VIM 7.0 on WinXP - Strange garbage during editing.
Hello, At work I am using VIM 7.0 on WindowsXP and detected some garbage during editing process. Say I am loading a normal Textfile. I edit it, move around with the arrows, press ESC move around even more, scroll around a bit.. And quite often I find stuff that I previously yanked into the buffers spread all over the file. With other words, it looks like someone has pressed 'p' for pasting what's in the buffer all over the file. I get this quite often when editing code at work and I wonder why I run into errors and reloading the files show me that somehow the content of the buffers got pasted somewhere. The paste somehow happens when scrolling or cursor moving happens. It's quite strange to explain. I also add the vimrc file that I keep using at work (it's basicly the same as I use under my home Linux machine - I never had that problem at home with Linux.) Any ideas are welcome. mfg, Ali Akcaagac .vimrc Description: Binary data
Re: vim7: problem with regex subst and combining chars
(I've attached the zip with the following text in case it doesn't come through for you). If you do: :s/.*/hi/ Verified this happens on Linux as well.
Re: vim7: problem with regex subst and combining chars
(I've attached the zip with the following text in case it doesn't come through for you). If you do: :s/.*/hi/ Verified this happens on Linux as well. And furthermore verified it does NOT happen on vim 6.4
Re: [vim7] a strange behavior of completeopt
On Tue, May 16, 2006 at 08:57:57AM -0400, Benji Fisher wrote: On Tue, May 16, 2006 at 04:06:27PM +0800, Linsong wrote: Hi, all I encounter a strange problem when use vim7, the following steps will reproduce the problem: 1. run vim with command: vim -u NONE -U NONE 2. set the follwoing options: :set nocompatible :set completeopt+=longest 3. input some text into the buffer like this: foo.bar bet better 4. then input foC-P, fo will completed as foo, that is expected, input '.b' after foo, now the text becomes foo.b, then press C-P, it will become fo. Is it expected or maybe a bug? Any explanation is welcomed! Best regards, Vincent I can confirm this. It looks like a bug to me. I have run into similar problems before, but have not figured out how to reproduce them. Thanks for the reproducible example. HTH --Benji Fisher I can confirm the same as well. Probably a bug. Difficult to catch because normally people get out of completion mode. If, at foo.b, one presses c-e to exit from completion mode, the following c-p will work appropriately. --Matt
Re: VIM 7.0 on WinXP - Strange garbage during editing.
Hello, On 5/16/06, Ali Akcaagac [EMAIL PROTECTED] wrote: Hello, At work I am using VIM 7.0 on WindowsXP and detected some garbage during editing process. Say I am loading a normal Textfile. I edit it, move around with the arrows, press ESC move around even more, scroll around a bit.. And quite often I find stuff that I previously yanked into the buffers spread all over the file. Are you scrolling with the mouse and are you using the mouse scroll wheel? - Yegappan With other words, it looks like someone has pressed 'p' for pasting what's in the buffer all over the file. I get this quite often when editing code at work and I wonder why I run into errors and reloading the files show me that somehow the content of the buffers got pasted somewhere. The paste somehow happens when scrolling or cursor moving happens. It's quite strange to explain. I also add the vimrc file that I keep using at work (it's basicly the same as I use under my home Linux machine - I never had that problem at home with Linux.) Any ideas are welcome. mfg, Ali Akcaagac
Re: VIM 7.0 on WinXP - Strange garbage during editing.
On 5/16/06, Yegappan Lakshmanan [EMAIL PROTECTED] wrote: Hello, On 5/16/06, Ali Akcaagac [EMAIL PROTECTED] wrote: Hello, At work I am using VIM 7.0 on WindowsXP and detected some garbage during editing process. Say I am loading a normal Textfile. I edit it, move around with the arrows, press ESC move around even more, scroll around a bit.. And quite often I find stuff that I previously yanked into the buffers spread all over the file. Are you scrolling with the mouse and are you using the mouse scroll wheel? Also, refer to the following FAQ question: http://vimdoc.sourceforge.net/vimfaq.html#31.14 - Yegappan With other words, it looks like someone has pressed 'p' for pasting what's in the buffer all over the file. I get this quite often when editing code at work and I wonder why I run into errors and reloading the files show me that somehow the content of the buffers got pasted somewhere. The paste somehow happens when scrolling or cursor moving happens. It's quite strange to explain. I also add the vimrc file that I keep using at work (it's basicly the same as I use under my home Linux machine - I never had that problem at home with Linux.) Any ideas are welcome. mfg, Ali Akcaagac
Re: Moving windows horizontally from col to col
On Mon, May 15, 2006 at 03:43:40PM -0700, Gerald Lai wrote: On Tue, 16 May 2006, Marc Weber wrote: I like the way you can move windows in wmii. 1 | 2 --+-- 3 | 4 if your cursor is in window 1 and you move the window to the right you get | 1 3 | 2 | 4 [improved illustrations] and back eg. putting cursor into 4 and moving it to the left should result in 4 | 1 --+-- 3 | 2 Wether 4 is above 3 or not isn't that important.. I don't know how to do this with wincmd HJKL Not going as far as writing a full script to move windows around, what I'd do to achieve the above are the following commands: :windo wincmd K :3wincmd w :wincmd H Using one mapping is much faster than typing 3 commands ;) http://www.vim.org/scripts/script.php?script_id=1522 I know it, but does too much much and not the way I like it. Perhaps source my script, do some :vsplit|enew and try it... (and remove the /tmp/.. file afterwards) Marc
Re: Moving windows horizontally from col to col
Have a look at WinWalker.vim. It does this sort of thing. On 5/16/06, Marc Weber [EMAIL PROTECTED] wrote: On Mon, May 15, 2006 at 03:43:40PM -0700, Gerald Lai wrote: On Tue, 16 May 2006, Marc Weber wrote: I like the way you can move windows in wmii. 1 | 2 --+-- 3 | 4 if your cursor is in window 1 and you move the window to the right you get | 1 3 | 2 | 4 [improved illustrations] and back eg. putting cursor into 4 and moving it to the left should result in 4 | 1 --+-- 3 | 2 Wether 4 is above 3 or not isn't that important.. I don't know how to do this with wincmd HJKL Not going as far as writing a full script to move windows around, what I'd do to achieve the above are the following commands: :windo wincmd K :3wincmd w :wincmd H Using one mapping is much faster than typing 3 commands ;) http://www.vim.org/scripts/script.php?script_id=1522 I know it, but does too much much and not the way I like it. Perhaps source my script, do some :vsplit|enew and try it... (and remove the /tmp/.. file afterwards) Marc
Re: Tab autocommand inconsistencies?
I'm not sure I fully get what's going on, but I think is has to do
with the window that is automatically cloned to start the tab, which
is then converted to an empty buffer window.
On 5/15/06, Hari Krishna Dara [EMAIL PROTECTED] wrote:
Just wanted to send the script that I used, in case anyone is interested
to repeat:
let g:auCount = 0
aug TT
au!
au WinEnter * :call Au('WinEnter')
au WinLeave * :call Au('WinLeave')
au TabEnter * :call Au('TabEnter')
au TabLeave * :call Au('TabLeave')
au BufEnter * :call Au('BufEnter')
au BufLeave * :call Au('BufLeave')
aug END
function! Au(autype)
let g:auCount = g:auCount + 1
echomsg a:autype.' '.g:auCount
call input(a:autype)
endfunction
--
Thanks,
Hari
On Mon, 15 May 2006 at 5:08pm, Hari Krishna Dara wrote:
I am observing what might be inconsistency in the order in which vim
fires autocommands. First, ovserving the order of buffer and window events,
- Using :new:
WinLeave
WinEnter
BufLeave
BufEnter
- Using :wincmd w
BufLeave
WinLeave
WinEnter
BufEnter
When combined with tab operations,
- Using, :tabe:
WinLeave
TabLeave
TabEnter
WinEnter
BufLeave
BufEnter
- Using :tabnext:
BufLeave
WinLeave
TabLeave
WinEnter
TabEnter
BufEnter
Extrapolating the first two, I was expecting these to be
- For tabe:
TabLeave
TabEnter
WinLeave
WinEnter
BufLeave
BufEnter
- For :tabnext:
BufLeave
WinLeave
TabLeave
TabEnter
WinEnter
BufEnter
Is the existing behavior expected? Does anyone agree that it is
inconsistent? I am even surprised that they should differ between
switching between the existing windows/tabs and creating new ones.
__
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
Re: Associating files with Vim 7
Search your registry (with regedit or something better) for any conflicting entries for Vim6 and Vim7. On 5/16/06, James Eibisch [EMAIL PROTECTED] wrote: In Windows 2000 I'm having problems associating file extensions with Vim 7. I've been using Vim 6.2 (GUI version) for a while, and had associated C and TXT file extensions with it. In both Windows Explorer and a third-party file manager (WinNavigator 1.96), double-clicking a C or TXT file launched Vim as it should. Yesterday I upgraded to Vim 7 (the full, self-installing gvim70.exe). The installer uninstalled 6.2 before installing 7. 6.2 was installed in ...\vim\vim62 and 7 was installed in ...\vim\vim70. After installing 7, double-clicking a C file didn't launch Vim. No surprises there, as the path to gvim.exe had changed. I tried to associate the C extension with Vim 7 via Explorer | Tools | Folder Options | File Types, but Vim wasn't listed in the available programs - it was as if Vim hadn't registered itself with Windows while installing. I chose Other and navigated to vim70\gvim.exe, but when I clicked OK, the association hadn't stuck. In the 'Registered file types' box, the C extension said Opens with: but then a blank space - no program name. And Vim still wasn't listed in the available programs. However, double-clicking a C file in Windows Explorer did then launch Vim, but clicking a C file in WinNavigator didn't launch Vim - nothing happened. I associated C files with another editor, EditPlus, and that did stick, and did work in Explorer and WinNavigator. Tried associating with gvim again, and the same problem. Then I associated C files with the console version, vim70\vim.exe, and that did work - the association stuck, Vim was listed in the available programs, and files launched in console Vim in both file managers. Tried gvim again and still no joy. Has anyone got any ideas? I'm not sure if it's a Vim, Windows, or WinNavigator problem :-\ Thanks.
Re: Highlighting in Vim 7
Did you try putting these at the bottom of your vimrc? If so, then it might be a plugin or script you are using which is causing them to reset. Try --noplugin. On 5/15/06, Antun Karlovac [EMAIL PROTECTED] wrote: I just upgraded from GVIM 6.3 to GVIM 7, and my highlight colors no longer work. I'm on Windows. In my _vimrc file I had the following settings: highlight Comment guifg=#5F5F5F highlight Constant guifg=#AA highlight Type gui=NONE guifg=#990011 highlight Searchguibg=#AA These colors are ignored altogether. If I run the above lines manually in command mode, the colors are set. My original _vimrc file is still getting sourced correctly (other commands are still being read). Is there something that I need to run to apply the above colors? Thanks and take care, Antun
Re: Shell support in Vim?
On 5/15/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: I haven't seen much discussion of the intermediate solution: have a command shell that *isn't* a terminal emulator. There have been several attempts at this, with varying degrees of success. A command shell window which does good, solid handling of command line utilities would be terrific. It would require none of the morass of issues of terminal emulation, but still allow me/you to do many of the things that would be so useful. I'm currently switching around between plugins like vimsh.vim which uses Python, and my own home grown version which uses more primitive interaction with Cygwin OS. They come close, but aren't fully fledged, and seemingly aren't well known or used. I think with a few small additions to vim I could make vimsh a very good substitute. The big sticking point right now is async I/O. I've tried just about every trick in the book with none providing a good solution. I'm interested in seeing what you've done w/ cygwin. It's pretty bad with Windows. Even with Cygwin, all you have are pipes, not pseduo-ttys. I ended up with something fairly primative: communicating through the existence of files, checking every 200-300 ms. It responds as well as pipes without all the deadlock problems, though eats more cpu. The shell seems to be the inefficient side. I'm wondering if anybody has done a shared memory implementation for Windows? I personally like vimsh better than the possibility of an intergrated terminal because I like being able to move around it like a buffer with all the benefits of that, like the movement keys, yanking, etc, etc. Agreed.
Spellcheck in vim 7.0 doesn't seem to work
I'm just trying out vim 7.0 but I must be misunderstanding vimspell. The commmand :SpellCheck gives Not an editor command and \ss does nothing. I do have ispell in place. I'm sure I'm missing something important in the help file but if someone can point me to the right place I'd be grateful. Anthony -- Anthony Campbell - [EMAIL PROTECTED] Microsoft-free zone - Using Linux Gnu-Debian http://www.acampbell.org.uk (blog, book reviews, on-line books and sceptical articles)
[vim7] a strange behavior of completeopt
Hi, all I encounter a strange problem when use vim7, the following steps will reproduce the problem: 1. run vim with command: vim -u NONE -U NONE 2. set the follwoing options: :set nocompatible :set completeopt+=longest 3. input some text into the buffer like this: foo.bar bet better 4. then input foC-P, fo will completed as foo, that is expected, input '.b' after foo, now the text becomes foo.b, then press C-P, it will become fo. Is it expected or maybe a bug? Any explanation is welcomed! Best regards, Vincent
Re: Spellcheck in vim 7.0 doesn't seem to work
On 16 May 2006, Georg Dahn wrote: Hi! --- Anthony Campbell [EMAIL PROTECTED] wrote: The commmand :SpellCheck gives Not an editor command and \ss does nothing. I do have ispell in place. Obviously, there is no editor command SpellCheck and you don't need ispell, since Vim has an internal spell checker. Just do :h spell and read the manual. I'm sure I'm missing something important in the help file but if someone can point me to the right place I'd be grateful. Set your language with :set spelllang=en (or whatever language you want). With :set spell you turn spell checking on and with :set nospell you turn it off again. If the dictionary of your language is not available, just follow the dialogues to download it. Best wishes, Georg Thanks for the clarification. These commands work fine, which is what I was looking for. But :h spell produces information only about vimspell and vimspell commands. It does not give the information you supplied. I still don't see how you are supposed to locate that. Anthony -- Anthony Campbell - [EMAIL PROTECTED] Microsoft-free zone - Using Linux Gnu-Debian http://www.acampbell.org.uk (blog, book reviews, on-line books and sceptical articles)
Re: Spellcheck in vim 7.0 doesn't seem to work
On Tue, 2006-05-16 at 09:52:29 +0100, Anthony Campbell sent: Thanks for the clarification. These commands work fine, which is what I was looking for. But :h spell produces information only about vimspell and vimspell commands. It does not give the information you supplied. I still don't see how you are supposed to locate that. Just some guesswork on my part... Looks to me like you have (at least the help for) a vimspell plugin loaded. Does :help spell-quickstart bring up a different helpfile? Hope this helps; --paj -- Pete Johns http://johnsy.com/ Tel/Fax numbers and IM information http://johnsy.com/contact/ Guy Kewney http://johnsy.com/20060515092823 pgpoB7VpdotM5.pgp Description: PGP signature
Re: Associating files with Vim 7
I wrote:
In Windows 2000 I'm having problems associating file extensions
with Vim 7.
-
Eric replied:
Search your registry (with regedit or something better) for any
conflicting entries for Vim6 and Vim7.
-
I've not done much with the registry before but below are some of the
related keys. There are some 6.2 keys left in there (numbers 4, 8, 12 plus
some others I didn't list).
Do you think it would be safe just to change all instances in the registry
of 'vim62' with 'vim70' as a try-it-and-see solution?
1. HKEY_CLASSES_ROOT\*\OpenWithList\gvim.exe\(value not set)
2. HKEY_CLASSES_ROOT\*\shellex\ContextMenuHandlers\gvim\a hex string
3.
HKEY_CLASSES_ROOT\Applications\gvim.exe\shell\edit\command\..\vim\vim70\gvim.exe
%1
4.
HKEY_CLASSES_ROOT\Applications\gvim.exe\open\edit\command\..\vim\vim62\gvim.exe
%1
5. HKEY_CLASSES_ROOT\CLSID\{long hex
string}\LocalServer32\..\vim\vim70\gvim.exe
6. HKEY_CLASSES_ROOT\CLSID\{long hex
string}\InProcServer32\..\vim\vim70\gvimext.dl
7. HKEY_CLASSES_ROOT\TypeLib\{long hex
string}\1.1\0\win32\..\vim\vim70\gvim.exe
8. HKEY_CLASSES_ROOT\Unknown\shell\open\command\..\vim\vim62\gvim.exe
%1
9.
HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Exploreer\FileExts\.C\gvim.exe
10. HKEY_LOCAL_MACHINE\SOFTWARE\Classes\*\OpenWithList\gvim.exe
11.
HKEY_LOCAL_MACHINE\SOFTWARE\Classes\Applications\gvim.exe\shell\edit\command\..\vim\vim70\gvim.exe
%1
12.
HKEY_LOCAL_MACHINE\SOFTWARE\Classes\Applications\gvim.exe\shell\open\command\..\vim\vim62\gvim.exe
%1
13.
HKEY_LOCAL_MACHINE\SOFTWARE\Classes\Applications\vim.exe\shell\open\command\..\vim\vim70\vim.exe
%1
Key Mapping for spellcheck.
Hi, I would like to map the right-clic-key (to make myself clear it's the one between Win flag and Ctrl key) so I can have the suggestion when I'm spellchecking a file. How is it named under vim ? Thank you for your help Eddine.
Re: Key Mapping for spellcheck.
If you mean the right-shift key, I don't think shift/control/alt/meta are delivered by themselves to Vim. You'll have to pick shift-somekey. On 5/16/06, Baha-Eddine MOKADEM [EMAIL PROTECTED] wrote: Hi, I would like to map the right-clic-key (to make myself clear it's the one between Win flag and Ctrl key) so I can have the suggestion when I'm spellchecking a file. How is it named under vim ? Thank you for your help Eddine.
Re: Key Mapping for spellcheck.
Baha-Eddine MOKADEM wrote: Hi, I would like to map the right-clic-key (to make myself clear it's the one between Win flag and Ctrl key) so I can have the suggestion when I'm spellchecking a file. How is it named under vim ? Thank you for your help Eddine. Not sure Vim sees that key. In Insert mode, try hitting Ctrl-V (or Ctrl-Q if you use Ctrl-V to paste) followed by the key in question. If something is inserted in your buffer, that's (probably) how your version of Vim sees the key. If nothing is inserted, or if something else happens (e.g., a menu opens) then Vim doesn't see the key. You might try changing the status of the 'winaltkeys' setting to see if it makes any difference. Best regards, Tony.
Re: [vim7] a strange behavior of completeopt
I reported this same issue to the mailing list a week or two ago. Bram wrote: I know about this: When you type the . and there no complete match was inserted (showing the longest common text in this example), Vim assumes you are extending the text to reduce the list of matches. Thus the completion still starts at BlahBlah. You need to stop completion somehow, e.g., with a space and backspace. This is not a nice way to work. I thought of having all punctuation characters stop completion, but that breaks completion of items where punctuation can be part of the match (e.g., () for functions). The same bug affects file name completion and presumably others as well: /uC-XC-F/bC-N Result with completeopt-=longest /usr/bin/ with '/usr/bin/' as only suggestion. Result with completeopt+=longest /usr/b with no suggestions. -- eric
Re: not opening correct syntax file for .prg files
At 10:30 PM 5/15/2006, you wrote: On Mon, May 15, 2006 at 12:01:35PM -0500, Donal wrote: Here is my vim\myfiletypes.vim myfiletypes.vim augroup filetype FoxPro au! BufRead,BufNewFile *.prg,*.mpr,*.sprset filetype=foxpro Cold Fusion au BufNewFile,BufRead *.cfm,*.cfi,*.cfc setf cf au! BufRead,BufNewFile *.cfml,*.cfm set filetype=cf augroup END What am I doing wrong? My first guess is that :au filetype BufRead will give you the hint you need. This is from vim70\filetype.vim: Clipper (or FoxPro; could also be eviews) au BufNewFile,BufRead *.prg \ if exists(g:filetype_prg) | \ exe setf . g:filetype_prg | \ else | \ setf clipper | \ endif And I have confirmed that clipper.vim IS the script being used. Here is a question... is myfiletypes.vim still being used, or has it been deprecated? I started using vim way back in 3.x... all I can find in the help files refers to filetypedetect and the ftdetect directory... By searching on filetype I found a reference to myfiletypefile that mentions that myfiletypes.vim is for backward support for vim 5.x only... so it looks like it may have been recently removed. This would explain alot... I guess I better read up on using the ftdetect directory :( --- Donal, SysAdmin of the Brewers' Witch BBS http://www.brewich.com mailto:[EMAIL PROTECTED] ICQ:422928 CMA: 20639 WitchVox: 1494 Soc.Religion.Paganism (Modkinus Primus, Ret.) news:soc.religion.paganism Moderator: Houston Pagans Online http://groups.yahoo.com/houstonpagansonline Council of the Magickal Arts (Brewers Society Coord, Pooh-burbanite) http://www.magickal-arts.org Pagans' Night Out (Founder) http://www.paganhouston.com/pno Everquest II: Florence Sopher (Templar Sage) Co-Guild Leader of Helanic Frost; Lucan D'Lere server http://setiathome.ssl.berkeley.edu My BOINC Credits: 2579.85 Avg: 29.44 ET's found: 0
Re: not opening correct syntax file for .prg files
Donal wrote: And I have confirmed that clipper.vim IS the script being used. Here is a question... is myfiletypes.vim still being used, or has it been deprecated? I started using vim way back in 3.x... all I can find in the help files refers to filetypedetect and the ftdetect directory... By searching on filetype I found a reference to myfiletypefile that mentions that myfiletypes.vim is for backward support for vim 5.x only... so it looks like it may have been recently removed. This would explain alot... I guess I better read up on using the ftdetect directory :( Here's an example of a .vim/filetype.vim file, used to select a syntax (in this case, asave.vim). filetype.vim: Author: Charles E. Campbell, Jr. Date: September 25, 2000 if exists(did_load_myfiletypes) finish endif let did_load_myfiletypes= 1 augroup filetypedetect au BufNewFile,BufReadPost asav*.txtsetf asave augroup END If you have a file that needs a bit of snooping to determine what type it is, you may also have a .vim/scripts.vim file. Again, here's an example: DrChip's scripts -- ie. those files which are ambiguously named so I have to do further testing to see if they qualify for specific syntax stuff if !has(syntax_items) handles my tmp[0-9]* debugging files if expand(afile) =~ '^tmp' if getline(2) =~ ^| || getline(3) =~ ^| setf dbg endif endif endif If you're using Windows, then instead of ~/.vim/ you'll need to use --wherever--\vimfiles\ ... Furthermore, if you want a personal syntax file, put it into .vim/syntax And, if you merely wish to extend syntax, put a same-name-as-the-filetype.vim file with the extensions in .vim/after/syntax Regards, Chip Campbell
Text - commandline
Hi, for what keyword I have to look in the online-help to find a hint how to copy any text from a buffer as any part of a command currently being edited in the commandline ? kind regards, mcc
Re: Text - commandline
On Tue, 2006-05-16 at 18:45:52 +0200, Meino Christian Cramer sent: Hi, for what keyword I have to look in the online-help to find a hint how to copy any text from a buffer as any part of a command currently being edited in the commandline ? :help c_CTRL-R Hope this helps; --paj -- Pete Johns http://johnsy.com/ Tel/Fax numbers and IM information http://johnsy.com/contact/ Guy Kewney http://johnsy.com/20060515092823 pgp0v7M7PVfJS.pgp Description: PGP signature
Re: Text - commandline
Meino Christian Cramer wrote: Hi, for what keyword I have to look in the online-help to find a hint how to copy any text from a buffer as any part of a command currently being edited in the commandline ? kind regards, mcc If by buffer you mean what the Vim docs call a register, see :help c_CTRL-R. If you mean part of a file being edited, IMHO the easiest way is to yank it beforehand into a register, though in some cases you can use the expression register (Ctrl-R =) with e.g. expressions such as getline(.) Best regards, Tony
Vim 7 Spell-check option?
Is there any *easy* way to tell the Vim 7 spell-checker not to flag single letters as spelling errors? For example, lists such as a. Report(s) to be delivered blah blah b. asdfasdf asdf sadf fd c. sdfg dfg sdgf dfg will have (s), b. and c. flagged as misspellings. -- __ | Edward J. Krall | [EMAIL PROTECTED] | | 10838 North 110 Place | 480-614-0423 | | Scottsdale, AZ 85259 | | |___|__|
Re: marked text in visual mode is loaded to xclipboard
Hello, On 5/16/06, Friedrich Strohmaier [EMAIL PROTECTED] wrote: Hi alltogether, I'm new to this list, but not new to vim, so let me say hello to everybody. I'm not that poweruser, but I hate unnecesary repeating things and vim allways gave me, what I needed :o)) Im working on ubuntu-linux 5.10 with the boxed vim Version 6.3.78 I subscribed this list to get ahead with a problem, which drives me crasy nearly everytime I work with vim: If I mark some text in visual mode that text is put in the x-clipboard and therefore pasted with the mouse on the action following. Try the following (in normal mode): 1. Take text from anywhere with the mouse 2. clear the target area and enter insert mode typing v, nl, s 3. paste with middle mouse button result: You get the text vom cleared area -- anoying!! expected result: the anywhere fetched text should be pasted. I noticed that behavior since vim 6.x This apears in console-vim (xterm) an gvim. using a virtual tty with gpm works as expected. Can anyone help me to find the right option to be set, or to file a bugreport. I subscribed here to get feedback/confirmation before bothering the developers. Any hints? When you make a visual selection, Vim will copy the selected text to the clipboard. This is controlled by the 'clipboard' option in terminal Vim and by the 'guioptions' option in GUI Vim. To disable Vim from copying the visually selected text to clipboard, use the following commands: set clipboard= set guioptions-=a You can place the first command in the .vimrc file and the second one in the .gvimrc file. For more information about this, read :help 'clipboard' :help guioptions_a - Yegappan
Re: not opening correct syntax file for .prg files
On Tue, May 16, 2006 at 11:22:00AM -0500, Donal wrote: At 10:30 PM 5/15/2006, you wrote: On Mon, May 15, 2006 at 12:01:35PM -0500, Donal wrote: Here is my vim\myfiletypes.vim myfiletypes.vim augroup filetype FoxPro au! BufRead,BufNewFile *.prg,*.mpr,*.sprset filetype=foxpro Cold Fusion au BufNewFile,BufRead *.cfm,*.cfi,*.cfc setf cf au! BufRead,BufNewFile *.cfml,*.cfm set filetype=cf augroup END What am I doing wrong? My first guess is that :au filetype BufRead will give you the hint you need. This is from vim70\filetype.vim: Clipper (or FoxPro; could also be eviews) au BufNewFile,BufRead *.prg \ if exists(g:filetype_prg) | \ exe setf . g:filetype_prg | \ else | \ setf clipper | \ endif And I have confirmed that clipper.vim IS the script being used. Here is a question... is myfiletypes.vim still being used, or has it been deprecated? I started using vim way back in 3.x... all I can find in the help files refers to filetypedetect and the ftdetect directory... By searching on filetype I found a reference to myfiletypefile that mentions that myfiletypes.vim is for backward support for vim 5.x only... so it looks like it may have been recently removed. This would explain alot... I guess I better read up on using the ftdetect directory :( I am sticking with my first guess for now. As I hinted, and another post said explicitly, your :au! command is clearing out the autocommand you defined for *.prg . I do not recall the order in which these things are :source'd, but you can check with :scriptnames whether vim is reading your myfiletypes.vim file, and if so whether it is being read before or after the default one. Depending on which comes first, it may make a difference whether you use :setf or :set ft , since the former has no effect if 'filetype' is already set. HTH --Benji Fisher
Calling through a function reference with a variable argument list
Hi all, I'm re-writing my cvscommand.vim plugin to handle both CVS and Subversion version control systems. I'm currently implementing some of the functionality through function references that define common operations for each source control system in a dictionary specfic to that system. I have a situation where I have a generic dispatch function that identifies which dictionary to dereference to obtain the function reference. The problem is that the function eventually called behind the function reference may have any number of arguments. Therefore, the dispatch function takes any number of arguments to pass through. This leads to the actual call, which looks like this (all on one line): function! s:ExecuteVCSCommand(command, ...) find the proper functionMap dictionary, and then: execute return functionMap[a:command]( . join(map(copy(a:000), '\' . v:val . '\'), ,) . ) My question is whether there is a simpler way to pass an unknown number of arguments from the current function to a function which accepts a variable-length list of arguments. Thank you, Bob
Re: Calling through a function reference with a variable argument list
On 5/16/06, Bob Hiestand [EMAIL PROTECTED] wrote: I'm re-writing my cvscommand.vim plugin to handle both CVS and Subversion version control systems. I'm currently implementing some of the functionality through function references that define common operations for each source control system in a dictionary specfic to that system. I have a situation where I have a generic dispatch function that identifies which dictionary to dereference to obtain the function reference. The problem is that the function eventually called behind the function reference may have any number of arguments. Therefore, the dispatch function takes any number of arguments to pass through. This leads to the actual call, which looks like this (all on one line): function! s:ExecuteVCSCommand(command, ...) find the proper functionMap dictionary, and then: execute return functionMap[a:command]( . join(map(copy(a:000), '\' . v:val . '\'), ,) . ) My question is whether there is a simpler way to pass an unknown number of arguments from the current function to a function which accepts a variable-length list of arguments. The only thing I can think of is rewriting target functions into accepting 1 argument which is a list. I don't find vim vararg mechanism easy to use in general. Yakov
Re: Text - commandline
On Tue, May 16, 2006 at 07:12:01PM +0200, A.J.Mechelynck wrote: Meino Christian Cramer wrote: for what keyword I have to look in the online-help to find a hint how to copy any text from a buffer as any part of a command currently being edited in the commandline ? If by buffer you mean what the Vim docs call a register, see :help c_CTRL-R. If you mean part of a file being edited, IMHO the easiest way is to yank it beforehand into a register, though in some cases you can use the expression register (Ctrl-R =) with e.g. expressions such as getline(.) For shortcuts to inserting files and words on the commandline see the section described here: :help c_C-R_C-F -- with kind regards Thor Andreassen
echon space ?
Does anybody understand why trailing spaces in an echon string don't actually show up? echon \ngimme let inp = getchar() echon nr2char(inp)
SNR, maparg(), and UTF-8
Hello,
I have a problem with an old hack that works fine in latin1, but starts
to cause problems in UTF-8.
The hack helps to replace activation key-sequences from i-mappings with
their mapped value, which are actually calls to script-local functions.
What is quite odd is that I have a workaround on Linux (by calling
iconv()) which has no, useful, effect on Windows (win32 build).
The problem has existed for a long time. The iconv() workaround works
correctly with vim 7.0.012 on linux, but not with vim 7.0.000 (default
win32 build) on windows.
Is there a solution to my problem (may be a patch for vim) ? Or have I
to change the scope of my i-mapped local-functions to global ?
Thank in advance for any hint.
Here follows a simplified viml code that illustrates what I'm trying to
achieve.
--- %
script1
function! s:foo()
complex computations according to context, ...
return foo
endfunction
inoremap !foo! c-r=sidfoo()cr
==
script2 in real situation
function! s:bar()
let foo = '!foo!'
let m = maparg(foo,'i')
if strlen(m) != 0
exe 'let m=' .
\ substitute(m, '\(.\{-1,}\)', '.\\\1.', 'g') . ''
if has('iconv')
uncomment the following line to activate the workaround on linux
let m = iconv(m, 'latin1', encoding)
endif
endif
return 'bar'.m.'bar'
endfunction
inoremap bfb c-r=sidbar()cr
--- %
--
Luc Hermitte
http://hermitte.free.fr/vim/
Re: echon space ?
On Tue, 16 May 2006, Eric Arnold wrote: Does anybody understand why trailing spaces in an echon string don't actually show up? echon \ngimme let inp = getchar() echon nr2char(inp) I think echo/echon is doing fine. It's getchar() that's eating up trailing spaces. Compare @a's for: :redir @a | echon 123 | call getchar() | redir END :redir @a | echon \n123 | call getchar() | redir END :redir @a || echon 123 | call getchar() | redir END The \n or previous ex command | has something to do with it. (tested on Vim 6.3) -- Gerald
Re: echon space ?
On 5/16/06, Gerald Lai [EMAIL PROTECTED] wrote: On Tue, 16 May 2006, Eric Arnold wrote: Does anybody understand why trailing spaces in an echon string don't actually show up? echon \ngimme let inp = getchar() echon nr2char(inp) I think echo/echon is doing fine. It's getchar() that's eating up trailing spaces. Compare @a's for: :redir @a | echon 123 | call getchar() | redir END :redir @a | echon \n123 | call getchar() | redir END :redir @a || echon 123 | call getchar() | redir END Not sure what the last example is supposed to do. The \n or previous ex command | has something to do with it. (tested on Vim 6.3) -- Gerald It's odd that it remembers all the trailing spaces, and prints them out as soon as the echon following the getchar() prints a non-space char. I'm thinking that it could also be the rendering in the command window that is causing it, as if it truncates trailing spaces when writing to the screen, but not when actually building the strings internally. It's probably a combination of this, and that getchar() isn't in the list of things that triggers printing the trailing spaces. I can't tell whether to call this a bug yet.
Re: echon space ?
Eric Arnold wrote: On 5/16/06, Gerald Lai [EMAIL PROTECTED] wrote: On Tue, 16 May 2006, Eric Arnold wrote: Does anybody understand why trailing spaces in an echon string don't actually show up? echon \ngimme let inp = getchar() echon nr2char(inp) I think echo/echon is doing fine. It's getchar() that's eating up trailing spaces. Compare @a's for: :redir @a | echon 123 | call getchar() | redir END :redir @a | echon \n123 | call getchar() | redir END :redir @a || echon 123 | call getchar() | redir END Not sure what the last example is supposed to do. The \n or previous ex command | has something to do with it. (tested on Vim 6.3) -- Gerald It's odd that it remembers all the trailing spaces, and prints them out as soon as the echon following the getchar() prints a non-space char. I'm thinking that it could also be the rendering in the command window that is causing it, as if it truncates trailing spaces when writing to the screen, but not when actually building the strings internally. It's probably a combination of this, and that getchar() isn't in the list of things that triggers printing the trailing spaces. I can't tell whether to call this a bug yet. (Just guessing in the dark) Could it be a redraw problem? Best regards, Tony.
vim7: two issues with insert mode completion
Very often, I record changes that involves i_^P, and see an issue replaying them in Vim7. Say, you have text such as: aaa bbb ccc ddd eee fff so on Now, if I want to change all the 3rd columns to same as the first column, I usually do this by recording the cw^P^P^[ while on the 3rd column and replay it on the rest (the convenience might not be obvious in this example, but for a small set of lines, this approach many times, is way more convenient than createing a substitute command using sub-expressions). I see two issues with Vim7. - Even with vim started using -u NONE (and 'nocp' set), repeating this macro works as if ^P is pressed only once (that is replaces with eee instead of ddd on the second line). If I set 'completeopt' to empty string, then it starts working again. - Happily, I came back to my regular vim session and tried again with 'completeopt' set to , but it still behaves as if only one ^P is pressed. Didn't know what other setting could have made this difference, but I observe another issue here. In my Vim 6.3, pressing ^P after a space would immediately return the word before the space, and another ^P will be as quick, unless there are no more words in that buffer. But in Vim 7, this results in scanning all the open buffers (causing unnecessary delays). When 'completeopt' is empty, shouldn't it just complete the word in front of the space? Is this probably causing the second ^P from getting ignored? To validate this, I repeated my earlier experiment (-u NONE), but while several other buffers are also loaded, and reproduced the same problem. Setting 'completeopt' to will still not make the macro to work (which it did, when there were no other buffers). To summarize, I think there are two issues compared to Vim 6.3: - i_Ctrl-P in macro recording is broken. - i_Ctrl-P is scanning too much, and is too slow. -- Thanks, Hari __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Re: vim7: two issues with insert mode completion
To add to this, I am surprised that ^C in macro recording is ignored. Since the first ^P was taking a long time scanning all buffers, I inserted a ^C after the first ^P to stop scanning (so the macro becomes, cw^P^C^P^[), and insert the word that comes before the space, but this got ignored while replaying. Don't know how Vim 6.3 behaves in this respect, but it doesn't seem generic (like recording only ^C and replaying it). -- Thanks, Hari On Tue, 16 May 2006 at 6:51pm, Hari Krishna Dara wrote: Very often, I record changes that involves i_^P, and see an issue replaying them in Vim7. Say, you have text such as: aaa bbb ccc ddd eee fff so on Now, if I want to change all the 3rd columns to same as the first column, I usually do this by recording the cw^P^P^[ while on the 3rd column and replay it on the rest (the convenience might not be obvious in this example, but for a small set of lines, this approach many times, is way more convenient than createing a substitute command using sub-expressions). I see two issues with Vim7. - Even with vim started using -u NONE (and 'nocp' set), repeating this macro works as if ^P is pressed only once (that is replaces with eee instead of ddd on the second line). If I set 'completeopt' to empty string, then it starts working again. - Happily, I came back to my regular vim session and tried again with 'completeopt' set to , but it still behaves as if only one ^P is pressed. Didn't know what other setting could have made this difference, but I observe another issue here. In my Vim 6.3, pressing ^P after a space would immediately return the word before the space, and another ^P will be as quick, unless there are no more words in that buffer. But in Vim 7, this results in scanning all the open buffers (causing unnecessary delays). When 'completeopt' is empty, shouldn't it just complete the word in front of the space? Is this probably causing the second ^P from getting ignored? To validate this, I repeated my earlier experiment (-u NONE), but while several other buffers are also loaded, and reproduced the same problem. Setting 'completeopt' to will still not make the macro to work (which it did, when there were no other buffers). To summarize, I think there are two issues compared to Vim 6.3: - i_Ctrl-P in macro recording is broken. - i_Ctrl-P is scanning too much, and is too slow. __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Re: sourcing vimrc files
On 5/14/2006 8:41 PM, Gerald Lai wrote: Encase your function like this: if !exists(*Source_vimrc) function Source_vimrc() ... endfunction endif Thanks, Gerald. This worked perfectly. Also, thanks to everyone else for their suggestions. I appreciate the feedback and read up on the suggested commands, but this ended up being the easiest. :-) -- Jared
Re: Text - commandline
From: Thor Andreassen [EMAIL PROTECTED] Subject: Re: Text - commandline Date: Tue, 16 May 2006 22:45:30 +0200 Hi, The yank-trick (first yank the stuff, then CTRL-R in the commandline fits currently my needs best. Thanks a lot! mcc On Tue, May 16, 2006 at 07:12:01PM +0200, A.J.Mechelynck wrote: Meino Christian Cramer wrote: for what keyword I have to look in the online-help to find a hint how to copy any text from a buffer as any part of a command currently being edited in the commandline ? If by buffer you mean what the Vim docs call a register, see :help c_CTRL-R. If you mean part of a file being edited, IMHO the easiest way is to yank it beforehand into a register, though in some cases you can use the expression register (Ctrl-R =) with e.g. expressions such as getline(.) For shortcuts to inserting files and words on the commandline see the section described here: :help c_C-R_C-F -- with kind regards Thor Andreassen
gvim when x server is shut down
when i exit my wm (e16), since it doesn't (and shouldn't) close any other programs, gvim is stuck without an x server, and doesn't handle this loss gracefully. effectively, it's as if it was kill -9'ed ... and thus leaves temporary files behind, which i later have to labouriously clean up. can it not do something better like simply close down if no changes were made to the file (and close any temp files). and, i guess, leave the temp files behind if changes were made (as it currently does in all cases :\).
right-to-left text selection
Ok, I have a really weird questions this time. I use the selection=exclusive option, because I don't like Vim to select the hidden newline character at the end of lines when I'm copying or deleting an entire line. However, this has one side effect that I have not been able to figure out. If I try to select a line of text from the right to the left, it is impossible to select the last character of the line. Of course, one solution would be to set selection=inclusive, but then the newline character at the end of the line is always selected when selecting text from left to right. I know that sounds pretty trivial, but it's a major nuisance for my editing style. So, my question: is it somehow possible to be able to select the last character of a line when selecting from right-to-left while using selection=exclusive? Alternatively, is there some way to make Vim NOT select the newline character at the end of the line when selecting text from left-to-right while using selection=inclusive? At this point I've tried quite a few options and I'm thinking it's not, but I'd certainly like to hear from the pros if they have any suggestions. Does this even make sense? Given how many times I used the word select, probably not. :-) Please let me know if this comes across as gibberish and I'll try to better explain myself. Thanks! -- Jared
Re: gvim when x server is shut down
On Wed, 17 May 2006, Dennis Nezic wrote: when i exit my wm (e16), since it doesn't (and shouldn't) close any other programs, gvim is stuck without an x server, and doesn't handle this loss gracefully. effectively, it's as if it was kill -9'ed ... and thus leaves temporary files behind, which i later have to labouriously clean up. can it not do something better like simply close down if no changes were made to the file (and close any temp files). and, i guess, leave the temp files behind if changes were made (as it currently does in all cases :\). You could try something like :au VimLeave * if v:dying | quitall! | endif if it helps. See :help v:dying. HTH. -- Gerald
