Vim binaries for Linux
Announcement: I've tentatively uploaded my current vim binary. Here are the details and caveats: - :version output is at http://users.skynet.be/antoine.mechelynck/vim/version.txt -- check this first before you attempt to download the executable. - executable is at http://users.skynet.be/antoine.mechelynck/vim/vim -- to download it, you will probably have to click right on this link, then Save Link Target As... or whatever your mailer calls it. - This is a huge Linux/i86 version with GTK2/Gnome GUI and support for perl, python, ruby and tcl, compiled on openSUSE 10.2. If you think it's overly bloated (and you quite well may), well, compile your own then: see e.g. my how-to page http://users.skynet.be/antoine.mechelynck/vim/compunix.htm - I compiled it about one and a half hours ago to the latest patchlevel (7.0.235), plus one additional (unnumbered) patch by Bram Moolenaar to fix the 'maxmemtot' default value. - This is a naked executable with no runtime files, no message translations and no ancillary programs (such as xxd). You will have to get all that from a different source such as ftp.vim.org, and keep them up-to-date yourself. This executable expects to find its runtime files starting at the default location, /usr/local/share/vim/vim70 - GNOME support, which is included, is *not* recommended by Bram. Warnings in the compilation of gui_gtk_x11.c seem to indicate that there might be problems with message translations, especially if you change the 'encoding' setting in your vimrc. - It works on my machine with the software I have installed. I don't know if it will work on yours, so: - you may want to keep (under another name or path) a backup Vim executable which you got somewhere else, at least until you've verified that you can use this one. - I don't know exactly how much your system must resemble mine in order to be able to run this executable. I think the GUI won't run without GTK2 and Gnome2, and I don't know if this editor version will load without perl, python, ruby and tcl. You may want to check the bottom part of my :version text for other library names. - if it doesn't work for you, and you cannot make it work by (for instance) installing missing libraries, you may want to discuss symptoms with me, either on the vim-dev list if you think it's on-topic for the list, or by private mail. In the latter case, please use an explicit Subject line because if I don't recognise an email's Subject I treat it as spam; and I get a lot of spam. Happy Vimming! Tony. -- For years a secret shame destroyed my peace -- I'd not read Eliot, Auden or MacNiece. But now I think a thought that brings me hope: Neither had Chaucer, Shakespeare, Milton, Pope. -- Justin Richardson.
Re: feedkeys() allowed in sandbox
John Beckett wrote: [...] Is folding really needed in a default modeline? John Folding may be useful in a modeline. (Don't know what you call a default modeline.) Depending on how the particular file is written, you may want to set foldmethod=marker (and which marker), foldmethod=syntax, foldmethod=indent, or default it to whatever (if anything) is set by the filetype-plugin. Best regards, Tony. -- Some of these fortunes are dated: I have an ADSL connection and a 96 gig HD, and I don't feel it's any special kind of achievement. -- hundred-and-one symptoms of being an internet addict: 208. Your goals for the future are obtaining an ISDN connection and a 6 gig hard drive.
Re: accessing vim's clipboard from java
Ernie Rael wrote: Hi all, I've just joined this list. I'm not a vim developer per se. However, I put together jVi, http://jvi.sourceforge.net , whose core is a port of some of vim to java. It runs on NetBeans ( and JBuilder, but not supported any more). jVi is based on vim-5.6. A jVi user has added visual char/line and is now tackling block. So now I want to setup access to the *real* vim clipboard, so blockmode paste works between vim and jVi. So I'm learning how to access native data formats in clipboard from java. I couldn't get anything to work, so I looked at the vim7 source, couldn't find windows source (I run cygwin, but not cygwin's vim, at home). I downloaded extras. I now see that the clipboard name has changed to VimClipboard2, and there's a whole lot more... So I changed the name, but still no luck. I thought I'd ping this list in case anyone has accessed the vim clipboard from java or has some clues. As an experiment I'm doing public static final String VIM_CLIPBOARD2 = VimClipboard2; SystemFlavorMap.addFlavorForUnencodedNative( ViManager.VIM_CLIPBOARD2, Misc.VimClipboardDataFlavor.get()); and the other way around. But after a paste into jVi from vim the DataFlavor I've defined is not available. Any clues? In os_mswin.c it looks like VimClipboard2 is always made available, so it should be there somewhere. Once I get something working, I'll look at doing all the various encodings... based on VimClipboard2. Or maybe, I'll use VimClipboard2 just to find out if it is MCHAR/MLINE/MBLOCK. Then go to the regular DataFlavors to pick the string type I'm looking for. -ernie IIUC, there is no specific interface between Vim and java, so java will have to do whatever any other application may do, without special knowledge about Vim. Whatever gvim writes to the + register is available in the system clipboard, just as if you'd used Edit = Copy in just about any application. There's nothing Vim-specific there. Best regards, Tony. -- You know you have a small apartment when Rice Krispies echo. -- S. Rickly Christian
Re: arabic
Babiker Osman wrote: Hi السلام I wonder who is the most arabic -vim -tex expert to consult him babiker osman It depends what you want to do. - If it's so high-fired secret that you won't give us any hint of what you might be doing, just dig into the help. Start at :help arabic.txt if you want to edit Arabic text, for instance. - The Arabic module was written by Nadim Shaikli. He certainly has a good knowledge of how to use Vim for Arabic. I have no idea what his knowledge of TeX might be. - In general, you may ask your questions on one of the Vim mailing lists, and see if anyone replies: [EMAIL PROTECTED] for general support questions vim-dev@vim.org with questions about compiling Vim or about writing new interfaces [EMAIL PROTECTED] for questions about encodings and (human) languages It helps if the Subject of your mail is explicit and if its body is clear. A useful reference about asking questions about anything on any forums, mailing lists or newsgroups is How To Ask Questions The Smart Way http://www.catb.org/~esr/faqs/smart-questions.html Best regards, Tony. -- I disapprove of the F-word, not because it's dirty, but because we use it as a substitute for thoughtful insults, and it frequently leads to violence. What we ought to do, when we anger each other, say, in traffic, is exchange phone numbers, so that later on, when we've had time to think of witty and learned insults or look them up in the library, we could call each other up: You: Hello? Bob? Bob: Yes? You: This is Ed. Remember? The person whose parking space you took last Thursday? Outside of Sears? Bob: Oh yes! Sure! How are you, Ed? You: Fine, thanks. Listen, Bob, the reason I'm calling is: Madam, you may be drunk, but I am ugly, and ... No, wait. I mean: you may be ugly, but I am Winston Churchill and ... No, wait. (Sound of reference book thudding onto the floor.) S-word. Excuse me. Look, Bob, I'm going to have to get back to you. Bob: Fine. -- Dave Barry, $#$%#^%!^%@[EMAIL PROTECTED]
Re: feedkeys() allowed in sandbox
A.J.Mechelynck wrote: Is folding really needed in a default modeline? Folding may be useful in a modeline. (Don't know what you call a default modeline.) By default modeline I mean I would like Vim to be changed so that its default behaviour is aggressively safe. If wanted, there could be a new option to enable clever features, and a user could choose to allow modelines with folding or expression evaluation, etc. But the only long-term safe procedure is to have Vim *default* to work with only very restricted modelines (set tab and other options - no way to even get near executing code). I am wondering what the lack of comment on this topic indicates. Do you understand that another modeline vulnerability could allow the next file you open to overwrite all files under your home folder? Or it might overwrite all sectors on your disk, if you have sufficient privilege. How about if you go to another computer that you rarely use. Would you be happy using Vim on that computer? Network admins in secure environments should be prohibited from using Vim. If I am overlooking something, or am overly alarmist, please tell me. For anyone new to this, enter following in Google: vim vulnerability modeline I just noticed that the fourth hit features Ciaran McCreesh who discovered a vulnerability in January 2005. John
Re: wish: show search progress on slow searches
On 4/29/07, Yakov Lerner [EMAIL PROTECTED] wrote: On 4/29/07, Bram Moolenaar [EMAIL PROTECTED] wrote: Yakov Lerner wrote: Wish: when search is slow, show the progress line number every second on the bottom line (like, 12345 of 9). What is slow? To my taste, when something takes longer than 1-2 sec, I'd prefer some visual feedback on the progress. Checking if the second passed will make the search even slower. Checking time is quite slow on some systems (the check for CTRL-C suffers from this). Checking for time every several hundred (N) lines will probably not slow the search perceptibly. N can be configurable, a parameter. Some value between 10 and 1000 will probaby be reasonable. Yakov I think it's possibe to check for time, which searching, not too often and not too seldom, even without user-defined parameter. Adaptive algorithm with two counters will find the right rate or time-checking: - as we start search, we check time every 50 lines (N=50 is initial value of N). We maintain counter M. M is how many times we called time() between the seconds changed. M is checked and reset every second. M is checked as folllows: - If M is too high (M10), then we adjust N by increasing it. If M is too low(M10), then we adjust N by decreasing it. Ideally, we want to check time() ~10 times per second. (overhead of 10 calls to time() per second cannot he high, right ?) - if search progresses for several seconds, then N quickly converges to the ideal value (~10 checks/sec). - we start every search with same value of N (say, 50). If search is slow, then N will quickly converge to the ideal value for this regex, the value in which where time() is checked ~10 times per second. Yakov
Re: feedkeys() allowed in sandbox
On Sun, 29 Apr 2007 19:10:55 +1000, John Beckett [EMAIL PROTECTED] wrote: Matthew Winn wrote: I don't like the idea of preventing modelines over 100 bytes. I imagine (haven't looked) that a modeline has no hard limit to its length. So multi-megabyte modelines are probably handled by Vim. That's potentially offering attackers extraordinary power. It doesn't matter how many bytes are accepted. Security that depends on the assumption that an exploit can't be written in less than an arbitrarily chosen number of bytes is no security at all. Take a look at some of the coding golf competitions that take place online, where the object is to perform some complex task in the minimum number of characters. If there was a security problem in Vim do you really think it couldn't be exploited in 100 characters? That's a pretty shaky foundation on which to build your security. Would someone who wants a modeline longer than 100 bytes please show us an example. How about a 200-byte limit? Oh, so nobody will need a long modeline? Just like they will never need more than [insert your favourite inaccurate prediction about the maximum amount of computing power anyone would ever need here]. Modelines are enabled by default, and are very useful for things like setting tabs. So most people, and all new installs, will have modelines enabled. It's very poor security practice to offer a rich auto-execution environment with a single line of defence (the sandbox). This discussion reminds me of the days of the Code Red vulnerability in IIS (Microsoft web server), and of the years of repeated vulnerabilities in Internet Explorer. The IIS and IE developers just couldn't bring themselves to build in limits to what their wonderful software could do. But a web site might need a 100KB URL with hundreds of '../' paths!. A web browser should be able to handle anything thrown at it in a way that doesn't compromise security. _Every_ application should be able to handle anything thrown at it in a way that doesn't compromise security. What you're suggesting isn't much different from security through obscurity. You're relying on the hope that nobody would ever be able to craft an exploit in under 100 bytes. Security doesn't work like that. Security needs to be something people can rely on to work every time, not something that depends on Well, let's hope nobody thinks of this. If Vim's modeline security is written correctly and securely then the length of modeline it can handle safely would depend only on the amount of memory it wants to allocate to hold it. If it isn't able to do that then there's no security at all. Furthermore, what am I supposed to do if I want a long, complicated but legitimate modeline? I would like a default high security setting for handling modelines. If people want modelines that do complex stuff, I would recommend setting a new anything goes option. ABSOLUTELY NOT! Are you honestly suggesting that to enter a long modeline you have to disable security? I wouldn't touch an editor like that. I like Perl's approach to untrustworthy data. It's flagged as tainted at the point it is read, and anything derived from it is also flagged as tainted. Perl has to have that system because part of its intended usage is to handle data entered into web pages. It's pretty complex and has taken years to get right. Vim is a text editor - it should not automatically execute code in any old file that I might accidentally open. Perl and Vim have exactly the same requirements: the need to safely handle code taken from an untrustworthy source. It makes no difference whether it comes directly from a network or from a disk. (If, like me, you use Vim as your source viewer for web pages, the need for the same level of security is obvious.) -- Matthew Winn
Re: who actually controls the window size of my gvim?
Zhaojun WU wrote: Hi, Vimmers, Just found an interesting problem but don't why. I am using Debian on my Linux box and used the vim-gtk package before. I have the settings like: = if has(gui_running) set guifont=BitStream\ Vera\ Sans\ Mono\ 11 set guioptions=mei only display Menu, Tab, and Icon colorscheme oceandeep set lines=60 columns=89 set cursorline Highlight Current Line in GUI mode endif == I set the lines and columns to make it start with a gvim window to cover half part of my screen (lines=60 and columns=89). This settings worked fine no matter when I run the gvim from the XFCE launch menu or from a command $gvim. Recently, I replaced the vim-gtk package with vim-full, if I launched it from the XFCE menu, it works like before (give me a 60x89 gvim window). But, if I run gvim from my bash prompt, I can get a window with random-sized gvim window. I am sure the gvim shortcut in the XFCE launch menu is also pointing to the gvim I ran on the my rxvt. So, in this case, I am just wondering who actually controls the lines, cols of my gvim window? Any difference btw vim-full and vim-gtk makes it happened? Thanks, Try :verbose set lines? columns? It should tell you where they were last set. Best regards, Tony. -- Sixtus V, Pope from 1585 to 1590 authorized a printing of the Vulgate Bible. Taking no chances, the pope issued a papal bull automatically excommunicating any printer who might make an alteration in the text. This he ordered printed at the beginning of the Bible. He personally examined every sheet as it came off the press. Yet the published Vulgate Bible contained so many errors that corrected scraps had to be printed and pasted over them in every copy. The result provoked wry comments on the rather patchy papal infallibility, and Pope Sixtus had no recourse but to order the return and destruction of every copy.
Re: arabic font
Babiker Osman wrote: Hi I am looking for appropriate arabic fonts to integrate with vim and how can i set it babiker The following assumes that you have a gvim version with Arabic support. Try :echo has(arabic) If the answer is nonzero (normally 1), it's OK. If it's zero, you need to find a more powerful executable. Setting the font in gvim means setting the 'guifont' option. This involves several steps: - finding a fixed-width font with Arabic glyphs (Vim cannot use variable-width fonts); - ascertaining how your version of gvim names that font; - writing the proper line into your vimrc. In my experience, the Courier New font is one of the rare monospaced fonts which includes Arabic glyphs. Now *any* monospaced font will make Arabic look ugly, but ugly is better than nothing. Another difficulty is that there are several different, incompatible formats for the 'guifont' version, depending on which GUI flavour is compiled into your gvim. Try pasting the following code snippet into your vimrc: if has(gui_running)only the GUI can set the font if has(gui_gtk2) GTK2 only, not GTK1 set gfn=Courier\ New\ 10 elseif has(gui_photon) set gfn=Courier\ New:s10 elseif has(gui_kde)the obsolete kvim set gfn=Courier\ New/10/-1/5/50/0/0/0/1/0 elseif has(x11)other X11 GUIs, including GTK1 set gfn=*-courier-medium-r-normal-*-*-100-*-*-m-*-* else non-X11 GUIs set gfn=Courier_New:h10:cDEFAULT endif endif This should sniff your GUI flavour and set a first-approximation Arabic font. The next step is checking whether you like the size. You can do this as follows: 1. Start gvim with a vimrc including the above snippet. 2. Enter :setlocal arabic then i to start Insert mode. 3. Type something in Arabic. It should appear near the top right of the editing area. If you want a bigger or smaller size, then hit Esc to go back to Normal mode, and then :set guifont=Tab where Tab means hit the Tab key. Vim will insert the current 'guifont' value, with escaping backslashes if and where needed. You may edit it (the first or only number is the font size), using Left and Right to move the cursor, and, after making changes, Enter to accept or Esc to cancel. Repeat until you like what you see (apart from the fact that Arabic always looks ugly in monospace). Once you have found which size pleases you best, enter the value into your vimrc by modifying the appropriate line in the code snippet shown above. See :help arabic.txt for more details about the specifics of Arabic editing with gvim. Best regards, Tony. -- A door is what a dog is perpetually on the wrong side of. -- Ogden Nash
Re: who actually controls the window size of my gvim?
John Orr wrote: Two cents worth - I've long had problems like this, on Suse Linux, where something, the OS I have assumed, or the X graphics system, takes control of the sizing of my gvim application. The size is initially set by my lines and columns settings, but something else resizes it afterwards, making lines and columns no longer valid. The only reliable solution I found was to write a function to resize my window, and to install an autocmd using the CursorHold event, with a suitable updatetime set. I tried using other autocmds, eg GUIEnter and VIMEnter, but they fired before the OS had its say. The idea - let the OS size gvim as it wants, and a second or so afterwards, with no key strokes pressed, the Cursorhold event fires and my function fixes things. It's a horrible solution, and wastes time on startup - but it's quicker than me manually resizing, and I've got no better solution. I can provide some code if you want (though I'd love someone to resolve it properly). I'm on SuSE Linux too, also with a GTK2 GUI, and I don't need that kind of hack. Are you sure you set your lines columns _after_ you set your 'guifont' ? Changing the font means changing the character cell size, which in turn changes the maximum character height width of the editing area. Best regards, Tony. -- It is not true that life is one damn thing after another -- it's one damn thing over and over. -- Edna St. Vincent Millay
Re: help needed with completion in version 7
On Fri, Apr 27, 2007 at 11:23:06PM +0200, Bram Moolenaar wrote: Andrei Voropaev wrote: [...] Unfortunately it's not just a missing screen. If you try to do completion again it won't work. So again, type the beginning of word, hit Ctrl-N, hit Backspace, type ( and beginning of another word, hit Ctrl-N to complete it. It won't work saying that there are no matches. That's because old completion is still active and it tries to complete the whole thing. This happens very often when one has to write C functions :) So, I would say this is a more serious bug than just missing update of the screen. When you press Backspace you go into a mode where you edit the text, so that you can change the list of matches. Aha, this is a feature after all. Is this something new for Version 7? I don't remember such behaviour in the old version. I guess there's no way to turn this feature off, since it is very confusing for me. I feel it is much easier to hit Ctrl-N one more time after I've done my adjustments, than to remember, that any adjustment I start will result in almost endless completion. In fact it is still broken. Let's look at example. I have word brown in text. Now I type bru and hit Ctrl-N. Completion says No matches. I think oops, typo, hit BackSpace, Oops. Completion has ended :) So, this appears to be the feature that works where it shouldn't, but does not work where it should :) It's difficult to decide when to leave this editing mode. Also because you can make a typo, and expect Backspace to correct that. If the key exits completion mode you can't go back to what you were doing. It's strange that you are saying it's difficult to decide when to leave the editing mode. As soon as there are no matches after my editing, the completion shall stop, just like it stops when I don't hit the BackSpace key. Or do I miss something? I mean, why appending to what I've typed is different from modifying it? Essentially it's just different way to modify the input for the completion function. From my naive point of view, the logic should be something like following. User starts completion of a word. Display available matches if any, wait for input. More text provided, leave the completion as soon as text does not match anything. Text is reduced using BackSpace, then adjust the matches, return to waiting for input or stop completion, if the user deleted the word completely. If you find a way to reproduce this undo line numbers wrong error then I would very much like to see it. It's hard to fix something that I can't reproduce. Yes, I know :) I'll keep looking. Hopefully this was already fixed by the patches. I was missing about 150 of them :) Andrei
Re: who actually controls the window size of my gvim?
On Monday 30 April 2007 19:21, A.J.Mechelynck wrote: John Orr wrote: Two cents worth - I've long had problems like this, on Suse Linux, where something, the OS I have assumed, or the X graphics system, takes control of the sizing of my gvim application. The size is initially set by my lines and columns settings, but something else resizes it afterwards, making lines and columns no longer valid. The only reliable solution I found was to write a function to resize my window, and to install an autocmd using the CursorHold event, with a suitable updatetime set. I tried using other autocmds, eg GUIEnter and VIMEnter, but they fired before the OS had its say. The idea - let the OS size gvim as it wants, and a second or so afterwards, with no key strokes pressed, the Cursorhold event fires and my function fixes things. It's a horrible solution, and wastes time on startup - but it's quicker than me manually resizing, and I've got no better solution. I can provide some code if you want (though I'd love someone to resolve it properly). I'm on SuSE Linux too, also with a GTK2 GUI, and I don't need that kind of hack. Are you sure you set your lines columns _after_ you set your 'guifont' ? Changing the font means changing the character cell size, which in turn changes the maximum character height width of the editing area. You had my hopes up for a moment there Tony, as I raced to my vimrc... but alas, definitely setting guifont before lines and columns (and winpos). I'm probably doing something else odd, but I've no idea what. Thanks, John Best regards, Tony. -- It is not true that life is one damn thing after another -- it's one damn thing over and over. -- Edna St. Vincent Millay
Re: who actually controls the window size of my gvim?
Hi, Tony and John, As I posted in my first email, I am also setting the guifont *before* the columns and lines setting. I think I find out where those strange lines and columns number are from after I check the columns and linessettings in the gvim opened from my urxvt terminal. It used the same geometry of the urxvt window as its lines x columns, no matter what I set them in .vimrc. I am a bit busy right now so cannot figure it out right now. I will get back to this issue in the coming days. Thanks, Zhaojun On 4/30/07, John Orr [EMAIL PROTECTED] wrote: On Monday 30 April 2007 19:21, A.J.Mechelynck wrote: John Orr wrote: Two cents worth - I've long had problems like this, on Suse Linux, where something, the OS I have assumed, or the X graphics system, takes control of the sizing of my gvim application. The size is initially set by my lines and columns settings, but something else resizes it afterwards, making lines and columns no longer valid. The only reliable solution I found was to write a function to resize my window, and to install an autocmd using the CursorHold event, with a suitable updatetime set. I tried using other autocmds, eg GUIEnter and VIMEnter, but they fired before the OS had its say. The idea - let the OS size gvim as it wants, and a second or so afterwards, with no key strokes pressed, the Cursorhold event fires and my function fixes things. It's a horrible solution, and wastes time on startup - but it's quicker than me manually resizing, and I've got no better solution. I can provide some code if you want (though I'd love someone to resolve it properly). I'm on SuSE Linux too, also with a GTK2 GUI, and I don't need that kind of hack. Are you sure you set your lines columns _after_ you set your 'guifont' ? Changing the font means changing the character cell size, which in turn changes the maximum character height width of the editing area. You had my hopes up for a moment there Tony, as I raced to my vimrc... but alas, definitely setting guifont before lines and columns (and winpos). I'm probably doing something else odd, but I've no idea what. Thanks, John Best regards, Tony. -- It is not true that life is one damn thing after another -- it's one damn thing over and over. -- Edna St. Vincent Millay -- Best, Zhaojun (Joseph)
Re: moving virual rectange about in virtualedit mode
I 'set ve=all' and selected a rectangle with Ctrl-V. How can I move this rectangle up/down left/right with arrows ? I assume you're asking how you can move the other sides of a visual block. When you're using visual block you usually have control of only one corner (southwest for me most of the time, but it could be any of the four). You can use the o and O commands to start moving different corners. Note that the o command also works in the other two visual modes, and so is very handy. No, I meant move as in, erase in old place and paint in new place. Well, could one not do something like the following? :vnoremap down downodowno :vnoremap up upoupo :vnoremap left leftolefto :vnoremap right rightorighto This still leaves the h/j/k/l keys for manipulating the size of the rectangle, and then allows the arrow keys for panning the selection. It should even work fairly well in all three block modes. It might have a little trouble at the top/bottom/left/right of your document where arrowing would try to push it off the edge. Or am I missing some wrinkle that set ve=all introduces? Or select mode rather than visual mode? (I don't use either so I don't know the nuances of them) -tim
Re: wish: show search progress on slow searches
On 4/29/07, Yakov Lerner [EMAIL PROTECTED] wrote: On 4/29/07, Bram Moolenaar [EMAIL PROTECTED] wrote: Yakov Lerner wrote: Wish: when search is slow, show the progress line number every second on the bottom line (like, 12345 of 9). What is slow? To my taste, when something takes longer than 1-2 sec, I'd prefer some visual feedback on the progress. Checking if the second passed will make the search even slower. Checking time is quite slow on some systems (the check for CTRL-C suffers from this). Checking for time every several hundred (N) lines will probably not slow the search perceptibly. N can be configurable, a parameter. Some value between 10 and 1000 will probaby be reasonable. Yakov I think it's possibe to check for time, which searching, not too often and not too seldom, even without user-defined parameter. Adaptive algorithm with two counters will find the right rate or time-checking: - as we start search, we check time every 50 lines (N=50 is initial value of N). We maintain counter M. M is how many times we called time() between the seconds changed. M is checked and reset every second. M is checked as folllows: - If M is too high (M10), then we adjust N by increasing it. If M is too low(M10), then we adjust N by decreasing it. Ideally, we want to check time() ~10 times per second. (overhead of 10 calls to time() per second cannot he high, right ?) - if search progresses for several seconds, then N quickly converges to the ideal value (~10 checks/sec). - we start every search with same value of N (say, 50). If search is slow, then N will quickly converge to the ideal value for this regex, the value in which where time() is checked ~10 times per second. Yakov
autocmd help - Sending new buffers into tabs
VIM, when opening buffers, seem to hide current one and replace it with the newly opened one. I want it to behave so that it instead opens a new tab and opens the new buffer there. I tried something like: autocmd BufReadPre * call CreateTab() let s:firstcall = 1 function! CreateTab () if (s:firstcall) let s:firstcall = 0 else tabn endif endfunction The firstcall is to ignore the starting file which already has it's own window. This doesn't work so well because somehow BufReadPre doesn't really seem to happen before slamming the buffer into the current window. I have read the helpfile for autocmd a couple of times, but I really can't make out which autocmd is appropriate, there are so many to choose from. -- View this message in context: http://www.nabble.com/autocmd-help---Sending-new-buffers-into-tabs-tf3669182.html#a10252039 Sent from the Vim - General mailing list archive at Nabble.com.
[converted]?
Never saw *this* before... There's one file (.htm) that I edit, and every time I write it to-disk, it'll say [converted], much the way you'd see on reading a file the status message that lists any non-native format or other quirks of the file, eg, [unix], [noeol], etc. (At least that's what I recall; the file's at home and don't have access to it here.) Uhhh, converted from/to *what*?? I explicitly set the file format to dos (running on w98), then write it out with changes, etc., and quit, but every time I fire up even a new session of 'vim' and read it again to edit it, I get the same [converted] text on writing it back out. So it seems to be writing it back to the same converted way it was before, enough that it always lists that text on writing the file even in a new editing session. I did ':help converted^D' but came up with nothing that seemed relevant. Any ideas?
Re: [converted]?
There's one file (.htm) that I edit, and every time I write it to-disk,
it'll say [converted], much the way you'd see on reading a file the
status message that lists any non-native format or other quirks of the
file, eg, [unix], [noeol], etc. (At least that's what I recall;
the file's at home and don't have access to it here.)
Uhhh, converted from/to *what*??
It's an encoding issue:
:help read-messages
where you'll read the terse blurb:
conversion from 'fileencoding' to 'encoding' done
indicating that the file was encoded in one way ('fileencoding')
but your vim is set to use 'encoding', so the file was converted
from 'fileencoding' to 'encoding'.
It would be nice to have a link so that
:help converted
dropped you right there in the docs, but at least
:helpgrep converted]
found it.
-tim
RE: [converted]?
There's one file (.htm) that I edit, and every time I write it
to-disk,
it'll say [converted], much the way you'd see on reading a file the
status message that lists any non-native format or other quirks of the
file, eg, [unix], [noeol], etc. (At least that's what I recall;
the file's at home and don't have access to it here.)
Uhhh, converted from/to *what*??
It's an encoding issue:
I suspected something along those lines, but there was no meta ...
tag listing any weirdo charset (utf8, unicode, windows1252, whatever),
no non-ascii chars (that I could see), etc.
Come to think of it, there were some latin quotes, so might be an errant
'aelig;' or something similar embedded in text only as a character
itself, not a named entity. Something like that might sneak by me...
:help read-messages
where you'll read the terse blurb:
conversion from 'fileencoding' to 'encoding' done
Aha. Didn't see that text anywhere when reading/writing the file, and I
was purposely looking for such a thing as a clue.
indicating that the file was encoded in one way ('fileencoding')
but your vim is set to use 'encoding', so the file was converted
from 'fileencoding' to 'encoding'.
Will have to look.
Personally, I *hate* when people do that, instead of using, say, a
portable entity; for non-ascii chars.
It would be nice to have a link so that
:help converted
dropped you right there in the docs, but at least
:helpgrep converted]
found it.
Kewl, tnx. Will have a look-see...
RE: determining if buffer is modified.. etc
-Original Message- From: Yakov Lerner [mailto:[EMAIL PROTECTED] Sent: Monday, April 30, 2007 1:53 PM To: Normandie Azucena Cc: vim@vim.org Subject: Re: determining if buffer is modified.. etc On 4/30/07, Normandie Azucena [EMAIL PROTECTED] wrote: hi all! I need to know if a certain buffer is modified. how can I do this? if modified | echo buffer is modified | endif also can I disable the prompt that says that buffer or file has changed and gives me an option to load the new file or not? because I want vim to automatically load changed files at certain times(i.e. when I invoke a certain function that automatically change the contents of the files) Add exclamation mark to the command Yakov hi yakov! tnx for the info. however about my 2nd question, what I wanted to know is this scenario I have a file lets say myfile. its currently open to a buffer. but then I input this file to a perl script then save the results what vim will do is prompt me that my file changed and make me choose to load it or not (because it is open in a buffer). This scenario is what I don't want to happen because obviously it was really my intention to change the file in the first place. can I disable this prompt somehow? tnx! normandie
Re: undo line numbers wrong
* A.J.Mechelynck [EMAIL PROTECTED] [070427 10:11]: Talk nicely to your sysadmin or your sysop, maybe around a glass of beer or a cup of coffee if you can, and try to convince him to upgrade Vim. He may not like compiling it himself though, even though it is not really hard: see my Vim cheat sheet, http://users.skynet.be/antoine.mechelynck/vim/compunix.htm -- you may want to print that for him before you talk to him. He may be interested in the fact that his current version dates back to begin October, and that since then 111 more patches (including the ones you need) have been published, including several new ones yesterday. Best regards, Tony. If he's not willing to compile vim himself, ask if he is willing to install the version from lenny, which is (currently) 1:7.0-219+1. This will at least get you close to the latest. Your other alternative is to compile it yourself and leave it in your own ~/bin directory. I've not tried mucking with the install target to get make to install in ~/bin and ~/.vim, but you can build it and manually move the files yourself. ...Marvin
...to shoot into oneelse feet...
Hi, is it possible to get out of a started change command (dont know, whether this is this the correct naming...) with a single key pressed ? For example the text is Vim is a #eally$nice editor. # is marking my cursor position and $ is the sign appearing after I have submitted cfn already. Since vim is really a nice editor, I do not want to change anything and pressed cfn by accident. HmmmESC kills everything between # and $... u would undo it...but this like do the wrong thing and repair it afterwards. What I want is to prevent doing wrong things by aborting them,..not to do them and saying ooops sorry...my fault afterwards and starting repairing the desaster then... :) Sohow can I _abort_ this ? Keep editing! mcc -- Please don't send me any Word- or Powerpoint-Attachments unless it's absolutely neccessary. - Send simply Text. See http://www.gnu.org/philosophy/no-word-attachments.html In a world without fences and walls nobody needs gates and windows.
Re: ...to shoot into oneelse feet...
Original Message Subject: ...to shoot into oneelse feet... From: [EMAIL PROTECTED] Date: Mon, April 30, 2007 11:36 am To: vim vim@vim.org Hi, is it possible to get out of a started change command (dont know, whether this is this the correct naming...) with a single key pressed ? For example the text is Vim is a #eally$nice editor. # is marking my cursor position and $ is the sign appearing after I have submitted cfn already. Since vim is really a nice editor, I do not want to change anything and pressed cfn by accident. HmmmESC kills everything between # and $... u would undo it...but this like do the wrong thing and repair it afterwards. What I want is to prevent doing wrong things by aborting them,..not to do them and saying ooops sorry...my fault afterwards and starting repairing the desaster then... :) Sohow can I _abort_ this ? Just press ESC followed by u to undo. Or, press ESC follwed by :q! to get out completely.
Again on gvim menu disappeared
Some time ago I posted a note on this topic. I received many kind answers but the problem was not solved. I just received a suggestion by G. Laurent, and it did the trick: rm .gnome2/Vim That's all! A simple interference of parameters. This file has some info on position and menu, such as Dock=Toolbar\\0,1,0,0\\Menubar\\0,0,0,0 and it did interfer. I just posted this mail because it may be useful to others in the future. Many thanks! gm --- Guido Milanese http://docenti.unicatt.it/milanese_guido http://www.arsantiqua.org
