RE: OT: Vi in a browser...
On Mon, 4 Jun 2007 at 11:27am, Gene Kwiecinski wrote:
Just getting to email now, so this is essentially a consolidated reply
to all who answered...
Speaking of which, is there any quicker way to visually select the
entire file, analogous to ^A in other systems?
To copy the entire file to the system clipboard, you can do:
:%y+
Rpelace y with d if you want to cut instead of copy.
Replace + with * if you want to use middle-click to paste (on X11.)
That's about the shortest I could come up with, :%d+, to do what I
want, but still not quite what I was looking for. I was kindasorta
expecting a normal-mode solution, like 'gg*V' or something, to avoid
even toggling the shift key all that much (think baud vs bps).
The only thing I really use it for is to cp from LookOut's email to
'vim', then back again. So I ^A the entire reply, dump it into a new
'vim' window, edit it to insert a new quotelevel, etc., then want to
^A it to get it back into LO. But it's repetitive/frequent enough to
make me want to shorten the command further.
Ain't hung up on visual mode or anything (hi Tim!), it's just that
when I don't want headers at the top, I can start from the bottom ('G'),
make my way to the top in visual ('1G'), then down my way past the
headers to *not* grab them when putting it all back. Or v/v if I want
to skip the signature. Etc.
The 'vim' instance used to do the editing is going to disappear
immediately after, so I'm not concerned about cut vs copy, etc.
Everything goes into the clipboard, then dumped back into LO's reply
window, so a plain ':%d' won't work.
In a similar vein, I was never much on visual vs *real* 'vi' commands,
but it does come in handy to delete subroutines, etc. Eg, for the
format
sub sub1(){
...
}
sub sub2(){
...
}
all you need to do it find the initial sub, then V$%jj to grab the
whole thing, and delete it, copy it, cut it, etc. Go into visual,
end-of-line (for the leading '{'), '%' (for the matching '}'), down a
coupla lines to grab trailing whitespace, then bam!, it's gone. And
it's a visual confirmation to make sure you don't go nuts and delete
more than you intended.
Point being that for some operations, visual mode is a lot more
reassuring.
Have you looked at the below Vim tip?
http://www.vim.org/tips/tip.php?tip_id=805
Read through the comments as well as the original tip has been improved
over a few iterations in the comments.
--
Hari
Ready
for the edge of your seat?
Check out tonight's top picks on Yahoo! TV.
http://tv.yahoo.com/
Re: hosting wiki tips
On Sat, 24 Mar 2007 at 7:11pm, Tom Purl wrote: On Fri, March 23, 2007 11:42 pm, Hari Krishna Dara wrote: I know this came up during the recent discussions on using wiki for tips and it was ruled out. ... I came across this free hosting website called 110mb.com which has like 2gb of free space with no advertisements and no catches on hosting, and many people were successful in hosting mediawiki (search their forums) and other wikis on their space. Why shoudn't this be an option that we should consider? My understanding was that we were going to try and make Wikibooks work for the following reasons: 1. We had people on the list who were already using Wikibooks and liked it quite a bit. 2. It uses the Mediawiki wiki engine, which is probably the most ubiquitous wike engine available. 3. It has proven spam-fighting capabilities 4. The majority of people who had an opinion on the topic seemed to favor using a Wikibook site. In the end, I guess you could say that it was the lowest-risk choice. The reason I brought this up is that someone (Bram?) mentioned that the hosted solution at Wikibooks doesn't have some security/spam features of mediawiki enabled so hosting it separately for Vim was considered a better option, but no completely free hosting services were found. Also, this will allow us to host even scripts such as those that we use to rate the tips on the same server (which might not be an option on wikibooks). However, migrating from Wikibooks to any other mediawiki host (whether self-hosted or another 3rd party) should be straight-forward (right?), so this might not be a big deal after all. -- Thanks, Hari Sucker-punch spam with award-winning protection. Try the free Yahoo! Mail Beta. http://advision.webevents.yahoo.com/mailbeta/features_spam.html
Re: pasting very long text at command-line
On Sat, 24 Mar 2007 at 6:47am, A.J.Mechelynck wrote: Hari Krishna Dara wrote: This happened to me always by mistake and what happened today was the worst. Forgetting that I have copied large amount of text into the clipboard, I tried to paste it at the search prompt using ^R* and this caused Vim to hang for a very long time and pressing ^C had no effect. I remember that Vim used to crash when a large amount of text is pasted this way, but I think that problem is now fixed, though I think a better behavior is needed, e.g., - Stop and give error after reaching some limit - Detect ^C and stop. Any comments? Ctrl-C ought to be detected, but some users (especially Vim newbies on Windows) remap it to yank to clipboard. You might want to try Ctrl-Break, which also (IIRC) has the property that (at the keyboard interrupt driver level) it empties the keyboard buffer (of waiting keys). Best regards, Tony. I doubt if Ctrl-Break will be any different here. The input is not really coming from keyboard, though Vim might internally emulate that way, so the OS might not play any role here. In fact, I just tried it again and observed that Ctrl-Break didn't work. -- Thanks, Hari Expecting? Get great news right away with email Auto-Check. Try the Yahoo! Mail Beta. http://advision.webevents.yahoo.com/mailbeta/newmail_tools.html
pasting very long text at command-line
This happened to me always by mistake and what happened today was the worst. Forgetting that I have copied large amount of text into the clipboard, I tried to paste it at the search prompt using ^R* and this caused Vim to hang for a very long time and pressing ^C had no effect. I remember that Vim used to crash when a large amount of text is pasted this way, but I think that problem is now fixed, though I think a better behavior is needed, e.g., - Stop and give error after reaching some limit - Detect ^C and stop. Any comments? -- Thanks, Hari Don't pick lemons. See all the new 2007 cars at Yahoo! Autos. http://autos.yahoo.com/new_cars.html
hosting wiki tips
I know this came up during the recent discussions on using wiki for tips and it was ruled out. I don't remember exactly what the reason was and there are too many messages to go through, so I would like to pose this question again. I came across this free hosting website called 110mb.com which has like 2gb of free space with no advertisements and no catches on hosting, and many people were successful in hosting mediawiki (search their forums) and other wikis on their space. Why shoudn't this be an option that we should consider? I don't know how successful their business model is, but if they already proved that it works, they might be around for a long time. -- Thanks, Hari Get your own web address. Have a HUGE year through Yahoo! Small Business. http://smallbusiness.yahoo.com/domains/?p=BESTDEAL
Re: VimTips Wiki: New Direction
On Mon, 5 Mar 2007 at 1:26pm, Tom Purl wrote: Here's my view of where we are regarding the Vim Tips wiki conversion project: 1. The Google wiki seems to be a poor option due to the difficulty involved in registering. 2. Multiple other wiki engines have been discussed, and the clear favorite seems to be a site built on top of the Mediawiki application. 3. Of all of the sites that offer free wiki hosting using Mediawiki, Wikibooks seems to be the most favored. Note: These are all my opinions based on what I've read. I hope to hear from everyone that has a different perspective :) Ok, so based on my version of reality, I think that we should proceed with the following actions: 0. I'll create the following page on the Vim Tips chapter of the Vim book on Wikibooks (whew!): * http://en.wikibooks.org/wiki/Learning_the_vi_editor/Vim/TipsSandbox 1. All of the people who wrote tip conversion scripts before should update them so that the output format is Wikipedia markup, not Google markup * I apologize to the script writers for making them do more work. Hopefully, the necessary changes to your scripts will be small. * Also, please note that I _don't_ think that anyone should contribute a new script to this effort. We already have three very capable scripts that can probably get the job done very well, so I don't think that the effort would be worthwhile for anyone else. 2. Convert one tip and post the output on the TipsSandbox page listed above. 3. The vim community will come to a consensus on the best format for the tips, and we will use the best script for the job. 4. Consensus achieved!!! 5. We will automate the task of converting all of the tips. 6. A group of wiki superusers will inspect 50 random tips and make sure that they look good. 7. The invisible hand of The Wiki will then gradually make our wonderful collection of Vim tips even more awesome than they've ever been before! ;D So, what do you guys think? Tom Purl I have been reading posts on this subject with interest and think that this is going to be a good decision. My only concern is on how we are planning to support the existing rating system going forward and if we can enforce a fixed style on commenting such that the comments don't look like a mess. I would imagine that one needs to edit the tip to add their comment at the end, but it will be nice if the comment itself happens as a discussion (which appears as a discussion tab on the same page). -- Thanks, Hari -- Thanks, Hari Sucker-punch spam with award-winning protection. Try the free Yahoo! Mail Beta. http://advision.webevents.yahoo.com/mailbeta/features_spam.html
RE: VimTips Wiki: New Direction
On Tue, 6 Mar 2007 at 12:34pm, Denis Perelyubskiy wrote: On Tue, 06 Mar 2007 11:31:53 -0700, Steve Hall [EMAIL PROTECTED] said: From: Hari Krishna Dara, Tue, March 06, 2007 11:33 am and if we can enforce a fixed style on commenting such that the comments don't look like a mess. I would imagine that one needs to edit the tip to add their comment at the end, but it will be nice if the comment itself happens as a discussion (which appears as a discussion tab on the same page). I agree, is there any way the porting process can push comments to each tip's respective discussion tab? why don't we discuss that here: http://en.wikibooks.org/wiki/Talk:Learning_the_vi_editor/Vim/TipsSandbox/Tip_1:_the_super_star :-) Seriously though, as I had mentioned on the discussion page, for me as a user of the tip, it is horribly counter-productive to go and read twenty-five thousands comments on a page. I'd much rather just read a perfect tip. This assumes, of course, that tip contributors care about me as a user. I hope they do :) Wikipedia model seems to work great. One page. All the information. Discussion on a separate page. One change: if it matters, we could reserve a line (or two) for a list of contributors. This information is available from the history page for those who care to look anyway, but maybe people care about their names being mentioned. Finally, on the subject of converting the comments - it is entirely a manual process, that can not be automated. Comments need to be integrated into the body of the main tip (maybe the tip needs to be adjusted, reworded, etc). We should just push out the existing pages, and then set to work on reworking the tips by hand. Eventually we'll be done. In any case, I think this will be an extremely useful resource (especially if we could then put VIM's documentation on there, and cross-link) I agree, without updating the original tip based on the feedback from comments, it is incredibly painful to go through all the comments and get best out of it. In fact, currently, when you read comments, what you are looking for a ways to improve the original tip, not those that just complement it. From this regard, the comments are more of discussions to improve the tip. Since the wiki model allows for anyone to go and modify the tip, it will be interesting to see how a tip will be modified once the discussion results in multiple ways to improve it. I guess you can then accommodate multiple solutions right in the tip. -- Thanks, Hari It's here! Your new message! Get new email alerts with the free Yahoo! Toolbar. http://tools.search.yahoo.com/toolbar/features/mail/
RE: argdo and grep
On Thu, 1 Mar 2007 at 5:25pm, Naim Far wrote: Thanx Yakov for your response, It would help, but I would rather to do it with in working in vim. I'm editing an enormous number of files, and when I change a pattern, I want to change it in the few files that has this pattern, and not having to go through all the files. Is there anyway you could think of?! Try: :args `grep -l 'pattern' *` | argdo :%s/pattern/new_pattern/g You will have to make sure 'hidden' is set or tack on | w at the end. -- HTH, Hari Thanx again... Naim -Original Message- From: Yakov Lerner [mailto:[EMAIL PROTECTED] Sent: Thursday, March 01, 2007 2:20 PM To: Naim Far Cc: vim@vim.org Subject: Re: argdo and grep On 3/1/07, Naim Far [EMAIL PROTECTED] wrote: I was wondering about argdo! Is there anyway to do the following command :grep pattern * | argdo :%s/pattern/new_pattern/g How about this: vim `grep -l 'pattern' *` :argdo :%s/pattern/new_pattern/g Yakov 8:00? 8:25? 8:40? Find a flick in no time with the Yahoo! Search movie showtime shortcut. http://tools.search.yahoo.com/shortcuts/#news
Re: Marking an undo-block before ^U in insert-mode
On Tue, 20 Feb 2007 at 9:13am, Tim Chase wrote: I'm trying to find a good way to remap control+U in insert-mode so that it begins an undo-block. There are times when type control+U in insert-mode and it doesn't do what I intend, or I want to undo it, only to find that an undo doesn't solve the problem. I know that transitioning out of insert-mode (via esc or c-o) will mark a point in the undo-stack. I am not sure I understand you right, but do you mean something like c-gu in insert mode ? (:help i_CTRL-G_u): :imap c-u c-gu Yes, precisely! Thanks! Or rather, it's the piece I was missing: :inoremap c-u c-guc-u As usual, Vim had the functionality, I just couldn't figure out how to find it in the help. It didn't help that the help only provides the one line you quote for the entirety of assistance on the matter. The whole i_CTRL-G family of commands are new to me. More stuff to learn. ;) I had the same requirement may be about 6 years ago and had to write a small plugin to do this job. I was essentially mapping the ^U and ^W commands to first save what is going to be deleted and map another key to paste it back. Saving ^U is more useful than ^W and starting a new undo point when you do ^U is probably a reasonable workaround. If you are interested to take a look anyway, the plugin is available at http://www.vim.org/script.php?script_id=150, but a newer version can be downloaded at: http://haridara.googlepages.com/undoins.vim -- Hari I'm still not 100% sure why I got this craziness: inoremap c-u c-onopc-u This gives me a crazy E486: Pattern not found: insert which, I haven't searched for the word insert so this one makes me scratch my head. Bug perhaps? Vim-internals showing through? to try and reproduce something similar, I did vim -u NONE :set nocp :inoremap c-u c-oNopc-u inserted some text and hit control+U. This time I got E35: No previous regular expression. I suspect that the Nop isn't getting interpreted as the do nothing operator as described at :help nop but rather is being interpreted as less-than, en, oh, pee, greater-than and the en portion of it is trying to look for the last regexp. I'm not sure how it thought I looked for insert previously, as I don't consciously remember searching for such text this morning. The docs on nop don't seem to detail that the only permissible context is a stand-alone rhs of a mapping. Ah well. At least I have the CTRL-G_u functionality to solve the problem. Thanks again, -tim Finding fabulous fares is fun. Let Yahoo! FareChase search your favorite travel sites to find flight and hotel bargains. http://farechase.yahoo.com/promo-generic-14795097
Vim crashing while starting nibbles game
After I updated the nibbles game, a user reported that his gvim crashes while starting the game. He is using gvim on mandriva linux with patchlevel upto 178. Strangely it doesn't crash on his console vim. I couldn't reproduce the crash on XP and tried with gvim with patchlevels 148 as well as 191. Here is the script page if anyone wants to try it and reproduce it: http://www.vim.org/scripts/script.php?script_id=916 Can anyone take a look at the below output I received from him and see if there is any information about the problem? here is what gvim outputs to the terminal after crashing $ gvim Fontconfig error: conf.d, line 1: no element found [EMAIL PROTECTED] autoload]$ *** buffer overflow detected ***: gvim terminated === Backtrace: = /lib/i686/libc.so.6(__chk_fail+0x41)[0xb731b0f1] /lib/i686/libc.so.6(__strcpy_chk+0x43)[0xb731a5f3] gvim[0x80987e6] === Memory map: 08048000-08214000 r-xp 03:05 230449 /usr/bin/gvim 08214000-08221000 rwxp 001cc000 03:05 230449 /usr/bin/gvim 08221000-087ef000 rwxp 08221000 00:00 0 [heap] b586d000-b5877000 r-xp 03:05 392517 /lib/libgcc_s-4.1.2.so.1 b5877000-b5878000 rwxp 9000 03:05 392517 /lib/libgcc_s-4.1.2.so.1 b5898000-b58f8000 rwxs 00:07 17039409 /SYSV (deleted) b58f8000-b58fe000 r-xp 03:05 344455 /usr/lib/gtk-2.0/2.10.0/loaders/libpixbufloader-xpm.so b58fe000-b58ff000 rwxp 5000 03:05 344455 /usr/lib/gtk-2.0/2.10.0/loaders/libpixbufloader-xpm.so b58ff000-b5ada000 r-xp 03:05 247080 /usr/share/icons/hicolor/icon-theme.cache b5ada000-b60f4000 r-xp 03:05 246307 /usr/share/icons/gnome/icon-theme.cache b60f4000-b6102000 r-xp 03:05 377519 /usr/share/icons/Clearlooks/icon-theme.cache b6102000-b6107000 r-xp 03:05 245343 /usr/share/locale/en_GB/LC_MESSAGES/glib20.mo b6107000-b6118000 r-xp 03:05 396368 /usr/share/fonts/TTF/Vera.ttf b6118000-b611c000 r-xp 03:05 347050 /usr/lib/gtk-2.0/2.10.0/loaders/libpixbufloader-png.so b611c000-b611d000 rwxp 3000 03:05 347050 /usr/lib/gtk-2.0/2.10.0/loaders/libpixbufloader-png.so b611d000-b6131000 r-xp 03:05 299599 /usr/X11R6/lib/X11/fonts/drakfont/Type1/ProggySmall.pfb b6131000-b6133000 r-xp 03:05 278892 /usr/lib/pango/1.6.0/modules/pango-basic-fc.so b6133000-b6134000 rwxp 1000 03:05 278892 /usr/lib/pango/1.6.0/modules/pango-basic-fc.so b6134000-b614 r-xp 03:05 392916 /usr/lib/gtk-2.0/2.10.0/engines/libindustrial.so b614-b6141000 rwxp c000 03:05 392916 /usr/lib/gtk-2.0/2.10.0/engines/libindustrial.so b6141000-b6147000 r-xp 03:05 246576 /usr/share/locale/en_GB/LC_MESSAGES/libgnomeui-2.0.mo b6147000-b614e000 r-xp 03:05 246849 /usr/share/locale/en_GB/LC_MESSAGES/libgnome-2.0.mo b614e000-b627a000 rwxp b614e000 00:00 0 b627a000-b627b000 r-xp 03:05 229160 /usr/lib/gconv/ISO8859-1.so b627b000-b627d000 rwxp 03:05 229160 /usr/lib/gconv/ISO8859-1.so b627d000-b6285000 r-xp 03:05 397071 /lib/libnss_files-2.4.so b6285000-b6287000 rwxp 8000 03:05 397071 /lib/libnss_files-2.4.so b6287000-b62a7000 r-xp 03:05 249891 /usr/share/locale/en_GB/LC_MESSAGES/gtk20-properties.mo b62a7000-b62ae000 r-xs 03:05 230370 /usr/lib/gconv/gconv-modules.cache b62ae000-b62e r-xp 03:05 163875 /usr/share/locale/ISO-8859-1/LC_CTYPE b62e-b62e1000 ---p b62e 00:00 0 b62e1000-b6ae5000 rwxp b62e1000 00:00 0 b6ae5000-b6b03000 r-xp 03:05 229513 /usr/lib/libexpat.so.0.5.0 b6b03000-b6b05000 rwxp 0001e000 03:05 229513 /usr/lib/libexpat.so.0.5.0 b6b05000-b6b0a000 r-xp 03:05 237405 /usr/lib/libXdmcp.so.6.0.0 b6b0a000-b6b0b000 rwxp 4000 03:05 237405 /usr/lib/libXdmcp.so.6.0.0 b6b0b000-b6b0d000 r-xp 03:05 229771 /usr/lib/libXau.so.6.0.0 b6b0d000-b6b0e000 rwxp 1000 03:05 229771 /usr/lib/libXau.so.6.0.0 b6b0e000-b6b0f000 rwxp b6b0e000 00:00 0 b6b0f000-b6b14000 r-xp 03:05 397055 /lib/libcrypt-2.4.so b6b14000-b6b16000 rwxp 4000 03:05 397055 /lib/libcrypt-2.4.so b6b16000-b6b3d000 rwxp b6b16000 00:00 0 b6b3d000-b6b4d000 r-xp 03:05 397064 /lib/libnsl-2.4.so b6b4d000-b6b4f000 rwxp 0001 03:05 397064 /lib/libnsl-2.4.so b6b4f000-b6b51000 rwxp b6b4f000 00:00 0 b6b51000-b6b55000 r-xp 03:05 425586 /lib/libattr.so.1.1.0 b6b55000-b6b56000 rwxp 3000 03:05 425586 /lib/libattr.so.1.1.0 b6b56000-b6b64000 r-xp 03:05 397083 /lib/libresolv-2.4.so b6b64000-b6b66000 rwxp e000 03:05 397083 /lib/libresolv-2.4.so b6b66000-b6b68000 rwxp b6b66000 00:00 0 b6b68000-b6b77000 r-xp 03:05 232189 /usr/lib/libavahi-client.so.3.2.2 b6b77000-b6b78000 rwxp e000 03:05 232189 /usr/lib/libavahi-client.so.3.2.2 b6b78000-b6b79000 rwxp b6b78000 00:00 0 b6b79000-b6b84000 r-xp 03:05 229248
RE: File name completion for files residing in multiple directories
On Mon, 12 Feb 2007 at 8:07pm, Max Dyckhoff wrote: This is a bug which I have actually informed Hari of a while ago, but perhaps my bug email got lost :) The email is not lost, just extremely busy with work and personal life :) Also, lately I have been using eclipse more and more at my new job, and haven't been spending much time in vim. The java specific features of the IDE are extremely productive, but I wish I can plug right gvim into the editor and still be able to use all the java specific features such as quick fixes, completions etc. The default mapping for LookupFile is F5. What this error message means is that you already have a mapping for F5 in your .vimrc file, and you haven't specified a mapping for PlugLookupFile. In this situations, LookupFile will try to map F5 to PlugLookupFile, which fails with the error message that you get. This is annoying, and this is my work around for it until Hari fixes it. All you need is the final line, some random unused mapping to PlugLookupFile, and that will stop the error from firing. :map silent F7 :LookupFileCR enter LookupFile explicitly :map silent S-F7 :LUWalkCR enter LUWalk explicitly :map silent C-F7 :LUPathCR enter LUPath explicitly :imap silent F7 escPlugLookupFileexit LookupFile :map silent S-C-A-F8 PlugLookupFilesomething random to remove the error! The plugin just follows the suggested Plug mapping approach (see |write-plugin|), and this is not usually a nuisance, as you would expect the user to always create a mapping, even if the default is undesirable. However, in this specific case, I realize you didn't want to map F7 directly to PlugLookupFile because you don't like the default behavior of remapping F7 to whatever is the latest operation. In fact, this has been bugging me also, but haven't taken the time to think of the right alternative. It might be best to create a different plug mapping for this purpose and have a flag to disable it altogether. Suggestions welcome. -- Thanks, Hari -Original Message- From: Meino Christian Cramer [mailto:[EMAIL PROTECTED] Sent: Monday, February 12, 2007 7:30 PM To: Max Dyckhoff Cc: [EMAIL PROTECTED]; vim@vim.org Subject: Re: File name completion for files residing in multiple directories From: Max Dyckhoff [EMAIL PROTECTED] Subject: RE: File name completion for files residing in multiple directories Date: Mon, 12 Feb 2007 11:58:35 -0800 I installed lookupfile and got back this error message while starting vim (console): Error detected while processing /home/mccramer/.vim/plugin/lookupfile.vim: line 105: E227: mapping already exists for [EMAIL PROTECTED] Press ENTER or type command to continue ??? You want Hari's LookupFile plugin, which you can find on vim.org. It's awesome, and has speeded up my development massively. It does exactly what you want, in almost exactly the way you suggest. Max -Original Message- From: Erik Bergman [mailto:[EMAIL PROTECTED] Sent: Monday, February 12, 2007 10:53 AM To: vim@vim.org Subject: File name completion for files residing in multiple directories I've been searching for a nice way to quickly open files that may reside in any of number of directories, similar to the quick open feature you find in some other editors. One solution is to mess around with the ** and * wildcards, but this gets terribly slow for large projects. Another solution is to set the 'path' variable, but vim does not perform completion on files opened that way. A third solution is to generate file name tags and use :tag to jump to files, but in that case you will perform completion on just not file names, but other tags as well. Finally, you can open all files you need to switch between and use :b, but for obvious reasons this isn't very practical. What I think would be an nice solution is if there was some way to make vim perform file name completion using 'file' tags from the tag file. That way you could still use tags for other things, and most often the files you generate tags for are exactly the files you want to be able to open and switch between quickly. Can anyone think of a better solution? Would it be possible to integrate this feature into vim in a nice way? /Erik Berman Want to start your own business? Learn how on Yahoo! Small Business. http://smallbusiness.yahoo.com/r-index
Re: File name completion for files residing in multiple directories
On Mon, 12 Feb 2007 at 7:53pm, Erik Bergman wrote: I've been searching for a nice way to quickly open files that may reside in any of number of directories, similar to the quick open feature you find in some other editors. One solution is to mess around with the ** and * wildcards, but this gets terribly slow for large projects. Another solution is to set the 'path' variable, but vim does not perform completion on files opened that way. A third solution is to generate file name tags and use :tag to jump to files, but in that case you will perform completion on just not file names, but other tags as well. Finally, you can open all files you need to switch between and use :b, but for obvious reasons this isn't very practical. What I think would be an nice solution is if there was some way to make vim perform file name completion using 'file' tags from the tag file. That way you could still use tags for other things, and most often the files you generate tags for are exactly the files you want to be able to open and switch between quickly. Can anyone think of a better solution? Would it be possible to integrate this feature into vim in a nice way? /Erik Berman Have you looked at my LookupFile plugin from vim.org? I think it has exactly what you need. -- Hari It's here! Your new message! Get new email alerts with the free Yahoo! Toolbar. http://tools.search.yahoo.com/toolbar/features/mail/
patch: set() function
Here is a patch that adds set() function on the lines of existing get() for setting list elements by index or dict keys by name. The reason I wanted this is the lack of support to use :let for modifying the dictionary elements. E.g., the below will be an error: :let get_dict().key = 'val' The alternative is to use the new set() function as: :call set(get_dict(), 'key', 'val') The function also returns the new value. Notice that the :let syntax works to call functions on the dict, so the below is valid: :let x = get_dict().getX() Together, I think they will serve most or all of the use cases. This is my first patch for Vim, and I haven't touched c/c++ code in years, so I don't know if I screwed up on something. I can write the documentation if Bram OK's the patch. I don't know if there are any tests that need to be emended, and if so where they are. -- Thanks, Hari __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com set_patch.diff Description: 919171944-set_patch.diff
Re: patch: set() function
On Wed, 25 Oct 2006 at 9:16am, Nikolai Weibull wrote: On 10/25/06, Hari Krishna Dara [EMAIL PROTECTED] wrote: Here is a patch that adds set() function on the lines of existing get() for setting list elements by index or dict keys by name. The reason I wanted this is the lack of support to use :let for modifying the dictionary elements. E.g., the below will be an error: :let get_dict().key = 'val' The alternative is to use the new set() function as: :call set(get_dict(), 'key', 'val') Wouldn't it be better to allow the :let syntax you describe above? It shouldn't be impossible to parse that kind of expression. - A set() function will be nice to have anyway (to balance out get()) - Adding a function is much easier (at least for me as a newbie) and the change is more isolated than changing the syntax of the :let command. This also means better likely hood of getting incorporated sooner. - The last time the :let syntax was discussed, I don't think Bram agreed to fix this issue, which indicates he is not in favor of that, and so less likelyhood to get incorporated. BTW, I noticed that I had the min args as 2 (copied from f_get) which is wrong, it should be 3. I can send another patch, again if Bram is OK with this change at all. -- Thanks, Hari __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Re: getchar() trick with recursive expr map
On Wed, 25 Oct 2006 at 11:33pm, Mikolaj Machowski wrote: On ¶ro pa¼ 25 2006, Mikolaj Machowski wrote: In Linux terminal and GTK2 versions cursor is stuck in command line and don't at its real position making inserting of text almost random. Getting stuck at command-line is normal, as it is always waiting on getchar(). I realize will not be suitable for all applications, but works well for what I am trying to achieve. I don't however understand the random part that you are mentioning. What exactly is happening? Is the position where the text is inserted random? No, just impression of randomness - user is accustomed to cursor and when doesn't see it he is lost. In heavily restricted environment like forms this is not so important. m. Yes, I agree, without cursor there is not much use for general application. What would be nice is to have an option for getchar() that will not move the cursor to the bottom, that way you can at least see where the cursor is (even if that means it is not blinking). -- Hari __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Re: escape() and '
On Mon, 23 Oct 2006 at 12:51pm, Mikolaj Machowski wrote:
Hello,
I understand that escape() was primarily designed to escape strings when
passing to system functions, but personally I never used that and in
didn't noticed such use in various scripts but very often it is used to
escape various charaters in Vim's own regexp matching or passing one
string to some other Vim command.
Hence is the problem: when escaping ' with escape(), character is
prepended with \ which doesn't make sense when passing it to other Vim
command because proper way to escape it in Vim is doubling it with
another '. Example::
:echo escape('as''df', )
I didn't even know that you can escape a single-quote inside
single-quotes like this, where is this information burried in Vim help?
It seems to work though, so just checking if it is documented.
--
Thanks,
Hari
__
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
Re: escape() and '
On Tue, 24 Oct 2006 at 11:10am, Nikolai Weibull wrote: There should really be a third, optional, parameter to escape() where you can specify what character to use for escaping. That wouldn't be real solution because to escape ' you still (in most situations) would need two escape() calls. One for escape ' with ' and second for rest of characters with \. The best solution is providing info about context. I don't follow. When would you need to escape both ' with '' and other characters with \? The only active character in a single-quoted string is the single-quote itself. Oh, I see. You're thinking of creating a string for passing to substitute() inside an :execute, or something like that. Ah, true, then you'd need to escape the single-quotes for the string, and, e.g., . with \.. Escaping is a lot more difficult than one often thinks, I suppose. I don't this this is a valid case either. The problem is only when you need to use such strings with the :exec command (as that involves concatenating strings), but if you are just passing on the string to Vim functions, you don't have to worry about escaping single quotes. Even when you need to concatenate and use a regex, you still need to only escape the single-quotes and backslashes and use it in the \V mode, something like: '\V'.escape(substitute(regex, ', '', 'g'), '\') -- Hari __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Re: Calling a non-existing dictionary function doesn't result in an error
On Mon, 23 Oct 2006 at 5:16pm, Yegappan Lakshmanan wrote:
Hi all,
When a non-existing dictionary function is invoked using the :call
command, there is no error. But when it is used in an expression,
an error message is displayed. Is this the expected behavior?
let a = {}
call a.xyz()
The :call command silently returns without any errors. But
the following commands result in error:
:let x = a.xyz()
E716: Key not present in Dictionary: xyz()
E15: Invalid expression: a.xyz()
:echo a.xyz()
E716: Key not present in Dictionary: xyz()
E15: Invalid expression: a.xyz()
I think I saw the same behavior, though I didn't do the analysis on why
certain calls don't generate an error (assumed that the Vim actually
ignored the error because of silent mode or something like that).
I actually want to propose that dictionary should call a special
function (if available) before giving an error. That will allow us to
extend the dictionary functionality to support some (psuedo)
inheritance. The special function should be passed with the name of the
function that user called and the arguments, and the return value of the
special function should be passed back to the caller.
--
Thanks,
Hari
__
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
jumplist/mark ' problem
I am facing a weird problem with the '' marker not getting set. Here is what I am doing, but this may be more generic than what I do, but this scenario is the most I use: - While on an identifier, use ^W^] to jump to the id definition. - Mark the line, say, ma - move a few lines up using k, say kkk - yank the range using y'a - Try to go back to the original position using '' Instead of cursor going back to the original line, it goes to the start of the file. This behavior is really irritating, as I end up doing this sequence repeatedly and it surprises me everytime. I have a feeling that this wasn't happening in prior versions. Is there a flag that that I might have changed? -- Thanks, Hari __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Re: Bug: CursorHoldI not triggered after startinsert
On Mon, 23 Oct 2006 at 9:25pm, Bram Moolenaar wrote: Hari Krishna Dara wrote: I am using :startinsert! from my plugin to put the user in insert mode, but if the user doesn't type anything for 'updatetime' after this, no CursorHoldI event is generated. I tried doing an explicit :doauto right after :startinsert!, but Vim ignores it, probably because the command only schedules for an insert mode (doesn't immediate change it). Note that the CursorMovedI gets triggered correctly in this case, but I don't want to use that as I don't want to know about every character that user types, but only when the user is holding. Any suggestions for a workaround? I have Vim7 upto the patch 146. It works just fine for me. After typing i and waiting a little while the CursorHoldI event is triggered. I used this: au! CursorHoldI * echomsg 'hi' | sleep 2 You are right, I had an internal flag getting set unexpectedly that was resulting in getting the event ignored. Sorry about that. -- Thanks, Hari __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Bug: CursorHoldI not triggered after startinsert
I am using :startinsert! from my plugin to put the user in insert mode, but if the user doesn't type anything for 'updatetime' after this, no CursorHoldI event is generated. I tried doing an explicit :doauto right after :startinsert!, but Vim ignores it, probably because the command only schedules for an insert mode (doesn't immediate change it). Note that the CursorMovedI gets triggered correctly in this case, but I don't want to use that as I don't want to know about every character that user types, but only when the user is holding. Any suggestions for a workaround? I have Vim7 upto the patch 146. -- Thanks, Hari __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
missing setbufline()?
I see functions for creating new unlisted buffers (bufnr() with {create}
option), and for reading the lines from the buffer using getbufline(),
all without having to change the current buffer, but I don't see a
setbufline() so there is no way to set the lines without having to
switch to it. Is there a reason to leave this circle incomplete?
--
Thank you,
Hari
__
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
Re: Bug: CursorHoldI not triggered after startinsert
On Sun, 22 Oct 2006 at 5:25pm, Hari Krishna Dara wrote: I am using :startinsert! from my plugin to put the user in insert mode, but if the user doesn't type anything for 'updatetime' after this, no CursorHoldI event is generated. I tried doing an explicit :doauto right after :startinsert!, but Vim ignores it, probably because the command only schedules for an insert mode (doesn't immediate change it). Note that the CursorMovedI gets triggered correctly in this case, but I don't want to use that as I don't want to know about every character that user types, but only when the user is holding. Any suggestions for a workaround? I have Vim7 upto the patch 146. I tried to convert the first CursorMovedI to CursorHoldI using the below code: aug LookupFileCursorHoldIHACK au! au CursorMovedI buffer nested exec 'doautocmd LookupFile CursorHoldI' | au! LookupFileCursorHoldIHACK aug END This also gets ignored :( -- Thanks, Hari __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Re: missing setbufline()?
On Sun, 22 Oct 2006 at 6:20pm, Yegappan Lakshmanan wrote:
Hi Hari,
On 10/22/06, Hari Krishna Dara [EMAIL PROTECTED] wrote:
I see functions for creating new unlisted buffers (bufnr() with {create}
option), and for reading the lines from the buffer using getbufline(),
all without having to change the current buffer, but I don't see a
setbufline() so there is no way to set the lines without having to
switch to it. Is there a reason to leave this circle incomplete?
Yes. I had a patch for the setbufline() function last year. There were
several problems with it. So it was not included in Vim7 and only
the getbufline() function was included.
The setbufline() function worked only for loaded buffers. The undo
history was not updated correctly.
But I agree that it will be good to have the setbufline() function.
- Yegappan
Nice, so it will be included at some point after resolving these issues.
--
Thanks,
Hari
__
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
feature request: v:mousecol and v:mouseline
When maps for mouse clicks are executed, can we have the location (in the form of line and column number) made available through v: variables? I just observed that getchar() works even with mouse clicks, but this is almost useless without knowing where the user clicked. Capturing mouse clicks along with expr maps or getchar() can do wonders if the mouse click position is also available. -- Thank you, Hari __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
completion marks buffer modified too soon
When using |completion-function|, Vim is marking the buffer as modified, as soon as the popup is triggered. When a plugin offers matches using 'completefunc' the user should be able to cancel by pressing C-E and this shouldn't leave the buffer as modified. Here is a sample function to show what I mean: function! TComplete(findstart, base) if a:findstart return 0 else return [a:base]+['test1', 'test2'] endif endfunction setl completefunc=TComplete Thinking about it, it might be that Vim automatically chooses the first item in the completion, but this provides no option to leave buffer as not modified when completion is cancelled without selecting an item. I even tried explicitly setting nomodified (though it is ugly), something like: inoremap C-XC-U C-XC-UC-R=ResetModified() function! ResetModified() setl nomodified return '' endfunction But Vim seems to ignore this, as the buffer is still modified at the end. -- Thanks, Hari __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Re: completion marks buffer modified too soon
On Sat, 21 Oct 2006 at 1:59pm, Bram Moolenaar wrote: Hari Krishna Dara wrote: When using |completion-function|, Vim is marking the buffer as modified, as soon as the popup is triggered. When a plugin offers matches using 'completefunc' the user should be able to cancel by pressing C-E and this shouldn't leave the buffer as modified. Here is a sample function to show what I mean: function! TComplete(findstart, base) if a:findstart return 0 else return [a:base]+['test1', 'test2'] endif endfunction setl completefunc=TComplete Thinking about it, it might be that Vim automatically chooses the first item in the completion, but this provides no option to leave buffer as not modified when completion is cancelled without selecting an item. I even tried explicitly setting nomodified (though it is ugly), something like: inoremap C-XC-U C-XC-UC-R=ResetModified() function! ResetModified() setl nomodified return '' endfunction But Vim seems to ignore this, as the buffer is still modified at the end. The completion itself is seen as a change. If you cancel completion it's like changing the text back to what it was. It's very difficult to do this otherwise. How about adding an option something like showonly in 'completeopt', that when set brings up the menu, but doesn't automatically choose the first item? However this should probably be better controlled at per buffer level. There were requests before for this same issue, e.g., someone was trying to map . to bring up omni-completion menu, but didn't want the first item to be automatically chosen (as it is the case in *all* the IDEs), and the workaround was to include the . also as part of completion (it solves the problem, but I think is ugly, as you need to type C-N or C-P twice to get to the real first item or last item in the matches). If there is a way for the |complete-function| to indicate this option, it will solve this problem. -- Thank you, Hari __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Re: feature request: v:mousecol and v:mouseline
On Sat, 21 Oct 2006 at 11:19am, Hari Krishna Dara wrote:
On Sat, 21 Oct 2006 at 1:59pm, Bram Moolenaar wrote:
Hari Krishna Dara wrote:
When maps for mouse clicks are executed, can we have the location (in
the form of line and column number) made available through v: variables?
I just observed that getchar() works even with mouse clicks, but this is
almost useless without knowing where the user clicked. Capturing mouse
clicks along with expr maps or getchar() can do wonders if the mouse
click position is also available.
Good point, getchar() should somehow make the position of the click
available.
It's not that easy, since the click could be in any of the windows. I
suppose we need:
v:mouse_window
v:mouse_column
v:mouse_line
The position could be in screen columns and lines, or in text column and
line. I suppose text position is more useful. You wouldn't need the
position of a click halfway a tab, right?
For most purposes the window and text position is all that matters, but
there can be some interesting possibilities if clicks outside any buffer
(such as at the command-line the way inputlist() works) can also be
made available (using something like v:mouse_region that can have
window, tab, cmdline).
Also want to propose that these v: variables should be settable by the
scripts in case the RHS of a map is a Mouse key. E.g., the following
should work (note: it is just indented to show the usage, not
particularly a useful example):
Make F12 always RightMouse at the center of the current window.
imap expr F12 CenterRightMouse()
function! CenterRightMouse()
let v:mouse_window = winnr()
let v:mouse_line = winheight('.')/2
let v:mouse_col = winwidth('.')/2
return \RightMouse\RightRelease
endfunction
--
Thanks,
Hari
__
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
getchar() trick with recursive expr map
I remember someone posting a patch to add a new event called GetChar to receive an event for every keypress. This trick is not as powerful and flexible as that, but it can be very useful for a plugin, and is supported in Vim7.0 with no patches. Often there are questions on this list on how to capture every key press from a user, and the answer is that it can't, unless you map all keys. But even if you map all keys, it is not flexible enough. Here is a trick with recursive expr maps and getchar() to get all keys pass through your function. You can do whatever you want with the keys, swallow them or pass them to Vim. Here is a demo that shows how to use it in insert mode. What the function does is to double every key you press, except Esc and C-C, when it breaks the loop. imap buffer silent expr F12 Double(\F12) function! Double(mymap) try let char = getchar() catch /^Vim:Interrupt$/ let char = \Esc endtry exec BPBreakIf(char == 32, 1) if char == '^\d\+$' || type(char) == 0 let char = nr2char(char) endif It is the ascii code. if char == \Esc return '' endif redraw return char.char.\C-R=Redraw()\CR.a:mymap endfunction function! Redraw() redraw return '' endfunction You can do almost eanything that you can do normally in an insert mode, press BS, C-U etc. Hope someone finds this useful. I will also post this as a tip. -- Hari __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Re: getchar() trick with recursive expr map
On Fri, 20 Oct 2006 at 8:33am, Benji Fisher wrote: On Thu, Oct 19, 2006 at 11:26:53PM -0700, Hari Krishna Dara wrote: [snip] imap buffer silent expr F12 Double(\F12) function! Double(mymap) try let char = getchar() catch /^Vim:Interrupt$/ let char = \Esc endtry exec BPBreakIf(char == 32, 1) if char == '^\d\+$' || type(char) == 0 Don't you want =~ above instead of == ? You are right, good catch. I copied this code from execmap.vim which has been there for ages, and I don't even remember why I am checking for this pattern, seems like the type() check is sufficient. let char = nr2char(char) endif It is the ascii code. if char == \Esc return '' endif redraw return char.char.\C-R=Redraw()\CR.a:mymap endfunction function! Redraw() redraw return '' endfunction You can do almost eanything that you can do normally in an insert mode, press BS, C-U etc. Hope someone finds this useful. I will also post this as a tip. How does this approach affect the undo history. That is, if I start in Normal mode and type AfooEsc (without the quotes) can I undo the append with u and repeat it with .? HTH --Benji Fisher The above code works only in insert mode and it plays naturally with undo history (it uses C-R= to execute :redraw so it doesn't break undo). If you extend the map to cover normal mode also, you can see it clearly for the case you mentioned (I also removed an excess redraw that I left out before) imap buffer silent expr F12 EatCapitals(\F12) nmap buffer silent expr F12 EatCapitals(\F12) function! EatCapitals(mymap) try let char = getchar() catch /^Vim:Interrupt$/ let char = \Esc endtry exec BPBreakIf(char == 32, 1) if char == '^\d\+$' || type(char) == 0 let char = nr2char(char) endif It is the ascii code. if char == \Esc return char elseif char =~# '[A-Z]' Eat it away, but continue to be in loop return \C-R=''\CR.a:mymap endif return char.\C-R=Redraw()\CR.a:mymap endfunction function! Redraw() redraw return '' endfunction Press F12 in normal mode and start typing your example. This will ignore capitals, so what you will see is foo not Afoo. Once you press Esc, if you press ., you can see that foo gets inserted again. I devised this technique for creating a read-only combobox for my forms plugin. While on the combo field, this allows me to eat away all characters except for those that let you select the item (C-N etc.) and those that allows you to change focus (Tab etc.). I wish I can extend this for all fields to completely control where the user is typing and what he can do, but the problem is the cursor stays at the bottom during this time so it will be hard to understand where you are typing (and it won't feel natural either). -- Hari __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Re: getchar() trick with recursive expr map
On Fri, 20 Oct 2006 at 4:34pm, Mikolaj Machowski wrote: Dnia pi±tek, 20 pa¼dziernika 2006 08:26, Hari Krishna Dara napisa³: Here is a demo that shows how to use it in insert mode. What the function does is to double every key you press, except Esc and C-C, when it breaks the loop. If world could be so beautiful... In Linux terminal and GTK2 versions cursor is stuck in command line and don't at its real position making inserting of text almost random. :( m. Getting stuck at command-line is normal, as it is always waiting on getchar(). I realize will not be suitable for all applications, but works well for what I am trying to achieve. I don't however understand the random part that you are mentioning. What exactly is happening? Is the position where the text is inserted random? -- Thanks, Hari __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
RE: getchar() trick with recursive expr map
On Fri, 20 Oct 2006 at 8:24am, Steve Hall wrote: From: Hari Krishna Dara, Fri, October 20, 2006 2:26 am Often there are questions on this list on how to capture every key press from a user, and the answer is that it can't, unless you map all keys. But even if you map all keys, it is not flexible enough. Here is a trick with recursive expr maps and getchar() to get all keys pass through your function. You can do whatever you want with the keys, swallow them or pass them to Vim. This is exactly how Cream's column mode works. We've been using this for several Vim versions, prior to the :try feature. It works great, but the only drawback I've ever found is the dependency on :redraw. You will find that when extending a selection area it requires the additional exclamation point (:redraw!) since that is the only way to update the background. Unfortunately, this greatly slows down the display response. The solution would be a Vim feature to refresh only the area of the selection change rather than the whole text area. But otherwise, this is a terrific way to loop on user keystrokes. If anyone is interested in seeing how this can develop (various key combinations, handling issues with listchars, etc.) take a look at: http://cream.cvs.sourceforge.net/cream/cream/cream-columns.vim?view=markup I glanced through the code. I don't understand the functionality from the description and can't visualize what it is doing from the code, but refactoring this code using the new Vim7 expr map will have some advantages. I see you are executing :normal command in a recursive function. It has two problems: - If you try to insert text using normal command, it becomes one undo transaction. - The recursive function calls will evenutually reach the 'maxfuncdepth' if the user interacts for long enough. The recursive expr map avoids both these problems and it acts like an transparent layer on top of Vim's user input (both keyboard and mouse). -- Hari __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Re: change counter ? -- test that buffer did not change between two calls
On Thu, 19 Oct 2006 at 11:25pm, Yakov Lerner wrote: I'd like to cache some information about file, into b:variables, and be able to check in my function, whether buffer changed in any way between 2 calls to the function. Is there any change counter that I can store and compare later to detect the buffer change (any change like any insertion, deletion, undo, redo, file was re-read from disk) ? I though about using modified but it does not work. If file was modified and saved, then modified is off and I don't detect anything. Yakov You can probably monitor InsertEnter and InsertLeave in addition to :undolist to figure this out, but you can only see what Vim thinks of the buffer, if you are trying to see if contents really changed, then you can do that only by comparing the text by saving it at different points. - If 'nomodified' at the time of InsertEnter, but 'modified' at the time of 'InsertLeave', then Vim thinks user changed something. - If 'modified' at the time of InsertEnter, save :undolist and compare it with that at the time of InsertLeave to see if any new undo points have been entered. -- HTH, Hari __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Re: change counter ? -- test that buffer did not change between two calls
On Thu, 19 Oct 2006 at 3:15pm, Yegappan Lakshmanan wrote: Hi Yakov, On 10/19/06, Yakov Lerner [EMAIL PROTECTED] wrote: I'd like to cache some information about file, into b:variables, and be able to check in my function, whether buffer changed in any way between 2 calls to the function. Is there any change counter that I can store and compare later to detect the buffer change (any change like any insertion, deletion, undo, redo, file was re-read from disk) ? I though about using modified but it does not work. If file was modified and saved, then modified is off and I don't detect anything. You can try using the b:changedtick variable or the changenr() function. :help b:changedtick-variable :help changenr() - Yegappan Right on what Yakov wants. I think diffing eval.txt with that of vim6 will reveal several hidden gems. -- Thanks, Hari __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Re: Patch 7.0.134
On Mon, 16 Oct 2006 at 9:40pm, Bram Moolenaar wrote: Hari Krishna Dara wrote: On Sun, 15 Oct 2006 at 3:10pm, Bram Moolenaar wrote: Patch 7.0.134 Problem:Crash when comparing a recursively looped List or Dictionary. Solution: Limit recursiveness for comparing to 1000. Files:src/eval.c Does this handle the cases when the exact same objects are involved in the references? All such cases will result in inf. recursion, as there is no logic to break the references, like it is possible in case of functions. If not, is it going to be in another patch? Yes, I have another patch in the pipeline to have comparing a list or dictionary with itself return TRUE quickly. Also, I was thinking of returning TRUE instead of FALSE when running into the recursiveness limit. If everything compares equal so far, then it's probably equal. There should be an error message, but I'm afraid you might get thousands of them... The need to compare lists or dictionaries with suge depths is very very rare, unless the user logic has a bug that creates such structures or Vim logic itself fails to detect recursions, in which case giving out an error message is helpful. -- Thanks, Hari __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
RE: VimL and Exuberant tags - Suggestions please
On Fri, 13 Oct 2006 at 11:43am, David Fishburn wrote:
-Original Message-
From: Peter Hodge [mailto:[EMAIL PROTECTED]
Sent: Thursday, October 12, 2006 11:24 PM
To: David Fishburn; vim@vim.org
Subject: Re: VimL and Exuberant tags - Suggestions please
Hello David,
Can I suggest support for these commands:
:set/setlocal/setglobal
:syntax
:highlight (and maybe :HiLink because it is so commonly used)
Some examples:
set foldmethod=syntax
setlocal formatoptions+=roq
setglobal completeopt-=preview
I can see why we might want to track settings, it is often useful to see
where a particular script is changing Vim options.
This can also work for:
let foldmethod='syntax'
let l:foldmethod='syntax'
let g:foldmethod='syntax'
As long as I can turn this off, I am ok with it, otherwise it will be
too much clutter.
syntax keyword phpFunction ...
syn match phpIdentifier ...
syn region phpRegion ...
sy cluster phpClTop ...
syntax clear phpMethods
highlight String ...
hi clear Constant ...
hi link Number ...
hi! link Number ...
hi def link Function ...
HiLink Number ...
These ones I am not certain of the value.
If I open a syntax file, there are somethimes hundreds of these lines. This
would merely identify a syn is there, but there is no real name associated
with the item. So the tag isn't particularily meaningful.
I agree.
Also, as a test case, please include all of the commands to repeat. If
functions repeat, I think you should tag both (it can actually help
catch programmatic error), but if variables repeat, you should tag only
the first one, which is implicitly the declaration also. If there are
non-local variables being set only in a function, it is technically a
declaration for the variable, but I don't usually do this, and when I do
it is a temporary thing, so I am OK not tagging it.
I presume user-commands are already tagged?
--
Thanks,
Hari
These are all pretty straightforward to find.
Also, for dictionary functions would it make sense to mark
them twice, since they get a new 'name' if the dictionary is
copied to a new variable? For
example:
let foo = { }
function! foo.func1() dict
endfunction
let bar = foo
There is now a function called 'bar.func1()', so maybe func1
should be tagged
as:
Dictionary Functions
foo.bar /^function! foo.bar() dict/
.bar /^function! foo.bar() dict/
I have fixed it to return:
foo.func1 as a function tag.
Let bar = foo, if made outside of a function tags bar as a variable. I
will not attempt to figure out what time of variable it is. Seem my
previous response to Tony.
I wouldn't mind if mappings could be tagged as well.
I was thinking on this topic too.
nnoremap silent Leaderyr :YRSearchCR
nnoremap silent F11 :YRShowCR
From maps I guess they have a name, in the above case it would be:
Leaderyr
F11
So these could be tagged.
I know I often open my vimrc and try to find these mappings.
Is there or will there be any way to toggle options for the
way ctags scans vim files?
You can override this yourself already using the taglist.vim plugin.
'a', augroup, autocommand groups
'f', function, function definitions
'v', variable, variable definitions
The current version of ctags tags the above, you can override this and only
capture functions and variables if you like.
I have added another:
'c', command, user-defined commands
And will consider adding more (like maps).
These options can be turned on or off by default. Currently they are all
on. To override it you provide additional information on the ctags command
line. To do this via the taglist plugin you can do something like this in
your vimrc:
let g:tlist_vim_settings = 'vim;a:augroup;c:command;f:function;v:variable'
Dave
__
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
netrw for new extension
Netrw comes with a few supported formats, and the format is deduced by the extension of the file, which is fair, but is there anyway to configure netrw such that it will recognize new extensions as one of the supported filetypes? E.g., there are several archives that are compatible/same as zip archives, except for extra metadata attached them. The jar, ear, war, and the Flex archives (forgot what the extension is), they are all zip archives, so I want netrw to treat them that way. -- Thanks, Hari __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Scanning messages in :messages
When you use ins-completion, Vim starts scanning all the buffers for matches, and this results in several messages, one for each of the buffer. I am wondering if these need to go into the :messages list. If you have several buffers loaded, one completion could potentially take all the existing messages out of the history resulting in any newly added messages right before the completion is started to be thrown away. Can we please have Vim skip them from being added to the :messages list? -- Thanks, Hari __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Re: netrw for new extension
On Fri, 13 Oct 2006 at 3:16pm, Charles E Campbell Jr wrote: Hari Krishna Dara wrote: Netrw comes with a few supported formats, and the format is deduced by the extension of the file, which is fair, but is there anyway to configure netrw such that it will recognize new extensions as one of the supported filetypes? E.g., there are several archives that are compatible/same as zip archives, except for extra metadata attached them. The jar, ear, war, and the Flex archives (forgot what the extension is), they are all zip archives, so I want netrw to treat them that way. If, on the other hand, you're not really talking about netrw, but about the zip plugin -- presumably just include in your .vimrc a line such as: au BufReadCmd *.jar,*.ear,*.warcall zip#Browse(expand(amatch)) Regards, Chip Campbell Right, I somehow thought netrw is the one doing that. Thanks for the information on how to do this with the zip plugin. -- Thanks, Hari __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
java indentation bug?
In the below code, I find that the curly-brace for the method is indented
incorrectly. The first line in the method is also indented incorrectly.
I verified this with gvim starting with -u NONE option and with
:filetype on and :filetype indent on.
public class A
{
public static void main(String[]
args) throws Something {
int i = 0;
}
}
This seems like a bug in the Java indent plugin.
--
Thanks,
Hari
__
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
Re: Folding between #ifdef _DEBUG and #endif
On Wed, 11 Oct 2006 at 1:45pm, [EMAIL PROTECTED] wrote: [EMAIL PROTECTED] дÓÚ 2006-10-11 12:27:33: :FoldMatching #ifdef\ _DEBUG #endif 0 The last parameter is a context, so you might like 1 better than 0 (allows you to see what you are folding). Alternatively, you can also configure the foldtext (see plugin page or the header in the file for information) If you want this to be automatically done everytime you open the file, then you need to create an autocommand e.g.,(untested): au FileType c FoldMatching #ifdef\ _DEBUG #endif 0 Hari, Perfect. That's exactly what I wanted, and I'm sure your script will be useful in many other ways as well Good to find out about it, and thanks for your work. -- Kamil Kisiel [EMAIL PROTECTED] I don't know how it works, but it seems that cannot cope with statements like the following: #ifdef _DEBUG /* only things here should be folded */ #else /* these lines should NOT be folded */ #endif or the following: #ifndef _DEBUG /* these lines should NOT be folded */ #else /* only things here should be folded */ #endif What should I do, if the #if statements may contain #else? especially for the latter one, the #ifndef has #else? For the first case, you can change the end pattern. :FoldMatching #ifdef\ _DEBUG #else 0 For the second case, it is not possible using this plugin, as you want to fold between #else to #endif, but these can be part of any #ifdef or #ifndef. If you are willing to add extra indicators (which is useful in any case, especially if you have nested loops), then something like this: #ifndef _DEBUG /* these lines should NOT be folded */ #else // _DEBUG /* only things here should be folded */ #endif // _DEBUG will give rise to: :FoldMatching #else\ //\ _DEBUG #endif\ //\ _DEBUG 0 -- HTH, Hari __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
RE: ctags for new Vim scripting features
On Wed, 11 Oct 2006 at 10:30pm, David Fishburn wrote: -Original Message- From: Hari Krishna Dara [mailto:[EMAIL PROTECTED] Sent: Wednesday, October 11, 2006 9:18 PM To: vim@vim.org Subject: ctags for new Vim scripting features Is anyone working or planning to work on enhancing exuberant ctags to recognize the dict and autoloaded functions ? Does this require modifying the code, or just some regex patterns? Exuberant tags has been under going some significant changes in the last couple of months. It has been moved to SVN and developers are being added to the project. Each of us volunteer for various components. I maintain two of the modules (sql.c and jscript.c). I am not sure if any one has volunteered for vim.c. I could probably take it on if there are no other volunteers. I have not noticed anything lacking in it to date (minus any new 7.x features). What language elements are you referring to? That would allow me to create a test case. Dave What I see is that ctags fails to extract the right function name, in the below syntax (it basically reports dict and plug as functions): function! dict.func() function! plug#func() In my new plugins, most of the functions are these so I hardly get to make use of ctags. -- Thanks, Hari __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Re: Folding between #ifdef _DEBUG and #endif
On Tue, 10 Oct 2006 at 12:14pm, Kamil Kisiel wrote: I've got some C++ source code that I'd like to fold away. Basically I want vim to have folds only between #ifdef _DEBUG and the corresponding #endif statement, and nowhere else. My vimfu is a bit weak in this respect so I'm not quite sure how I would go about doing this. Using foldexpr, changing the marker type? Previously I was just manually creating folds, but as you can imagine it gets fairly tedious and it would be great if I could automate it. Your help is much appreciated. If the ifdefs that you want to fold are not nested, you can use my foldutil plugin from here: http://www.vim.org/scripts/script.php?script_id=158 You would use something like: :FoldMatching #ifdef\ _DEBUG #endif 0 The last parameter is a context, so you might like 1 better than 0 (allows you to see what you are folding). Alternatively, you can also configure the foldtext (see plugin page or the header in the file for information) If you want this to be automatically done everytime you open the file, then you need to create an autocommand e.g.,(untested): au FileType c FoldMatching #ifdef\ _DEBUG #endif 0 -- HTH, Hari __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Re: bugs in vim scripting highlighting
On Tue, 10 Oct 2006 at 3:29pm, Charles E Campbell Jr wrote: Problem 1 has been addressed in the latest syntax/vim.vim -- please try it out. I think problem 2 was addressed previously. syntax/vim.vim is now up to v7.0-55, and you can get it from http://mysite.verizon.net/astronaut/vim/index.html#vimlinks_syntax You can then select vim.vim syntax. Regards, Chip Campbell I faced a problem, though it is with netrw, not with vim syntax file. I tried to open the download link from Vim, and got the below error: Error detected while processing function netrw#NetRead: line 275: http://mysite.verizon.net/astronaut/vim/syntax/vim.vim.gz; E212: Can't open file for writing VIG3A4.tmp.gz [+][Not edited] --No lines in buffer-- Error detected while processing function netrw#NetRead..SNR115_NetGetFile: line 42: E37: No write since last change (add ! to override) http://mysite.verizon.net/astronaut/vim/syntax/vim.vim.gz; [+][Not edited] --No lines in buffer-- Error detected while processing function gzip#read: line 31: Error: Could not read uncompressed file VIJ3A7.tmp.gz [Not edited] --No lines in buffer-- I got an empty buffer, and when I reloaded the buffer, it worked fine. I am on windows. VIM - Vi IMproved 7.0 (2006 May 7, compiled Sep 10 2006 20:44:39) MS-Windows 32 bit GUI version with OLE support Included patches: 1-99 Compiled by [EMAIL PROTECTED] Huge version with GUI. Features included (+) or not (-): -- Thanks, Hari __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Re: Bug in :(un)lockvar
Bram,
I need to create a doubly linked list and since this will cause problem
with lockvar, I will just comment the lock/unlockvar commands. I am
wondering if you have any plans to fix this issue. The lockvar is a
great way to prevent accidental changes (and it already helped me once)
so I would rather not comment it.
--
Thank you,
Hari
On Sat, 7 Oct 2006 at 5:56pm, Hari Krishna Dara wrote:
On Sat, 7 Oct 2006 at 3:32pm, Bram Moolenaar wrote:
Hari Krishna Dara wrote:
The :lockvar and :unlockvar commands fail when there is a recursive
references. E.g., try the below:
:let a = {}
:let b = {}
:let a.b = b
:let b:a = a
:lockvar! a
E743: variable nested too deep for (un)lock
You could of course end up with more complicated indirect recursive
references as well, so it should guard against it.
Although it's correct as such, I know a trick to detect the same list or
dictionary is encountered a second time, and then don't recurse into it.
Does that mean you will provide a patch? Also note that it could be
a self recursion too (:let a.a = a).
Also, just noticed that string() fails as well.
:echo string(a)
E724: variable nested too deep for displaying
This is much harder to avoid. It's very well possible that a list or
dictionary appears multiple times without a recursive reference. In
that case it should be listed normally. It's not easy to distinguish a
normal reference from a recursive reference.
Why is it hard to distinguish a direct reference and indirect reference?
In any case, this functionality is not much of a use unless you really
want to be able to restore the original structure using eval(), but I
doubt if string() has special semantics to preserve identities.
There are probably others that would fail as well.
What others?
I just meant there could be others, but I looked at the list there
shouldn't be any others.
__
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
RE: tags - alternative ways to use them
On Fri, 6 Oct 2006 at 11:48am, Max Dyckhoff wrote: Hari's new plugin LookupFile is a great use of tags, I use it dozens of times a day! http://www.vim.org/scripts/script.php?script_id=1581 Max Thanks Max :) To stimulate more ideas, with the use of taglist() function, you can essentially pull in any information that you put in the fields such as filename, cmd and kind. As long as you don't include that file in the global 'tags' setting and use :tag command, Vim won't even care what you put in there (you could index your bank accounts e.g.). This means, you are basically using the tag file format as a database to store information and taglist() to look it up. This is probably not the most optimal way to store and index a database, but certainly the easiest (and Vim is generally, surprisingly quick in looking up exact matches). For LookupFile, I am using this approach to index filenames to their full paths. There is nothing preventing you from creating a tag file that indexes keywords to their references (instead of definitions), though id-utils and cscope will probably do a much better job in that. -- Thanks, Hari -Original Message- From: Yakov Lerner [mailto:[EMAIL PROTECTED] Sent: Friday, October 06, 2006 11:45 AM To: Kim Schulz Cc: vim@vim.org Subject: Re: tags - alternative ways to use them On 10/6/06, Kim Schulz [EMAIL PROTECTED] wrote: Most of you probably know about using tags, tagfiles and the taglist plugin, but I am courious if anyone has used the tags functionality in interesting alternative ways? maybe in plugins or simple macros - Actually, I find the way vimhelp system uses tags to jump around by vim topics an interesting alternative way of using tags. Yakov __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Re: Forms highlighting
There is a new version at:
http://haridara.googlepages.com/forms.vim
Significant changes being:
- Support for disabling fields.
- Validator support.
- Cursor monitoring to prevent accidental editing of readonly parts of
the form.
- Several bug fixes.
- F2 to start edit mode.
- Implemented several TODO items.
- Added some new TODO items :)
Combobox functionality is now less flaky, but I have some ideas to make
it better, especially with the readonly version. I have put in several
guards to make sure editing can be done only in the areas where it is
supposed to be done. Please feel free to break this and let me know so
that I can plug any more holes.
I modified the demo to include both enabling/disabling fields as well as
validation (zip field). The demo could be something useful, e.g., a find
dialog like in MS Word, but that could be a lot of work and I would
rather spend that time in improving the script.
See below for my comments.
On Thu, 5 Oct 2006 at 1:19pm, Mikolaj Machowski wrote:
C-N, C-P? It should work everywhere and is quite natural for Vim
users (IMO).
Now C-N and C-P also work like Tab and S-Tab.
I would expect some simplifying in use. For example why explicitly
declare them? Create listeners automatically.
I am not still clear. How can you create listeners automatically? Can
you give some example?
Check example I send earlier. Core stuff is quite simple, big part of it
is overhead dealing with listeners.
Part of it is due to the workarounds you had to put in (which is no
longer needed, I fixed the problem) and the rest is expected if you want
any dynamic nature. If you want to simplify, all that you need is one
listener for the OK button and you are done.
In any case, I have added checks to make callbacks only when the
dict function is defined (with no errors), so there is more flexibility.
You can have all the three callbacks in one dict and use the same dict
for all fields, or split them into different dicts.
- Validators.
Local validation (onBlur event) can be already done. Problem is when
doing after pressing OK. Hmm, in fact it can be also done but is boring
;) to do. Some API for that would be good.
How was onBlur event possible? Previously you could do validation in the
valueChanged() callback, but you couldn't constrain the focus, but the
new isValid() callback allows that.
- When the focus is moved in, explicitly set the value again, to make
sure any fouled up entries are fixed.
Don't understand that. Maybe you were thinking about moving out of
field (onBlur JavaScript event)? It is already possible.
I was just referring to accidentally removing too much (e.g., the {}
bounds of a combobox). Now I am reasonably confident that this is not
possible, so I removed this TODO item.
- Recognize no/empty title.
Title may be declared. Make it support for non showing it, like::
let demoform = g:forms#form.new('Address Entry Form', 1)
To show it and 0 for non showing it.
What is the use of declaring it when not showing? Are you thinking of it
as an identifier, like a name for fields?
One change which would be good to introduce before official beta:
obligatory fields. As I wrote earlier - full validation if possible but
laborious. And declaring it in API should allow for some emphasis
(highlighting?).
Does the new isValid() callback meet your expectations?
--
Thanks,
Hari
__
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
RE: Forms highlighting
On Thu, 5 Oct 2006 at 9:35am, David Fishburn wrote: I gave the demo a whirl. When you enter the State field the omni completion pops up. You cannot hit escape to get out of this. In fact you must choose something, even if you didn't want to. You can press C-E to close the popup, just like for the normal completion popup. Escape restores the old value, but doesn't close the popup. There is a lot of scope for improvements with the combobox, but using the Vim native popup features, it is very hard to do this. I am thinking of using a recursive expr map in combination of getchar() to make this better, but I don't know if it will work. It is right now usable, though a bit flaky. Entering the Country field. If you cursor is on U, press C. I wanted to just type Canada, but of course C in normal mode changes to end of line. So this wiped out the rest of the line. It seems when the is gone, things get messed up. You can't actually type anything. I plugged a lot of such holes in the latest release. I encourage to break it in other ways and let me know how you did it. There is no reward for breaking though :) (well, you could consider a more robust form.vim as a reward). So I restarted the form. When to USA hit cw, typed in Canaada. Realized my mistake, but my cursor on the a and hit x. Since I was in visual mode this left me with xada. Now use the left and right keys to reposition yourself. Very funky behaviour ending up with the existing characters being repeated many times. Actually it does this with h,l as well. This is an issue with complete(), you can only specify the start column, and end column is restricted to the current column, so you can't complete an item when the cursor is in the middle of it. I faced this same issue with LookupFile also, and the solution was to just hide the popup if the cursor is not at the end. I did the same thing here, so you shouldn't see this anymore. That is all I had a chance to try this morning. Thanks for trying, I was actually counting on you :) -- Thanks, Hari __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Re: how to remember file offsets?
On Sat, 7 Oct 2006 at 6:12pm, A.J.Mechelynck wrote:
Yakov Lerner wrote:
Forwarding to the ist
-- Forwarded message --
From: Fletcher Mattox [EMAIL PROTECTED]
Date: Oct 7, 2006 3:21 PM
Subject: Re: how to remember file offsets?
To: Yakov Lerner [EMAIL PROTECTED]
On 10/6/06, Fletcher Mattox [EMAIL PROTECTED] wrote:
Hi,
When I edit two files by typing :e foo and :e #, vim remembers
my current location in each and kindly positions me there when
I revisit them. However, when I edit three or more files, vim forgets
where I was and always positions the cursor at the top of the file.
How do I get vim to remember where I was in an arbitrary number
of files?
Check that you have option 'viminfo properly set
(:help 'vimnifo') in your vimrc; and check that you have
following in your vimrc:
autocmd BufReadPost *
\ if line('\) 0 line('\) = line($) |
\ exe normal g`\ |
\ endif
Yakov
Yakov,
Perfect! Thank you so much for spelling this out. One of the other
list members
alluded to this solution, but I couldn't quite put it all together (I am
a new
vim user) until your email arrived.
Thanks again,
Fletcher
Well, the solution to which I alluded includes this implicitly by having the
line
source $VIMRUNTIME/vimrc_example.vim
near the top of your vimrc.
Best regards,
Tony.
In the vimrc_example.vim, there is a common on this and part of it says:
Don't do it when the position is invalid or when inside an event handler
(happens when dropping a file on gvim).
Any idea what it is exactly talking about? Is the Don't do it part
a comment on how the functionality of the autocommand or an instruction
to the user?
--
Thanks,
Hari
__
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
Re: Bug in updating block markers ?
On Sat, 7 Oct 2006 at 3:32pm, Bram Moolenaar wrote:
Hari Krishna Dara wrote:
The ' and ' markers identify the start and end position of a selection
block and it seems to be not updated correctly in one particular case.
Say you start selection (visual mode or select mode) on one line, and
use ^E or ^Y to scroll the buffer such that the current line goes past
the window bounds and cursor is forced to move to the next or previous
line respectively. This results in the selection getting expanded, but
the markers still return the old values. Here is a utility map that
you can press on the block to see the latest values for these markers:
xnoremap expr F12 T()
snoremap expr F12 T()
function! T()
echo 'mode: '.mode().' start: '.line(').' end: '.line(')
return ''
return ''
Once the selection gets expanded, press F12 on it see that the values
haven't changed (viz., they both will have the same line numbers, for
the original line where the selection started.)
The problem is actually the other way around: While Visual mode is
active the ' and ' marks should keep the old values, from a previous
selection. I discovered the marks get set because of the autoselect
value in 'clipboard' and the a flag in 'guioptions. The patch below
will fix that.
I am not clear on what the expected behavior is. Are you saying that
the marks should be set only after clearing the current selection, and
until then older marks should be preserved? I am pretty sure many
maps have been written using this assumption (I might have one or two as
well) and they will break with your patch.
If the bug has always been there, why not make it the expected behavior?
Do you see any problem with that?
Anyone can think of an alternate way to identify the correct line
numbers? The o command seems to work fine, but I can't use it as I
need to do the checks from a CursorMoved handler.
I don't think you can get the position of the other end of the Visual
area directly. Perhaps by stopping Visual mode, using the ' and '
marks and then using gv to select the same area? It would be a lot
simpler if we have a mark for this.
I first thought this will not a be a valid command to be executed from
CursorMoved autocommand, but the doc doesn't say anything about
executing normal mode commands (there is a warning, but seems like
nothing is explicitly restricted). Anyway, I used the below and it works
well now:
exec 'normal! '.(s:IsSelectMode() ? \C-G : '').\Escgv.
\ (s:IsSelectMode() ? \C-G : '')
The s:IsSelectMode() is just a wrapper around a check on three select
modes.
It is strange that the normal command would not recognize the Esc in
select mode if I don't first switch to visual mode using C-G.
--
Thanks,
Hari
__
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
Re: Bug in updating block markers ?
On Sat, 7 Oct 2006 at 10:08pm, Bram Moolenaar wrote: exec 'normal! '.(s:IsSelectMode() ? \C-G : '').\Escgv. \ (s:IsSelectMode() ? \C-G : '') It is strange that the normal command would not recognize the Esc in select mode if I don't first switch to visual mode using C-G. I dunno. A did a small test and it seemed to work OK for me. I got the gv replacing the selection, as if Esc was never pressed. When I added C-G, it worked fine. No big deal though. -- Thanks, Hari __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Re: how to remember file offsets?
On Sat, 7 Oct 2006 at 8:40pm, A.J.Mechelynck wrote: Hari Krishna Dara wrote: [...] In the vimrc_example.vim, there is a common on this and part of it says: Don't do it when the position is invalid or when inside an event handler (happens when dropping a file on gvim). Any idea what it is exactly talking about? Is the Don't do it part a comment on how the functionality of the autocommand or an instruction to the user? [snip] Inside an event handler means that the autocommand is not defined as nested, which means that the autocommand will not be triggered from within an autocommand for a different event (as when, IIUC, a file is drag-dropped onto an existing gvim window). I don't use drag-drop for Vim so this doesn't bother me. If you often encounter the problem, you might try adding the nested keyword to the autocommand (see :help autocmd-nested) but there might be side-effects. I suppose Bram didn't lightly choose to add a comment rather than a keyword. I don't know where you got the notion of nested in the above comment, but I think you are actually wrong and that it is irrelevant here. When you define an autocommand (call as parent), adding nested keyword allows other autocommands (call as children) to be triggered from the actions performed by the parent autocommand. If BufReadPost got triggered, it means it either triggered as a parent autocommand (as a direct user action), or as a child autocommand of another parent autocommand that allowed nesting. Given the above explanation, I still don't understand the comment. Is there a different autocommand that gets triggered while dnding files? If so which one is it? If that autocommand allows nesting, how are we detecting that BufReadPost is being nested (or a child, in my terms) here (I don't see any special condition). Last but not least, why is setting a position in such a situation wrong? In any case, I actually tried doing dnd of files on gvim with this autocommand, and it seems to just work fine, preserving cursor positions. Is the comment not relevant anymore? Would you care to elaborate your earlier explanation? Sorry for being so finicky, I just want to understand that's all. -- Thanks, Hari __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Re: bufdo search stop at first match
On Sat, 7 Oct 2006 at 12:43pm, Eric Smith wrote: I am using the following to search all buffers for foo. b1|bufdo exec search(foo , flags) This stops at the last match. How do I stop at the first match? thanx The :bufdo and cousines stop when there is an error when the file can't be |abondon|ed, so the easiest to stop is to generate an error, something like: :bufdo g/foo/throw 'Found match' This generates an ugly error message, but at least it works. There may be a more graceful way of generating error that someone can suggest. -- HTH, Hari __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Re: bug in map expr and complete()
On Fri, 6 Oct 2006 at 8:19am, Jürgen Krämer wrote:
Hi,
Hari Krishna Dara wrote:
The help on complete() gives an example as a usage pattern which seems
to be very useful, but it doesn't work. Here is a slightly modified
example to avoid breaking the lines in email transmission:
inoremap expr F5 ListWeeks()
func! ListWeeks()
call complete(col('.'), ['Sun', 'Mon', 'Tue', 'Wed', 'Thu', 'Fri',
'Sat'])
return ''
endfunc
If you hit F5, Vim complains about the complete() as not allowed.
Error detected while processing function ListWeeks:
line1:
E523: Not allowed here
I don't know the reason for this restriction, but it is documented under
:help complete():
I am sorry, what exactly are you referring to as documented? The help on
complete() talks nothing about E523 or why it can't be used in expr
maps. In fact the above example is directly based on the example given
in that help.
--
Thanks,
Hari
__
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
Re: how to remember file offsets?
On Fri, 6 Oct 2006 at 2:53pm, Fletcher Mattox wrote: Hi, When I edit two files by typing :e foo and :e #, vim remembers my current location in each and kindly positions me there when I revisit them. However, when I edit three or more files, vim forgets where I was and always positions the cursor at the top of the file. How do I get vim to remember where I was in an arbitrary number of files? Thanks Fletcher My observation is that if you don't have 'hidden' option set, Vim will unload the buffer when it is hidden. And when you reopen the file using the :e command, it results in getting reloaded, and Vim discards the saved position (somehow this doesn't apply to :e#). A better way is to open existing buffers using :buf and :sbuf commands (which preseve the position) and use :edit only to load new buffers. The :buf commands also allow you to complete names from loaded buffers. -- HTH, Hari __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Re: detecting whether the quickfix window is open
On Fri, 6 Oct 2006 at 3:55pm, Mike wrote:
On 10/6/06, Aaron Griffin [EMAIL PROTECTED] wrote:
On 10/6/06, Mike [EMAIL PROTECTED] wrote:
alternatively: is there a single command to toggle the quickfix
window, rather than issuing :copen and :ccl?
:help cwindow
The problem with :cwindow is that it depends on what is in the
quickfix window. I just want it to open or close, I don't care what
is in there.
There were a couple of suggested functions already, but an alternative way
to track if it is open or not (untested) is to listen to the quickfix
filetype and BufWipeout later.
au FileType quickfix :call SIDQuickFixOpened(1)
let s:quickFixOpen = 0
function! s:QuickFixOpened(b)
if a:b
'au BufWipeout buffer='.expand('abuf').' call SIDQuickFixOpened(0)'
endif
let s:quickFixOpen = a:b
endfunction
Depending on the value of s:quickFixOpen, you can issue the appropriate
command.
--
HTH,
Hari
__
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
Re: bug in map expr and complete()
On Fri, 6 Oct 2006 at 7:48pm, A.J.Mechelynck wrote:
Hari Krishna Dara wrote:
On Fri, 6 Oct 2006 at 8:19am, Jürgen Krämer wrote:
Hi,
Hari Krishna Dara wrote:
The help on complete() gives an example as a usage pattern which seems
to be very useful, but it doesn't work. Here is a slightly modified
example to avoid breaking the lines in email transmission:
inoremap expr F5 ListWeeks()
func! ListWeeks()
call complete(col('.'), ['Sun', 'Mon', 'Tue', 'Wed', 'Thu', 'Fri',
'Sat'])
return ''
endfunc
If you hit F5, Vim complains about the complete() as not allowed.
Error detected while processing function ListWeeks:
line1:
E523: Not allowed here
I don't know the reason for this restriction, but it is documented under
:help complete():
I am sorry, what exactly are you referring to as documented? The help on
complete() talks nothing about E523 or why it can't be used in expr
maps. In fact the above example is directly based on the example given
in that help.
He means this, from
*eval.txt* For Vim version 7.0. Last change: 2006 Sep 22
lines 2019-2023
8
complete({startcol}, {matches}) *complete()* *E785*
Set the matches for Insert mode completion.
Can only be used in Insert mode. You need to use a mapping
with CTRL-R = |i_CTRL-R|. It does not work after CTRL-O or
with an expression mapping.
8
IIUC, expression mapping refers to :imap expr.
:help E523 refers to the 'secure' option.
The difference between your mapping and the example is that you use :imap
expr while the example does not use expr but uses C-R=
I don't know the reason for the restriction but it _is_ documented.
Best regards,
Tony.
Interesting... the 7.0.99 version that I have doesn't have anything that
you are pointing to, and the example clearly used map expr. The
documentation was probably updated later on? What patch version do you
have? Or may be that I updated the vim binaries, not runtime, so I might
not be seeing the updates to documentation.
--
Thanks,
Hari
__
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
Bug in updating block markers ?
The ' and ' markers identify the start and end position of a selection
block and it seems to be not updated correctly in one particular case.
Say you start selection (visual mode or select mode) on one line, and
use ^E or ^Y to scroll the buffer such that the current line goes past
the window bounds and cursor is forced to move to the next or previous
line respectively. This results in the selection getting expanded, but
the markers still return the old values. Here is a utility map that
you can press on the block to see the latest values for these markers:
xnoremap expr F12 T()
snoremap expr F12 T()
function! T()
echo 'mode: '.mode().' start: '.line(').' end: '.line(')
return ''
return ''
Once the selection gets expanded, press F12 on it see that the values
haven't changed (viz., they both will have the same line numbers, for
the original line where the selection started.)
Anyone can think of an alternate way to identify the correct line
numbers? The o command seems to work fine, but I can't use it as I
need to do the checks from a CursorMoved handler.
--
Thanks,
Hari
__
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
Re: detecting whether the quickfix window is open
On Sat, 7 Oct 2006 at 1:56am, A.J.Mechelynck wrote:
Hari Krishna Dara wrote:
On Fri, 6 Oct 2006 at 3:55pm, Mike wrote:
On 10/6/06, Aaron Griffin [EMAIL PROTECTED] wrote:
On 10/6/06, Mike [EMAIL PROTECTED] wrote:
alternatively: is there a single command to toggle the quickfix
window, rather than issuing :copen and :ccl?
:help cwindow
The problem with :cwindow is that it depends on what is in the
quickfix window. I just want it to open or close, I don't care what
is in there.
There were a couple of suggested functions already, but an alternative way
to track if it is open or not (untested) is to listen to the quickfix
filetype and BufWipeout later.
au FileType quickfix :call SIDQuickFixOpened(1)
let s:quickFixOpen = 0
function! s:QuickFixOpened(b)
if a:b
'au BufWipeout buffer='.expand('abuf').' call
SIDQuickFixOpened(0)'
I think the above line needs exe (without the quotes) in front
endif
let s:quickFixOpen = a:b
endfunction
Depending on the value of s:quickFixOpen, you can issue the appropriate
command.
Right, thanks.
--
Thanks,
Hari
__
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
Bug in :(un)lockvar
The :lockvar and :unlockvar commands fail when there is a recursive
references. E.g., try the below:
:let a = {}
:let b = {}
:let a.b = b
:let b:a = a
:lockvar! a
E743: variable nested too deep for (un)lock
You could of course end up with more complicated indirect recursive
references as well, so it should guard against it.
Also, just noticed that string() fails as well.
:echo string(a)
E724: variable nested too deep for displaying
There are probably others that would fail as well.
--
Thanks,
Hari
__
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
bug in map expr and complete()
The help on complete() gives an example as a usage pattern which seems
to be very useful, but it doesn't work. Here is a slightly modified
example to avoid breaking the lines in email transmission:
inoremap expr F5 ListWeeks()
func! ListWeeks()
call complete(col('.'), ['Sun', 'Mon', 'Tue', 'Wed', 'Thu', 'Fri', 'Sat'])
return ''
endfunc
If you hit F5, Vim complains about the complete() as not allowed.
Error detected while processing function ListWeeks:
line1:
E523: Not allowed here
I am assuming that this is another place where the code is too strict
than required (like setting :compiler in a FileChangeRO handler that I
reported long back).
I tried to modify this such that expr is not used, like this:
inoremap F5 C-R=ListWeeks()CR
and it works fine, but expr approach is superior and more flexible.
Also, while playing with the above (by pressing F5 repeatedly while
opening new lines) I observed that occassionally, Mon gets inserted
instead of Sun. I can't find a reproduciable case other than trying to
bring up popup several times (happened twice while trying may be about
20 times). I have observed this in general while using the complete()
function that Vim advances one too many items in the completion list
(happens very often with my LookupFile plugin).
--
Thanks,
Hari
__
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
Re: Patch 7.0.111
On Wed, 4 Oct 2006 at 10:30pm, Bram Moolenaar wrote: Fan Decheng wrote: Bram Moolenaar wrote: Patch 7.0.111 Problem:The gzip plugin can't handle filenames with single quotes. Solution: Add and use the shellescape() function. (partly by Alexey Froloff) Files: runtime/autoload/gzip.vim, runtime/doc/eval.txt, src/eval.c, src/mbyte.c, src/misc2.c, src/proto/misc2.pro [...] I wonder whether it is possible to use execv() instead of escaping the command and then sending it to the shell. How do you think? Vim doesn't have an execv() function. Implementing this properly for all systems isn't that simple. At least you would need to take care of $PATH. How about using the underlying execv() where it is supported, and when it is not support just behave like system() does? This approach will probably cover more than 95% of the vim users. The problems that exist with using system() and different shells and environments is a huge usability issue (this will also avoid the minimized window on windows that most people feel bothered), and it might even make big difference in the performance when external commands are executed often (like using external commands to find matches for popup completion, everytime a character is typed). One caceat is that currently, if the external command execution takes a lot of time, you want to terminate it, you can un-minimize the window and kill it. If this window is avoided, Vim should still provide a means to kill it (like doing an explicit kill() when user presses ^C while waiting for the process). -- Thanks, Hari __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Re: Forms highlighting
On Wed, 4 Oct 2006 at 10:37pm, Mikolaj Machowski wrote: Dnia ¶roda, 4 pa¼dziernika 2006 05:06, Hari Krishna Dara napisa³: No. They are inserting some version of keycode: OA, OB, OC, OD. In gui everything works well. In menus enabled Doesn't that just mean your term is not properly setup? I tried it on win32 console vim and it worked just fine. It is normal setup. Arrows doesn't work in xterm, konsole, rxvt. I have 6.3 version of cygwin and arrows work fine in rxvt. I stil think your term settings are not right. But this is not really concern forms plugin, though it means we might have to support some other maps that will reliably work in all the terms. Bug: When completely remove value, leave field and later return to it default value is forgotten, Esc is going to Normal mode. This is not a bug. When you leave the field, the value is immediately saved, which means the new empty value overwrote the old value. When you return back to the field, this empty value becomes your new default value. Hmm. Not sure if this is expected behavior, maybe other users could tell more? Who? No one seems to be interested, it is just us :) Bug: Form is creating swap file which makes hard to use simultaneously the same form in various Vims when editing files in the same directory. Solution: Add 'setl noswapfile' after 'setl nomodified' in SetupBuf function (this is local option and but it is easier to read when explicitly declaring as local). This is really not a bug. Since the user is creating the buffer, it is his responsibility to set noswapfile if he is intending to open the same form multiple times. We could set noswapfile in forms, but then if the Vim crashes in the middle of the form entry, the user could loose some important data :) OK. At least for demo use just new instead of new Form. I intended that as a clue on the usage (suggesting a nice name for the buffer). Setting 'noswapfile' is not sufficient if you create multiple buffers with the same name (Vim will essentially open the same buffer in new windows). If we have to demo the ability to create multiple forms then some buffer management will need to be done there (creating unique buffers, tracking which form is shown in which buffer etc.). Again, since user is creating the window for now I think we should leave this to the user. When buffer management is implemented in forms, we can set these parameters. Problem with current implementation is that user cannot influence dimensions of buffer. Before calling ShowForm he don't know them later it doesn't work. Don't know why, when placing above lines after ShowForm call formwidth is computed but it only places _ in first field. I don't know why it wouldn't work later, but I can certainly add functions to determine the widthPreference and heightPreference of the form. One bug: On X11 @* (you are using to store form in clipboard) is selection, which means that it will be overwritten by [OK] (visually selected with normal navigation). At least on Unix systems you should use @+ clipboard (don't know how it works on Windows). BTW - you don't have to play with if/endif:: let @* = address let @+ = address will do. I will make this change. Another thing. Until now I was only playing with demo. Now I tried to do my own form and have one thing to say: Listener stuff is complicated. Can it be done simpler? Do you mean simplify the listener interface, or completely do away with them? - If you mean the former, then the alternative is to accept a function name (this is what my previous version worked). But a big problem with this is that the function has to be global and I hate defining global functions without intending them to be part of API, and I know several others feel the same. The current scheme of expecting a dict object should be more familiar to many, who worked with the newer GUI frameworks (such as Swing and Flex). While not having to define a global dict variable, it also provides a way to create more contextual listeners (you can e.g., put the form that the listener is attached to, without having to modify the listener interface to also expect the form object). - If you mean the later, then I don't know how we can do that. If you have any ideas, you can throw them on me. May be a scriptlet can be passed in as a string instead of a dict object, but I don't know if this can always make it simple. It may however be possible to support both. What do you think are the next priority TODO items before making the first release (or a beta release)? I am thinking if I fix the known issues and implement the items that improve the overall feel of a static form, it will be good enough. Right now, there are too many ways the user can end up in 'modifiable' mode and just remove/change anything, giving the impression that the plugin is not robust). -- Thanks, Hari
Re: Time to remove naming restrictions?
On Tue, 3 Oct 2006 at 10:30am, A.J.Mechelynck wrote: Nikolai Weibull wrote: On 10/1/06, Bram Moolenaar [EMAIL PROTECTED] wrote: Nikolai Weibull wrote: One thing that really annoys me with Vim is the limits it emposes on what names are legal for user-defined functions and commands. I know the reason for these restrictions, but I don't think they make much sense, especially so for user-defined commands. I realize that overriding :quit does have its implications, but done carefully, this does allow for some interesting effects. So, why not lift the restrictions on valid names for user-defined functions and commands? That is, give me good reasons for why they should be maintained and I'll drop this request. Predictability. As in what? That :quit always works as documented? Sure, that's great, but if that's the problem, the restriction should be limited to commands already defined. And what happens when more commands are added? Hell, then they'll break the user-defined commands with the same name. Big deal; that's life, you'll get over it - everyone does, eventually. I really don't see the big difference between user-defined commands clashing with built-in commands and user-defined commands clashing with each other. It'll happen; unless you start adding prefixes or namespaces or some other way of separating your commands. But then you lose out on simplicity. You don't want to type :NOWCommand (given that NOW is my prefix), and I don't want to type :Command; I want to type :command. Sure, it only saves my fingers from giving up on me for so long, but every little bit helps. I guess my problem is that I want - and I've always wanted - the flexibility of Emacs coupled with the simplicity and efficiency of Vim's command set and modes. I guess that's why I nitpick at things such as this. nikolai :command -bar Command ... :cabbrev command Command and then you'll wonder why you can't define a new user-command but it's your funeral. It's still not perfect though; the cabbrev will be expanded even if it's not at the start (but that may be not-so-bad if you use :verbose command, :vertical command, etc.) Best regards, Tony. You can use the Vim7 expr abbreviation in combination of getcmdpos() and getcmdtype() to make this a lot more reliable, and avoid expanding everywhere. I have created the cmdalias.vim plugin (http://www.vim.org/script.php?script_id=745) just to address this problem (as it bothered me as well). The only case this breaks is the debug mode because of a bug in Vim (the expression itself is executed in the debug mode). Another oddity in using this approach is the history. If you execute: :command what will end up getting stored in the history is: :Command which means you have to remember to use the righ case while retrieving the last command (:comUp will not work). -- HTH, Hari __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Re: Forms highlighting
I have updated it again. The main difference is some syntax highlighting rules and some tweaks. I also changed the hotkey to link to Underlined, which has both a color as well as underscore by default (and I doubt any colorscheme change this). I also added a few extra rules/conditions to highlight the right hotkey as well as the boundaries of fields and button labels. -- Thanks, Hari On Mon, 2 Oct 2006 at 5:33pm, Hari Krishna Dara wrote: My comments below. If anyone is still interested to try, here is how you do it: - Download the below file and put it in your autoload directory: http://haridara.googlepages.com/forms.vim - Start a fresh Vim session and execute: :call forms#demo() - Optionally, remove the downloaded file after you are done trying. It is very easy and safe to try it (I hope I haven't scared away folks with the warning in my previous email :) On Tue, 3 Oct 2006 at 1:31am, Mikolaj Machowski wrote: Hello, Below patch to yesterday version of forms.vim . Rather proof of concept than full solution but looks much nicer: Features: - highlight header of form in Comment - highlight labels of fields as Questions - hightlight hotkeys as Statements I applied your patch and it looks very nice, thanks for taking the time. One minor problem is that if the hotkey repeats multiple times in the label, it is highlighted multiple times. Limitations: - Buttons are not supported We can also highlight checkboxes and comboboxes differently. Problems with current version of forms: - arrows doesn't work in terminal. They are completely messing things eg. destroy knowledge about default value. Do arrows work like j and k outside form? Since I am mapping Up and Down keys, as long as they work outside form, I am assuming they shoudl work inside form also. - when there is more than one the same character as hotkey repeating hotkey doesn't cycle between them. It stucks with last entry with that hotkey I noted this down as a limitation for now. We can look at it later. I am creating a map of hotkey-field which will obviously not work if the same hotkey is used multiple times. On Mon, 2 Oct 2006 at 10:28am, Mikolaj Machowski wrote: Maybe not all. You should catch only switching between major modes and vertical movement. The rest isn't so important. When you Tab into the fields, the values are first selected so that the user can easily overwrite it (like most GUIs do). However, the user can press Esc once to get into the normal insert mode and change the values (there is currently a known issue with this that you can't change the value, unless 'backspace' has start). If you want, you can press Esc again to get into the normal mode to move around, but this will put the buffer in a 'readonly' state, so when you find the field that you want to edit, you can press Space on the field to get back into edit mode. Let me know if you have ideas on how this can be improved. After some consideration C-K wasn't best suggestion. I think in such forms is bigger probability of digraphs than somewhere else. Other possibilities; C-F (may break behave mswin and/or Cream - obvious client of such script); C-D/T no mnemonic value but are covering indenting mappings. How about using C-G? i_CTRL_G is used to move around the buffer, which we prevent anyway, and it could be a good mnemonic too. Maybe you are right. I am biased here - I hate buffer management and if someone else can take care about that... ;) I agree, buffer management is messy, which is why putting the task on the user makes it a little easier for the first version to get out :) I have now uploaded a version with your changes. http://haridara.googlepages.com/forms.vim This version also contains an API to create forms. The forms#demo() function shows you how to use the API. You can invoke it as: :call forms#demo() I will enhance the demo with some buffer management as a suggested pattern for the users. Are you interested to use the forms for any of your plugins or are you just helping me out? :) (in either case, many thanks). I wish more people will come forward to try and give feedback, especially that it is so easy to try it. -- Thanks, Hari __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Re: Forms highlighting
A new version is available, to try:
- Download the below file and put it in your autoload directory:
http://haridara.googlepages.com/forms.vim
- Start a fresh Vim session and execute:
:call forms#demo()
The new version has support for listening to changes in the field
values. The demo can now automatically lookup city and state when you
fill in your zipcode using a webservice (you need wget in the path and
need Internet connection).
On Tue, 3 Oct 2006 at 11:59am, Mikolaj Machowski wrote:
Do arrows work like j and k outside form? Since I am mapping Up and
Down keys, as long as they work outside form, I am assuming they
shoudl work inside form also.
No. They are inserting some version of keycode: OA, OB, OC, OD. In gui
everything works well. In menus enabled
Doesn't that just mean your term is not properly setup? I tried it on
win32 console vim and it worked just fine.
Bug: When completely remove value, leave field and later return
to it default value is forgotten, Esc is going to Normal mode.
This is not a bug. When you leave the field, the value is immediately
saved, which means the new empty value overwrote the old value. When you
return back to the field, this empty value becomes your new default
value.
Bug: Form is creating swap file which makes hard to use simultaneously
the same form in various Vims when editing files in the same directory.
Solution: Add 'setl noswapfile' after 'setl nomodified' in SetupBuf
function (this is local option and but it is easier to read when
explicitly declaring as local).
This is really not a bug. Since the user is creating the buffer, it is
his responsibility to set noswapfile if he is intending to open the same
form multiple times. We could set noswapfile in forms, but then if the
Vim crashes in the middle of the form entry, the user could loose some
important data :)
Wish: different highlighting of in drop-down menu (State) and
combobox (Country). Maybe use {} somewhere?
Makes sense, I took a note in the TODO.
I looked in the code: you are making just difference between editable
and non-editable combobox. IMO would be better to split this in two
widgets: combobox and dropdown menu. With that you will be able to make
visual differences between those two items (highlighting, braces).
I don't know if this is more intuitive, but I know Java Swing/AWT
framework (the only GUI framework that I am familiar with) doesn't have
separate widgets.
Good thing would be possibility to scale height of buffer to height of
form and width [1]. Usually when filling you want to check context. Also
in space preserving department: header is 3 lines high. First - empty
line should go to /dev/null; second - value of separator is doubtful
when highlighting works.
[1] User may want to split window vertically. Maybe full buffer
management isn't required but some elements for making it easier to user
would be good: eg. length and width of form.
This is complete addition to beginning SetupBuf::
setl noswapfile
let formheight = len(b:curForm.fields) + 3
exe normal! .formheight.\C-W_
let formwidth = b:curForm.maxLblSize * 2
exe normal! .formwidth.\C-W|
We have to be careful in doing this. E.g., if you change the height
while there is only one window, Vim will behave strangely. I don't know
if there is any similar side effect of changing the width when there is
only one window. Again, since user is creating the window for now I
think we should leave this to the user. When buffer management is
implemented in forms, we can set these parameters.
Unfortunately it goes wild when form will be opened in vertical
window...
What do you mean?
Are you interested to use the forms for any of your plugins or are you
just helping me out? :) (in either case, many thanks).
I have idea where I would like to use it but at the moment it is rather
vague (tag form for HTML/XML editing). At the moment I want to have
something good in tool-box (new screwdriver syndrome ;)
I get several such urges and try to control myself. :)
E.g., I created a softtabstop plugin to allow setting tabs at arbitrary
locations (just like a word processor), just for the fun of it and
because I needed it once. However, after I finished it a few weeks back,
I didn't need to use it even once. :))
--
Thanks,
Hari
__
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
Re: Local scope ?
On Wed, 4 Oct 2006 at 5:09am, Meino Christian Cramer wrote: Hi, when writing a function in vim script sometimes it makes sense to change options of vim. Are these changes local to the function ? And if not: Can I simply assign the current value of the option to a variable, change the option and restore the option value from the value stored in that variable ? Or is this way just another kind of shooting into my own feet ? :) Keep hacking! mcc Yegappan already answered your question. However, in case you want to do the whole of it in the same function, I recommend the below pattern: let _ic = ignorecase set noic try do something finally let ignorecase = _ic endtry -- HTH, Hari __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Re: Forms highlighting
My comments below. If anyone is still interested to try, here is how you do it: - Download the below file and put it in your autoload directory: http://haridara.googlepages.com/forms.vim - Start a fresh Vim session and execute: :call forms#demo() - Optionally, remove the downloaded file after you are done trying. It is very easy and safe to try it (I hope I haven't scared away folks with the warning in my previous email :) On Tue, 3 Oct 2006 at 1:31am, Mikolaj Machowski wrote: Hello, Below patch to yesterday version of forms.vim . Rather proof of concept than full solution but looks much nicer: Features: - highlight header of form in Comment - highlight labels of fields as Questions - hightlight hotkeys as Statements I applied your patch and it looks very nice, thanks for taking the time. One minor problem is that if the hotkey repeats multiple times in the label, it is highlighted multiple times. Limitations: - Buttons are not supported We can also highlight checkboxes and comboboxes differently. Problems with current version of forms: - arrows doesn't work in terminal. They are completely messing things eg. destroy knowledge about default value. Do arrows work like j and k outside form? Since I am mapping Up and Down keys, as long as they work outside form, I am assuming they shoudl work inside form also. - when there is more than one the same character as hotkey repeating hotkey doesn't cycle between them. It stucks with last entry with that hotkey I noted this down as a limitation for now. We can look at it later. I am creating a map of hotkey-field which will obviously not work if the same hotkey is used multiple times. On Mon, 2 Oct 2006 at 10:28am, Mikolaj Machowski wrote: Maybe not all. You should catch only switching between major modes and vertical movement. The rest isn't so important. When you Tab into the fields, the values are first selected so that the user can easily overwrite it (like most GUIs do). However, the user can press Esc once to get into the normal insert mode and change the values (there is currently a known issue with this that you can't change the value, unless 'backspace' has start). If you want, you can press Esc again to get into the normal mode to move around, but this will put the buffer in a 'readonly' state, so when you find the field that you want to edit, you can press Space on the field to get back into edit mode. Let me know if you have ideas on how this can be improved. After some consideration C-K wasn't best suggestion. I think in such forms is bigger probability of digraphs than somewhere else. Other possibilities; C-F (may break behave mswin and/or Cream - obvious client of such script); C-D/T no mnemonic value but are covering indenting mappings. How about using C-G? i_CTRL_G is used to move around the buffer, which we prevent anyway, and it could be a good mnemonic too. Maybe you are right. I am biased here - I hate buffer management and if someone else can take care about that... ;) I agree, buffer management is messy, which is why putting the task on the user makes it a little easier for the first version to get out :) I have now uploaded a version with your changes. http://haridara.googlepages.com/forms.vim This version also contains an API to create forms. The forms#demo() function shows you how to use the API. You can invoke it as: :call forms#demo() I will enhance the demo with some buffer management as a suggested pattern for the users. Are you interested to use the forms for any of your plugins or are you just helping me out? :) (in either case, many thanks). I wish more people will come forward to try and give feedback, especially that it is so easy to try it. -- Thanks, Hari __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Re: forms support for Vim
First, a big thank you for trying it and giving feedback. On Sun, 1 Oct 2006 at 4:11pm, Mikolaj Machowski wrote: Hello, Interesting concept. The most difficult thing are Vim habits. Seeing spelling error in line before I tend to make Esck than S-Tab which is obviously messing things. Yes, that will be a problem, For short forms, this will not be much of a problem, as you don't expect to spend a lot of time on them (that is when your inherent habits start to show up). Covering all the vim movement commands and supporting them will be a lot of pain and maintenance. - Use Esc in fields to cancel changes and restore old value. This doesn't work. I am getting Plug17|v$h Sorry, I broke this later. As I said, it was meant to be a proof-of-concept, so I wasn't really testing all the features :) Cannot accept entry from combobox, CTRL-Y jumps to first element, anything else doesn't work or insert Plug17|v$h. Fixed. Plug thing is inserted also when hitting Esc twice. Fixed. I would appreciate any kind of feedback on this. Random remarks: After completely removing of entry tabbing goes wild (it works only from first entry to removed one). Fixed. Combobox (Zip-code) is only drop-down menu: in combobox you should be able to insert your own values. This will be a editable combobox, and I didn't implement it as of last time (it was there in the TODO), however it is now implemented and the Country field in the demo allows you to do this. Avoid M- mappings. They don't always and everywhere work. Better use something like C-Kf to go to the First name field. Good comment, I am now mapping both the meta keys as well as your suggested C-K keys. Introduce Arrows (Up, Down) navigation. Although Tab works everywhere S-Tab doesn't work in terminal. Currently Up, Down are extending visual selection to other fields. Good comment again, both work now. On combobox, the Down in addition opens up the popup (if not already open). When open, you can only Tab out forwards or S-Tab out backwards, but when not open You can also use Up out backwards (but as I said Down will popup completion). Hotkey emphasis should be rather done with syntax highlighting, not underscore (not always available). I took note of this. I don't have much idea of how to implement syntax coloring right now. Full version should take care about creation and destruction of buffer. With all this mappings it is tricky. For the first implementation, this is not important. With all the mappings, it is hard for the plugin to manage a single buffer for all the forms. E.g., if clicking on a button should bring up another form, then it is better to use a different buffer. It is easier for the client of forms plugin to create a new window with a new temp buffer and show forms, and wipe it off at the end. Handling this inside forms plugin will need more thought. Your comments are welcome. Thanks again for your feedback. I uploaded the new version here: http://haridara.googlepages.com/forms.vim I will add API to create forms and a few other things next. I have to implement some more features (especially the user-completion on fields) before I can start using it for myself. -- Thanks, Hari __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
RE: Take Two: Pasteboard sans HTML
On Sun, 1 Oct 2006 at 6:53pm, Suresh Govindachar wrote: Calvin Waterbury asked on Sunday, October 01, 2006 3:04 PM for a pasteboard feature. This is a feature that automatically captures clipboard content to a text file that has been designated as the Pasteboard. Perhaps an example would clarify. If I had this feature implimented in VIM I would do the following: - Open a text ed window - Set it to be the Pasteboard - Switch to whatever window I want to capture (webpage text like a recipe, another text file, etc.) --- [1]Select the first text item --- [2]Copy to clipboard --- [3]Repeat [1] and [2] until done. - Go back to the Pasteboard window and I would see all of my captures neatly separated by whatever separator (a line of hyphens, equal signs, etc.) I had set in the Options. - Turn off the Pasteboard - Save the file. [Tony: OP is asking about copying to a VIM buffer stuff fed to the MS Windows clipboard _not_ from other VIM buffers but from non-vim applications.] One way to implement this feature is by using VIM's support for perl and the Win32::Clipboard module. --Suresh How about looping in a vim script for changes in clipboard register and paste it into a buffer everytime a change is detected? The :sleep command accepts millisecond granularity, so you can tune the wait period such that you can detect the changes fast enough without seein 100% CPU. Once you enter into the loop, you can't use the Vim session for anything else, but then this may not be bad as you are not using Vim during that time, and you can start other Vim sessions if you still need to use Vim. -- HTH, Hari __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Re: scripting of listing commands
On Sat, 30 Sep 2006 at 9:33am, Yegappan Lakshmanan wrote: Hi, On 9/30/06, Meino Christian Cramer [EMAIL PROTECTED] wrote: Hi, I want to write a little function in vim script to put all settings into a file. I want the output of :map :version :set (and more of this kind, if I will find them all...) to go into that file. From the list I learned that redir is the command of choice here. But I want the function to doi its work non-interactively. But :map (for example) wants SPACE to be pressed. Hmmm... Can I do something like :ignore_guy_in_front_of_the_monitormap (not thinking, that this really exists...) ??? You can reset the 'more' option to disable the more prompt for the above commands: :set nomore :map :set :version :set more For more information, read the following help: :help 'more' :help more-prompt - Yegappan I also suggest taking a look at the bugreport.vim in the Vim installation root. -- Hari __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
forms support for Vim
As I was building complex code generation framework, I realized that asking for user input for several options is cumbersome and unproductive (especially when most of the options are anyway defaulted). I have seen some very clever use of dialogs in the form of wizards before (I think in the cream project), but it is cumbersome to build and not to my taste either. All that I need is a very simple presentation of a form with data and allow the user to change only the fields that are required, so I started experimenting and came up with a few maps that allow form like features such as tabbing between fields and pressing buttons. It works somewhat like the plugin that allows you to see and change Vim settings in a buffer (can't recollect where I saw it), but allows ad-hoc building of forms, more like a GUI (with no frills), so plugins can define forms and show them for user input. It has a very simple interface and forces some habbits on the user, but I think it is still much better than not having anything. With some more improvements (especially the syntax coloring) and more widget support, it can be very useful. The plugin is still in a proof-of-concept stage, but you can actually define forms and play with them. Before I go ahead and spend a lot more time, I thought it is wise to get the opinion of the experts here and get the feedback as a whole (and may be even generate some interest for contribution). It is available from: http://haridara.googlepages.com/forms.vim I have included the definition of a demo form so to try, all that you need to do is download the above file and put in your autoload directory and execute: :call forms#ShowForm(forms#form) The hotkeys are not currently highlighted, but they are functional, so try pressing the first letter of field names with the meta combination (e.g., M-f for the First Name: field). Here are the features that I implemented so far: - Supports textfield and button fields. - Supports tabbing between fields. - Hotkeys to jump to a field directly. - Listeners for actions on buttons. - Use Esc in fields to cancel changes and restore old value. - Support for default button by hitting Return anywhere. I think support for combobox and checkbox will make this truly distinguishable from using dialogs and such. Vim7 popup completion will be a great fit for implementing combobox. Here are the TODO items I have noted so far: - Constructors/utilties for creating form objects (createForm(), addField() getField(), etc.). - Syntax highlighting: - labels - Buttons - Hotkey (underline) - ComboBox using completion popup. Optional user completion. - CheckBox using True/False combobox or [x] style buttons. - Support for disabling fields. - Mouse support. - Trap C-C and disable 'modifiable' I would appreciate any kind of feedback on this. -- Thanks, Hari __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Re: no winclose event
On Wed, 27 Sep 2006 at 10:07am, Charles E Campbell Jr wrote:
Bram Moolenaar wrote:
Charles Campbell wrote:
Just a suggestion -- I'd appreciate a WinClose event. BufWinLeave would
almost do, but if two or more windows are open on the same buffer, then
no event. WinLeave fires whenever one changes windows, which isn't
what I want, either. Unless I'm misunderstanding the help for these two
events.
What would this event be used for?
The WinResized event has also been suggested. It could be used to
update the Window layout. It will also be triggered when a window is
closed, since another window will get bigger then. Would it be
sufficient to only have a WinResized event? Would these events also be
triggered when closing the last window of a tab page?
As an example: I have debugging output in a left hand window (Decho.vim
produces this sort of output);
when I hit f9 on a function name, a vertically split window shows up
on the right and tags to the
named function. However, if that window already exists, I just want to
re-use it, not split and create another
one. To do that correctly, I need that window, when it is actually
closed, to perform some cleanup (ie. make a change
in a script variable). I want to allow other vertical windows, so there
isn't necessarily a fixed number of vertically
split panes. Actually, the script also allows s-f9 to create a left
hand source window: [leftsource|debugging|rightsource].
The leftsource and right source windows may well be open to the same
source file. Consequently the various buffer
closing events aren't adequate. BufWinLeave almost does the trick, but
there's that not when a buffer is still visible
in another window caveat associated with it. That's what I've been
using, but it really isn't adequate.
A WinResized might easily occur when that window wasn't closed, too.
Regards,
Chip Campbell
FYI, the last I needed this event, I wrote a function to do this. It is
part of genutils.vim as NotifyWinClose(). Here is the implementation
(written as a generalization), it is kind of heuristic (see
CheckWindowClose). I will be happy to see a WinClose event though.
let s:notifyWindow = {}
function! genutils#AddNotifyWindowClose(windowTitle, functionName)
let bufName = a:windowTitle
let s:notifyWindow[bufName] = a:functionName
let g:notifyWindow = s:notifyWindow Debug.
Start listening to events.
aug NotifyWindowClose
au!
au WinEnter * :call genutils#CheckWindowClose()
au BufEnter * :call genutils#CheckWindowClose()
aug END
endfunction
function! genutils#RemoveNotifyWindowClose(windowTitle)
let bufName = a:windowTitle
if has_key(s:notifyWindow, bufName)
call remove(s:notifyWindow, bufName)
if len(s:notifyWindow) == 0
unlet g:notifyWindow Debug.
aug NotifyWindowClose
au!
aug END
endif
endif
endfunction
function! genutils#CheckWindowClose()
if !exists('s:notifyWindow')
return
endif
Now iterate over all the registered window titles and see which one's are
closed.
for nextWin in keys(s:notifyWindow)
if bufwinnr(s:FindBufferForName(nextWin)) == -1
let funcName = s:notifyWindow[nextWin]
Remove this entry as these are going to be processed. The caller can
add
them back if needed.
unlet s:notifyWindow[nextWin]
call input(cmd: . cmd)
call call(funcName, [nextWin])
endif
endfor
endfunction
Here is a test case that shows how to use it:
function! NotifyWindowCloseF(title)
call input(a:title . closed)
endfunction
function! RunNotifyWindowCloseTest()
call input(Creating three windows, 'ABC', 'XYZ' and 'b':)
split ABC
split X Y Z
split b
redraw
call genutils#AddNotifyWindowClose(ABC, NotifyWindowCloseF)
call genutils#AddNotifyWindowClose(X Y Z, NotifyWindowCloseF)
call input(notifyWindow: . string(s:notifyWindow))
au NotifyWindowClose WinEnter
call input(Added notifications for 'ABC' and 'XYZ'\n.
\ Now closing the windows, you should see ONLY two notifications:)
quit
quit
quit
endfunction
--
Thanks,
Hari
__
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
Re: taglist() bugs related to 'tags'
On Wed, 27 Sep 2006 at 9:53pm, Bram Moolenaar wrote:
Hari Krishna Dara wrote:
I am observing that the taglist() function is not sensitive to the
changes in 'tags' value. It also seems to cache the value of 'tags' as
of the time the function is called for the first time. To reproduce the
problem (you need to have patch 96 applied, otherwise there is another
bug in 7.0GA that could mask the bug that the below is trying to show),
- create a directory with at least one file that ctags recognizes. Make
a copy of this directory.
- Run ctags in both directories to create tags file. They will
essentially be identical.
- Start vim/gvim and cd to one of the directories. Have 'tags' set to
./tags.
- Execute taglist() on a tag that you know exists, something like:
:echo taglist('main')
- Now, cd into the other directory, and run the same command. You will
see that the tags are reported from the other directory.
- Change 'tags' to the absolute path to the second directory and run
the
echo command again. You will still observe that taglist() is using
the
previous tags file.
Can anyone confirm that they can reproduce this?
Did you take into account that Vim uses ./tags as the tags file
relative to the current file? Try editing another file after the :cd
command. Or use the value tags, which means the tags file in the
current directory.
Frankly speaking I didn't know that ./tags is relative to the current
file (I was expecting it to be relative to the current directory),
however that makes no difference to this bug.
- when you run taglist() in the above steps, there is no file opened.
- I repeated the experiment with just tags as the value for 'tags'.
- I also tried hardcoding the tags value to the absolution paths of both
tags files, something like: c:/tmp/t1/tags,c:/tmp/t2/tags and later
changing it to something like c:/tmp/t1/tags, but it continues to
show results from both tags files.
Using Vim with patch 7.0.096 it works just fine for me. I can only
explain the behavior when 'tags' is set to ./tags. The result of
taglist() is not cached.
I am using taglist() from lookupfile plugin and find that changing the
tags value for looking up files doesn't have an impact on the results.
While debugging I verified that the right value is getting set to 'tags'
setting, but still it returns results for the prior 'tags' value. I also
couldn't reproduce this in a standalone environment (like calling
taglist() from command-line), I apologize for wasting your time. I need
to spend some more time to isolate the problem.
--
Thanks,
Hari
__
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
Re: taglist() bugs related to 'tags'
On Tue, 26 Sep 2006 at 11:03am, Bram Moolenaar wrote:
Hari Krishna Dara wrote:
I am observing that the taglist() function is not sensitive to the
changes in 'tags' value. It also seems to cache the value of 'tags' as
of the time the function is called for the first time. To reproduce the
problem (you need to have patch 96 applied, otherwise there is another
bug in 7.0GA that could mask the bug that the below is trying to show),
- create a directory with at least one file that ctags recognizes. Make
a copy of this directory.
- Run ctags in both directories to create tags file. They will
essentially be identical.
- Start vim/gvim and cd to one of the directories. Have 'tags' set to
./tags.
- Execute taglist() on a tag that you know exists, something like:
:echo taglist('main')
- Now, cd into the other directory, and run the same command. You will
see that the tags are reported from the other directory.
- Change 'tags' to the absolute path to the second directory and run the
echo command again. You will still observe that taglist() is using the
previous tags file.
Can anyone confirm that they can reproduce this?
Did you take into account that Vim uses ./tags as the tags file
relative to the current file? Try editing another file after the :cd
command. Or use the value tags, which means the tags file in the
current directory.
Frankly speaking I didn't know that ./tags is relative to the current
file (I was expecting it to be relative to the current directory),
however that makes no difference to this bug.
- when you run taglist() in the above steps, there is no file opened.
- I repeated the experiment with just tags as the value for 'tags'.
- I also tried hardcoding the tags value to the absolution paths of both
tags files, something like: c:/tmp/t1/tags,c:/tmp/t2/tags and later
changing it to something like c:/tmp/t1/tags, but it continues to
show results from both tags files.
--
Thanks,
Hari
__
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
taglist() bugs related to 'tags'
I am observing that the taglist() function is not sensitive to the
changes in 'tags' value. It also seems to cache the value of 'tags' as
of the time the function is called for the first time. To reproduce the
problem (you need to have patch 96 applied, otherwise there is another
bug in 7.0GA that could mask the bug that the below is trying to show),
- create a directory with at least one file that ctags recognizes. Make
a copy of this directory.
- Run ctags in both directories to create tags file. They will
essentially be identical.
- Start vim/gvim and cd to one of the directories. Have 'tags' set to
./tags.
- Execute taglist() on a tag that you know exists, something like:
:echo taglist('main')
- Now, cd into the other directory, and run the same command. You will
see that the tags are reported from the other directory.
- Change 'tags' to the absolute path to the second directory and run the
echo command again. You will still observe that taglist() is using the
previous tags file.
Can anyone confirm that they can reproduce this?
--
Thanks,
Hari
__
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
Re: Single-File Vim?
On Sat, 23 Sep 2006 at 3:38am, A.J.Mechelynck wrote: Hari Krishna Dara wrote: On Sat, 23 Sep 2006 at 1:46am, A.J.Mechelynck wrote: Hari Krishna Dara wrote: On Fri, 22 Sep 2006 at 4:05pm, Dmitriy Yamkovoy wrote: Hi all, Is there a binary compiled for Windows which allows me to run Vim without any of the runtime files? Long story short, I want something I can keep online or on a USB key and just copy to the desktop of any computer I sit at. Thanks, -Dmitriy I think Vim, when behaving as plain Vi, doesn't require any of the runtime files. E.g., try starting vim with -u NONE option, and run :scripts command, you will see that nothing is loaded. The runtime directory is not essential for using Vim. indeed, but then you will get - no help (doc/) - no Vim tutor (tutor/) - no syntax highlighting and no colorschemes (syntax/, colors/) - no filetype detection, no filetype plugins and no filetype indenting (filetype.vim, ftplugin/, indent/) - no keymaps (keymap/) - no non-English messages (lang/) - no menus (not even English menus) (menu.vim) - no spell checking (spell/) - no matchit matching (macros/matchit.vim) - no directory browsing (plugin/netrwPlugin.vim etc.) - no editing of remote files (plugin/netrwPlugin.vim etc.) - no editing of zipfiles, tarballs, etc. (plugin/gzip.vim, plugin/tarPlugin.vim, plugin/zipPlugin.vim) - no conversion to HTML (syntax/2html.vim) - no :options command (optwin.vim) - no vimrc_example.vim (vimrc_example.vim) etc., in other words, you would lose most of the things which, IMHO, make Vim great. First of all, I presumed that that is what OP wanted. Secondly, it is still several magnitudes better than plain Vi :) For the sake of argument, glancing through your list again I find none of them to be essential. The only feature out of the list that I use most is the matchit, the rest, I don't either (regularly) use or need. Not even the help? Then you've got a better (and more encyclopaedic) memory than mine. Sorry, that was a mistake. Help is essential for all the newer features and finding options etc. -- Thanks, Hari In fact most of these features didn't even exist in older Vim versions (which was still a lot better than Vi). I don't remember Vim versions older than 6.1 but I would expect them to have had a help system. PS: I don't need lang, but I would imagine it to be essential for someone needing a non-English language. When typing Russian or Arabic I would also need keymaps, except that I'm using my own keymaps, in $VIM/vimfiles/keymap or ~/vimfiles/keymap. I also use syntax colouring whenever available. Best regards, Tony. __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Re: copy paste file names from windows explorer
On Sat, 23 Sep 2006 at 4:02am, A.J.Mechelynck wrote: Hari Krishna Dara wrote: On Sat, 23 Sep 2006 at 12:49am, Yakov Lerner wrote: On 9/23/06, Hari Krishna Dara [EMAIL PROTECTED] wrote: I am wondering if it is possible to copy a file in the windows explorer (MS windows) and then access the filename(s) from vim/gvim. I know there are workarounds like dnd and sendto powertoy to send the filename to clipboard, but they are not that convenience, as they either require using the mouse or you need to use several key strokes. It is easy to add SendTo items to file explorer. I think I had a trick that added a SendTo item and when you selected it, it puts filename to the clipboard. But I forgot how exactly I did it, and (2) it does require mouse, although yuo can do it with keyborad shortcuts like Shift-F10 ... I'm not using windows anymore, forgot it. I was also using the Rename trick: choose rename file in explorer, press Ctrl-C, and you have filename in the clipboard. Yakov The SendTo works, I currently have it, but it will just open a new instance. If you use the Vim installer, it creates Open With context menu entries which are better, as you can open with existing windows. However, this is not what I want, and I realize I am not clear about one thing here. I don't want to open the file, I just want to get the filename at the command-line (or insert the filename into the current buffer, say as a string constant). The reason I mentioned dnd is if you start the command mode, and then dnd a file, Vim nicely inserts its filename instead of actually loading the file. I want the same functionality without having to do dnd or open the file first. The best I can think of is if Vim can understand this format, and extract filename(s) it will be very useful (at least for me). I use the rename trick often, but this will not get the entire path into the clipboard, just the name. You can get the full path-and-filename (at least in XP) from RightClick - Properties - General - Location. Select that path by dragging the mouse pointer over it, then Ctrl-C copies it to the clipboard. Then paste it into Vim with +p or similar. Best regards, Tony. It is much easier to use the SendTo Clipboard PowerToy than this. However, nothing will compare to just pressing ^C and retrieving the name in Vim (i.e, if it is possible). It will also make it possible to copy multiple files and retrieve their names in Vim. -- Thanks, Hari __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
copy paste file names from windows explorer
I am wondering if it is possible to copy a file in the windows explorer (MS windows) and then access the filename(s) from vim/gvim. I know there are workarounds like dnd and sendto powertoy to send the filename to clipboard, but they are not that convenience, as they either require using the mouse or you need to use several key strokes. -- Thanks, Hari __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Re: Single-File Vim?
On Fri, 22 Sep 2006 at 4:05pm, Dmitriy Yamkovoy wrote: Hi all, Is there a binary compiled for Windows which allows me to run Vim without any of the runtime files? Long story short, I want something I can keep online or on a USB key and just copy to the desktop of any computer I sit at. Thanks, -Dmitriy I think Vim, when behaving as plain Vi, doesn't require any of the runtime files. E.g., try starting vim with -u NONE option, and run :scripts command, you will see that nothing is loaded. The runtime directory is not essential for using Vim. -- HTH, Hari __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Re: copy paste file names from windows explorer
On Sat, 23 Sep 2006 at 12:49am, Yakov Lerner wrote: On 9/23/06, Hari Krishna Dara [EMAIL PROTECTED] wrote: I am wondering if it is possible to copy a file in the windows explorer (MS windows) and then access the filename(s) from vim/gvim. I know there are workarounds like dnd and sendto powertoy to send the filename to clipboard, but they are not that convenience, as they either require using the mouse or you need to use several key strokes. It is easy to add SendTo items to file explorer. I think I had a trick that added a SendTo item and when you selected it, it puts filename to the clipboard. But I forgot how exactly I did it, and (2) it does require mouse, although yuo can do it with keyborad shortcuts like Shift-F10 ... I'm not using windows anymore, forgot it. I was also using the Rename trick: choose rename file in explorer, press Ctrl-C, and you have filename in the clipboard. Yakov The SendTo works, I currently have it, but it will just open a new instance. If you use the Vim installer, it creates Open With context menu entries which are better, as you can open with existing windows. However, this is not what I want, and I realize I am not clear about one thing here. I don't want to open the file, I just want to get the filename at the command-line (or insert the filename into the current buffer, say as a string constant). The reason I mentioned dnd is if you start the command mode, and then dnd a file, Vim nicely inserts its filename instead of actually loading the file. I want the same functionality without having to do dnd or open the file first. The best I can think of is if Vim can understand this format, and extract filename(s) it will be very useful (at least for me). I use the rename trick often, but this will not get the entire path into the clipboard, just the name. -- Thanks, Hari __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Re: Single-File Vim?
On Sat, 23 Sep 2006 at 1:46am, A.J.Mechelynck wrote: Hari Krishna Dara wrote: On Fri, 22 Sep 2006 at 4:05pm, Dmitriy Yamkovoy wrote: Hi all, Is there a binary compiled for Windows which allows me to run Vim without any of the runtime files? Long story short, I want something I can keep online or on a USB key and just copy to the desktop of any computer I sit at. Thanks, -Dmitriy I think Vim, when behaving as plain Vi, doesn't require any of the runtime files. E.g., try starting vim with -u NONE option, and run :scripts command, you will see that nothing is loaded. The runtime directory is not essential for using Vim. indeed, but then you will get - no help (doc/) - no Vim tutor (tutor/) - no syntax highlighting and no colorschemes (syntax/, colors/) - no filetype detection, no filetype plugins and no filetype indenting (filetype.vim, ftplugin/, indent/) - no keymaps (keymap/) - no non-English messages (lang/) - no menus (not even English menus) (menu.vim) - no spell checking (spell/) - no matchit matching (macros/matchit.vim) - no directory browsing (plugin/netrwPlugin.vim etc.) - no editing of remote files (plugin/netrwPlugin.vim etc.) - no editing of zipfiles, tarballs, etc. (plugin/gzip.vim, plugin/tarPlugin.vim, plugin/zipPlugin.vim) - no conversion to HTML (syntax/2html.vim) - no :options command (optwin.vim) - no vimrc_example.vim (vimrc_example.vim) etc., in other words, you would lose most of the things which, IMHO, make Vim great. First of all, I presumed that that is what OP wanted. Secondly, it is still several magnitudes better than plain Vi :) For the sake of argument, glancing through your list again I find none of them to be essential. The only feature out of the list that I use most is the matchit, the rest, I don't either (regularly) use or need. In fact most of these features didn't even exist in older Vim versions (which was still a lot better than Vi). PS: I don't need lang, but I would imagine it to be essential for someone needing a non-English language. -- Thanks, Hari __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Re: sharing keyboard/mouse (was: Paragraph formatting options)
On Wed, 6 Sep 2006 at 7:27pm, Gary Johnson wrote: On 2006-08-27, Jim Tittsler [EMAIL PROTECTED] wrote: On Aug 26, 2006, at 18:09, Gary Johnson wrote: Pretty well. The monitors have dual inputs, so I can switch them easily between the two PCs. I don't have a way to switch a keyboard and mouse, though, so I have to shuffle the two keyboards and mice around when I want to use one machine or the other. That, plus not being able to copy-and-paste between the two [...] Have you tried Synergy? It allows you to share mouse/keyboard (and even clipboards) between machines. You will still have to hit the video selection buttons if you want to have both monitors on a single machine at once, but it solves the keyboard/mouse problem.. http://synergy2.sourceforge.net/ I've been waiting for a little free time to try this and finally found some. This is fantastic! It was really easy to install, too. The mouse and keyboard switch smoothly between the Linux and Windows boxes. I don't have copy-and-paste working yet, and once the Windows (client) machine is locked, Ctrl-Alt-Del from the Linux server's keyboard doesn't work, but I'll try working these out tomorrow. Thank you so much for suggesting this. Regards, Gary Thanks to this thread, I found good use for this software. I have been using it for past 3 days now and it works great. With the combination of hotkeys, I am able quickly switch between the screens. In the absence of this software, I would have used MS remote desktop, or KVM switch, but it is not the best use of the screens. Regarding the problem with Ctrl-Alt-Del not working on windows machine, I find that Ctrl-Alt-Break works instead, but I have the server also on windows, so YMMV. -- Thanks, Hari __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Re: :s/pattern Undocumented feature?
On Wed, 20 Sep 2006 at 1:08pm, Tim Chase wrote: I hadn't seen a reply to this fly by, so I thought I'd let you know it wasn't entirely ignored :) It appears that :s/pattern produces the same result as :s/pattern//. I couldn't find that behavior in the docs. A hidden feature? (Or was I just not creative enough using helpgrep?) I'm not sure I've seen it anywhere in the docs, but I've noticed the same behavior not only in ex/vi/vim, but also in ed. I was originally hesitant to use it, not sure whether it was unintended and if it would be there from version to version. However, after finding it consistent from version 5.x of vim forward, in classic vi, as well as ed, I presume it's an undocumented feature, and have begun using it when I have the need. I scoured through the help, looking in a multitude of places I deemed sensible, and couldn't find anything documented either. -tim I found this accidentally too and mostly use it for removing extra carriage-returns, using :%s/^M (where ^M is a literal Ctrl+M). -- Hari __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Re: Hiding lines
On Mon, 18 Sep 2006 at 8:01pm, Meino Christian Cramer wrote: Tim's :foldd and :foldo suggestions are actually very good in deed (didn't know about them), especially with the help of tools to create folds and operate commands on them. I would like to suggest you take a look at my foldutil.vim (http://www.vim.org/script.php?script_id=158). The benefit for you is that you can execute a single command to create folds that include/exclude all the lines that are matching or not-matching your specified pattern. You can then use :foldo or :foldd commands to issue commands on them. Also configure the 'foldopen' setting such that the folds will not be automatically opened by Vim when you move cursor around. I think, setting an empty value will help keep them closed as much as possible. You might also be interested in my multiselect.vim plugin (http://www.vim.org/script.php?script_id=953). It provides commands that are similar in nature to :foldo and :foldd to restrict normal mode and ex mode commands to selected regions. You can also use mouse to create selections. Hi, I have downloaded your script and genutils but got some problems... It displays: Folds created: 0 line 75: E117: Unknown function: RestoreHardPosition There is another message, which appears for a very short time -- too short for me to read it. What did I wrong here ? Keep hacking! mcc Looks like I haven't uploaded the one which uses the autoload version of genutils yet. I will update it soon, but meanwhile please try the below version: http://haridara.googlepages.com/foldutil.vim -- Thanks, Hari __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Re: Hiding lines
On Sun, 17 Sep 2006 at 9:03pm, Yakov Lerner wrote: On 9/17/06, Meino Christian Cramer [EMAIL PROTECTED] wrote: Hi, a few years ago I had to edit text files on a big iron (IBM) and a OS called TCO or such. The editor was [CENSORED] but there was one feature I miss since then: One could hide lines matching or !matching a certain pattern. Any further edit actions were only executed with the visible lines as target. Regardless what you were doing -- only the visible lines were affected. You had to give the unhide command explicitely to return to full text mode. Tim gave you the solution (:foldd). But I think there is one small problem with operating on non-folded lines; not with Tim's solution but with folding in general. Namely, you cannot fold single line. That is not true, you can have one line folded, however the default value of 'foldminlines' is 1, which means single-line folds are never shown as closed. You can however set this to 0. -- HTH, Hari So if you want to protect separate, single-standing lines from :folddo, you cannot. On the other hand, there is not limit on number of lines *between* folds. You can perfectly have 1 line between folds. But you cannot have 1 line *in* the fold. It follows that there's certain asymmetry between operating on unfolded lines vs operating on folded lines. Yakov __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Re: Hiding lines
On Sun, 17 Sep 2006 at 7:17pm, Meino Christian Cramer wrote: From: Tim Chase [EMAIL PROTECTED] Subject: Re: Hiding lines Date: Sun, 17 Sep 2006 11:15:13 -0500 One could hide lines matching or !matching a certain pattern. Any further edit actions were only executed with the visible lines as target. Regardless what you were doing -- only the visible lines were affected. You had to give the unhide command explicitely to return to full text mode. There is a script snipped in the VimTips (#77) which does something like this, but the hidden lines are not protected or really invisible until unhide... Is there a way to mimic this feature with vim in any way ? Well, while it sounds like you may have already uncovered folding (which will collapse/hide a bunch of lines into one), but as you describe, it doesn't really protect those lines. However, there are some things you can do do make them a little more protected. If you're doing :s commands (or other Ex commands), you can have them operate only over things that aren't currently folded away by modifying your Ex statement to be: :foldd s/foo/bar/g You can read all about folding at :help fold.txt wherein you'll find :help folddoopen :help folddoclosed which allow you to perform operations over sections of the file that are/aren't folded. You don't really describe what protected means...so perhaps if there are particular things that stymie you, you can mention them and perhaps a solution can be found for the particular problems. If you just want to extract certain lines, you can make use of a :g command, something like :let @a='' :g/pattern/y A will gather all the lines matching pattern into the a register. This can be dumped in another buffer if needed. Or, I often find myself doing something like :g/pattern/# which will show me all the line numbers in the current file for lines matching pattern (after which I can just jump to that line by typing the line-number followed by G). Just a couple ideas... -tim Hi Tim, thank you for your explanations ! :O) With protected I mean the effect of doing as follows (but I mean the result only ... not the way which leads to it...) There is a text with some lines containing the word gold. Those lines should never be changed/edited. Therefore I will do a :g/gold/d Then I will do all commands, mistakes or whatever, which I will do -- all gold lines will not be affected. After all that I will do a undo delete of all lines containing 'gold' -- and that's it. In reality an undo delete all lines containing /pattern/ is not pratical, impossible, irritationg or whatelse. This is only as an example for being protected. An Unix chmod a-w on all lines matching /pattern/ cames a little closer to it -- unless you are root, hehehehe But in the last example those lines were not hidden. Examples are only ...examples, therefore... Hope my german English is english enough... ;) Keep hacking! mcc Tim's :foldd and :foldo suggestions are actually very good in deed (didn't know about them), especially with the help of tools to create folds and operate commands on them. I would like to suggest you take a look at my foldutil.vim (http://www.vim.org/script.php?script_id=158). The benefit for you is that you can execute a single command to create folds that include/exclude all the lines that are matching or not-matching your specified pattern. You can then use :foldo or :foldd commands to issue commands on them. Also configure the 'foldopen' setting such that the folds will not be automatically opened by Vim when you move cursor around. I think, setting an empty value will help keep them closed as much as possible. You might also be interested in my multiselect.vim plugin (http://www.vim.org/script.php?script_id=953). It provides commands that are similar in nature to :foldo and :foldd to restrict normal mode and ex mode commands to selected regions. You can also use mouse to create selections. -- HTH, Hari __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Re: Patch 7.0.096
On Tue, 12 Sep 2006 at 1:56pm, A.J.Mechelynck wrote:
Hari Krishna Dara wrote:
[...]
Yes, that is what I am doing. Is fnamemodify() an expensive operation
involving OS calls?
From the description of what it does, fnamemodify() _seems_ to involve
only string manipulation, possibly checking $HOME and/or the current
window's current directory depending on the {mods} argument. There may
be one OS call on Unix or VMS if ~user/ (not just ~ which is $HOME) is
used in conjunction with :p.
I haven't checked the C code however.
Best regards,
Tony.
That is what I was hoping. At least for simple modifications not
involving special character expansion, it is probably simple string
manipuations and will not be expensive.
--
Thanks,
Hari
__
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
Re: Patch 7.0.096
On Mon, 11 Sep 2006 at 6:20pm, Bram Moolenaar wrote: Hari Krishna Dara wrote: On Sun, 10 Sep 2006 at 1:56pm, Bram Moolenaar wrote: Patch 7.0.096 Problem:taglist() returns the filename relative to the tags file, while the directory of the tags file is unknown. (Hari Krishna Dara) Solution: Expand the file name. (Yegappan Lakshmanan) Files:src/tag.c I applied the patch and tested that it works in my scenario, thank you. However, I see that the name is expanded only when the tags file is not in the current directory, which means the results can have a mixture of both absolute and relative names (if they are coming from different tag files in different directories). this could create some weird issues with looking up tags in one window and opening the file in another window and if they have differe lcd. This also means, the results can't be cached and used later on, as the current directory could change. Is this intentional? One observation I made is that (on windows) the expanded path doesn't include the drive letter unless the current directory and the directory of the tags files are on different drives. I don't know if this is how Vim normally behaves, but this means, they are not really absolute paths, but relative to the current drive. I could always explicitly do a fnamemodify() on each of the files, so it is not a big deal, but I am wondering how efficient fnamemodify() is, if it involves simple string manipulation or OS calls. Normally relative file names work just fine. If you need a full path you can use fnamemodify() in a map() to change it. Yes, that is what I am doing. Is fnamemodify() an expensive operation involving OS calls? -- Thanks, Hari There was also a request from me some time back to allow a limit argument to the taglist() function such that its response can be improved in scenarios involving large number of matches. Is there a plan to provide a 7.0 patch for this feature? Not soon. __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Re: Patch 7.0.096
On Sun, 10 Sep 2006 at 1:56pm, Bram Moolenaar wrote:
Patch 7.0.096
Problem:taglist() returns the filename relative to the tags file, while
the directory of the tags file is unknown. (Hari Krishna Dara)
Solution: Expand the file name. (Yegappan Lakshmanan)
Files:src/tag.c
I applied the patch and tested that it works in my scenario, thank you.
However, I see that the name is expanded only when the tags file is not
in the current directory, which means the results can have a mixture of
both absolute and relative names (if they are coming from different tag
files in different directories). this could create some weird issues
with looking up tags in one window and opening the file in another
window and if they have differe lcd. This also means, the results can't
be cached and used later on, as the current directory could change. Is
this intentional?
One observation I made is that (on windows) the expanded path doesn't
include the drive letter unless the current directory and the directory
of the tags files are on different drives. I don't know if this is how
Vim normally behaves, but this means, they are not really absolute
paths, but relative to the current drive.
I could always explicitly do a fnamemodify() on each of the files, so it
is not a big deal, but I am wondering how efficient fnamemodify() is, if
it involves simple string manipulation or OS calls.
There was also a request from me some time back to allow a limit
argument to the taglist() function such that its response can be
improved in scenarios involving large number of matches. Is there a plan
to provide a 7.0 patch for this feature?
--
Thank you,
Hari
*** ../vim-7.0.095/src/tag.c Thu Apr 27 23:40:34 2006
--- src/tag.c Sun Sep 10 13:42:41 2006
***
*** 3787,3792
--- 3787,3793
{
int num_matches, i, ret;
char_u **matches, *p;
+ char_u *full_fname;
dict_T *dict;
tagptrs_T tp;
longis_static;
***
*** 3809,3823
if (list_append_dict(list, dict) == FAIL)
ret = FAIL;
if (add_tag_field(dict, name, tp.tagname, tp.tagname_end) == FAIL
! || add_tag_field(dict, filename, tp.fname,
! tp.fname_end) == FAIL
|| add_tag_field(dict, cmd, tp.command,
tp.command_end) == FAIL
|| add_tag_field(dict, kind, tp.tagkind,
tp.tagkind_end) == FAIL
|| dict_add_nr_str(dict, static, is_static, NULL) == FAIL)
ret = FAIL;
if (tp.command_end != NULL)
{
--- 3810,3827
if (list_append_dict(list, dict) == FAIL)
ret = FAIL;
+ full_fname = tag_full_fname(tp);
if (add_tag_field(dict, name, tp.tagname, tp.tagname_end) == FAIL
! || add_tag_field(dict, filename, full_fname,
! NULL) == FAIL
|| add_tag_field(dict, cmd, tp.command,
tp.command_end) == FAIL
|| add_tag_field(dict, kind, tp.tagkind,
tp.tagkind_end) == FAIL
|| dict_add_nr_str(dict, static, is_static, NULL) == FAIL)
ret = FAIL;
+
+ vim_free(full_fname);
if (tp.command_end != NULL)
{
*** ../vim-7.0.095/src/version.c Sun Sep 10 13:22:26 2006
--- src/version.c Sun Sep 10 13:52:01 2006
***
*** 668,669
--- 668,671
{ /* Add new patch number below this line */
+ /**/
+ 96,
/**/
__
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
Re: Patch 7.0.098
On Sun, 10 Sep 2006 at 9:07pm, Bram Moolenaar wrote:
Patch 7.0.098
Problem:Redirecting command output in a cmdline completion function
doesn't work. (Hari Krishna Dara)
Solution: Enable redirection when redirection is started.
Files:src/ex_docmd.c, src/ex_getln.c
The patch works great, thank you.
--
Thanks,
Hari
*** ../vim-7.0.097/src/ex_docmd.c Sun Sep 10 15:50:32 2006
--- src/ex_docmd.cSun Sep 10 20:59:46 2006
***
*** 8422,8427
--- 8422,8436
else
EMSG2(_(e_invarg2), eap-arg);
}
+
+ /* Make sure redirection is not off. Can happen for cmdline completion
+ * that indirectly invokes a command to catch its output. */
+ if (redir_fd != NULL
+ #ifdef FEAT_EVAL
+ || redir_reg || redir_vname
+ #endif
+ )
+ redir_off = FALSE;
}
/*
*** ../vim-7.0.097/src/ex_getln.c Sat Sep 2 17:58:36 2006
--- src/ex_getln.cSun Sep 10 21:04:57 2006
***
*** 324,329
--- 324,332
*/
for (;;)
{
+ redir_off = TRUE; /* Don't redirect the typed command.
+Repeated, because a :redir inside
+completion may switch it on. */
#ifdef USE_ON_FLY_SCROLL
dont_scroll = FALSE;/* allow scrolling here */
#endif
*** ../vim-7.0.097/src/version.c Sun Sep 10 15:50:32 2006
--- src/version.c Sun Sep 10 20:58:17 2006
***
*** 668,669
--- 668,671
{ /* Add new patch number below this line */
+ /**/
+ 98,
/**/
__
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
Re: Patch 7.0.082
On Tue, 5 Sep 2006 at 5:19pm, Hari Krishna Dara wrote: On Mon, 4 Sep 2006 at 9:50pm, Bram Moolenaar wrote: Hari Krishna Dara wrote: I wrote: Patch 7.0.082 Problem:Calling a function that waits for input may cause List and Dictionary arguments to be freed by the garbage collector. Solution: Keep a list of all arguments to internal functions. Files:src/eval.c I vaguely recall that some people were having unreproducible crashes when using input() or inputlist(). This patch should solve that. What happened was that the garbage collector didn't see the arguments to internal functions, thus would free List and Dict arguments that are still in use. That leads to a double free later. The garbage collector only does it's work when the user doesn't type for a little while, that made it unpredictable when it would happen. Can this happen during the debug session also? Like, when you do echo on lists? I am seeing that while debugging scripts that use Lists for sometime, Vim almost always crashes. Sometimes, I also start seeing internal errors related to List access (sorry, I didn't notedown the numbers) before it crashes. Yes, this could also happen in debug mode. If you don't type something for 'updatetime' seconds the garbage collector is invoked. But the fix is only for when you pass a List or Dictionary to an internal function. User functions were already OK. Hmm, now that I think of it you could get problems with a command like this: :echo [1, 2, 3, ..., 2000] If you get the more prompt the garbage collector might delete the list before it's completely echoed. I'll look into that. This is probably what I was doing during the debugging. I will try to notice if an :echo on a list in a long running debug session is what is causing the crash. I hit the error while debugging again. I did an echo on a list and did a quit after a few seconds. Instead of debug session aborting immediately, I got this below error: E685: Internal error: clear_tv() And it continued executing after that with several errors all seem to be because of corrupted list. The list that I echoed is no longer treated as a List type and function calls such as sort() that I had after that resulted in errors. A subsequent quit worked and aborted the debug session. If I had continued executing debug commands, I am pretty sure that it would have resulted in a Vim crash. -- Thanks, Hari __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Re: Patch 7.0.082
On Fri, 8 Sep 2006 at 11:11pm, Bram Moolenaar wrote: Hari Krishna Dara wrote: Hmm, now that I think of it you could get problems with a command like this: :echo [1, 2, 3, ..., 2000] If you get the more prompt the garbage collector might delete the list before it's completely echoed. I'll look into that. This is probably what I was doing during the debugging. I will try to notice if an :echo on a list in a long running debug session is what is causing the crash. I hit the error while debugging again. I did an echo on a list and did a quit after a few seconds. Instead of debug session aborting immediately, I got this below error: E685: Internal error: clear_tv() And it continued executing after that with several errors all seem to be because of corrupted list. The list that I echoed is no longer treated as a List type and function calls such as sort() that I had after that resulted in errors. A subsequent quit worked and aborted the debug session. If I had continued executing debug commands, I am pretty sure that it would have resulted in a Vim crash. Hopefully this happened before applying patch 7.0.084 !? Yes, sorry I intend to mention that and forgot. But I thought you are still going to look at more cases that might cause the bug that you were originally trying to patch. Do you think this patch already covers the cases that might arise during debugging as well? -- Thanks, Hari __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Re: glob() and |file-pattern|
On Fri, 8 Sep 2006 at 9:24am, Bram Moolenaar wrote:
Hari Krishna Dara wrote:
I asked a couple of questions below, but I solved the last one
('ignorecse') by implementing a filter() myself, so it is not an issue.
The other question is on why {} works on win32 GVIM (7.0 version
compiled by you) is not important, though a confirmation that yes, that
is supposed to work will be great. It can then also be documented to
avoid confurion in the future (as this works on posix platforms also, it
might be important for someone to know what characters are special and
need escaped in some situations).
I don't know why {} works in Win32 Gvim. I don't really have time to
figure it out. Perhaps someone else can dig into the code.
I have another question related to this. According to the help on
|file-pattern|, there is no significance for ^ and $ characters, but
I have been using them with bufnr() to be able to do an exact match on
filenames. I have a suspicion that they were suggested by you when I had
a question on how to restrict bufnr() to do this exact match (probably
about 5 years ago). The function is defined like this:
function! s:FindBufferForName(fileName)
let fileName = genutils#Escape(a:fileName, '[?,{')
let _isf = isfname
try
set isfname-=\
set isfname-=[
let i = bufnr('^' . fileName . '$')
finally
let isfname = _isf
endtry
return i
endfunction
It has been working great, but since I am using what seem like
undocumented features, I just wanted your perusal on my usage, as well
as getting it documented such that this will not be broken in a future
change.
This is documented: A full match is preferred over a partial match.
Internally the ^ and $ are added to find a match, only if this fails
they are left out. Thus if you _only_ want to find a full match you
should add the ^ and $.
It will be helpful to add what you just said to the help on |bufname()|.
It does say a full match is preferred, but a new user has no way to
guess how to force a full match and that ^ and $ can be used in this
case (espceially that a |file-pattern| is expected and these are not
special in a |file-pattern|). Is it that ^ and $ can be used anywhere a
|file-pattern| is expected or only for bufname() and related functions
(like bufnr())?
--
Thanks,
Hari
__
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
Re: parsing error with ?: usage
On Fri, 8 Sep 2006 at 6:08am, A.J.Mechelynck wrote: Hari Krishna Dara wrote: [...] I know that this is possible, but as I said previously, it is a force of habit to compact as much as possible in some situations, though I normally prefer using whitespace and parenthesis to improve clarity. Also, the reason I mentioned using spaces is not really as a workaround but to show the subtle difference it makes to the parser. Once you use parenthesis, there is nothing really ambiguous about it. I have a suspcion that using parenthesis also didn't solve the issue in one of the cases (I remember it was calling script-local functions as part of map() expression). I have to try to reproduce it though, I don't remember it now. As Tim said, a liitle bit of paranoia is healthy here: If you write if condition_1 || condition_2 condition_3 the parser will interpret it in a well-defined way, determined by the syntax of the language, but when you come back 2 years hence, will it still be clear to you? Some languages mandate left-to-right order in this case, which results in the equivalent of if (condition_1 || condition_2) condition_3 In others, and takes precedence over or, which results in if condition_1 || (condition_2 condition_3) With parentheses, precedence rules are unimportant and an error in logic won't be overlooked even if you mistook a left-to-right language for an and-before-or language or vice-versa. similarly for all other possible ambiguities: remember, (x?a:1) is a valid expression if you have a variable named a. You may even have an argument named a:a so what about (x?a:a:a) if you have both a and a:a ? I repeat: don't trust priorities and use parentheses. And if you caught a bad habit, reeducate yourself. Best regards, Tony. We are deviating from my original point. It is not that I don't know what is more cleaner way of writing code that I asked this question. I just want to write more compact code sometimes, and if that doesn't work in this case, I will avoid, there is no convincing required. I don't write this kind of code as a rule and it certainly is not my regular habbit. May be my use of word habbit is wrong here, but you didn't really have to give all the explanation. I am an experienced programmer (and I don't write just Vim scripts), and if you look at my Vim scripts, you will find that I write them very seriously (and passionately), following my own coding standards, tediously splitting the long lines for readability and doing all that you are suggesting here. My intention was to report a problem I found, and sometimes minor symptoms can lead to the discovery of major issues, so I don't generally ignore any bugs. I also wanted to know (for educational purpose) if it can even be parsed without ambiguity (ie., if the bug can even be fixed) to which I think Bram answered NO, and that is the answer I was looking for. -- Thanks, Hari __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Re: Thank you for Vim7 scripting improvements
On Sun, 3 Sep 2006 at 7:09pm, A.J.Mechelynck wrote: Hari Krishna Dara wrote: On Sun, 3 Sep 2006 at 2:23pm, Bram Moolenaar wrote: Yakov Lerner wrote: On 9/3/06, Bram Moolenaar [EMAIL PROTECTED] wrote: I still miss pre and post increment and decrement operators (avoids a separate :let command by itself), You mean, as in: :let linenr = a++ I don't know how difficult this is to implement, and if there are any conflicts in the syntax. And then probably :let linenr ++ , too ? That looks weird. You can do it already with: :let linenr += 1 Right, I am not talking about this case, but inside expressions, like in: return val++; instead of saying: let oldval = val let val += 1 return oldval or in: let ar[i] = ar[i++] Expressions with side-effects (or value-returning assignments, depending on point of view) are a head-breaker in C. I hate them. Too often I won't see the error when some dumbass (me included) writes a++ where ++a should have been, or vice-versa. I think your opinions are subjective. I personally never got confused by the use of these operators and find them to have very clean expression. let val += 1 return (val - 1) is much clearer for someone who doesn't use C day-in day-out. At least I find this more confusing than using a post-increment operator. You are expressing a logic that is distributed in multiple lines, and to me that definitely is less expressive than simply returning val++. Again, this is very subjective, and so I am not surprised that you find it differently. Vim doesn't allow if (x = y) which is perfectly legal in C, where it means set x equal to y, and return TRUE if the value is nonzero and not as a novice would expect, return TRUE if x equals y. I agree that this constuct is heavily subject to errors and most post-C/C++ languages boast generating a compiler error to prevent unexpected bugs, but I didn't get what your point here is w.r.t. to the subject of this thread. Best regards, Tony. -- Thanks, Hari __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Re: vimdiff functionality
On Thu, 7 Sep 2006 at 11:55am, Lev Lvovsky wrote: I'm using a version control app called darcs, which allows me to view a diff hunk by hunk, to pick and choose the changes that I want to apply. darcs aside, is there an in-depth howto for editing patches and such? Specifically, I'm looking for a way to split single hunks into two hunks, write the diff, and then feed it into darcs. My co-worker uses emacs, which seems to come with a pretty complete patch editing command set - it's likely my inexperience that's causing me to not find much of that same functionality in vim, so any pointers would be appreciated... thanks, -lev It is not clear from your email what you mean by splitting hunks, may be giving some examples will help. Vim has the :diffpatch command though I never used it. If I have diff, I often just execute the external patch command as: :!patch -i - % and then copy paste the diff in to the window. If you can get the vimdiff to open up with two versions, you can easily use the :diffget and :diffput commands to selectively move the hunks that you are interested. I have no idea on how darcs works and if there is a Vim plugin to integrate it, but I maintain a plugin for perforce and have commands to open vimdiff on multiple versions (including the local ones) and use it to patch (or revert) only selective hunks all the time. -- HTH, Hari __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
parsing error with ?: usage
I have hit this thrice already, while using the ?: ternary operator, in some conditions, you are forced to put whitespace to separate the operator otherwise Vim gets confused. Here is something that fails: let direction = (a:0?a:1:1) I had this issue before calling script-local functions from the true or false condition. The workaround as I said for the above is: let direction = (a:0 ? a:1 :1) The problem is, sometimes I have a force of habit to skip the whitespace in some places when I want the code to be really compact/tight (especially when with map(), filter() or \=), and I will not notice the problem until sometime later when the code gets executed. If the code happened to execute with a :silent, you may have to do quite a bit of debugging to find this kind of errors. Is it possible for Vim to parse this unambiguously? The usage could be even worse, something like: let direction = (a:01?a:2:a:1) -- Thanks, Hari __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Re: glob() and |file-pattern|
Bram,
I asked a couple of questions below, but I solved the last one
('ignorecse') by implementing a filter() myself, so it is not an issue.
The other question is on why {} works on win32 GVIM (7.0 version
compiled by you) is not important, though a confirmation that yes, that
is supposed to work will be great. It can then also be documented to
avoid confurion in the future (as this works on posix platforms also, it
might be important for someone to know what characters are special and
need escaped in some situations).
I have another question related to this. According to the help on
|file-pattern|, there is no significance for ^ and $ characters, but
I have been using them with bufnr() to be able to do an exact match on
filenames. I have a suspicion that they were suggested by you when I had
a question on how to restrict bufnr() to do this exact match (probably
about 5 years ago). The function is defined like this:
function! s:FindBufferForName(fileName)
let fileName = genutils#Escape(a:fileName, '[?,{')
let _isf = isfname
try
set isfname-=\
set isfname-=[
let i = bufnr('^' . fileName . '$')
finally
let isfname = _isf
endtry
return i
endfunction
It has been working great, but since I am using what seem like
undocumented features, I just wanted your perusal on my usage, as well
as getting it documented such that this will not be broken in a future
change.
PS: Please note that Vim has otherwise no primitives to find an exact
match for buffers given its name, other than enumerating all the
buffers, so functionality of the above is very important for several of
my plugins (at least for me).
--
Thank you,
Hari
On Tue, 29 Aug 2006 at 1:31pm, Hari Krishna Dara wrote:
On Tue, 29 Aug 2006 at 10:06pm, Bram Moolenaar wrote:
Hari Krishna Dara wrote:
The help on glob() or globpath() don't indicate what type of
metacharacters are accepted, but there is a separate section called
|file-pattern| that describes the metacharacters used for filename
matching for autocommands. I don't know if these are applicable for
glob() and globpath() as well, but a lot of these don't seem to work
as
described. Is there a different section that I am missing to see, or
is
it completely left out? Are the metacharacters predictable, or
dependent
on the platform and environment? If so, is there a base set that
could
work on all?
The reason I am asking is that I would like to translate a
filename-pattern to a Vim regex-pattern such that I can highlight the
part of the filename that matched the filename-pattern, after getting
the results from glob() or globpath(), so I need to know all the
supported chars.
glob() should work as described at :help wildcard. There are
small differences depending on the system.
Thanks Bram. This covers ** as well, but doesn't mention most of the
other wildcards that are applicable for |file-pattern|, which makes
sense. I was however surprised to see {} working to group patterns and
, working to separate patterns with in them. Is this something extra
for windows and undocumented?
For Unix the {} things are detected and then expansion is done by the
shell. I don't see how {} things can work on MS-Windows. Perhaps you
compiled with Cygwin?
I have a win32 version:
VIM - Vi IMproved 7.0 (2006 May 7, compiled May 7 2006 16:23:43)
MS-Windows 32 bit GUI version with OLE support
Compiled by [EMAIL PROTECTED]
It is also strange that the [abc] wildcard
always matches as if 'ignorecase' is turned on. Is there a way to force
a 'noignorecase' on windows?
On MS-Windows case of file names is always ignored.
Is this because the underlying library function that glob() uses doesn't
care about the case? If this is in the control of Vim, it is useful to
support 'noignorecase' or something equivalent. Even though the
filesystem itself ignores the case, it still preserves it, and as a
user, most developers do care about the case (in fact, it is important
in most areas of Java/JSP world).
__
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
bug in taglist() and filename
When taglist() returns matches, each match is hash and the filename key gives the filename where the tag is expected to be found. This works as expected, but the problem is that the filename is returned as it is found in the tags file, which could be a relative path from the location of the tags file itself. If the current directory of Vim is not the same as the tags file itself, then there is no way to findout what the absolute path of the filename is. I just verified that the tag commands (such as :ts) converte them to absolute paths in this case. A workaround in this case would be to run taglist() multiple times once for each entry in the 'tags' such that you know to which directory the paths are relative. -- Thanks, Hari __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
