UTL plugin query
Hi All, I'm using the UTL plugin to navigate local files. I have a markdown formatted file (which should not affect things), and a list of files in a directory * file.txt * other.txt When the cursor is on one of the files, leadergu opens it, which is the desired effect. However sometimes it is opened in the current window, and sometimes the window is split. I can't seem to find why this happens, but it seems file dependent. Any help? Sam
Re: UTL plugin query
* file.txt * other.txt Why not simply use gf in such a situation? The (shameless plug) viki plugin also provides advanced hyperlinking facilities. Thomas.
conceal-ownsyntax vim7-patches: 1-158 errors
Hi all I can't patch vim with conceal-ownsyntax. The patch it's applied with only 2 errors patching file src/spell.c Hunk #14 FAILED at 2042. Hunk #24 FAILED at 9271. Someone here ecountered the same problem? The real problems is because I don't know how to program in C , i do ok with './configure' and 'make' but that is all I can do. If some kind soul can take a look at the problem I'll appreciate the help. Thanks in advance P.S patch taken from http://vince.negri.googlepages.com/conceal-ownsyntax.diff
Re: UTL plugin query
Hi, Sam, On Tue, Nov 07, 2006 at 11:27:33AM +, Samuel Wright wrote: Hi All, I'm using the UTL plugin to navigate local files. I have a markdown formatted file (which should not affect things), and a list of files in a directory * file.txt * other.txt When the cursor is on one of the files, leadergu opens it, which is the desired effect. However sometimes it is opened in the current window, and sometimes the window is split. I can't seem to find why this happens, but it seems file dependent. Supposably the file containing these two references is modified!? \gu opens in the current window unless the current buffer cannot be abandoned ( see URL:vimhelp:abandon ). This is a feature, in order to avoid annoying No write since last change vim messages ( see URL:vimhelp:E37 ). If interested, see utl.vim, lines 785 - 791, for the code that handles this behaviour. You can just remove these lines if you do not like this smart open feature. Any help? Sam HTH, Stefan
vim.org refreshed mockup
I made a mockup of a refreshed version of vim.org, trying to maintain as much of the original look as possible: http://panos.solhost.org/mockups/vimorg-01.png vim tangofied icon by toZth -- Panos Laganakos
Re: active links for opening files
Hi Michal, On Fri, Nov 03, 2006 at 11:49:19PM +0100, Michael M. Tung wrote: Hi Samuel: Thanks for the link to GtdWithVim! Actually I saw it on the vim script site just after writing my hack. I didn't have a chance yet to try it out, but as far as I understand from the script description it's philosophy is quite different. GtdWithVim seems to work independently from any external program. With vimGTD I just wanted to quickly write a frontend to PyGTD. So all the power is in there... I use vimGTD in mutt and it works well. The UTL plugin sounds great stuff. Maybe it also resolves some of my other problems with various links in email which I want to combine with external launchers. The upcoming version utl.vim V2.1 will support preliminary support to reference emails via a new mail: URL like URL:mail:///Inbox?07.11.2006 18:38 This would open the email which you received on the specific date. Other example: URL:mail:///Sent Items?07.11.2006 18:40 . Currently I only have an implementation for MS-Outlook (which is implemented using OLE Automation via Visual Basic Script). It seems you are using the mutt mailer though. Anyway, I would be interested to know what you mean with other problems with various links in emails...; perhaps we can dicuss some requirements. An implementation for mutt mailer / mbox format should not be to difficult then. Regards, Stefan If you want to get in touch with me about some more thoughts, just write me directly to [EMAIL PROTECTED] Best, Mike Samuel Wright [EMAIL PROTECTED] wrote: Hi Michal, I notice you are working on a GTD plugin. Have you tried the existing plugin? http://www.bartholomew.id.au/projects/Project.aspx?ProjectCode=GtdWithVim The other thing of interest (perhaps) is vim outliner I started playing around with that a few days ago. Mor sepcifically regarding your questions, the UTL plugin lets you open plain text 'links' including emails, and other files. I'd be interested to swap thoughts on where you are going with GTD on vim. S -- - Dr. Michael M. Tung Email: [EMAIL PROTECTED] Departamento de Matemática Aplicada [EMAIL PROTECTED] Universidad Politécnica de Valencia Phone: +34 96 3877000 x88287 Inst. de Matemática Multidisciplinar+34 96 38-79777 Edificio 8-G, 2º pisoIM: ICQ96423950 Camino de Vera, s/n 46022 Valencia (Spain) http://www.uv.es/~tung/ - PGP Public Key http://personales.upv.es/mictun/mtung_pubkey.pgp - --
Re: gvim cut paste selection
Ujjal, Although it fixed the problem (or perhaps only masked it, as the underlying problem is with Cygwin X), the patch I submitted to Vim was rejected. Bram maintained that since the bug pertained to Cygwin XWindows, so should the fix. I actually did not disagree with him on this point. The reason I had started with Vim rather than XWindows was that I was more familiar with Vim's source code. However, since Bram refused to incorporate the patch, I proceeded to post to the XWindows list. It was suggested that I write a patch and submit it. I wrote a patch, and Colin Harrison (who was more familiar with the patch submission process) tested the patch and submitted it to the Bugzilla bug tracking database. I also tested on my own PC running Cygwin X and gVim compiled from unix sources. Months after patch submission, the patch was accepted and the issue changed to FIXED / RESOLVED. I have not yet checked to see whether the patch has actually been rolled into the most recently released version of XWin. You can see a full description of the bug and how I fixed it by reading the thread below. Also, I've included the link to the Bugzilla submission page, so you can obtain and apply the Xwin patch if you like. Alternatively, you could obtain and apply the Vim patch, but since it's not likely ever to find its way into Vim (and really is kind of a kludge anyways), I'd recommend the former approach... Hope this helps, Brett Stahlman Thread subject: Serious flaw in Cygwin X clipboard integration prevents paste from X to Windows app http://www.cygwin.com/ml/cygwin-xfree/2006-01/msg00030.html Bugzilla entry 5375: https://bugs.freedesktop.org/show_bug.cgi?id=5735 - Original Message - From: Ujjal Bose To: [EMAIL PROTECTED] Sent: Tuesday, November 07, 2006 3:16 AM Subject: Fwd: gvim cut paste selection Hi, I saw ur patch that you have posted to the URL mentioned below. So will the same patch work for a unix vim or is it only for Win32 ? As you can see from the thread below that I am also facing similar problems , but from Unix Gvim Windows Apps. Thanks, Ujjal Forwarded Conversation Subject: gvim cut paste selection From: Ujjal Bose [EMAIL PROTECTED] To: vim@vim.org Date: Sat, Nov 4, 2006 at 9:30 PM Hi , I was having problem with cut-paste selections from X - Windows for gvim (6.2) , and this is the reply I got from the RealVNC team . So is there a way to solve this in gvim ? Thanks in advance ! -Ujjal -- Forwarded message -- From: James Weatherall [EMAIL PROTECTED] Date: Nov 3, 2006 9:59 PM Subject: RE: Xvnc cut paste problem To: Ujjal Bose [EMAIL PROTECTED], [EMAIL PROTECTED] Hi Ujjal, It sounds like gvim doesn't set the timestamp on the X selection correctly when it sets it, so vncconfig doesn't think it's changed. Selecting text in another X application, then selecting the desired text in gvim should cause vncconfig to see the selection ownership change and to then send the gvim text to the viewer. Cheers, Wez @ RealVNC Ltd. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] ] On Behalf Of Ujjal Bose Sent: 01 November 2006 19:09 To: [EMAIL PROTECTED] Subject: Xvnc cut paste problem For the laste few days my cut paste selections from Unix-Windows is not working properly but Windows-Unix works perfectly. I was using autocutsel to enable cut-paste between various X11 selections, and also had a line for vncconfig -nowin -iconic in my VNC xstartup file but nothing seems to help. 0) I am using Xvnc 4.2.1 server in my Linux m/c and TightVNC viewer on Windows XP side. 1) A Copy selection from a unix application (gvim) seems to work intermittently. 2) If I do a mouse based visual selection (also called PRIMARY selection in X11) from my gvim windows , and paste it in Windows notepad, only a partial paste happens for the first time, and then onwards , the same stuff is pasted over and over again, in spite of selecting some other text in gvim. 3) Pasting from xterm-Notepad(Windows) seems to work correctly. 4) I even started a new VNC session on another Linux m/c (same xstartup file) but didnt help. 5) Another thing I observed : from gvim , irrespective of my selection method (copy or mouse based) , the paste in Notepad seems to work only (partially in case of mouse selection and fully in case of Copy) for the first time. If I select something else now and then try to paste , the last stuff only gets pasted. BUT IF I COPY BACK SOME TEXT FROM WINDOWS-UNIX and then try again , IT WORKS FOR THE NEW SELECTION , but again , only for once, till I repeat the process. 6) Again, pasting from xterm always works perfectly. Any help appreciated. -Ujjal # My xstartup file vncconfig -nowin if ($OSTYPE == Linux) then # Linux xrdb $HOME/.Xresources \xterm -geometry 80x24+10+10 -ls -title $VNCDESKTOP Desktop #/usr/bin/gnome-session #/usr/bin/startkde #fvwm2
RE: vim.org refreshed mockup
I made a mockup of a refreshed version of vim.org, trying to maintain as much of the original look as possible: http://panos.solhost.org/mockups/vimorg-01.png vim tangofied icon by toZth Uhhh, light-gray text on a gray/white checkerboard background? Ouch... Just my 2c worth, maybe ditch the checkerboard background, as it makes even clear dark text harder to see (and makes my head hurt). Gray text simply vanishes. Other'n that, it looks nice.
Re: gvim cut paste selection
On 11/8/06, Stahlman Family [EMAIL PROTECTED] wrote: Ujjal, Although it fixed the problem (or perhaps only masked it, as the underlying problem is with Cygwin X), the patch I submitted to Vim was rejected. Bram maintained that since the bug pertained to Cygwin XWindows, so should the fix. I actually did not disagree with him on this point. The reason I had started with Vim rather than XWindows was that I was more familiar with Vim's source code. However, since Bram refused to incorporate the patch, I proceeded to post to the XWindows list. It was suggested that I write a patch and submit it. I wrote a patch, and Colin Harrison (who was more familiar with the patch submission process) tested the patch and submitted it to the Bugzilla bug tracking database. I also tested on my own PC running Cygwin X and gVim compiled from unix sources. Months after patch submission, the patch was accepted and the issue changed to FIXED / RESOLVED. I have not yet checked to see whether the patch has actually been rolled into the most recently released version of XWin. You can see a full description of the bug and how I fixed it by reading the thread below. Also, I've included the link to the Bugzilla submission page, so you can obtain and apply the Xwin patch if you like. Alternatively, you could obtain and apply the Vim patch, but since it's not likely ever to find its way into Vim (and really is kind of a kludge anyways), I'd recommend the former approach... Hope this helps, Brett Stahlman Thread subject: Serious flaw in Cygwin X clipboard integration prevents paste from X to Windows app http://www.cygwin.com/ml/cygwin-xfree/2006-01/msg00030.html Bugzilla entry 5375: https://bugs.freedesktop.org/show_bug.cgi?id=5735 - Original Message - From: Ujjal Bose To: [EMAIL PROTECTED] Sent: Tuesday, November 07, 2006 3:16 AM Subject: Fwd: gvim cut paste selection Hi, I saw ur patch that you have posted to the URL mentioned below. So will the same patch work for a unix vim or is it only for Win32 ? As you can see from the thread below that I am also facing similar problems , but from Unix Gvim Windows Apps. Thanks, Ujjal Hi Brett, I tested your vim patch on my machine and its working for me in Unix, after removing the ifdef WIN32 macros from the patch. Now cut/paste across gvim (unix) -- Windows apps is perfect ! As noted earlier by Brett, this may not be the best approach, but it pretty much solves my problem :) Thanks to Brett and Yakov ! -Ujjal
RE: vim.org refreshed mockup
http://panos.solhost.org/mockups/vimorg-01.png Uhhh, light-gray text on a gray/white checkerboard background? Ouch... I musta missed something - no checkerboard here. Looks nice! Hang on a sec... Just looked at it again from the above link, and yeah, it's a white checkerboard pattern, 'though the gray matches the background of the viewer (M$ Photo Editor? whatever comes out-of-the-box on LoseXP), so it might be a transparency color/layer that just lets the background poke through. If it's a .png, maybe it's something with the alpha channel being set, like the transparency color of GIF89A (also usually bright-white, fwiw)? No idea, no time to look in more detail. White on white wouldn't be discernable, but on a darker background (even light gray, as I have here; a blinding-white background fries my retinas), it shows up a *lot*. Washes out the light-gray text almost completely. If it were me, I'd just check the background graphic, if any, on the actual site. But that's just me... ;)
Re: gvim cut paste selection
On 11/5/06, Bram Moolenaar [EMAIL PROTECTED] wrote: Ujjal Bose wrote: I was having problem with cut-paste selections from X - Windows for gvim (6.2) , and this is the reply I got from the RealVNC team . So is there a way to solve this in gvim ? Thanks in advance ! -Ujjal -- Forwarded message -- From: James Weatherall [EMAIL PROTECTED] Date: Nov 3, 2006 9:59 PM Subject: RE: Xvnc cut paste problem To: Ujjal Bose [EMAIL PROTECTED], [EMAIL PROTECTED] Hi Ujjal, It sounds like gvim doesn't set the timestamp on the X selection correctly when it sets it, so vncconfig doesn't think it's changed. Selecting text in another X application, then selecting the desired text in gvim should cause vncconfig to see the selection ownership change and to then send the gvim text to the viewer. Cheers, Wez @ RealVNC Ltd. This is a known problem that nobody has found a solution for yet. The Time type is some special kind of timestamp. I don't even know how to get the timestamp for now. That's why CurrentTime is used. Getting the timestamp from an event (e.g. a mouse click) is not always possible (e.g., in an xterm we don't get it) and certainly difficult to pass all the way from the input to the selection. Problem with Xvnc is that they stick to the specification instead of to what applications do in practice. Bram, I know how to fill the correct non-0 time in own_selection() for xterm clipbpard and for Xt gui (we need to generate dummy self-NotifyEvent to get timestamp). I did not know how to do it for gtk, but looks like Brett have the solution for gtk. What do you say about adding option xcliptime with values 0=use 0L timestamp, 1=fill non-0 timestamp ? It might be even possible to auto-guess whether server supports 0L timestamp in OwnSelection (can be xcliptime==2). Yakov
Re: vim.org refreshed mockup
On 11/7/06, Gene Kwiecinski [EMAIL PROTECTED] wrote: Just looked at it again from the above link, and yeah, it's a white checkerboard pattern, 'though the gray matches the background of the viewer (M$ Photo Editor? whatever comes out-of-the-box on LoseXP), so it might be a transparency color/layer that just lets the background poke through. Why are you looking at it outside of a browser it's a URL
RE: Search all text files in a directory for text
Sorry to bring this up again. Was there every any solution to this? Do I just need the latest netrw? I was trying to get :Explore **/pattern working But as I do see the Match n of N in the lower right, the cursor never moves in the browse buffer (with S-Down/S-Up) and occasionally I get errors: Error detected while processing function netrw#Explore: line 165: E121: Undefined variable: w:netrw_longlist E15: Invalid expression: w:netrw_longlist == 0 || w:netrw_longlist == 1 I'm using vim7.0 (2006 may 7), and tried this with -N -u NONE. Maybe someone here knows how to get this working? -Original Message- From: Gary Johnson [mailto:[EMAIL PROTECTED] Sent: Monday, August 28, 2006 1:14 PM To: vim@vim.org Subject: Re: Search all text files in a directory for text FWIW, I just tried this on Windows using vim-7.0 without patches, downloaded from vim.sf.net, and netrw 103g. I started vim from the Command Prompt in a directory that contained one Python file and a number of subdirectories, each containing several Python files. vim -N -u NONE -i NONE :runtime plugin/netrwPlugin.vim :Explore **/*.py Error detected while processing function netrw#Explore: line 178: E63: invalid use of \_ the buffer was empty and the status line contained Match 1 of 222. Regards, Gary -- Gary Johnson | Agilent Technologies [EMAIL PROTECTED] | Wireless Division | Spokane, Washington, USA
Re: vim.org refreshed mockup
Panos Laganakos wrote: I made a mockup of a refreshed version of vim.org, trying to maintain as much of the original look as possible: http://panos.solhost.org/mockups/vimorg-01.png vim tangofied icon by toZth Well, I don't see any checkerboard pattern, but I do find dark grey text on a dark blue background a bit difficult. Seems like something isn't being specified in the display. Regards, Chip Campbell
Re: Search all text files in a directory for text
Chuck Mason wrote: Sorry to bring this up again. Was there every any solution to this? Do I just need the latest netrw? I was trying to get :Explore **/pattern working But as I do see the Match n of N in the lower right, the cursor never moves in the browse buffer (with S-Down/S-Up) and occasionally I get errors: Error detected while processing function netrw#Explore: line 165: E121: Undefined variable: w:netrw_longlist E15: Invalid expression: w:netrw_longlist == 0 || w:netrw_longlist == 1 I'm using vim7.0 (2006 may 7), and tried this with -N -u NONE. Maybe someone here knows how to get this working? netrw is up to v107g (Nov 03, 2006). I suggest upgrading! You'll also need an up-to-date version of vimball to extract netrw, which is also available at: http://vim.sourceforge.net/scripts/script.php?script_id=1502 -or- http://mysite.verizon.net/astronaut/vim/index.html#VimFuncs see Vimball Archiver Also, to make these new plugins work, you first need to completely remove all older vestiges of netrw and vimball from your runtimepath. Under Linux, that usually means cd /usr/local/share/vim/vim70 /bin/rm plugin/netrw*.vim plugin/vimball*.vim /bin/rm autolaod/netrw*.vim autoload/vimball*.vim Under Windows, check your runtimepath to determine where your vim 7.0's runtime directories are: vim :echo rtp :q should give you a clue. Regards, Chip Campbell
Re: vim.org refreshed mockup
On 11/7/06, Charles E Campbell Jr [EMAIL PROTECTED] wrote: Well, I don't see any checkerboard pattern, but I do find dark grey text on a dark blue background a bit difficult. Seems like something isn't being specified in the display. Funny, I don't see any dark blue background in the image at all. I do see light grey text on white background for the dates which is hard to read as are the light green links to the bottom right of each post. I don't mind pastellized (sp?) colours and the rounded corners, but a little darker text on those items would help immensely. Overall very simple clean layout which I like. Of course it needs a rotating (and maybe flashing) gif or two doesn't it? :)
Re: vim.org refreshed mockup
On 11/7/06, Brian McKee [EMAIL PROTECTED] wrote: It's IE that adds the dark blue I think Brian Yeah. Just checked. It shows a blue background instead of white in IE6. I assume it's just a .png support problem.
Re: gvim cut paste selection
Yakov Lerner wrote: On 11/5/06, Bram Moolenaar [EMAIL PROTECTED] wrote: Ujjal Bose wrote: I was having problem with cut-paste selections from X - Windows for gvim (6.2) , and this is the reply I got from the RealVNC team . So is there a way to solve this in gvim ? Thanks in advance ! -Ujjal -- Forwarded message -- From: James Weatherall [EMAIL PROTECTED] Date: Nov 3, 2006 9:59 PM Subject: RE: Xvnc cut paste problem To: Ujjal Bose [EMAIL PROTECTED], [EMAIL PROTECTED] Hi Ujjal, It sounds like gvim doesn't set the timestamp on the X selection correctly when it sets it, so vncconfig doesn't think it's changed. Selecting text in another X application, then selecting the desired text in gvim should cause vncconfig to see the selection ownership change and to then send the gvim text to the viewer. Cheers, Wez @ RealVNC Ltd. This is a known problem that nobody has found a solution for yet. The Time type is some special kind of timestamp. I don't even know how to get the timestamp for now. That's why CurrentTime is used. Getting the timestamp from an event (e.g. a mouse click) is not always possible (e.g., in an xterm we don't get it) and certainly difficult to pass all the way from the input to the selection. Problem with Xvnc is that they stick to the specification instead of to what applications do in practice. Bram, I know how to fill the correct non-0 time in own_selection() for xterm clipbpard and for Xt gui (we need to generate dummy self-NotifyEvent to get timestamp). I did not know how to do it for gtk, but looks like Brett have the solution for gtk. What do you say about adding option xcliptime with values 0=use 0L timestamp, 1=fill non-0 timestamp ? It might be even possible to auto-guess whether server supports 0L timestamp in OwnSelection (can be xcliptime==2). I don't like using an option for something that is actually something system-dependent. It's like telling the user we are incapable to figure it out so he has to do all the work to figure out how it should work himself. As mentioned before, using CurrentTime for the timestamp, as we do now, should work anyway. -- If Microsoft would build a car... ... Occasionally your car would die on the freeway for no reason. You would have to pull over to the side of the road, close all of the car windows, shut it off, restart it, and reopen the windows before you could continue. For some reason you would simply accept this. /// 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: vim.org refreshed mockup
[EMAIL PROTECTED] wrote: I made a mockup of a refreshed version of vim.org, trying to maintain as much of the original look as possible: http://panos.solhost.org/mockups/vimorg-01.png A clear improvement. However, the light-gray text is hard to read. How about having a search form directly on every page, instead of having to go to a special page? Also, allow users to log in directly from the home page. /George -- /George V. Reilly [EMAIL PROTECTED] http://www.georgevreilly.com/blog The biggest mistake is not learning from all your other mistakes.
Re: gvim cut paste selection
- Original Message - From: Ujjal Bose [EMAIL PROTECTED] To: vim@vim.org Sent: Tuesday, November 07, 2006 1:19 PM Subject: Re: gvim cut paste selection On 11/8/06, Stahlman Family [EMAIL PROTECTED] wrote: Ujjal, Although it fixed the problem (or perhaps only masked it, as the underlying problem is with Cygwin X), the patch I submitted to Vim was rejected. Bram maintained that since the bug pertained to Cygwin XWindows, so should the fix. I actually did not disagree with him on this point. The reason I had started with Vim rather than XWindows was that I was more familiar with Vim's source code. However, since Bram refused to incorporate the patch, I proceeded to post to the XWindows list. It was suggested that I write a patch and submit it. I wrote a patch, and Colin Harrison (who was more familiar with the patch submission process) tested the patch and submitted it to the Bugzilla bug tracking database. I also tested on my own PC running Cygwin X and gVim compiled from unix sources. Months after patch submission, the patch was accepted and the issue changed to FIXED / RESOLVED. I have not yet checked to see whether the patch has actually been rolled into the most recently released version of XWin. You can see a full description of the bug and how I fixed it by reading the thread below. Also, I've included the link to the Bugzilla submission page, so you can obtain and apply the Xwin patch if you like. Alternatively, you could obtain and apply the Vim patch, but since it's not likely ever to find its way into Vim (and really is kind of a kludge anyways), I'd recommend the former approach... Hope this helps, Brett Stahlman Thread subject: Serious flaw in Cygwin X clipboard integration prevents paste from X to Windows app http://www.cygwin.com/ml/cygwin-xfree/2006-01/msg00030.html Bugzilla entry 5375: https://bugs.freedesktop.org/show_bug.cgi?id=5735 - Original Message - From: Ujjal Bose To: [EMAIL PROTECTED] Sent: Tuesday, November 07, 2006 3:16 AM Subject: Fwd: gvim cut paste selection Hi, I saw ur patch that you have posted to the URL mentioned below. So will the same patch work for a unix vim or is it only for Win32 ? As you can see from the thread below that I am also facing similar problems , but from Unix Gvim Windows Apps. Thanks, Ujjal Hi Brett, I tested your vim patch on my machine and its working for me in Unix, after removing the ifdef WIN32 macros from the patch. Now cut/paste across gvim (unix) -- Windows apps is perfect ! As noted earlier by Brett, this may not be the best approach, but it pretty much solves my problem :) Ujjal, I'm glad you got it working. Although the XWin patch is probably the ideal solution, building Vim is probably easier than building XWin, and a working non-ideal solution is always better than none at all. However, I am meaning to download the latest XWin source distribution to see whether my patch is in it yet. When I see that it is, I'll notify the list, since there are probably other Vim users who have been affected by this... Brett Stahlman Thanks to Brett and Yakov ! -Ujjal
RE: vim.org refreshed mockup
Just looked at it again from the above link, and yeah, it's a white checkerboard pattern, 'though the gray matches the background of the viewer (M$ Photo Editor? whatever comes out-of-the-box on LoseXP), so it might be a transparency color/layer that just lets the background poke through. Why are you looking at it outside of a browser it's a URL ?? He posted a link to a *png* file, probably a snapshot pic of the site: http://panos.solhost.org/mockups/vimorg-01.png Wherever the problem lies, whether in the background pic, the .png file, M$PE on this machine here, or elsewhere, all I'm doing is pointing out that there's potentially a problem with viewability. If it looks good to y'all, great. Might be something different here than there that's giving me checkerboards. Only thing I can suggest in looking at the pic is to stick it on its own wrapper page where the background is anything *other* than #FF, then have a look-see.
Re: vim.org refreshed mockup
* Panos Laganakos [EMAIL PROTECTED] [2006-11-07T12:59:57] I made a mockup of a refreshed version of vim.org, trying to maintain as much of the original look as possible: http://panos.solhost.org/mockups/vimorg-01.png vim tangofied icon by toZth I like it. The light grey used in the dates/names in the sripts section is a bit too light for easy reading. I think that if the V icon is going to be used (as opposed to the (unofficial?) Vim icon), you should do SOMETHING to get Vim in the header. After all, it isn't V the editor. I think putting a on the left, instead of a on the right, will make the current selection clearer; otherwise it will move left and right and be harder to pick out. I liked the search on every page suggestion a lot. -- rjbs
Re: Search all text files in a directory for text
On 2006-11-07, Charles E Campbell Jr [EMAIL PROTECTED] wrote: Chuck Mason wrote: Sorry to bring this up again. Was there every any solution to this? Do I just need the latest netrw? I was trying to get :Explore **/pattern working But as I do see the Match n of N in the lower right, the cursor never moves in the browse buffer (with S-Down/S-Up) and occasionally I get errors: Error detected while processing function netrw#Explore: line 165: E121: Undefined variable: w:netrw_longlist E15: Invalid expression: w:netrw_longlist == 0 || w:netrw_longlist == 1 I'm using vim7.0 (2006 may 7), and tried this with -N -u NONE. Maybe someone here knows how to get this working? netrw is up to v107g (Nov 03, 2006). I suggest upgrading! I just updated to vim 7.0.161 from the Cream site and to netrw 107g from your (Chip's) web site. I don't know how to get anything more up-to-date than that. I renamed all the *netrw* files under vim70 with a .orig extension to hide them. I had already downloaded a recent vimball.vim, which is version 18a. Repeating my experiment, vim -N -u NONE -i NONE :runtime plugin/netrwPlugin.vim :Explore **/*.py from a Command Prompt in a directory with no .py files below it, yields Match 1 of 0 in the status line and the following messages: ***netrw*** no more files match Explore pattern Error detected while processing function netrw#Explore: line 192: E684: list index out of range: 0 E15: Invalid expression: w:netrw_explore_list[0] line 194: E121: Undefined variable: dirfile E116: Invalid arguments for function substitute(dirfile,'/[^/]*$','','e') E15: Invalid expression: substitute(dirfile,'/[^/]*$','','e') line 198: E121: Undefined variable: newdir E116: Invalid arguments for function netrw#LocalBrowseCheck line 203: E121: Undefined variable: dirfile E116: Invalid arguments for function substitute(dirfile,^.*/,,).'\',W) E116: Invalid arguments for function search Then I exited vim, cd'd to a directory with a bunch of .py files under it and repeated the commands above. This time there were no error messages and the status line said Match 1 of 394. However, the status line also showed a buffer name of [No Name] and the buffer itself was empty. HTH, Gary -- Gary Johnson | Agilent Technologies [EMAIL PROTECTED] | Wireless Division | Spokane, Washington, USA
Re: BufEnter Oddity After TabEnter
On Mon 6-Nov-06 11:02pm -0600, you wrote: There is not-a-solution-but-weird-workaround at http://www.vim.org/tips/tip.php?tip_id=1379 Tip #1379: make echo seen when it would otherwise disappear and go unseen Nice idea. I've expanded it a bit by changing the CursorHold to get rid of itself and restore the previous value of 'updatetime'. The following was added to your tip: The following is a self destructive version of the CursorHold autocmd. It also restores 'updatetime'. let s:Pecho='' fu! s:Pecho(msg) if ut!=11|let s:hold_ut=ut|let ut=11|en let s:Pecho=a:msg aug Pecho au CursorHold * if s:Pecho!=''|echo s:Pecho \|let s:Pecho=''|let ut=s:hold_ut|en \|aug Pecho|exe 'au!'|aug END|aug! Pecho aug END endf Test of above au! BufEnter foo call s:Pecho(Entered foo) Now even changing to foo in a different tab page will print the message. -- Best regards, Bill
Re: vim.org refreshed mockup
--- Ricardo SIGNES [EMAIL PROTECTED] wrote: * Panos Laganakos [EMAIL PROTECTED] [2006-11-07T12:59:57] I made a mockup of a refreshed version of vim.org, trying to maintain as much of the original look as possible: http://panos.solhost.org/mockups/vimorg-01.png vim tangofied icon by toZth I like it. The light grey used in the dates/names in the sripts section is a bit too light for easy reading. I think that if the V icon is going to be used (as opposed to the (unofficial?) Vim icon), you should do SOMETHING to get Vim in the header. After all, it isn't V the editor. No, 'V' is in fact an energy drink, quite well-known in Australia, so it's good to keep the whole 'Vim' name on the page! http://www.frucor.com/brands/aus/new_age.html regards, Peter Send instant messages to your online friends http://au.messenger.yahoo.com
Howto inserting multiline completefunc text?
I want the first completion entering
abc
def
and the second entering
2nd example
2nd lne
How to do this?
example (source this the following lines)
function! CompleteExample(findstart, base)
if a:findstart
locate the start of the word
let [bc,ac] = vl#lib#buffer#splitlineatcursor#SplitCurrentLineAtCursor()
return len(bc)-len(matchstr(bc,'\%(\a\|\.\|\$\|\^\)*$'))
else
call complete_add( { 'word' : abc\ndef
\ , 'abbr' : completion1
\ } )
call complete_add( { 'word' : 2nd exapmle\n2ndline
\ , 'abbr' : completion2
\ } )
endif
endfunction
set completefunc=CompleteExample
Marc
syn sync fromstart in modeline
How can I put the equivalent of :syn sync fromstart in a modeline for a file? Thank you, Alan Isaac
Spurious undefined variable error generated for certain valid ternary expressions
The following expression var10?var:10 generates the following errors: E121: Undefined variable: var:10 E15: Invalid expression: var10?var:10 The reason is that find_name_end uses eval_isnamec unconditionally to decide whether a character is a valid variable name character, with the result that `:' is always gobbled up as part of the variable name, even if it's not the second character in the name string (ie, even if it doesn't separate the scope prefix from the variable name). find_var_ht, on the other hand, will not permit a colon anywhere but at character index 1 in the variable name; hence, E121, and ultimately, E15. Since `:' is part of a valid VimL operator, and is not valid anywhere other than at index 1 in a non-curly-brace variable name, there is no ambiguity in the expression shown above. For expressions such as b10?b:a the ambiguity would be resolved according to the relative precedence of the ternary operator and the variable scope separator (`:'). I would assume that the precedence of the scope operator would be higher (since Vim treats it as part of 'variable', whose precedence is much higher than that of the ternary operator); hence, in the preceding example, the expression would be evaluated as (b10)?(b:a) which would indeed be a syntax error... Should eval_isnamec (or perhaps its caller) take into consideration the character index when deciding whether `:' is to be considered part of the variable name? Thanks, Brett Stahlman
Re: syn sync fromstart in modeline
Alan Isaac wrote: How can I put the equivalent of :syn sync fromstart in a modeline for a file? Thank you, Alan Isaac You can't. Modelines only allow setting options (and not all of them). :syn sync fromstart is not a :setlocal statement. Best regards, Tony.
Re: command line completion on several lines
koxinga wrote: koxinga wrote: Hello, [...] It won't work with multibyte. [...] Any feedback appreciated, of course ... koxinga No feedback at all ? Not even a nice you dumbass, it doesn't even compile or a this is not a feature, this is a bug, moron ? koxinga Anything doesn't work with multibyte, I'm not interested. UTF-8 is essential to my use of Vim. Best regards, Tony.
Creating a custom browser window.
Please forgive me if I use the incorrect terms ... I've been using vim for years, but am just now getting into more than just the editing part. I am writing a vim plugin using perl's Net::Blogger so I can make my blogs entries from vim. What I'd like to do, if possible, is create a window that lists the blogs and entries in a window like the one created when you try to edit a directory. You can move the cursor up and down but you can't modify the contents of the buffer. When you press enter on an entry it either displays the directory or edits the file. So, something like this initially: Blog1 Blog2 When you press enter on Blog1 you'll get: Blog1 Article1 Article2 Blog2 When you press enter on Article1 you'll get a buffer with the contents of Article1 to modify and repost. I've gotten the perl/vim interaction down I think, and I program in perl professionally--this isn't my problem. I have no idea as to how to go about doing the above. Any pointers? With VIm7 I think I can use the Lists and/or Dictionaries data types (they seem to be the same as perls array/list and hash types) but I'm just clueless on how to get the data into the buffer I described, or even how to create that buffer.
Patch 7.0.159
Patch 7.0.159
Problem:When there is an I/O error in the swap file the cause of the error
cannot be seen.
Solution: Use PERROR() instead of EMSG() where possible.
Files: src/memfile.c
*** ../vim-7.0.158/src/memfile.cWed Nov 1 18:10:36 2006
--- src/memfile.c Wed Nov 1 21:38:59 2006
***
*** 1028,1039
size = page_size * hp-bh_page_count;
if (lseek(mfp-mf_fd, offset, SEEK_SET) != offset)
{
! EMSG(_(E294: Seek error in swap file read));
return FAIL;
}
if ((unsigned)vim_read(mfp-mf_fd, hp-bh_data, size) != size)
{
! EMSG(_(E295: Read error in swap file));
return FAIL;
}
return OK;
--- 1028,1039
size = page_size * hp-bh_page_count;
if (lseek(mfp-mf_fd, offset, SEEK_SET) != offset)
{
! PERROR(_(E294: Seek error in swap file read));
return FAIL;
}
if ((unsigned)vim_read(mfp-mf_fd, hp-bh_data, size) != size)
{
! PERROR(_(E295: Read error in swap file));
return FAIL;
}
return OK;
***
*** 1085,1091
offset = (off_t)page_size * nr;
if (lseek(mfp-mf_fd, offset, SEEK_SET) != offset)
{
! EMSG(_(E296: Seek error in swap file write));
return FAIL;
}
if (hp2 == NULL)/* freed block, fill with dummy data */
--- 1085,1091
offset = (off_t)page_size * nr;
if (lseek(mfp-mf_fd, offset, SEEK_SET) != offset)
{
! PERROR(_(E296: Seek error in swap file write));
return FAIL;
}
if (hp2 == NULL)/* freed block, fill with dummy data */
*** ../vim-7.0.158/src/version.cWed Nov 1 21:24:58 2006
--- src/version.c Tue Nov 7 17:58:58 2006
***
*** 668,669
--- 668,671
{ /* Add new patch number below this line */
+ /**/
+ 159,
/**/
--
hundred-and-one symptoms of being an internet addict:
171. You invent another person and chat with yourself in empty chat rooms.
/// 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///
Patch 7.0.160
Patch 7.0.160
Problem::@a echoes the command, Vi doesn't do that.
Solution: Set the silent flag in the typeahead buffer to avoid echoing the
command.
Files: src/ex_docmd.c, src/normal.c, src/ops.c, src/proto/ops.pro
*** ../vim-7.0.159/src/ex_docmd.c Tue Oct 24 13:02:27 2006
--- src/ex_docmd.c Tue Nov 7 17:42:52 2006
***
*** 8219,8226
c = *eap-arg;
if (c == NUL || (c == '*' *eap-cmd == '*'))
c = '@';
! /* put the register in mapbuf */
! if (do_execreg(c, TRUE, vim_strchr(p_cpo, CPO_EXECBUF) != NULL) == FAIL)
{
beep_flush();
}
--- 8219,8227
c = *eap-arg;
if (c == NUL || (c == '*' *eap-cmd == '*'))
c = '@';
! /* Put the register in the typeahead buffer with the silent flag. */
! if (do_execreg(c, TRUE, vim_strchr(p_cpo, CPO_EXECBUF) != NULL, TRUE)
! == FAIL)
{
beep_flush();
}
*** ../vim-7.0.159/src/normal.c Tue Oct 17 22:40:14 2006
--- src/normal.cTue Nov 7 17:42:59 2006
***
*** 8860,8866
#endif
while (cap-count1-- !got_int)
{
! if (do_execreg(cap-nchar, FALSE, FALSE) == FAIL)
{
clearopbeep(cap-oap);
break;
--- 8860,8866
#endif
while (cap-count1-- !got_int)
{
! if (do_execreg(cap-nchar, FALSE, FALSE, FALSE) == FAIL)
{
clearopbeep(cap-oap);
break;
*** ../vim-7.0.159/src/ops.cTue Oct 17 16:26:52 2006
--- src/ops.c Tue Nov 7 17:52:30 2006
***
*** 95,102
static void block_insert __ARGS((oparg_T *oap, char_u *s, int b_insert,
struct block_def*bdp));
#endif
static intstuff_yank __ARGS((int, char_u *));
! static void put_reedit_in_typebuf __ARGS((void));
! static intput_in_typebuf __ARGS((char_u *s, int colon));
static void stuffescaped __ARGS((char_u *arg, int literally));
#ifdef FEAT_MBYTE
static void mb_adjust_opend __ARGS((oparg_T *oap));
--- 95,102
static void block_insert __ARGS((oparg_T *oap, char_u *s, int b_insert,
struct block_def*bdp));
#endif
static intstuff_yank __ARGS((int, char_u *));
! static void put_reedit_in_typebuf __ARGS((int silent));
! static intput_in_typebuf __ARGS((char_u *s, int colon, int silent));
static void stuffescaped __ARGS((char_u *arg, int literally));
#ifdef FEAT_MBYTE
static void mb_adjust_opend __ARGS((oparg_T *oap));
***
*** 1120,1129
* return FAIL for failure, OK otherwise
*/
int
! do_execreg(regname, colon, addcr)
int regname;
int colon; /* insert ':' before each line */
int addcr; /* always add '\n' to end of line */
{
static intlastc = NUL;
long i;
--- 1120,1130
* return FAIL for failure, OK otherwise
*/
int
! do_execreg(regname, colon, addcr, silent)
int regname;
int colon; /* insert ':' before each line */
int addcr; /* always add '\n' to end of line */
+ int silent; /* set silent flag in typeahead
buffer */
{
static intlastc = NUL;
long i;
***
*** 1173,1181
/* When in Visual mode ',' will be prepended to the command.
* Remove it when it's already there. */
if (VIsual_active STRNCMP(p, ',', 5) == 0)
! retval = put_in_typebuf(p + 5, TRUE);
else
! retval = put_in_typebuf(p, TRUE);
}
vim_free(p);
}
--- 1174,1182
/* When in Visual mode ',' will be prepended to the command.
* Remove it when it's already there. */
if (VIsual_active STRNCMP(p, ',', 5) == 0)
! retval = put_in_typebuf(p + 5, TRUE, silent);
else
! retval = put_in_typebuf(p, TRUE, silent);
}
vim_free(p);
}
***
*** 1186,1192
p = get_expr_line();
if (p == NULL)
return FAIL;
! retval = put_in_typebuf(p, colon);
vim_free(p);
}
#endif
--- 1187,1193
p = get_expr_line();
if (p == NULL)
return FAIL;
! retval = put_in_typebuf(p, colon, silent);
vim_free(p);
}
#endif
***
*** 1198,1204
EMSG(_(e_noinstext));
return FAIL;
}
! retval = put_in_typebuf(p, colon);
vim_free(p);
}
else
--- 1199,1205
EMSG(_(e_noinstext));
return FAIL;
}
! retval = put_in_typebuf(p, colon, silent);
vim_free(p);
}
else
***
*** 1213,1232
/*
* Insert lines into typeahead buffer, from last one to first one.
*/
!
Flickering of completion menu
Hi!
As you've probably all noticed the completion menu flickers when you
move through the items rapidly. Why is this? Is it really necessary
to redraw the whole completion menu when it really only should require
redrawing the item previously selected and the item selected now [1]?
Anyway, would this be possible to implement?
Also, here's a set of mappings that make the digits move their value
number of items down the completion list (if displayed):
for digit in [1, 2, 3, 4, 5, 6, 8, 9]
execute 'inoremap silent ' . digit . ' C-R=pumvisible() ? ' .
repeat('\ltC-N', digit) . ' : ' . digit . 'CR'
endfor
(I guess this could be extended to include -n, for 1 = n = 9, which
would move n number of items upward. Any takers?)
It flickers like mad, but at least it goes a lot faster than holding
down CTRL-N or CTRL-P.
nikolai
[1] Excepting the case where one begins to scroll in the menu, when
all items need to be redrawn, as they move up or down one step - which
leads to a second question, wouldn't it be a lot more economical to
scroll like half a menu or something, so that scrolling wouldn't
require so many redraws? Or at least utilize the terminal codes that
enable scrolling in a buffer to be done with only redrawing the first
or last line when scrolling by a single line in a buffer?
Patch 7.0.161
Patch 7.0.161
Problem:Win32: Tab pages line popup menu isn't using the right encoding.
(Yongwei Wu)
Solution: Convert the text when necessary. Also fixes the Find/Replace
dialog title. (Yegappan Lakshmanan)
Files: src/gui_w48.c
*** ../vim-7.0.160/src/gui_w48.cTue Aug 29 21:30:15 2006
--- src/gui_w48.c Tue Nov 7 19:03:52 2006
***
*** 2217,2226
#if defined(FEAT_GUI_TABLINE) || defined(PROTO)
static void
show_tabline_popup_menu(void)
{
HMENU tab_pmenu;
- MENUITEMINFOminfo;
long rval;
POINT pt;
--- 2217,2270
#if defined(FEAT_GUI_TABLINE) || defined(PROTO)
static void
+ add_tabline_popup_menu_entry(HMENU pmenu, UINT item_id, char_u *item_text)
+ {
+ #ifdef FEAT_MBYTE
+ WCHAR *wn = NULL;
+ int n;
+
+ if (enc_codepage = 0 (int)GetACP() != enc_codepage)
+ {
+ /* 'encoding' differs from active codepage: convert menu name
+* and use wide function */
+ wn = enc_to_ucs2(item_text, NULL);
+ if (wn != NULL)
+ {
+ MENUITEMINFOW infow;
+
+ infow.cbSize = sizeof(infow);
+ infow.fMask = MIIM_TYPE | MIIM_ID;
+ infow.wID = item_id;
+ infow.fType = MFT_STRING;
+ infow.dwTypeData = wn;
+ infow.cch = (UINT)wcslen(wn);
+ n = InsertMenuItemW(pmenu, item_id, FALSE, infow);
+ vim_free(wn);
+ if (n == 0 GetLastError() == ERROR_CALL_NOT_IMPLEMENTED)
+ /* Failed, try using non-wide function. */
+ wn = NULL;
+ }
+ }
+
+ if (wn == NULL)
+ #endif
+ {
+ MENUITEMINFOinfo;
+
+ info.cbSize = sizeof(info);
+ info.fMask = MIIM_TYPE | MIIM_ID;
+ info.wID = item_id;
+ info.fType = MFT_STRING;
+ info.dwTypeData = item_text;
+ info.cch = (UINT)STRLEN(item_text);
+ InsertMenuItem(pmenu, item_id, FALSE, info);
+ }
+ }
+
+ static void
show_tabline_popup_menu(void)
{
HMENU tab_pmenu;
long rval;
POINT pt;
***
*** 2236,2256
if (tab_pmenu == NULL)
return;
! minfo.cbSize = sizeof(MENUITEMINFO);
! minfo.fMask = MIIM_TYPE|MIIM_ID;
! minfo.fType = MFT_STRING;
!
! minfo.dwTypeData = _(Close tab);
! minfo.wID = TABLINE_MENU_CLOSE;
! InsertMenuItem(tab_pmenu, TABLINE_MENU_CLOSE, FALSE, minfo);
!
! minfo.dwTypeData = _(New tab);
! minfo.wID = TABLINE_MENU_NEW;
! InsertMenuItem(tab_pmenu, TABLINE_MENU_NEW, FALSE, minfo);
!
! minfo.dwTypeData = _(Open tab...);
! minfo.wID = TABLINE_MENU_OPEN;
! InsertMenuItem(tab_pmenu, TABLINE_MENU_OPEN, FALSE, minfo);
GetCursorPos(pt);
rval = TrackPopupMenuEx(tab_pmenu, TPM_RETURNCMD, pt.x, pt.y, s_tabhwnd,
--- 2280,2289
if (tab_pmenu == NULL)
return;
! add_tabline_popup_menu_entry(tab_pmenu, TABLINE_MENU_CLOSE, _(Close
tab));
! add_tabline_popup_menu_entry(tab_pmenu, TABLINE_MENU_NEW, _(New tab));
! add_tabline_popup_menu_entry(tab_pmenu, TABLINE_MENU_OPEN,
!_(Open tab...));
GetCursorPos(pt);
rval = TrackPopupMenuEx(tab_pmenu, TPM_RETURNCMD, pt.x, pt.y, s_tabhwnd,
***
*** 2455,2460
--- 2488,2517
}
#endif
+ static void
+ set_window_title(HWND hwnd, char *title)
+ {
+ #ifdef FEAT_MBYTE
+ if (title != NULL enc_codepage = 0 enc_codepage != (int)GetACP())
+ {
+ WCHAR *wbuf;
+ int n;
+
+ /* Convert the title from 'encoding' to ucs2. */
+ wbuf = (WCHAR *)enc_to_ucs2((char_u *)title, NULL);
+ if (wbuf != NULL)
+ {
+ n = SetWindowTextW(hwnd, wbuf);
+ vim_free(wbuf);
+ if (n != 0 || GetLastError() != ERROR_CALL_NOT_IMPLEMENTED)
+ return;
+ /* Retry with non-wide function (for Windows 98). */
+ }
+ }
+ #endif
+ (void)SetWindowText(hwnd, (LPCSTR)title);
+ }
+
void
gui_mch_find_dialog(exarg_T *eap)
{
***
*** 2470,2477
s_findrep_hwnd = FindText((LPFINDREPLACE) s_findrep_struct);
}
! (void)SetWindowText(s_findrep_hwnd,
! (LPCSTR)_(Find string (use '' to find a '\\')));
(void)SetFocus(s_findrep_hwnd);
s_findrep_is_find = TRUE;
--- 2527,2534
s_findrep_hwnd = FindText((LPFINDREPLACE) s_findrep_struct);
}
! set_window_title(s_findrep_hwnd,
! _(Find string (use '' to find a '\\')));
(void)SetFocus(s_findrep_hwnd);
s_findrep_is_find = TRUE;
***
*** 2495,2502
s_findrep_hwnd = ReplaceText((LPFINDREPLACE) s_findrep_struct);
}
! (void)SetWindowText(s_findrep_hwnd,
! (LPCSTR)_(Find Replace
Current buffer name after :python os.chdir()
Assuming the current buffer is the file 'foobar' in the current directory. After running the following Vim commands: :python import os :python os.chdir(subdir) the current buffer name is not changed as it is when you run the Vim command ':cd subdir' (but the output of ':pwd' is Ok), and when the following command is run afterwards: :write Vim writes the buffer to the file 'subdir/foobar', instead of the original file. This happens with Vim 7.0 compiled with Python 2.5. Xavier -- http://clewn.sourceforge.net gdb support in Vim
[RFC] Add a new getAnno function to the netbeans protocol
During the compile-debug-edit development cycle, the signs placed in the Vim buffers by the IDE with the netbeans protocol can have their line numbers changed when the buffers are edited (a Vim sign sticks with the line it has been set upon, and moves with it). It would be nice to allow the IDE to query Vim for these updated line numbers, so that when the IDE restarts gdb after a new make and the IDE is capable of restoring the breakpoints set on a previous session, the breakpoints and their corresponding signs can be automatically set by the IDE to their new position. The netbeans function documentation can be: === 10.4 Functions and Replies *nb-functions* getAnno serNum Return the line number of the annotation in the buffer Arguments: serNum serial number of this placed annotation The reply is: lnum = line number of the annotation === The implementation can be based on the existing sign_list_placed() function in buffer.c. I can propose a patch if this request for change is acceptable. Xavier -- http://clewn.sourceforge.net gdb support in Vim
Re: Current buffer name after :python os.chdir()
Xavier de Gaye wrote: Assuming the current buffer is the file 'foobar' in the current directory. After running the following Vim commands: :python import os :python os.chdir(subdir) the current buffer name is not changed as it is when you run the Vim command ':cd subdir' (but the output of ':pwd' is Ok), and when the following command is run afterwards: :write Vim writes the buffer to the file 'subdir/foobar', instead of the original file. This happens with Vim 7.0 compiled with Python 2.5. Well, you should not use Python to change directory. But it may happen unintentionally... Checking the current directory after each :python command is a bit inefficient, but that's probably what needs to be done then. An alternative is to always chdir back to where we were to undo the side effect of the Python command. -- If Apple would build a car... ... it would be powered by the sun, be reliable, five times as fast and twice as easy to drive; but would only run on five percent of the roads. /// 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: [RFC] Add a new getAnno function to the netbeans protocol
Xavier de Gaye wrote: During the compile-debug-edit development cycle, the signs placed in the Vim buffers by the IDE with the netbeans protocol can have their line numbers changed when the buffers are edited (a Vim sign sticks with the line it has been set upon, and moves with it). It would be nice to allow the IDE to query Vim for these updated line numbers, so that when the IDE restarts gdb after a new make and the IDE is capable of restoring the breakpoints set on a previous session, the breakpoints and their corresponding signs can be automatically set by the IDE to their new position. The netbeans function documentation can be: === 10.4 Functions and Replies *nb-functions* getAnno serNum Return the line number of the annotation in the buffer Arguments: serNum serial number of this placed annotation The reply is: lnum = line number of the annotation === The implementation can be based on the existing sign_list_placed() function in buffer.c. I can propose a patch if this request for change is acceptable. It makes sense. The only alternative is to listen to insert and delete messages to keep track of the position, which probably requires keeping a copy of the text. -- If Microsoft would build a car... ... the oil, water temperature, and alternator warning lights would all be replaced by a single General Protection Fault warning light. /// 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///
Patch 7.0.162
Patch 7.0.162
Problem:vim -o a b when file a triggers the ATTENTION dialog,
selecting Quit exits Vim instead of editing b only.
When file b triggers the ATTENTION dialog selecting Quit or
Abort results in editing file a in that window.
Solution: When selecting Abort exit Vim. When selecting Quit close the
window. Also avoid hit-enter prompt when selecting Abort.
Files: src/buffer.c, src/main.c
*** ../vim-7.0.161/src/buffer.c Fri Oct 20 20:15:05 2006
--- src/buffer.cTue Nov 7 21:08:02 2006
***
*** 4220,4226
/* Use the name from the associated buffer if it exists. */
bp = buflist_findnr(aep-ae_fnum);
! if (bp == NULL)
return aep-ae_fname;
return bp-b_fname;
}
--- 4222,4228
/* Use the name from the associated buffer if it exists. */
bp = buflist_findnr(aep-ae_fnum);
! if (bp == NULL || bp-b_fname == NULL)
return aep-ae_fname;
return bp-b_fname;
}
*** ../vim-7.0.161/src/main.c Tue Sep 5 12:57:14 2006
--- src/main.c Tue Nov 7 22:35:49 2006
***
*** 2392,2398
(void)open_buffer(FALSE, NULL); /* create memfile, read file */
#if defined(HAS_SWAP_EXISTS_ACTION)
! check_swap_exists_action();
#endif
#ifdef FEAT_AUTOCMD
dorewind = TRUE;/* start again */
--- 2392,2414
(void)open_buffer(FALSE, NULL); /* create memfile, read file */
#if defined(HAS_SWAP_EXISTS_ACTION)
! if (swap_exists_action == SEA_QUIT)
! {
! if (got_int || only_one_window())
! {
! /* abort selected or quit and only one window */
! did_emsg = FALSE; /* avoid hit-enter prompt */
! getout(1);
! }
! /* We can't close the window, it would disturb what
!* happens next. Clear the file name and set the arg
!* index to -1 to delete it later. */
! setfname(curbuf, NULL, NULL, FALSE);
! curwin-w_arg_idx = -1;
! swap_exists_action = SEA_NONE;
! }
! else
! handle_swap_exists(NULL);
#endif
#ifdef FEAT_AUTOCMD
dorewind = TRUE;/* start again */
***
*** 2432,2437
--- 2448,2455
{
int arg_idx;/* index in argument list */
int i;
+ int advance = TRUE;
+ buf_T *old_curbuf;
# ifdef FEAT_AUTOCMD
/*
***
*** 2440,2470
++autocmd_no_enter;
++autocmd_no_leave;
# endif
arg_idx = 1;
for (i = 1; i parmp-window_count; ++i)
{
! if (parmp-window_layout == WIN_TABS)
{
! if (curtab-tp_next == NULL)/* just checking */
! break;
! goto_tabpage(0);
}
! else
{
! if (curwin-w_next == NULL) /* just checking */
! break;
! win_enter(curwin-w_next, FALSE);
}
/* Only open the file if there is no file in this window yet (that can
!* happen when .vimrc contains :sall) */
if (curbuf == firstwin-w_buffer || curbuf-b_ffname == NULL)
{
curwin-w_arg_idx = arg_idx;
! /* edit file from arg list, if there is one */
(void)do_ecmd(0, arg_idx GARGCOUNT
? alist_name(GARGLIST[arg_idx]) : NULL,
NULL, NULL, ECMD_LASTL, ECMD_HIDE);
if (arg_idx == GARGCOUNT - 1)
arg_had_last = TRUE;
++arg_idx;
--- 2458,2522
++autocmd_no_enter;
++autocmd_no_leave;
# endif
+
+ /* When w_arg_idx is -1 remove the window (see create_windows()). */
+ if (curwin-w_arg_idx == -1)
+ {
+ win_close(curwin, TRUE);
+ advance = FALSE;
+ }
+
arg_idx = 1;
for (i = 1; i parmp-window_count; ++i)
{
! /* When w_arg_idx is -1 remove the window (see create_windows()). */
! if (curwin-w_arg_idx == -1)
{
! ++arg_idx;
! win_close(curwin, TRUE);
! advance = FALSE;
! continue;
}
!
! if (advance)
{
! if (parmp-window_layout == WIN_TABS)
! {
! if (curtab-tp_next == NULL)/* just checking */
! break;
! goto_tabpage(0);
! }
! else
! {
! if (curwin-w_next == NULL) /* just checking */
! break;
! win_enter(curwin-w_next, FALSE);
! }
}
+ advance = TRUE;
/* Only open the file if there is no file in this window yet (that can
!* happen when .vimrc contains :sall). */
Re: Current buffer name after :python os.chdir()
--- Bram Moolenaar [EMAIL PROTECTED] wrote: Xavier de Gaye wrote: Assuming the current buffer is the file 'foobar' in the current directory. After running the following Vim commands: :python import os :python os.chdir(subdir) the current buffer name is not changed as it is when you run the Vim command ':cd subdir' (but the output of ':pwd' is Ok), and when the following command is run afterwards: :write Vim writes the buffer to the file 'subdir/foobar', instead of the original file. This happens with Vim 7.0 compiled with Python 2.5. Well, you should not use Python to change directory. But it may happen unintentionally... Checking the current directory after each :python command is a bit inefficient, but that's probably what needs to be done then. An alternative is to always chdir back to where we were to undo the side effect of the Python command. I am trying to use Vim as a python interpreter. So, I have mapped: :map F4 :exe pyfile . expand(%)CR I edit some python stuff in a foobar file, and hit F4 to run it. When the foobar file content is: import os os.chdir(subdir) I run into the above problem. It is probably safer to run python as: :map F4 :exe !python . expand(%)CR But you lose the capability to do some investigation on the variables contents after the script has run. Xavier -- http://clewn.sourceforge.net gdb support in Vim
Re: Flickering of completion menu
I would also love a flicker-less popup menu. I use the completion
excessively, since I've found it makes coding faster and less error
prone. I noticed the menu only flickers in some cases.
--Matt
On Wed, Nov 08, 2006 at 10:10:09AM +1100, Peter Hodge wrote:
Hello,
I agree, it would be great if the popup-menu could be optimized. One of the
best features of Vim is that is fast enough to keep up with my keystrokes
(many
editors will begin to 'lag' when given commands too rapidly, and I have to
stop
and wait for them). I often have to slacken my pace when it comes to Vim's
popup-menu, because it takes at least .2 seconds to redraw each time I press
CTRL-N.
regards,
Peter
--- Nikolai Weibull [EMAIL PROTECTED] wrote:
Hi!
As you've probably all noticed the completion menu flickers when you
move through the items rapidly. Why is this? Is it really necessary
to redraw the whole completion menu when it really only should require
redrawing the item previously selected and the item selected now [1]?
Anyway, would this be possible to implement?
Also, here's a set of mappings that make the digits move their value
number of items down the completion list (if displayed):
for digit in [1, 2, 3, 4, 5, 6, 8, 9]
execute 'inoremap silent ' . digit . ' C-R=pumvisible() ? ' .
repeat('\ltC-N', digit) . ' : ' . digit . 'CR'
endfor
(I guess this could be extended to include -n, for 1 = n = 9, which
would move n number of items upward. Any takers?)
It flickers like mad, but at least it goes a lot faster than holding
down CTRL-N or CTRL-P.
nikolai
[1] Excepting the case where one begins to scroll in the menu, when
all items need to be redrawn, as they move up or down one step - which
leads to a second question, wouldn't it be a lot more economical to
scroll like half a menu or something, so that scrolling wouldn't
require so many redraws? Or at least utilize the terminal codes that
enable scrolling in a buffer to be done with only redrawing the first
or last line when scrolling by a single line in a buffer?
Send instant messages to your online friends http://au.messenger.yahoo.com
vimtutor bug
In vimtutor, I see: NOTE: A count between the operator d and the motion works similar to using the motion without an operator. However, it seems that 2dw works the same as d2w. I think the tutor needs to be updated. I'm using Vim 7.0.35. Thanks! -jj -- http://jjinux.blogspot.com/
