Crash with strftime()
Not nice: :echo strftime(%e) %e - some undefined code I used by accident makes Vim crash. (GVim 7.0.235, Win32) -- Regards, Andy
Re: Crash with strftime()
Hi! I observe different results. The compiled on MinGW gvim doesn't crash, but displays nothing. Under linux it works quite well, and prints the day of the month, i.e. 23. So the crash may refer to a bug in the system libraries or environments. It'd be interesting to have look at the crash from a debugger. -- Anatoli Sakhnik. On 23/05/07, Andy Wokula [EMAIL PROTECTED] wrote: Not nice: :echo strftime(%e) %e - some undefined code I used by accident makes Vim crash. (GVim 7.0.235, Win32) -- Regards, Andy
Re: Crash with strftime()
Anatoli Sakhnik schrieb: Hi! I observe different results. The compiled on MinGW gvim doesn't crash, but displays nothing. Under linux it works quite well, and prints the day of the month, i.e. 23. So the crash may refer to a bug in the system libraries or environments. It'd be interesting to have look at the crash from a debugger. -- Anatoli Sakhnik. On 23/05/07, Andy Wokula [EMAIL PROTECTED] wrote: Not nice: :echo strftime(%e) %e - some undefined code I used by accident makes Vim crash. (GVim 7.0.235, Win32) -- Regards, Andy Also no crash with the original GVim 7.0 Win32 distribution (returns empty string). -- Regards, Andy
Re: Crash with strftime()
I've forgotten. The version of mine is 7.1. -- Anatoli Sakhnik. On 23/05/07, Andy Wokula [EMAIL PROTECTED] wrote: Also no crash with the original GVim 7.0 Win32 distribution (returns empty string). -- Regards, Andy
Re: weird defaults in Feisty
On Tue, 22 May 2007 15:51:29 -0700, Micah Cowan [EMAIL PROTECTED] wrote: As at least one person has noted, there are many users who expect a vi-compatible program when they type vi at the command-line. When this isn't what you want, you really should consider changing your habit to use vim, as that way you are sure to get a featureful vim, if one is installed (vi could get you any one of a number of programs, depending on the system you're on). When I first used Vim I hated the way it made the text I was replacing vanish instead of showing me what I was overwriting, and I almost gave up on Vim before I discovered that it was possible to make it preserve the behaviour I was accustomed to. When using Vim on Unix I never rely on the system vimrc. I make a point of setting every option I want in my personal configuration files. I also have my own zsh alias from vi to vim so I know exactly what I'm getting. -- Matthew Winn
Re: Vim to Vi (Was: weird defaults in Feisty)
Micah Cowan [EMAIL PROTECTED] 写于 2007-05-23 09:11:54: [EMAIL PROTECTED] wrote: All you need to do is to: sudo apt-get install vim-gtk, which installs a Big version of vim, and the vim will be replaced with that version. Well... not replaced. They will both be installed. You'll probably need to run update-alternatives to ensure that /usr/bin/vim points at the one you want. -- It doesn't really matter if it is replaced or both be installed. What I care is: when I installed a fresh version of Ubuntu Feisty, type vi, I got the Tiny version. After I apt-get installed the vim-gtk, then I type vi, I got the Big version. So, you see, vi is replaced from Tiny version to Big version, that's what I had observed. -- Sincerely, Pan, Shi Zhu. ext: 2606
VimWiki - Poll on wiki hosting
Since John asked for wikibooks again, I've setup a poll to bring this discussion to an end. But before some last words: Wikibooks does not ask you to create structure in chapters,sections up front. It is not even suggested! Suggested is Content first and structure in chapters,sections later. But I don't see any structure in the 1500 tips. Neither now nor later. That's the reason why tips are separated from the manual! Regarding the ads on wikia: The guys there told me that ads will be reduced much in space soon. And I even noticed ads on vim.org ... :-) Now for the vote: Please review the arguments before voting. I hope you can find all major arguments in the full quote at the bottom of this mail. Perhaps a word of Bram would be helpful !? Now here's the link to the poll: http://snappoll.com/poll/194388.php I propose to close the vote on Friday, May 25th, 12:00 +0200 (MEZ aka CET). (please ignore the funny graphic, it was the first result for free poll on google ...) Sebastian. Am Dienstag, den 15.05.2007, 21:06 +0200 schrieb Martin Krischik: Am Dienstag 15 Mai 2007 schrieb Sebastian Menge: Am Montag, den 14.05.2007, 21:49 +0200 schrieb Martin Krischik: Now refresh my mind: Why did we choose advertising ridden wikea over advertising free wikibooks? There was already a lot of discussion on this topic but no real decision. I think that mediawiki is accepted as the most stable, feature-rich and spam-resistant software around. Given that we dont want to host the wiki ourselves, we need a hosting service: Here's a list http://en.wikipedia.org/wiki/List_of_wiki_farms There are no mediawiki-based offers that are completely free. If someone has an idea where/howto host a mediawiki completey free, that would be best! Here my pros and cons for wikia vs wikibooks: 1 +wikia: no costs 2 +wikia: a complete wiki, not just a bunch of pages 3 -wikia: ads 4 +wikibooks: really free, open content 5 -wikibooks: is intended for books/lecture material. vim tips doesnt fit that. A real book would need a structure in chapters,sections etc. 6 +wikibooks: personal Administrator. For me points 2 and 5 win. But anyway I would love to see a good VimBook on wikibooks. Other ideas/votes? Now on WikiBook there is allready a real book with structure in chapters, sections ;-) - it's called Learning the vi editor. Of the 16 chapters 7 are Vim chapters :-). And I belive Vim covers more the 50% of the content. Now the Wiki motto is Content first so here my advertising free suggestion: 1) We add the Vim tips to the Tips and Tricks Chapter 2) Once we we have enough tips (content) we split the book. Wikibooks does not ask you to create structure in chapters,sections up front. It is not even suggested! Suggested is Content first and structure in chapters,sections later. BTW: With a tabbed browser and a fast internet connection you can rename 10 pages per minute - I once rename a 200 page book from Programming:Ada to Ada Programming. Martin [1] http://en.wikibooks.org/wiki/Learning_the_vi_editor [2] http://en.wikibooks.org/wiki/Learning_the_vi_editor/Vim/Tips_and_Tricks
RE: VimWiki - Poll on wiki hosting
-Original Message- From: Sebastian Menge [mailto:[EMAIL PROTECTED] Sent: 23 May 2007 10:03 To: vim@vim.org Subject: VimWiki - Poll on wiki hosting [...] But I don't see any structure in the 1500 tips. Neither now nor later. Well, say they could be thought of belonging loosely to different 'categories' (folding, highlighting, mapping, ...). I don't know if it can be equaled to chapters, sections, paragraphs, probably not, but some structure would surely eventually help in browsing, searching, etc. Hopefully that can be changed later if people think with me it would be useful. That's the reason why tips are separated from the manual! Correct, tips should be separated from the manual IMHO. Regarding the ads on wikia: The guys there told me that ads will be reduced much in space soon. And I even noticed ads on vim.org ... :-) I like that smiley! Now for the vote: Please review the arguments before voting. I hope you can find all major arguments in the full quote at the bottom of this mail. Perhaps a word of Bram would be helpful !? Now here's the link to the poll: http://snappoll.com/poll/194388.php I would have rephrased the 'I don't care' option to something like you guys, who know what you are talking about, choose the solution you believe fits the bill well, can be maintained if needed and is reasonably easy to implement. With this in mind I will vote 'I don't care', which doesn't mean I don't care :-)! I propose to close the vote on Friday, May 25th, 12:00 +0200 (MEZ aka CET). Good suggestion. Cheers and thanks for your involvement in this! ---Zdenek Am Dienstag, den 15.05.2007, 21:06 +0200 schrieb Martin Krischik: Am Dienstag 15 Mai 2007 schrieb Sebastian Menge: Am Montag, den 14.05.2007, 21:49 +0200 schrieb Martin Krischik: Now refresh my mind: Why did we choose advertising ridden wikea over advertising free wikibooks? There was already a lot of discussion on this topic but no real decision. I think that mediawiki is accepted as the most stable, feature-rich and spam-resistant software around. Given that we dont want to host the wiki ourselves, we need a hosting service: Here's a list http://en.wikipedia.org/wiki/List_of_wiki_farms There are no mediawiki-based offers that are completely free. If someone has an idea where/howto host a mediawiki completey free, that would be best! Here my pros and cons for wikia vs wikibooks: 1 +wikia: no costs 2 +wikia: a complete wiki, not just a bunch of pages 3 -wikia: ads 4 +wikibooks: really free, open content 5 -wikibooks: is intended for books/lecture material. vim tips doesnt fit that. A real book would need a structure in chapters,sections etc. 6 +wikibooks: personal Administrator. For me points 2 and 5 win. But anyway I would love to see a good VimBook on wikibooks. Other ideas/votes? Now on WikiBook there is allready a real book with structure in chapters, sections ;-) - it's called Learning the vi editor. Of the 16 chapters 7 are Vim chapters :-). And I belive Vim covers more the 50% of the content. Now the Wiki motto is Content first so here my advertising free suggestion: 1) We add the Vim tips to the Tips and Tricks Chapter 2) Once we we have enough tips (content) we split the book. Wikibooks does not ask you to create structure in chapters,sections up front. It is not even suggested! Suggested is Content first and structure in chapters,sections later. BTW: With a tabbed browser and a fast internet connection you can rename 10 pages per minute - I once rename a 200 page book from Programming:Ada to Ada Programming. Martin [1] http://en.wikibooks.org/wiki/Learning_the_vi_editor [2] http://en.wikibooks.org/wiki/Learning_the_vi_editor/Vim/Tips_and_Tricks smime.p7s Description: S/MIME cryptographic signature
Re: A performance question
Op woensdag 23 mei 2007, schreef fREW: 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. Indeed, among other things, this disables the swap file for 'large' files, which should really speed up things. Peter
Re: A performance question
Peter Palm wrote: http://www.vim.org/scripts/script.php?script_id=1506. Indeed, among other things, this disables the swap file for 'large' files, which should really speed up things. I was going to report the following issue to vim-dev after I got a chance to investigate it a little further, but it seems appropriate to mention it now. I did some work with a 3GB text file on Win32, using Vim 7.0 and Dr.Chip's LargeFile.vim script from Tip 1506 above. The result was really ugly. The script failed to notice that 3GB was large because the Vim function getfsize(f) returned a negative number. Vim eventually opened the file and was able to search, etc. So Vim doesn't rely on the code behind getfsize(). I started looking at what could be done to fix the bug, but have had to leave it for another day. I was starting to think that it wouldn't be too hard to use the extended functions available in recent Win32 and Linux to get a 64-bit file size. Then maybe provide a function to compare a 64-bit file size with a specified 32-bit limit, so LargeFile.vim could work reliably. I haven't checked getfsize() on 32-bit Linux yet, nor am I sufficiently patient to try opening the 3GB file with Vim 7.1. John
Re: undo replace in multiple files
Tim Chase wrote: I think given those conditions (autowrite and nohidden), there seems to be no such way from my experimenting. However, if you switch to using hidden instead of nohidden, you can do :argdo u which will undo the last action in each argument. I've been casually looking for such a feature, but so far I've come up a little short. After a multi-file search-and-replace, I'd like to be able to undo the replace across the files. The `:argdo u` command almost does what I want, but I can't think how to restrict the undo operation to changes made only by the replace operation. For example, suppose I create two files and edit them together: echo first file first.txt echo second file second.txt gvim first.txt second.txt Suppose in first.txt I edit `first` to become `1st` using Vim editing commands: cw1stEscape Now I perform a search-and-replace to change `second` to `2nd`: :argdo %s/second/2nd/ge Now I try to undo my most recent replace operation: :argdo u I'd like this to undo only the change(s) made by the s/// command, but it also changes `1st` back to `first`. Since the `u` is performed indiscriminately in all arguments regardless of whether the s/// command made changes there, I can't blindly use the undo trick to reverse an arbitrary replace operation. I've tried saving all buffers before doing the replace operation, but `:argdo u` undoes past the save (which generally pleases me greatly, but is unfortunate in this case :-)). I searched for replace undo in Vim's plugins and tips, but came up empty. Does anyone have a pointer to a plugin or other resource to allow blind undoing of multi-file replace operations? Thanks, Michael Henry
Re: A performance question
John Beckett [EMAIL PROTECTED] 写于 2007-05-23 18:39:22: The result was really ugly. The script failed to notice that 3GB was large because the Vim function getfsize(f) returned a negative number. I haven't checked getfsize() on 32-bit Linux yet, nor am I sufficiently patient to try opening the 3GB file with Vim 7.1. John 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 is not that 32bit isn't enough, but the fsize should be *unsigned*. The problem is that vim script can use only *signed* 32-bit int as internel type, so there might be improvement of vim script engine ―― instead of get the 64-bit file size. -- Sincerely, Pan, Shi Zhu. ext: 2606
Re: undo replace in multiple files
echo first file first.txt echo second file second.txt gvim first.txt second.txt Suppose in first.txt I edit `first` to become `1st` using Vim editing commands: cw1stEscape Now I perform a search-and-replace to change `second` to `2nd`: :argdo %s/second/2nd/ge Now I try to undo my most recent replace operation: :argdo u I'd like this to undo only the change(s) made by the s/// command, but it also changes `1st` back to `first`. I've tried saving all buffers before doing the replace operation, but `:argdo u` undoes past the save (which generally pleases me greatly, but is unfortunate in this case :-)). If saving a snapshot of your buffers in a good state (using :wall) before monkeying with argdo is acceptable (which by your comments, it is), you should be able to revert to the saved copy with something like: :wall :argdo %s/foo/bar/g [whoops! I meant s/\foo\/bar!] :argdo e! :argdo %s/\foo\/bar/g where argdo e! abandons any changes you've made and reloads the file. -tim
Re: A performance question
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.
The Win32 API includes function _stati64() to get a 64-bit file
size (the API really wants you to use GetFileSize(); _stati64()
is for old timers).
I was envisaging some new Vim script function like:
islargefile({fname}, {limit})
which would return nonzero if the size of the file is greater
than the 32-bit signed {limit} argument.
On many systems, the calculation could use 64-bit integers.
John
Re: A performance question
John Beckett [EMAIL PROTECTED] 写于 2007-05-23 19:32:25: On many systems, the calculation could use 64-bit integers. John Yes, but on all systems, vim script could not take 64-bit integers: see eval.txt line 38: 1.1 Variable types ~ *E712* There are five types of variables: NumberA 32 bit signed number. Examples: -123 0x10 0177 The only integer which supported by vim script is 32-bit signed. So even if you can get 64-bit file size, you cannot save it in any variables in vim script. -- Sincerely, Pan, Shi Zhu. ext: 2606
Re: Netrw edit file
Eric Smith wrote: When I am in vim, I can edit a file after selecting form the explorer, however I can only :read a file if I use Nread I'm not sure what you mean by this -- :r file works normally. If the file is an url style: :r ftp://somehost/path/to/file then netrw will read the file, too. How do I :edit from within vim? Place cursor on the target file; press the cr. Regards, Chip Campbell
Re: A performance question
Robert M Robinson wrote: That brings me to my question. I have noticed that when editing large files (millions of lines), deleting a large number of lines (say, hundreds of thousands to millions) takes an unbelieveably long time in VIM--at least on my systems. This struck me as so odd, I looked you up (for the first time in all my years of use) so I could ask why! The LargeFile.vim plugin helps to speed up the editing of large files: http://vim.sourceforge.net/scripts/script.php?script_id=1506 It does so by changing a number of things: no syntax highlighting, no undo, etc. Regards, Chip Campbell
Re: A performance question
John Beckett wrote: Peter Palm wrote: http://www.vim.org/scripts/script.php?script_id=1506. Indeed, among other things, this disables the swap file for 'large' files, which should really speed up things. I was going to report the following issue to vim-dev after I got a chance to investigate it a little further, but it seems appropriate to mention it now. I did some work with a 3GB text file on Win32, using Vim 7.0 and Dr.Chip's LargeFile.vim script from Tip 1506 above. The result was really ugly. The script failed to notice that 3GB was large because the Vim function getfsize(f) returned a negative number. Sounds like the filesize is getting stored in a 32bit signed number, and overflowing. Is the negative number -1 (that would mean file can't be found)? If not, then perhaps that fact could be used to extend the LargeFile's ability to catch large files: trigger when getfsize() returns a number -1. Please let me know what getfsize() is actually returning when applied to that 3GB file. Regards, Chip Campbell
Re: can i map the number pad enter or somesuch?
shawn bright wrote: hello all, Is the enter key on the numeric keypad different than the enter key of the keyboard? i was thinking that it would be super handy to map it to gg. I have a lot of long files to mess around with. I believe the NumLock key modifies the behavior of the number pad keys. To see if your vim will respond to something from it, use insert mode and ctrl-v: i ctrl-v enter ctrl-v numberpad-enter If they're different, you should be able to use it in a mapping. Regards, Chip Campbell
VimWiki - referring to vimdoc
Im tweaking the import script right now, and noticed that there are many references to the :help. I would like to replace all the occurrences of sth. like (:help some-text) by a reference to vimdoc. Does someone know how what URL could be used instead of :help sometext ?? I found the link http://vimdoc.sourceforge.net/htmldoc/tags.html#help-tags but the page is not available. (404) Any ideas? Sebastian.
Re: VimWiki - Poll on wiki hosting
On Wed, May 23, 2007 3:03 am, Sebastian Menge wrote: Since John asked for wikibooks again, I've setup a poll to bring this discussion to an end. But before some last words: Wikibooks does not ask you to create structure in chapters,sections up front. It is not even suggested! Suggested is Content first and structure in chapters,sections later. But I don't see any structure in the 1500 tips. Neither now nor later. That's the reason why tips are separated from the manual! I agree with this. The tips are basically just a bucket of information, with very little structure. Also, some day it might be nice to add other content to the wiki that doesn't fit very well into a book format. One of the things I really like about Wikia is that it's run by the founds of the Mediawiki project. Here's some more information: * http://www.wikia.com/wiki/Why_use_Wikia%3F Of course, we could make it work on wikibooks, and it is a very nice site. Just my two cents, Tom Purl
Transparent Encryption and Decryption On Windows
I like to use OpenSSL to encrypt some files on my hard drive. I cobbled together the following script that allows me to transparently view and updated OpenSSL-encrypted docs using vim on Linux: augroup encrypted au! First make sure nothing is written to ~/.viminfo while editing an encrypted file. autocmd BufReadPre,FileReadPre *.des3 set viminfo= We don't want a swap file, as it write unencrypted data to disk autocmd BufReadPre,FileReadPre *.des3 set noswapfile Switch to binary mode to read the encrypted file autocmd BufReadPre,FileReadPre *.des3 set bin autocmd BufReadPre,FileReadPre *.des3 let ch_save = ch|set ch=2 autocmd BufReadPre,FileReadPre *.des3 let shsave=sh autocmd BufReadPre,FileReadPre *.des3 let sh='sh' autocmd BufReadPre,FileReadPre *.des3 let ch_save = ch|set ch=2 autocmd BufReadPost,FileReadPost*.des3 '[,']!openssl enc -d -des3 2 /dev/null autocmd BufReadPost,FileReadPost*.des3 let sh=shsave Switch to normal mode for editing autocmd BufReadPost,FileReadPost*.des3 set nobin autocmd BufReadPost,FileReadPost*.des3 let ch = ch_save|unlet ch_save autocmd BufReadPost,FileReadPost*.des3 execute :doautocmd BufReadPost . expand(%:r) Convert all text to encrypted text before writing autocmd BufWritePre,FileWritePre*.des3 set bin autocmd BufWritePre,FileWritePre*.des3 let shsave=sh autocmd BufWritePre,FileWritePre*.des3 let sh='sh' autocmd BufWritePre,FileWritePre*.des3 '[,']!openssl enc -e -des3 -salt 2/dev/null autocmd BufWritePre,FileWritePre*.des3 let sh=shsave Undo the encryption so we are back in the normal text, directly after the file has been written. autocmd BufWritePost,FileWritePost *.des3 silent u autocmd BufWritePost,FileWritePost *.des3 set nobin augroup END Basically, when I try to open a file with a des3 file extension, this chunk of code is executed. To get this to work on Windows, I changed the openssl lines to the following: autocmd BufReadPost,FileReadPost*.des3 '[,']!C:\OpenSSL\bin\openssl.exe enc -d -des3 2 /dev/null ... autocmd BufWritePre,FileWritePre*.des3 '[,']!C:\OpenSSL\bin\openssl.exe enc -e -des3 -salt 2/dev/null Also, I commented out the let sh='sh' lines, since I get the following value when I execute the :echo sh command: C:\WINDOWS\system32\cmd.exe However, when I try to open an encrypted file using this function, I get the following error: c: gvim .\secret.txt.des3 .\secret.txt.des3 [noeol][unix] 10L, 1304C shell returned 1 10 lines filtered Press ENTER or type command to continue ... 'sh' is not recognized as an internal or external command, operable program or batch file. The weird part is that I commented out all of the lines that explicitly reference 'sh'. What am I doing wrong? Is there anyone else who's usuing gpg or openssl with Vim? Thanks in advance! Tom Purl
Re: Transparent Encryption and Decryption On Windows
On 2007-05-23T09:59:22-0500, Tom Purl wrote: Is there anyone else who's usuing gpg or openssl with Vim? I use one of the gpg plugins all the time: http://www.vim.org/scripts/script.php?script_id=1751 /Allan
Re: A performance question
In that case, I'll have to thank Bram for fixing my problem before I even asked him to do so! Thanks Gary, when I get a chance I'll download vim 7. To those of you who provided links to work-around scripts etc., thank you for your help. If any of you are having trouble with large files I'd recommend doing what I _didn't_ do: make sure you're using the most recent version of vim before looking for other solutions. You may not need to reduce vim's capabilities in order to work with large files, either! Cheers, Max On Tue, 22 May 2007, Gary Johnson wrote: 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!)
Re: Transparent Encryption and Decryption On Windows
On Wed, May 23, 2007 11:05 am, Allan Wind wrote: On 2007-05-23T09:59:22-0500, Tom Purl wrote: Is there anyone else who's usuing gpg or openssl with Vim? I use one of the gpg plugins all the time: http://www.vim.org/scripts/script.php?script_id=1751 Problem solved. Thanks Allan. I was hoping to find an openssl solution since I'm so familiar with it and prefer symmetric to asymmetric encryption. However, since the gpg.vim plugin is so robust, and since it works with Windows, I decided to take a closer look at gpg. It turns out that I can use symmetric (password-only) encryption with gpg, and that the gpg.vim plugin supports it very well. I therefore converted my old encrypted file to use gpg encryption using the following commands on Windows: c:\foo dir 05/23/2007 10:42 AM 312 secret.txt.des3 c:\foo openssl enc -d -des3 -in .\secret.txt.des3 -out .\secret.txt (entered password) c:\foo dir 05/23/2007 10:45 AM 312 secret.txt 05/23/2007 10:42 AM 312 secret.txt.des3 c:\foo gpg --symmetric --output .\secret.txt.gpg .\secret.txt (entered password twice) c:\foo dir 05/23/2007 10:45 AM 312 secret.txt 05/23/2007 10:42 AM 312 secret.txt.des3 05/23/2007 10:46 AM 312 secret.txt.gpg c:\foo sdelete .\secret.txt c:\foo dir 05/23/2007 10:42 AM 312 secret.txt.des3 05/23/2007 10:46 AM 312 secret.txt.gpg I could then transparently edit the file using vim once I had installed the gpg.vim plugin. Thanks to everyone for their help, especially Markus Braun for writing such an excellent plugin. Tom Purl
RE: repeating up/down/delete commands
often well beyond those of the present line. I had been used to this deleting up to 999 characters, but only up to the end of the present line. It appears that the set compatible Ummm, 'D' doesn't work?
Re: VimWiki - referring to vimdoc
On 5/23/07, Sebastian Menge [EMAIL PROTECTED] wrote: Im tweaking the import script right now, and noticed that there are many references to the :help. I would like to replace all the occurrences of sth. like (:help some-text) by a reference to vimdoc. Does someone know how what URL could be used instead of :help sometext ?? I found the link http://vimdoc.sourceforge.net/htmldoc/tags.html#help-tags but the page is not available. (404) You can use following URL to find tags matching SOMETEXT: http://vimdoc.sourceforge.net/search.php?docs=helpsearch=SOMETEXT Yakov
Re: VimWiki - referring to vimdoc
On 2007-05-23, Sebastian Menge [EMAIL PROTECTED] wrote: Im tweaking the import script right now, and noticed that there are many references to the :help. I would like to replace all the occurrences of sth. like (:help some-text) by a reference to vimdoc. Does someone know how what URL could be used instead of :help sometext ?? I think I'd keep the :help sometext so that people can access the topic locally if they want to. This is especially important if someone prints a paper copy of the tip. The official on-line help files seem to be at http://vimdoc.sourceforge.net/htmldoc/. For example, the :help i_CTRL-W entry is found at http://vimdoc.sourceforge.net/htmldoc/insert.html#i_CTRL-W These URLs may have to be found manually, since they consist of the file name as well as the tag. I found the link http://vimdoc.sourceforge.net/htmldoc/tags.html#help-tags but the page is not available. (404) Executing :help tags.txt shows there is no tags.txt help file, so I wouldn't expect there to be a tags.html file, and :help help-tags shows there is no such tag, either. However, :help helptab shows :helptags, which is found in various.txt, so this URL should work: http://vimdoc.sourceforge.net/htmldoc/various.html#:helptags and it does. HTH, Gary -- Gary Johnson | Agilent Technologies [EMAIL PROTECTED] | Mobile Broadband Division | Spokane, Washington, USA
Re: Python Omni complete on Windows?
On 5/21/07, Mike Hansen [EMAIL PROTECTED] wrote: Oh great VIM gurus. With VIM 7.# on Windows, I can't seem to get the Omni complete to work for Python for my own modules written in python. Omni complete seems to work for standard library modules, but not for modules that I have in the same directory as the source I'm editing. I have a tags file in the same directory as the python source. When I try to Omni complete, I get Pattern not found. If I do a :version, I see +python/dyn. If I do :py import sys;print sys.version, I see 2.4.4. How do I get Omni complete to work for Python on Windows? Does anyone have any ideas on this? Hmm, could you provide a test case (some example files) so that I can reproduce this? Sorry I didn't get this message earlier. I just got a message from the ezmlm program that several messages from the vim list bounced. I then decided to look at the list on the web, and your reply was there. I think I solved it. I have been doing development of a web application on my Windows PC for an app that runs on Linux. I have a mapped drive(using SAMBA) to the Linux server where the source code resides. I've been editing the files on the Linux server from my Windows version of VIM. Omni complete wasn't working except for standard library modules. I did a simple test on Windows by creating a simple module, running ctags, then creating another python file and importing the module, and Omni complete worked. I did the same test with the files sitting on the mapped drive, and it worked too. That lead me to believe that there was something different about my web application. Well, there were three 3rd party modules that were installed on the Linux server, but they were not installed on my Windows PC. I installed them on my Windows PC, and now Omni complete works much better than before. Lesson learned. I tried running VIM on a putty session to the Linux server, but it was somewhat sluggish. I also tried running XMing on my Windows PC and launching gvim from the Linux server, but that was sluggish too. Running VIM from my Windows PC to the mapped drive to the Linux server seems to work best. I just have to watch the line endings, but that's usually not much of an issue.(set ff=unix) Mike
Re: VimWiki - referring to vimdoc
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
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
Opening files matching tags in another window
Hello, This is a newbie question. I want to have a functionality similar to g CTRL-] which implements the command :stj [ident]. Is there something like that? I wasn't able to find it in :help tags. Thanks, Krishna
Re: undo replace in multiple files
Hi, On 5/23/07, Michael Henry [EMAIL PROTECTED] wrote: Tim Chase wrote: I think given those conditions (autowrite and nohidden), there seems to be no such way from my experimenting. However, if you switch to using hidden instead of nohidden, you can do :argdo u which will undo the last action in each argument. I've been casually looking for such a feature, but so far I've come up a little short. After a multi-file search-and-replace, I'd like to be able to undo the replace across the files. The `:argdo u` command almost does what I want, but I can't think how to restrict the undo operation to changes made only by the replace operation. For example, suppose I create two files and edit them together: echo first file first.txt echo second file second.txt gvim first.txt second.txt Suppose in first.txt I edit `first` to become `1st` using Vim editing commands: cw1stEscape Now I perform a search-and-replace to change `second` to `2nd`: :argdo %s/second/2nd/ge Now I try to undo my most recent replace operation: :argdo u I'd like this to undo only the change(s) made by the s/// command, but it also changes `1st` back to `first`. Since the `u` is performed indiscriminately in all arguments regardless of whether the s/// command made changes there, I can't blindly use the undo trick to reverse an arbitrary replace operation. I've tried saving all buffers before doing the replace operation, but `:argdo u` undoes past the save (which generally pleases me greatly, but is unfortunate in this case :-)). I searched for replace undo in Vim's plugins and tips, but came up empty. Does anyone have a pointer to a plugin or other resource to allow blind undoing of multi-file replace operations? You can try using the gReplace Vim plugin: http://vim.sourceforge.net/scripts/script.php?script_id=1813 Even though this plugin doesn't provide the undo operation across multiple buffers, it allows you to interactively change a pattern across multiple buffers/files and you can abandon the changes before the buffers are updated with the change. For example, to replace a pattern across multiple buffers, you can do the following: 1. Execute the :Gbuffersearch pattern command. This will open a buffer with all the lines containing pattern in all the open buffers. 2. You can edit this buffer using the usual Vim editing commands. 3. Now you can execute the :Greplace command to incorporate all the changes made in the replace buffer back to the corresponding buffers. 4. To abandon making the changes, you can just close the replace buffer. - Yegappan
Re: Opening files matching tags in another window
Hello, You can try this mapping with the left mouse button (I don't try with C-] because I can't type CTRL-] on my french keyboard :p ) : map C-LeftMouse :exe :stj . expand(cword)CR Best regards, Vissale 2007/5/24, cupaxe [EMAIL PROTECTED]: Hello, This is a newbie question. I want to have a functionality similar to g CTRL-] which implements the command :stj [ident]. Is there something like that? I wasn't able to find it in :help tags. Thanks, Krishna
Re: VimWiki - referring to vimdoc
Sebastian Menge 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 Hm, interesting. AFAICT, there is a tie: both options come out too close to each other for a statistically significant winner to come out. So IMHO more votes are required to clear the fog and resolve the issue. Best regards, Tony. -- I would like to suggest that you not use speed, and here's why: it is going to mess up your heart, mess up your liver, your kidneys, rot out your mind. In general this drug will make you just like your mother and father. -- Frank Zappa
Re: Opening files matching tags in another window
On 2007-05-23, cupaxe [EMAIL PROTECTED] wrote: Hello, This is a newbie question. I want to have a functionality similar to g CTRL-] which implements the command :stj [ident]. Is there something like that? I wasn't able to find it in :help tags. Do you mean like either of these? I'm not very familiar with all the various tag commands. :help CTRL-W_] :help CTRL-W_g_CTRL-] For a list of similar functions, see :help window-tag HTH, Gary -- Gary Johnson | Agilent Technologies [EMAIL PROTECTED] | Mobile Broadband Division | Spokane, Washington, USA
Re: A performance question
Robert Maxwell Robinson wrote: In that case, I'll have to thank Bram for fixing my problem before I even asked him to do so! Thanks Gary, when I get a chance I'll download vim 7. To those of you who provided links to work-around scripts etc., thank you for your help. If any of you are having trouble with large files I'd recommend doing what I _didn't_ do: make sure you're using the most recent version of vim before looking for other solutions. You may not need to reduce vim's capabilities in order to work with large files, either! Cheers, Max That, my dear Max, is golden advice indeed, and not only with Vim: if you have a problem with some software, indeed any problem with any software, try to reproduce your problem using the latest available version of that software (the latest one which doesn't break your system of course). You shouldn't come out worse off for installing it, and, who knows? maybe your problem was solved by one of the intervening bugfixes. This advice is particularly worth while for fast-moving software such as, among others, Vim. Best regards, Tony. -- hundred-and-one symptoms of being an internet addict: 251. You've never seen your closest friends who usually live WAY too far away.
Re: A performance question
Charles E Campbell Jr [EMAIL PROTECTED] 写于 2007-05-23 21:38:27: Sounds like the filesize is getting stored in a 32bit signed number, and overflowing. Is the negative number -1 (that would mean file can't be found)? If not, then perhaps that fact could be used to extend the LargeFile's ability to catch large files: trigger when getfsize() returns a number -1. Please let me know what getfsize() is actually returning when applied to that 3GB file. Regards, Chip Campbell Yes the getfsize() does return -1 when filesize between 2G and 4G. But if the filesize is 4G to 6G, this may not work. Anyway, trigger when getfsize returns a number -1 does help in 50% cases. It can't be wrong, so please just do it. -- Sincerely, Pan, Shi Zhu. ext: 2606
Re: A performance question
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/
Re: A performance question
Yongwei Wu [EMAIL PROTECTED] 写于 2007-05-24 11:28:06: 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 -- Yes it fits in this role, and frankly speaking this was the reason I first choose Vim. (tail -h might be better for that, but if we want to do search, we may have to use vi.) Six years ago I often need to check the logs in the servers of my company (those are generally HP, DEC and IBM minicomputers with different Unixes without vim installed), we got more than 30 servers like that and the file is usually 2GB to 11GB. I open the log file in plain vi and it takes way too long to open. One day I happened to compile and installed Vim (it was 5.x or 6.x) on one of the servers, and found that the Vim opens those file about 10 to 20 times faster than the plain Vi, then I installed Vim on all of our servers and feel that Vim greatly speeds my work. After that I begin to learn Vim. So you see, if Vim could not handle Big text files, I would not have know and using vim now. Vim5 and Vim6 opens big file fast, if anyone opens 3GB text file for more than 60 seconds, I'll doubt if this is an issue of Vim7 or something wrong with his own configuration. -- Sincerely, Pan, Shi Zhu. ext: 2606
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
