Re: 'fileencodings': Why use ucs-2le for cp936 file?
[EMAIL PROTECTED] wrote: A.J.Mechelynck [EMAIL PROTECTED] 写于 2007-06-06 10:30:54: 1. will vim write BOM when writing to unicode files? or is there any options for that? :setlocal bomb When opening a Unicode file, Vim will set or clear the buffer-local 'bomb' option according to the presence or absence of a BOM. That option is irrelevant for non-Unicode files. You can also set or clear it manually. When creating a new Unicode file from scratch, a BOM will be set, or not,depending on the corresponding global setting, so if you want your new Unicode files to be created with a BOM, you may add :setglobal bomb to your vimrc. Thanks, it seems that BOM is not written by default and can be set only globally for all unicode encoding. But the problem is: my gcc 4.0 will complain about BOM for utf-8 source file, while ucs-2le must have a BOM so that vim can recognize it without adding the ucs-2le in fencs (ucs-2le should never be added into fencs though, since most characters in cpxxx are valid and it is likely to mess things up). Is there anyway to do BOM setting only for particular unicode encoding like the following? when write utf-8 files, do not write the BOM. when write ucs-2 files, write the BOM. (it should happen even if the file opend as utf-8 then :set fenc=ucs-2le and then :write) -- Sincerely, Pan, Shi Zhu. ext: 2606 autocmd BufWritePre * if fenc ==? 'utf-8' || fenc ==? 'utf8' | \ setlocal nobomb | \ elseif fenc =~? '^u' | setlocal bomb | endif ... will clear 'bomb' just before writing UTF-8 files and set it just before writing other Unicode files (UCS-2, UCS-4 or UTF-16, UTF-32, of any endianness; I'm not speaking here of the latest PRC encoding, GB18030 I think it is called, which is, strictly speaking, also a Unicode encoding). Best regards, Tony. -- A man wrapped up in himself makes a very small package.
Re: search/paste question
Tim Chase wrote: I see you can /text to search, and do * to find the next occurrence of the word under the cursor, but how do you paste text that you've just yank'd, into the search line after you press / without using the mouse? You can use control+R followed by / to insert the text of the last search. :help i_CTRL-R :help c_CTRL-R (both are pretty much the same, as it works in both insert mode and command-line mode). This allows you access to any of vim's registers from insert mode or command-line mode--not just the search, but the file-name, the a-z registers, etc. :help registers Note that when you shift from using /text to using *, you'll get a subtle shift in your search pattern, as * tacks on \ and \ around your word to ensure a whole-word pattern. These extra characters are part of the search pattern and will thus be included/pasted when you use the above control+R/ method. You may want to use n/N for searching for the next/previous instance of your pattern instead. -tim Similarly, after a yank, you can use Ctrl-R on the command-line to put the yanked value there (Ctrl-R for the default register, or Ctrl-R followed by the register name if you yanked into a named register). Best regards, Tony. -- Q: Do you know what the death rate around here is? A: One per person.
Re: buffer local autocmd
Markus Schulz wrote: hello, i want to setup some things only for php-source files. But i don't get the autocmd local to buffer. The setup was also applied to opened c++ files after the first php file. currently i have this inside my .vimrc (php.vim sets some tabulator options) autocmd FileType php source ~/.vim/php.vim i've tried something like: autocmd FileType buffer php source ~/.vim/php.vim without luck. Any hints how i can achieve this? Instead of ~/.vim/php.vim, name it ~/.vim/after/ftplugin/php.vim and you won't even need an autocommand. (Create the directories if they don't exist). Make sure the script contains only local commands such as :map buffer and :setlocal. Best regards, Tony. -- Lewis's Law of Travel: The first piece of luggage out of the chute doesn't belong to anyone, ever.
Re: vim apparently ignoring -c nomodeline cmdline option
Gary Johnson wrote:
On 2007-06-05, Rodolfo Borges [EMAIL PROTECTED] wrote:
When opening a file that ends with
# vim:fdm=marker:
vim keeps doing the folding, even if I call it with -c nomodeline (I
also tried -c modelines=0).
Is it vim fault's, or (more likely) mine?
Note that :help -c says:
-c {command}{command} will be executed after the first file
has been read (and after autocommands and
modelines for that file have been processed).
Try using --cmd instead of -c. See
:help --cmd
Regards,
Gary
Also, :nomodeline is not a valid Vim command. Use
vim --cmd set nomodeline
instead.
Best regards,
Tony.
--
You are old, father William, the young man said,
And your hair has become very white;
And yet you incessantly stand on your head --
Do you think, at your age, it is right?
In my youth, father William replied to his son,
I feared it might injure the brain;
But, now that I'm perfectly sure I have none,
Why, I do it again and again.
-- Lewis Carrol
Re: history in new instance
Ron Olson wrote: Hi all- I use Vim 7 both on Windows and a Mac (in gui mode) and Linux (console mode) and I've noticed that all versions I have, except the Mac one, keeps a command history from previous instances. That is, if I type : and then up-arrow, I can see commands that I've previously entered even though I just started Vim. The Mac does keep a command line history of the current instance, but loses it when Vim is shut down. Is there a setting I can check to see how to set this? Thanks, Ron :help 'history' :help 'viminfo' :help viminfo-file Best regards, Tony. -- FIRST HEAD: Oh! quick! get the sword out I want to cut his head off. THIRD HEAD: Oh, cut your own head off. SECOND HEAD: Yes - do us all a favour. Monty Python and the Holy Grail PYTHON (MONTY) PICTURES LTD
Re: VimWiki - released finally
Tom Purl wrote: On Tue, June 5, 2007 2:29 pm, [EMAIL PROTECTED] wrote: Selon Tom Purl [EMAIL PROTECTED]: On Tue, June 5, 2007 12:36 pm, [EMAIL PROTECTED] wrote: Hello, Tom Purl [EMAIL PROTECTED] wrtoe: How do you update the categories? I can't seem to find that text when I edit the full page. We need to edit the tips to add them one, or several category tags. e.g.: [[Category:Integration]] But I am editing a tip, and I don't see any reference to a [[Category:Foo]] link. IIRC, the category won't appear in the general categories list until it has a page associated (edit the description of the category). However, if you have several pages for a given undocumented category (i.e. having [[Category:Foo]]) and then open the default page for the category (i.e. click on the red link) you will see all the related pages of that category. From my very little experience regarding the organisation of a wiki from scratch, I'll say that everytime we put a page into a new category, we have to define right away the page of that new category. Otherwise, another similar, but different) category may emerge. I don't think that I'm describing my problem very clearly. I'm trying to edit the following page: * http://vim.wikia.com/wiki/Indenting_%22throws%22_in_java When I click on the edit link, I should see something similar to this: some text some more text [[Category:Foo]] Instead, all I see is this: some text some more text One would assume that if the raw version of the page didn't include a [[Category:Foo]] link, then the published version also wouldn't include any category information. The weird thing is that the published version of this particular page includes two categories; Review and VimTip. So what I don't understand is, why can't I change these categories? I've been editing Mediawiki pages for 4 years, and I've never seen anything like this. Thanks in advance for any help! Tom Purl If you click [edit] somewhere in the page, you edit the corresponding section. To edit the whole page, click Edit this page at bottom. Best regards, Tony. -- Never commit yourself! Let someone else commit you.
Re: Syntax Highlighting works for one file only
Tim Johnson wrote: Hello: I'm using vim compiled as 'vim.full' for kubuntu 7.04 amd-64. I can load one file and one file only - it's a python file - where syntax highlighting comes on automatically. Any subsequent files with a .py extension are loaded with only strings highlighted. :setf python enables full highlighting I'm baffled. I've rebuilt .vimrc and .gvimrc one line at a time and I see nothing that could be causing this. Any and all help would be appreciated. Thanks Tim In your second (badly highlighted) *.py file, what does Vim answer to :verbose set filetype? ? Best regards, Tony. -- VIRGO (Aug 23 - Sept 22) You are the logical type and hate disorder. This nitpicking is sickening to your friends. You are cold and unemotional and sometimes fall asleep while making love. Virgos make good bus drivers.
Re: Syntax Highlighting works for one file only
Tim Johnson wrote: On Tuesday 05 June 2007, A.J.Mechelynck wrote: In your second (badly highlighted) *.py file, what does Vim answer to :verbose set filetype? filetype=conf Last set from /usr/share/vim/vim70/filetype.vim Hmm! Thanks Tony Tim Hm. In the Vim 7.1 filetype.vim, filetype conf is set for any file, one of the first 5 lines of which starts with #, but only if everything else fails (and *.py is detected as type python before that...) I wonder what causes your first *.py, but not the others, to be detected as python. Best regards, Tony. -- I have the world's largest collection of seashells. I keep it scattered around the beaches of the world ... Perhaps you've seen it. -- Steven Wright
Re: 'fileencodings': Why use ucs-2le for cp936 file?
[EMAIL PROTECTED] wrote: Hello, Recently I want to do some research about 'fileencodings', what I want is to recognize utf-8, ucs-2le, euc-cn and cp936 encodings. So I set the 'fencs' in my .vimrc: set fencs=ucs-bom,utf-8,ucs-2le,euc-cn,cp936 However, cp936 files are always recognized as ucs-2le and I got everything in a mess... If I remove the ucs-2le: set fencs=ucs-bom,utf-8,euc-cn,cp936 That would work, but ucs-2le files cannot get recognized at all. It is said that unicode files all have BOM, and obviously cp936 files do not have BOM, so I wonder why cp936 files get recognized as ucs-2le file without any BOM. probably because the cp936 files you tested do not contain any sequence of bytes that would be illegal under UCS-2le. I tried to change my 'encoding' setting, but it doesn't affect anything. Any hints? -- Sincerely, Pan, Shi Zhu. ext: 2606 Unicode files may or may not have a BOM, depending on who (or which program) created them and where they come from. If you remove ucs-2le from your 'fileencodings', but leave ucs-bom at the start, any Unicode files having a BOM will still be recognised and the proper encoding set. Best regards, Tony. -- Cahn's Axiom: When all else fails, read the instructions.
Re: 'fileencodings': Why use ucs-2le for cp936 file?
[EMAIL PROTECTED] wrote: A.J.Mechelynck [EMAIL PROTECTED] 写于 2007-06-06 09:51:51: Unicode files may or may not have a BOM, depending on who (or which program) created them and where they come from. If you remove ucs-2le from your 'fileencodings', but leave ucs-bom at the start, any Unicode fileshaving a BOM will still be recognised and the proper encoding set. Best regards, Tony. It seems that ucs-2le files with BOM will get recongized now. But I've got some other question: 1. will vim write BOM when writing to unicode files? or is there any options for that? :setlocal bomb When opening a Unicode file, Vim will set or clear the buffer-local 'bomb' option according to the presence or absence of a BOM. That option is irrelevant for non-Unicode files. You can also set or clear it manually. When creating a new Unicode file from scratch, a BOM will be set, or not, depending on the corresponding global setting, so if you want your new Unicode files to be created with a BOM, you may add :setglobal bomb to your vimrc. 2. what is the correct way of converting a file encoding inside vim? I opened a file with cp936 encoding, then :set fenc=ucs-2le, then :w newfile.txt, close the vim and open the newfile.txt with a new vim, then I found everything in a mess. (gvim 7.1 winxp) -- Sincerely, Pan, Shi Zhu. ext: 2606 It should have worked; but if the file had no BOM, maybe its encoding was detected wrongly: so if it was in UCS-2le but Vim thought it was in GB2312 or in cp936... a mess would be the result. Try opening a file in cp936 then doing :setlocal fenc=ucs-2le bomb :w Your other Vim ought to display it correctly then. See also :help ++opt for another way to set the 'fileencoding' for one file only. Best regards, Tony. -- Life would be so much easier if we could just look at the source code.
Re: Pass vim variable to ruby function
Akbar wrote:
Hi,
This is my ruby script:
VIM::command(function! OpenRequire(open)
ruby open_require(open)
endfunction)
But open is not recognized by ruby. But I can do this:
VIM::command(function! OpenRequire(open)
echo a:open
endfunction)
This does not work too:
VIM::command(function! OpenRequire(open)
ruby open_require(a:open)
endfunction)
How do I pass vim function argument to ruby function. Thank you.
What about
ruby open_require(VIM::evaluate('a:open'))
?
Best regards,
Tony.
--
NOBODY EXPECTS THE SPANISH INQUISITION
Re: CVS vs SVN
Robert Hicks wrote: Is Vim moving to svn? I was curious as to why in the downloads section there is both a cvs version and a svn version. Robert IIUC, the SVN server is mirroring the CVS server, with some lag, for the users who prefer getting the source by SVN. Best regards, Tony. -- To be responsive at this time, though I will simply say, and therefore this is a repeat of what I said previously, that which I am unable to offer in response is based on information available to make no such statement.
Re: Selecting font size
Tim Johnson wrote: Hello: I'm using vim compiled as 'vim.full' for kubuntu 7.04 amd-64. I used vim extensively for programming for years, and am now getting back into it. When I start vim, I see a font that I really like, but I would like to make the font smaller. The problem is that when I choose Edit - Select Font - the font that is highlighted is Sans and when I choose the font size, the font that is loaded is very different from what was installed when i started and is far from appealing. I appreciate some tips as how to resolve this. thanks timf To change the font size without changing the font face (in 'nocompatible' mode): :set guifont=Tab where Tab means hit the Tab key. Vim will fill in the current value (which may be empty if it is still the default) with escaping backslashes if and where needed. You can edit it in place, then hit Enter to accept the new value (or Esc to abort). If the value is empty, you'll have to do something else to find the real value, see furter down this post. If the value is not empty, it can still be in various formats depending on your GUI version. If there is only one number, that's the size. If there are several... well... one of them is usually the size. Here are a few examples: GTK2 (but not GTK1): :set guifont=Bitstream\ Vera\ Sans\ Mono\ 11 ... the size is 11 (pt). kvim (obsolete): :set guifont=Bitstream\ Vera\ Sans\ Mono/9/-1/5/50/0/0/0/1/0 ... the size is 9 (pt). Keep the rest unchanged. Photon: :set guifont=Bitstream\ Vera\ Sans\ Mono:s9 ... the size is 9 (pt). Other X11 versions (including GTK1): :set guifont=-*-lucidatypewriter-medium-r-normal-*-*-100-*-*-m-*-* ... the size is 100 (meaning, IIUC, 10.0pt). Other (e.g. Windows): :set guifont=Courier_New:h12:cDEFAULT ... the size is 12 (pt). In all cases, decrease the size to make the font smaller. For other-x11 there is a hitch: height, or width, or both, may be specified. If the height changes but the width doesn't, replace all numbers other than the height (as shown above) by a single asterisk apiece. If the current value is empty, some GUI flavours will accept :set guifont=* to set it via a menu. You'll have to find a font face that you like, and set the size too. If :set guifont=* doesn't work on your version, then you can either recompile with GTK2 (which does accept that command), or use the following code snippet to set a nonempty value acceptable to your particular gvim flavour: if has(gui_running) if has(gui_gtk2) set gfn=Bitstream\ Vera\ Sans\ Mono\ 9 elseif has(gui_photon) set gfn=Bitstream\ Vera\ Sans\ Mono:s9 elseif has(gui_kde) set gfn=Bitstream\ Vera\ Sans\ Mono/9/-1/5/50/0/0/0/1/0 elseif has(x11) set gfn=-*-lucidatypewriter-medium-r-normal-*-*-100-*-*-m-*-* else set gfn=Lucida_Console:h9:cDEFAULT endif endif Place it in your vimrc. Then you can tweak it by command-line editing (using :set gfn=Tab, edit-in-place, then Enter). You will, however, have to guess the font face name if you want something else than what was set (or if the above tries to set a font face which doesn't exist on your computer). (If you have a program which can set the font via a font chooser menu, you can use that to see which fonts are available, but remember that gvim can only use fixed-width aka monospace fonts -- except in GTK2, where :set gfn=* is legal anyway.) Once you decide that you've found something you like, don't forget to insert the new value at the appropriate place in the vimrc. (You can always use :set gfn=Tab, in 'nocompatible' mode, to see what you must use). Best regards, Tony. -- They now pass three KNIGHTS impaled to a tree. With their feet off the ground, with one lance through the lot of them, they are skewered up like a barbecue. Monty Python and the Holy Grail PYTHON (MONTY) PICTURES LTD
Re: good keys for mappings
John Little wrote: Hi all Tony said: F2 to F12 (with the possible exception of F10), Shift-F1 to Shift-F12. Perhaps not the OP, but someone might find this useful. Vim, at least on Windows, also knows about F13, F14 and F15. I've never seen a keyboard with such, but registry mappings can be used to map the otherwise next to useless (IMO) windows keys (called Left Windows, Right Windows and Application) to them, and their easily found location may make them good for a map leader, though grossly unportable. (I confess the weakness, oh the shame, of using the arrow keys a lot, with the mouse, more shame, in my left hand, so while in this mode, I use the above trick to bring often used functions to hand without having to move my left hand from the mouse.) Of the various pages about this windows arcana I found http://www.usnetizen.com/fix_capslock.html very helpful. I'm curious, though. Are these keys known by Vim on Unices, so could be mapped with say, xmodmap? Regards, John After doinf some research (it wasn't easy) on my Linux system, I came up with the following: X11 allows up to 35 F-keys; you would of course have to determine the geographical code of the keys involved, or to find some way to remap them. (Keyboards with up to 248 keys are supported in theory, and keycodes are in the range 8..255 so they are not the same as keyboard scan codes.) On my system, /usr/include/X11/keysymdef.h, and a few more in the same directory, define a lot of key functions for X11 (I mean, they give names to what a key can do when you hit it). Best regards, Tony. -- To err is human, to moo bovine.
Re: Cut and paste between vim and OS X terminal
Henry Throop wrote: Hi -- I'm having a problem using cut and paste to put text from a VIM document, into a terminal window. It's some sort of character encoding issue. Here's what I do: o Start up gvim with no file. I'm using 6.2. o Type a few characters. o Copy some material (Apple-C) o Move to a terminal window o Paste it (Apple-V) o Material is pasted, but the encoding is incorrect. If I cut the phrase 'ABCabc', then what gets pasted is this: '\344\205\202\344\215\241\346\211\243' If I paste it into a non-terminal window such as Mail or Textedit, I get Chinese characters. Copying *from* Textedit to terminal works fine, so I think the problem is something to do with vim. Can someone point me to what I might have set that's doing this? Thanks, -Henry What happens if you set 'encoding' to macroman (the legacy Mac encoding) prior to yanking? If it doesn't work, try UTF-8. Best regards, Tony. -- Meader's Law: Whatever happens to you, it will previously have happened to everyone you know, only more so.
Re: Cut and paste between vim and OS X terminal
Henry Throop wrote: OK; tried that. Both macroman and utf-8 give me the same results, which are the same as before. -Henry On Jun 2, 2007, at 2:50 PM, A.J.Mechelynck wrote: Henry Throop wrote: Hi -- I'm having a problem using cut and paste to put text from a VIM document, into a terminal window. It's some sort of character encoding issue. Here's what I do: o Start up gvim with no file. I'm using 6.2. o Type a few characters. o Copy some material (Apple-C) o Move to a terminal window o Paste it (Apple-V) o Material is pasted, but the encoding is incorrect. If I cut the phrase 'ABCabc', then what gets pasted is this: '\344\205\202\344\215\241\346\211\243' If I paste it into a non-terminal window such as Mail or Textedit, I get Chinese characters. Copying *from* Textedit to terminal works fine, so I think the problem is something to do with vim. Can someone point me to what I might have set that's doing this? Thanks, -Henry What happens if you set 'encoding' to macroman (the legacy Mac encoding) prior to yanking? If it doesn't work, try UTF-8. Best regards, Tony. -- Meader's Law: Whatever happens to you, it will previously have happened to everyone you know, only more so. Analysis of the octal values you list seems to indicate that your clipboard is getting Latin1, mistaking it for ucs-2be, and translating it to UTF-8: for instance, \344\205\202 is the UTF-8 bytecode for the U+4142 codepoint. I think this /might/ be a fixed bug, check the following bug summaries: http://ftp.vim.org/pub/vim/patches/README (patches for Vim 6.2 and earlier) http://ftp.vim.org/pub/vim/patches/6.3/README http://ftp.vim.org/pub/vim/patches/6.4/README http://ftp.vim.org/pub/vim/patches/7.0/README http://ftp.vim.org/pub/vim/patches/7.1/README Or else, boldly install 7.1.002 and see if the problem persists. Best regards, Tony. -- Paranoid schizophrenics outnumber their enemies at least two to one.
Re: OT: Vi in a browser...
Gene Kwiecinski wrote: Personally, I don't agree with you. When editing short text items on web pages, I feel that the overhead of copying/pasting back and forth from vim is too much. I am currently using the Speaking of which, is there any quicker way to visually select the entire file, analogous to ^A in other systems? I have to essentially do 1GVGctl-del to stick everything into the scratchpad/clipboard/whatever to dump it back into the item from whence it originally came, and that's just a pain. Well, not so much a pain as an annoying itch I can't quite reach. I was thinking something along the lines of %V but that obviously won't work. :) It may depend on what you want to do with the selection: see the commands :yank, :put, delete, all of which accept a range and a register: To copy the whole file to the clipboard: :%y+ To cut (delete) the whole file to the clipboard (not very useful for the whole file, but it may be interesting for a different range): :%d+ To paste the clipboard after the last line: :$put+ To paste the clipboard before the first line: :0put+ To paste the clipboard linewise after the current line: :put+ Without the + at the end, all these act on the default (unnamed) register. Best regards, Tony. -- Bravely bold Sir Robin, rode forth from Camelot, He was not afraid to die, Oh Brave Sir Robin, He was not at all afraid to be killed in nasty ways Brave, brave, brave, brave Sir Robin. Monty Python and the Holy Grail PYTHON (MONTY) PICTURES LTD
Re: :scriptfiles
Tushar Desai wrote: I was previously able to do :scriptfile for vim 7.1 (on Fedora Core 6), when I was debugging why my plugins won't work. Then to check if plugins would work in vim 7.0, I did a make install from vim 7.0. Since they didn't seem to work in vim 7.0, I reverted back to vim 7.1, by doing a make install from vim 7.1 directory. Now, if I type :scriptfile, vim complains that it is not an editor command. (I'm seeing the same issue on Ubuntu Feisty with vim 7.1.) Any ideas why it would stop working? (Probably that will also explain why my plugins are not working.) thanks, -tushar. :scriptfile is indeed not an editor command. You may have misremembered the name of the scriptnames command. :scrCtrl-D or, with 'wildmode' on, :scrTab would have shown you :scriptnames and :scriptencoding. Best regards, Tony. -- Error:015 - Unable to exit Windows. Try the door.
Re: :scriptfiles
Tushar Desai wrote: sorry ... my bad. it is scriptnames and not scriptfiles. but, my plugins still won't work. :-( regards, -tushar. If nothing else avails, you may try executing Vim step-by-step, see :help debug-scripts. Best regards, Tony. -- The price of seeking to force our beliefs on others is that someday they might force their beliefs on us. -- Mario Cuomo
[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
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
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: 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: 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!
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
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
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: 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: 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?
Re: Is there a xml formatter?
wangxu wrote: I want to have this function: formatting my xml file automatically. or,indent xml element and attributes. is there any plugin like this? thanks! I see that an indent/xml.vim is distributed with Vim. Try the following: 1) In you vimrc, make sure that you enable filetype-related indenting, either by runtime vimrc_example.vim or by filetype plugin indent on 2) If you changed your vimrc, restart Vim. 3) From then on, every xml file should get formatted as you type. 4) to reformat an existing file: gggqG Best regards, Tony. -- In war we're tough and able. Quite indefatigable Between our quests We sequin vests And impersonate Clark Gable It's a busy life in Camelot. I have to push the pram a lot. Monty Python and the Holy Grail PYTHON (MONTY) PICTURES LTD
Re: Encoding
Damir Zucic wrote: Hi everybody, I have just recently installed my new linux box. It runs openSUSE 10.2, and I have upgraded vim to version 7.0.243 . Before, I have used older vim versions (6 and older). In the past I have used ctrl-vdecimal_number to insert special characters (there are five uppercase and five lowercase exotic characters in Croatian language). A single byte was used to store each of these characters. However, in version 7 two bytes are used to store each of them! I don't know how to fix this problem. The value of LANG variable is en_US.UTF-8 and encoding is not mentioned in my vimrc file. Decimal values of these exotic characters are 200, 232, 198, 230, 208, 240, 169, 186, 174 and 190. Now 200 is replaced with two bytes: 195 and 136 (decimal) etc. The command :digraphs works fine and lists digraphs using iso-8859-1, I guess. The command :set encoding shows that encoding is utf-8 . Normally, we use the code page ISO-8859-2 here in Croatia. What can I do to force vim to use a single byte to store exotic character? Best regards, Damir Zucic http://physics.mefos.hr/zucic The fact that two (or more) memory bytes are used to store characters other than 0x00 to 0x7F is normal; it's part of the definition of UTF-8. To save your data on disk in such manner that each character occupies only one disk byte, set 'fileencoding' appropriately for your files. You will see [converted] when reading and writing ISO_8859-2 files, but again, this is normal, since Vim uses UTF-8 internally to represent the data in memory. See also the second NOTE paragraph under :help 'encoding'. You may want to add the following to your vimrc: if encoding !~? '^u'if not Unicode, let's set it if termencoding == '' let termencoding = encodingsave the keyboard layout endif set encoding=utf-8 endif set fileencodings=ucs-bom,utf-8,iso-8859-2 encoding-detect heuristics setglobal bomb for new Unicode files setglobal fileencoding=iso-8859-2default for new files Best regards, Tony. -- The First Commandment for Technicians: Beware the lightening that lurketh in the undischarged capacitor, lest it cause thee to bounce upon thy buttocks in a most untechnician-like manner.
Re: Is there a xml formatter?
fREW wrote: Or just try gg=G after you had opened your xml file. 4) to reformat an existing file: gggqG What is the actual difference of these two commands? I usually use = for code and gq for text, so I presumed that one was for formatting and one was for 'linewidth'ing. You may be right. For the exact differences, lookup :help = :help gq Best regards, Tony. -- GOD: That is your purpose Arthur ... the Quest for the Holy Grail ... Monty Python and the Holy Grail PYTHON (MONTY) PICTURES LTD
Re: JSVI: Vi implemented in Javascript
Kevin Old 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 Hmm... when's the day when Vim will be implemented in Lisp, so if the boss wants everyone to use Emacs, we can obey and still have the look, feel and functionality of Vim? (Not necessarily the speed, though.) Best regards, Tony. -- It says he made us all to be just like him. So if we're dumb, then god is dumb, and maybe even a little ugly on the side. -- Frank Zappa
Re: JSVI: Vi implemented in Javascript
Tobias Klausmann wrote: Hi! On Wed, 30 May 2007, A.J.Mechelynck wrote: [...] Hmm... when's the day when Vim will be implemented in Lisp, so if the boss wants everyone to use Emacs, we can obey and still have the look, feel and functionality of Vim? (Not necessarily the speed, though.) Of course, that has already been done. It's called viper: http://www.delorie.com/gnu/docs/emacs/viper.html Viper Is a Package for Emacs Rebels. Nice Backronym, too. Regards, Tobias PS: I don't know if it's pure lisp. But hey, I don't need it :) Neither do I know, neither do I need it, and Emacs-script is rumored to be Lisp, but since I don't use Emacs (and never did, except maybe for just a few minutes until I found out it wasn't the editor for me), and never used Lisp either (I just know it uses way too much parentheses for sanity) so I don't rightly know. Best regards, Tony. -- In the long run, every program becomes rococo, and then rubble. -- Alan Perlis
Re: No Previous Regular expression
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. Any help is welcome. thanks tim 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'. By default (unless set otherwise in the vimrc), in 'compatible' mode 50 lines for each register, and 20 lines of history, are remembered. If you mean in the same Vim session (e.g. by doing :e bar.txt after searching in foo.txt), then the search pattern should be remembered, unless there is something which explicitly clears it. An autocommand or a mapping, invoking :let @/ = '', could be such a something. Best regards, Tony. -- The cry has been that when war is declared, all opposition should therefore be hushed. A sentiment more unworthy of a free country could hardly be propagated. If the doctrine be admitted, rulers have only to declare war and they are screened at once from scrutiny ... In war, then, as in peace, assert the freedom of speech and of the press. Cling to this as the bulwark of all our rights and privileges. -- William Ellery Channing
Re: Why bottom-posting is prefered on Vim Mainling List?
Michael Henry wrote: [...] I continue to be impressed by the Vim mailing list. Contributors are helpful, willing to spend time answering in detail, and above all very polite. This is one of the nicest top- versus bottom-posting discussions I've seen on a mailing list :-) Michael Henry Yes indeed. In many a ML/NG I have known, this discussion would have long before degenerated into throwing animal names. Best regards, Tony. -- About the time we think we can make ends meet, somebody moves the ends. -- Herbert Hoover
Re: Why bottom-posting is prefered on Vim Mainling List?
Matthew Winn wrote: [...] I've seen similar debates elsewhere where the top-poster's response has been along the lines of This is my Internet on my computer; I'm going to behave how I want and I don't care how much trouble I cause for other people. :D :D :D Best regards, Tony. -- Executive ability is deciding quickly and getting somebody else to do the work. -- John G. Pollard
Re: Why bottom-posting is prefered on Vim Mainling List?
Yakov Lerner wrote: On 5/28/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: As far as I know, most e-mail clients defaults to top-posting some email clients have an option. But it does not help much. Top-vs-bottom depends on the specific mailing list. If I am on mailing list X which has convention of bottom-posting and also on mailing list Y which has convention of top-posting, then single option in mail client is not much helpful. gmail doesn't have this option at all, but I dont feel invonvenienced. Yakov Some mailers, such as Thunderbird which I use, have a thing named identities: I can set one or more identities for a each mail or news account, and quoting preference (quote or not, and put the cursor above or below the quote) is among the options I can set for each identity. Of course, webmail accounts use browsers, not email clients, which means the webmail provider makes its own rules and the customer has no choice of interface. (As you can guess, I don't like webmail.) Best regards, Tony. -- A Mormon is a man that has the bad taste and the religion to do what a good many other people are restrained from doing by conscientious scruples and the police. -- Mr. Dooley
Re: mbox format archive?
[EMAIL PROTECTED] wrote: hi i'd like to get as large an archive as possible of this list in mbox format. Looking around I don't see any archive in mbox format surprisingly, does anyone know if this exists? thanks! I've been archiving the vim, vim-dev and vim-multibyte lists locally, ever since I switched over to Linux. The file is 19 meg by now. Shall I send it to you as attachment by private email? Best regards, Tony. -- GALAHAD: Camelot ... LAUNCELOT: Camelot ... GAWAIN:It's only a model. Monty Python and the Holy Grail PYTHON (MONTY) PICTURES LTD
Re: mbox format archive?
steven smith wrote: A.J.Mechelynck wrote: [EMAIL PROTECTED] wrote: [...] I've been archiving the vim, vim-dev and vim-multibyte lists locally, ever since I switched over to Linux. The file is 19 meg by now. Shall I send it to you as attachment by private email? Please make sure you strip out any email addresses before you do that. Thank you Steve S. No. Either you get it as it came through the list, or you don't; I'm not gonna lose timeeffort at editing a file which I'm providing as is as a convenience to some other Vimmer. Email addresses were sent to the list, so what's the matter? Best regards, Tony. -- The opposite of a profound truth may well be another profound truth. -- Bohr
Re: VimWiki - First Beta
Sebastian Menge wrote: Am Dienstag, den 29.05.2007, 02:45 -1100 schrieb Yakov Lerner: On 5/29/07, Sebastian Menge [EMAIL PROTECTED] wrote: Hi all Access the first beta here: http://tinyurl.com/34kfj5 Where can I see the recently posted/by recency view ? In other words, what's used for RSS ? It's a quick and dirty installation on my machine, probably RSS is an extension that is not installed. That will change on vim.wikia.com. Recent Changes in HTML-Form can be found here: http://tinyurl.com/34kfj5/index.php/Special:Recentchanges Seb. That URL is broken; use the following: http://tinyurl.com/34kfj5/Special:Recentchanges otherwise index.php gets duplicated, leading to Page not found, do you wish to create it? Best regards, Tony. -- $100 invested at 7% interest for 100 years will become $100,000, at which time it will be worth absolutely nothing. -- Lazarus Long, Time Enough for Love
Re: mbox format archive?
Ali Polatel wrote: A.J.Mechelynck [EMAIL PROTECTED] yazmış: [EMAIL PROTECTED] wrote: hi i'd like to get as large an archive as possible of this list in mbox format. Looking around I don't see any archive in mbox format surprisingly, does anyone know if this exists? thanks! I've been archiving the vim, vim-dev and vim-multibyte lists locally, ever since I switched over to Linux. The file is 19 meg by now. Shall I send it to you as attachment by private email? Hi, I was reading the vim mailing list today and saw this post :) I would be very happy if you can send me the archives of vim and vim-dev when you have time.. thanks! Hmm... This post of mine seems to be eliciting two kinds of reactions: Me too, me too and Don't, you fool, he may be a spammer harvesting addresses. I think I'll leave it on the backburner for a while, waiting for the situation to clarify. Comments, anyone? Best regards, Tony. -- We're knights of the round table We dance whene'er we're able We do routines and chorus scenes With footwork impeccable. We dine well here in Camelot We eat ham and jam and spam a lot. Monty Python and the Holy Grail PYTHON (MONTY) PICTURES LTD
Re: mbox format archive?
Tim Chase wrote: Hmm... This post of mine seems to be eliciting two kinds of reactions: Me too, me too and Don't, you fool, he may be a spammer harvesting addresses. I think I'll leave it on the backburner for a while, waiting for the situation to clarify. Comments, anyone? This is the vim list, after all...surely a quick regexp to mangle/hide the email adderesses could be applied across any such files? I don't know the inner workings of mbox (all in one file? multiple files in one directory?), but some short work with argdo should take care of it :) mbox is (IIUC) the format used by Thunderbird, Outlook Express (but not Outlook), and many other mailers for what they misleadingly call email folders. Each folder is a single file (from the OS's viewpoint). Email headers are included. Any munging I would do would be applied equally to headers and body. sh$ cd /path/to/vim/mbox sh$ mkdir ../munged sh$ cp * ../munged sh$ cd ../munged sh$ vim * :set hidden :argdo %s/[EMAIL PROTECTED])+/\=substitute(substitute(submatch(0), '\.', ' [DOT] ', 'g'), '@', ' [AT] NoSpAm.', 'g')/g :wqa sh$ cd .. sh$ tar cvfz vim_ml.tgz munged It may mung a bit more or less redacting than one actually wants, but for the most part, it should stave off the fears that the OP is a spam harvester. My inkling is that such is not the case...there are a lot more fertile grounds for harvesting addresses than personally asking for mbox files in a place as niche as the vim ML. And if targeting the mass audience, I suspect they would as for an Outlook/OE .PST file instead of mbox :) My Turing-test-o-meter is registering fairly high on the it's a human scale. :) -tim Best regards, Tony. -- If the colleges were better, if they really had it, you would need to get the police at the gates to keep order in the inrushing multitude. See in college how we thwart the natural love of learning by leaving the natural method of teaching what each wishes to learn, and insisting that you shall learn what you have no taste or capacity for. The college, which should be a place of delightful labor, is made odious and unhealthy, and the young men are tempted to frivolous amusements to rally their jaded spirits. I would have the studies elective. Scholarship is to be created not by compulsion, but by awakening a pure interest in knowledge. The wise instructor accomplishes this by opening to his pupils precisely the attractions the study has for himself. The marking is a system for schools, not for the college; for boys, not for men; and it is an ungracious work to put on a professor. -- Ralph Waldo Emerson
Re: mbox format archive?
fREW wrote: [...] The interesting thing is that the guy who is in question of being a spammer is the same guy who asked for safeguards against that type of thing... no, he isn't; it was requested by [EMAIL PROTECTED] (and later by Ali Polatel), and warned against by steven smith. If my reply to the latter gave the (false) impression that he was the same as the former, it may be because I was a little confused at the time. Best regards, Tony. -- It was a virgin forest, a place where the Hand of Man had never set foot.
Re: mbox format archive?
[EMAIL PROTECTED] wrote: Ehehe never mind about this, I had no idea this would stir everyone up. I consider it fairly normal for list archives to be offered in mbox format (ex. Lua and Template Toolkit and 5 million others) and like to keep them around, since I can just drop them right into local folders in thunderbird for searching. Especially handy for offline, and for not having to rely on someone's frontend to search the archives for difficult to find things, that I know are buried someplace in the archive. Looking at the commands I can issue to the listmanager, looks like I can whip out something that will make me an archive so all good. thanks for your offer though AJ. A. My pleasure. Best regards, Tony. -- Experience is something you don't get until just after you need it. -- Olivier
Re: mbox format archive?
fREW wrote: On 5/29/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Ehehe never mind about this, I had no idea this would stir everyone up. I consider it fairly normal for list archives to be offered in mbox format (ex. Lua and Template Toolkit and 5 million others) and like to keep them around, since I can just drop them right into local folders in thunderbird for searching. Especially handy for offline, and for not having to rely on someone's frontend to search the archives for difficult to find things, that I know are buried someplace in the archive. Looking at the commands I can issue to the listmanager, looks like I can whip out something that will make me an archive so all good. thanks for your offer though AJ. A. I don't think you are a spammer/bot! :-) Certainly not a bot. A spammer -- I don't think so either. Thinking back on it, I think it would be better if aff can get it by querying the listbot, because from time to time I've been moving private mail by Vimmers to that same archive folder. Best regards, Tony. -- Festivity Level 1: Your guests are chatting amiably with each other, admiring your Christmas-tree ornaments, singing carols around the upright piano, sipping at their drinks and nibbling hors d'oeuvres. Festivity Level 2: Your guests are talking loudly -- sometimes to each other, and sometimes to nobody at all, rearranging your Christmas-tree ornaments, singing I Gotta Be Me around the upright piano, gulping their drinks and wolfing down hors d'oeuvres. Festivity Level 3: Your guests are arguing violently with inanimate objects, singing I can't get no satisfaction, gulping down other peoples' drinks, wolfing down Christmas tree ornaments and placing hors d'oeuvres in the upright piano to see what happens when the little hammers strike. Festivity Level 4: Your guests, hors d'oeuvres smeared all over their naked bodies are performing a ritual dance around the burning Christmas tree. The piano is missing. You want to keep your party somewhere around level 3, unless you rent your home and own Firearms, in which case you can go to level 4. The best way to get to level 3 is egg-nog.
Re: VimWiki - First Beta
Yongwei Wu wrote: HI Sebastian, On 29/05/07, Sebastian Menge [EMAIL PROTECTED] wrote: Hi all Access the first beta here: http://tinyurl.com/34kfj5 [snipped] Please give feedback! From this page: http://ls10pc13.cs.uni-dortmund.de/mediawiki/index.php/AES256_Encryption_in_vim_done_easy. I realized that `#' is interpreted as numbering in MediaWiki and needs some special processing. Maybe it is better to do so from your script. I have no idea how to escape it. I haven't tried but I can imagine either #35; or nowiki#/nowiki Not sure whether they both work. Best regards, Yongwei Best regards, Tony. -- When I was crossing the border into Canada, they asked if I had any firearms with me. I said, `Well, what do you need?' -- Steven Wright
[Fwd: Re: VimWiki - First Beta]
Forward to list. Best regards, Tony. Original Message Subject: Re: VimWiki - First Beta Date: Tue, 29 May 2007 16:25:35 -0600 From: fREW [EMAIL PROTECTED] To: A.J.Mechelynck [EMAIL PROTECTED] References: [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] On 5/29/07, A.J.Mechelynck [EMAIL PROTECTED] wrote: Yongwei Wu wrote: HI Sebastian, On 29/05/07, Sebastian Menge [EMAIL PROTECTED] wrote: Hi all Access the first beta here: http://tinyurl.com/34kfj5 [snipped] Please give feedback! From this page: http://ls10pc13.cs.uni-dortmund.de/mediawiki/index.php/AES256_Encryption_in_vim_done_easy. I realized that `#' is interpreted as numbering in MediaWiki and needs some special processing. Maybe it is better to do so from your script. I have no idea how to escape it. I haven't tried but I can imagine either #35; or nowiki#/nowiki I think the nowiki syntax is preferred for stuff like that. -- -fREW
Re: Why bottom-posting is prefered on Vim Mainling List?
Friedrich Strohmaier wrote: [...] btw. I join the voices that price the nice way people are discussing even that (off-)topic on this list. Vimmers seem to be a special kind of civilized people. :o)) About being off-topic: IMO netiquette questions about a list are always on-topic on that same list, unless maybe there is another list in the same family (i.e., in this case, @vim.org) which is explicitly dedicated to netiquette questions. About politeness and civilization: We all learn by example. ;-) Best regards, Tony. -- 'Twas the nocturnal segment of the diurnal period preceding the annual Yuletide celebration, And throughout our place of residence, Kinetic activity was not in evidence among the possessors of this potential, including that species of domestic rodent known as Mus musculus. Hosiery was meticulously suspended from the forward edge of the woodburning caloric apparatus, Pursuant to our anticipatory pleasure regarding an imminent visitation from an eccentric philanthropist among whose folkloric appelations is the honorific title of St. Nicklaus ...
Re: Why bottom-posting is prefered on Vim Mainling List?
Dave Land wrote: On May 29, 2007, at 4:22 AM, Matthew Winn wrote: I've seen similar debates elsewhere where the top-poster's response has been along the lines of This is my Internet on my computer; I'm going to behave how I want and I don't care how much trouble I cause for other people. Trimming _and_ bottom-posting, Dave Land replies: On another list, one of the members insisted on sending HTML posts where the font was HHH HHH UUU UUU EE H H U U G E H U U G GGG EEE H H U U G G E HHH HHH UUUGGG EE His argument was that he had visual problems, so he had to use a large font. He was quite incensed that people were bothered by his ENORMOUS emails, and he couldn't be bothered to figure out how to make it so that he could see it just fine on his computer without sending 40-point fonts to everyone else. I believe it deteriorated to the point where the poster in question was hurling four-letter words at anyone who challenged him. The list master eventually turned off HTML posts. I'm glad that this list is so much more civilized. Dave The irony of it is that it's so much easier to set a large font for reading when all the posts are in plaintext. Best regards, Tony. -- If you stick a stock of liquor in your locker, It is slick to stick a lock upon your stock. Or some joker who is slicker, Will trick you of your liquor, If you fail to lock your liquor with a lock.
Re: breakindent, take 2
Yakov Lerner wrote: On 5/14/07, Václav Šmilauer [EMAIL PROTECTED] wrote: Hello, I submit patch that implements the 'breakindent' feature. It is on vim todo list, since the moment I tried a few years ago (see e.g. http://marc.info/?l=vim-devm=109921292009721w=1). Picture says what it's about (showbreak is aligned with first non-whitespace): http://beta.arcig.cz/~eudoxos/vim7/breakindent1.png http://beta.arcig.cz/~eudoxos/vim7/breakindent2.png I tried to address all Bram's comments he had to the original patch, like coding style, functionality in diff mode, selections etc. I had to change a few prototypes to pass line number. There is one bug and some (easily fixable) limitations: * BUG: there is some weird interaction with quickfix window, where very rarely there is the ml_get(): invalid line number error. I think it is caused by passing wrong line number thgouth the *chartabsize* family routines (line in the main buffer interpreted as line in the quickfix window or something like that), but I am not sure. * No test case. This will be added once there is enough interest from developers (there _is_ documentation). * The bri_min variable is not exposed to userspace yet, is set to 20 in the code. If the rest is considered ready for inclusion, I will add a user-serrable variable for that. The patch is against current svn (vim7, rev. 288). Any comments are welcome. I played with the patch. Works smoothly, I did not find any deficiencies. I have one wish though. It would be nice if I could specificy additional indent for continuation lines. You make indent for continuation line *EQUAL* to indent of the 1st screen line. Let's say you have 3 consequitive long lines with same indent, and each lines wrapped into 4 screen lines. With current 'breakindent' patch, you see 8 lines with *same* indent. It's not that easy to see beginning of each long lines. If breakindent would be numeric value N which meant assign indent K+N to continuation indent, where K is indent of the line itself. Current breakindent corresponds to N==0. But I'd probably prefer N=1 or N==2. Just my 2 cents Thanks Yakov ** nobreakindent line1line1line1line1 line1line1line1line line2line2line2line2 line2line2line2line ** breakindent=0 line1line1line1line1 line1line1line1line line2line2line2line2 line2line2line2line ** breakindent=2 line1line1line1line1 line1line1line1line line2line2line2line2 line2line2line2line ** With this change plus 'linebreak' on, it could be made to simulate French paragrah style for text, where the first line of a paragraph starts maybe 1em or so right of the left margin (but with no blank line, unlike American paragraph style which uses flush-left alignment with a blank line between paragraphs). Thus breakindent=0 flush left (as above) breakindent=-3 French style with first line indented 3 spaces, as follows: The quick brown fox jumps over the lazy dog. The quick brown fox jumps over the lazy dog. The quick brown fox jumps over the lazy dog. Line two starts here; neither line goes back to the left margin of the Vim window. The lazy dog is jumped over by the quick brown fox. The lazy dog is jumped over by the quick brown fox. The lazy dog is jumped over by the quick brown fox. breakindent=2 all lines except the first indented 2 spaces (as you show above) A single option cannot be both boolean and integer; if a negative number is greater than the 1st line indent, don't go back farther left than the left margin of the window; thus breakindent=-999 would agree with your first example. Best regards, Tony. -- Sex is a natural bodily process, like a stroke.
Re: VimWiki - Page Titles
John Beckett wrote: Sebastian Menge wrote: Find the list (95 entries) here: http://scratchpad.wikia.com/wiki/Errornames Thanks for the good start. FYI there are a couple of lines with broken links: 157 160: 171: Do you know the g/ and g? commands? Above gives: Vim Online Error Couldn't find tip 160. Are you sure it exists? Im not sure howto proceed here. Should we a) find better titles before the import Yes! In option (b), you have to change every '/' to '__OR__', so you may as well change the titles to something good now. Can you readily do something like this: Put each tip in a separate file on your disk. Name them tip0001, tip0002, etc. Put the list of 1500 tip titles in one file, one title per line. Then edit that file to clean up the titles. Then run a script to rename each tip to match the cleaned-up title. or b) replace '/' by sth like '__OR__' and fix the whole title later? Whatever works, but wouldn't this create a whole bunch of problems? I don't understand the internals of wikis but I think your suggestion would create 95 tips with URLs that will later need to be manually edited. Not so easy, and probably involves copying the content from the wiki to a new page, then deleting the old page (I guess). [...] This is where my redirect suggestion comes into play (assuming wiki software compatible to that used at ??.wikipedia.org): First pass: migration proper. For each tip, create *two* wiki pages: - one page with the tip text and a real title, possibly doctored as shown above - one page titled Vim tip 1 Vim tip 2 etc. (url ending in .../Vim_tip_1 etc.) with only a redirect, as follows: (url=something/Vim_tip_1) #REDIRECT [[The super star]] During this first pass, any link vimtip#3456 gets translated to [[Vim tip 3456]] pointing to the redirect page for the link pointed to. At this time the actual name of the link pointed to doesn't have to be known, and in the case of forward comments it _won't_ yet be known. Second pass (after all tips have been migrated and the wiki software has had the time to cycle and reconstruct its indexes) For each redirect page: open it with ?noredirect and get the corresponding What points here page, as delivered by the wiki software. Change links pointing to the redirect into links pointing to the (now known) actual page title. IIUC this can be done by a robot (i.e., a script, not a human). Best regards, Tony. -- If you're not very clever you should be conciliatory. -- Benjamin Disraeli
Re: VimWiki - Page Titles
Sebastian Menge wrote: Am Montag, den 28.05.2007, 16:18 +0200 schrieb A.J.Mechelynck: This is where my redirect suggestion comes into play (assuming wiki software I took your advice silently. Your suggestion is already in the script. Sebastian. well, sorry I didn't look at the script, but it seemed to solve John's objection. Best regards, Tony. -- Interpreter, n.: One who enables two persons of different languages to understand each other by repeating to each what it would have been to the interpreter's advantage for the other to have said. -- Ambrose Bierce, The Devil's Dictionary
Re: A performance question (patch included)
Charles E Campbell Jr wrote: A.J.Mechelynck wrote: I'm not sure what varnumber_T means: will st.stsize (the dividend) be wide enough to avoid losing bits on the left? varnumber_T is int (long if an sizeof(int) = 3). st.stsize 's size depends on whether 32bit or 64bit integers are available. So, its possible to lose bits: pick a small enough unitsize and a large enough file, st.stsize will end up not being able to fit into a varnumber_T. After all, unitsize could be 1, and getfsize() will behave no differently than it does now. However, unitsize could be 100. My patch divides st.stsize by the unitsize first; presumably in whatever arithmetic is appropriate for working with st.stsize. Regards, Chip Campbell Yes, yes, but before the division, will it be able to hold the file size? (sorry, I meant st.st_size) Will mch_stat (at line 10134, one line before the context of your patch) be able to return huge file sizes? Best regards, Tony. -- Real Programmers don't play tennis, or any other sport that requires you to change clothes. Mountain climbing is OK, and real programmers wear their climbing boots to work in case a mountain should suddenly spring up in the middle of the machine room.
Re: A performance question (patch included)
Yakov Lerner wrote: [...] stat() on Linux has 32-bit st_size field (off_t is 32-bit). There is stat64() syscall which uses 'struct stat64' structure where st_size is 64-bit. By defining __USE_LARGEFILE64 at compile-time, stat() is redirected to stat64(). I don't know whether default Linux vim build defines __USE_LARGEFILE64 or not. Yakov :version says: [...] Compilation: gcc -c -I. -Iproto -DHAVE_CONFIG_H -DFEAT_GUI_GTK -I/usr/include/cairo -I/usr/include/freetype2 -I/usr/include/libpng12 -I/opt/gnome/include/gtk-2.0 -I/opt/gnome/lib/gtk-2.0/include -I/opt/gnome/include/atk-1.0 -I/opt/gnome/include/pango-1.0 -I/opt/gnome/include/glib-2.0 -I/opt/gnome/lib/glib-2.0/include -DORBIT2=1 -pthread -I/usr/include/libart-2.0 -I/usr/include/cairo -I/usr/include/freetype2 -I/usr/include/libpng12 -I/usr/include/libxml2 -I/opt/gnome/include/libgnomeui-2.0 -I/opt/gnome/include/libgnome-2.0 -I/opt/gnome/include/libgnomecanvas-2.0 -I/opt/gnome/include/gtk-2.0 -I/opt/gnome/include/gconf/2 -I/opt/gnome/include/libbonoboui-2.0 -I/opt/gnome/include/gnome-vfs-2.0 -I/opt/gnome/lib/gnome-vfs-2.0/include -I/opt/gnome/include/gnome-keyring-1 -I/opt/gnome/include/glib-2.0 -I/opt/gnome/lib/glib-2.0/include -I/opt/gnome/include/orbit-2.0 -I/opt/gnome/include/libbonobo-2.0 -I/opt/gnome/include/bonobo-activation-2.0 -I/opt/gnome/include/pango-1.0 -I/opt/gnome/lib/gtk-2.0/include -I/opt/gnome/include/atk-1.0 -O2 -fno-strength-reduce -Wall -D_REENTRANT -D_GNU_SOURCE -DTHREADS_HAVE_PIDS -DDEBUGGING -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -I/usr/lib/perl5/5.8.8/i586-linux-thread-multi/CORE -I/usr/include/python2.5 -pthread -I/usr/include -D_LARGEFILE64_SOURCE=1 -I/usr/lib/ruby/1.8/i586-linux Linking: [...] so, maybe we'll have to check what happens when _LARGEFILE64_SOURCE is defined? I don't find a match in src/ or src/auto/. Best regards, Tony. -- If all these sweet young things were laid end-to-end, I wouldn't be a bit surprised. -- Dorothy Parker
Re: taglist: ctrl ] azerty
Mathieu Malaterre wrote: Hello there, I am trying to use taglist on my AZERTY keyboard and I cannot get ctrl ] to work. If I type :ts + tagname I can see that taglist is working. thanks, I also have an AZERTY keyboard, and neither do I know whether (and where) it has Ctrl-] but that doesn't bug me because of the following mapping: :mapF9 C-] Best regards, Tony. -- If you're right 90% of the time, why quibble about the remaining 3%?
Re: A performance question
John Beckett wrote:
Charles E Campbell Jr wrote:
Sounds like the filesize is getting stored in a 32bit signed
number, and overflowing.
Yes, definitely.
Please let me know what getfsize() is actually returning
The return value is the bit pattern for the low 32 bits of the
true 64-bit file size:
3,146,839,490 file actual size
-1,148,127,806 returned by getfsize()
The sum of the absolute values is exactly 4G. I confirmed the
above with a file exactly 8G + 512 bytes (getfsize() said it was
512 bytes).
I was going to suggest that you treat a negative getfsize()
value as a large file (may as well do that even if the value is
-1 for an error indication).
I suppose that would be useful until some better solution is
implemented. I didn't propose it because it would be quite ugly
for the script to give results like this:
3GB file is large
5GB file is not large
7GB file is large
9GB file is not large
Another ugly (but accurate) workaround would be:
- Provide the source for a small executable called islargefile
to do the calculation.
- Provide an option in the script to use the executable.
- Have the script execute system('islargefile xxx 123456').
Return value 0 means no, 1 means yes, 2 means error
(return is first character of system() string).
Need to work out how to pass arguments:
xxx = path of file to be tested
123456 = limit at which file is large
John
What about a different function to return, say, the number of 1K blocks (or
the number of times 2^n bytes, with a parameter passed to the function) that a
file uses?
Best regards,
Tony.
--
hundred-and-one symptoms of being an internet addict:
252. You vote for foreign officials.
Re: A performance question
John Beckett wrote: Yongwei Wu wrote: Even FAT32 supports files much larger than 4GB. Not true. FAT32 supports files up to 4 GB. Sorry I shot my mouth off there - I realised my blunder about ten minutes after sending. I haven't actually used a FAT32 partition for over ten years, and was confusing the maximum size of a FAT32 partition with its maximum file size. On NTFS of course, as you mentioned, the sky is the limit. I have made files larger than 4GB, and have written a couple of simple programs to work with such files, so my basic point is valid. The Win32 API supports files much larger than 4GB. John ...not to mention Unix/Linux, with its variety of not only FAT12, FAT16, FAT32 and NTFS but also ext2, ext3, reiserfs, etc., supported. I see a backups.tgz file of 7GB (which normally isn't mounted) so big files exist here too. Best regards, Tony. -- While I, with my usual enthusiasm, Was exploring in Ermintrude's busiasm, She explained, They are flat, But think nothing of that -- You will find that my sweet sister Susiasm.
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: 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
Robert M Robinson wrote: First, thanks very much for creating VIM! I have been using it on Linux systems for years, and now use it via cygwin at home as well. I vastly prefer VIM to EMACS, especially at home. I learned vi on a VAX/VMS system long ago (a friend of mine had ported it), when our computer science department was loading so many people on the VAXen that EDT was rendered unusably slow. I still like VIM largely because I can do so much with so little effort in so little time. 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! Seriously, going to line 1 million of a 2 million line file and typing the command :.,$d takes _minutes_ on my system (Red Hat Linux on a 2GHz Athlon processor (i686), 512kb cache, 3 Gb memory), far longer than searching the entire 2 million line file for a single word (:g/MyQueryName/p). Doing it this way fits way better into my usual workflow than using head -n 100, because of course I'm using a regular expression search to determine that I want to truncate my file at line 100 in the first place. I looked in the archive, and couldn't see that this issue had been raised before. Is there any chance it can get added to the list of performance enhancement requests? Thanks, Max Robinson, PhD I think this is just part of how Vim behaves. When you edit a file, Vim holds the whole file in memory (IIUC). When you delete a million lines, Vim frees (i.e., releases to the OS) the memory those lines were using. That takes some time. Best regards, Tony. -- hundred-and-one symptoms of being an internet addict: 250. You've given up the search for the perfect woman and instead, sit in front of the PC until you're just too tired to care.
doc bug: 'browsedir'
In
*options.txt* For Vim version 7.1. Last change: 2007 May 11
under 'browsedir', at line 1151, there is:
{not in Vi} {only for Motif and Win32 GUI}
Actually, this option is functional in my GTK2/Gnome GUI.
Best regards,
Tony.
--
The day after tomorrow is the third day of the rest of your life.
Re: Save as not responding
Smoldas Vladimir wrote: Hi, I have a problem to execute: browse confirm saveas (or save as from menu list) on new file (without name). Steps to simulate the problem: 1.Open gvim 2. Save as (browse confirm saveas) - gvim not responding for 5 minutes (than I killed him) But when I open existing file it's works well... Thanks Vladimír Šmoldas SOFTIP a.s. Works for me VIM - Vi IMproved 7.1 (2007 May 12, compiled May 15 2007 09:20:56) Included patches: 1-2 Compiled by [EMAIL PROTECTED] Huge version with GTK2-GNOME GUI. Features included (+) or not (-): [...] Best regards, Tony. -- Admiration, n.: Our polite recognition of another's resemblance to ourselves. -- Ambrose Bierce, The Devil's Dictionary
Re: Save as not responding
Smoldas Vladimir wrote: Sorry I forgot to attach environment info: Vim 7.1 (2007 May 12,compiled May 12...) Windows XP SP2 But, I have installed this version today only.. I will try install the version you mentioned. Regards Vladimír Šmoldas The version I'm using is a Linux version; but for Windows, you can download an equivalent version (with precompiled executables and full runtime files) from https://sourceforge.net/project/showfiles.php?group_id=43866package_id=39721 Best regards, Tony. -- If you're right 90% of the time, why quibble about the remaining 3%?
[Fwd: RE: Save as not responding]
Forward to list. Original Message Subject: RE: Save as not responding Date: Mon, 21 May 2007 11:33:17 +0200 From: Smoldas Vladimir [EMAIL PROTECTED] To: A.J.Mechelynck [EMAIL PROTECTED] References: [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] Thanks for replay I checked that I have the latest version available for Windows OS. Before 7.1 version, I had 7.0 version and from maybe two weeks ago, I have the problem with save as... Vladimír Šmoldas SOFTIP a.s. -Original Message- From: A.J.Mechelynck [mailto:[EMAIL PROTECTED] Sent: Monday, May 21, 2007 11:26 AM To: Smoldas Vladimir Cc: 'Vim mailing list' Subject: Re: Save as not responding Smoldas Vladimir wrote: Sorry I forgot to attach environment info: Vim 7.1 (2007 May 12,compiled May 12...) Windows XP SP2 But, I have installed this version today only.. I will try install the version you mentioned. Regards Vladimír Šmoldas The version I'm using is a Linux version; but for Windows, you can download an equivalent version (with precompiled executables and full runtime files) from https://sourceforge.net/project/showfiles.php?group_id=43866package_id=39721 Best regards, Tony. -- If you're right 90% of the time, why quibble about the remaining 3%?
Re: C-X C-F completion and paths with spaces
Matthew Winn wrote: On Sat, 19 May 2007 19:43:46 +0200, A.J.Mechelynck [EMAIL PROTECTED] wrote: It seems that the 'isfname' option doesn't include a space by default. But is that right? On both Windows and Unix, a filename may include spaces (though special steps must be taken to include such names in a command-line). Having a space in isfname by default would cause problems when trying to use gf. Vim would try to treat both the intended filename and all the surrounding spaces and words as part of the name. On Unix a filename may contain any character apart from slash or null, but the potential for problems is avoided by an informal policy of never creating names containing characters that are regularly used as delimiters. I can't begin to imagine why Microsoft thought it would be a good idea to put spaces in the names of system directories, but I guess the environment was probably something like the final panel of http://www.giantitp.com/comics/oots0130.html. Or else, the decision was made by some suit with the same mentality as a flight admiral who never flew anything other than a desk. Best regards, Tony. -- The years of peak mental activity are undoubtedly between the ages of four and eighteen. At four we know all the questions, at eighteen all the answers.
Re: How to get value of ~ (last used replace-to string) in script
Tim Chase wrote: In a script, how do I get the value of ~ -- the last used replace-to string, as used in s//~/ ? While I've wondered this in the past, and don't have an answer at the moment, I found a small bug in the help text (or in the :help command) while hunting. In Vim7, if I type :help ~ and hit control+D to expand the available help items, one of them is s/\~ However, if I type :help s/\~ and hit enter, Vim returns E33: No previous substitute regular expression E149: Sorry, no help for s/\~ According to a helpgrep (which had to be entered as :helpgrep s/\\\~ ), there's only one location in the help where this matches, right next to :help s~ I suspect it's a bug for control+D expansion to return something that, if chosen as the help tag, refuses to jump there. -tim I don't get an error but I get a wrong matching anyway. Here, :help s/\~ goes to the helptag for s/\ (s/\~ is 12 lines further down). To find the tag for s/\~ I have to enter :help s/\\~. :help s/\\\~ jumps to s/\\ Best regards, Tony. -- Most people wouldn't know music if it came up and bit them on the ass. -- Frank Zappa
Re: How to compile graphical Vim on Mandriva 2007?
Steve Litt wrote: On Sunday 20 May 2007 15:51, you wrote: On 5/20/07, Steve Litt [EMAIL PROTECTED] wrote: Hi all, I tried to compile graphical Vim 7.1 on Mandriva 2007. I downloaded vim-7.1.tar.bz2, untarred it, and did the following from the top level directory created (vim71): ./configure --enable-gui make src/vim -g The following error message appeared: E25: GUI cannot be used: Not enabled at compile time I retried, after make distclean, with the following configure options: enable-gui=gtk enable-gui=gtk2 enable-gui=auto All produced the same error: E25: GUI cannot be used: Not enabled at compile time I chose not to perform make install in order to preserve the integrity of my existing Vim 7.0 that came with Mandriva 2007. Anyone know how to compile graphical Vim on Mandriva 2007, or at least some diagnostic tests I can use to narrow down the problem? You need to install gtk2-devel package. Also, the x11-devel package if it's not installed. The exact names of packages may vary between distributions. But the idea is, you are missing development packages (*-devel or *-dev) needed to compile GUI functionality of vim. Thanks Yakov, I can't find them anywhere in the distribution packages. Funny thing is, Gnome works, and Mandriva managed to get a working 7.0 version of gvim installed on the machine as a package. Is there any way I can look at the error message and find out exactly what filename it's looking for? Perhaps it's just a missing symlink. Thanks SteveT Steve Litt Author: Universal Troubleshooting Process books and courseware http://www.troubleshooters.com/ If you redirected your configure output (saving it as a logfile on disk) you can look into tyhat logfile, searching for anything unexpected. Then, regardless of whether you logged configure output, there's the file src/auto/config.log, which traces in much more detail what happened during configure. Note that for Vim, you don't need to run configure as a separate step: make (if there is no config cache), make config or make reconfig will invoke it; see my HowTo sheet http://users.skynet.be/antoine.mechelynck/compunix.htm for details. I agree with Yakov that you probably lack the development packages required to compile Vim (they are not needed to run a precompiled Vim binary). Search your installation source (CD-ROM, online repository, whatever) for packages with names similar (but not necessary identical) to ncurses-devel gtk2-devel xorg-x11-devel and maybe more, depending on which features you want to include. If you can search package names, try to see all packages including devel (or maybe -dev) in them, include any of them that you may need, and when in doubt about some package, include it. Then if you installed from a CD (which will always be slightly out-of-date even on the day you buy it), do an online update of your whole system (or whatever Mandriva calls it), and after that, set your environment options (as shown in my above-mentioned HowTo page), cd to the vim71/src directory (for building: there is no src/ subfolder in $VIMRUNTIME) and run make reconfig 21 |tee ../reconfig.log This normally runs configure and proceeds to compile and link. If it produces a Vim executable (in the current src/ folder), run ./vim --version |more and, if it looks OK, cd .. make install 21 |tee install.log If, instead, it produces no executable, or if you don't get the features you wanted, check the logs, and try to find some more packages you might lack. Best regards, Tony. -- He thought he saw an albatross That fluttered 'round the lamp. He looked again and saw it was A penny postage stamp. You'd best be getting home, he said, The nights are rather damp.
Re: repeating up/down/delete commands
[EMAIL PROTECTED] wrote: A.J.Mechelynck [EMAIL PROTECTED] 写于 2007-05-19 15:42:15: This is true, but rather than an empty vimrc I suggest the following: runtime vimrc_example.vim if and when we want to further customize Vim, we'll add more lines below Best regards, Tony. -- I always recommend include the contents of vimrc_example.vim instead of just source the file by :runtime. By including the contents of vimrc_example.vim we know all it has done and we can change it anyway. i.e. chang the .vimrc is a good way, changing the $VIMRUNTIME/vimrc_example.vim is NOT a good pratice. (vimrc_example fits the need of the author but it definetely do not fit everyone, so I suggest most users to change it and create their own .vimrc.) The second reason: vimrc_example.vim comes from the distribution and it may change, when it change it may silently break our existing scripts or configurations. include the contents into our .vimrc minimize the incompatible changes. So the better practise to create a new .vimrc may be: just copy the vimrc_example.vim to ~/.vimrc -- Sincerely, Pan, Shi Zhu. ext: 2606 Changing the vimrc_example.com is not a good practice, but I prefer sourcing (contrary to Bram's repeated advice) because that way, if an improvement is distributed, I don't remain stuck with the old version. If the vimrc_example does something I don't want (and sometimes it does) I reverse it in the part of my own vimrc after the sourcing: for instance, to avoid filetype-specific indenting: ... runtime vimrc_example.vim filetype indent off ... Likewise for other options. If I want to check what the vimrc_example actually does, I can always use :view $VIMRUNTIME/vimrc_example.vim; but that script is long, complex, and not written by me, enough for me to want it kept apart from my own changes -- and in a different file. I don't remember the vimrc_example introducing changes which broke my own scripts, but if it did, :verbose set optionname would quickly tell me that 'optionname' whas set there. YMMV. Which practice is better depends on by which criteria you judge those practices. According to my criteria, sourcing the vimrc_example is better than copying it. Bram doesn't agree with me on that point, and neither do you, because you apply different criteria. Best regards, Tony. -- The best book on programming for the layman is Alice in Wonderland; but that's because it's the best book on anything for the layman.
Re: repeating up/down/delete commands
Gary Johnson wrote: [...] One way to make sure that vim starts in non-compatible mode is to make sure you have a .vimrc file in your HOME directory, even if the file is empty. [...] This is true, but rather than an empty vimrc I suggest the following: Vim startup file Preferences which affect the menus must come first: uncomment if desired if 0 force English messages and menus regardless of locale if has(unix) language messages C else language messages en endif endif if 0 invoke the example vimrc runtime vimrc_example.vim if and when we want to further customize Vim, we'll add more lines below Best regards, Tony. -- Let's talk about how to fill out your 1984 tax return. Here's an often overlooked accounting technique that can save you thousands of dollars: For several days before you put it in the mail, carry your tax return around under your armpit. No IRS agent is going to want to spend hours poring over a sweat-stained document. So even if you owe money, you can put in for an enormous refund and the agent will probably give it to you, just to avoid an audit. What does he care? It's not his money. -- Dave Barry, Sweating Out Taxes
Re: C-X C-F completion and paths with spaces
Maciej Kalisiak wrote: Hello fellow Vimmers, Can any of you that work on Windows tell me how you handle filename completion (C-X C-F) for paths that contain spaces? I love this completion method, but as soon as I get to C:\Document and Settings\, it stops working, because of course a space character is not in 'isfname' (so it tries to complete just Settings), and putting it in makes no sense (Vim won't know where the path starts). How do you deal with it? Or is there simply no hope? It seems that the 'isfname' option doesn't include a space by default. But is that right? On both Windows and Unix, a filename may include spaces (though special steps must be taken to include such names in a command-line). Does it work after :set isf+=32 (without the quotes)? Best regards, Tony. -- Succumb to natural tendencies. Be hateful and boring.
Re: C-X C-F completion and paths with spaces
David Nečas (Yeti) wrote: On Sat, May 19, 2007 at 07:43:46PM +0200, A.J.Mechelynck wrote: It seems that the 'isfname' option doesn't include a space by default. But is that right? On both Windows and Unix, a filename may include spaces The question is not whether file names can include spaces or not. They can include newlines and bells too. And vim cannot complete file names containing the former, no matter your settings. The question is what value of ifsname is the most likely to be useful to most people. Yeti -- http://gwyddion.net/ Well, I haven't yet seen a filename with a bell or (aargh) a linefeed in it; but filenames and dirnames including spaces are frequent on Windows, and they aren't unseen even on Linux. Best regards, Tony. -- hundred-and-one symptoms of being an internet addict: 246. You use up your free 100 hours in less than a week.
Re: Vim Wiki - Tip id and URL
John Beckett wrote: A.J.Mechelynck wrote: Wouldn't it be enough to set up the main tip page with a tip _name_ (which would be the current title of the tip, or a disambiguation page if there are more than one tip with the same title), and have the tip _number_ (only for tips imported from Vim-online) refer to a redirect page, let's say Vim tip 1 = The super star? So the conversion script could convert vimtip#1 to [[Vim tip 1]], which could be done mechanically, and the redirect would automagically resend anyone clicking that link to the actual page. I suppose that links pointing to the redirect pages could be readjusted later, in no hurry, either by hand or by a wiki robot, and in either case with the help of the What points here page for the redirect. Would someone who understands wiki procedures please describe how the URL for a tip would be generated. What is actually achievable? Can a URL be changed later without much effort? I propose using just the title as it already exists in the tip, e.g. The super star (see below about spaces). In addition, a page titled Vim tip 1 would also be created, with only the line #REDIRECT [[The super star]] so that trying to get that page would normally automatically go to the other one. The conversion script, when finding the text vimtip#1 (used by the vim-online tips to generate links to each other) would translate it to [[Vim tip 1]] (without the quotes) which is an internal link in wikicode. Later, someone (or maybe some wiki robot) could check the What points here page for the redirection page, and change everywhere [[Vim tip 1]] to [[The super star]]. See http://en.wikipedia.org/wiki/Wikipedia:Cheatsheet (and, possibly, what it links to) for Wikipedia editing help. Can we have a redirect as Tony outlines above? I proposed devising a short id for each tip (like super_star for tip 1), then using that tip_id in the URL. That would avoid ugly URLs which would wrap in an email, or which would contain stuff like %20, making the URL hard to read. %20 are never necessary because spaces are replaced by underscores in the URL: when the title of a wiki page is The super star the URL is (something)/The_super_star where (something)/ depends on the wiki, e.g., http://en.wikipedia.org/wiki/ for the English wikipedia or http://kb.mozillazine.org/ for the Mozillazine knowledge base. %28 or %29 might appear if there are parentheses in the title, but only when referring to a wiki page from outside the wiki: e.g. the Vim (text editor) page of the English wikipedia is http://en.wikipedia.org/wiki/Vim_%28text_editor%29 from outside the wiki, but it is referred to as [[Vim (text editor)]] within the wiki, and (when equipped with the Wikipedia (en) search plugin) typing Vim (text editor) (without the quotes) in the Firefox 2 search bar finds it (I just tried it). Some Fx2 search plugins can also be used with Fx1.5, others can also be used with IE7, I'm not sure to which category this one belongs. Is my concern (that we should avoid long ugly URLs) misguided? John Best regards, Tony. -- The idea is to die young as late as possible. -- Ashley Montague
Re: Vim Icon
Michael Phillips wrote: Before install the new vim, I deleted the version of vim first. In the process it deleted the vim icon. Now I have installed Vim 7.1. Where is the icon located for vim? I am using VIM - Vi IMproved 7.1 (2007 May 12, compiled May 12 2007 14:19:39) MS-Windows 32 bit GUI version with OLE support. Thanks for your help in advance. Michael Michael D. Phillips - A computer science enthusiast I do not hate Windows, I just like the alternatives better. Linux is my primary choice. A number of Vim icons in various sizes and formats are in the top runtime/ directory in the source tree. Windows icons are in the src/ directory, as src/*.ico. Like every Windows program, the gvim.exe executable also includes compiled-in icons which can be picked by the Shortcut properties dialog of your desktop shortcuts. If you don't have the Vim source, my compiling HowTo http://users.skynet.be/antoine.mechelynck/vim/compile.htm (or, for Unix, .../compunix.htm) will tell you how to get it and from where. Best regards, Tony. -- To the best of my recollection, Senator, I can't recall.
Re: repeating up/down/delete commands
David Pike wrote: This will hopefully be an easy question or two... An upgraded version of vim was installed on our systems recently, and some tricks that I'm used to are no longer functional, such as: [a large integer, say N] up to quickly get to the top of the file that I am editting, [N] down to quickly get to the last line of the file (similarly, PageUp and PageDown could be used). Also, while part way through a file, [N] dd or [N] d Enter was a handy way of deleting all remaining lines in the file. The new version of vim does not seem to let me do this anymore. Specifically, if the N value that I enter (typically ) is larger than the number of lines involved, then vim now just beeps to signal that it won't do what I would like to do. Is there some easy way of getting vim to accept these commands once again? Thanks, - David. To get to the top of the file: gg To get to the last line: G Best regards, Tony. -- Non-sequiturs make me eat lampshades.
Re: repeating up/down/delete commands
David Pike wrote: Uh oh... I spoke slightly too soon. Although the up/down/delete functions that I first asked about now behave normally, the vim -N -u NONE -i NONE option now results in 999 dspace deleting 999 characters, 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 option had been helping me to get the desired 'this line only' functionality, but the -N option above now overrides that. - David. To delete from cursor to end of line, use d$ Is it so hard to remember? Best regards, Tony. -- hundred-and-one symptoms of being an internet addict: 244. You use more than 20 passwords.
Re: Disabling Alt+keys (menu keys) in Windows gVim
Tim Chase wrote: Is there a way I can rebind alt+something keys for Windows gVim. Normally alt+b is for opening the buffers menu, alt + w is for opening the windows menu, etc. Is the only solution rebuilding Vim without those shortcuts, or is there a easier/quicker way to do it? Well, if you don't use the menus, you can just disable them all together: :set guioptions-=m :set guioptions-=M which is how I fly with gvim on win32, though I also remove the toolbar to maximize my vertical screen real-estate. -tim For a less drastic solution, see :help 'winaltkeys'. Best regards, Tony. -- ... And malt does more than Milton can To justify God's ways to man -- A. E. Housman
Re: [Fwd: Re: compiling vim7.1 (huge version) gets build with normal version]
Stephan Hegel wrote: Hi, A.J.Mechelynck wrote: - Using cat is OK as long as you can be sure that you'll get them in numeric order: this is usually the case on Unix but not necessarily on Dos, where a wildcarded filename usually gets its results in directory order, not sorted by filename. Well, you are right: I'm on Linux and wasn't aware of the different DOS sorting order. So, the following below applies to Linux/Unix only ... - By patching individually, if one of the patches fails horribly you may decide not to try the following. - Usually there aren't more than a handful of _new_ patches anyway, so (except when starting from scratch with many patches already published) it's hardly worth the trouble going to a cat step. What you have described even on your Web page, IMHO still too much manual work. After downloading new patches with ncftp I just type make all with the following Makefile: - PREFIX=/usr/local help: @echo Available targets: @echoall @echoinstall @echoclean all: clean tar xfj vim-7.1.tar.bz2 tar xfz vim-7.1-lang.tar.gz tar xfz vim-7.1-extra.tar.gz cat vim-7.1.patches/7.1.* patchfile (cd vim71 ; patch -p0 ../patchfile) (cd vim71 ; ./configure --prefix=$(PREFIX) --with-x --enable-gui=gtk2 --enable-multibyte --enable-xim --enable-fontset --enable-perlinterp --enable-cscope make) install: (cd vim71; umask 022; installwatch -o /home/steve/install.log/vim-7.1.log make install) chmod 644 /home/steve/install.log/vim-7.1.log clean: rm -rf patchfile rm -rf vim71 .PHONY: help all install clean -- ... and everything is done in less than 150 sec. Works for me for a long time and starting from scratch keeps me out of trouble with old objects, etc. Should not happen with make ... yes, this is what optimists always say, but there is still Murphy ;). BTW, make should stop when patch or any other action fails. Interesting would be an extension to download the patches automagically. Comments ideas ? Regards, Stephan. Comments: - Since on Linux I build only one version of Vim (a full-featured GUI-enabled executable which can also run in console mode) I prefer to keep already-built objects, doing what the Mozilla guys call a depend build rather than a clobber build (which is what you do). I've found that it spares quite a lot of time, finishing in a few seconds rather than a few minutes. - When I really need a clobber build (because my configuration has changed), then I do make reconfig in the src subfolder. - After make clean, make will invoke configure, you don't need to run it separately. (I keep my configure options in a separate script, which I source in bash to set the required environment variables.) - What is ncftp? On my openSUSE 10.2 system I have a program called ftp but none called ncftp. Best regards, Tony. -- hundred-and-one symptoms of being an internet addict: 241. You try to look for Net Search even when you're in File Manager.
Re: [Fwd: Re: compiling vim7.1 (huge version) gets build with normal version]
Stephan Hegel wrote: A.J.Mechelynck wrote: - What is ncftp? On my openSUSE 10.2 system I have a program called ftp but none called ncftp. [39]./home/steve: rpm -qi ncftp Name: ncftpRelocations: (not relocatable) Version : 3.1.9 Vendor: SUSE LINUX Products GmbH, Nuernberg, Germany Release : 2 Build Date: Fri 09 Sep 2005 06:15:16 PM CEST Install date: Sun 16 Oct 2005 06:07:57 AM CEST Build Host: berlioz.suse.de Group : Productivity/Networking/Ftp/Clients Source RPM: ncftp-3.1.9-2.src.rpm Size: 1038391 License: Artistic License Signature : DSA/SHA1, Fri 09 Sep 2005 06:52:45 PM CEST, Key ID a84edae89c800aca Packager: http://www.suse.de/feedback URL : http://www.ncftp.com/ Summary : A Comfortable FTP Program Description : This program has been in service on UNIX systems since 1991 and is a popular alternative to the standard FTP program, /usr/bin/ftp. NcFTP offers many ease-of-use and performance enhancements over the stock FTP client, and runs on a wide variety of UNIX platforms as well as operating systems such as Microsoft Windows and Apple Mac OS X. Authors: Mike Gleason [EMAIL PROTECTED] Distribution: SUSE LINUX 10.0 (i586) Regards, Stephan. Well, AFAICT it has disappeared between SuSE 10.0 and 10.2. I have packages named lftp and lukemftp (which are installed); YaST also shows, among FTP clients, gftp, tftp and yafc; but the only available packages (in category zzzAll) whose name starts nc are ncpfs, ncurses and ncurses-devel. /usr/bin/ftp is actually a link, /bin/ftp - /etc/alternatives/ftp - /usr/bin/pftp where pftp comes from the lukemftp package which is the enhanced ftp client in NetBSD Best regards, Tony. -- How do you like the new America? We've cut the fat out of the government, and more recently the heart and brain (the backbone was gone some time ago). All we seem to have left now is muscle. We'll be lucky to escape with our skins!
Cannot print in UTF-8?
:set enc? penc? encoding=utf-8 printencoding=utf-8 :%ha not found in runtimepath: print/utf-8.ps Is this last message normal? I have here a file including an Esperanto-French glossary, which contains both the consonants+circumflex of Esperanto and the French oe ligature. No matter how I try, Vim cannot print it: - penc=utf-8 gives the above error - penc=latin3 prints Esperanto correctly, but oe becomes an inverted question mark - penc=latin9 prints French correctly but not the Esperanto letters. Compiled with +multi_byte +iconv +printer +postscript Looks like the only way to print that file properly is to load it in my browser. Best regards, Tony. -- When I said we, officer, I was referring to myself, the four young ladies, and, of course, the goat. PreÄ|o sub la verd|a standard|o 1. Al Vi, ho potenc|a sen|korp|a mister|o, Fort|eg|o, la mond|o|n reg|ant|a, Al Vi, grand|a font|o de l'am|o kaj ver|o Kaj font|o de viv|o konstant|a, Al Vi, kiu|n Äiu malsame prezent|as, Sed egal|e Äiu|j en kor|o Vi|n sent|as, Al Vi, kiu kre|as, al Vi, kiu reÄ|as, HodiaÅ ni preÄ|as. 2. Al vi ni ne ven|as kun kred|o naci|a, Kun dogm|o|j de blind|a fervor|o; Silent|as nun Äiu disput' religi|a, Kaj reg|as nur kred|o de kor|o. Kun Äi, kiu est|as Äe Äiu|j egal|a, Kun Äi, la plej ver|a, sen trud|o batal|a, Ni star|as nun, fil|o|j de l'tut|a hom|ar|o Äe Vi|a altar|o. 3. Hom|ar|o|n Vi kre|is perfekt|e kaj bel|e, Sed Äi si|n divid|is batal|e; Popol|o popol|o|n atak|as kruel|e, Frat' frat|o|n atak|as Åakal|e. Ho, kiu ajn est|as Vi, fort|o mister|a, AÅskult|u la voÄ|o|n de l'preÄ|o sincer|a, Re|don|u la pac|o|n al la infan|ar|o De l'grand|a hom|ar|o! 4. Ni ĵur|is labor|i, ni ĵur|is batal|i, Por re|unu|ig|i l'hom|ar|o|n. Sub|ten|u ni|n, Fort|o, ne las|u ni|n fal|i, Sed las|u ni|n venk|i la bar|o|n; Donac|u Vi ben|o|n al ni|a labor|o, Donac|u Vi fort|o|n al ni|a fervor|o, Ke Äiam ni kontraÅ atak|o|j sovaÄ|a|j Ni|n ten|u kuraÄ|a|j. 5. La verd|a|n standard|o|n tre alt|e ni ten|os; Äi sign|as la bon|o|n kaj bel|o|n. La Fort|o mister|a de l'mond|o ni|n ben|os, Kaj ni|a|n ating|os ni cel|o|n. Ni inter popol|o|j la mur|o|n detru|os, Kaj ili ek|krak|os kaj ili ek|bru|os Jaj fal|os por Äiam, kaj am|o kaj ver|o Ek|reg|os sur ter|o. Prononciation - L'accent tonique tombe toujours sur l'avant-dernière syllabe: potènca senkòrpa mistèro a,b,d,f,i,k,l,m,n,p,s,t,v,z : comme en français c = ts dans tsar Ä = tch dans catch, Tchantchès e = e dans cette; ai dans vrai g = g gans garçon; gu dans guerre Ä = dj dans Djerba, djinn h = comme dans les langues germaniques Ä¥ = comme ch allemand dans Bach, ch écossais dans loch, ch yiddisch dans chutzpa, j espagnoj dans jota j = comme y dans yole ĵ = comme j dans jardin o = comme o dans botte r = légèrement roulé, comme en espagnol Å = comme ch dans chant, chez, choix, pacha, chichi u = comme ou dans flou, bout, ouvrir Å = (généralement après voyelle) semi-voyelle oué L'alphabet: Aa Bb Cc ÄÄ Dd Ee Ff Gg ÄÄ Hh Ĥĥ Ii Jj Ĵĵ Kk Ll Mm Nn Oo Pp Rr Ss ÅÅ Tt Uu ŬŠVv Zz qui se lit: a, bo, tso, tcho, do, é, fo go, djo, ho, kho, i, yo, jo ko, lo, mo, no, o, po, ro so, cho, to, ou, wo, vo, zo. Vocabulaire --- -' (élision):voir -o -a (adjectif) ajn ...que ce soit al à alt(a) haut altar(o) autel am(i) aimer -aro (un ensemble de...) -as (temps présent) -ant- (participe présent actif) atak(i) attaquer ating(i) atteindre aÅskult(i) écouter bar(i) barrer batal(o) bataille,combat bel(a) beau ben(i) bénir blind(a) aveugle bon(a) bon (adj.) bru(o) bruit Äe chez;auprès de Äiam toujours Äiu chacun; (au pluriel) tous de de detru(i) détruire disput(o) dispute divid(i) diviser don(i) donner donac(o) cadeau dogm(o) dogme -e (adverbe) -eg- augmentatif egal(a) égal ek- (action subite) en en,dans est(i) être fal(i) tomber fervor(o) ferveur fil(o) fils font(o) source fort(a) fort frat(o) grand(a) grand Äi il,elle(chose) ho 1.à 2.oh! hodiaÅ aujourd'hui hom(o) être humain -i (infinitif) -ig(i) (factitif) faire (+infinitif), rendre (+attribut du c.o.d.), changer (en...) ili ils,elles infan(o) enfant inter entre (prép.) -is (passé) -j (pluriel) ĵur(i) jurer, faire serment de kaj et ke que (conj. de sub.) kiu qui?(pronom),quel?(adjectif)(interrogatif-relatif) konstant(a) constant kontraÅ contre kor(o) cÅur korp(o) corps krak! crac! kre(i) créer kred(i) croire kruel(a) cruel kun avec kuraÄ(o) courage la,l' la labor(i) travailler las(i) laisser mal- (le contraire de) mister(o) mistère mond(o) monde mur(o) mur -n (marque le c.o.d. ou le lieu où l'on va) naci(o) nation ne non,ne pas ni nous nun maintenant nur seulement -o,-' (substantif) -os (futur) pac(o) paix perfekt(a) parfait plej le plus (superlatif) popol(o) peuple por pour potenc(o) puissance preÄ(i) prier prezent(i) présenter re- re- reg(i) gouverner reÄ(o) roi religi(o) religion sam(a) pareil,même sed mais sen sans sent(i) sentir si soi sign(o)
Re: [Fwd: Re: compiling vim7.1 (huge version) gets build with normal version]
scott wrote: [...] ncftp should have popped right up for you -- what do you have in Configured Software Catalogs (under installation sources)? sc Status Refresh Name URL On On YaST iso:///?iso=openSUSE-10.2-GM-DVD-i386.isourl=hd:///?device=/dev/hda2filesystem=auto On On YUM http://gd.tuwien.ac.at/linux/suse.com/suse/update/10.2 On On YUM http://ftp.hosteurope.de/mirror/ftp.suse.com/pub/suse/update/10.2 [x] Synchronize changes with ZENworks Anyway, ftp (aka pftp from the lukemftp package), and occasionally lftp, are good enough for me. Best regards, Tony. -- hundred-and-one symptoms of being an internet addict: 242. You turn down a better-paying job because it doesn't come with a free e-mail account.
Re: Vim Wiki - Tip id and URL
John Beckett wrote:
It is important for us to have an easy way to refer to tips,
and the URL of each tip should be simple (and not wrap in an
email).
Below is some detail for a proposal to achieve this.
What does everyone think?
Have a script scrape tip titles from the current Vim Tips.
Create a plain text file with fields (say tab-separated):
tip_nrtip_idtip_name
tip_id would initially be empty.
Example:
Tip #1504: External commands on Windows
http://www.vim.org/tips/tip.php?tip_id=1504
would give line (':' represents '\t'):
1504::External commands on Windows
I would edit this file (or maybe split it over three
volunteers). We would manually insert a short tip_id by
abbreviating tip_name. For example:
1504:win_external_cmd:External commands on Windows
We would manually confirm (with a script) that the 1500
tip_id fields are unique.
The script to import each tip would read the above file:
- Use tip_nr to read the current tip.
- Use tip_id to make the URL of the new tip.
- Ignore tip_name.
The example URL might be:
http://vim.wikia.com/wiki/tips/win_external_cmd
Perhaps a contents page could list all tips:
win_external_cmdExternal commands on Windows
Where we might once have said see tip 1504, we would instead
say see tip win_external_cmd.
John
Wouldn't it be enough to set up the main tip page with a tip _name_ (which
would be the current title of the tip, or a disambiguation page if there are
more than one tip with the same title), and have the tip _number_ (only for
tips imported from Vim-online) refer to a redirect page, let's say Vim tip 1
= The super star? So the conversion script could convert vimtip#1 to
[[Vim tip 1]], which could be done mechanically, and the redirect would
automagically resend anyone clicking that link to the actual page. I suppose
that links pointing to the redirect pages could be readjusted later, in no
hurry, either by hand or by a wiki robot, and in either case with the help
of the What points here page for the redirect.
Best regards,
Tony.
--
YOU TOO CAN MAKE BIG MONEY IN THE EXCITING FIELD OF
PAPER SHUFFLING!
Mr. TAA of Muddle, Mass. says: Before I took this course I used to be
a lowly bit twiddler. Now with what I learned at MIT Tech I feel
really important and can obfuscate and confuse with the best.
Mr. MARC had this to say: Ten short days ago all I could look forward
to was a dead-end job as a engineer. Now I have a promising future and
make really big Zorkmids.
MIT Tech can't promise these fantastic results to everyone, but when
you earn your MDL degree from MIT Tech your future will be brighter.
SEND FOR OUR FREE BROCHURE TODAY!
Re: How to efficiently type polytonic Greek?
Guido Milanese wrote: [...] Important: use a font with a decently complete set of chars. In Linux you should be able to use Gentium, I believe, but personaly I prefer a fixed font and use Bitstream\ Vera\ Sans\ Mono with excellent results. [...] Except in the GTK+2 version of gvim, variable-vidth fonts are simply not permitted. In the GTK+2 version, any font is permitted, but anything other than a monospaced font will look ugly, because the character cell has a fixed size in Vim, so narrower glyphs will get extra space between them (bad), and wider glyphs will get clipped at the character cell edge (worse). Yes, Bitstream Vera Sans Mono is a good-looking font. For any language whose glyphs are not present, try Courier New if it exists on your system. It is not so good-looking but it has a large number of different alphabets. Not CJK double-width glyphs though. Best regards, Tony. -- Pascal, n.: A programming language named after a man who would turn over in his grave if he knew about it.
[Fwd: Re: compiling vim7.1 (huge version) gets build with normal version]
Forward to vim-dev list. See my comments at bottom.
Original Message
Subject: Re: compiling vim7.1 (huge version) gets build with normal version
Date: Tue, 15 May 2007 08:14:28 -0700
From: Tushar Desai [EMAIL PROTECTED]
Reply-To: [EMAIL PROTECTED]
To: A.J.Mechelynck [EMAIL PROTECTED]
References: [EMAIL PROTECTED]
[EMAIL PROTECTED]
HI Tony,
I tried what you suggested, but now I'm getting this really weird
compile error (I'm compiling on ubuntu 7.04 with gnome 2.0)
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/include/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/orbit-2.0 -I/usr/include/glib-2.0
-I/usr/lib/glib-2.0/include -I/usr/include/libbonobo-2.0
-I/usr/include/bonobo-activation-2.0 -I/usr/include/pango-1.0
-I/usr/include/freetype2 -I/usr/lib/gtk-2.0/include
-I/usr/include/atk-1.0 -I/usr/include/cairo -I/usr/include/libpng12
-I/usr/include/libxml2 -O2 -fno-strength-reduce -Wall
-D_REENTRANT -D_GNU_SOURCE -DTHREADS_HAVE_PIDS -DDEBIAN
-I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64
-I/usr/lib/perl/5.8/CORE -I/usr/include/python2.5 -pthread
-I/usr/include/tcl8.4 -D_REENTRANT=1 -D_THREAD_SAFE=1
-D_LARGEFILE64_SOURCE=1 -I/usr/lib/ruby/1.8/i486-linux -o
objects/gui_gtk.o gui_gtk.c
In file included from /usr/include/glib-2.0/glib/gi18n.h:23,
from /usr/include/libbonobo-2.0/bonobo/bonobo-i18n.h:37,
from /usr/include/libgnome-2.0/libgnome/gnome-i18n.h:41,
from /usr/include/libgnome-2.0/libgnome/libgnome.h:30,
from /usr/include/libgnomeui-2.0/gnome.h:5,
from gui_gtk.c:62:
/usr/include/libintl.h:92: error: expected identifier or '(' before ';' token
make[1]: *** [objects/gui_gtk.o] Error 1
make[1]: Leaving directory `/home/tushar/vim/vim71/src'
make: *** [myself] Error 2
Regards,
-tushar.
- End Original Message -
This may be the problem addressed by patch 7.1.001, see
http://ftp.vim.org/pub/vim/patches/7.1/
So, try the following:
cd ~/vim/vim71
mkdir -pv patches
cd patches
ftp ftp.vim.org
Name: ftp
Password: ftp
cd pub/vim/patches/7.1
mget *
a
bye
cd ..
patch -p0 patches/7.1.001
patch -p0 patches/7.1.002
# beware of beautifying mailers! Here comes a long line starting rsync
# followed by a line starting vim
rsync -avzcP --delete --exclude=/dos/ ftp.nluug.nl::Vim/runtime/ ./runtime/
21 | tee rsync.log
vim -es -u NONE -c '%s/^.*\r//' -cx rsync.log
echo $CONF_OPT_FEAT
(if the reply is not --with-features=huge):
source myconfig
make 21 |tee make.log
etc. If you still get the same error, someone else will have to help you.
Best regards,
Tony.
--
*** NEWSFLASH ***
Russian tanks steamrolling through New Jersey Details at eleven!
Re: [Fwd: Re: compiling vim7.1 (huge version) gets build with normal version]
Stephan Hegel wrote: A.J.Mechelynck wrote: patch -p0 patches/7.1.001 patch -p0 patches/7.1.002 As long as you have two patches this can be done easily. But what if you have 100+ ? Then try this: cat patches/7.1.* patchfile patch -p0 patchfile rm patchfile Done. Rgds, Stephan. If you have more than a hundred, Bram sets up recapitulative patches for one hundred patchlevels at a time, so if you want to patch plain-vanilla 7.0 to compile 7.0.233 you would do gunzip -c patches/7.0.001-100.gz |patch -p0 gunzip -c patches/7.0.101-200.gz |patch -p0 patch -p0 patches/7.0.201 patch -p0 patches/7.0.202 patch -p0 patches/7.0.203 etc. With command-line editing, you can recall the latest command and change only the last (or the last two) digit(s) every time. But normally you would download and implement the patches a few at a time as they are published, and there would never be many of them at any one time, except maybe the first time you compile Vim; so now (that there aren't many patches to the latest version) is a good time to start. - Using cat is OK as long as you can be sure that you'll get them in numeric order: this is usually the case on Unix but not necessarily on Dos, where a wildcarded filename usually gets its results in directory order, not sorted by filename. - By patching individually, if one of the patches fails horribly you may decide not to try the following. - Usually there aren't more than a handful of _new_ patches anyway, so (except when starting from scratch with many patches already published) it's hardly worth the trouble going to a cat step. Best regards, Tony. -- Justice, n.: A decision in your favor.
Re: Compiling Vim
fREW wrote: Hey Tony, What is the URL for your Vim Compile site? I can't find the link anywhere. Thanks! -fREW Method I: Start at my home portal http://users.skynet.be/antoine.mechelynck/ Click The Vim Editor then the two bottom links in the list at top left point to my HowTo pages for Windows and Unix/Linux. This method can easily be deduced from my email address plus the knowledge of how Belgacom/Skynet user sites are named. Method II: Direct links: Windows: http://users.skynet.be/antoine.mechelynck/vim/compile.htm Unix:http://users.skynet.be/antoine.mechelynck/vim/compunix.htm Best regards, Tony. -- ROMEO: Courage, man; the hurt cannot be much. MERCUTIO: No, 'tis not so deep as a well, nor so wide as a church- door; but 'tis enough, 'twill serve.
Re: vim 7.1 and cr/lf interpretation
Gene Kwiecinski wrote: fileformats=dos,unix, so both formats are available, yet the detection and switching does not seem to work. Are you sure _every_ line ends in ^M? Positive. Every single line shows an ^M at the end. set fileformat gives unix after loading. Setting fileformat to dos doesn't change the files interpretation in vim. Somehow I think I miss something. Uhhh, don't think it *should* automagically delete the ^Ms. I'm always running into that, and in addition to an almost reflexive alt-EIFD to go dos-mode, I *still* always have to ':s/^V^M' to get rid of 'em, and I'm using version 6.4, not even 7.x, so it's definitely been around for a while. Setting ff=dos after the file is loaded changes nothing to the contents of the file data in memory, it only changes how the ends-of-lines will be represented on output. So if you have a file with mixed ends-of-lines and 'fileformat' detected as unix, using :setlocal ff=dos will result in some lines having CR+LF (where there was only LF before) and others (which already had CR+LF shown as ^M at end of line) will get CR+CR+LF. So this is not the way to go. To detect a file with mixed ends-of-lines as dos-format, we must first disable automatic unix filetype detection. One way to do this is to set the 'fileformats' (plural) option to the empty string: :set fileformats= Now we can manually detect the file's format (see :help ++opt): :e ++ff=dos filename which will interpret CR+LF as an end-of-line, and LF-without-CR also as an end-of-line. So now all lines (in memory) are as they should be, with no spurious end-of-line ^M showing. ^M will only appear if there is a CR not immediately followed by a LF (either a lone CR in the middle, or more than one CR before a LF). We must now save this file-in-memory to disk, to make the repairs permanent. Here we have the choice of how we want to save it: - To save the file with CR+LF at the end of every line, leave 'fileformat' at its current value (dos) and just write the file: :w - To save the file with LF-only: :setlocal ff=unix :w - To save the file with CR-only: :setlocal ff=mac :w After that, we may want to re-enable automatic fileformat detection: either set it back to its default: :set fileformats or set the value explicitly, for example: :set ffs=dos,unix,mac Best regards, Tony. -- hundred-and-one symptoms of being an internet addict: 238. You think faxes are old-fashioned.
Re: Vim Wiki - Tip Page Formatting Deadline
Gene Kwiecinski wrote: Thinking about how a wiki works shows that keeping tip numbers is doomed. First, there is no auto-increment id, and as you point out, there is no reasonable way to automate fixes. Is there any equivalent to javascript's document.lastModified? Can create a serial number based on the date of submission, then rearrange by fields to a sortable ID, eg 2007.05.15.23.53 for a tip created yesterday at 23:53. Don't need dots, or hyphens, or anything, as 2007051523353 would be fine, too. The odds of having 2 tips be submitted in the same minute would be remote. I don't think so. A minute is sixty seconds, and sooner or later we'll have two different users submitting tips less than sixty (or even thirty) seconds away from each other. Even adding the seconds to the ID doesn't clear the problem, it lowers the probability but doesn't make it zero. With enough Vimmers adding tips, sooner or later there'll be a clash. Best regards, Tony. -- If the odds are a million to one against something occurring, chances are 50-50 it will.
Re: enabling cyrillic character display support
Yongwei Wu wrote: [...] If you are courageous enough see a real-world example of complicated multi-language support, check my _vimrc at: http://wyw.dcweb.cn/download.asp?path=vimfile=_vimrc.txt (as text) or http://wyw.dcweb.cn/download.asp?path=vimfile=_vimrc.html (as HTML) Best regards, Yongwei I see a number of tests for has(eval) in this vimrc, sometimes embedded in longer if clauses. Note that the following: if has(gui_running) do something endif then later if ! has(gui_running) blah blah if has(eval) do something endif more blah blah endif will do nothing at all (neither the 'if has(gui_running)' nor the 'if ! has(gui_running) will be run) if expression evaluation is not compiled-in, because in that case the if...endif structure is treated as a nestable comment: see :help no-eval-feature. The one way that I know of executing some statements _only_ if evaluation is not compiled-in, is to place them at the end of a script (such as a vimrc), as follows: if 1 finish endif the following, to the end of the script, runs only if evaluation is not compiled-in. Best regards, Tony. -- hundred-and-one symptoms of being an internet addict: 240. You think Webster's Dictionary is a directory of WEB sites.
Re: Identify this Vim font for me, please
madiyaan wrote: Hello, This isn't very related to Vim, but I found this font on Vim's wikipedia webpage: http://upload.wikimedia.org/wikipedia/commons/8/8c/Vim-%28logiciel%29-console.png Can anyone identify this font for me? It looks very good for programming. Thank you very much, That's the 80x25 font cooked into the PC ROM-BIOS. To use it on Windows: open a Dos Box, then select Alt-Space = Properties Select 80 columns, 25 lines and Full screen display. On Linux: hit Ctrl-Alt-Fn (with n in the range [1..6]), then log in with username and password. I don't think that font is available on Motorola Macs (including Power PCs). It may or may not be available in Intel Macs but I don't know how to get at it. Maybe the same way on OS X as on Linux above, I'm not sure. In both cases, you can then invoke Vim as vim (not gvim). For Windows, you'll need a console version (compiled as vim.exe) for that. On Linux, a single binary can do double duty as Console Vim and as gvim GUI. Best regards, Tony. -- Yea, though I walk through the valley of the shadow of APL, I shall fear no evil, for I can string six primitive monadic and dyadic operators together. -- Steve Higgins
Re: Vim71: breaking change not mentioned in the document.
[EMAIL PROTECTED] wrote: Hi, vimmers: The line 1230 of editing.txt said: To change to the directory of the current file: :cd %:h This works for Vim 7.0 and before, but not for Vim 7.1. In Vim 7.1 when the pwd is the same as the directory of current file, the command will fail with E500. The failure will break the execution of a mapping, if one have a mapping to do :cd %:h and then continue to do something else. To reproduce the error, just at anytime, run :cd %:h twice. (I've got Windows gvim7.1.1, cygwin console vim 7.1.1) So there's at least two issues IMHO: 1. the line 1230 of editing.txt should be changed to :cd %:p:h 2. somewhere in the document should mention: if we had used :cd %:h in our mappings or scripts, we should change them into %:p:h after upgraded to vim 7.1. Or did I missed anything? -- Sincerely, Pan, Shi Zhu. ext: 2606 I agree with point 1. As for point 2, the way I remember it, :cd %:h and :lcd %:h already failed on Vim 6.3 or maybe earlier, if the current filename (as displayed e.g. on the status line) had no explicit path before it. So apparently one of us either missed something or remembered something the wrong way. Note that :cd (without an argument) has different meanings on different OSes, thus reflecting the OS's idiosyncrasies: on Windows it is synonymous with :pwd, on Linux with :cd $HOME. Best regards, Tony. -- Here's something to think about: How come you never see a headline like `Psychic Wins Lottery'? -- Jay Leno
Re: embedable vim?
Franco Saliola wrote: Is there a way to embed vim into my browser (or any other application for that matter)? I hate typing in the html text boxes and would much prefer to use vim to edit my email. Or are there any suggestions on reading/writing email using Gmail and Vim? I'll create a tip if I figure out a good method. Thank you, Franco -- It all depends on your browser (or other application for that matter). Some browsers (or other applications) support defining an external editor, either natively as (IIRC) kde applications do, or by means of an extensions (as seveal other posts mention doing for Firefox). Other browsers (such as IE IIRC) simply don't support any external editor. Best regards, Tony. -- ... The Anarchists' [national] anthem is an international anthem that consists of 365 raspberries blown in very quick succession to the tune of Camptown Races. Nobody has to stand up for it, nobody has to listen to it, and, even better, nobody has to play it. -- Mike Harding, The Armchair Anarchist's Almanac
Re: problems with vim
Nageshwar M wrote: Hello, I compiled the vim 7.1 source for unix and installed it in my fedora core 4 pc. When I pressed arrows its printing A,B,C,D's(in insert mode) , backspace is not working and when I pressed delete continuously the gvim is closing down. Someone please help me. The information that vim is showing for :version is Normal version with GTK2 GUI. Features included (+) or not (-): [...] This is usually due to a termcap problem. In which case(s) do you see the problem (among the following)? - in GUI mode (e.g. Alt-F2 then gvim) - in console mode in a terminal displaying through X (and which one: xterm? konsole? gnome-terminal? other[and which one]?) - in the pure text linux console (hit Ctrl-Alt-Fn with n in the range [1..6], log in if necessary, then invoke vim) Best regards, Tony. -- A nymph hits you and steals your virginity.
Re: vim 7.1 and cr/lf interpretation
Thomas Michael Engelke wrote: 2007/5/14, Andy Wokula [EMAIL PROTECTED]: Thomas Michael Engelke schrieb: :set fileformats? gives fileformats=dos,unix, so both formats are available, yet the detection and switching does not seem to work. Are you sure _every_ line ends in ^M? Positive. Every single line shows an ^M at the end. set fileformat gives unix after loading. Setting fileformat to dos doesn't change the files interpretation in vim. Somehow I think I miss something. If 'fileformats' includes dos, then if _all_ lines end in CR+LF, the 'fileformat' should be set (locally) to dos. But a single line without a CR causes 'fileformat' to be set to unix, and all other lines show a ^M Test 1: Load the file. Then: /[^[:return:]]$ If there is a line ending in LF-without-CR, this search should find it. Test 2, variant a: To remove all carriage-returns at end-of-line: :set fileformats= :e ++ff=dos filename :setlocal ff=unix :w Test 2, variant b: to repair any lines where a CR is missing, (by adding it): same as 2a, but omit the line with :setlocal ff=unix. Then exit Vim and reload the file with your usual settings to see if the problem has gone away. If it hasn't, do you still see it with vim -u /usr/local/share/vim/vim71/vimrc_example.vim (replace the path if necessary by wherever Vim sets $VIMRUNTIME on your installation: on Windows it might be vim -u C:\Program Files\Vim\vim71\vimrc_example.vim instead)? Best regards, Tony. -- hundred-and-one symptoms of being an internet addict: 236. You start saving URL's in your digital watch.
Re: compiling vim7.1 (huge version) gets build with normal version
Tushar Desai wrote: I recently did a clean install of Ubuntu 7.04 and also installed all vim related packages. That got me a gui version of vim (7.0.164/Big compiled on 2007/03/11). I now want to compile and install the gui version of vim 7.1. So, I downloaded the tar-ball for the 7.1 sources to my home dir ($HOME/vim), untarred at ($HOME)/vim/vim71, enabled CONF_OPT_FEAT = --with-features=huge in the src/Makefile. I also did apt-get build-dep vim and finally ./configure followed by make (in $HOME/vim/vim71). However, I'm ending up with the Normal version of vim and although vim -g pops up a window, it doesn't show the menu and the toolbar. I tried the same on Fedora Core 6 and got the same results. I tried vim7.0 on ubuntu and have the same situation. Strangely enough, I was previously able to compile vim7.0 on my Fedora Core 6 box and it gave the menu and toolbar. (I don't know what I did right in that case.). Any idea what I could be happening here? Thanks, Tushar. I suspect your configure step and your make step are setting different options. Here's what I suggest: 1. Undo any changes you made to the Makefile. 2. Paste the following text as $HOME/vim/vim71/myconfig. It doesn't need to be made executable. #!/bin/bash export CONF_OPT_GUI='--enable-gnome-check' export CONF_OPT_PERL='--enable-perlinterp' export CONF_OPT_PYTHON='--enable-pythoninterp' export CONF_OPT_TCL='--enable-tclinterp --with-tcl=tclsh8.4' export CONF_OPT_RUBY='--enable-rubyinterp' export CONF_OPT_MZSCHEME='--disable-mzschemeinterp' #export CONF_OPT_PLTHOME='--with-plthome=/usr/local/plt' export CONF_OPT_CSCOPE='--enable-cscope' export CONF_OPT_MULTIBYTE='--enable-multibyte' export CONF_OPT_FEAT='--with-features=huge' export CONF_OPT_COMPBY='[EMAIL PROTECTED]' 3. Edit it (change at least the last line) to reflect your desired settings. 4. Do the following, in bash: source myconfig cd src make reconfig 21 |tee ../config.log (It is important to source the script, not run it.) This should re-run configure and proceed to compile. If the configure step suggests that you delete config.cache or something, do it, then repeat the last line above. 5. If the compile proceeds to its end: ls -l vim (if there is a vim executable with a timestamp of a few seconds ago): ./vim --version |more 6. If you got the desired huge version, you can then cd .. make install 21 |tee install.log If you still did _not_ get a huge version, inspect ~/vim/vim71/config.log for details of what might have gone wrong. Best regards, Tony. -- Q: How many DEC repairman does it take to fix a flat ? A: Five; four to hold the car up and one to swap tires.
Re: Appending to Paste (*) Register
zzapper wrote:
Yegappan Lakshmanan [EMAIL PROTECTED] wrote in
news:[EMAIL PROTECTED]:
Hi,
On 5/14/07, zzapper [EMAIL PROTECTED] wrote:
Hi
I believe that the problem of Appending to Paste (*) Register was one
of the points Bram was looking at (problem is no uppercase for a
symbol)
Was there
In Vim7 and above, you can append the output of an ex command to the
clipboard register '*' using the following command:
:redir @*
- Yegappan
From the doc how are the following different?
:redi[r] @*
:redi[r] @+ Redirect messages to the selection or clipboard.
For
backward compatibility, the after the register
name can be omitted. See |quotestar| and |quoteplus|.
{not in Vi}
:redi[r] @*
:redi[r] @+ Append messages to the selection or clipboard.
{not in Vi}
Anyway I was looking for something like
:g/fred/y A append to register a but for the clipboard register *
1) @* and @+ clobber the register, @* and @+ append to it.
2) * and + are synonymous, except on X systems, where + is the CLIPBOARD
(pasted into other programs by Edit = Paste or Ctrl-V), while * is the
SELECTION (pasted by MiddleMouse).
For yanking, you may use something like
:g/fred/yank | let @a .= @0
Best regards,
Tony.
--
Mencken and Nathan's Fifteenth Law of The Average American:
The worst actress in the company is always the manager's wife.
