Just wanted to add to the below that the problem is not just chaining
functions, but using the return value of the function itself. If the
function returns a dictionary (and probably a list), you can't use it to
access its members, so something like this will also fail:
let t.T()['abc'] = 'xyz'
On 6/21/06, Hari Krishna Dara [EMAIL PROTECTED] wrote:
Just wanted to add to the below that the problem is not just chaining
functions, but using the return value of the function itself. If the
function returns a dictionary (and probably a list), you can't use it to
access its members, so
Can anyone else please try to reproduce this?
Yes, I. With
:
On Sun, 18 Jun 2006 at 11:26pm, Bram Moolenaar wrote:
Hari Krishna Dara wrote:
I was just stuck by another serious bug in Vim7, again to do with insert
mode completion (i_Ctrl-P) and repeat, and it is easy to reproduce (I
apologize if this was already reported). Try this:
- Start
Hari Krishna Dara wrote:
I was just stuck by another serious bug in Vim7, again to do with insert
mode completion (i_Ctrl-P) and repeat, and it is easy to reproduce (I
apologize if this was already reported). Try this:
- Start plain vim: gvim -u NONE
- :set nocp
- Add the below two lines
Ilya Bobir wrote:
I've found bug in vim version
VIM - Vi IMproved 7.0 (2006 May 7, compiled May 25 2006 04:17:33)
MS-Windows 32 bit GUI version with OLE support
Included patches: 1-17
In case incremental search is on, tab line some times is not visible.
Steps to reproduce:
gvim -u
Hi,
Am Freitag, 16. Jun 2006, 18:47:32 +0200 schrieb Christian Ebert:
* Bram Moolenaar on Friday, June 16, 2006 at 17:24:20 +0200:
I'll leave it up to language specialists to decide whether making straße
uppercase should result in STRAßE or STRASSE. I thought it was STRASSE.
Historic:
Tony Mechelynck wrote:
Documentation bug: In
*help.txt*For Vim version 7.0. Last change: 2006 May 07
Under standard plugins, at lines 191-196, pi_spec.txt and
pi_vimball.txt are not mentioned.
I haven't checked the helpfile names other than pi_*.txt
pi_spec.txt is about
was: regexp.c:4198.
Just before the trap the debugger complained that someone wrote data
after allocated heap block (the address corresponds to the variable
'cond').
Should I pay more attention on this bug to provide more info?
-- Anatoli Sakhnik.
P.S.: The version without gui works
Jürgen Krämer wrote:
can anybody confirm this misbehaviour in VIM 7.0:
Starting
gvim -u NONE -U NONE
and typing
iStraßenesc0gUe
results in
STRASSEn
(note the lower case 'n'). The same is true for
iStraßenesc0veU
It seems that after converting the sharp s to
hmm, well ... this is as buggy as the java String.toUpperCase() method ;-)
oracle for example does it right and leaves the sharp s as it is -
because there is no upper case variant of it.
SQL select upper('straße') from dual;
UPPER('
---
STRAßE
my 2 cents,
martin
Bram Moolenaar wrote:
Martin Kraegeloh wrote:
hmm, well ... this is as buggy as the java String.toUpperCase() method ;-)
oracle for example does it right and leaves the sharp s as it is -
because there is no upper case variant of it.
I'll leave it up to language specialists to decide whether making straße
* Bram Moolenaar on Friday, June 16, 2006 at 17:24:20 +0200:
I'll leave it up to language specialists to decide whether making straße
uppercase should result in STRAßE or STRASSE. I thought it was STRASSE.
Historic: STRASZE
Now: STRASSE
See: http://de.wikipedia.org/wiki/Versal-Eszett
Benji Fisher wrote:
On Thu, May 18, 2006 at 10:20:38AM +, Dan Clarke wrote:
Hi. I've just installed Vim 7. l use MS Windows. I've found a
problems with the indentations.
You can replicate it by doing the following ...
- Copy a whole word into the clipboard.
- In a C/C++
Christian Ebert wrote:
* Bram Moolenaar on Friday, June 16, 2006 at 17:24:20 +0200:
I'll leave it up to language specialists to decide whether making straße
uppercase should result in STRAßE or STRASSE. I thought it was STRASSE.
Historic: STRASZE
Now: STRASSE
See:
Dnia piątek, 16 czerwca 2006 16:47, martin kraegeloh napisał:
hmm, well ... this is as buggy as the java String.toUpperCase() method
;-)
oracle for example does it right and leaves the sharp s as it is -
because there is no upper case variant of it.
I was thought that capital version of ß
Dnia piątek, 16 czerwca 2006 13:34, Bram Moolenaar napisał:
I see the problem. I'll put it in the todo list.
Sub-problem with ß. In latin2 'encoding' (where ß also exists) it isn't
changed to SS. I think behaviour should be the same for all encodings.
m.
Mikolaj Machowski wrote:
Dnia piątek, 16 czerwca 2006 13:34, Bram Moolenaar napisał:
I see the problem. I'll put it in the todo list.
Sub-problem with ß. In latin2 'encoding' (where ß also exists) it isn't
changed to SS. I think behaviour should be the same for all encodings.
m.
In
a dictionary).
RME
Text to bug report:
This concerns functions and dictionaries
While bug: 1491613 is a true error in the existing
code, this bug is more of an enhancement.
Currently if a function returns a dictionary, one
can not call a function on that returned dictionary
(or access a value
dictionary function chaining.
Some of you might be interested in extending the
patch to include value access via applying a key
to the results of a function (if the function returns
a dictionary).
RME
Text to bug report:
This concerns functions and dictionaries
While bug: 1491613 is a true error
Tony Mechelynck wrote:
*pi_paren.txt* For Vim version 7.0. Last change: 2006 Apr 24
line 46 (i.e. 5th from bottom)
there is 'synmaxcolumn'
there should be 'synmaxcol'
Thanks for the fix.
--
% cat /usr/include/sys/errno.h
#define EPERM 1 /* Operation not permitted
.
is this bug known ?
regards jochen
Strange.
1. What are the first lines (until and including Features included (+)
or not (-)) output by the :version command?
To copy them to the clipboard, use the following (on gvim for X11):
:redir @*
:version
:redir END
:let @+ = @*
Then paste
*pi_paren.txt* For Vim version 7.0. Last change: 2006 Apr 24
line 46 (i.e. 5th from bottom)
there is 'synmaxcolumn'
there should be 'synmaxcol'
Best regards,
Tony.
Dnia niedziela, 11 czerwca 2006 15:57, Bertram Scharpf napisał:
Is there any way to tell Vim to leave the `ß' as it was?
Change encoding? In latin2 (where ß also exists) it is not
changed into SS but IMO this is bug.
m.
On 06/08/2006 04:14, Mathias Michaelis wrote:
Bram has fixed this bug already a month ago ;-)
See: http://groups.yahoo.com/group/vimdev/message/43639
Sigh. Good news, but I wish we knew this 13 e-mails ago. :-)
Thanks to everyone that looked into this.
--
Jared
Hi,
can anybody confirm this misbehaviour in VIM 7.0:
Starting
gvim -u NONE -U NONE
and typing
iStraßenesc0gUe
results in
STRASSEn
(note the lower case 'n'). The same is true for
iStraßenesc0veU
It seems that after converting the sharp s to 'SS' VIM does not account
for the now
the time to investigate. I'm a little
puzzled why Benji and I are seeing this issue, but Ilya is not.
Can anyone else either confirm or refute this? Is it perhaps a
Windows-specific bug? I only currently have access to Vim 7 on a Windows
system, so I'm unable to test it under Linux.
I
= []
This function is used for the 'omnifunc' option.
Or Benji's:
long line
()
another
Reason I'm asking is because if you're using mine, then you do NOT see the
bug. If you're using Benji's then you do see the bug. It's an unfortunate
coincidence that 'o' signifies a success in one
and I are seeing this issue, but Ilya is not.
Can anyone else either confirm or refute this? Is it perhaps a
Windows-specific bug? I only currently have access to Vim 7 on a Windows
system, so I'm unable to test it under Linux.
--
Jared Breland
[EMAIL PROTECTED]
http://www.legroom.net/
the time to investigate. I'm a little
puzzled why Benji and I are seeing this issue, but Ilya is not.
Can anyone else either confirm or refute this? Is it perhaps a
Windows-specific bug? I only currently have access to Vim 7 on a Windows
system, so I'm unable to test it under Linux.
I
was: regexp.c:4198.
Just before the trap the debugger complained that someone wrote data
after allocated heap block (the address corresponds to the variable
'cond').
Should I pay more attention on this bug to provide more info?
-- Anatoli Sakhnik.
P.S.: The version without gui works just fine.
On Mon, Jun 05, 2006 at 04:24:38PM +0300, Ilya wrote:
Benji Fisher wrote:
I can reproduce it. Perhaps we just need more explicit
instructions on how to reproduce it. Using the text above, go to the
g:loaded_autoit_completion line and (starting in Normal mode) type
$iDownDown
Benji Fisher wrote:
Perhaps you have set 'matchpairs' so that it does not include
[:]?
matchpairs does include [:] - as by default. And brackets are
highlighted when cursor is near one of them.
Since you snipped the three sample lines, here is another
example:
long line
On Tue, Jun 06, 2006 at 05:11:13PM +0300, Ilya wrote:
Benji Fisher wrote:
Perhaps you have set 'matchpairs' so that it does not include
[:]?
matchpairs does include [:] - as by default. And brackets are
highlighted when cursor is near one of them.
Since you snipped the three sample
Benji Fisher wrote:
I can reproduce it. Perhaps we just need more explicit
instructions on how to reproduce it. Using the text above, go to the
g:loaded_autoit_completion line and (starting in Normal mode) type
$iDownDown
to reproduce.
I can see the problem in
Bug: Cannot redir to @+
- Symptom: Trying to :redir to register + (seen by other apps as the
clipboard) gives
E475: Invalid argument: @+
- Vim version: 7.0.017 for GTK2 GUI
- Workaround: :redir to register * then (after :redir END) do manually
:let @+ = @*
Just redirecting
Hi Antoine,
On 6/2/06, A.J.Mechelynck [EMAIL PROTECTED] wrote:
Bug: Cannot redir to @+
Redirecting the Ex command output and messages to the + register
is not (yet?) supported and is not mentioned in the help for the :redir
command.
- Yegappan
- Symptom: Trying to :redir to register
I think I found a bug in in the matchparen feature of Vim 7. I'm using the
7.0 binary release for Windows XP.
When I'm in Insert mode and moving across lines, if the cursor passes over a
paren (defined here as any character in the matchpairs option), the cursor
will stay in the column position
, then my cursor
will instead end up on the 'e' in 'used'.
[...]
I do not have this bug.
I'm having
VIM - Vi IMproved 7.0 (2006 May 7, compiled May 25 2006 04:17:33)
MS-Windows 32 bit GUI version with OLE support
Included patches: 1-17
that I've compiled myself from current CVS version
Hello.
I've found bug in vim version
VIM - Vi IMproved 7.0 (2006 May 7, compiled May 25 2006 04:17:33)
MS-Windows 32 bit GUI version with OLE support
Included patches: 1-17
In case incremental search is on, tab line some times is not visible.
Steps to reproduce:
gvim -u NONE -U NONE
:e 1.txt
It appears that the first key of any incremental search to a point far
enough down in the file (i.e. a page below the displayed area) will
cause it. Typing any additional key brings the tabline back.
I fiddled around with TabLineSet.vim, but it appears that the bug is
in the code that decides
strange (i.e.
bug like) if Vim first asks me if I want to recover a file, and when I
say yes, Vim tells me it can't find the swap file anymore ...
Another possibility: Did you by any chance have a zero-length swap file?
Vim creates the swap file when you open a non-readonly edit file
What's the value of your 'paste' option?
On 5/18/06, Dan Clarke [EMAIL PROTECTED] wrote:
Hi. I've just installed Vim 7. l use MS Windows. I've found a
problems with the indentations.
You can replicate it by doing the following ...
- Copy a whole word into the clipboard.
- In a C/C++ file,
The paste option isn't set. If I set it, auto indentation doesn't work
at all, and when I press 'control-v', it just pastes a caret character
instead of what's in the clipboard.
- Dan
Eric Arnold wrote:
What's the value of your 'paste' option?
On 5/18/06, Dan Clarke [EMAIL PROTECTED]
On Thu, May 18, 2006 at 10:20:38AM +, Dan Clarke wrote:
Hi. I've just installed Vim 7. l use MS Windows. I've found a
problems with the indentations.
You can replicate it by doing the following ...
- Copy a whole word into the clipboard.
- In a C/C++ file, position the cursor on a
Hi All,
I found the following bug:
$ mkdir /tmp/foo
$ touch /tmp/foo/bar
$ cd /tmp/
$ ln -s foo/bar .
$ vim bar
Now type some text into bar, and then kill vim (say with kill -9) from a
different terminal.
Now when you type vim /tmp/bar it reports that a .swp file is found
On Tue, May 16, 2006 at 11:19:57PM -0500, Gautam Iyer wrote:
Now when you type vim /tmp/bar it reports that a .swp file is found
and asks you about recovery. However when you press R for recovering
the file, vim complains saying it can not find the swap file (probably
because vim looks for the
On Wed, May 17, 2006 at 10:31:55AM -0400, James Vega wrote:
On Tue, May 16, 2006 at 11:19:57PM -0500, Gautam Iyer wrote:
Now when you type vim /tmp/bar it reports that a .swp file is found
and asks you about recovery. However when you press R for recovering
the file, vim complains saying
Gautam Iyer wrote:
On Wed, May 17, 2006 at 10:31:55AM -0400, James Vega wrote:
On Tue, May 16, 2006 at 11:19:57PM -0500, Gautam Iyer wrote:
Now when you type vim /tmp/bar it reports that a .swp file is found
and asks you about recovery. However when you press R for recovering
the
Matt Zyzik wrote:
Not a single IDE has the kind of completion system where the entry isn't
selected as you type it. It's a speed convenience, that you can hit
enter at any time to insert the entry into text. With Vim, I could hit
c-l to keep completing, or c-y to select. I don't feel like
On Thu, May 11, 2006 at 03:10:40PM +0200, Pierre Habouzit wrote:
Le Jeu 11 Mai 2006 14:57, Pierre Habouzit a écrit :
make enter work in popup
inoremap cr C-R=pumvisible() ? \ltC-Y : \ltcrcr
sadly I can't do the same with esc to exit the completion, because
of esc beeing esc
Le Jeu 11 Mai 2006 21:55, Martin Stubenschrott a écrit :
On Thu, May 11, 2006 at 03:10:40PM +0200, Pierre Habouzit wrote:
Le Jeu 11 Mai 2006 14:57, Pierre Habouzit a écrit :
make enter work in popup
inoremap cr C-R=pumvisible() ? \ltC-Y :
\ltcrcr
sadly I can't do the
On 5/11/06, Bram Moolenaar [EMAIL PROTECTED] wrote:
1. Vim is not an IDE
2. Vim works differently
3. Get used to it
Hah. Awesome, I literally LOLed
at bottom will say: match 1 of 100
I get Spell checking is not enabled. Did you do :set spell?
Yes, I did :set spell before ifooey.
Hit up-arrow
Message at bottom will say: Back at original
BUT BUG: 1) word in buffer is Phooey (not original word).
2) esc
, but it doesn't
insert the chosen word on the buffer window and therefore things don't
behave as expected.
IMHO, yes, as Gerald said, it is confirmed that there is a bug in
using i_up-arrow and i_down-arrow for omni features, but not the omni
function itself. I believe what Bram has defined in vim help holds
oh dearI just realize I kept saying omni this and omni that when I
read the thread again! Please forgive my stupidity and ignore any word
about omni...it should be completion, IT IS *i_ctrl-x_s*.
I should stop working and go home. :)
On Wed, 10 May 2006, Suresh Govindachar wrote:
[snip]
Confirmed for 7.0 release. It seems that i_up-arrow
i_down-arrow work un-intuitively as compared to i_ctrl-p
i_ctrl-n, respectively.
Not exactly -- the bug is _NOT_ un-intutiveness.
To both Suresh and Edward: please read my
I have finally correctly understood Bram's intent regarding
what can happen after i_CTRL s and things indeed work that way.
--Suresh
Matt Mzyzik wrote:
Assume the buffer is as follows (between quotes):
Rabbits are really great
rats are not so great
ra
Now if my cursor is after the ra on the third line, and I do a c-n to
see keyword completions, the ra disappears when the menu comes up. Is
this desired?
I get
completions, the ra disappears when the menu comes up. Is
this desired?
I get rats. Check your 'completeopt' setting.
my 'completeopt' is set to longest,menuone
also, I'm certain now that this bug didn't happen on at least one of the
old vim betas (the one on the gentoo portage)
and yes, if I take
to
see keyword completions, the ra disappears when the menu comes up. Is
this desired?
I get rats. Check your 'completeopt' setting.
my 'completeopt' is set to longest,menuone
also, I'm certain now that this bug didn't happen on at least one of the
old vim betas (the one
Matt Mzyzik wrote:
I do have 'ic' set. So then it's not a bug... ok. However, you did not
address my other bug: c-l to complete character by character does not
work.
When you use 'longest' then none of the items is selected. That was
discussed quite a while ago. You need to do CTRL-N first
On Wed, May 10, 2006 at 08:08:57PM +0200, Bram Moolenaar wrote:
Matt Mzyzik wrote:
I do have 'ic' set. So then it's not a bug... ok. However, you did not
address my other bug: c-l to complete character by character does not
work.
When you use 'longest' then none of the items
Matt Mzyzik wrote:
I do have 'ic' set. So then it's not a bug... ok. However, you did not
address my other bug: c-l to complete character by character does not
work.
When you use 'longest' then none of the items is selected. That was
discussed quite a while ago. You need to do
Try the following in an empty buffer:
:g/./
It will give you an
E486: Pattern not found: .
message, but it won't be highlighted as an ErrorMsg.
Executing
/./
on the same buffer does give the error message with the correct highlighting.
I'm running Vim 7 without any patches applied.
what you mean is that you select the item first
with the up/down arrows and then take letters with CTRL-L. Even then
that's not the case, it only works for one letter.
I'm pretty sure it's a bug; try it out.
OK, I see what you mean. After using CTRL-L it shouldn't unselect the
item
-L
does nothing. I think what you mean is that you select the item first
with the up/down arrows and then take letters with CTRL-L. Even then
that's not the case, it only works for one letter.
I'm pretty sure it's a bug; try it out.
OK, I see what you mean. After using CTRL-L
nothing. I think what you mean is that you select the item first
with the up/down arrows and then take letters with CTRL-L. Even then
that's not the case, it only works for one letter.
I'm pretty sure it's a bug; try it out.
OK, I see what you mean. After using CTRL-L
ifooey.
Hit up-arrow
Message at bottom will say: Back at original
BUT BUG: 1) word in buffer is Phooey (not original word).
2) esc will result in buffer having Phooey in it.
Using the cursor only selects another entry, it doesn't insert
it. Use Enter to insert
On 5/9/06, Gary Johnson [EMAIL PROTECTED] wrote:
By default, :cn should open a closed fold, and when executed as
:cn, it does so. But when :cn is the rhs of a map and the lhs
of the map is typed, closed folds do not open. I think :cn
should behave the same whether executed
Gary Johnson wrote:
Summary:
By default, :cn should open a closed fold, and when executed as
:cn, it does so. But when :cn is the rhs of a map and the lhs
of the map is typed, closed folds do not open. I think :cn
should behave the same whether executed directly or as
On Fri, 5 May 2006 at 9:22am, Bram Moolenaar wrote:
Hari Krishna Dara wrote:
Using Vim 70g, I am seeing a weird problem with CursorMoved autocommand.
In a function, I am removing my CursorMoved autocommand, moving the
cursor and adding the CursorMoved autocommand back, but the cursor
Georg Dahn wrote:
I tried, also on Windows XP, but I don't see the problem. I have no
idea why it happens for you. Must be something obscure. What
compiler did you use? Does it also show in the distributed Vim 7.0g?
That's interesting. I use the same compiler as you (at least
Hari Krishna Dara wrote:
Using Vim 70g, I am seeing a weird problem with CursorMoved autocommand.
In a function, I am removing my CursorMoved autocommand, moving the
cursor and adding the CursorMoved autocommand back, but the cursor
movement somehow ends up triggering the autocommand. At
Hi!
I tried several versions, starting with gvim -u NONE -N
and still don't see the problem. I have no idea what
could make it appear.
It would be interesting, what is common between Mikolaj Machowski and
me, since we both can see the problem. I am working on two computers
and this problem
Hi!
I tried, also on Windows XP, but I don't see the problem. I have no
idea why it happens for you. Must be something obscure. What
compiler did you use? Does it also show in the distributed Vim 7.0g?
That's interesting. I use the same compiler as you (at least that's what
I think),
Dnia czwartek, 4 maja 2006 16:30, Georg Dahn napisał:
I am running gVim 7.0g02 on Windows XP.
Confirming for gtk2 version.
Last character is always highlighted and whole line becomes yellow
(default color). BTW - also true for console version.
VIM - Vi IMproved 7.0g02 BETA (2006 May 3,
Eric Van Dewoestine wrote:
You've mentioned a few times how the code completion logic is getting
complicated, but is that a good reason for leaving in known issues?
Perhaps after you have released vim70, vim71 should get a bit of an
overhaul in this area now that you've encountered a broader
Charles Campbell wrote:
This one appears to be a ctrl-f (and ctrl-b) bug. Here's the setup:
(using Linux,vim-7.0g, huge)
.vimrc :
set nocp
.gvimrc :
set lines=21
no .vim/ directory.
Now, for the problem:
gvim -geometry 139x22+0+4 netrw.vim
11jspace
zcr
4jspace6k4j
Eric Van Dewoestine wrote:
I know about this: When you type the . and there no complete
match was inserted (showing the longest common text in this example),
Vim assumes you are extending the text to reduce the list of matches.
Thus the completion still starts at BlahBlah.
You need
On Tue, May 02, 2006 at 12:13:37AM +0200, Bram Moolenaar wrote:
Eric Van Dewoestine wrote:
I know about this: When you type the . and there no complete
match was inserted (showing the longest common text in this example),
Vim assumes you are extending the text to reduce the list of
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
Hello!
This one appears to be a ctrl-f (and ctrl-b) bug. Here's the setup:
(using Linux,vim-7.0g, huge)
.vimrc :
set nocp
.gvimrc :
set lines=21
no .vim/ directory.
Now, for the problem:
gvim -geometry 139x22+0+4 netrw.vim
11jspace
zcr
4jspace6k4j
ctrl-f
Note that the ctrl-f does
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
Yakov wrote:
I'v began testing of VIM 7 rather late, so may be this is fixed
already but anyway folks from IRC knows nothing bout that fact.
I'v built vim7c04 on QNX632 and NetBSD with --enable-gui=gtk. When i
use :tabnew i got several tabs. That works but when im trying to
navigate throw
[EMAIL PROTECTED] wrote:
All,
I found a bug related to syntax highlighting, although I wouldn't be
surprised if people already know about this. Simply, the syntax
highlighting sometimes gets messed up and I have to refresh the window
(with c-l) in order make the highlighting correct again.
I
Matt Mzyzik wrote:
I found a bug related to syntax highlighting, although I wouldn't be
surprised if people already know about this. Simply, the syntax
highlighting sometimes gets messed up and I have to refresh the window
(with c-l) in order make the highlighting correct again.
I have
On Fri, Apr 28, 2006 at 04:08:32PM +0200, Nikolai Weibull wrote:
On 4/28/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
I found a bug related to syntax highlighting, although I wouldn't be
surprised if people already know about this. Simply, the syntax
highlighting sometimes gets messed up
[EMAIL PROTECTED] wrote:
On Fri, Apr 28, 2006 at 04:08:32PM +0200, Nikolai Weibull wrote:
On 4/28/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
I found a bug related to syntax highlighting, although I wouldn't be
surprised if people already know about this. Simply, the syntax
On Thu, 27 Apr 2006 09:47:06 +0100 (BST)
Georg Dahn [EMAIL PROTECTED] wrote:
Hi!
There is another strange behavior with gui tabs on Windows.
I. First test case
1. Open gVim (gvim -u NONE)
2. Assure, that 'guioptions' contain 'e' (gui tab)
3. Open a new tab with :tabnew and write
.
There is definitely no problem with the spell function in Vim.
Thanks for your help.
Best regards,
Milan
On Tue Apr 25, 2006 at 06:11:22PM +0200, Bram Moolenaar wrote:
Milan Berta wrote:
Is this only my problem, or is this really a bug?
There are no suggestions with hyphen - in the list
In Vim 6.3, hitting ^X in insert mode when the cursor is on the number:
08)
produced:
03778)
This is a bug which seems to be fixed in Vim 7.0f, but it doesn't work
right, as it now produces:
7)
instead of:
07)
If the string is say,
07)
both versions correctly produce,
06
On Wed, 26 Apr 2006, Hari Krishna Dara wrote:
In Vim 6.3, hitting ^X in insert mode when the cursor is on the number:
08)
produced:
03778)
This is a bug which seems to be fixed in Vim 7.0f, but it doesn't work
right, as it now produces:
7)
instead of:
07)
If the string is say
Hello Vim-Dev,
Is this only my problem, or is this really a bug?
There are no suggestions with hyphen - in the list of suggestions (for
example, on z= request in normal mode. There are a lot of possibilities
with the hyphen in long words (especially in English). But they are just
not shown
Milan Berta wrote:
Is this only my problem, or is this really a bug?
There are no suggestions with hyphen - in the list of suggestions (for
example, on z= request in normal mode. There are a lot of possibilities
with the hyphen in long words (especially in English). But they are just
On Sat, Apr 22, 2006 at 04:39:58AM -0600, Eric Arnold wrote:
I just noticed that :marks has the first column as 0.
I see it, too. If I do ma (in Normal mode, without the quotes)
and then
:echo col('a)
:marks
the results are off by one.
I am getting behind: vim 7.0e.
HTH
Benji Fisher wrote:
On Sat, Apr 22, 2006 at 04:39:58AM -0600, Eric Arnold wrote:
I just noticed that :marks has the first column as 0.
I see it, too. If I do ma (in Normal mode, without the quotes)
and then
:echo col('a)
:marks
the results are off by one.
I am
It isn't a big deal, but I don't know of anywhere in Vim where 0 is
a valid column. String index, maybe but...
On 4/25/06, Bram Moolenaar [EMAIL PROTECTED] wrote:
Benji Fisher wrote:
On Sat, Apr 22, 2006 at 04:39:58AM -0600, Eric Arnold wrote:
I just noticed that :marks has the first
Subject Govindachar wrote:
Hello,
Is this a bug, or is it something that cannot be fixed?
1) gvim.exe -u NONE -U NONE --noplugin
2) :set smartindent tw=40 fo=tcq
3) Type text -- at least, say, 60 characters.
Vim will insert linebreaks.
4) Join the pieces to have
. Is it a normal behavior or is this a bug? Can it be set (or
suppressed) that the underlaying (in this case) pink writing will have
a different color then (in this case) the pink VISUAL block?
I just report it as a bug.
I wanted to report a simple example as a JPEG (as I've seen it as an
E-mail while
301 - 400 of 418 matches
Mail list logo
