GSoC Regexp engine
Hi all, I'm Ian, one of the two students working on improving the regexp engine in Vim for this year's Google Summer of Code. I haven't had a whole lot to contribute as of yet, but now that work is underway, I'll probably pop up here asking lots of questions some days. Right now we're working on getting things set up and building a testing suite, but I thought I would spark some discussion on a design decision that will be coming up after we finish this phase, which is whether to implement the new model ourselves, or use an alternative engine, like TRE: http://laurikari.net/tre/. I'm tempted to implement one ourselves, as it's an intellectually stimulating prospect, but that doesn't mean I won't listen to reason if TRE or another option is far better. I don't know much about the internals of TRE, but according to previous posts to this list, it utilizes three engines: a slow one for handling backreferences (presumably similar to Vim's current engine), a fast one for most cases (what we are looking to implement), and one for their 'fuzzy matching' feature. I have a couple questions to start things off. First: I couldn't see much need for 'fuzzy matching' in Vim, but some of you are probably much better acquainted with regexp use cases than I am. Would this be a useful feature to have available? Second: We might have to do some gymnastics to work with multibyte characters, as discussed here: http://tech.groups.yahoo.com/group/vimdev/message/46408. I haven't worked with multibyte characters before, so I'm not clear on the subtleties. Would this translation to wide characters before passing to the engine cause much of a performance hit and/or be excessively complicated to implement? On a side note, TRE's main page says it has both wide character and multibyte character support. I couldn't find a version history, so I'm not sure if this is a new feature that Nikolai isn't aware of, or if we need something more. I'm interested to hear what you all have to say. We don't need to make this decision until middle of next week at the earliest, but I thought I would get the discussion going now. Ian
Re: GSoC Regexp engine
I have also heard good things about the PCRE (Perl Compatible Regex Library). You may want to consider it as an option. http://www.pcre.org/ -Brian On 5/31/07, Ian Young [EMAIL PROTECTED] wrote: Hi all, I'm Ian, one of the two students working on improving the regexp engine in Vim for this year's Google Summer of Code. I haven't had a whole lot to contribute as of yet, but now that work is underway, I'll probably pop up here asking lots of questions some days. Right now we're working on getting things set up and building a testing suite, but I thought I would spark some discussion on a design decision that will be coming up after we finish this phase, which is whether to implement the new model ourselves, or use an alternative engine, like TRE: http://laurikari.net/tre/. I'm tempted to implement one ourselves, as it's an intellectually stimulating prospect, but that doesn't mean I won't listen to reason if TRE or another option is far better. I don't know much about the internals of TRE, but according to previous posts to this list, it utilizes three engines: a slow one for handling backreferences (presumably similar to Vim's current engine), a fast one for most cases (what we are looking to implement), and one for their 'fuzzy matching' feature. I have a couple questions to start things off. First: I couldn't see much need for 'fuzzy matching' in Vim, but some of you are probably much better acquainted with regexp use cases than I am. Would this be a useful feature to have available? Second: We might have to do some gymnastics to work with multibyte characters, as discussed here: http://tech.groups.yahoo.com/group/vimdev/message/46408. I haven't worked with multibyte characters before, so I'm not clear on the subtleties. Would this translation to wide characters before passing to the engine cause much of a performance hit and/or be excessively complicated to implement? On a side note, TRE's main page says it has both wide character and multibyte character support. I couldn't find a version history, so I'm not sure if this is a new feature that Nikolai isn't aware of, or if we need something more. I'm interested to hear what you all have to say. We don't need to make this decision until middle of next week at the earliest, but I thought I would get the discussion going now. Ian
Re: GSoC Regexp engine
On 5/31/07, Brian Gupta [EMAIL PROTECTED] wrote: I have also heard good things about the PCRE (Perl Compatible Regex Library). You may want to consider it as an option. PCRE is crap. It is crap, because it uses the same, crappy, backtracking method that Vim, and most other crappy regex (note: not regular expression) libraries use, which is exactly the kind of crap that this GSoC project is aiming to scrap. nikocrap
Re: GSoC Regexp engine
On 5/31/07, Ian Young [EMAIL PROTECTED] wrote: I'm Ian, one of the two students working on improving the regexp engine in Vim for this year's Google Summer of Code. I haven't had a whole lot to contribute as of yet, but now that work is underway, I'll probably pop up here asking lots of questions some days. Right now we're working on getting things set up and building a testing suite, but I thought I would spark some discussion on a design decision that will be coming up after we finish this phase, which is whether to implement the new model ourselves, or use an alternative engine, like TRE: http://laurikari.net/tre/. I'm tempted to implement one ourselves, as it's an intellectually stimulating prospect, but that doesn't mean I won't listen to reason if TRE or another option is far better. I don't know much about the internals of TRE, but according to previous posts to this list, it utilizes three engines: a slow one for handling backreferences (presumably similar to Vim's current engine), a fast one for most cases (what we are looking to implement), and one for their 'fuzzy matching' feature. I have a couple questions to start things off. First: I couldn't see much need for 'fuzzy matching' in Vim, but some of you are probably much better acquainted with regexp use cases than I am. Would this be a useful feature to have available? Second: We might have to do some gymnastics to work with multibyte characters, as discussed here: http://tech.groups.yahoo.com/group/vimdev/message/46408. I haven't worked with multibyte characters before, so I'm not clear on the subtleties. Would this translation to wide characters before passing to the engine cause much of a performance hit and/or be excessively complicated to implement? On a side note, TRE's main page says it has both wide character and multibyte character support. I couldn't find a version history, so I'm not sure if this is a new feature that Nikolai isn't aware of, or if we need something more. It supports * Byte matching, that is, raw bytes * Wide characters, that is, whatever wchar_t is * Multi-byte characters, thas is, whatever mbrtowc supports * Streams that is, objects that feed TRE characters as it needs them It would be pretty easy to set up a stream object that would feed TRE characters. It would only have to keep track of where it was in the buffer and basically request more of the buffer as TRE needs it. It should be noted that there are quite a few bugs in TRE that relate to the interaction of quantifiers. I have discussed this privately with Ville, but neither of us has been able to resolve it. It has also been discussed here: http://laurikari.net/pipermail/tre-general/2007-February/thread.html where Chris Kuklewicz suggests a solution to the problem that seems to work. It is a somewhat costly solution, but it may be worth it in all its simplicity. Chris has written an implementation of TDFAs for Haskell that is quite simple and manages to both outperform all other regex libraries for Haskell and still pass all POSIX tests. Here's the announcement: http://www.mail-archive.com/[EMAIL PROTECTED]/msg11442.html This will, sadly, be of no use to us, but it does show that TDFAs are a possibility, and that the problems TRE has with quantifiers can be resolved. Anyway, fuzzy matching, it seems like this is a feature that never really caught on. Agrep has long enjoyed the status of being one of the few commands that remain to be implemented for the GNU project (can't seem to find the list right now, so I can't provide a link). This does, however, seem to indicate that no one has cared enough about it to implement and distribute it with GNU. It can be a quite interesting thing to have, but it's perhaps not useful enough to care about at this stage. Also, you won't have time to implement this yourself. Seriously. It takes a lot of work to write an efficient and as-compatible-as-possible implementation implementation and a summer isn't nearly enough time to complete said work. I think that what's most important here is to set up a test suite and the code required to interface with a library, such as TRE. That way one can always hook in another library when it gets written. Finally, good to hear from you. I think we all look forward to being able to enjoy the fruits of your hard labor ;-). nikolai
Re: GSoC Regexp engine
Ian Young wrote: I have a couple questions to start things off. First: I couldn't see much need for 'fuzzy matching' in Vim, but some of you are probably much better acquainted with regexp use cases than I am. Would this be a useful feature to have available? As you likely know, fuzzy matching hasn't been available in Vim. One place it has been useful is in suggesting spelling corrections; I myself used agrep in the engspchk.vim plugin to support fuzzy matching. Bram already has a spelling error suggestion feature, so I have no idea if the fuzzy regex would help with it or not. What I think could be more useful would be boolean logic for regexp. My LogiPat plugin provides this capability, but undoubtedly it'd be better if somehow it could be incorporated. The resulting patterns from LogiPat seem to me to be somewhat opaque. Regards, Chip Campbell
Re: GSoC Regexp engine
On 5/31/07, Charles E Campbell Jr [EMAIL PROTECTED] wrote: What I think could be more useful would be boolean logic for regexp. My LogiPat plugin provides this capability, but undoubtedly it'd be better if somehow it could be incorporated. The resulting patterns from LogiPat seem to me to be somewhat opaque. What would be even cooler would be to use regular relations, as that would allow for far superior substitution possibilities to what :substitute has to offer. I've long considered writing a text editor around regular relations, and was actually hoping to get a Ph.D. based on using regular relations in interactive processes, but that sadly never happened. nikolai
Re: GSoC Regexp engine
On 5/31/07, Nikolai Weibull [EMAIL PROTECTED] wrote: What would be even cooler would be to use regular relations, as that would allow for far superior substitution possibilities to what :substitute has to offer. (Someone asked off-list what regular relations were. If anyone else is interested, here's what I responded with.) Here are some papers on regular relations: http://citeseer.comp.nus.edu.sg/karttunen95replace.html http://citeseer.comp.nus.edu.sg/karttunen96regular.html Also see http://www.xrce.xerox.com/competencies/content-analysis/fst/home.en.html nikolai P.S. Please don't top-post. D.S.
Defining new visual-mode motions?
Hello, all.
I was recently helping someone out with a vim script (camelcasemotion.vim)
which adds additional motion commands (they treat camel-cased words
(WordsLikeThis) as separate words, rather than as a single word). This is
easy enough to do in normal and operator-pending mode. It seems to be very
complicated to do this in visual mode, though -- calling a function (or
anything that lets you move the cursor) seems to force you to leave visual
mode (i.e., doing `vmap ,w :C-Ucall MoveCursor()` will move the cursor to
the right place, but you're no longer in visual mode).
My approach to this was to call the movement function, set a mark, select
the previous visual block (with gv) and then jump to the mark that was
previously set. The mapping that I created to deal with this is the
following:
vmap silent ,w @=\33:\25call
SIDCamelCaseMotion('w',1,'v')CRCRm`gvg``
This seems somewhat inelegant, and also clobbers a mark to be able to
accomplish its magic. Is there an easier way to accomplish the same thing?
It seems like there should be, but I was unable to figure one out.
Thanks for your help.
JKB
Re: confirm unsubscribe from vim-dev@vim.org
On 1 Jun 2007 05:59:49 -, [EMAIL PROTECTED] wrote: Hi! This is the ezmlm program. I'm managing the vim-dev@vim.org mailing list. To confirm that you would like [EMAIL PROTECTED] removed from the vim-dev mailing list, please send an empty reply to this address: [EMAIL PROTECTED] Usually, this happens when you just hit the reply button. If this does not work, simply copy the address and paste it into the To: field of a new message. I haven't checked whether your address is currently on the mailing list. To see what address you used to subscribe, look at the messages you are receiving from the mailing list. Each message has your address hidden inside its return path; for example, [EMAIL PROTECTED] receives messages with return path: vim-dev-return-number[EMAIL PROTECTED] Some mail programs are broken and cannot handle long addresses. If you cannot reply to this request, instead send a message to [EMAIL PROTECTED] and put the entire address listed above into the Subject: line. --- Administrative commands for the vim-dev list --- I can handle administrative requests automatically. Please do not send them to the list address! Instead, send your message to the correct command address: To subscribe to the list, send a message to: [EMAIL PROTECTED] To remove your address from the list, send a message to: [EMAIL PROTECTED] Send mail to the following for info and FAQ for this list: [EMAIL PROTECTED] [EMAIL PROTECTED] Similar addresses exist for the digest list: [EMAIL PROTECTED] [EMAIL PROTECTED] To get messages 123 through 145 (a maximum of 100 per request), mail: [EMAIL PROTECTED] To get an index with subject and author for messages 123-456 , mail: [EMAIL PROTECTED] They are always returned as sets of 100, max 2000 per request, so you'll actually get 100-499. To receive all messages with the same subject as message 12345, send an empty message to: [EMAIL PROTECTED] The messages do not really need to be empty, but I will ignore their content. Only the ADDRESS you send to is important. You can start a subscription for an alternate address, for example [EMAIL PROTECTED], just add a hyphen and your address (with '=' instead of '@') after the command word: [EMAIL PROTECTED] To stop subscription for this address, mail: [EMAIL PROTECTED] In both cases, I'll send a confirmation message to that address. When you receive it, simply reply to it to complete your subscription. If despite following these instructions, you do not get the desired results, please contact my owner at [EMAIL PROTECTED] Please be patient, my owner is a lot slower than I am ;-) --- Enclosed is a copy of the request I received. Return-Path: [EMAIL PROTECTED] Received: (qmail 31011 invoked from network); 1 Jun 2007 05:59:49 - Received: from unknown (HELO avmail.wilbury.sk) (81.89.56.24) by foobar.math.fu-berlin.de with SMTP; 1 Jun 2007 05:59:49 - Received: from avmail.ltc.sk (avmail.ltc.sk [81.89.56.18]) by avmail.wilbury.sk (Postfix) with ESMTP id 1B31C131DC for [EMAIL PROTECTED]; Fri, 1 Jun 2007 06:53:56 +0200 (CEST) X-Virus-Scanned-ltcavmail: amavisd-new at ltc.sk Received: from avmail.wilbury.sk ([81.89.56.24]) by avmail.ltc.sk (avmail.ltc.sk [81.89.56.18]) (amavisd-new, port 12425) with ESMTP id KiKjn+6Xn0hZ for [EMAIL PROTECTED]; Fri, 1 Jun 2007 06:53:55 +0200 (CEST) Received: from hathor.lasermount.plus.com (lasermount.plus.com [212.159.61.82]) by avmail.wilbury.sk (Postfix) with ESMTP id 93F42131CB for [EMAIL PROTECTED]; Fri, 1 Jun 2007 06:53:19 +0200 (CEST) Received: from hathor.lasermount.plus.com (localhost [127.0.0.1]) by hathor.lasermount.plus.com (Postfix) with ESMTP id 451EEC2650 for [EMAIL PROTECTED]; Fri, 1 Jun 2007 05:53:17 +0100 (BST) Date: Fri, 1 Jun 2007 05:53:16 +0100 From: Spencer Collyer [EMAIL PROTECTED] To: [EMAIL PROTECTED] Message-ID: [EMAIL PROTECTED] Organization: Lasermount Limited X-Mailer: Claws Mail 2.7.2 (GTK+ 2.10.6; x86_64-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit -- Eagles may soar, but weasels don't get sucked into jet engines 6:13am up 93 days 12:56, 17 users, load average: 2.88, 2.72, 1.65 Registered Linux User #232457 | LFS ID 11703
Re: No Previous Regular expression
On Thu, May 31, 2007 at 03:52:29AM +0200, A.J.Mechelynck wrote: Tim Johnson wrote: Using vim 7.0 on kubuntu 7.04 (feisty fawn amd 64) I've recently migrated from vim 6-something on slack 10.0 On my previous version and box, if I searched on an expression in one file, closed it and opened another, n would continue with the search. Now, I get an E35: No previous regular expression. I've imported all of my previous settings, .vimrc etc... so I don't know how to correct this. 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'. And since this is Ubuntu... .viminfo probably got owned by root and therefore it is not writable, as was discussed in the recent thread. Yeti -- http://gwyddion.net/
Re: plugins in vim 7.1
Tushar Desai [EMAIL PROTECTED] 写于 2007-05-31 13:51:28: I recently upgraded from vim 7.0 to vim 7.1 (on ubuntu feisty) by compiling the vim7.1 tarball. Did you make install from the tarball? If compiled from tarball, the prefix defaults to /usr/local, while the ubuntu official version will be in /usr The plugins are located at /usr/local/share/vim/vim71/plugins. This is not the right place to place your plugins, a better approach is to put it into your ~/.vim/plugins HTH. -- Sincerely, Pan, Shi Zhu. ext: 2606
Re: JSVI: Vi implemented in Javascript
On Wed, 30 May 2007 14:21:27 -0400, 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 Unfortunately, in Opera it detects shift-presses as extra keys in their own right instead of modifiers, so something like :%s/a/b/g fails because the % is preceded by the extra character. I once created a single-line emulation of vi in Perl for a terminal- oriented program I was writing. It's surprising how little code you need to implement the basic editing commands. I think it's because once you've provided w to move to the next word you get cw and dw almost for free, and so on for other movements. -- Matthew Winn
[Fwd: Re: No Previous Regular expression]
Forward to list.
Best regards,
Tony.
Original Message
Subject: Re: No Previous Regular expression
Date: Wed, 30 May 2007 20:02:36 -0700
From: [EMAIL PROTECTED]
To: A.J.Mechelynck [EMAIL PROTECTED]
References: [EMAIL PROTECTED] [EMAIL PROTECTED]
Quoting A.J.Mechelynck [EMAIL PROTECTED]:
Tim Johnson wrote:
Using vim 7.0 on kubuntu 7.04 (feisty fawn amd 64)
I've recently migrated from vim 6-something on slack 10.0
On my previous version and box, if I searched on an expression
in one file, closed it and opened another, n would continue
with the search.
Now, I get an E35: No previous regular expression.
I've imported all of my previous settings, .vimrc etc...
so I don't know how to correct this.
[snip]
If you close and reopen Vim, the last search pattern is remembered -- or not
-- in the viminfo file. (It is one of the registers.) [snip]
I suspect that you edited a system file for your settings instead of a
$HOME/.vimrc (or %HOME%\vimfiles). Vim system files are under vim6x/... and
are provided by the vim installation process. When you upgraded to vim7.0 (the
latest is vim7.1, BTW) any customizations you did under vim6x/ are no longer
effective.
Try:
vim
:echo $HOME
to see where your home directory is... and edit a .vimrc file there. Put
set nocp
if version = 600
filetype plugin indent on
endif
set viminfo=!,'10,\100,:20,%,nc:\\WINDOWSPATHHERE\\_viminfo
or
set viminfo=!,'25,\100,:20,%,n~/.viminfo
(latter setting for linux/unix).
And, while I'm at it, here's a snippet to restore cursor position:
Restore position in file: if previously edited (uses viminfo) {{{1
David Fishburn mod: use zv to open folds on current line, but after having
read the modelines.
augroup RestorePosition
au!
au BufReadPost * if line('\) 0|if line('\) = line($)|exe norm
g`\|else|exe norm $|endif|endif
au BufWinEnter * norm! zv
augroup END
HTH,
Chip Campbell
how to ..... compiler
Hi There, I can't make use of built-in compiler facility in vim. Tried the help files(quickfix and FAQ) as well but couldn't get much about the same. I want to compile a project, where the files are distributed among different directories. I have my own makefile but want to make use of vim's facility for the same ( much like turbo C where U get a spilte window where errors are marked). Further I came across a script http://www.vim.org/scripts/script.php?script_id=213 which provides similar kinda utility about the same. But again not much details mentioned in the doc file(csupport.txt) about external make. How can I run my makefile(external) within vim. Further How to check and add ,if missing, compiler support in vim( say HP-UX xompiler aCC). I'm using Console version of vim via putty. Regards, Jagpreet
Re: OT: Vi in a browser...
Edward L. Fox wrote: [...] A friend told me that he is developing a Firefox addon to emulate the Vi/Vim behaviors in all text areas in Firefox, without launching external applications. I'm looking forward to it. [...] I don't think any Vim extension aiming at reproducing Vim's behaviour without actually calling it, will be able to come near the result of the gazillions of man-hours Bram (with a few others) has put and is still putting into it. Many browsers are able to interact with any external editor (such as true-blue Vim) these days, which also means that any bugfix or improvement to Vim gets reflected in the editing behaviour of the browser. Or you could always write the text in Vim, then use the clipboard to paste it into the browser, even with no special external editor function. YMMV. Best regards, Tony. -- A cow comes flying over the battlements, lowing aggressively. The cow lands on GALAHAD'S PAGE, squashing him completely. Monty Python and the Holy Grail PYTHON (MONTY) PICTURES LTD
Re: plugins in vim 7.1
[EMAIL PROTECTED] wrote: Tushar Desai [EMAIL PROTECTED] 写于 2007-05-31 13:51:28: I recently upgraded from vim 7.0 to vim 7.1 (on ubuntu feisty) by compiling the vim7.1 tarball. Did you make install from the tarball? If compiled from tarball, the prefix defaults to /usr/local, while the ubuntu official version will be in /usr The plugins are located at /usr/local/share/vim/vim71/plugins. This is not the right place to place your plugins, a better approach is to put it into your ~/.vim/plugins This _is_ the right place for plugins distributed with Vim, like the one to highlight matching parentheses (matchparen.vim)... except that there should be no s at the end of $VIMRUNTIME/plugin/ make install would indeed have created all the runtime directories exactly where the version which make compiled just before that would expect them. HTH. -- Sincerely, Pan, Shi Zhu. ext: 2606 HTH, Tony. -- Don't get suckered in by the comments -- they can be terribly misleading. Debug only code. -- Dave Storer
starting a second vim session in diff mode from out first vim
Hi, Is it possible from a first gvim session to init a second gvim session in diff mode? And this diff mode should then use the two files that are used in the first gvim session? So if A.TXT and B.TXT are used in the first, the second should show the difference in the second gvim session? Rgds, Eric
Scrolling marquee text on vim status bar
HI Vimmers, Is it possible to have a horizontal text to run horizontally on marquee ? regards, Srini...
copying text char-by-char from the line above line..
Hi All, I saw one of my friends (once!) copying the text from the line right above. He was using some keycombo and it would appear like he was copying the characters one-by-one. So, if there are two lines like quick brown fox I see and on the 2nd line, after 'see', i wanted to copy 'brown fox' from the 1st line, I will just keep pressing that keycombo 9 times. I know how to copy the full line, text till some character, etc. But, I was just wondering how to do the above. Does anybody know how to do this? thanks... Ajay
Re: copying text char-by-char from the line above line..
Le 31 mai 07 à 15:14, Ajay Gupta a écrit : Hi All, I saw one of my friends (once!) copying the text from the line right above. He was using some keycombo and it would appear like he was copying the characters one-by-one. So, if there are two lines like quick brown fox I see and on the 2nd line, after 'see', i wanted to copy 'brown fox' from the 1st line, I will just keep pressing that keycombo 9 times. I know how to copy the full line, text till some character, etc. But, I was just wondering how to do the above. Does anybody know how to do this? thanks... Ajay Hi, first you do the following : - go on the second line - press 'qq' start to record in q register - then 'k0xj$p' the motion to iterate - finally 'q'leave register recording then to use the register, do : - go on the second line - press '@q' - iterate until the full line is copied (as usual you can use eg. [EMAIL PROTECTED] to iterate 5 times in once) More on registers with ':help complex-repeat' Vincent
Re: copying text char-by-char from the line above line..
Ajay Gupta schrieb: Hi All, I saw one of my friends (once!) copying the text from the line right above. He was using some keycombo and it would appear like he was copying the characters one-by-one. So, if there are two lines like quick brown fox I see and on the 2nd line, after 'see', i wanted to copy 'brown fox' from the 1st line, I will just keep pressing that keycombo 9 times. I know how to copy the full line, text till some character, etc. But, I was just wondering how to do the above. Does anybody know how to do this? thanks... Ajay :h i_Ctrl-Y -- Regards, Andy
good keys for mappings
Hi, Any suggestions on keys/key combos that are good candidates for custom mappings etc? Maybe a dumb question but I hate having to unlearn something, I'd like to create a fair number of mappings that use a consistent convention and won't conflict with anything existing. I think Bram mentioned he's found prefixing with _ works well.. thanks
Re: good keys for mappings
Any suggestions on keys/key combos that are good candidates for custom mappings etc? [snip] I think Bram mentioned he's found prefixing with _ works well.. I believe that the backslash (\) is the only stand-alone lower-ASCII character available for mappings, and thus is the default map-leader (:help mapleader). Depending on your vim environment, control+S and control+Q are also available, but on console versions, they ofter mess with your flow-control so they're not quite as portable. There are a family of characters which mostly duplicate behavior of other keys, and thus are good candidates if you want them. Such characters include the underscore (as you mentioned), the plus, the minus, the enter key and control+M/control+J. These characters mostly navigate up or down with tweaks regarding how they treat counts, and how they behave column-wise. (Always a bit like my understanding of the kama-sutra...#58 is the same as #42, only you cross your fingers) Fortunately, Alt+anything should be available if supported by your vim environment (some consoles don't pass along Alt). Additionally, all the F-n keys are available (again, assuming availability in your terminal). Some folks have problems with the backslash on their keyboard because it's in an inconvenient place (or requires key-chords or use of dead-keys), so they prefer to use another character as the mapleader. However, if backslash is available and easy enough for you to reach, it would be my recommended character. A lot of folks seem to use the comma or semi-colon as a map-leader, but they _do_ have functionality that I use on a regular basis. Therefore, if you don't want to relearn muscle memory and want to eventually learn to use those commands (a good follow-on lesson to using t/T/f/F for jumping in a line), I wouldn't go over to the dark side... ;-) -tim
Re: good keys for mappings
Op donderdag 31 mei 2007, schreef Arn: Hi, Any suggestions on keys/key combos that are good candidates for custom mappings etc? Maybe a dumb question but I hate having to unlearn something, I'd like to create a fair number of mappings that use a consistent convention and won't conflict with anything existing. I think Bram mentioned he's found prefixing with _ works well.. Well, there's a special key, the so called 'mapleader', you can use to define your mappings. If you don't set it, it defaults to '\'. You can change the value of the mapleader to '_' to 'test' your mapping with the '_' prefix, or change it to something else, without changing the definition of the map. See :help mapleader for more info. Oh, and personally, I just keep it set to the default. Peter
Re: copying text char-by-char from the line above line..
[Andy Wokula] Ajay Gupta schrieb: I saw one of my friends (once!) copying the text from the line right above. :h i_Ctrl-Y At first, I had some difficulty remembering Ctrl-Y, until I decided that Y was a picture of what was going on: that is, funneled from above. Now, I use it very often. Ctrl-E copies from the line below, often useful too, yet it is harder to see an upside-down Y into E :-). -- François Pinard http://pinard.progiciels-bpi.ca
Re: good keys for mappings
[Arn] Any suggestions on keys/key combos that are good candidates for custom mappings etc? The usual is \ followed by something. I initially fought this convention, because \ is a bit hard to type on my keyboard, and tried other things instead, with various levels of conflicts and displeasure. I finally gave in the convention and overcame the keyboard difficulty. I think Bram mentioned he's found prefixing with _ works well.. The _ key is sometimes suggested as well, and some say it is unused. But this is not true, _ is a very useful command for me (it brings the cursor back at the first non-blank character of the current line). A common approach is to use timeouts for recognizing a single key command when that key is also the prefix of multi-key commands. The timeout is not incurred when you immediately follow the single key command by other commands which are not ambiguous with the multi-key commands, but if you want to see the effect of the single key command, you have to suffer the timeout, which may be a bit irritating at times. -- François Pinard http://pinard.progiciels-bpi.ca
Re: good keys for mappings
Hi Arn :) * Arn [EMAIL PROTECTED] dixit: Any suggestions on keys/key combos that are good candidates for custom mappings etc? Maybe a dumb question but I hate having to unlearn something, I'd like to create a fair number of mappings that use a consistent convention and won't conflict with anything existing. I think Bram mentioned he's found prefixing with _ works well.. I think that, apart from '\' (backslash) and probably '_' (underscore) there aren't many keys available for everyone to use as mapleader. This said, depending on your keyboard layout, you may find interesting candidates: for example, my spanish keyboard comes with ç, which is just under my right little finger and that I almost never use. So, I've remapped some combos to 'çç', 'ç+', 'ç-', etc. That is, the key I don't use and the keys that are near to it. This is very useful to me, but this works only on spanish keyboards. Which layout do you use? Raúl Núñez de Arenas Coronado -- Linux Registered User 88736 | http://www.dervishd.net It's my PC and I'll cry if I want to... RAmen!
Re: good keys for mappings
On Thu, May 31, 2007 at 11:15:18AM -0400, François Pinard wrote: I think Bram mentioned he's found prefixing with _ works well.. The _ key is sometimes suggested as well, and some say it is unused. But this is not true, _ is a very useful command for me (it brings the cursor back at the first non-blank character of the current line). If you use _ only for that (i.e. without count), it is equivalent to ^. So you can map one of them. Yeti -- http://gwyddion.net/
Re: No Previous Regular expression
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
Re: copying text char-by-char from the line above line..
François Pinard wrote: At first, I had some difficulty remembering Ctrl-Y, until I decided that Y was a picture of what was going on: that is, funneled from above. Now, I use it very often. Ctrl-E copies from the line below, often useful too, yet it is harder to see an upside-down Y into E :-). It's easier to remember if you already know what C-Y and C-E do in normal made (they scroll the page) Tobia
Re: plugins in vim 7.1
Tushar Desai wrote: I had done a make install for vim7.1 and that's how the /usr/local/share/vim71/... dir structure was created on my machine. Also, the directory is plugin and not plugins (which was my typo in the email). The makeparens.vim plugin has stopped working in Fedora Core 6 as well. The only thing common is that on both machines I started with vim7.0 and then manually upgraded to vim 7.1, by compiling from the tarball. Thanks for your help. - What does ls -l `which vim` display? It should be your vim 7.1 - The :scriptnames command will show you which files (including plugins) have been sourced. - Near the middle of the output of :version, there is a list of default directories for the current version of Vim. Best regards, Tony. -- In specifications, Murphy's Law supersedes Ohm's.
Re: starting a second vim session in diff mode from out first vim
Eric Leenman wrote: Hi, Is it possible from a first gvim session to init a second gvim session in diff mode? And this diff mode should then use the two files that are used in the first gvim session? So if A.TXT and B.TXT are used in the first, the second should show the difference in the second gvim session? Rgds, Eric Editing the same file(s) in more than one gvim sessions in parallel is bound to run into pitfalls of ever kind; but you can change any numbers of files already open in Vim by using :diffthis in each window concerned; e.g., to diff all files currently visible in split windows: :windo diffthis Best regards, Tony. -- Today is the first day of the rest of the mess
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: good keys for mappings
Arn wrote:
Hi,
Any suggestions on keys/key combos that are good candidates for custom
mappings etc?
Maybe a dumb question but I hate having to unlearn something, I'd like
to create a fair number of mappings that use a consistent convention and
won't conflict with anything existing. I think Bram mentioned he's
found prefixing with _ works well..
thanks
F2 to F12 (with the possible exception of F10), Shift-F1 to Shift-F12. As many
keys as the Great Arcana of a Tarot deck ;-) Need more? Use some of them as
prefixes for multikey {lhs}es.
On my Linux/kde system, the window manager preempts Ctrl-Fn and Alt-Fn so
those are not usable for Vim.
Best regards,
Tony.
--
The chief cause of problems is solutions.
Re: good keys for mappings
DervishD wrote: Hi Arn :) * Arn [EMAIL PROTECTED] dixit: Any suggestions on keys/key combos that are good candidates for custom mappings etc? Maybe a dumb question but I hate having to unlearn something, I'd like to create a fair number of mappings that use a consistent convention and won't conflict with anything existing. I think Bram mentioned he's found prefixing with _ works well.. I think that, apart from '\' (backslash) and probably '_' (underscore) there aren't many keys available for everyone to use as mapleader. This said, depending on your keyboard layout, you may find interesting candidates: for example, my spanish keyboard comes with ç, which is just under my right little finger and that I almost never use. So, I've remapped some combos to 'çç', 'ç+', 'ç-', etc. That is, the key I don't use and the keys that are near to it. This is very useful to me, but this works only on spanish keyboards. Which layout do you use? Raúl Núñez de Arenas Coronado On my Belgian keyboard, there are ù (u-grave) and µ (greek mu) at the right end of the middle row, plus shift-mu which is £ (pound sterling). Shift-ù is % and Vim uses that, especially when matchit is enabled. Then there are keys like ² (superscript 2), é (e-acute), § (paragraph), è (e-grave), ç (c-cedilla), à (a-grave) as the unshifted counterparts of various keys of the digits row (on this AZERTY layout the digits are shifted, unlike on US-QWERTY). But I'd say the F keys are the safest in general, especially when taking portability into account. Best regards, Tony. -- An attorney was defending his client against a charge of first-degree murder. Your Honor, my client is accused of stuffing his lover's mutilated body into a suitcase and heading for the Mexican border. Just north of Tijuana a cop spotted her hand sticking out of the suitcase. Now, I would like to stress that my client is *not* a murderer. A sloppy packer, maybe...
Re: No Previous Regular expression
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
Re: good keys for mappings
Hi Tony :) * A.J.Mechelynck [EMAIL PROTECTED] dixit: But I'd say the F keys are the safest in general, especially when taking portability into account. Of course: if you plan to use more than one vim or more than one keyboard type, the F keys are the best choice. In fact, for complex commands I think that they are the only option, because that way you will be able to do these complex commands in any keyboard. But for simple things (like my 'çç', which is just a shorcut for gqip more or less) I prefer a key which is near to my blind typing position. Raúl Núñez de Arenas Coronado -- Linux Registered User 88736 | http://www.dervishd.net It's my PC and I'll cry if I want to... RAmen!
Re: good keys for mappings
DervishD wrote: Hi Tony :) * A.J.Mechelynck [EMAIL PROTECTED] dixit: But I'd say the F keys are the safest in general, especially when taking portability into account. Of course: if you plan to use more than one vim or more than one keyboard type, the F keys are the best choice. In fact, for complex commands I think that they are the only option, because that way you will be able to do these complex commands in any keyboard. But for simple things (like my 'çç', which is just a shorcut for gqip more or less) I prefer a key which is near to my blind typing position. Raúl Núñez de Arenas Coronado I used to have a mapping for µ (mu) because it's easily accessible (not far from your ç, I guess), but that mapping must have gone up in smoke when I upgraded from M$ to Linux. Nowadays I have all my important mappings on Fn and Shift-Fn, but I keep µ and £ (and then maybe ² ³ etc) in reserve for the time when all available F slots will have been taken. Best regards, Tony. -- Just remember: when you go to court, you are trusting your fate to twelve people that weren't smart enough to get out of jury duty!
install new syntax file
Hi, I'm using gVim on windows. I've created an lzx.vim syntax file and dropped it into C:\Program Files\Vim\vim70\syntax. It works fine if I execute: :cal setSyn(lzx) However this syntax is not available from the syntax menu and vim does not automatically use this syntax when I open files with an .lzx extension. How can I fix these problems? Thanks in advance, Don ___ Yahoo! Mail is the world's favourite email. Don't settle for less, sign up for your free account today http://uk.rd.yahoo.com/evt=44106/*http://uk.docs.yahoo.com/mail/winter07.html
Vim (or any editor) meets Firefox in a meaningful way
Sorry if this is known but this is a really cool way to have a Vim/Firefox marriage. :) https://addons.mozilla.org/en-US/firefox/addon/4125 Cheers, Keith
Re: install new syntax file
DM wrote: Hi, I'm using gVim on windows. I've created an lzx.vim syntax file and dropped it into C:\Program Files\Vim\vim70\syntax. It works fine if I execute: :cal setSyn(lzx) However this syntax is not available from the syntax menu and vim does not automatically use this syntax when I open files with an .lzx extension. How can I fix these problems? Thanks in advance, Don 1. Don't drop anything into $VIMRUNTIME and its subdirs, it may be silently erased at any upgrade and it _will_ be forgotten when you upgrade to Vim 7.1 (which is already out by now). Drop that script into $HOME/vimfiles/syntax/ or $VIM/vimfiles/syntax/ (this is in Vim notation; the latter corresponds e.g. to C:\Program Files\vim\vimfiles\syntax), and create the necessary directories if they don't yet exist. $VIMRUNTIME, and everything under it, is ONLY for files distributed together with Vim. Putting anything else there is courting disaster. 2. You have to tell Vim to recognise that syntax. Normally each syntax corresponds to a filetype. So, create a file named $HOME/vimfiles/filetype.vim or $VIM/vimfiles/filetype.vim and paste the following into it: augroup filetypedetect autocmd BufRead,BufNewFile *.lzx setfiletype lzx for every future «new» filetype, add one autocommand here augroup END If that file already exists, it already ought to have the augroup commands at beginning and end, so in that case you need only paste the autocmd line in the middle. With the above, Vim will recognise all *.lzx files as of filetype lzx, and, thanks to an already existing autocommand, all files of lzx filetype will get lzx syntax and source your syntax script. (You must of course, have filetype detection on, but I assume you already have that.) After you do the above, and restart Vim, the new syntax ought to appear in the menu. Best regards, Tony. -- There is a God, but He drinks -- Blore
Retaining undo levels
Hi, Is there a way to retain the undo levels, even when the buffer is not loaded in any windows/tabs? Right now, whenever I open another file in a window, the previous file loses it's undo levels, even though it is still inside the buffer list. -- Виктор Кожухаров /Viktor Kojouharov/ signature.asc Description: Това е цифрово подписана част от писмото
Re: plugins in vim 7.1
see my comments interspersed and at bottom Tushar Desai wrote: Thanks Tony; here's the output :scriptfiles /usr/local/share/vim/vim71/plugin/cscope_maps.vim 2: /usr/local/share/vim/vim71/plugin/getscriptPlugin.vim 3: /usr/local/share/vim/vim71/plugin/gzip.vim 4: /usr/local/share/vim/vim71/plugin/matchparen.vim ...well, it was sourced:^ 5: /usr/local/share/vim/vim71/plugin/netrwPlugin.vim 6: /usr/local/share/vim/vim71/plugin/rrhelper.vim 7: /usr/local/share/vim/vim71/plugin/spellfile.vim 8: /usr/local/share/vim/vim71/plugin/tarPlugin.vim 9: /usr/local/share/vim/vim71/plugin/tohtml.vim 10: /usr/local/share/vim/vim71/plugin/vimballPlugin.vim 11: /usr/local/share/vim/vim71/plugin/zipPlugin.vim 12: /usr/local/share/vim/vim71/menu.vim 13: /usr/local/share/vim/vim71/autoload/paste.vim 14: /home/tushard/.gvimrc 15: /usr/local/share/vim/vim71/syntax/syntax.vim 16: /usr/local/share/vim/vim71/syntax/synload.vim 17: /usr/local/share/vim/vim71/syntax/syncolor.vim 18: /usr/local/share/vim/vim71/filetype.vim 19: /usr/local/share/vim/vim71/colors/desert.vim 20: /usr/local/share/vim/vim71/syntax/cpp.vim 21: /usr/local/share/vim/vim71/syntax/c.vim :version :vers VIM - Vi IMproved 7.1 (2007 May 12, compiled May 15 2007 09:52:47) Compiled by [EMAIL PROTECTED] meaning the two outstanding patches were not compiled-in. Huge version with GTK2-GNOME 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_gui +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_interact +xterm_clipboard -xterm_save system vimrc file: $VIM/vimrc user vimrc file: $HOME/.vimrc user exrc file: $HOME/.exrc system gvimrc file: $VIM/gvimrc user gvimrc file: $HOME/.gvimrc system menu file: $VIMRUNTIME/menu.vim fall-back for $VIM: /usr/local/share/vim Compilation: gcc -c -I. -Iproto -DHAVE_CONFIG_H -DFEAT_GUI_GTK -I/usr/include/gtk-2.0 -I/ usr/lib/gtk-2.0/include -I/usr/include/atk-1.0 -I/usr/include/cairo -I/usr/include/pango-1 .0 -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/include/freetype2 -I/usr/inc lude/libpng12 -DORBIT2=1 -pthread -I/usr/include/libgnomeui-2.0 -I/usr/include/libgnome- 2.0 -I/usr/include/libgnomecanvas-2.0 -I/usr/include/gtk-2.0 -I/usr/include/libart-2.0 -I/ usr/include/gconf/2 -I/usr/include/libbonoboui-2.0 -I/usr/include/gnome-vfs-2.0 -I/usr/lib /gnome-vfs-2.0/include -I/usr/include/gnome-keyring-1 -I/usr/include/glib-2.0 -I/usr/lib/g lib-2.0/include -I/usr/include/orbit-2.0 -I/usr/include/libbonobo-2.0 -I/usr/include/bonob o-activation-2.0 -I/usr/include/pango-1.0 -I/usr/include/freetype2 -I/usr/lib/gtk-2.0/incl ude -I/usr/include/atk-1.0 -I/usr/include/cairo -I/usr/include/libpng12 -I/usr/include/lib xml2 -O2 -fno-strength-reduce -Wall-D_REENTRANT -D_GNU_SOURCE -I/usr/local/inclu de -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -I/usr/include/gdbm -I/usr/lib/perl5/5.8.8/ i386-linux-thread-multi/CORE -I/usr/include/python2.4 -pthread Linking: gcc -L/lib-Wl,-E -Wl,-rpath,/usr/lib/perl5/5.8.8/i386-linux-thread-multi/CORE -L/usr/local/lib -o vim -L/lib -lgtk-x11-2.0 -lgdk-x11-2.0 -latk-1.0 -lgdk_pixbuf-2.0 -lpangocairo-1.0 -lpango-1.0 -lcairo -lgobject-2.0 -lgmodule-2.0 -lglib-2.0 -L/lib -l gnomeui-2 -lbonoboui-2 -lgnome-keyring -lxml2 -lgnomecanvas-2 -lgnome-2 -lpopt -lart_lgpl_ 2 -lpangoft2-1.0 -lgtk-x11-2.0 -lgdk-x11-2.0 -latk-1.0 -lgdk_pixbuf-2.0 -lpangocairo-1.0 - lpango-1.0 -lcairo -lbonobo-2 -lgnomevfs-2 -lbonobo-activation -lgconf-2 -lgobject-2.0 -lO RBit-2 -lgmodule-2.0 -lgthread-2.0 -lrt -lglib-2.0 -lXt -lncurses -lacl -lgpm -Wl,-E - Wl,-rpath,/usr/lib/perl5/5.8.8/i386-linux-thread-multi/CORE -L/usr/local/lib /usr/lib/per l5/5.8.8/i386-linux-thread-multi/auto/DynaLoader/DynaLoader.a -L/usr/lib/perl5/5.8.8/i386- linux-thread-multi/CORE -lperl -lresolv -lutil -lc -L/usr/lib/python2.4/config -lpython2.4 -lutil -lm -Xlinker -export-dynamic On 5/31/07, A.J.Mechelynck [EMAIL PROTECTED] wrote: Tushar Desai wrote: I had done a make install for vim7.1 and that's how the
Re: Retaining undo levels
Виктор Кожухаров wrote: Hi, Is there a way to retain the undo levels, even when the buffer is not loaded in any windows/tabs? Right now, whenever I open another file in a window, the previous file loses it's undo levels, even though it is still inside the buffer list. I /think/ the undo levels are by buffer. To undo the changes in one buffer, first make that buffer active (e.g. by switching to its window or by :editing it in the current window). If I'm wrong, someone please correct me. Всего хорошего, Тоня. -- What color is a chameleon on a mirror?
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
can't diffsplit
I have two files which I'd like to compare via diffsplit in an existing vim session - trying to do so by issuing ':diffsplit filename' when the other one is already in the window gets me the error: E97: Cannot create diffs I can properly open the diff in a separate instance via 'vimdiff', as well as ':diffsplit' - is there something wrong with my existing session? thanks! -lev
Re: Retaining undo levels
Is there a way to retain the undo levels, even when the buffer is not loaded in any windows/tabs? Right now, whenever I open another file in a window, the previous file loses it's undo levels, even though it is still inside the buffer list. Just to make sure I understand, you're talking about preserving undo (not the 'undolevels' setting, which is global) across buffer abandonment. To do this, it sounds like you want the 'hidden' setting: :set hidden This has some other effects, such as not requiring you to save when you leave the buffer (though if you try and quit Vim entirely with such unsaved buffers hidden, it will squeal) However, it should allow you to keep your undo history even if you close the tab/window/buffer. For more info, you can read up at :help 'hidden' -tim
Re: Retaining undo levels
В чт, 2007-05-31 в 16:19 -0500, Tim Chase написа: Is there a way to retain the undo levels, even when the buffer is not loaded in any windows/tabs? Right now, whenever I open another file in a window, the previous file loses it's undo levels, even though it is still inside the buffer list. Just to make sure I understand, you're talking about preserving undo (not the 'undolevels' setting, which is global) across buffer abandonment. To do this, it sounds like you want the 'hidden' setting: :set hidden This has some other effects, such as not requiring you to save when you leave the buffer (though if you try and quit Vim entirely with such unsaved buffers hidden, it will squeal) However, it should allow you to keep your undo history even if you close the tab/window/buffer. For more info, you can read up at :help 'hidden' -tim Excellent, that's exactly what I was looking for. -- Виктор Кожухаров /Viktor Kojouharov/ signature.asc Description: Това е цифрово подписана част от писмото
Re: Retaining undo levels
В чт, 2007-05-31 в 22:09 +0200, A.J.Mechelynck написа: Виктор Кожухаров wrote: Hi, Is there a way to retain the undo levels, even when the buffer is not loaded in any windows/tabs? Right now, whenever I open another file in a window, the previous file loses it's undo levels, even though it is still inside the buffer list. I /think/ the undo levels are by buffer. To undo the changes in one buffer, first make that buffer active (e.g. by switching to its window or by :editing it in the current window). If I'm wrong, someone please correct me. No, if the buffer is no longer in any window, going back to it by editing the file or selecting the buffer by any means will not bring the undo levels. pressing 'u' will tell you that you are at the earliest change. What I'm asking is whether it's possible to make vim remember the buffer undo levels for each non-deleted buffer while vim is still open. Всего хорошего, Тоня. -- Виктор Кожухаров /Viktor Kojouharov/ signature.asc Description: Това е цифрово подписана част от писмото
Re: Retaining undo levels
Виктор Кожухаров wrote: В чт, 2007-05-31 в 22:09 +0200, A.J.Mechelynck написа: Виктор Кожухаров wrote: Hi, Is there a way to retain the undo levels, even when the buffer is not loaded in any windows/tabs? Right now, whenever I open another file in a window, the previous file loses it's undo levels, even though it is still inside the buffer list. I /think/ the undo levels are by buffer. To undo the changes in one buffer, first make that buffer active (e.g. by switching to its window or by :editing it in the current window). If I'm wrong, someone please correct me. No, if the buffer is no longer in any window, going back to it by editing the file or selecting the buffer by any means will not bring the undo levels. pressing 'u' will tell you that you are at the earliest change. What I'm asking is whether it's possible to make vim remember the buffer undo levels for each non-deleted buffer while vim is still open. Всего хорошего, Тоня. Ah, if it's no longer in any window _and_ not hidden but unloaded, then it loses its undo levels. But you may either hide it, or (more to my taste) keep it in a window which may (with :set winminheight=0) be collapsed to a status line and nothing else; and then (IIUC) the undo levels will be kept. I notice that even with the true tabs of Vim 7 available, I still use Rolodex Vim a lot; it essentially consists of :set winheight=9 winminheight=0 (without the quotes of course). This way, the current window expands to full height and all other windows are reduced to just a status line at either top or bottom. Think of a Rolodex phone directory at the office. Best regards, Tony. -- I'd love to go out with you, but I have to floss my cat.
Re: can't diffsplit
Lev Lvovsky wrote: I have two files which I'd like to compare via diffsplit in an existing vim session - trying to do so by issuing ':diffsplit filename' when the other one is already in the window gets me the error: E97: Cannot create diffs I can properly open the diff in a separate instance via 'vimdiff', as well as ':diffsplit' - is there something wrong with my existing session? thanks! -lev I. To diff one file already being edited with another file not being edited: 1. make the file already being edited current (let's say foo.txt) 2. :vertical diffsplit bar.txt II. To diff two files already being edited: 1. make one file current 2. :diffthis 3. make the other file current 4. :diffthis 5. (Optional) Rearrange the windows (using ^W commands) to place them side-by-side. III. To diff (in an existing Vim, but in new windows) two files not being edited 1. :bot new foo.txt 2. :vert diffsplit bar.txt Best regards, Tony. -- A KNIGHT rides into shot and hacks him to the ground. He rides off. We stay for a moment on the glade. A MIDDLE-AGED LADY in a C. A. twin-set emerges from the trees and looks in horror at the body of her HUSBAND. MRS HISTORIAN: FRANK! Monty Python and the Holy Grail PYTHON (MONTY) PICTURES LTD
Re: can't diffsplit
On May 31, 2007, at 3:02 PM, A.J.Mechelynck wrote: Lev Lvovsky wrote: I have two files which I'd like to compare via diffsplit in an existing vim session - trying to do so by issuing ':diffsplit filename' when the other one is already in the window gets me the error: E97: Cannot create diffs I can properly open the diff in a separate instance via 'vimdiff', as well as ':diffsplit' - is there something wrong with my existing session? thanks! -lev II. To diff two files already being edited: 1. make one file current 2. :diffthis 3. make the other file current 4. :diffthis 5. (Optional) Rearrange the windows (using ^W commands) to place them side-by-side. Great. this solved the error that I was getting... thanks! -lev
Re: plugins in vim 7.1
Tushar Desai wrote: Hi Tony, which patches are you referring to? if download latst vim7.1 tarball, will it have the patches? thanks for your help, -tushar. No. The patches are in ftp://ftp.vim.org/pub/vim/patches/7.1/ and are _in addition_ to the tarball which is 7.1.0. See http://users.skynet.be/antoine.mechelynck/vim/compunix.htm (which is for 7.0, but you ought to be able to use it /mutatis mutandis/ fot 7.1) about how to download and apply the patches. Best regards, Tony. -- But the greatest Electrical Pioneer of them all was Thomas Edison, who was a brilliant inventor despite the fact that he had little formal education and lived in New Jersey. Edison's first major invention in 1877, was the phonograph, which could soon be found in thousands of American homes, where it basically sat until 1923, when the record was invented. But Edison's greatest achievement came in 1879, when he invented the electric company. Edison's design was a brilliant adaptation of the simple electrical circuit: the electric company sends electricity through a wire to a customer, then immediately gets the electricity back through another wire, then (this is the brilliant part) sends it right back to the customer again. This means that an electric company can sell a customer the same batch of electricity thousands of times a day and never get caught, since very few customers take the time to examine their electricity closely. In fact the last year any new electricity was generated in the United States was 1937; the electric companies have been merely re-selling it ever since, which is why they have so much free time to apply for rate increases. -- Dave Barry, What is Electricity?
how can I add this feature to vim!!
mostly when I press {, I have to press one more } after, because
they are always appears at the same time! the same as () [], and
also the quote mark(). so I wonder how can I add the feature that when
I insert { or the other punctuations above, it will automatically add
} !!!
besides, I wonder how can I make vim to break the line automatically??
and I find a great tip named #166 which tells me how to switch Capslock
to esc, the tip goes to like this:
add
*! Swap caps lock and escape, good for Vim
remove Lock = Caps_Lock
keysym Escape = Caps_Lock
keysym Caps_Lock = Escape
add Lock = Caps_Lock
*to a file named .speedswapper to the home directory, and run *xmodmap
~/.speedswapper* in a terminal, I follow the guide and finally done! but
the bad thing is I have to run the command every time I reboot ubuntu!!
so any helps??
maybe too much questions! hope someone could help
best regards!
jaywee
Re: confirm unsubscribe from vim@vim.org
On 1 Jun 2007 06:00:36 -, [EMAIL PROTECTED] wrote: Hi! This is the ezmlm program. I'm managing the vim@vim.org mailing list. To confirm that you would like [EMAIL PROTECTED] removed from the vim mailing list, please send an empty reply to this address: [EMAIL PROTECTED] Usually, this happens when you just hit the reply button. If this does not work, simply copy the address and paste it into the To: field of a new message. I haven't checked whether your address is currently on the mailing list. To see what address you used to subscribe, look at the messages you are receiving from the mailing list. Each message has your address hidden inside its return path; for example, [EMAIL PROTECTED] receives messages with return path: vim-return-number[EMAIL PROTECTED] Some mail programs are broken and cannot handle long addresses. If you cannot reply to this request, instead send a message to [EMAIL PROTECTED] and put the entire address listed above into the Subject: line. --- Administrative commands for the vim list --- I can handle administrative requests automatically. Please do not send them to the list address! Instead, send your message to the correct command address: To subscribe to the list, send a message to: [EMAIL PROTECTED] To remove your address from the list, send a message to: [EMAIL PROTECTED] Send mail to the following for info and FAQ for this list: [EMAIL PROTECTED] [EMAIL PROTECTED] Similar addresses exist for the digest list: [EMAIL PROTECTED] [EMAIL PROTECTED] To get messages 123 through 145 (a maximum of 100 per request), mail: [EMAIL PROTECTED] To get an index with subject and author for messages 123-456 , mail: [EMAIL PROTECTED] They are always returned as sets of 100, max 2000 per request, so you'll actually get 100-499. To receive all messages with the same subject as message 12345, send an empty message to: [EMAIL PROTECTED] The messages do not really need to be empty, but I will ignore their content. Only the ADDRESS you send to is important. You can start a subscription for an alternate address, for example [EMAIL PROTECTED], just add a hyphen and your address (with '=' instead of '@') after the command word: [EMAIL PROTECTED] To stop subscription for this address, mail: [EMAIL PROTECTED] In both cases, I'll send a confirmation message to that address. When you receive it, simply reply to it to complete your subscription. If despite following these instructions, you do not get the desired results, please contact my owner at [EMAIL PROTECTED] Please be patient, my owner is a lot slower than I am ;-) --- Enclosed is a copy of the request I received. Return-Path: [EMAIL PROTECTED] Received: (qmail 31083 invoked from network); 1 Jun 2007 06:00:36 - Received: from unknown (HELO avmail.wilbury.sk) (81.89.56.24) by foobar.math.fu-berlin.de with SMTP; 1 Jun 2007 06:00:36 - Received: from avmail.ltc.sk (avmail.ltc.sk [81.89.56.18]) by avmail.wilbury.sk (Postfix) with ESMTP id D0C56131CB for [EMAIL PROTECTED]; Fri, 1 Jun 2007 06:54:42 +0200 (CEST) X-Virus-Scanned-ltcavmail: amavisd-new at ltc.sk Received: from avmail.wilbury.sk ([81.89.56.24]) by avmail.ltc.sk (avmail.ltc.sk [81.89.56.18]) (amavisd-new, port 12425) with ESMTP id Ldja+VgJsmuu for [EMAIL PROTECTED]; Fri, 1 Jun 2007 06:54:42 +0200 (CEST) Received: from hathor.lasermount.plus.com (lasermount.plus.com [212.159.61.82]) by avmail.wilbury.sk (Postfix) with ESMTP id 6F8D8131DC for [EMAIL PROTECTED]; Fri, 1 Jun 2007 06:54:06 +0200 (CEST) Received: from hathor.lasermount.plus.com (localhost [127.0.0.1]) by hathor.lasermount.plus.com (Postfix) with ESMTP id 80C02C2650 for [EMAIL PROTECTED]; Fri, 1 Jun 2007 05:54:06 +0100 (BST) Date: Fri, 1 Jun 2007 05:54:06 +0100 From: Spencer Collyer [EMAIL PROTECTED] To: [EMAIL PROTECTED] Message-ID: [EMAIL PROTECTED] Organization: Lasermount Limited X-Mailer: Claws Mail 2.7.2 (GTK+ 2.10.6; x86_64-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit -- Eagles may soar, but weasels don't get sucked into jet engines 6:14am up 93 days 12:56, 17 users, load average: 3.36, 2.85, 1.72 Registered Linux User #232457 | LFS ID 11703
Re: OT: Vi in a browser...
On 31/05/07, A.J.Mechelynck [EMAIL PROTECTED] wrote: Edward L. Fox wrote: [...] A friend told me that he is developing a Firefox addon to emulate the Vi/Vim behaviors in all text areas in Firefox, without launching external applications. I'm looking forward to it. [...] I don't think any Vim extension aiming at reproducing Vim's behaviour without actually calling it, will be able to come near the result of the gazillions of man-hours Bram (with a few others) has put and is still putting into it. Many browsers are able to interact with any external editor (such as true-blue Vim) these days, which also means that any bugfix or improvement to Vim gets reflected in the editing behaviour of the browser. Or you could always write the text in Vim, then use the clipboard to paste it into the browser, even with no special external editor function. Agreed. Maybe Edward should persuade his friend to use the OLE interface of Vim instead. Yongwei -- Wu Yongwei URL: http://wyw.dcweb.cn/
