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: 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: 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: 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: collapsing single lines of html tag attributes via plugin??
On 6/1/07, Charles E Campbell Jr <[EMAIL PROTECTED]> wrote: Howard Glynn wrote: > > > 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 > 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 ;) > 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: 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 > > 1GVG > > 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 "y"anking 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: 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: 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: 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: 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: 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: 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: 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 c&p (^A^X from LO) to 'vim' (shift-), then :g/^> /s//> :g/^./s//>& gqap(per paragraph, iirr) then c&p 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: 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: 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: 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: 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: 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: 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
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/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: 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 (:w ...) 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: 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: 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, 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 ("[A" > and "[B"). Wouldda thought the 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, 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 ("[A" and "[B"). Wouldda thought the 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, 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
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: 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 : 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: launching vim from eclipse
On 5/17/07, y m <[EMAIL PROTECTED]> wrote: In Visual Studio, you can use the visvim ole plugin to open the currently displayed file in vim. Is there a similar plugin available for eclipse? I see that there is a viPlugin for eclipse which lets you edit files directly in eclipse using vi keystrokes. However, I want to externally launch vim from eclipse since I have many customizations in vim which the viPlugin does not support. Thank you. I am pretty sure you can set it up in the setting somewhere. It ends up with you right-clicking the file and then clicking open with gvim in the menu. -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 - 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/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: 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: 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: > wl > 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 - 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: 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(":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
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: wl zM zr Thanks! -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 VimTip 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 around the brackets. Also, I think that for the most part '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
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 - 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, 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 VimTip 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, 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: 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 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: 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 "*" 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 "*" did. I also wish I had known earlier...Using the "*" key while in normal mode searches for the word under the cursor.If 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: 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 . 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: 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, my name 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: 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
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, my name is fREW. I presume it will have something to do with using '< and '>, but beyond that I am not really sure. Thanks! -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\ In gvim, I get the following: :e $HOME\ which expands to :e c:\Documents\ and\ Settings\\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\ just fine. Chris -- Chris Sutcliffe http://ir0nh34d.googlepages.com http://ir0nh34d.blogspot.com http://emergedesktop.org
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: Mapping to and doesn't work
On 4/25/07, Tim Chase <[EMAIL PROTECTED]> wrote: > I'm running vim in a console using gnome-terminal. I put these > mappings in my .vimrc file: > > map :mksession! ~/.vim/.session > map :source ~/.vim/.session > > Pressing those buttons (CTRL+Q or CTRL+S) doesn't work. When I map as > below instead: > > map :mksession! ~/.vim/.session > map :source ~/.vim/.session > > the commands work. > > What is causing this behavior? Is it the terminal capturing the CTRL+Q > and CTRL+S keystrokes before they reach VIM? Yes, the ^S and ^Q keystrokes are flow-control characters. I don't have Gnome-term on hand, but it works much the same in other terminal emulators (xterm, rxvt, etc). Control+S is the "hey, stop sending stuff to this terminal until I have a chance to catch up" character, and Control+Q is the "okay, I've caught up, you can start sending stuff to my terminal again" character. The terminal software may catch these before Vim gets a chance to see them. You might poke around in your GT settings for a setting like "flow control" or "XON/XOFF" and try to disable that. It's not like your terminal runs on an 8-bit processor with 16 bytes of buffer for your serial-I/O terminal any more where a speedy 2400-baud modem might overwhelm your terminal's ability to draw on the screen. ;) -tim There may be a way to change the XON/XOFF keystrokes, but in the past I have found that it is too much work to be worth the effort. I would suggest trying different keystrokes that don't already have meaning. -fREW
Re: RAM issues
On 4/18/07, A.J.Mechelynck <[EMAIL PROTECTED]> wrote: fREW wrote: > 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 > It may depend on which (X11) GUI you have installed: with kde, run ksysguard; with Gnome, run gnome-system-monitor; then in either of these, look at the "Processes" tab. You may have to run the gvim versions one-by-one in order to be able to distinguish them -- unless you give the executables (or the links pointing to them) different names such as gvim-nextaw, gvim-motif, gvim-gtk, etc. Best regards, Tony. -- In Corning, Iowa, it's a misdemeanor for a man to ask his wife to ride in any motor vehicle. Are there any general tools that will do this? I don't use KDE or Gnome. -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
RAM issues
Does anyone know if vim uses less ram with nextaw, motif, or gtk, assume that none of the libraries are already loaded? -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 g you'd likely have problems because the on the right-hand side (RHS) of the mapping again gets expanded to make it "gg" which would then be expanded to "ggg", ad infinitum. :nnoremap g 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 :!pdftex book.tex > map :!pdftex book.tex > imap :!texexec book.tex >/dev/null > map :!texexec book.tex >/dev/null > imap :!acroread book.pdf > map :!acroread book.pdf > map 1GgqG > imap1GgqGi > > 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=manual&title=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
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
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
completion menu colors
Hi all, Is there a way to change the completion menu colors? -fREW
Re: two questions , map and scroll
On 3/27/07, Andy Wokula <[EMAIL PROTECTED]> wrote: shawn bright schrieb: > lo there, > > i have two quick questions. > first, is there a way i can scroll text under the cursor ( so that the > cursor stays on the same place in the terminal, but the text scrolls > anyway ) > i just think that would be really cool. Without mappings: " keep cursor in same column :set nostartofline " global, also has influence on other commands " how many lines to scroll :set scroll=1 " local to window Then use Ctrl-D and Ctrl-U. A count changes the value of 'scroll'. Don't miss the help: :h 'sol :h 'scr -- Regards, Andy EOM What I would do for the rails stuff (and what I actually do for Template Toolkit w/ perl) is use abbreviations. For example: :ab RLS <% %>^]hhi :ab RL= <%= %>^]hhi That way when you type RLS(space) it will put you inside the brackets automatically. Note: the ^] is a literal, so to type it you need to do . -- -fREW
Re: Keep cursor fixed when scrolling with mouse
Just so you know, the exact way to use marks in this situation (as Yakov had mentioned) would be to do this: ma'a 'a can be replaced with `a also. The former (') goes to the line you were at when you pressed ma (set a mark at a) and (`) goes to the specific character that you marked. Hope that helps! -- -fREW
Re: Customizing vim: How to change the char before commands
So is there a way we could swap the ; and : keys? I hardly ever use ";" but it would be nice to still have it available as : -- -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 tome (\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
Re: Updated Windows installer 7.0.219
On wtorek 20 marzec 2007, vim@vim.org wrote: > firewall our build machine sits behind. So I'm open to solutions for > how to remove obsoletes from the file set. I had considered deleting > the oldest files, but in most cases (such as the current) the files to > be removed are generally newer than the rest. The best I can do is to > occasionally delete the whole set and re-download, but with the new > spelling dictionaries, this is 200+ MB each time and I hate to waste > the bandwidth. Suggestions? Put that on users bandwidth -> let download dictionaries during install from Vim page, distribute only English dicts. Dictionary can be downloaded later even when trying to use particular dictionary. m. That's a good call. And if you give them the option of which dictionaries to install you can save even more. -- -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: o or O 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 o nnoremap zk O 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
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
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: Maximize gvim at startup
What you may want to do is look into your GNOME documentation. Most window managers have options on what to do with certain apps when they run. For instance I have firefox load in one virtual desktop, and I have amaroK load in another, and I have eclipse run fullscreen. Surely there are options similar to that for whatever GNOME uses nowadays (metacity?). -fREW On 3/13/07, Mr. Shawn H. Corey <[EMAIL PROTECTED]> wrote: Hi, I'm running Ubuntu 6.10 on a PowerBook 4 under GNOME. Is there any command I can put inn my .gvimrc that will maximize the window at startup? I tried: :autocmd GUIEnter * simalt But simalt does not work in Linux. I may not know much about GUIs but ever one I read so far has an API call that maximizes the window. So, what's the best way to do this?
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: v"ay v"ap 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
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]\1 > '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\1 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
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