mode is used, then
the
pink color disappear where the VISUAL block extends. I know, if there
would be a VISUAL mode in another color than the same happens
somewhere
else. Is it a normal behavior or is this a bug? Can it be set (or
suppressed) that the underlaying (in this case) pink writing
On Fri, 21 Apr 2006 at 1:42pm, Hari Krishna Dara wrote:
On Fri, 21 Apr 2006 at 12:38pm, Yegappan Lakshmanan wrote:
Hi Hari,
On 4/21/06, Hari Krishna Dara [EMAIL PROTECTED] wrote:
According to the doc, the '. mark is supposed to indicate the position
where the last change
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
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
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.
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.
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
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.
Thanks,
Aaron Griffin
On Tue, Apr 18, 2006 at 12:40:17PM +0200, Bram Moolenaar wrote:
Srinath Avadhanula wrote:
I found the following difference in behavior between vim6 and vim7:
1. Open a buffer (vim -u NONE)
2. :set encoding=utf8
3. Type some stuff
4. Type the following in insert mode:
On Tue, 2006-04-18 at 12:40 +0200, Bram Moolenaar wrote:
Steve Hall wrote:
I'm seeing a gVim 7.0d (GTK2) bug in refreshing the GUI tab
bar. When a guitablabel is set by autocmd (VimEnter, BufEnter,
etc), the results aren't actually shown until the Vim window
is refreshed
On Sun, 2006-04-16 at 13:03 +0200, Bram Moolenaar wrote:
Steve Hall wrote:
I'm seeing a gVim 7.0d (GTK2) bug in refreshing the GUI tab bar.
When a guitablabel is set by autocmd (VimEnter, BufEnter, etc),
the results aren't actually shown until the Vim window is
refreshed
hi,
i have some questions about vim7/vim:
- in help ft-c-omni i can read CTRL-X CTRL-O shouldn´t this be
CTRL-N CTRL-P ? new-omni-completion section too.
-how about display line numbers in the completion popup menu ?
this would increase the speed to insert the desired string. (by typing
the
Pierre Habouzit wrote:
in certain conditions, vim was freezing on swap file prompt. One of our
users tracked that bug down, and a patch is attached.
look http://bugs.debian.org/292397
for more explanations !
[...]
Subject: Bug#292397: vim freezes on swap file prompt
Date: Jeu 13
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?
Thanks for any answer/help.
Andre
--
Feel free - 10 GB Mailbox, 100 FreeSMS/Monat ...
Jetzt GMX TopMail testen: http://www.gmx.net/de/go/topmail
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 confirm this. Did you check for conflicting abbreviations
and trailing spaces in the :ab command?
HTH
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 confirm this. Did you check for conflicting abbreviations
and trailing spaces
.) 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 confirm this. Did you check for conflicting abbreviations
I am running Vim 7.0d on FC3.
1 - the file 'no_m.vim' contains only the following line where 'm' has
been removed from the default guioptions option:
set guioptions=agirLtT
2 - run gvim with the following invocation:
$ gvim -u no_m.vim -U NONE
3 - hit F10:
The following messages are
401 - 418 of 418 matches
Mail list logo
