set nocompatible
set wildmenu
amenu test.etc\..1 :echo 1cr
emenu test.{press tab}
This presents no possible completion in vim, but correctly shows the
submenu in gvim.
It works fine for me. Could there be something else that matters?
I tried this with the terminal version on linux
that this is a bug, but I don't see what else could be
causing this.
Thanks for any help!
-Robert
I haven't delved very deep into the 'comments' options. In CSS files
it is set (by the ftplugin, I guess) to
comments=s1:/*,mb:*,ex:*/
and I get
/*
*
*
*/
With your settings, I see
Think I found a bug in the undo-branches behaviour, which cuts
undo-states. Try this out:
In a new buffer, insert `one' (or some other text), then in normal mode
type `g-g-u', now insert `two' and type `g-g-u' again (ignore quotes
`'). From now on it is not possible to get back the text states
Hi,
I have the following line in my source:
exec 'autocmd BufReadCmd '. pattern .' call '. rcmd .'(1,
expand(afile), , %)'
This fails if the filename contains % which is replaced with
expand('%'). I can't seem to escape the % at any point, can I? Wrapping
the exand(afile) in a escape(, %)
Thomas sent to vim-dev@vim.org
I have the following line in my source:
exec 'autocmd BufReadCmd '. pattern .' call '. rcmd .'(1,
expand(afile), , %)'
This fails if the filename contains % which is replaced with
expand('%'). I can't seem to escape the % at any point,
You can already do quite a lot if you define your own assert function or
command for this.
Ok, I now uploaded a plugin[1] that does this. Maybe somebody finds this
useful too.
The handling of script local functions is suboptimal though, which is
why I still think this should be integrated
Sanoblast wrote:
Looking back, now that Vim script has become much more complex, a bit
more type checking would be good.
A valid point. Mabye this could be done by an assert command/function
that checks its arguments or does nothing depending on an option (maybe
Peter Knaggs wrote:
On 12/10/06, A.J.Mechelynck [EMAIL PROTECTED] wrote:
I can't type fast enough
I noticed by looking in getchar.c at line 2695 that the timeout
p_ttm is a global,
which we can set (in milliseconds) using set ttimeoutlen value
(see option.c).
So e.g. to set it to three
Peter Knaggs wrote:
On 12/10/06, A.J.Mechelynck [EMAIL PROTECTED] wrote:
I can't type fast enough but (in Vim in konsole) the command
:exe 'norm A^[Oj^['
(where each of the two ^[ is typed as Ctrl-V Esc) results in a lone star
without the additional line below it.
Thomas wrote:
As mentioned in the documentation, automatic conversion only happens
between numbers and strings, not with Lists and Dictionaries. This is
to avoid mistakes, e.g., trying to concatenate a List and a String.
Something like
let l = [1,2,3]
exec Foo . l
could
Looking back, now that Vim script has become much more complex, a bit
more type checking would be good.
A valid point. Mabye this could be done by an assert command/function
that checks its arguments or does nothing depending on an option (maybe
'debug')/flag/variable?
Problem
On 12/10/06, A.J.Mechelynck [EMAIL PROTECTED] wrote:
I can't type fast enough
I noticed by looking in getchar.c at line 2695 that the timeout
p_ttm is a global,
which we can set (in milliseconds) using set ttimeoutlen value
(see option.c).
So e.g. to set it to three seconds, to give yourself
As mentioned in the documentation, automatic conversion only happens
between numbers and strings, not with Lists and Dictionaries. This is
to avoid mistakes, e.g., trying to concatenate a List and a String.
Something like
let l = [1,2,3]
exec Foo . l
could come handy though -- which
Something like
let l = [1,2,3]
exec Foo . l
could come in handy though -- which isn't possible now.
Although I just realized that lists seem to be passed on by reference
and this would create a new copy if the string presentation of a list
were a parseable list.
Which leads to another
let l = [1,2,3]
exec Foo . l
Which leads to another point: How do I pass a list by reference to Foo
Sorry, I somehow seem to have forgot what the original problem was --
which I should able to solve with the function() call() functions.
On Wed, 6 Dec 2006, Bill McCarthy apparently wrote:
I repeated this starting with a file name file:
gvim -u NONE -i NONE -N file
Here I see what appears to be a cosmetic bug. I am seeing:
i @ buffer
v @
I am using Vim 7.0.
Starting with
gvim -u NONE
On Wed 6-Dec-06 9:17am -0600, Alan G Isaac wrote:
On Wed, 6 Dec 2006, Bill McCarthy apparently wrote:
I repeated this starting with a file name file:
gvim -u NONE -i NONE -N file
Here I see what appears to be a cosmetic bug. I am seeing:
i @ buffer
v
Ingo Karkat wrote:
I found a bug in VIM 7.0's new tr() function. If the {src} string
contains exactly 80 characters, an additional junk character is
appended to the tr() result; this happens regardless of whether a
character translation has occurred or not.
How to reproduce:
vim -u NONE
I have run across a rather strange error in the syntax highlighting for
either vb.vim or html.vim. I'm unsure which is causing the problem.
Here are the circumstances under which this error occurs:
I am developing an HTA program. An HTA program (for those who do not
use Windows) is an HTML
if I had the following in a vim script:
call FooBar('xxx'
\ 'yyy')
then the last character ')' will be highlight as Error.
It seems that the '\' continued line are not recognized well.
My :version
VIM - Vi IMproved 7.0 (2006 May 7, compiled Sep 15 2006 16:06:30)
Included patches: 1-76
On Thu 30-Nov-06 7:30pm -0600, [EMAIL PROTECTED] wrote:
if I had the following in a vim script:
call FooBar('xxx'
\ 'yyy')
then the last character ')' will be highlight as Error.
It seems that the '\' continued line are not recognized well.
Yes, the continuation support is limited.
Viktor Kojouharov wrote:
It seems that searchpos doesn't match under the cursor, when the
cursor itself is on the first column. You can try the simple search
pos command below, and try searching for anything non-whitespace. Even
with the 'c' flag, it will still move the cursor to the first
explained some
months ago. When you move to a new location and very quickly begin some command
(like ^W, r, etc) then the command will be aborted because the au for
CursorHold runs and issues some command.
The one difference is that this new instance of the bug will happen at any time
(you can
In vimtutor, I see:
NOTE: A count between the operator d and the motion works similar to
using the motion without an operator.
However, it seems that 2dw works the same as d2w. I think the tutor
needs to be updated.
I'm using Vim 7.0.35.
Thanks!
-jj
--
Hello,
I'm pretty new to this mailing list and I hope I'm posting at the
right place. I just want to report a simple bug, easy to reproduce.
I have only tested it on Windows.
Open vim, write a single 1 characters line (filled with blanks for
example), and just maximize the window
On 11/2/06, [EMAIL PROTECTED]
[EMAIL PROTECTED] wrote:
Hello,
I'm pretty new to this mailing list and I hope I'm posting at the
right place. I just want to report a simple bug, easy to reproduce.
I have only tested it on Windows.
Open vim, write a single 1 characters line (filled
with an already corrected bug.
Anyway, even with the latest release installed, the version displayed
by windows is still 7.0.262.0.
Best regards,
Mike Meirsman
This message was sent using IMP, the Internet Messaging Program.
From: dotpanic dotpanic homelinux.org, Thu, November 02, 2006 6:11 am
I'm pretty new to this mailing list and I hope I'm posting at the
right place. I just want to report a simple bug, easy to reproduce.
I have only tested it on Windows.
Open vim, write a single 1 characters line
On 11/2/06, Steve Hall [EMAIL PROTECTED] wrote:
From: dotpanic dotpanic homelinux.org, Thu, November 02, 2006 6:11 am
I'm pretty new to this mailing list and I hope I'm posting at the
right place. I just want to report a simple bug, easy to reproduce.
I have only tested it on Windows
On Thu 2-Nov-06 5:11am -0600, [EMAIL PROTECTED] wrote:
I'm pretty new to this mailing list and I hope I'm posting at the
right place. I just want to report a simple bug, easy to reproduce.
I have only tested it on Windows.
Open vim, write a single 1 characters line (filled with blanks
to
have bothered you with an already corrected bug.
Anyway, even with the latest release installed, the version displayed by
windows is still 7.0.262.0.
Best regards,
Mike Meirsman
This message was sent using IMP, the Internet
Hi Bram and maintainers,
I encountered this bug when editing files:
1) Open a file, change something. The file is marked as modifed.
2) Use Ctrl-W,Ctrl-] to go to the definition of any symbol in a new
window. The newly opened file is unmodified, and the old one is still
modified.
3) Use Ctrl-T
Hi,
On 10/26/06, Yongwei Wu [EMAIL PROTECTED] wrote:
Hi Bram and maintainers,
I encountered this bug when editing files:
1) Open a file, change something. The file is marked as modifed.
2) Use Ctrl-W,Ctrl-] to go to the definition of any symbol in a new
window. The newly opened file
Hi Yegappan,
On 10/26/06, Yegappan Lakshmanan [EMAIL PROTECTED] wrote:
Hi,
On 10/26/06, Yongwei Wu [EMAIL PROTECTED] wrote:
Hi Bram and maintainers,
I encountered this bug when editing files:
1) Open a file, change something. The file is marked as modifed.
2) Use Ctrl-W,Ctrl-] to go
Hi list,
On 10/26/06, Yongwei Wu [EMAIL PROTECTED] wrote:
Hi Yegappan,
On 10/26/06, Yegappan Lakshmanan [EMAIL PROTECTED] wrote:
Hi,
On 10/26/06, Yongwei Wu [EMAIL PROTECTED] wrote:
Hi Bram and maintainers,
I encountered this bug when editing files:
1) Open a file, change
Yongwei Wu wrote:
Hi list,
On 10/26/06, Yongwei Wu [EMAIL PROTECTED] wrote:
Hi Yegappan,
On 10/26/06, Yegappan Lakshmanan [EMAIL PROTECTED] wrote:
Hi,
On 10/26/06, Yongwei Wu [EMAIL PROTECTED] wrote:
Hi Bram and maintainers,
I encountered this bug when editing files:
1) Open
Marius Roets wrote:
I believe I have found a bug in Vim 7.0.146, relating to mksession and
lcd. Here is a small example.
1) Open Vim
2) :e file1.txt
3) :tabe temp/file2.txt Any different directory
4) :lcd %:h
5) :mks test.vim
6) Close vim
7) Open vim
8) :source test.vim
9) The second
On 10/24/06, Bram Moolenaar [EMAIL PROTECTED] wrote:
I see the problem. I'll fix it.
Thanks Bram!
On 10/24/06, Bram Moolenaar [EMAIL PROTECTED] wrote:
I see the problem. I'll fix it.
This works correctly now after applying patch 7.0.147. Thanks again Bram.
Marius
Hari Krishna Dara wrote:
I am using :startinsert! from my plugin to put the user in insert mode,
but if the user doesn't type anything for 'updatetime' after this, no
CursorHoldI event is generated. I tried doing an explicit :doauto right
after :startinsert!, but Vim ignores it, probably
Hi everybody,
I believe I have found a bug in Vim 7.0.146, relating to mksession and
lcd. Here is a small example.
1) Open Vim
2) :e file1.txt
3) :tabe temp/file2.txt Any different directory
4) :lcd %:h
5) :mks test.vim
6) Close vim
7) Open vim
8) :source test.vim
9) The second tab is empty
On Mon, 23 Oct 2006 at 9:25pm, Bram Moolenaar wrote:
Hari Krishna Dara wrote:
I am using :startinsert! from my plugin to put the user in insert mode,
but if the user doesn't type anything for 'updatetime' after this, no
CursorHoldI event is generated. I tried doing an explicit :doauto
to consistently reproduce this bug,
but I can't.
- Christian
--
Microsoft is to software what McDonalds is to gourmet cooking.
Christian J. Robinson [EMAIL PROTECTED] http://infynity.spodzone.com/
PGP keys: 0x893B0EAF / 0xFB698360 http://infynity.spodzone.com/pgp
.
It shouldn't happen.
I've tried very hard to find a way to consistently reproduce this bug,
but I can't.
I'm afraid I can't guess what causes this, thus there is nothing I can
do.
--
From know your smileys:
:-{} Too much lipstick
/// Bram Moolenaar -- [EMAIL PROTECTED] -- http
I am using :startinsert! from my plugin to put the user in insert mode,
but if the user doesn't type anything for 'updatetime' after this, no
CursorHoldI event is generated. I tried doing an explicit :doauto right
after :startinsert!, but Vim ignores it, probably because the command
only
On Sun, 22 Oct 2006 at 5:25pm, Hari Krishna Dara wrote:
I am using :startinsert! from my plugin to put the user in insert mode,
but if the user doesn't type anything for 'updatetime' after this, no
CursorHoldI event is generated. I tried doing an explicit :doauto right
after :startinsert!,
Peter Hodge wrote:
When I have formatoptions=t, it makes comment lines wrap when they
shouldn't, and it also ignores whatever comment leader is defined in
'comments'. To reproduce:
:set formatoptions=roc
:set comments=b:%
:set textwidth=30
% type these lines of text
% as
Hello,
When I have formatoptions=t, it makes comment lines wrap when they shouldn't,
and it also ignores whatever comment leader is defined in 'comments'. To
reproduce:
:set formatoptions=roc
:set comments=b:%
:set textwidth=30
% type these lines of text
% as one line, and notice
(String[]
args) throws Something {
int i = 0;
}
}
This seems like a bug in the Java indent plugin.
--
Thanks,
Hari
__
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http
On Thu, Sep 28, 2006 at 01:27:26PM -0400, David Fishburn wrote:
Running this command:
echo inputdialog(Choose # of database type:\n1. None\n2. ASA\n3. MYSQL\n4.
SQLSERVER\n5. DB2,1,-1)
On Windows and Linux will correctly size the inputdialog box so that the
entire text is displayed.
Hari Krishna Dara wrote:
I need to create a doubly linked list and since this will cause problem
with lockvar, I will just comment the lock/unlockvar commands. I am
wondering if you have any plans to fix this issue. The lockvar is a
great way to prevent accidental changes (and it already
Giving up on 80.91.16.141.
This continues the conversion with the same subject. There
does appear to be a bug.
Please read on.
On Sun 8-Oct-06 10:42pm -0600, Igor Prischepoff wrote:
Hello, Bill.
Can you try _one more last time_ please ?
gvim - whatever you prefer for clean vim without
Thank you, Bill.
I can confirm same behaviour as you described with my vim.
Now it is up to Bram to decide if this is wrong or right.
---
[EMAIL PROTECTED]
Bram,
I need to create a doubly linked list and since this will cause problem
with lockvar, I will just comment the lock/unlockvar commands. I am
wondering if you have any plans to fix this issue. The lockvar is a
great way to prevent accidental changes (and it already helped me once)
so I would
I can reproduce the problem. Indeed looks like a bug. Removing
containedin=NOTHING solves it, while it should not change anything.
Sorry for finding a bug while you are so busy. But I am addicted to syntax
highlighting, it's such a wonderful feature.
regards,
Peter
--
hundred
Victor Hsieh wrote:
That is exactly what I think.
In most cast, http server and ftp server doesn't share the same PATH
(I mean, http,ftp://somewhere/PATH). Consider about this case, if I
tried to edit http://somewhere/~victor/ , and my vim opened
ftp://somewhere/~victor/ instead, it's not
Hari Krishna Dara wrote:
The :lockvar and :unlockvar commands fail when there is a recursive
references. E.g., try the below:
:let a = {}
:let b = {}
:let a.b = b
:let b:a = a
:lockvar! a
E743: variable nested too deep for (un)lock
You could of course end up with more complicated
Hari Krishna Dara wrote:
The ' and ' markers identify the start and end position of a selection
block and it seems to be not updated correctly in one particular case.
Say you start selection (visual mode or select mode) on one line, and
use ^E or ^Y to scroll the buffer such that the current
am pretty sure many
maps have been written using this assumption (I might have one or two as
well) and they will break with your patch.
If the bug has always been there, why not make it the expected behavior?
Do you see any problem with that?
Anyone can think of an alternate way to identify
have been written using this assumption (I might have one or two as
well) and they will break with your patch.
These maps would already break when autoselect is not enabled.
If the bug has always been there, why not make it the expected behavior?
Do you see any problem with that?
It may
On Sat, 7 Oct 2006 at 10:08pm, Bram Moolenaar wrote:
exec 'normal! '.(s:IsSelectMode() ? \C-G : '').\Escgv.
\ (s:IsSelectMode() ? \C-G : '')
It is strange that the normal command would not recognize the Esc in
select mode if I don't first switch to visual mode using
Hi,
With vim 7.0 and netrw.vim version 98, I've encountered a problem
when trying to vim http://somewhere/file.txt;. This patch will fix
the problem:
--- netrw.vim 2006-10-06 13:53:03.567758750 +0800
+++ netrw.vim.orig 2006-10-06 13:47:02.757209500 +0800
@@ -753,7 +753,7
Peter Hodge wrote:
Thanks for your help, I had another look and found out you need another syntax
command to reproduce it properly. Here is the revised bug report
Start vim using
vim -u NONE
insert the following test code (note that the 4th line must be indented).
array($foo)
is_array
in buffer?
// I still thinks it should be considered as a bug.
What action did you take on the first C-N? Since 'o' is
the longest common, no addition completion is done. If you
just want the 'o' type C-Y, if you want 'one' type C-N,
or if you want 'or' type C-P.
Why C-Y? See ':h complete_CTRL-Y
Victor Hsieh wrote:
With vim 7.0 and netrw.vim version 98, I've encountered a problem
when trying to vim http://somewhere/file.txt;. This patch will fix
the problem:
By the way, netrw is up to version 107a on my website. If you have a
problem
with netrw, its always best to get the latest
Victor Hsieh wrote:
On 10/6/06, Charles E Campbell Jr [EMAIL PROTECTED] wrote:
Victor Hsieh wrote:
With vim 7.0 and netrw.vim version 98, I've encountered a problem
when trying to vim http://somewhere/file.txt;. This patch will fix
the problem:
This would silently let users overwrite
Victor Hsieh wrote:
On 10/6/06, Charles E Campbell Jr [EMAIL PROTECTED] wrote:
Victor Hsieh wrote:
With vim 7.0 and netrw.vim version 98, I've encountered a problem
when trying to vim http://somewhere/file.txt;. This patch will fix
the problem:
This would silently let users overwrite their
Charles E Campbell Jr wrote:
Victor Hsieh wrote:
[...]
I know. But I just want to read the html code or so with my favoriate
editor ;) I used to do it with vim6. Actually in most case,
connecting to ftp://somewhere (when open http://somewhere) is not
gonna work.
Not if you don't have the
A.J.Mechelynck wrote:
Charles E Campbell Jr wrote:
Victor Hsieh wrote:
[...]
I know. But I just want to read the html code or so with my favoriate
editor ;) I used to do it with vim6. Actually in most case,
connecting to ftp://somewhere (when open http://somewhere) is not
gonna work.
Not
Geoff Reedy wrote:
When calling getwinvar or gettabwinvar with an empty string as the
last argument it is supposed to return a dictionary of the values
defined in the specified window. This does not appear to be
documented in the help files but it is documented in a comment within
Peter Hodge wrote:
Thanks for your help, I had another look and found out you need another syntax
command to reproduce it properly. Here is the revised bug report
Start vim using
vim -u NONE
insert the following test code (note that the 4th line must be indented).
array($foo
That is exactly what I think.
In most cast, http server and ftp server doesn't share the same PATH
(I mean, http,ftp://somewhere/PATH). Consider about this case, if I
tried to edit http://somewhere/~victor/ , and my vim opened
ftp://somewhere/~victor/ instead, it's not gonna work at all. There
Hi,
Hari Krishna Dara wrote:
The help on complete() gives an example as a usage pattern which seems
to be very useful, but it doesn't work. Here is a slightly modified
example to avoid breaking the lines in email transmission:
inoremap expr F5 ListWeeks()
func! ListWeeks()
call
On Fri, 6 Oct 2006 at 8:19am, Jürgen Krämer wrote:
Hi,
Hari Krishna Dara wrote:
The help on complete() gives an example as a usage pattern which seems
to be very useful, but it doesn't work. Here is a slightly modified
example to avoid breaking the lines in email transmission:
Hari Krishna Dara wrote:
On Fri, 6 Oct 2006 at 8:19am, Jürgen Krämer wrote:
Hi,
Hari Krishna Dara wrote:
The help on complete() gives an example as a usage pattern which seems
to be very useful, but it doesn't work. Here is a slightly modified
example to avoid breaking the lines in email
On Fri, 6 Oct 2006 at 7:48pm, A.J.Mechelynck wrote:
Hari Krishna Dara wrote:
On Fri, 6 Oct 2006 at 8:19am, Jürgen Krämer wrote:
Hi,
Hari Krishna Dara wrote:
The help on complete() gives an example as a usage pattern which seems
to be very useful, but it doesn't work. Here is a
Hari Krishna Dara wrote:
[...]
Interesting... the 7.0.99 version that I have doesn't have anything that
you are pointing to, and the example clearly used map expr. The
documentation was probably updated later on? What patch version do you
have? Or may be that I updated the vim binaries, not
On Fri 6-Oct-06 6:46pm -0600, A.J.Mechelynck wrote:
Hari Krishna Dara wrote:
[...]
Interesting... the 7.0.99 version that I have doesn't have anything that
you are pointing to, and the example clearly used map expr. The
documentation was probably updated later on? What patch version do you
Bill McCarthy wrote:
On Fri 6-Oct-06 6:46pm -0600, A.J.Mechelynck wrote:
Hari Krishna Dara wrote:
[...]
Interesting... the 7.0.99 version that I have doesn't have anything that
you are pointing to, and the example clearly used map expr. The
documentation was probably updated later on? What
The ' and ' markers identify the start and end position of a selection
block and it seems to be not updated correctly in one particular case.
Say you start selection (visual mode or select mode) on one line, and
use ^E or ^Y to scroll the buffer such that the current line goes past
the window
On Fri 6-Oct-06 8:36pm -0600, you wrote:
Bill McCarthy wrote:
On Fri 6-Oct-06 6:46pm -0600, A.J.Mechelynck wrote:
Hari Krishna Dara wrote:
[...]
Interesting... the 7.0.99 version that I have doesn't have anything that
you are pointing to, and the example clearly used map expr. The
The :lockvar and :unlockvar commands fail when there is a recursive
references. E.g., try the below:
:let a = {}
:let b = {}
:let a.b = b
:let b:a = a
:lockvar! a
E743: variable nested too deep for (un)lock
You could of course end up with more complicated indirect recursive
references as well,
Hello,
I have discovered that it is possible for a syntax region to overlap a syntax
keyword, even though the region is not contained in the keyword. Take the
following code example and apply the syntax commands below:
TEST CODE:
(is_array($foo))
( is_array($foo) )
SYNTAX
Peter Hodge wrote:
Hello,
I have discovered that it is possible for a syntax region to overlap a syntax
keyword, even though the region is not contained in the keyword. Take the
following code example and apply the syntax commands below:
TEST CODE:
(is_array($foo))
( is_array($foo)
On Wed 4-Oct-06 10:16pm -0600, Igor Prischepoff wrote:
Hi, i think i have found a bug in vim 7.0
Patch level 1-109.
Windows version +perl +python (i don't think this matters in this case)
here is how to reproduce:
gvim -u NONE -U NONE
:set complete-=tdon't want complete from
Igor Prischepoff wrote:
Hi, i think i have found a bug in vim 7.0
Patch level 1-109.
Windows version +perl +python (i don't think this matters in this case)
here is how to reproduce:
gvim -u NONE -U NONE
:set complete-=t don't want complete from tags file - it's not
important
Dnia czwartek, 5 października 2006 05:16, Igor Prischepoff napisał:
Hi, i think i have found a bug in vim 7.0
Patch level 1-109.
Windows version +perl +python (i don't think this matters in this case)
here is how to reproduce:
gvim -u NONE -U NONE
:set complete-=t don't want
command to reproduce it properly. Here is the revised bug report
Start vim using
vim -u NONE
insert the following test code (note that the 4th line must be indented).
array($foo)
is_array $foo
is_array($foo)
is_array($foo)
Apply the following syntax commands:
syn
BTW, using
gvim -u NONE -U NONE
is both redundant (in the case of -U NONE), dangerous (since
default settings may truncate your viminfo on exit), and put
you in vi compatible mode. Better is:
gvim -u NONE -i NONE -N
I wouldn't think the -i option is necessary, because
On 2006-10-06, Peter Hodge [EMAIL PROTECTED] wrote:
BTW, using
gvim -u NONE -U NONE
is both redundant (in the case of -U NONE), dangerous (since
default settings may truncate your viminfo on exit), and put
you in vi compatible mode. Better is:
gvim -u NONE -i NONE -N
When calling getwinvar or gettabwinvar with an empty string as the
last argument it is supposed to return a dictionary of the values
defined in the specified window. This does not appear to be
documented in the help files but it is documented in a comment within
getwinvar in eval.c. The
;
two_and_three : byte;
three : byte;
// may be this is a word?
one:=three;
// or next one is a a word?
one:=two_and_three;
oC-N:=tC-n
// completion in second C-N still not working here...
// so there is no word? not 'one:=t*' or 't*' words in buffer?
// I still thinks it should be considered as a bug
The help on complete() gives an example as a usage pattern which seems
to be very useful, but it doesn't work. Here is a slightly modified
example to avoid breaking the lines in email transmission:
inoremap expr F5 ListWeeks()
func! ListWeeks()
call complete(col('.'), ['Sun', 'Mon', 'Tue',
Hi, i think i have found a bug in vim 7.0
Patch level 1-109.
Windows version +perl +python (i don't think this matters in this case)
here is how to reproduce:
gvim -u NONE -U NONE
:set complete-=tdon't want complete from tags file - it's not
important, just to switch off message
:set
is called. In GUI
Vim, I correctly see 27 returned by getchar(0), but in Terminal Vim, getchar(0)
is returning '0', even though ESC has been pressed. Is this a bug in Vim?
regards,
Peter
Here, it depends of the number of keypresses:
In gvim, :sleep 10 | echo getchar(0) followed by Esc returns 27
. In GUI Vim, I correctly see 27 returned by getchar(0), but in
Terminal Vim, getchar(0) is returning '0', even though ESC has been
pressed. Is this a bug in Vim?
It's because Esc is the start of a key sequence and it's incomplete.
Vim can't know you pressed the Esc key instead of having
correctly see 27 returned by getchar(0), but in Terminal Vim, getchar(0)
is returning '0', even though ESC has been pressed. Is this a bug in Vim?
regards,
Peter
On Yahoo!7
Answers: 25 million answers and counting. Learn
Ilya Bobir wrote:
I've found bug in highlighting when matchparen is used. Not sure it is
because of a matchparen thought.
Test case
=
gvim
i{}EschO
Now I can see first line with one character background been highlighted
and an insert cursor over it and '{}' on a second
Running this command:
echo inputdialog(Choose # of database type:\n1. None\n2. ASA\n3. MYSQL\n4.
SQLSERVER\n5. DB2,1,-1)
On Windows and Linux will correctly size the inputdialog box so that the
entire text is displayed.
On the Mac platform the inputdialog does not size appropriately and will
Hello.
I've found bug in highlighting when matchparen is used. Not sure it is
because of a matchparen thought.
Test case
=
gvim
i{}EschO
Now I can see first line with one character background been highlighted
and an insert cursor over it and '{}' on a second line, both highlighted
101 - 200 of 418 matches
Mail list logo
