On 7/25/06, Mikolaj Machowski [EMAIL PROTECTED] wrote:
Dnia wtorek, 25 lipca 2006 02:14, Eric Van Dewoestine napisał:
1. We are in /home/mikolaj::
echo findifile(b, 1;)
1/b
You are giving findfile() a relative path to search, so it is
returning a relative result
Results of findfile() are inconsistent:
The results seem consistent to me.
/home/mikolaj/a
/home/mikolaj/1/b
/home/mikolaj/2/c
/home/mikolaj/3/d
/home/mikolaj/3/4/e
1. We are in /home/mikolaj::
echo findifile(b, 1;)
1/b
You are giving findfile() a relative path to
I would like to suggest the addition of a new command -
:tcd[!] {path}
This command would be like :cd and :lcd, but instead of changing the
global or window relative directory, :tcd would change the directory
for the current tab resulting in all currently open windows on that
tab and any new
Should prepending :silent to a command be suppressing an autocommand?
Neither the docs for autocommands nor the docs for :silent indicate
this is the intended behavior.
For example:
using the following the autocommand is executed as expected with the
desired output
vim -u NONE -c set
The default setting, wildmode=full , highlights (if anything) what it
actually completes. If you repeatedly hit the right-arrow key, it will
cycle through all full matches and what you had typed. See :help
'wildmode' for the various other possibilities. Whatever you see
highlighted on the
On 4/24/06, Eric Van Dewoestine [EMAIL PROTECTED] wrote:
I'll move it then. Please try it out with the next snapshot.
Appears to be working as expected.
Actually, I've found one small issue with this...
If the executed make command results in one or more errors added to
the quickfix
When starting vim as follows
vim -u NONE -c set nocompatible | set wildmenu | set
wildmode=longest:full,full
if you perform
:eTab
you get a list of commands starting with 'e' and the command line is
unchanged (still only contains 'e').
The only issue, is that the first entry in the list is
Do you mean that the autocommand removes all matches? Well, somehow I
think it's good to give the message then. But perhaps it's just another
execuse to give this deep error message :-).
Yes, the autocommand may remove all entries from the quickfix list.
My underlying issue is that I run
It's too complicated already, adding another option will mainly cause
more users to get confused. Also, I wouldn't know what to set it to for
C.
It's not that confusing. This is not a good reason for not implementing
something like 'completedelim'. A better reason would be that nobody
feels
Tested with vim70g
Given the following file contents:
BlahBlahImpl
BlahBlah.Type
If I try to perform the following on a new line at the end of the file
Blc-xc-n or p.Tc-n or p
The resulting text should be
BlahBlah.Type
However, if my 'completeopt' has menu and longest, or menuone and
I'll move it then. Please try it out with the next snapshot.
Appears to be working as expected.
thanks guys.
--
eric
Allowing duplicate entries is not that difficult. Perhaps adding an
item to the dictionary for this is sufficient. Let's use dup for
that.
Just tested this with the latest snapshot... works like a champ.
thanks for the quick turn around.
--
eric
On 4/21/06, Bram Moolenaar [EMAIL PROTECTED] wrote:
Eric Van wrote:
It appears that code completion is removing any entries that have
duplicate 'word' attributes.
For completion results not using the dictionary format I fully agree
that duplicates can safely be removed, but when using
13 matches
Mail list logo
