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
