Re: VimWiki - released finally
On 6/5/07, Sebastian Menge [EMAIL PROTECTED] wrote: [cross-posted to vim, vim-dev, vim-announce, wikia-l] Hi all Finally I have imported all the vim tips from http://vim.org/tips to http://vim.wikia.com and set up a minimal infrastructure to keep things going. Not everything is perfect, but I think it is usable now. Thanks to all the support from [EMAIL PROTECTED] and especially to the very kind wikia community (#wikia on freenode and the mailing list, Greetings!). Some words on contribution: A good wiki depends on two main factors: Excellent content and a lively community. We have a lot of good content now, but to make it excellent we need You! If you ever posted a tip or a comment to the old tips database, please have a look at it on the wiki, and review the page. Every little bit helps! See you on the wiki, Sebastian. I am EXCITED! -- -fREW
Re: VimWiki - released finally
On 6/5/07, Sebastian Menge [EMAIL PROTECTED] wrote: [cross-posted to vim, vim-dev, vim-announce, wikia-l] Hi all Finally I have imported all the vim tips from http://vim.org/tips to http://vim.wikia.com and set up a minimal infrastructure to keep things going. Not everything is perfect, but I think it is usable now. Thanks to all the support from vim@vim.org and especially to the very kind wikia community (#wikia on freenode and the mailing list, Greetings!). Some words on contribution: A good wiki depends on two main factors: Excellent content and a lively community. We have a lot of good content now, but to make it excellent we need You! If you ever posted a tip or a comment to the old tips database, please have a look at it on the wiki, and review the page. Every little bit helps! See you on the wiki, Sebastian. I am EXCITED! -- -fREW
Re: ex editor
On 6/5/07, Tim Chase [EMAIL PROTECTED] wrote: I would dearly like to be able to replace ex by a more comfortable older version eg not wiping image of recent changes on screen on exit. I'm not 100% sure how to do this one. This is likely a terminal thing. Perhaps you can monkey with the settings as described in :help xterm-save-screen where it sounds like the NOTE 2 at the bottom of that section describes what you want: :set t_ti= t_te= I'm ambivalent about this option, as sometimes I want it, and sometimes I don't, and I don't think about it until I quit and find that it's not what I wanted. Some machines I use preserve the original screen (using the alternate screen for vim), and some don't. I've just learned to shrug that one off :) undo to undo just the last change by default - not all changes since start of session. Vim7's undo is mind-blowingly more powerful than any other software I've used (except maybe VCS software such as RCS/Subversion/Mercurial/etc). It shouldn't undo all changes since the start of the session (assuming by session, you mean since opening the file). Vim certainly allows you to return to the old-school way of doing things, as described at :help undo-two-ways and following section for how Vim treats undo blocks as well. etc Without more details on this etc, it's hard to point you in the right direction. However, this mailing list is a friendly place, so if you encounter more questions, feel free to ask them here and the list will try and help you out. I get accused of being the list's resident Ex junkie, so hopefully I can help. :) I'm likely one of the scant few who still wants Vim to support true open mode (:help :open). Not urgently, but there are times it would have been handy. Fortunately, I've got some older versions of vi that do support it for those scarse occasions I want it. -tim Is :help undo where we can get information on Vim7's undo? I remember reading about how it was all awesome and stuff, but I haven't gotten a chance to actually try to use it yet. -- -fREW
Re: vimlatex and mks
On 6/4/07, Sebastian Menge [EMAIL PROTECTED] wrote: Hey I have a problem with vimlatex and mks. To reproduce it: 1) create a simple tex file see attachment. 2) :mks! 3) quit vim 4) vim -S Session.vim You should see something like this (from a more complicated tex-file ...) --- Fehler beim Ausführen von /home/menge/.vim/ftplugin/latex-suite/folding.vim: Zeile 11: settings_preamble.tex 47L, 721C Fehler beim Ausführen von /home/menge/Diss/sketches/sketches.vim: Zeile 739: settings_preamble.tex 47L, 721C Zeile 885: E165: Kann nicht über die letzte Datei hinausgehen --- Hope there is someone around using vimlatex ... TIA, Sebastian. I can reproduce it, but it disappears before I can copy paste it. -- -fREW
Re: Multiple search highlights?
On 6/4/07, Ron Olson [EMAIL PROTECTED] wrote: Hi all- I just recently joined this list after using Vim for awhile, and vi since, gosh, 1990 on a Vax. I'm astounded how, over the years, vi (and now Vim) have served my needs pretty much perfectly; what other editor is available on everything, has every feature you could possibly want, and is fast. That said, there is a feature I do want, or maybe it's already there but I can't figure out how to do it: multiple highlights. What I mean by this is, typically I look for a string like foo in vim with /foo, and it highlights all occurrences in the file (standard behavior). What I need is to be able to search for something else (which I believe I could do by searching using a regex), but I would like that second thing to be in another color a la Google's search results (at least in dejanews). What I need, eventually, is an angry fruit salad of colors for all the search items I've entered. Is this currently doable, and if not, do you think it's possible to accomplish using a plugin? Thanks, Who doesn't want an angry fruit salad of colors? -- -fREW
Re: gvim 7 highlight search string
On 6/1/07, Tim Chase [EMAIL PROTECTED] wrote: In the old gvim, doing a search (/something) highlights all something in red. In gvim 7, it doesn't highlight all occurrences. Is there a way to turn this back on? It sounds like in the process, a vimrc (system-wide?) was changed. You don't mention your distro/OS, so it's hard to help there. However, in your $HOME/.vimrc (or _vimrc on Win32), you can simply add the line set hls to turn on highlighting your searches by default. If you just want to turn it on for a current session, you can use it as an Ex command: :set hls or toggle it with :set hls! Using this method, it's not preserved across runs of Vim though (which is what the vimrc is for). -tim If Brian is running Ubuntu that could have happened. When I mentioned on the list how updating changes default (to Ubuntu) behavior this was another symptom (I think.) -- -fREW
Re: OT: Vi in a browser...
On 6/1/07, Tim Chase [EMAIL PROTECTED] wrote: Speaking of which, is there any quicker way to visually select the entire file, analogous to ^A in other systems? I have to essentially do 1GVGctl-del to stick everything into the scratchpad/clipboard/whatever to dump it back into the item from whence it originally came, and that's just a pain. Well, not so much a pain as an annoying itch I can't quite reach. I was thinking something along the lines of %V but that obviously won't work. :) You're so close, it could bite you :) It looks like you're getting hung up on expecting the solution to need visual mode rather than just using Ex commands. I frequently use :%d or if I need it to go to the system clipboard, :%d* :%d+ I use these (and their yanking counterparts, :%y) so regularly that they're ingrained muscle-memory. Because the y/d Ex command takes any range, I also regularly use :.,$d to do just from my current line to the EOF, or :1,.d to pull from the first line through the current line. -tim Awesome. Tim is our ex friend. Or something? -- -fREW
Re: collapsing single lines of html tag attributes via plugin??
On 6/1/07, Charles E Campbell Jr [EMAIL PROTECTED] wrote: Howard Glynn wrote: snip I wondered whether there was a plugin somewhere that was able to abbreviate or partially hide the detail so i can see the overall structure more clearly. In essence I would like to collapse huge (single) lines of tags to something like a id=xyz href=/img ... - where implies I could expand if required. I'm sure it is probably possible to craft a plugin to do this, i just have some urgent deadlines right now ;) snip Hello! Sounds like Vince Negri's conceal patch to vim would come in handy for this. Vim's current folding is on a line-by-line basis; Negri's patch can also perform concealing in lines. You can get his patch at: http://vince.negri.googlepages.com/ Here's an example, although it may conceal more than what you've requested... if has(conceal) if conc == 0 let conc= 3 endif syn clear syn region htmlTag conceal start= end= endif So this will conceal anything between ... . One neat thing; even though I've selected conceal level 3, nonetheless, when your cursor is atop a line that line will *not* be concealed. So editing may proceed, as that's what Vim's for. A more comprehensive (but not html-related) example of concealing is available at my website: see AnsiEsc.vim. This plugin will conceal ansi escape codes and perform proper colorizing of the text based on the concealed ansi codes. Vince N has a tex.vim syntax using concealment, too, somewhere... BTW, folks -- if more people than H Glynn would want this -- let Bram know! He's under the impression that its not wanted very much, which is why I presume its not in vim 7.x. Vince's patch also supports ownsyntax. Read about it at his website. Regards, Chip Campbell I would use conceal if it were in standard vim. Definitely. -- -fREW
Re: No Previous Regular expression
On 5/31/07, Tim Johnson [EMAIL PROTECTED] wrote: On Wednesday 30 May 2007, David Nečas wrote: If you close and reopen Vim, the last search pattern is remembered -- or not -- in the viminfo file. (It is one of the registers.) The search history can also be saved. See :help 'viminfo'. Yes, search history is being saved. And since this is Ubuntu... .viminfo probably got owned by root and therefore it is not writable, as was discussed in the recent thread. That's a gotcha - still haven't got used to this 'sudo' thing - viminfo *was* owned by root, so all is good now. Thanks folks, I appreciate it. tim If this list had a FAQ, it would probably contain this issue and the large file issue (and maybe something about bottom posting :-P ) So you are certainly not alone. -- -fREW
Re: No Previous Regular expression
On 5/31/07, Tim Johnson [EMAIL PROTECTED] wrote: On Thursday 31 May 2007, fREW wrote: ... If this list had a FAQ, it would probably contain this issue and the large file issue (and maybe something about bottom posting :-P ) So you are certainly not alone. 1)What is the large file issue? (you can just point me to archives, if any) thanks tim I don't really know where to look for the archives. It's come up a lot recently. Basically if you have a big file make sure to set undolevels=0 and turn off syntax highlighting. Also turn of swap files I think. That's the main stuff. And when I say big files I mean multiple gigs. -- -fREW
Re: Is there a xml formatter?
Or just try gg=G after you had opened your xml file. 4) to reformat an existing file: gggqG What is the actual difference of these two commands? I usually use = for code and gq for text, so I presumed that one was for formatting and one was for 'linewidth'ing. -- -fREW
Re: Is there a xml formatter?
On 5/30/07, A.J.Mechelynck [EMAIL PROTECTED] wrote: fREW wrote: Or just try gg=G after you had opened your xml file. 4) to reformat an existing file: gggqG What is the actual difference of these two commands? I usually use = for code and gq for text, so I presumed that one was for formatting and one was for 'linewidth'ing. You may be right. For the exact differences, lookup :help = :help gq Best regards, Tony. -- GOD: That is your purpose Arthur ... the Quest for the Holy Grail ... Monty Python and the Holy Grail PYTHON (MONTY) PICTURES LTD For anyone who was wondering, they can be the same, but they can both be customized, and if they are NOT customized, it looks like gq will textwidthify and = will format for c. -- -fREW
Re: JSVI: Vi implemented in Javascript
On 5/30/07, Kevin Old [EMAIL PROTECTED] wrote: Not sure if everyone's seen this, but it's definitely cool and quite accurate. http://ajaxian.com/archives/jsvi-you-love-vi-you-love-javascript-now-you-have-both -- Kevin Old [EMAIL PROTECTED] Wow... That is brilliant. I kinda wish I were stuck with it, just because it's so ridiculous. -- -fREW
Re: Re[2]: mbox format archive?
On 5/29/07, Alan G Isaac [EMAIL PROTECTED] wrote: On Tue, 29 May 2007, A.J.Mechelynck apparently wrote: Hmm... This post of mine seems to be eliciting two kinds of reactions: Me too, me too and Don't, you fool, he may be a spammer harvesting addresses. I think I'll leave it on the backburner for a while, waiting for the situation to clarify. Comments, anyone? - Probability that this is a spammer request: approx 0. Old addresses aren't much use. Spammers aren't so polite. Etc. - To make it zero, see if he has ever posted to the list... - sed s/@[A-Za-z]\+/@xxx/g archivefile archivefile2send Cheers, Alan Isaac The interesting thing is that the guy who is in question of being a spammer is the same guy who asked for safeguards against that type of thing... -- -fREW
Re: mbox format archive?
On 5/29/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Ehehe never mind about this, I had no idea this would stir everyone up. I consider it fairly normal for list archives to be offered in mbox format (ex. Lua and Template Toolkit and 5 million others) and like to keep them around, since I can just drop them right into local folders in thunderbird for searching. Especially handy for offline, and for not having to rely on someone's frontend to search the archives for difficult to find things, that I know are buried someplace in the archive. Looking at the commands I can issue to the listmanager, looks like I can whip out something that will make me an archive so all good. thanks for your offer though AJ. A. I don't think you are a spammer/bot! :-) -- -fREW
Re: Why bottom-posting is prefered on Vim Mainling List?
On 5/29/07, Gene Kwiecinski [EMAIL PROTECTED] wrote: Uhhh, that's not my doing, as the text gets resplit/rewrapped somewhere else along the line. About the only thing I could do is manually split it shorter than the default (whatever that is) Reformatting the quoted blocks (gq} or visual+gq as you like best) while you're formatting your email works quite well. Uhh, I *do*. gqap, actually (iirr). (Learned that trick here, in fact.) That's what I mean by manually, vs letting the mailer itself autowrap. Thing is, if I don't know what's the default max-width of v.o's messages, being over by just 1 char will still do the long/short/long/short/... rewraps. Point being that it's not on this end where the rewrap gets done, but somewhere on the 'vim.org' side, either translating incoming email to whatever margins, etc., it prefers, else reformatting it somewhat when sending it back out to the list. I've had private/offline correspondence with quite many people on this list, have seen my own replies echoed back, and have yet to see this wrapping issue apply to any off-list items. Given that I'm stuck with LookOut here, I have to cp (^A^X from LO) to 'vim' (shift-ins), then :g/^ /s// :g/^./s// gqap(per paragraph, iirr) then cp it back to LO's draft before sending. Crude, but more or less effective. It may be a little bit on the expensive side, but it might be worth your while if you use Outlook at work to check out ViEmu [1]. The guy has it for Outlook, Word, Visual Studio (all flavors as far as I know), and some more. The Word and Outlook on come together, so it's really not that bad of a deal if you use both. [1]: http://www.viemu.com/ -- -fREW
Re: VimWiki - Page Titles
On 5/27/07, Sebastian Menge [EMAIL PROTECTED] wrote:
Hi
I have prepared a list with problematic page titles. Especially titles
with chars like [/#{}[]*] and the like are problematic since mediawiki
doesnt allow them (even if one urlencodes them).
Find the list (95 entries) here:
http://scratchpad.wikia.com/wiki/Errornames
Im not sure howto proceed here. Should we
a) find better titles before the import or
b) replace '/' by sth like '__OR__' and fix the whole title later?
I tend to b). Other suggestions?
BTW: For the import I will now use WikipediaFS. A great little
filesystem that lets you treat mediawiki articles like real files.
Simply edit with vim, :wq, done. Or for the bulkimport: copy/write
prepared files to the fs.
Sebastian.
That WikipediaFS is pretty gnarly. Thanks for the tip ;-)
--
-fREW
Re: VimWiki - Page Titles
On 5/27/07, fREW [EMAIL PROTECTED] wrote:
On 5/27/07, Sebastian Menge [EMAIL PROTECTED] wrote:
Hi
I have prepared a list with problematic page titles. Especially titles
with chars like [/#{}[]*] and the like are problematic since mediawiki
doesnt allow them (even if one urlencodes them).
Find the list (95 entries) here:
http://scratchpad.wikia.com/wiki/Errornames
Im not sure howto proceed here. Should we
a) find better titles before the import or
b) replace '/' by sth like '__OR__' and fix the whole title later?
I tend to b). Other suggestions?
BTW: For the import I will now use WikipediaFS. A great little
filesystem that lets you treat mediawiki articles like real files.
Simply edit with vim, :wq, done. Or for the bulkimport: copy/write
prepared files to the fs.
Sebastian.
That WikipediaFS is pretty gnarly. Thanks for the tip ;-)
--
-fREW
Also, I think b is a better option.
--
-fREW
Re: A performance question
On 5/25/07, Yakov Lerner [EMAIL PROTECTED] wrote: On 5/25/07, Yongwei Wu [EMAIL PROTECTED] wrote: On 24/05/07, Robert M Robinson [EMAIL PROTECTED] wrote: On Wed, 23 May 2007, fREW wrote: |Someone recently was emailing the list about looking at a small |section of DNA with vim as text and it was a number of gigs. I think |he ended up using other unix tools (sed and grep I think), but |nontheless, text files can be big too ;-) | |-fREW | A maxim that comes up here is A lack of imagination doesn't prove anything. The fact that Condoleeza Rice couldn't imagine the degree of chaos that would ensue if we invaded Iraq does not prove that Iraq is not currently in chaos! I use vim for _structured_ text files, largely because regular expression search is much more useful than word search when the text is structured. Whether those files are large or not usually depends on whether I'm editing programs (small) or viewing/editing their output (often quite large). Emacs also provides regular expression search, but I find vim's commands simpler and easier to type--and therefore faster to use. I do not understand your statements: what's your problem of using regular expressions in grep and sed? I think Robert implied that it takes lot of imagination to use vim on multi-gigabyte size. I might be wrong. I don't exactly understand the connection size of one's imagination and size of the file on which one applies vim. But the connection is perfectly possible. For example, I never tried to run vim on anything bigger than 0.5GB and I do indeed have average or lesser than average imagination. Hell starting tomorrow, I am going to vim the 2+0.2*day_count sized files, every day, It only remains to buy imagine-o-meter, and apply it daily. Yakov average-sized imagination Lerner You should use that as your standard sig from now on. Awesome. -fREW
Re: VimWiki - referring to vimdoc
On 5/23/07, Sebastian Menge [EMAIL PROTECTED] wrote: Am Mittwoch, den 23.05.2007, 11:12 -0700 schrieb Gary Johnson: Executing :help tags.txt shows there is no tags.txt help file, Yea, there is tags in the doc-directory of vim, one can easily use that with python (python is really cool!) and construct the URL. You're right, the text of the link should still be :help sth Sebastian PS: By now only 16 votes for the wiki-issue. I repeat the URL to the poll just in case someone missed it at first: http://snappoll.com/poll/194388.php For the help links could you just have :help tag be a link to where ever? It would then look right on paper, but you could still click it. -fREW
Re: A performance question
On 5/23/07, Yongwei Wu [EMAIL PROTECTED] wrote: On 23/05/07, John Beckett [EMAIL PROTECTED] wrote: panshizhu wrote: As far as I know, Windows does not support files larger than 4GB. So its okay to use unsigned 32-bit for filesize in windows. It's not as bad as that! Even FAT32 supports files much larger than 4GB. Not true. FAT32 supports files up to 4 GB. Check http://support.microsoft.com/kb/314463 NTFS does support big files. I can copy big movie files to a USB hard disk only when it is formatted in NTFS. Who really want to edit TEXT files as large as that? I cannot think of scenarios other than log files. Maybe Vim does not fit in this role. Best regards, Yongwei -- Wu Yongwei URL: http://wyw.dcweb.cn/ Someone recently was emailing the list about looking at a small section of DNA with vim as text and it was a number of gigs. I think he ended up using other unix tools (sed and grep I think), but nontheless, text files can be big too ;-) -fREW
weird defaults in Feisty
Hey all, I just updated to feisty on a samba server machine and a lot of the vim defaults went crazy. For example: Pressing the Up or Down keys in insert mode add new lines with just A or B on them, respectively. That I can live with, but check this out, if I have the following sentence: fREW is a silly guy and my cursor is on the s, and I press cw, it changes to fREW is a sill$ guy and it works just like I had pressed cw and it replaces up the the $ or if I press escape it only has the new text I put in, but it's just so weird! Does anyone know where these new changes in Feisty come from? I wanted to just replace /etc/vim/vimrc, but it was exactly the same. Ideas? Thanks, -fREW
Re: weird defaults in Feisty
On 5/22/07, Michael Hernandez [EMAIL PROTECTED] wrote: On May 22, 2007, at 11:39 AM, fREW wrote: Hey all, I just updated to feisty on a samba server machine and a lot of the vim defaults went crazy. For example: Pressing the Up or Down keys in insert mode add new lines with just A or B on them, respectively. That I can live with, but check this out, if I have the following sentence: fREW is a silly guy and my cursor is on the s, and I press cw, it changes to fREW is a sill$ guy and it works just like I had pressed cw and it replaces up the the $ or if I press escape it only has the new text I put in, but it's just so weird! Does anyone know where these new changes in Feisty come from? I wanted to just replace /etc/vim/vimrc, but it was exactly the same. Ideas? Thanks, -fREW The letters coming from the arrow keys is probably because you don't have set nocompatible in your rc file. Not sure what the other stuff is... I am using vim on feisty right now and have never seen that stuff before :) --Mike H That's the bizarre thing. The computer I am using right now has feisty with no issue, but I also have a heavily customized .vimrc, so that could change that. Anyway, I opened /etc/vim/vimrc and changed a lot of stuff in there to make it more nice to use (incsearch and the like) and for some reason vim appears to be not sourcing the file. Does anyone know why that would be the case? -fREW
Re: weird defaults in Feisty
On 5/22/07, Gene Kwiecinski [EMAIL PROTECTED] wrote: I just updated to feisty on a samba server machine and a lot of the vim defaults went crazy. For example: Pressing the Up or Down keys in insert mode add new lines with just A or B on them, respectively. Sounds like it stopped recognising arrow keys' ANSI sequences (esc[A and esc[B). Wouldda thought the esc would break out of insert mode, but... That I can live with, but check this out, if I have the following sentence: fREW is a silly guy and my cursor is on the s, and I press cw, it changes to fREW is a sill$ guy and it works just like I had pressed cw and it replaces up the the $ or if I press escape it only has the new text I put in, but it's just so weird! Does anyone know where these new changes in Feisty come Uhh, sounds like what it's supposta do, no? ?? Is there a problem with actually changing the text, or just what's displayed? Dunno the setting offhand, but a slow-redraw will mark to the end of the text to be replaced, eg, if you were to change to the end of the line, you'd still see the whole line, but with a '$' where the last character would be, vs erasing all the text and just leaving the insert-cursor in its place. I find the latter disquieting, and would rather *see* what I'm replacing, but never really paid too much attention to which settings do what. I'm complacent that way... :D I prefer that cw doesn't do this weird $ thing. It bothers me. I might be ok with it if the word I was typing over were a different color, but that is not the case. Also: set nocompatible worked just fine, but I wanted to make this a system wide setting. I think that the problem has to do with vim not sourcing the /etc/vim/vimrc. It appears that that is why things aren't working correctly. Anyone know why it wouldn't source that file? -fREW
Re: weird defaults in Feisty
On 5/22/07, fREW [EMAIL PROTECTED] wrote: On 5/22/07, Gene Kwiecinski [EMAIL PROTECTED] wrote: I just updated to feisty on a samba server machine and a lot of the vim defaults went crazy. For example: Pressing the Up or Down keys in insert mode add new lines with just A or B on them, respectively. Sounds like it stopped recognising arrow keys' ANSI sequences (esc[A and esc[B). Wouldda thought the esc would break out of insert mode, but... That I can live with, but check this out, if I have the following sentence: fREW is a silly guy and my cursor is on the s, and I press cw, it changes to fREW is a sill$ guy and it works just like I had pressed cw and it replaces up the the $ or if I press escape it only has the new text I put in, but it's just so weird! Does anyone know where these new changes in Feisty come Uhh, sounds like what it's supposta do, no? ?? Is there a problem with actually changing the text, or just what's displayed? Dunno the setting offhand, but a slow-redraw will mark to the end of the text to be replaced, eg, if you were to change to the end of the line, you'd still see the whole line, but with a '$' where the last character would be, vs erasing all the text and just leaving the insert-cursor in its place. I find the latter disquieting, and would rather *see* what I'm replacing, but never really paid too much attention to which settings do what. I'm complacent that way... :D I prefer that cw doesn't do this weird $ thing. It bothers me. I might be ok with it if the word I was typing over were a different color, but that is not the case. Also: set nocompatible worked just fine, but I wanted to make this a system wide setting. I think that the problem has to do with vim not sourcing the /etc/vim/vimrc. It appears that that is why things aren't working correctly. Anyone know why it wouldn't source that file? -fREW I figured it out and if anyone else has this problem I am sending out the solution. Basically when I run vi it is running vim.tiny. vim.tiny sources /etc/vim/vimrc.tiny, not /etc/vim/vimrc, also, vim.tiny is pretty crippled, in that it doesn't even have syntax highlighting, so consider whether that's even what you want. -fREW
Re: weird defaults in Feisty
On 5/22/07, Peter Palm [EMAIL PROTECTED] wrote: Op dinsdag 22 mei 2007, schreef fREW: I figured it out and if anyone else has this problem I am sending out the solution. Basically when I run vi it is running vim.tiny. vim.tiny sources /etc/vim/vimrc.tiny, not /etc/vim/vimrc, also, vim.tiny is pretty crippled, in that it doesn't even have syntax highlighting, so consider whether that's even what you want. Actually, if I run vi (not vim), I definitely don't want a 'full-featured' vim (modeline exploits etc), and expect vim to run in 'compatible mode' (or whatever vi implementation is the default on my system). (my shell config aliases vi to vim, if it's available, but only as a normal user) Setting the defaults in /etc/vim/vimrc is, in my opinion, not 'the right way', it's what ~/.vimrc is for. And, just out of curiosity, does vim.tiny parse ~/.vimrc, or does it (only?) look at ~/.vimrc.tiny as well? Regards, Peter Palm No, as far as I know it still reads the regular .vimrc. I changed the system wide defaults because it wasn't just me who was surprised by the changes. Otherwise I would directly copy over my personal .vimrc. -fREW
Re: weird defaults in Feisty
On 5/22/07, David Nečas (Yeti) [EMAIL PROTECTED] wrote: On Tue, May 22, 2007 at 09:39:29AM -0600, fREW wrote: I just updated to feisty on a samba server machine and a lot of the vim defaults went crazy. For example: Pressing the Up or Down keys in insert mode add new lines with just A or B on them, respectively. This is what vi does. Movement is performed by hjkl, remember? That I can live with, but check this out, if I have the following sentence: fREW is a silly guy and my cursor is on the s, and I press cw, it changes to fREW is a sill$ guy and it works just like I had pressed cw and it replaces up the the $ or if I press escape it only has the new text I put in, but it's just so weird! This is exactly what vi does. Command cw changes the word (and does only that), $ marks where it ends. Does anyone know where these new changes in Feisty come from? This has been hopefully explained already (vi runs a binary that really behaves like vi, whereas vim runs something more featureful -- this common in Linux distros). Anyway, it's a bit strange when a vim user describes vi as `crazy' and `so weird'... Yeti -- http://gwyddion.net/ Well, nocompatible is recommended, and since this is a vim list, not just a vi list, I wouldn't think that it would be strange at all for people to expect vim (not vi) when they want vim. Just my two-cents. -fREW
Re: Vim to Vi (Was: weird defaults in Feisty)
On 5/22/07, Tobia [EMAIL PROTECTED] wrote:
David Nečas (Yeti) wrote:
it's a bit strange when a vim user describes vi as `crazy' and `so
weird'...
It may sound strange to us Vim veterans, but it's what I would expect.
My path to learning Vi/Vim (which took place at the same time as my
learning of GNU/Linux, by the way) was as follows:
1. Use it as a Notepad with weird save/quit commands (esc:wcr ...)
Always in insert mode, only using the arrows, Del, BS, Home, End, and
hitting Esc and 'u' like crazy whenever something weird happened.
2. Learn copy paste, first line-wise (dd yy p P), then selection-wise
(v V ^V y d, still only using the arrow keys.
At this point (a few months?) I was already as productive as with my
former Windows editor of choice! (something like TextEdit™ or TextPad™)
3. Learn that command mode is actually useful for moving around in the
file (gg, G, {, }) and opening two files at a time (:e, C-^)
4. Other stuff (complex movements, buffers/windows/tabs, registers,
macros, mappings, autocommands, folding, custom syntax files...)
This timeline might look non-linear, in fact I believe that learning Vim
is an exponential task to the engaged user, and that's a very good thing!
The point is: I don't consider my learning path in any way peculiar, and
if Vim had suddenly reverted to Vi while I was in phases 1 to 3, I would
have looked at my computer with a blank, baffled expression on my face.
Tobia
Yeah, the really big problem is that the guy I am working with who I
am helping admin a few servers is at exactly step 1. In fact, it
wasn't until recently that he figured out (I told him) that Ctrl-Z is
not the same as :q!. And like you said, we upgraded and he was just
like, vi got totally weird and now I use nano! But after having
explained to him a couple things that might help him out (r for
replacing single characters and whatnot) I think he might start the
path to enlightenment ;-)
-fREW
Re: A performance question
On 5/22/07, Gary Johnson [EMAIL PROTECTED] wrote: On 2007-05-22, Robert Maxwell Robinson [EMAIL PROTECTED] wrote: Hmm, interesting. I've noticed before that the CPU is pegged when I'm deleting, but I don't think my machine's behavior is due to CPU load; the machine has two CPUs, I'm typically the only (serious) user, as top has confirmed is the case now, and I get the same behavior whether I'm running another large job or not. My other large job takes about 1 Gb leaving almost 2 Gb of memory free, so I don't think I'm running out of physical memory, either. Given the difference between your results and mine, I finally checked my software versions, which are old: Red Hat 3.4.6, vim 6.3.82. Unfortunately I don't have permission to update this system, and the administrator hasn't been willing to do so in the past. It turns out that this Red Hat installation also has vim 6.3.82 in /usr/bin/vim, so I tried that, too. /usr/bin/vim -u NONE two_million_lines 50% :.,$d 2 minutes 30 seconds! Eureka! According to the System Monitor CPU bar color, that was almost all User time, whereas with vim 7.1, it was a more balanced mix of User and Kernel time. (Kudos to Bram for such a performance improvement from vim 6 to 7!) I'm not allowed to update anything under /usr on this system, either, so I build the latest and greatest versions of tools under $HOME/src and put the binaries in $HOME/bin. Building vim under Linux is really easy. I do the following. mkdir ~/src/Linux/vim-7.1 cd ~/src/Linux/vim-7.1 Download vim-7.1.tar.bz2 from vim.sf.net. tar jxf vim-7.1.tar.bz2 cd vim71 ./configure --prefix=$HOME/src/Linux/vim-7.1 --enable-cscope make make install ln -s $HOME/src/Linux/vim-7.1/bin/vim ~/bin/Linux/vim My PATH includes $HOME/bin/Linux and that directory contains most of the symbolic links to vim that you will find in $HOME/src/Linux/vim-7.1/bin; the ones I use. That is, $ cd ~/bin/Linux $ ls -l | grep vim lrwxrwxrwx 1 garyjohn fw 3 Nov 14 2005 gvim - vim lrwxrwxrwx 1 garyjohn fw 3 Nov 14 2005 gvimdiff - vim lrwxrwxrwx 1 garyjohn fw 3 Sep 23 2005 vi - vim lrwxrwxrwx 1 garyjohn fw 3 Sep 23 2005 view - vim lrwxrwxrwx 1 garyjohn fw 40 May 17 18:45 vim - /home/garyjohn/src/Linux/vim-7.1/bin/vim lrwxrwxrwx 1 garyjohn fw 3 Sep 23 2005 vimdiff - vim That makes it really easy to update and to test different versions of vim with only a change to one symbolic link. But that's just a matter of taste. The point is that however you choose to install it, it's easy to build and maintain your own vim installation without having to bother or bother with your system administrator. I went looking for release notes for vim, but the announcements I found didn't go into detail about what bugs were fixed in which version. Can someone point me in the right direction? Go to the vim home page, vim.sf.net, click on the link to Documentation, then help files online, then main help file, and finally, version7.txt. Or you can just go that page directly, http://vimdoc.sourceforge.net/htmldoc/version7.html This describes all the changes from version 6 to version 7, including bug fixes. Regards, Gary -- Gary Johnson | Agilent Technologies [EMAIL PROTECTED] | Mobile Broadband Division | Spokane, Washington, USA Another thing that might help with speed that was mentioned a month or so ago is the following script specifically aimed at increasing speed for large files: http://www.vim.org/scripts/script.php?script_id=1506. -fREW
Re: remote editing and spell list sync
On 5/20/07, Yakov Lerner [EMAIL PROTECTED] wrote: On 5/19/07, Eric Smith [EMAIL PROTECTED] wrote: I use remote editing a lot (rsync protocol) and want to keep the spelling lists on both machines always synchromised. Is the best way with unison(1) or suchlike or is there a better way? I tried unison, but then I found that personal svn/hg/git/cvs is much better. For many years, I have been using personal svn. Then I switched to git. It's matter of taste which VCS to use. But it beats unison, to my opinion. One problem of VCS is that there are many any choices. hg and svn are both good choices. Yakov I agree with Yakov. I have my dotfiles for zsh and vim and a number of other programs in an svk and I can do svk push and it will commit it to an svn server on another computer. That is nice because I can have backups but also don't NEED internet access to commit. -fREW
Re: launching vim from eclipse
On 5/18/07, y m [EMAIL PROTECTED] wrote: Thanks for your reply. I guess I should have been more specific. Yes I tried doing that but I would like 2 additional functionalities which the Visvim ole interface to MS Visual Studio does: 1. I want to be able to open vim with the currently displayed file instead of having to navigate to it through the left hand package view. 2. After opening the file, I want vim to jump to the line currently displayed in the eclipse editor. I suppose I will have to write my own ole plugin to do this, but I was hoping something like this already existed so I wouldn't have to reinvent the wheel. I don't know of anything that works that way, but it should be that hard. Eclipse is good about things like that. Just make a hotkey or something that will run gvim -c :line number or something like that. Eclipse often makes such variables for things like that. I don't know off hand though. -fREW
Re: Vim Wiki - Tip id and URL
On 5/18/07, John Beckett [EMAIL PROTECTED] wrote: A.J.Mechelynck wrote: Wouldn't it be enough to set up the main tip page with a tip _name_ (which would be the current title of the tip, or a disambiguation page if there are more than one tip with the same title), and have the tip _number_ (only for tips imported from Vim-online) refer to a redirect page, let's say Vim tip 1 = The super star? So the conversion script could convert vimtip#1 to [[Vim tip 1]], which could be done mechanically, and the redirect would automagically resend anyone clicking that link to the actual page. I suppose that links pointing to the redirect pages could be readjusted later, in no hurry, either by hand or by a wiki robot, and in either case with the help of the What points here page for the redirect. Would someone who understands wiki procedures please describe how the URL for a tip would be generated. What is actually achievable? Can a URL be changed later without much effort? Can we have a redirect as Tony outlines above? I proposed devising a short id for each tip (like super_star for tip 1), then using that tip_id in the URL. That would avoid ugly URLs which would wrap in an email, or which would contain stuff like %20, making the URL hard to read. Is my concern (that we should avoid long ugly URLs) misguided? John %20's won't show up in a wiki. If you make super_star the id, then super star will also get to the same place. That's what makes a good wiki so nice. Redirects do seem to be easy to do. If we have a page and move it to somewhere else, the old URL automatically redirects to the new one. If I understand what Tony is saying, it would be pretty easy. -fREW
Re: Vim Wiki - Wiki Template Proposal
On 5/17/07, John Beckett [EMAIL PROTECTED] wrote: Martin Krischik wrote: Well, on most Wikibooks comments are seldom cleaned up. They are just left to rot. And since there are not on the main page it does not matter. I see what you mean. If that were to happen with the Vim wiki then it would be really ugly (i.e. if junk comments were left indefinitely on the main tip page). Let's agree that in November (say), we could have a clean up. Someone could post a message to vim@vim.org with a list of tips that contain extraneous comments. Give everyone 14 days notice that the listed tips will be deleted if no one cares enough about them to clean up the comments. This suggestion is not for difficult cases where the tip is worthwhile, but for various reasons it's hard to integrate the comments. However, even in those cases, if we care enough we should edit the comments for spelling and accuracy, and should delete unhelpful comments. John That sounds reasonable to me. -fREW
Re: embedable vim?
On 5/17/07, Marc Weber [EMAIL PROTECTED] wrote: either natively as (IIRC) kde applications do, or by means of an extensions (as seveal other posts mention doing for Firefox). Other browsers (such as IE IIRC) simply don't support any external editor. Shouldn't be that hard to tell AutoHotkey to copy paste the text to vim and back .. (windows only) Marc That's actually one of the vim tips out there. Search for windows and it's one of the top 10 I think. -fREW
Re: Vim Wiki - Tip Page Formatting Deadline
On 5/15/07, Tom Purl [EMAIL PROTECTED] wrote: Task: Wiki Format Sign-Off Deadline: Monday, May 21st (arbitrary, I know) Overview We've had some great, constructive discussions lately regarding how we will be creating and editing tips in the future. Before we can finally decide how this is going to work, however, we need to decide upon a page format for tips. The most recently-updated wiki tip examples can be found at the following URL: * http://scratchpad.wikia.com/wiki/VimTest The following tips should stand out: * http://scratchpad.wikia.com/wiki/VimTip1 * http://scratchpad.wikia.com/wiki/VimTip1_v2 This first tip uses the Template:Tip template (http://scratchpad.wikia.com/wiki/Template:Tip), and the second tip uses the Template:Tip2 template (http://scratchpad.wikia.com/wiki/Template:Tip2). Requested Actions = Please take a look at these tips, decide which one you prefer, and then provide constructive criticism for that tip's format. There's no such thing as a dumb comment. My Two Cents I really like VimTip1_v2, which uses the Tip2 template. Here's what I like: * No special formatting for commands or any other preformatted text. I think that this is an essential requirement for the initial conversion effort. * Easy to read * Succinct How do you want to handle comments? Typically on a Mediawiki site, you sign you comments like so: This is so cool! Which is then saved to the page like this: This is so cool! Tpurl 15:17, 15 May 2007 (UTC) It's a little ugly, but it's the norm in the wiki world. What do you guys think? Tom Purl I think you are right about the comments. It doesn't look like the best thing ever, but it will work fine for a wiki. People will probably leave off the sometimes and that will probably be something that we will have to live with. I think that there is probably a way that we can make a reminder for people to put that there after comments, but I don't think we could easily require it. Also, it should be obvious that I prefer the Tip2 template ;-) -fREW
Re: Vim Wiki - Wiki Template Proposal
On 5/15/07, Sebastian Menge [EMAIL PROTECTED] wrote: Am Dienstag, den 15.05.2007, 10:03 +0200 schrieb Sebastian Menge: There is an extension called InbutBox but I have not understood yet howto use it. Now I have. There is a sample on http://scratchpad.wikia.com/wiki/VimTest But it leads to another problem: In a wiki we have no means to autoincrement the id. Thus the convention VimTipID for page names is not feasible. A good prefix is a must in my opinion, but what suffix? Howto assure that it is unique, not cryptic etc? Or what about complete freedom, and revising it afterwards? Perhaps we can even drop the prefix and use simply a category. Seb. That's a hard question. Would it be worth it to have a cron job or something that ran every night and moved/linked the newest tips to chronologically ordered tip numbers? I don't think doing that would be a problem, I just think it might be surprising when you make a tip, and it's gone the next day. But a redirect like wikipedia has might make that more reasonable. Sound good? -fREW
Re: Vim Wiki - Tip Page Formatting Deadline
On 5/15/07, Gary Johnson [EMAIL PROTECTED] wrote:
On 2007-05-15, Tom Purl [EMAIL PROTECTED] wrote:
Task: Wiki Format Sign-Off
Deadline: Monday, May 21st (arbitrary, I know)
Overview
We've had some great, constructive discussions lately regarding how we
will be creating and editing tips in the future. Before we can finally
decide how this is going to work, however, we need to decide upon a page
format for tips.
The most recently-updated wiki tip examples can be found at the
following URL:
* http://scratchpad.wikia.com/wiki/VimTest
The following tips should stand out:
* http://scratchpad.wikia.com/wiki/VimTip1
* http://scratchpad.wikia.com/wiki/VimTip1_v2
This first tip uses the Template:Tip template
(http://scratchpad.wikia.com/wiki/Template:Tip), and the second tip uses
the Template:Tip2 template
(http://scratchpad.wikia.com/wiki/Template:Tip2).
Requested Actions
=
Please take a look at these tips, decide which one you prefer, and then
provide constructive criticism for that tip's format. There's no such
thing as a dumb comment.
I much prefer VimTip1 v2. Whether just browsing tips or reading
tips I've searched for, I want to be able to read it quickly without
having to scan through a bunch of boilerplate. I would even
advocate a Synopsis line that would summarize the tip if the title
didn't already do so. I like having the meta data collected as it
is in one line at the bottom of the tip: it's concise and in an
unobtrusive yet consistent and easy-to-find location.
In the table of contents, each tip really needs to have the title
alongside its number. The first page,
http://scratchpad.wikia.com/wiki/VimTest, is lacking that, unless
the names there (e.g., VimTip123) are just place holders for real
titles. I really don't want to have to load each tip page one at a
time to browse the latest contributions.
My $0.02.
Regards,
Gary
--
Gary Johnson | Agilent Technologies
[EMAIL PROTECTED] | Mobile Broadband Division
| Spokane, Washington, USA
I don't know how to add pages to that dynamic page there if they have
already been created, but I made [1] with template [2] so that it
would work better if you just wanted to see the titles of pages. The
only problem is that this would require more work if we wanted to
scrape the wiki at some point. Anyway, if we WERE to do this, this is
how I envision it working:
1: User creates a new page using Template:Tip3 (or 2 or whatever)
2: They leave the id blank because it will be ignored
3: At some specified interval, a cron job runs that will scrape the
source of any newly created pages and sort them in a chronological
list
4: The program in the cron job moves each new tip to: #{generated id} - #{title}
And then we could probably have another program that would run say,
once a week that would iterate through the entire tip list ensuring
that people didn't do something silly, like change the numbers. I
presume that we would have to use the history and then look at the
initial creation of the page to ensure correct times and whatnot.
I can still see why we would want to use the format:
Tip1
Tip2
...
Tip10
...
but it makes sense to have the names show the titles (or more
obviously, the titles should BE the names).
What do you guys think?
[1] http://scratchpad.wikia.com/wiki/1_-_the_super_star
[2] http://scratchpad.wikia.com/wiki/Template:Tip3
Re: Vim Wiki - Wiki Template Proposal
On 5/15/07, Tom Purl [EMAIL PROTECTED] wrote: On Tue, May 15, 2007 7:46 am, Sebastian Menge wrote: Am Dienstag, den 15.05.2007, 13:51 +0200 schrieb Zdenek Sekera: http://scratchpad.wikia.com/wiki/VimTest Since I'm the *only* person who has so far voted against using wiki templates, I will accept the fact that I'm in the minority and get out of the way :) Having said that, I really like the idea of using templates in this way if we're going to use macros. Also, check out the wikia site (vim.wiki.com). I uploaded Sebastian's logo. Thanks, Tom Purl I dig the page! That logo is great :-) I think you dropped off an a when you sent out the link though. http://vim.wikia.com/wiki/Main_Page -fREW
Re: Vim Wiki - Wiki Template Proposal
On 5/15/07, fREW [EMAIL PROTECTED] wrote: On 5/15/07, Sebastian Menge [EMAIL PROTECTED] wrote: Am Dienstag, den 15.05.2007, 10:03 +0200 schrieb Sebastian Menge: There is an extension called InbutBox but I have not understood yet howto use it. Now I have. There is a sample on http://scratchpad.wikia.com/wiki/VimTest But it leads to another problem: In a wiki we have no means to autoincrement the id. Thus the convention VimTipID for page names is not feasible. A good prefix is a must in my opinion, but what suffix? Howto assure that it is unique, not cryptic etc? Or what about complete freedom, and revising it afterwards? Perhaps we can even drop the prefix and use simply a category. Seb. That's a hard question. Would it be worth it to have a cron job or something that ran every night and moved/linked the newest tips to chronologically ordered tip numbers? I don't think doing that would be a problem, I just think it might be surprising when you make a tip, and it's gone the next day. But a redirect like wikipedia has might make that more reasonable. Sound good? -fREW Also, we need to make sure that the script correctly escapes any wiki formatting. For example, http://scratchpad.wikia.com/wiki/VimTip7. As you can see the and is set to be a page in the first comment. To fix that you just put nowiki/nowiki around the brackets. Also, I think that for the most part br's can be replaced with newlines. Any html at all should have a wiki version. See below for help on that. For the most part I don't think the markup is a huge deal, but think that we should try to get the script to output the closest thing possible to wiki syntax. Could someone send out the script that was used to upload pages initially? It would be helpful to see it so that we could set up some translation code in the script. [1] http://en.wikipedia.org/wiki/Wikipedia:Cheatsheet [2] http://www.wikia.com/wiki/Help:Tutorial_3 [3] http://www.wikia.com/wiki/Help:Tutorial_4 [4] http://www.wikia.com/wiki/Help:Tutorial_5 -fREW
calling normal commands from ex/a function
Hey everyone, How do I have a function call Normal commands? Example: I'd like to make a function that will open a certain file, and then set the foldlevel to 1, and then go to the right window. So I have: function TodoListMode() execute :e ~/.todo.otl execute :Calendar endfunction and then after the second command I want to do: ctrlwl zM zr Thanks! -fREW
Re: Tip #80: Restore cursor to file position in previous editing session does not work on Ubuntu
On 5/15/07, Tushar Desai [EMAIL PROTECTED] wrote:
This tip (which restores cursor to the last position in previous
editing session) is the lifeline of any developer and it works great
for me at work (on Fedora Core 6).
I've Ubuntu 7.04 @home and I just compiled and installed vim7.1 and
this doesn't work for me. It didn't work with vim7.0 either.
Actually, even on Ubuntu it works if I don't quit from vim. On FC6,
irrespective of the quit. I suppose on ubuntu this is some how not
being remembered. So, how do I get my cursor back across session
quits?
Regards,
-tushar.
PS: Pardon me for some lame questions, while I try to improve my vim skills.
Actually this problem came up something like 3-4 days ago. First off,
you need to make sure that you have permissions to read and modify
~/.viminfo . It appears that sudo'ing can mess that up. After that
you can just put this (from tip 80?) into your .vimrc
augroup JumpCursorOnEdit
au!
autocmd BufReadPost *
\ if expand(afile:p:h) !=? $TEMP |
\ if line('\) 1 line('\) = line($) |
\ let JumpCursorOnEdit_foo = line('\) |
\ let b:doopenfold = 1 |
\ if (foldlevel(JumpCursorOnEdit_foo)
foldlevel(JumpCursorOnEdit_foo - 1)) |
\let JumpCursorOnEdit_foo = JumpCursorOnEdit_foo - 1 |
\let b:doopenfold = 2 |
\ endif |
\ exe JumpCursorOnEdit_foo |
\ endif |
\ endif
Need to postpone using zv until after reading the modelines.
autocmd BufWinEnter *
\ if exists(b:doopenfold) |
\ exe normal zv |
\ if(b:doopenfold 1) |
\ exe +.1 |
\ endif |
\ unlet b:doopenfold |
\ endif
augroup END
I had the same issue from Ubuntu upgrades and that fixed it.
Hope that helps!
-fREW
Re: Vim Wiki - Wiki Template Proposal
On 5/16/07, John Beckett [EMAIL PROTECTED] wrote: Martin Krischik wrote: We should not include comments on the content page! That's what the discussion page is for. You are very keen on that point, so I'm going into a bit of detail about why I don't agree. A wiki discussion page (as you know!) is intended for people to discuss the future of the page. Does an error need fixing? Are there points which need to be expanded? Is the content or style inconsistent with overall guidelines? Or, on the discussion page, I might ask why you reverted my edits, and we could debate whether my wording was better than yours. We'll still need the above in a Vim wiki. However, the Comments in Vim Tips are a different animal. Most comments are fluff, and need to be deleted ASAP. Many comments are very helpful, and their content needs to be merged into the body of the tip. On some tips, a reader would need a lot of persistence to work out what to do, because the tip says X, some comment says Y, and another comment says Z. I think I recall seeing cases where a comment points out that the tip is hopeless because there's a better way of handling the situation. We wouldn't want that comment hidden on the discussion page (where a casual reader won't see it). As I understand it, the whole point of moving Vim Tips to a wiki is so that we can fix each tip so that there is one consistent story on each page. You are correct that having the comments on the main page will be ugly. However, we hope that will be temporary. Perhaps I should say that *I* hope it will be temporary because I see that the proposed sample has a section for Comments. I imagine editing the wiki will go like this: - Import all tips with comments on main page. - Edit important tips and clean them up completely. - Edit nearly all tips to remove junk comments. - Leave difficult cases for later. I imagine there will be lots of difficult cases where considerable effort would be needed to merge the comments. In those cases, we would just leave the useful comments, perhaps editing them where helpful. Later (say in six months) we would discuss what to do with those tips that still have unmerged comments. In some cases, it might be very reasonable to leave comments on the main page. For example, a tip might describe a scenario and its solution. Then a comment might say that if you are running on a certain platform, then a better approach would be something else. It may never be worth fixing all tips to eliminate such comments, yet you wouldn't want to hide that useful info on the discussion page. I think that following the above strategy would be much easier for people editing a tip (easier than editing the main page and the discussion page, because once a comment is dealt with, it would have to be removed from the discussion page). Also, seeing the old comments on the main page would be an immediate reminder that the tip needs cleaning up. Imagine the mess if comments were on the discussion page, then someone edited the main page to include a few useful comments from the discussion page, but failed to remove those comments. It would then take herculean efforts to properly fix the tip, and the discussion pages would have so much junk in them that their function as a tip discussion would fail. John Also, just to follow up with what John said, Wikipedia is /not/ like most wiki's in this respect. I read a certain wiki off and on and I have stumbled upon a few that are similar where people just ask questions right on the page. It's pretty nice once you get used to it, so I'd say leave the discussion for meta-thought and not actual thoughts about content. -fREW
Re: calling normal commands from ex/a function
On 5/16/07, Charles E Campbell Jr [EMAIL PROTECTED] wrote: fREW wrote: Hey everyone, How do I have a function call Normal commands? Example: I'd like to make a function that will open a certain file, and then set the foldlevel to 1, and then go to the right window. So I have: function TodoListMode() execute :e ~/.todo.otl execute :Calendar endfunction and then after the second command I want to do: ctrlwl zM zr * may I point out that you're using execute when you don't need to. * you're already in ex mode; no need to use colons to do ex mode commands * ctrl-w_l can be performed with wincmd l . * to perform normal mode commands in a function, use norm! (the exclamation prevents any maps from interfering) So, with these points in mind: fun! TodoListMode() e ~/.todo.otl wincmd l norm! zMzr Calendar endfun Now, I confess that I didn't test this... Regards, Chip Campbell Thanks for the pointers! I ended up with this, which doesn't use any normal commands at all ironically. function! TodoListMode() e ~/.todo.otl Calendar wincmd l set foldlevel=1 endfunction Thanks for the help though, it works just as one would hope now! -fREW
Re: Vim Wiki - Tip Page Formatting Deadline
On 5/16/07, A.J.Mechelynck [EMAIL PROTECTED] wrote: Gene Kwiecinski wrote: Thinking about how a wiki works shows that keeping tip numbers is doomed. First, there is no auto-increment id, and as you point out, there is no reasonable way to automate fixes. Is there any equivalent to javascript's document.lastModified? Can create a serial number based on the date of submission, then rearrange by fields to a sortable ID, eg 2007.05.15.23.53 for a tip created yesterday at 23:53. Don't need dots, or hyphens, or anything, as 2007051523353 would be fine, too. The odds of having 2 tips be submitted in the same minute would be remote. I don't think so. A minute is sixty seconds, and sooner or later we'll have two different users submitting tips less than sixty (or even thirty) seconds away from each other. Even adding the seconds to the ID doesn't clear the problem, it lowers the probability but doesn't make it zero. With enough Vimmers adding tips, sooner or later there'll be a clash. Best regards, Tony. -- If the odds are a million to one against something occurring, chances are 50-50 it will. I still think we could automate it with a cron job. It doesn't have to be run on wikia. I don't think it would be that hard to scrape and moving a tip is even simpler. So you just move all the tips created since the last run of the cron job and move them to $id - $title -fREW
Re: embedable vim?
On 5/16/07, Franco Saliola [EMAIL PROTECTED] wrote: Is there a way to embed vim into my browser (or any other application for that matter)? I hate typing in the html text boxes and would much prefer to use vim to edit my email. Or are there any suggestions on reading/writing email using Gmail and Vim? I'll create a tip if I figure out a good method. Thank you, Franco -- Try searching the tips database. I remember reading something once about sending gmail with vim. Reading it with vim is harder, and if you really want to do that you will want to look into using the gmail pop3 with mutt. I think that you can embed vim with konqueror or something like that, but for the most part you should vote for that as a feature in vim. Currently it is #4. Hope that helps. [1] http://www.vim.org/sponsor/vote_results.php -fREW
Re: $HOME inconsistent in Windows?
If you haven't already gotten an answer you may want to try logging out and back in. I recall having some issues with the Environment variables in windows. On 5/9/07, Chris Sutcliffe [EMAIL PROTECTED] wrote: Hey All, I've defined a HOME environment variable as %HOMEDRIVE%%HOMEPATH%. In a command prompt, if get the following: echo %HOME% C:\Documents and Settings\user ID In gvim, I get the following: :e $HOME\ which expands to :e c:\Documents\ and\ Settings\user ID\Application\ Data\ Is there some reason why vim is ignoring the HOME variable I've set? What is interesting is that my _viminfo is being read from C:\Documents and Settings\user ID just fine. Chris -- Chris Sutcliffe http://ir0nh34d.googlepages.com http://ir0nh34d.blogspot.com http://emergedesktop.org
How to make a replacer function
How does one make a function that will surround a visual selection? Example: Hello, my name is fREW. Select my name and say, :Bang() and the text should now be Hello, bmy name/b is fREW. I presume it will have something to do with using ' and ', but beyond that I am not really sure. Thanks! -fREW
Re: what feature is required to return to last editing position?
On 5/10/07, Micah Cowan [EMAIL PROTECTED] wrote: Bram Moolenaar wrote: Micah Cowan wrote: Vincent BEFFARA wrote: However, it would be nice of vim to always test that it owns the $HOME directory before creating files there. Would it break anything ? I think this would be a good idea as well. One could argue that if we reason this way for vim, we should reason this way about everything that ever creates config files in the user's home directory; however, not every such thing can be expected to be run as root, and editors--and most particularly vim--are extremely likely to be run as root, so I think it's not unreasonable to ask them to take on this responsibility. And what if root always uses $HOME/.viminfo, where $HOME is the only person who can be root? It might be that there is no root home directory. Let's keep it simple: $HOME/.viminfo is the default viminfo file. If you want to use another file you have to tell Vim. I don't think it was suggested that we use a different file. I think it was suggested that vim not automatically create .viminfo with euid's ownership, if $HOME isn't owned by euid. I still think that this part of it (which was Vincent's) is a good idea, despite your good points wrt 'verbose' and giving away files (which was my idea). Perhaps rather than simply avoiding file creation, in the case of root we could set the file's owner to the real id/gid, instead of the effective one. This option is unavailable when the user is sudoing as non-root, but this seems much less likely to happen before having run it normally, than running under sudo is. Giving away a file is a big no-no for security reasons. Root may yank text in a register that a normal user is not supposed to see and this ends up in the viminfo file. Good point. Although, I have a difficult time envisioning how such a scenario could take place, and it not be the same user reading viminfo that was running as the root with HOME set that way. But better safe than sorry. Another issue, which was touched on in that Ubuntu bug report, is that vim doesn't warn or anything when it can't open .viminfo. Perhaps it should distinguish between ENOENT and EPERM, and warn in the latter case? It should possibly also warn in the event that it decides to change ownership as above (if this is decided to be a good idea), or when it is not created because of non-root, non-HOME-owner effective user id. :set verbose=1 When ACLs are used there are many ways reading a file can fail. Just mentioning that it failed should be sufficient, the user will have to figure out why. That's better than a wrong message. Hm... but the typical user isn't going to necessarily going to think to do this. IMO, the user should just be able to run typical commands like sudo vim /some/important/file and have it just work, without having to think to himself Gee, I'd better set my HOME directory properly or better make sure I run it myself first or better put it into verbose mode. Sure, the user would've been better off running sudo -He ... instead, but most users never ever do. It could be argued that this is the user's miseducation; but my philosophy is that when an erroneous usage pattern is common, then the error ceases to lie with the user, and becomes an error in the interface. However, if it were decided that we will have vim balk at creating .viminfos that are mismatched to the root user, then I probably wouldn't care overly much whether vim complains about existing ownership problems overly much. Perhaps an option could be added to control this (in case a user should /want/ a root .viminfo in a regular user home dir, for some reason), with the default set for non-creation. As an alternative, what about vim nusing a uid-based name for .viminfo, when it detects the ownership mismatch? Say, .viminfo-u%d, where %d is vim's euid? Couldn't we set up that latter part manually somehow with scripts? Like, if I am root, viminfo is .viminfo-ux and otherwise, viminfo is .viminfo-uy? -fREW
Re: How to make a replacer function
On 5/14/07, Ian Tegebo [EMAIL PROTECTED] wrote: On 5/14/07, fREW [EMAIL PROTECTED] wrote: How does one make a function that will surround a visual selection? Example: Hello, my name is fREW. Select my name and say, :Bang() and the text should now be Hello, bmy name/b is fREW. I presume it will have something to do with using ' and ', but beyond that I am not really sure. Thanks! -fREW Have you seen the surround plugin? http://www.vim.org/scripts/script.php?script_id=1697 -- Ian Tegebo Very cool! Thanks! -fREW
Re: Vim and email quoting
On 5/12/07, Troy Piggins [EMAIL PROTECTED] wrote: * Timothy Knox is quoted my replies are inline below : I use vim to write my outgoing email, and for the most part, it rocks. Thanks to all the folks who have written modules and provided tips that make it the best thing for writing email since mailx grin. What tips/scripts are you using and what are your favourites? Yeah, I am interested as well. What do you use to do all of this? -fREW
Re: Vim Wiki - Wiki Template Proposal
On 5/14/07, Tom Purl [EMAIL PROTECTED] wrote:
Sebastian Menge has graciously created a Mediawiki template that could
be used with the proposed Vim wiki. Here's a link to the template:
* http://scratchpad.wikia.com/wiki/Template:Tip
This is the wrapper for the actual tip content. Here's an example of
some plain-text content:
{{Tip
|id=1
|title=Tip #1 - the super star
|created=February 24, 2001 14:47
|complexity=basic
|author=scott at kintana.com
|version=5.7
|text=
When a discussion started about learning vim on the vim list Juergen
Salk mentioned the quot;*quot; key as something that he wished he had
know earlier. When I read the mail I had to go help on what the heck the
quot;*quot; did. I also wish I had known earlier...brbrUsing the
quot;*quot; key while in normal mode searches for the word under the
cursor.brbrIf that doesn't save you a lot of typing, I don't know
what will.
}}
When you combine this content with the template on the wiki, you get the
following:
* http://scratchpad.wikia.com/wiki/VimTip1
The big benefit of using a wiki template is that it separates the
content from the presentation, which can be very nice from the
perspective of a sysadmin or tip converter.
The disadvantage, in my eyes, of using wiki templates is that it adds
another barrier to entry for potential tip authors/editors. Not only
would they have to know how to do basic Mediawiki editing, but they
would also have to know how to use templates. Also, in my opinion, it
is more difficult to edit the content when it's squished into a
template.
So far, we know about the opinions of me and Sebastian. What does
everyone else think? Is the template thing a good idea for our wiki?
Thanks again!
Tom Purl
I think that a template is a good idea, but like someone else (was it
you Tom) said in another thread, let's make the metadata more subtle.
It really dominates the page and it's kindav an eyesore. I put up
another template and it is at
http://scratchpad.wikia.com/wiki/Template:Tip2 with a demo at
http://scratchpad.wikia.com/wiki/VimTip1_v2 . The only difference
being that I manually took the #1 off of the tip title from VimTip1
and I made the Your signed comments here. not part of the template,
which was probably not really intended in the original anyway. What
do you guys think? The other idea that I had was to completely remove
the first header (==Tip: #{{{id}}} - {{{title}}}==) and have the tips
actually indexed something like that, so you would have that header by
default, and then a comments thing at the bottom.
-fREW
Re: book
On Mon, 14 May 2007 16:07:03 -0700 linda.s [EMAIL PROTECTED] wrote: Hi, I am a beginner in VIM. Wonder whether there is any good book for VIM? Also, what is the difference between vim and latex? Thanks, Linda I'm a beginner too, and I enjoy this best editor in the world very much. As for the book, I recommend Learning the vi by O'reilly! I got so much from that book! Yeah, if you want to learn vi, the underlying system of vim, this is a pretty good book. The author does a few things the vi way instead of the vim way, like the way he yanks with marks instead of with visual mode, but it's still a good start. But I think you would probably be fine with the tutorial as well. -fREW
Re: button t useless?
On 4/26/07, Yegappan Lakshmanan [EMAIL PROTECTED] wrote: Hi, On 4/26/07, zzapper [EMAIL PROTECTED] wrote: zzapper [EMAIL PROTECTED] wrote in news:[EMAIL PROTECTED]: alebo [EMAIL PROTECTED] wrote in news:[EMAIL PROTECTED]: In fact VIM has many features that appear redundant but then one day (perhaps after many years) you realise their utility. In fact I've found that there is usually (always?) a subtle advantage in using one or other of a command which apparently does the same thing, and that in different circumstances one or the other will be superior. eg When the cursor is in the middle of a word you wish to delete diw has a distinct advantage over bdw But what is it? The bdw command can be used to delete the current word only when the cursor is in the middle of the word. Also, this command cannot be used to delete single letter words. You have to then use 'x' to delete single letter words, 'dw' when the cursor is at the start of a word and 'bdw' when the cursor is not at the start of the word. The diw command can be used to delete the current word irrespective of the cursor position in the word and also to delete single letter words. This is particularly useful from a map command. - Yegappan The subject may have been beaten to death by now, but one thing that happens to me a lot that proves the usefulness of t is this: Say you have the following line of text: Computer.open_close(cdrom) if your cursor is on the o and you want to delete till the (, dt( will do the trick, whereas dfe will not unless you do it twice. Honestly, I use t more because it fits my mental model better, like tim was talking about. -fREW
Re: RAM issues
On 4/18/07, A.J.Mechelynck [EMAIL PROTECTED] wrote: fREW wrote: Does anyone know if vim uses less ram with nextaw, motif, or gtk, assume that none of the libraries are already loaded? -fREW I suppose the only way to know is to compile gvim with each of the three libraries and otherwise _exactly_ the same compile-time options. Note that this implicitly exclude some options which don't work with all three. Are you willing to try? You may avail yourself of my HowTo page for Unix if you want to: http://users.skynet.be/antoine.mechelynck/vim/compunix.htm Best regards, Tony. -- If anyone wants to trade a couple of centrally located, well-cushioned showgirls for an eroded slope 90 minutes from Broadway, I'll be on this corner tomorrow at 11 with my tongue hanging out. -- S. J. Perelman I am running Gentoo, so recompilation isn't a really big deal. How do I find out about memory consumption issues? -fREW
Re: Annoying insertion.
On 4/17/07, Tim Chase [EMAIL PROTECTED] wrote: With that knowledge, I'd go spelunking in the $VIMRUNTIME/ folders for the tex-related plugins/syntax/filetype files to see if there are map commands that should be nnoremap commands. Or perhaps you have some of your own additions under $HOME/.vim/ that might be bunging matters. -tim And what is the difference between map and nnoremap? Well, there's map, nmap and nnoremap. I tend to use nnoremap rotely because it's usually what I mean. map applies pretty much anywhere nmap applies only in normal mode nnoremap also applies only in normal mode, but prevents recursive expansion. Thus, if you did something like :nmap up gup you'd likely have problems because the up on the right-hand side (RHS) of the mapping again gets expanded to make it ggup which would then be expanded to gggup, ad infinitum. :nnoremap up gup prevents things on the RHS from expanding as additional mappings. The same applies to any of the *noremap commands. When I create a mapping, I generally mean do this list of things as if they are actual Vim commands, even if I accidentally overwrite one of its constituent parts with a new mapping. Each has its uses, but for my general uses, nnoremap is almost always what I mean, so I just type it and think later...or not at all :) :help recursive-mapping has more details on the matter. I inserted several map commands. Here is my list: :syntax on imap F3 C-O:!pdftex book.texCr map F3 :!pdftex book.texCr imap F4 C-O:!texexec book.tex /dev/nullCr map F4 :!texexec book.tex /dev/nullCr imap F5 C-O:!acroread book.pdfCr map F5 :!acroread book.pdfCr map F2 1GgqG imap F2 1GgqGi Do you see any that could be causing trouble? I noticed those in your *vimrc files, but didn't see anything among them that would have triggered the exact text you had in your original example (something about wqa or update or something like that). However, if some of the above text appears in your text at random, perhaps they are of a problematic ilk. There's no harm in changing them to more precise mappings (inoremap and nnoremap) to eliminate one possible source of problems. -tim I noticed your mappings for help with TeX stuff, and I thought you might want to check out Vim-LaTeX, if you haven't already. It can be found at http://vim-latex.sourceforge.net . The Tutorial (http://vim-latex.sourceforge.net/index.php?subject=manualtitle=Tutorial#tutorial) explains how to use it. I started using it for some Calculus stuff I have to write and it really saves me keystrokes and whatnot. It has conveniences for viewing and compiling as well. I highly recommend it. -fREW
Re: how to avoid deleting the auto-indent in a new empty line when i press Esc
On 4/16/07, Tom Whittock [EMAIL PROTECTED] wrote: What I need is to always keep the auto-indented spaces. So next time I can start to insert from the spaced cursor. Alternatively use cc to edit the ostensibly blank line. This will open the line using the correct auto indent. Get into this habit and it doesn't matter what state the line was in before - you always get the right indentation. Cheers. I tried cc and S and neither of them correctly reindented the line for me. What gives?
Re: let loaded_matchparen = 1
On 4/13/07, A.J.Mechelynck [EMAIL PROTECTED] wrote: Andre Majorel wrote: Are there any plans to make the highlight-the-matching-thing feature disabled by default in a future release of Vim ? AFAIK, there isn't; for one thing, it would break all the vimrc's which rely on its being set by default (and therefore don't force-set it). As your Subject line shows, you know how to remove that feature. Best regards, Tony. -- Sorry. I forget what I was going to say. Personally I like this feature, but I do get lost every now and then and forget which one is my cursor. Is there any way that I can say, make the cursor have a red background and make the matched paren (or whatever) have a blue background? And is there a way to do this that won't break if the background is already red/blue? -fREW
Re: copy pasting HTML code into vim
On 4/10/07, Jürgen Krämer [EMAIL PROTECTED] wrote: Hi, me wrote: actually, the selected HTML code might be available from the clipboard. E.g., both Firefox and Internet Explorer put it there in multiple formats. The following are lists of the available formats after copying from FF and IE, respectively: 49161: DataObject 49422: text/html 49366: HTML Format 49776: text/_moz_htmlcontext 49778: text/_moz_htmlinfo 13: CF_UNICODETEXT 1: CF_TEXT 49171: Ole Private Data 16: CF_LOCALE 7: CF_OEMTEXT 49161: DataObject 1: CF_TEXT 13: CF_UNICODETEXT 49366: HTML Format 49330: Rich Text Format 49171: Ole Private Data 16: CF_LOCALE 7: CF_OEMTEXT The formats starting with CF_ are pre-defined clipboard formats, the remaining ones are registered through Windows' RegisterClipboardFormat() function. I don't know how widely understood they are, but at least Microsoft Word is able to render headlines and other HTML-formatting instructions when text copied from Firefox is pasted into a document. It seems, the clipboard object associated with HTML Format contains enough information for correct rendering. A different point is how to access the HTML content in VIM. I doubt it would be a good idea to always paste the HTML source when accessing the clipboard through the + or * register. Probably a pasteclipboard() function which takes an argument for determining the preferred format would be a better way. This function function could then be used inside a mapping whenever a VIM user wants to paste the original HTML source. sorry, I forgot to mention explicitly that this is totally Microsoft Windows-centric. But I think other OSs might also support multiple formats on the clipboard. Regards, Jürgen -- Sometimes I think the surest sign that intelligent life exists elsewhere in the universe is that none of it has tried to contact us. (Calvin) Yeah, I know it is somehow available in linux, even though most of the time it drives me crazy. I will copy paste a bunch of stuff into OO and it will format it all the way it was on the site. I'll bet that this could be done with a vim plugin that used a small external tool to get the html data copied. I assume external because I don't know how you could use vim to get at that information, but with C/C++ or even some scripting language it could probably be done. -fREW
Re: Silly Question
On 4/7/07, Matthew Winn [EMAIL PROTECTED] wrote: On Fri, 06 Apr 2007 14:37:30 -0400, Mitch Wiedemann [EMAIL PROTECTED] wrote: I'm unlucky enough to have 'i' as the second letter in both my first and last names... So I get a jump to the middle of the screen, or to the first word in the line, and then boring ol' text insertion... I'm almost exactly the same, except that the end of my forename is placed one character to the right of yours. If I stick to lower case then it's a bit more interesting because the a becomes a mark, and the rest of my name makes the cursor stagger along the line without changing anything, ending up at the start of the word following the word containing the next t. Vowels are a problem. Unless you have an escape in your name, a, i and o are boring letters. I know someone named Veerle and her name is actually quite destructive, overwriting an entire line with l. What's the most interesting name anyone can find, and also the most damaging? -- Matthew Winn My realnames all do something boring: Arthur (Append rthur) Axel (Append xel) Schmidt (Replace line with chmidt) And my nickname is even sillier fREW (find an R, move to the end of a WORD, then move to the end of the next WORD.) So yeah, boring. -fREW
Re: Question about paragraphs: make lines containing only whitespace characters a paragraph separator
On 4/3/07, Thomas [EMAIL PROTECTED] wrote: Maybe I misunderstand the problem but can't you change those lines with just blanks to empty lines? Sure I can remove the whitespace characters. But I'd rather simply not have to care about them (but this is filetype-dependent because for some filetypes this really could be what I want). I was just wondering if there maybe already is a (buffer local) option to do this. Regards, Thomas. This is something that might be easier and better anyway. Recently on the list someone posted this little gem: autocmd BufRead,BufWrite * if ! bin | silent! %s/\s\+$//ge | endif That will erase any trailing whitespace whenever you save the file. --fREW
completion menu colors
Hi all, Is there a way to change the completion menu colors? -fREW
Re: completion menu colors
On 4/2/07, Peter Hodge [EMAIL PROTECTED] wrote: --- fREW [EMAIL PROTECTED] wrote: Hi all, Is there a way to change the completion menu colors? Change the highlighting options for the Pmenu* highlight groups: :hi Pmenu ctermfg=Cyanctermbg=Blue cterm=None guifg=Cyan guibg=DarkBlue :hi PmenuSel ctermfg=White ctermbg=Blue cterm=Bold guifg=White guibg=DarkBlue gui=Bold :hi PmenuSbar ctermbg=Cyanguibg=Cyan :hi PmenuThumb ctermfg=White guifg=White etc. The 'cterm*' settings are for colour terminal, the 'gui*' settings are for GUI. You can see all colour groups by using ':runtime syntax/hitest.vim', or in GUI Vim use the menu selection Syntax - Highlight Test. regards, Peter Are these things that should be set in the colorschemes, but just aren't yet because the names are new, or what? -fREW
Re: Project script
On 3/23/07, Mika Fischer [EMAIL PROTECTED] wrote: Hi Claus, * Claus Atzenbeck [EMAIL PROTECTED] [2007-03-23 13:20]: Thanks for your mail. \C works perfectly, however \R seems not to add recently created subdirectories. That's true. Is there a way to update a Project entry as if I would create a new entry with \C? Not that I know of. I tend to just create the new fold manually since it doesn't happen too often... I think the Project script is still maintained by Aric Blumer. I don't know if he reads this list, but it might be nice to ask him about it. Maybe he'll implement it... Regards, Mika He certainly responds to emails about bugfixes and did so for me just a few months ago, so it's worth a shot to email him. -- -fREW
Re: Plug-ins for C++ Development
On 3/22/07, Andreas Bakurov [EMAIL PROTECTED] wrote: Hi! What is a good set of plug-ins for vim in order to make it suitable for productive C++ editing for small programs (around 15-20 .cpp files). Navigation enhancements are helpful in such cases: * I need some kind of method tree where i can select methods quickly, * some enhancements for tag browsing and * maybe debugger(gdb) interface. Thank You in advance. omnicppcomplete ( http://vim.sourceforge.net/scripts/script.php?script_id=1520) can help with completion TagList (http://vim.sourceforge.net/scripts/script.php?script_id=273) is good for browsing methods and whatnot. You'll need to set up exuberant tags with it, but that's pretty easy. It shows how on the site. Project (http://vim.sourceforge.net/scripts/script.php?script_id=69) is really nice if you need to navigate through a bunch of different files. I have a special binding that will load a project file for each of my projects separately. So for instance I have a project called tome, to load the plugin for tome I do leadertome (\tome) and it will load the plugin and I can easily access any of the files for the project. Hope that helps! -- -fREW
Re: Consistently exit message display with 'q'?
On 3/20/07, A.J.Mechelynck [EMAIL PROTECTED] wrote: cga2000 wrote: On Mon, Mar 19, 2007 at 11:50:12PM EST, A.J.Mechelynck wrote: [..] more shows the colors with no problem. In general, I use: - less - when there is a long listing which I want to be able to scroll back and forth, or to search with a / command - not when there are interspersed ANSI-like escape sequences as in ls --color. [OT] You could try less -R. Works for me, although a quick look at the man page suggests this might not work under all circumstances: .. tries to keep track .. In any case I have aliased b as in browse to less -R -M and never had a problem. Thanks, cga Hey, nice! I'm going to alias less with /usr/bin/less -R in my bash startup scripts. Best regards, Tony. -- Megaton Man:LOOK at them! Helpless, tender creatures, relying on ME, waiting for ME to make my move! (from below): Move your ASS, Fat-head! Megaton Man:It is a MANDATE, and I am DUTY BOUND to OBEY! Another thing worth trying if you use something like zsh that supports global aliases is: alias -g L= | less -R which makes it so you can do: ls L Nifty, but if you use zsh, you probably already know that ;-) -fREW
inserting newlines
Hi all, I was recently discussing some features of vim that I use a lot with a friend and asking if he knew of ways to do certain things better, and one issue that both of us have is that we create newlines with o or O and then go back to normal mode immediately afterwards. So I often end up doing: oesc or Oesc where it would be nice to have a single key that would do this. Is there already such a feature, or should I just do something like nnoremap zj oEsc nnoremap zk OEsc I realize that zk and zj are still two keystrokes, but they are easier to type as it is. Thanks! -- -fREW
Re: Netrw go up dir command
Isn't a vimball just another archive? It seems, according to the vimball help file that it's just a bunch of inert files. It doesn't really run anything... Maybe I am wrong, though. -fREW On 3/16/07, Steve Hall [EMAIL PROTECTED] wrote: From: Charles E Campbell Jr, Fri, March 16, 2007 12:17 pm Please try netrw v108l which I just put on my website: http://mysite.verizon.net/astronaut/vim/index.html#NETRW Unfortunately these appear distributed in vimball format only. It is unrealistic to expect users to fire off a home-brewed executable simply to unpackage TEXT FILES! Age-old formats like tar.gz or .zip are still around precisely because they allow user control--simple inspection and evalutation without potentially modifying system files. -- Steve Hall [ digitect dancingpaper com ] -- -fREW
OmniCompletion for C#/.NET
Does anyone here know if there is anyone trying to set up omnicompletion for C#/.NET? I know that you can get vim for visual studio, but that doesn't work with the express editions, which is what I am stuck with when I code almost anywhere other than my personal computer. Thanks in advance! -fREW
Re: Case-sensitive match for :e under cygwin?
On 3/13/07, John Wiersba [EMAIL PROTECTED] wrote: When I use :e file* under cygwin (a Unix emulator running on Windows), I get an error saying E77: Too many filenames. But in fact there is only one such file. However, there are other files matching FILE*. How can I turn off this behavior so that vim under cygwin performs case-sensitive globbing? I've searched the vim help pages but can't seem to find it, if it exists. For comparison, bash has a nocaseglob option which, if set, matches filenames in a case-insensitive fashion when performing pathname expansion. P.S. Thanks for vim! Like thousands of other people, I use it everywhere: unix, windows, cygwin. :version VIM - Vi IMproved 7.0 (2006 May 7, compiled Oct 10 2006 10:07:11) Included patches: 1-122 Compiled by [EMAIL PROTECTED] Huge version without GUI. Features included (+) or not (-): +arabic +autocmd -balloon_eval -browse ++builtin_terms +byte_offset +cindent -clientserver -clipboard +cmdline_compl +cmdline_hist +cmdline_info +comments +cryptv +cscope +cursorshape +dialog_con +diff +digraphs -dnd -ebcdic +emacs_tags +eval +ex_extra +extra_search +farsi +file_in_path +find_in_path +folding -footer +fork() +gettext -hangul_input +iconv +insert_expand +jumplist +keymap +langmap +libcall +linebreak +lispindent +listcmds +localmap +menu +mksession +modify_fname +mouse -mouseshape +mouse_dec -mouse_gpm -mouse_jsbterm +mouse_netterm +mouse_xterm +multi_byte +multi_lang -mzscheme -netbeans_intg -osfiletype +path_extra -perl +postscript +printer +profile -python +quickfix +reltime +rightleft -ruby +scrollbind +signs +smartindent -sniff +statusline -sun_workshop +syntax +tag_binary +tag_old_static -tag_any_white -tcl +terminfo +termresponse +textobjects +title -toolbar +user_commands +vertsplit +virtualedit +visual +visualextra +viminfo +vreplace +wildignore +wildmenu +windows +writebackup -X11 -xfontset -xim -xsmp -xterm_clipboard -xterm_save system vimrc file: $VIM/vimrc user vimrc file: $HOME/.vimrc user exrc file: $HOME/.exrc fall-back for $VIM: /usr/share/vim Compilation: gcc -c -I. -Iproto -DHAVE_CONFIG_H -g -O2 Linking: gcc -L/usr/local/lib -o vim.exe -lncurses -liconv -lintl ___ We won't tell. Get more on shows you hate to love (and love to hate): Yahoo! TV's Guilty Pleasures list. http://tv.yahoo.com/collections/265 I hope I am not speaking prematurely here, but I really think that this has more to do with the underlying Windows Filesystem stuff. As you probably know the files in windows are NOT case sensitive and I think that vim is probably using some form of Filesystem globbing, which would find both file1 and FILE2. On the other hand I remember reading about a cygwin feature that would allow you to have funky filenames not supported by windows in a cygwin partition (just escapes in the filenames really) that might change things. This is where I read about the cygwin filename stuff: http://gentoo-wiki.com/HOWTO_Gentoo_on_Cygwin#.22Managed.22_mounts I hope that helps! -fREW -- -fREW
Re: How to paste without replace the content in buffer
I think that the best way to do this is just with registers. So what you would do is: vhighlight regionay vhighlight regionap what this does is use the a register to yank to/put from. For more info see :help y and :help p On 3/10/07, Peng Yu [EMAIL PROTECTED] wrote: Hi, Suppose I want to replace string1 with string2 in a file from vim. 1. Highlight string1 (in visual mode) and then type y. 2. Highlight string2 (in visual mode) and then type p. However, the problem with the above procedure is that string2, instead of string1, is in buffer. That is if I highlight string3 and then type p, string3 will be replaced with string2 instead of string1. I'm wondering if there is any way to avoid change the content in the buffer? Thanks, Peng -- -fREW
rotation
Does anyone know if there are any builtin commands to rotate the current line about a character or word? Example: rotate about the j and just respectively 'This is just a test ' becomes 'ust a testj This is' 'This is just a test' becomes 'a test just This is' I know it would be pretty easy to do these with macros, but I thought there might be some builtin or something. Thanks! -- -fREW
Re: rotation
Cool! Thanks Tim and A.J.
And yeah, sorry about the typo with 'ust a test jThis is ', I meant
to include that space.
And I use Vim7 so I can use any extensions that may have been added then.
Thanks again!
-fREW
On 3/7/07, Tim Chase [EMAIL PROTECTED] wrote:
Does anyone know if there are any builtin commands to rotate
the current line about a character or word?
I know it would be pretty easy to do these with macros, but I
thought there might be some builtin or something.
There's nothing built-in, but you can map something of the like:
rotate about the j and just respectively
'This is just a test ' becomes 'ust a testj This is'
According to your description of what rotating should do,
rotating around the j in this example would yield
'ust a test jThis is '
rather than
'ust a testj This is'
but can be done with
:nnoremap gw :s/^\(.*\)\%#\(.\)\(.*\)$/\3[\2]\1cr
'This is just a test' becomes 'a test just This is'
This can be done with:
:nnoremap gW :s/^\(.\{-}\)\(\s*\\w*\%#\w*\s*\)\(.*\)$/\3\2\1cr
Though somewhat funky things happen if you're in whitespace
rather than over Word characters.
I don't recall if the \%# was added in Vim7 or if it works in
prior versions. YMMV.
HTH,
-tim
