Hi all,
After reading
http://www.run.montefiore.ulg.ac.be/~martin/resources/kung-f00.html
I now use anonymous arrays in C. This is an exemple of use:
result = ldap_search_s( ld
, dc=u-strasbg,dc=fr
, LDAP_SCOPE_ONELEVEL
, NULL
, (char *[]){
Marc Chantreux wrote:
After reading
http://www.run.montefiore.ulg.ac.be/~martin/resources/kung-f00.html
I now use anonymous arrays in C. This is an exemple of use:
result = ldap_search_s( ld
, dc=u-strasbg,dc=fr
, LDAP_SCOPE_ONELEVEL
, NULL
In
*options.txt* For Vim version 7.1. Last change: 2007 May 11
under 'browsedir', at line 1151, there is:
{not in Vi} {only for Motif and Win32 GUI}
Actually, this option is functional in my GTK2/Gnome GUI.
Best regards,
Tony.
--
The day after tomorrow is the
Vim on three MS-Windows XP machines coming from
different vendors and everywhere was that bug. Looks like classic
example of:
1. MS-Windows is always right
2. If MS-Windows is wrong see 1.
m.
--
The world really isn't any worse.
It's just that the news coverage is so much better.
Hi All,
I see the following bug:
1. Open Vim, and vertically split into two windows.
2. File name complete something with very long file names (longer
than the width of the window you're typing into).
The screen is hodge podge. There are uncleared pieces of the
completion menu
Micah Cowan wrote:
Following description lifted from bug filed at
https://bugs.launchpad.net/ubuntu/+source/vim/+bug/78960
[EMAIL PROTECTED]:~$ rm .viminfo
[EMAIL PROTECTED]:~$ ln -s /dev/null .viminfo
[EMAIL PROTECTED]:~$ ls -l .viminfo
lrwxrwxrwx 1 sa sa 9 2007-01-12 17:16 .viminfo
Bram Moolenaar wrote:
Micah Cowan wrote:
Following description lifted from bug filed at
https://bugs.launchpad.net/ubuntu/+source/vim/+bug/78960
[EMAIL PROTECTED]:~$ rm .viminfo
[EMAIL PROTECTED]:~$ ln -s /dev/null .viminfo
[EMAIL PROTECTED]:~$ ls -l .viminfo
lrwxrwxrwx 1 sa sa 9 2007
Micah Cowan wrote:
Bram Moolenaar wrote:
[...]
The solution is simple: Don't create a link in place of the .viminfo
file. And certainly not to /dev/null.
Background info: When Vim finds an existing .viminfo file, it writes the
new info into a temp file (since it's still reading from the
A.J.Mechelynck wrote:
Micah Cowan wrote:
Bram Moolenaar wrote:
[...]
The solution is simple: Don't create a link in place of the .viminfo
file. And certainly not to /dev/null.
Background info: When Vim finds an existing .viminfo file, it writes the
new info into a temp file (since it's
Micah Cowan wrote:
A.J.Mechelynck wrote:
Micah Cowan wrote:
Bram Moolenaar wrote:
[...]
The solution is simple: Don't create a link in place of the .viminfo
file. And certainly not to /dev/null.
Background info: When Vim finds an existing .viminfo file, it writes the
new info into a temp
A.J.Mechelynck wrote:
Micah Cowan wrote:
A.J.Mechelynck wrote:
Micah Cowan wrote:
Bram Moolenaar wrote:
[...]
The solution is simple: Don't create a link in place of the .viminfo
file. And certainly not to /dev/null.
Background info: When Vim finds an existing .viminfo file, it
writes
Robert Lee wrote:
A.J.Mechelynck wrote:
Micah Cowan wrote:
A.J.Mechelynck wrote:
Micah Cowan wrote:
Bram Moolenaar wrote:
[...]
The solution is simple: Don't create a link in place of the .viminfo
file. And certainly not to /dev/null.
Background info: When Vim finds an existing .viminfo
Hello,
Vim 7.1b on Windows XP doesn't properly recognizes words. It does not
count Polish diacritics in, so each one is treated as separate word.
This is serious bug and with taking into account that Windows users can
have problems with getting patched versions it is IMO showstopper.
In its
Mikolaj Machowski wrote:
Vim 7.1b on Windows XP doesn't properly recognizes words. It does not
count Polish diacritics in, so each one is treated as separate word.
This is serious bug and with taking into account that Windows users can
have problems with getting patched versions
What is 'iskeyword' set to and where was it set?
:15verbose se isk?
returns
n:\mikolaj\pf\vim\vim71b\vimrc_example.vim
m.
INFERNAL: From Paris to Berlin
Potężna dawka hitów! CD+DVD już w sklepach!
Mikolaj Machowski wrote:
Vim 7.1b on Windows XP doesn't properly recognizes words. It does not
count Polish diacritics in, so each one is treated as separate word.
This is serious bug and with taking into account that Windows users can
have problems with getting patched versions
Following description lifted from bug filed at
https://bugs.launchpad.net/ubuntu/+source/vim/+bug/78960
[EMAIL PROTECTED]:~$ rm .viminfo
[EMAIL PROTECTED]:~$ ln -s /dev/null .viminfo
[EMAIL PROTECTED]:~$ ls -l .viminfo
lrwxrwxrwx 1 sa sa 9 2007-01-12 17:16 .viminfo - /dev/null
[EMAIL PROTECTED
Micah Cowan wrote:
Following description lifted from bug filed at
https://bugs.launchpad.net/ubuntu/+source/vim/+bug/78960
[EMAIL PROTECTED]:~$ rm .viminfo
[EMAIL PROTECTED]:~$ ln -s /dev/null .viminfo
[EMAIL PROTECTED]:~$ ls -l .viminfo
lrwxrwxrwx 1 sa sa 9 2007-01-12 17:16 .viminfo - /dev
Micah Cowan [EMAIL PROTECTED] writes:
Is there a good reason not to simply follow symlinks when they are
encountered, as this user obviously expected?
If it did follow the symlink to /dev/null, and tried to read from that
device, it would fail. You can't (or at least, shouldn't) read from
Taylor Venable wrote:
[...]
If it did follow the symlink to /dev/null, and tried to read from that
device, it would fail. You can't (or at least, shouldn't) read from
/dev/null because it's a sink, not a source. What kind of behavior
would you expect, trying to read from /dev/null?
[...]
Tony Mechelynck wrote:
One word under :help 'ttymouse' was obviously forgotten when that
option got more possible settings. See suggested patch, attached.
To avoid it being forgotten again, I'll simply remove the count.
--
From know your smileys:
:-{} Too much lipstick
/// Bram
One word under :help 'ttymouse' was obviously forgotten when that option got
more possible settings. See suggested patch, attached.
Best regards,
Tony.
--
You should never wear your best trousers when you go out to fight for
freedom and liberty.
-- Henrik Ibsen
***
GVim runs into an endless loop if I do the following:
clean startup
:new at least two windows
:windo throw foo
Error detected while processing :
E605: Exception not caught: foo
E605: Exception not caught: foo
E605: Exception not caught: foo
E605:
Andy Wokula wrote:
GVim runs into an endless loop if I do the following:
clean startup
:new at least two windows
:windo throw foo
Error detected while processing :
E605: Exception not caught: foo
E605: Exception not caught: foo
E605:
There seems to be a bug in java indentation. The maintainer (Cc'ed) is said
to be resigned, so I'm writing here. It is sort of special situation. Take
a look at the println() in the following:
public class Bug {
public static void main(String args[]) {
Foo.bar(new Baz
Bram Moolenaar schrieb:
Andy Wokula wrote:
GVim runs into an endless loop if I do the following:
clean startup
:new at least two windows
:windo throw foo
Error detected while processing :
E605: Exception not caught: foo
E605: Exception not caught:
Ali Polatel wrote:
Hi everyone,
I was playing around with langmap and found out there is a problem with
characters
'ı'[1] - 0131;LATIN SMALL LETTER DOTLESS I - and
'Ä'[2] - 011F;LATIN SMALL LETTER G WITH BREVE
The Turkish keyboard looks like this[3]Â for those who don't know about
Bram Moolenaar wrote:
[...]
I guess most Turkish characters are in latin1, only the ones that are
not won't work with 'langmap'.
small undotted i, g-breve, s-cedilla, ...
Best regards,
Tony.
--
The primary requisite for any new tax law is for it to exempt enough
voters to win the next
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi everyone,
I was playing around with langmap and found out there is a problem with
characters
'ı'[1] - 0131;LATIN SMALL LETTER DOTLESS I - and
'ğ'[2] - 011F;LATIN SMALL LETTER G WITH BREVE
The Turkish keyboard looks like this[3] for those who
On 4/23/07, A.J.Mechelynck [EMAIL PROTECTED] wrote:
Виктор Кожухаров wrote:
Hello,
I think there might be a bug with vim7, and they way it handles the
arrow keys in a terminal.
The problem is, that in insert mode, the arrow keys don't navigate
through the text, but output letters
On 4/23/07, A.J.Mechelynck [EMAIL PROTECTED] wrote:
Виктор Кожухаров wrote:
Hello,
I think there might be a bug with vim7, and they way it handles the
arrow keys in a terminal.
The problem is, that in insert mode, the arrow keys don't navigate
through the text, but output letters
Viktor Kojouharov wrote:
It turned out that these mappings broke the arrow keys in the terminal:
inoremap expr Esc pumvisible()?\C-E:\Esc
inoremap expr CR pumvisible()?\C-Y:\CR
inoremap expr Down pumvisible()?\C-N:\Down
inoremap expr Up pumvisible()?\C-P:\Up
inoremap expr
a vimtip btw.
But something happens, and none of the remapped keys (besides the Esc)
work correctly if the pum is not visible. Perhaps it might still be a
bug in vim7, but at least its explained now why vim6 works correctly.
nikolai
--
Виктор Кожухаров /Viktor Kojouharov/
signature.asc
Description
Hello,
I think there might be a bug with vim7, and they way it handles the
arrow keys in a terminal.
The problem is, that in insert mode, the arrow keys don't navigate
through the text, but output letters. For example, pressing Up in
insert mode would do the equivalent of OAEsc in normal mode
Виктор Кожухаров wrote:
Hello,
I think there might be a bug with vim7, and they way it handles the
arrow keys in a terminal.
The problem is, that in insert mode, the arrow keys don't navigate
through the text, but output letters. For example, pressing Up in
insert mode would do the equivalent
On Tue, 10 Apr 2007, Jon Combe wrote:
The following snippet of code, when saved with a .pl file extension
breaks the colour coding in Vim
@split = split ( / |-|\/|\/ , $surname , -1 );
This sometimes annoys me, too. To work around it, use the 'm' operator
specifically, thus:
@split =
The following snippet of code, when saved with a .pl file extension
breaks the colour coding in Vim
#!/usr/bin/perl -w
my $surname = ABC-DEF GHI;
@split = split ( / |-|\/|\/ , $surname , -1 );
foreach ( @split )
{
print $_\n;
}
The lines after the
Jon Combe wrote:
The following snippet of code, when saved with a .pl file extension
breaks the colour coding in Vim
#!/usr/bin/perl -w
my $surname = ABC-DEF GHI;
@split = split ( / |-|\/|\/ , $surname , -1 );
foreach ( @split )
{
print $_\n;
}
Jürgen Krämer wrote:
[...]
the FileType event is only fired once with the exact filetype you
specified in your set command, so you must additionally define the
following autocommand:
autocmd FileType c.doxygen setlocal cindent number cursorline
Regards,
Jürgen
If that is true, doesn't it
Hi,
A.J.Mechelynck wrote:
Jürgen Krämer wrote:
[...]
the FileType event is only fired once with the exact filetype you
specified in your set command, so you must additionally define the
following autocommand:
autocmd FileType c.doxygen setlocal cindent number cursorline
If that is
Jürgen Krämer wrote:
[...]
Nice idea (esp. the recursion), but alas it's not that simple, because
the pattern only accepts wildcards (not regular expressions) and if it
did, the subpatterns would probably not be recognized in the command.
But your command gave me an idea -- the following should
On 3/26/07, Michael Wookey [EMAIL PROTECTED] wrote:
I have the following in my .vimrc:
filetype plugin indent on
autocmd FileType c,h,cpp,hpp,cs setlocal cindent number cursorline
If I have a new buffer and set the filetype as follows, everything works
just fine:
:set filetype=c
I have the following in my .vimrc:
filetype plugin indent on
autocmd FileType c,h,cpp,hpp,cs setlocal cindent number
cursorline
If I have a new buffer and set the filetype as follows, everything
works
just fine:
:set filetype=c
However, if I have a new buffer
Hi,
Michael Wookey schrieb:
I have the following in my .vimrc:
filetype plugin indent on
autocmd FileType c,h,cpp,hpp,cs setlocal cindent number cursorline
If I have a new buffer and set the filetype as follows, everything works
just fine:
:set filetype=c
However, if
Hi,
When I use the following command (for demonstration purposes):
au CursorMoved * norm! zz
When I now press s-c-left or s-c-right, zz get inserted in the buffer.
These cursor key seem to be set by :behave mswin.
In summary:
:au CursorMoved * norm! zz
:behave mswin
Press s-c-left or
Thomas wrote:
Hi,
When I use the following command (for demonstration purposes):
au CursorMoved * norm! zz
When I now press s-c-left or s-c-right, zz get inserted in the buffer.
These cursor key seem to be set by :behave mswin.
In summary:
:au CursorMoved * norm! zz
:behave mswin
Press
Thomas wrote:
When I use the following command (for demonstration purposes):
au CursorMoved * norm! zz
When I now press s-c-left or s-c-right, zz get inserted in the buffer.
These cursor key seem to be set by :behave mswin.
In summary:
:au CursorMoved * norm! zz
:behave mswin
When in Select mode you are still in sort-of Normal mode. Your
autocommand will have to take care of mode stuff by itself. You can use
CTRL-\ CTRN-N to make sure you are in Normal mode.
Okay, I now wrapped the norm! commands in a function and check via
mode() if we are in select mode and
Gombault Damien wrote:
I noticed a display bug with the completion menu.
If accented characters appears in the completion menu, some others characters
from the edited file appears too in the menu ! It's quite difficult to
explain so I've made some screenshots. You can also notice
'. On the screenshot,
the file was wrotten in 'latin1' charset.
After some tests, I noticed this bugs seems only appears when 'encoding'
and 'fileencoding' are not the same. Finally, I could get this bug on win32 :
I set 'encoding' to 'utf-8' then open some 'latin-1' files.
I wrote two very simple C++ file
your 'encoding' to 'utf-8'.
Edit 3.cpp file.
Type, before the comment, CTRL-x CTRL-i for 'include' completion. Words
from 2.cpp are displayed but you have a display bug with the completion
menu because words are not converted to the current encoding.
Regards.
--
Gombault Damien | Powered
' is also set to 'utf-8'. On the screenshot,
the file was wrotten in 'latin1' charset.
After some tests, I noticed this bugs seems only appears when 'encoding'
and 'fileencoding' are not the same. Finally, I could get this bug on win32 :
I set 'encoding' to 'utf-8' then open some 'latin-1
Bram Moolenaar wrote:
Tony Mechelynck wrote:
In languages using accented letters, the Vim spell checker doesn't recognise
HTML entities (in HTML text): for example, the letters outside of the ...;
entities are highlighted as spellBad (after :set spell spelllang=fr) in
the following French
François Pinard wrote:
[Bram Moolenar]
Tony Mechelynck wrote:
In languages using accented letters, the Vim spell checker doesn't
recognise HTML entities (in HTML text) [...]
You'll have to check if using and ; in the middle of a word is
causing trouble. Adding them to word characters
In languages using accented letters, the Vim spell checker doesn't recognise
HTML entities (in HTML text): for example, the letters outside of the ...;
entities are highlighted as spellBad (after :set spell spelllang=fr) in
the following French words:
ougrave; meaning:
Tony Mechelynck wrote:
In languages using accented letters, the Vim spell checker doesn't recognise
HTML entities (in HTML text): for example, the letters outside of the ...;
entities are highlighted as spellBad (after :set spell spelllang=fr) in
the following French words:
ougrave;
[Bram Moolenar]
Tony Mechelynck wrote:
In languages using accented letters, the Vim spell checker doesn't
recognise HTML entities (in HTML text) [...]
You'll have to check if using and ; in the middle of a word is
causing trouble. Adding them to word characters will probably create
Reproducible: Always
Steps to reproduce:
1. Place an uppercase mark A in file aa.c;
2. use :echo line('A), it will display the correct line number;
3. change to another file, execute :echo line('A), it will display the line
number too.
Actual result:
See above.
Expected result:
In a file
Easwy Yang wrote:
Reproducible: Always
Steps to reproduce:
1. Place an uppercase mark A in file aa.c;
2. use :echo line('A), it will display the correct line number;
3. change to another file, execute :echo line('A), it will display the line
number too.
Actual result:
See above.
Sorry for sending to Bram's private mail address.
Here's my original mail.
-- Forwarded message --
From: Easwy Yang [EMAIL PROTECTED]
Date: 2007-3-21 上午9:19
Subject: Re: BUG? line('A) always returns line number in all the files
To: Bram Moolenaar [EMAIL PROTECTED]
Yes
Opening a vimball in Vim sets 'nomodifiable' not only locally but also
globally: henceforward, all new [No Name] buffers opened in the same session
will be created with 'nomodifiable' set.
Workaround: Use :set modifiable in the first [No Name] buffer created after
opening a vimball.
Fix:
A.J.Mechelynck wrote:
Opening a vimball in Vim sets 'nomodifiable' not only locally but also
globally: henceforward, all new [No Name] buffers opened in the same
session will be created with 'nomodifiable' set.
Workaround: Use :set modifiable in the first [No Name] buffer created
after
Quoting A.J.Mechelynck [EMAIL PROTECTED]:
Opening a vimball in Vim sets 'nomodifiable' not only locally but also
globally: henceforward, all new [No Name] buffers opened in the same session
will be created with 'nomodifiable' set.
Workaround: Use :set modifiable in the first [No Name] buffer
Bram Moolenaar wrote:
Tony Mechelynck wrote:
Ctrl-W ] (or :wincmd ] ) splits the window to show the definition of the tag
under the cursor, but prefixing it with :tab doesn't open a new tab:
Reproducible: Always
Steps to reproduce:
1. Place the cursor on a tag (e.g. on an identifier in a
Tony Mechelynck wrote:
Ctrl-W ] (or :wincmd ] ) splits the window to show the definition of the
tag
under the cursor, but prefixing it with :tab doesn't open a new tab:
Reproducible: Always
Steps to reproduce:
1. Place the cursor on a tag (e.g. on an identifier in a program for
Ctrl-W ] (or :wincmd ] ) splits the window to show the definition of the tag
under the cursor, but prefixing it with :tab doesn't open a new tab:
Reproducible: Always
Steps to reproduce:
1. Place the cursor on a tag (e.g. on an identifier in a program for which
ctags has been run).
2. Type
What gets displayed?
Does this happen on gVim as well?
Do Chinese characters appear correctly in the console window when using
other programs?
-Original Message-
From: Mike Li [mailto:[EMAIL PROTECTED]
Sent: Monday, March 05, 2007 10:04 PM
To: vim-dev@vim.org
Subject: Re: bug: gvim
using
other programs?
-Original Message-
From: Mike Li [mailto:[EMAIL PROTECTED]
Sent: Monday, March 05, 2007 10:04 PM
To: vim-dev@vim.org
Subject: Re: bug: gvim 7.0.205 on xp can not display ucs-2
console vim 7.0 (patches 1-205), built with the mingw compiler under
cygwin (gcc -mno-cygwin
one point of clarification: the correcly functioning fedora console
vim binaries were run under x11 (rxvt-unicode) with appropriate
truetype fonts.
-x
On 3/5/07, Mike Li [EMAIL PROTECTED] wrote:
gvim 7.0 (patches 1-205) under windows xp, built with the mingw
compiler under cygwin (gcc
one more update: if i add the following two lines to my _vimrc, then
the ucs-2le text file works:
set fileencodings+=ucs-2le
set encoding=utf-8
note that both need to be set before i edit the file. once i load the
file, setting them no longer helps.
-x
On 3/6/07, Mike Li [EMAIL PROTECTED]
Mike Li wrote:
one more update: if i add the following two lines to my _vimrc, then
the ucs-2le text file works:
set fileencodings+=ucs-2le
set encoding=utf-8
note that both need to be set before i edit the file. once i load the
file, setting them no longer helps.
-x
Of course:
- Vim needs
: Mike Li [mailto:[EMAIL PROTECTED]
Sent: Tuesday, March 06, 2007 1:53 AM
To: Doug Cook
Cc: vim-dev@vim.org
Subject: Re: bug: gvim 7.0.205 on xp can not display ucs-2
for big-endian, the following is displayed:
[EMAIL PROTECTED]@
for little-endian, the following is displayed:
8l^M^@
^@
^@ and ^M
much thanks to Doug and A.J. -- i now see that it wasn't a bug at all.
sorry for the noise.
-x
On 3/6/07, Doug Cook [EMAIL PROTECTED] wrote:
Using gVim, if I load your file normally, I do get ASCII instead of Unicode.
But if I then type:
:e ++enc=ucs-2
it appears to work. I don't have
gvim 7.0 (patches 1-205) under windows xp, built with the mingw
compiler under cygwin (gcc -mno-cygwin), can not display ucs-2 text
files. see below for the xxd-dump of an ucs-2 text file containing a
single chinese character (U+6c38):
000: 6c 38 00 0d 00 0a
console vim 7.0 (patches 1-205), built with the mingw compiler under
cygwin (gcc -mno-cygwin), as well as the console vim 7.0.122 binary
distributed with cygwin have the same problem as the gvim binaries
under windows xp.
-x
On 3/5/07, Mike Li [EMAIL PROTECTED] wrote:
gvim 7.0 (patches 1-205)
2007/3/2, A.J.Mechelynck [EMAIL PROTECTED]:
Mapping seems to be buggy with some characters.
For instance:
:imap ' foo
does not work (the apostrophe is U+2019).
What is 'encoding' set to? Using multibyte characters (e.g. in a mapping) will
only work if 'encoding' (which defines how
+2200), works.
Since I can map some multibyte characters, there is in my opinion no
issue with the encoding.
The question is: why is it possible to map U+2200 but not U+2019?
Regards,
thomas
Hm. It just might be a bug, but Bram would be better able than me to check this.
I can map Char-0x2019
Bram Moolenaar wrote:
[...]
How can you tell if the mapping works or not?
You can see what a key actually produces with CTRL-V key . So when
you type
:imap CTRL-V key foo
Where CTRL-V is one key and key is the mapped key.
Does the mapping still not work?
When I type
:map!
Die von Ihnen genutzte eMail-Adresse ([EMAIL PROTECTED]) existiert nicht oder
existiert nicht mehr.
Michael Schaap wrote:
When editing a read-only file, :confirm w only works the first time
you use it in a session. The second time you try to use it, you simply
get an error message, as if you didn't use :confirm.
The same problem occurs when using :set confirm.
To recreate:
$ echo
G'day folks,
In the following sample string:
{pre{contained}post}
the right brace after contained is not highlighted when using these
syntax commands.
syn region foo1 matchgroup=foo2 start={ end=} contains=foo3
syn region foo3 start={ end=} transparent contained
hi def link foo1 Constant
hi
Tony Mechelynck wrote:
When cycling through matches using :cnext, if there are several matches in
a
single long line, the line is only shortened the first time (but _not_ the
2nd, 3rd, etc.,) to avoid a Hit-Enter prompt.
Reproducible: every time.
Steps to reproduce:
1. :set wrap
Doug Kearns wrote:
In the following sample string:
{pre{contained}post}
the right brace after contained is not highlighted when using these
syntax commands.
syn region foo1 matchgroup=foo2 start={ end=} contains=foo3
syn region foo3 start={ end=} transparent contained
hi def
When cycling through matches using :cnext, if there are several matches in a
single long line, the line is only shortened the first time (but _not_ the
2nd, 3rd, etc.,) to avoid a Hit-Enter prompt.
Reproducible: every time.
Steps to reproduce:
1. :set wrap I'm not sure this is necessary
2.
after typing Space,
(but was
expanded with Tab or Esc.) Actually it works properly only
if I use iab
NK Newton-Kaskade. This phenomena only occurs when I use gvim7
but neither
in a terminal vim7 nor in any (gui or non-gui) prior version of
vim (6.4.7).
Is this a bug in gvim7?
I cannot
Hi,
we have a bug report that keybindings with Alt does not work in gvim if
the X input method is enabled:
Testcase
:set wak=no # disable keybindings for the menu
:tabnew
:map M-1 1gt
:map M-2 2gt
This should allow you to switch with Alt-1 and Alt-2 between tabs
Matthias Koenig wrote:
we have a bug report that keybindings with Alt does not work in gvim if
the X input method is enabled:
Testcase
:set wak=no # disable keybindings for the menu
:tabnew
:map M-1 1gt
:map M-2 2gt
This should allow you to switch with Alt-1
will install a clean version here and try to determine if it is
really a vim bug.
I assume you are using GTK then. If you use GTK + Gnome then try
recompiling Vim without Gnome. The Gnome libraries introduce some
problems.
The window manager may do things that Vim can't handle. Whether
version here and try to determine if it is
really a vim bug.
Regards, Vaclav
John Doe wrote:
I am sorry for my html post. Anyway I can reproduce the resizing bug on
my system by doing:
set lines=999 columns=999
twice in a row.
Strange. Once I do that, gvim starts behaving strangely -- and very slowly. I
don't see ex-commands I type (as if they were off-screen
Folks,
Vim 6.4/7.0 can't show result of cscope find f name correctly.
E.g.
1 1 Makefile unknown
2 1 arch/Makefile unknown
h
3 1 arch/README unknown
4 1 arch/evbsh5/Makefile unknown
Ã~mts5
5 1
Nikolai Weibull wrote:
Test case:
vim -c 'e ++enc=latin1 a.test | exec normal! i\C-Vu2026 | set
autowriteall | q'
And make sure 'encoding' is utf-8. Yes, I can reproduce it. One more
item for the todo list...
--
hundred-and-one symptoms of being an internet addict:
39. You move into a
Alexei Alexandrov wrote:
Hi Bram et al.,
here is a rather strange bug. It seems to be specific for Windows and only when I try to open *.exe or *.dll file (yes, it's strange but sometimes I use it). If I open an *.exe file with
gvim bjam.exe
it opens just fine. But if I open it with
gvim
Hi Bram Moolenaar, you wrote:
I can't reproduce it. It could be caused by a plugin.
Does adding -V10 show some context of the error?
Does anyone else see this?
Not sure if my previous message reached the list: the bug is reproducible only
if the extension of the file
set 'binary', try another variant.
The key in the bug report is that error is reproducible only with
--remote-tab-silent. I'm not sure why the advices above can have different
behavior with this option.
--
Alexei Alexandrov
into
'wildignore'. In my .vimrc I have
set
wildignore=*.o,*.obj,*.exe,*.lib,*.a,*.dll,*.swp,*.ncb,*.aps,*.opt,*.pdb,*.bak,*~,*.d
and the bug can be reproduced for any of these extensions. And only
with --remote-tab-silent.
OK, I can reproduce it now. I have *.pyc in 'wildignore' and editing
foo.pyc
into
'wildignore'. In my .vimrc I have
set
wildignore=*.o,*.obj,*.exe,*.lib,*.a,*.dll,*.swp,*.ncb,*.aps,*.opt,*.pdb,*.bak,*~,*.d
and the bug can be reproduced for any of these extensions. And only
with --remote-tab-silent.
OK, I can reproduce it now. I have *.pyc in 'wildignore' and editing
Thomas Link wrote:
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
Hi,
In the following, command line expansion works in gvim but not in vim:
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.
Regards,
Thomas.
Thomas wrote:
In the following, command line expansion works in gvim but not in vim:
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
1 - 100 of 418 matches
Mail list logo
