Re: visual selection invisible in default color scheme when
Georg Dahn wrote: Vim 7.0e02 / Windows XP: 1. gvim -u NONE 2. colo desert 3. colo default Then the visual selection is invisible and the error message Warning: terminal cannot highlight is shown. This behavior is reproducible with other color schemes than desert (like morning, evening...). However, doing 'colo desert' is not necessary. Just do 1. gvim -u NONE 2. colo default and visual selection is invisible, too, and the error message is shown again. Thanks for the clear example. I'll fix it. -- hundred-and-one symptoms of being an internet addict: 186. You overstay in the office so you can have more time surfing the net. /// Bram Moolenaar -- [EMAIL PROTECTED] -- http://www.Moolenaar.net \\\ ///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\ \\\download, build and distribute -- http://www.A-A-P.org/// \\\help me help AIDS victims -- http://www.ICCF.nl ///
Re: omni-completion: info bug
Dnia czwartek, 20 kwietnia 2006 13:04, Bram Moolenaar napisał: Aaron Griffin wrote: Just a heads up: Using an omni-completion dictionary, a single completion entry (for which no menu is displayed) does not update the info preview window. Yes, filling the preview window is part of the code for the popup menu. If there is only one alternative you don't really need more info to make a choice, right? But old 'info' stays which may lead to misunderstandings. m.
Re: Moderator for Vim Tips
On Wed, Apr 19, 2006 at 08:21:49PM -0400, Jeremy Conlin wrote: A few weeks (months?) ago a suggestion was made that the submissions to Vim tips be moderated. This is due to the address being used by spammers. Apparently nobody volunteered to do this because there are still inappropriate tips being submitted. I am willing to do this, but I don't have the expertise required to test all the tips. I can screen them to make sure they are appropriate. Would that agree with anyone? IMHO all a moderator should do is reject tips which are spam. The vim community can (and should) test the tips, vote on them, and post comments as desired :). Gautam -- 'eieio' -- A gross misspelling of the word 'farm'.
Re: Code completion suggestions...
On 4/20/06, Bram Moolenaar [EMAIL PROTECTED] wrote:
Eric Van wrote:
Code Completion suggestion.
Ok, first a little context.
I currently have a project which provides an interface for vim to
invoke commands via system() calls which are executed in a headless
eclipse instance.
I use this interface to provide code completion for java source files
and ant build files, which both work great. My issue comes into play
when I attempt to provide completion info (for display in the new
completion preview window in vim). Retrieving this extra info can
result in a lot of extra processing on the eclipse side and depending
on the size of the completion set, can dramatically affect the
performance.
Most of this should already be possible using complete_add() and
complete_check(). See below :help complete-items.
Unfortunately not, since I'm using a system() call, so I get all the
results at once.
So, I propose a means to lazily retrieve info for a completion.
Basically it should be like a CursorHold, but in the context of the
completion popup. If the user stops on a completion for some
determined amount of time, vim should then, ideally, spawn off a
thread to retrieve the info for that completion and display it in the
completion preview. I think it is key to do this retrieval in an
asynchronous way so as not to prevent the user from moving to the next
completion or performing some other action.
Using threads is a difficult thing to do in a portable way. Vim is
build with threads in some situations (e.g., when using the Python
interface) and this often causes problems. On some systems threads are
not possible.
That's probably fine since retrieving the info for a single completion
should be quick... it's retrieving info for many that can be slow.
To accomplish this, I also suggest that the means for defining how
completion is to be handled, be modified.
Currently completion is defined as follows:
setlocal completefunc=3DSomeFunction
With a single function
function SomeFunction (findstart, base)
Instead of defining a single function, I propose that a script be
defined instead:
setlocal completescript=3Dfoo/bar/mycompletion.vim
Where the script is located via the autoload directory and contains
the following functions (of which the first 2 are required, and the
third is optional)
find the column in the current line where the completion starts
function foo#bar#FindCompletionStart ()
find the list of completions given the supplied base.
function foo#bar#FindCompletions (base)
find additional info for the completion at the supplied index
within the current completion results
function foo#bar#FindCompletionInfo (index)
If implemented in this fashion, you gain a few advantages:
1. Completion info is only retrieved for completions that the user
chooses to view and not for the possibly many others for which the
retrieval would have been completely wasted.
This will break the use of the completion menu. It's better to have all
possible completions, so that the user knows how many possibilities
there are. Since Vim checks if the user typed something while it's
still searching this should not be a disadvantage.
Maybe I didn't explain this correctly... I would expect the flow to be
- User hits C-XC- O or U
- vim executes foo#bar#FindCompletionStart instead of
CompletionFunction(1, '...')
The starting column of the completion is returned.
- vim executes foo#bar#FindCompletions('...') instead of
CompletionFunction(0, '...')
The FULL list of completions is retuned, but in this case the 'info'
attribute of the contained dictionaries is empty (since they would
be lazily retrieved later, only when needed)
- User stops on a completion for a determined amount of time
- vim then executes foo#bar#FindCompletionInfo(index), where index
is the index of completion the user paused on.
- vim displays the that info in the preview window
When using netbeans or eclipse this lazy loading of the 'info' text is
very apparent (especially in netbeans). As you navigate down the
completion menu, the info loads only after you have paused on an entry
(eclipse in about half a second, netbeans in about a second and a half).
2. More optional functions could be added to this completion script in
the future without breaking compatibility with previous releases.
While I'm at it another suggestion I have would also to be to add
another function to my proposed script paradigm:
function foo#bar#FindCompletionEnd ()
Which would find the ending column of the word to be replaced by the
completion. So if I am have the following ('|' denoting the cursor
position):
List mylist = ...
mylist.ad|d(
The 'd' after the cursor position could be replaced when I choose
amongst my choices of 'add' or 'addAll', instead of having to
Re: Feature request: expr for abbreviations
On Thu, 20 Apr 2006 at 1:04pm, Bram Moolenaar wrote: Hari Krishna Dara wrote: In Vim7, I see that maps can now have expr argument to indicate that the RHS is an expression that should be evaluated. I think this is cool, and though I don't have a need yet, I am pretty sure it will come to good use soon. But meanwhile, I think the same should be extended to abbreviations too. I know you can already use C-R= for the same, but the expr method is going to be useful specifically for the cabbr case. Currently if you need to define a cabbr that uses the C-R= construct to evaluate an expression, this causes trouble when typing the abbreviation (even if it is accidental) at the expression register prompt. Did you try it? It should already work. Thank you so much, it is there and works great for me. I presume documentation is pending on this? -- Thanks, Hari __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Re: vim7: request for new autocommands
On Thu, 20 Apr 2006 at 1:04pm, Bram Moolenaar wrote: Hari Krishna Dara wrote: On the lines of InsertEnter and InsertLeave, can we please have CommandEnter and CommandLeave that will get triggered when the user starts one of the :, /, ?, = etc. modes? The reason I ask is, with the addition of getcmdtype(), it is now possible to create maps and abbreviations dynamically that only apply to a particular type of prompt, provided we can know when the mode starts and when it ends. It's too close to a release to add that now. It already was in the todo list. Thanks, I will wait for them to be added, hopefully in 7.1 or a patch for 7.0? Using these autocommands will make my script a lot cleaner and reliable to detect when the command prompt is done. -- Thanks, Hari __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Re: Feature request: expr for abbreviations
Hari Krishna Dara wrote: In Vim7, I see that maps can now have expr argument to indicate that the RHS is an expression that should be evaluated. I think this is cool, and though I don't have a need yet, I am pretty sure it will come to good use soon. But meanwhile, I think the same should be extended to abbreviations too. I know you can already use C-R= for the same, but the expr method is going to be useful specifically for the cabbr case. Currently if you need to define a cabbr that uses the C-R= construct to evaluate an expression, this causes trouble when typing the abbreviation (even if it is accidental) at the expression register prompt. Did you try it? It should already work. Thank you so much, it is there and works great for me. I presume documentation is pending on this? Oh, it's not mentioned at :help :abbr. I'll add something. -- hundred-and-one symptoms of being an internet addict: 222. You send more than 20 personal e-mails a day. /// Bram Moolenaar -- [EMAIL PROTECTED] -- http://www.Moolenaar.net \\\ ///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\ \\\download, build and distribute -- http://www.A-A-P.org/// \\\help me help AIDS victims -- http://www.ICCF.nl ///
Re: omni-completion: info bug
On 4/20/06, Bram Moolenaar [EMAIL PROTECTED] wrote:
Nice feature, right? I'll add a remark about that. The idea is that
the preview info remains there for a while, so that you can see function
arguments, for example, while you continue typing. But if you want to
explicitly clear it using a space is a good idea.
If I didn't know anything about it, I would expect it to work as follows:
if length of info text 0, clear window and output text
else remove preview window
It might be nice to offer two options: '' will kill the preview window
and ' ' would blank it.
Is there any possiblity to get the preview window to pop up for single
completions? If not, I can always force a single empty entry like
{'word':'', 'abbr':'[Cancel]'} or some such oddity...
Re: netrw needs more keepjumps?
On Thu, 20 Apr 2006 at 9:58am, Charles E Campbell Jr wrote: Hari Krishna Dara wrote: The new version of netrw seems to be a lot better than the old explorer in terms of not corrupting jumplist, but I think there is more work needed. Ideally, when you open a directory, you should see only one new entry for each, and it should be in the natural order. What I am seeing right now is more than one, and it is even confusing. Also, if you open a couple of directories in sequence and try to get back to the original file using ^O, then the jumplist goes into a loop and you can never come back to the original file. If the directory is entered by means of pressing ^O, I think it should completely avoid modifying jumplist. Hello! Please try setting g:netrw_fastbrowse=0 in your .vimrc. Hopefully the jumplist will then be retained. Regards, Chip Campbell Did you mean the value 2? The value 0 didn't help so looked at the help and figured 2 might help and it did, as I can now ^O out of multiple directories. This is not ideal because I don't really want those directory buffers cached around, but can live with that for now. Are you planning to fix this problem? I looked at the code, and there are so many individual places the :keepjumps command is used, so don't know where else it needs to be prefixed. I was hoping we can just prefix the main functions/commands, but the help clearly says it won't work. -- Thanks, Hari __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Re: omni-completion: info bug
Dnia czwartek, 20 kwietnia 2006 17:12, Aaron Griffin napisał: On a related note, an 'info' dict entry of '' does not change and/or remove the preview information. Using a single space blanks the window, but an empty string does not. And this is Good Thing :) m.
RFC: (x)html completion support in Vim7
Hello, I am author of (x)html completion scripts and related (php, css, javascript). I'd like to ask what you think it should like. At the beginning I was pushing for one default: XHTML 1.0 Strict. Bram didn't like it and now there are two: fot ft='html' HTML 4.01 Transitional and for ft=='xhtml' XHTML 1.0 Strict (user can still choose another version with b:html_omni_flavor variable - this improvement may be not yet in snapshot/cvs/svn). Bram still doesn't like it. According for him completion should be more flexible and not limited to some standard. For me it defies whole idea of omni-completion - completion suggestions should be precise. Problem with (X)HTML is there are many standards but creation of messy compilation from them has no sense. Vim is superb program and should support writing of good code - according to standards. To make this support full it could look: - provide data files for most of (X)HTML standards: - HTML 3.2 Strict (for legacy pages) - HTML 4.0 Transitional - HTML 4.0 Strict - HTML 4.0 Frameset - HTML 4.01 Transitional - HTML 4.01 Strict - HTML 4.01 Frameset - XHTML 1.0 Transitional - XHTML 1.0 Strict - XHTML 1.0 Frameset - XHTML 1.1 That is 11 data files, ca. 45kB each (5kB packed) - total 500 kB (55kB) Add functions for detection of DOCTYPE to ftplugins for xhtml and html. Still there is usability problem for creation of new files. Maybe some general completion for insertion of DOCTYPE and setting appropriately completion. TIA for comments. m.
Re: netrw needs more keepjumps?
Hari Krishna Dara wrote: On Thu, 20 Apr 2006 at 9:58am, Charles E Campbell Jr wrote: Please try setting g:netrw_fastbrowse=0 in your .vimrc. Hopefully the jumplist will then be retained. Did you mean the value 2? Whoops -- yes, I meant 2. If you want the jumplist to work, you need places to jump to, which in turn means cached buffers. That's the way that netrw used to always work; the fastbrowse stuff is relatively recent, and to implement it netrw deliberately wipes out netrw buffers that aren't being currently displayed. So, its a trade-off for users to make. Hidden (ie. :ls won't display netrw buffers), but available, thereby making fast re-displays of previously seen directory listings. Also makes the jumplist useful. Versus: re-acquisition of a directory listing every time a directory is entered, so netrw's directory listing is up-to-date as of the display time (cursor leaving/entering will also cause netrw to update browser displays), but the jumplist is forgetful. Regards, Chip Campbell
Re: omni-completion: info bug
Dnia czwartek, 20 kwietnia 2006 21:59, Aaron Griffin napisał:
Is there any possiblity to get the preview window to pop up for single
completions? If not, I can always force a single empty entry like
{'word':'', 'abbr':'[Cancel]'} or some such oddity...
:help completeopt
menuone flag
m.
Re: omni-completion: info bug
Dnia piątek, 21 kwietnia 2006 00:20, Aaron Griffin napisał: Ack, sorry - that was supposed to go to the list On 4/20/06, Mikolaj Machowski [EMAIL PROTECTED] wrote: Dnia czwartek, 20 kwietnia 2006 17:12, Aaron Griffin napisał: On a related note, an 'info' dict entry of '' does not change and/or remove the preview information. Using a single space blanks the window, but an empty string does not. And this is Good Thing :) Well here's the way I see it. If I have completions like so (format word:info): abc : 'this is info for abc' def : '' ghi : 'this is info for ghi' Starting on 'abc', you move down to 'def', and the info for 'abc' is left in the window. Fine, that may be intentional. Moving down to 'ghi' will switch the info, then moving back up to 'def' will give you the wrong info, assuming the 'correct' info was the entry for 'abc'. Buf if:: def : ' ' Window will be cleared. And that is Good Thing. m.
Re: Mappings fail me, yet again
On 4/21/06, Nikolai Weibull [EMAIL PROTECTED] wrote:
Still, I figured that now that we have operator functions ...
I would be able to define my long-wanted g:
mapping that makes : act like an operator, i.e., first waits for a
range and then starts command mode with that range on the command
line:
noremap silent g: Esc:set operatorfunc=GetCommandModeRangeCRg@
function! GetCommandModeRange(type)
let b = line('[)
let e = line('])
if b e
let range = '.,+' . (e - b)
elseif b == e
let range = '.'
else
let range = '.,+' . (b - e)
endif
start command mode with 'range' already on the command line
...
endfunction
The question is, how do I start command mode?
Does this work for you inside the function :
:exe normal :.range
?
Yakov
Re: Setting Abbreviatons In .exrc Problems
On Thu, 20 Apr 2006, Mark Sargent wrote: Hi All, I'm trying to get vi to display an ab like so(minus the \), ab htm !DOCTYPE html PUBLIC -//W3C//DTD HTML 4.01 Transitional//EN \html \head \meta content=text/html; charset=UTF-8 http-equiv=content-type \titleNewUser/title \/head \body \/body \/html [snip] Mark, Here's an alternate suggestion: You may want to take a look at :help template. It may be better to have a file with the HTML header/skeleton elsewhere that you can read in to your current buffer on demand. For example: :read skeleton.htm This way, you don't have to wrestle with :abbreviate - you can make skeleton.htm as pretty as you wish (indents and all). Besides, abbreviating htm may cause future problems everytime you do type htm. You could try a mapping instead: nnoremap \htm :read skeleton.htmCR With the mapping above, in Normal mode, type \htm and skeleton.htm will be inserted into your text. Hope this helps. -- Gerald
Re: Setting Abbreviatons In .exrc Problems
Yakov Lerner wrote: which is not the desired result. If I remove the leading backslashes, I get errors when starting vi, Does adding cr into your :ab command, into those places where you want linebreaks, help ? Like this: :ab htm !DOCTYPE html PUBLIC -//W3C//DTD HTML 4.01 Transitional//EN \crhtml \crhead Hi All, yes, indeed it works. Great stuff!! Thank you, Yakov. Cheers. Mark Sargent.
Re: Displaying Opened File Name in Terminal Title
Yakov Lerner wrote: This is possible. But first, try this: :set laststatus=2 and see if it helps. Hi All, Yakov, that is it. Again, great stuff. Cheers. Mark Sargent.
Re: Vim7 mouse cursor focus freaking
On 4/20/06, Bram Moolenaar [EMAIL PROTECTED] wrote: Eric Arnold wrote: Certain things seem to cause Vim7 to do go into some odd loop when the mouse moves the cursor into a different window. So far I've seen it when 1) I've got the command line edit window open, and the mouse moves the cursor to another window (usually happens when I switch away from Vim and back). Something is flashing non-stop in the lower right of the command line (probably some mouse string, but it's a bunch of unreadable chars). The input focus doesn't actually change away from the command edit window (typing stuff goes there). In what way does the mouse moves the cursor to another window? Do you mean you click there? Yes, I mean that I do something that moves the mouse, either inside Gvim, or moving to another MSwin application and back. I don't have to *click* in another window, as I have 'mousefocus' on. 2) when I have tabline set to my own function, it interacts with taglist and other specialized buffers (which have non-standard autocommands, among other things). Sometimes C-C will stop the looping until the mouse moves the cursor agai= n. It might have something to do with the way Vim is re-setting the cursor position to the lower right of the screen sometimes, even though the input focus remains in the correct window. Does this only happen when you have a taglist window open? No, but it goes particularly wild when I do. Otherwise, I get occasional flickers of odd [mouse input?] chars in the lower right (where it displays Normal commands in progress), and it takes several seconds to deliver focus to the window the mouse is moved to. Sometimes the mouse warps to the lower right of the screen regardless of what window I move the mouse to. (This stuff happens without having the command line edit window open.) I'm wondering if part of this is related to the problem discussed earlier where the tabline function gets called too often (with respect to the constant flow of spurious input, though the spurious mouse warping doesn't seem related). Note that when the command line window is open, the cursor is not allowed to go to another window. You must finish typing the command first. If it does go to another window there is a problem that needs to be fixed. No, it doesn't go to another window, but it does get that constant stream of spurious Normal (??) input as long as the mouse isn't positioned over the command line window. Is this in GUI or console Vim? GUI, MSWin. The xterm I'm using doesn't have any focus differentiation between Vim windows inside VIm.
Re: beta 7.0e and cmdline_comp on ubuntu
On Thu, Apr 20, 2006 at 11:45:41AM +0200, Raphael Bauduin wrote: Hi, I have compiled beta 7.0e on ubuntu, but command completion doesn't seem to work. A tab displays ^I. Did I miss something obvious? :set nocp :help 'compatible' HTH --Benji Fisher
Re: beta 7.0e and cmdline_comp on ubuntu
On 4/20/06, Benji Fisher [EMAIL PROTECTED] wrote: On Thu, Apr 20, 2006 at 11:45:41AM +0200, Raphael Bauduin wrote: Hi, I have compiled beta 7.0e on ubuntu, but command completion doesn't seem to work. A tab displays ^I. Did I miss something obvious? :set nocp :help 'compatible' HTH --Benji Fisher That was it indeed, thanks! Not sure why it works with the packaged vim as I nowhere found nocp (no vimrc listed by vim --version contained that command). Is there a compile time configuration possible? Cheers Raph
Re: bugs in spanish dictionary
On Thu, Apr 20, 2006 at 01:04:07PM +0200, Bram Moolenaar wrote: Luis Jure wrote: where can i report bugs in the spanish dictionary? i have just installed vim 7 (as per the gentoo ebuild) and the spanish spell checker, and i found there are many words missing, some of them quite essential, like the conjunction y (and in spanish). you can imagine there is hardly a paragraph without at least one occurrence of that word... The Spanish dictionary (ca_ES) comes from Myspell. The README mentions http://es.openoffice.org. Can you give a few examples of good words that are not found? Then I can check this is a problem in the dictionary or in the way Vim uses the dictionary. If you think you can fix these problems, please become maintainer for the Vim Spanish dictionary. The procedure is to get the Myspell dictionary and applay patch. The maintainer can change the files and create a new patch. Hi, I'm using the Spanish dictionary and noticed also the lack of 'y'. I added it to my personal dictionary anyway, but it should be added to the distributed one. So far, it is the only commonly used word I have not found in the dictionary. Besides this, Vim 7 rocks. Regards, Matias
RE: Moderator for Vim Tips
Yongwei, I'm a moderator myself and just noticed something a few days ago: a perfectly legitimate tip had a follow-up comment that was one of the spam messages... Salman. -Original Message- From: Wu Yongwei [mailto:[EMAIL PROTECTED] Sent: Wednesday, April 19, 2006 9:35 PM To: vim@vim.org Subject: Re: Moderator for Vim Tips On 4/20/06, Jeremy Conlin [EMAIL PROTECTED] wrote: A few weeks (months?) ago a suggestion was made that the submissions to Vim tips be moderated. This is due to the address being used by spammers. Apparently nobody volunteered to do this because there are still inappropriate tips being submitted. I am willing to do this, but I don't have the expertise required to test all the tips. I can screen them to make sure they are appropriate. Would that agree with anyone? Jeremy Conlin There are quite a few moderators here. However, tips are not moderated *before* appearing online. They are deleted if found inappropriate. I just deleted one. If you check the recent tips, you will find some sequence numbers missing, which are deleted `tips'. Best regards, -- Wu Yongwei URL: http://wyw.dcweb.cn/
Re: Ruby + Vim
--- Meino Christian Cramer [EMAIL PROTECTED] wrote: Hi, I am looking for a hacked/tuned/patched/newer version of the ruby indentation/syntax highlightning files for vim. Look at the vim-ruby bundle on rubyforge. -- Thomas Adam ___ 24 FIFA World Cup tickets to be won with Yahoo! Mail http://uk.mail.yahoo.com
Re: Ruby + Vim
Hi, I am looking for a hacked/tuned/patched/newer version of the ruby indentation/syntax highlightning files for vim. Look at the vim-ruby bundle on rubyforge. I did: Last release is of 2005-10-07. The versioning of the files are older than those bundled with vim itsself Have you tried their anonymous CVS access? You can obtain directions at the following page: * http://rubyforge.org/scm/?group_id=16 If you've found a bug, then you can also submit it to this project. They have both a bug tracking system (http://rubyforge.org/tracker/?atid=145group_id=16func=browse) and a mailing list (http://rubyforge.org/pipermail/vim-ruby-devel/). Hope that helps! Tom Purl
Re: Ruby + Vim
From: Tom Purl [EMAIL PROTECTED] Subject: Re: Ruby + Vim Date: Thu, 20 Apr 2006 12:38:39 -0500 (CDT) Hi, I am looking for a hacked/tuned/patched/newer version of the ruby indentation/syntax highlightning files for vim. Look at the vim-ruby bundle on rubyforge. I did: Last release is of 2005-10-07. The versioning of the files are older than those bundled with vim itsself Have you tried their anonymous CVS access? You can obtain directions at the following page: * http://rubyforge.org/scm/?group_id=16 If you've found a bug, then you can also submit it to this project. They have both a bug tracking system (http://rubyforge.org/tracker/?atid=145group_id=16func=browse) and a mailing list (http://rubyforge.org/pipermail/vim-ruby-devel/). Hope that helps! Tom Purl I did a cvs checkout and found in the NEWS file the following paragraph: = 2005.10.07 == Vim 6.4 This release is included in Vim 6.4. == Bug Fixes Ruby filetype plugin - symbols were incorrectly being matched as match_words causing the matchit motion command to jump to an incorrect location in some circumstances. It is the same version I got from their homepage and a even newer version of the cvs snapshot is included in the vim-6.4 distro. I think their are not interested in any bug reports anymore... mcc
Re: bugs in spanish dictionary
Matias Grana wrote: On Thu, Apr 20, 2006 at 05:52:30PM +0200, Bram Moolenaar wrote: snip ... /snip I can see that the word y simply isn't there. Even my mini travelers dictionary has twelve words starting with y, but the ca_ES.dic file has only one... Shouldn't yo also be there? I would appreciate it if someone can look into this and find out how to fix the Myspell dictionary. Otherwise we can (temporarily) add these words to the Vim list. Yes, but I guess maybe you are looking at the wrong dictionary. ca_ES should be for Catalan, we are talking about es_ES here. I don't have the Spanish dictionary from OpenOffice in my machine. How can I parse the Vim file for it? I mean, es.utf-8.spl or es.utf-8.sug. Oh, do y and yo only appear in es_ES and not in ca_ES? For generating the spell files yourself you need Aap. See www.aap.org. It requires Python. -- hundred-and-one symptoms of being an internet addict: 221. Your wife melts your keyboard in the oven. /// Bram Moolenaar -- [EMAIL PROTECTED] -- http://www.Moolenaar.net \\\ ///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\ \\\download, build and distribute -- http://www.A-A-P.org/// \\\help me help AIDS victims -- http://www.ICCF.nl ///
RE: Building Vim7 with Visual Studio 8
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Thursday, April 20, 2006 1:38 PM To: David Fishburn Cc: vim@vim.org Subject: Re: Building Vim7 with Visual Studio 8 David Fishburn wrote: Has anyone attempted to build Vim using Visual Studio 8? Yes, George Reilly has tried various configurations. New machine, trying to reduce the # of compilers I have to install. This could be a configuration issue. [...] Perl requested (version 58) - root dir is C:\Programs\perl Perl DLL will be loaded dynamically [...] -DDYNAMIC_PYTHON_DLL=\python24.dll\ -DFEAT_PERL -DDYNAMIC_PERL -DDYNAMI C_PERL_DLL=\perl58.dll\ -DFEAT_BIG /Zi /Fd.\ObjGOLY/ /I C:\Programs\perl\Lib\Core if_perl.c if_perl.c if_perl.xs(158) : error C2061: syntax error : identifier '__attribute__' if_perl.xs(158) : error C2059: syntax error : ';' Your problem appears to be with Perl, not with Vim. You may have a Perl for Unix and building Vim with MSVC doesn't work then. Hmm, just the standard ActiveState install: c:\programs\perl\binperl -v This is perl, v5.8.8 built for MSWin32-x86-multi-thread (with 25 registered patches, see perl -V for more detail) Copyright 1987-2006, Larry Wall Binary build 817 [257965] provided by ActiveState http://www.ActiveState.com Built Mar 20 2006 17:54:25 When I removed the Perl piece I did successfully build and compile Vim. So maybe the Perl code has to be updated for Visual Studio 8. Dave
Re: Best Way to open a file in a directory tree?
On 4/20/06, Curtis Spencer [EMAIL PROTECTED] wrote: I am looking for a nice way to open up a file in subdirectory if I know the first few characters of the name, ie.: :open helpress tab and then I see :open hello_world.c, if it is somewhere in some subdirectories of the current directory. Is there a nice way to do this? Try :e **/helTab Althoug I noticed this gives different results in vim6 vs vim7. Yakov
Re: vim7.0e beta tabs and buffers
On 4/20/06, Silent1 [EMAIL PROTECTED] wrote: Hi all, just tried out vim7.0e on my xp machine (at home and at work, although i'm setting my my new mac mini at home). I read thru the :help version7 and i was wondering how tabs work with buffers. I use minibuffer explorer to show the different buffers per window, i was wondering if you can have different buffers per tab and send buffers from one tab to another? You can have multiple windows per tab. I've been working on a couple related plugins. TabLineSet.vim adds information to the default tabline format that shows buffers per tab, buffer numbers, etc. If you want to send buffers between tabs, I uploaded WinWalker.Vim a few days ago which does a nice job with this. I'm not sure how to mix and match fold methods...
Re: Best Way to open a file in a directory tree?
On Thu, 20 Apr 2006 at 7:14pm, Curtis Spencer wrote: Hi, I am looking for a nice way to open up a file in subdirectory if I know the first few characters of the name, ie.: :open helpress tab and then I see :open hello_world.c, if it is somewhere in some subdirectories of the current directory. Is there a nice way to do this? I put the following in my vimrc: command! -nargs=* -bang -complete=custom,SIDPathComplete FindInPath \ :findbang args function! s:PathComplete(ArgLead, CmdLine, CursorPos) return UserFileComplete(a:ArgLead, a:CmdLine, a:CursorPos, 1, path) endfunction You need to set 'path' appropriately for this to work. The UserFileComplete() is a function from genutils.vim, so you need that plugin, or copy the relevant code from it into your vimrc. -- HTH, Hari __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Re: beta 7.0e and cmdline_comp on ubuntu
On 4/20/06, James Vega [EMAIL PROTECTED] wrote: On Thu, Apr 20, 2006 at 05:06:05PM +0200, Raphael Bauduin wrote: I looked there, but it's not set. ( I rechecked with a grep ;-) nocp is short for nocompatible which is set in Debian (and Ubuntu's unless they're deviating from us on that) /etc/vim/vimrc. that's it indeed. raph
Re: Ruby + Vim
--- Meino Christian Cramer [EMAIL PROTECTED] wrote: From: Thomas Adam [EMAIL PROTECTED] Subject: Re: Ruby + Vim Date: Thu, 20 Apr 2006 18:15:06 +0100 (BST) --- Meino Christian Cramer [EMAIL PROTECTED] wrote: Hi, I am looking for a hacked/tuned/patched/newer version of the ruby indentation/syntax highlightning files for vim. Look at the vim-ruby bundle on rubyforge. -- Thomas Adam I did: Last release is of 2005-10-07. The versioning of the files are older than those bundled with vim itsself mcc Not much has changed, that's why. I believe the stuff in the CVS has, as there's often fixes there at the moment that have not been released. Worth checking though. -- Thomas Adam ___ Switch an email account to Yahoo! Mail, you could win FIFA World Cup tickets. http://uk.mail.yahoo.com
RE: Best Way to open a file in a directory tree?
Curtis Spencer Sent April 20, 2006 12:15 PM Hi, I am looking for a nice way to open up a file in subdirectory if I know the first few characters of the name, ie.: :open helpress tab and then I see :open hello_world.c, if it is somewhere in some subdirectories of the current directory. Is there a nice way to do this? Reading :help find and :help path would make one think the preceding is doable, but I have never succeeded! I have tried adding various bits of .*,.**,./*,./** to path but it never worked. --Suresh
Re: Best Way to open a file in a directory tree?
We need an alternate index into the help doc.s for stuff like this that's too useful not to know. This falls under the category of I read that section, but it didn't register in my brain. Sadly, I suspect you'd need a digest for every help page :-/ More questions: the 'path' option seems to allow even more interesting stuff, but only for 'gf' and the like. Is there a way to have the :e ...tab completion use the 'path'? It would be cool to have dual upward/downward recursive completion (although I can't seem to get it to work as I expected with 'gf' either). On 4/20/06, Yakov Lerner [EMAIL PROTECTED] wrote: On 4/20/06, Curtis Spencer [EMAIL PROTECTED] wrote: I am looking for a nice way to open up a file in subdirectory if I know the first few characters of the name, ie.: :open helpress tab and then I see :open hello_world.c, if it is somewhere in some subdirectories of the current directory. Is there a nice way to do this? Try :e **/helTab Althoug I noticed this gives different results in vim6 vs vim7. Yakov
Re: c_CTRL-D, :find and 'path'
Hi Suresh, On 4/20/06, Suresh Govindachar [EMAIL PROTECTED] wrote: Hello Bram, Is the following :find partialC-D supposed to use 'path'? For me, it uses the current directory to suggest completions but not the 'path' -- am I doing something wrong? No. The command-line file name completion doesn't search for file names from the directories set in the 'path' option. You can use the following function and command: function! FindFileFn(ArgLead, CmdLine, CursorPos) let pat = a:ArgLead . '*' return substitute(globpath(path, pat), [^\n]\\+/, '', 'g') endfunction command! -nargs=1 -bang -complete=custom,FindFileFn \ FindFile findbang args - Yegappan
Re: vim7.0e beta tabs and buffers
Eric Arnold [EMAIL PROTECTED] wrote in news:[EMAIL PROTECTED]: On 4/20/06, Silent1 [EMAIL PROTECTED] wrote: Hi all, just tried out vim7.0e on my xp machine (at home and at work, although i'm setting my my new mac mini at home). I read thru the :help version7 and i was wondering how tabs work with buffers. I use minibuffer explorer to show the different buffers per window, i was wondering if you can have different buffers per tab and send buffers from one tab to another? Is it possible to make tabs default behaviour? ie gf or :e somefile would automatically open a new tab?
