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
