On Do, 08 Aug 2013, glts wrote:
When I run an external command like :!find I can see the output in the
messages area and the prompt
Press ENTER or type command to continue
By reflex I hit u to scroll up and I got
Press ENTER or type command to continuePress ENTER or type command to
On 08/08/2013 23:51, tooth pik wrote:
On Thu, Aug 08, 2013 at 04:14:08PM -0400, Manuel Ortega wrote:
There is a horrendous bug wrt the 'g~' operator. I've found it on OSX
10.8.4. Doesn't matter whether it's MacVim 7.4b or Vim 7.4b.18.
To reproduce: Make a new file with three lines:
On Tuesday, August 6, 2013 4:34:33 AM UTC+9, Bram Moolenaar wrote:
Thanks. I wonder why nobody reported a problem with this before. Just
not so many users in this situation or are they not using multi-byte
characters with external commands?
:vimgrep works properly, right?
Maybe it is. I
Mike Williams wrote:
On 08/08/2013 23:51, tooth pik wrote:
On Thu, Aug 08, 2013 at 04:14:08PM -0400, Manuel Ortega wrote:
There is a horrendous bug wrt the 'g~' operator. I've found it on OSX
10.8.4. Doesn't matter whether it's MacVim 7.4b or Vim 7.4b.18.
To reproduce: Make a new
Hi,
First vim -nNX -u NONE ad :se ve=all
Then enter the following test with X representing the cursor:
if {
X
}
Now vaB is wrong
Regards
Dimitar
---
GPG Key: 2048R/160C6FA8 2012-10-11 Dimitar Dimitrov (kurkale6ka)
mitk...@yahoo.fr
--
--
You received this message from
On Friday, August 9, 2013 9:52:58 AM UTC-5, Dimitar DIMITROV wrote:
Hi,
First vim -nNX -u NONE ad :se ve=all
Then enter the following test with X representing the cursor:
if {
X
}
Now vaB is wrong
I don't see anything wrong. For me it selects all
On 2013-08-09, Christian Brabandt wrote:
Hi Gary!
On Do, 08 Aug 2013, Gary Johnson wrote:
On 2013-08-08, Christian Brabandt wrote:
Hi Gary!
On Do, 08 Aug 2013, Gary Johnson wrote:
The following problem appears in vim 7.3.882 and 7.4b.19 on Linux.
In the Vim src
Hi,
First vim -nNX -u NONE ad :se ve=all
Then enter the following test with X representing the cursor:
if {
X
}
Now vaB is wrong
I don't see anything wrong. For me it selects all text from the opening { to
the closing }. What do you see?
I tried gvim 7.3.822
On Friday, August 9, 2013 11:20:37 AM UTC-5, Dimitar DIMITROV wrote:
I don't see anything wrong. For me it selects all text from the opening { to
the closing }. What do you
see?
I tried gvim 7.3.822 on Windows, and also vim (not gvim) 7.4b.14 on Solaris,
both with Huge features. What
Patch 7.4b.020
Problem:g~ap changes first character of next paragraph. (Manuel Ortega)
Solution: Avoid subtracting (0 - 1) from todo. (Mike Williams)
Files: src/ops.c, src/testdir/test82.in, src/testdir/test82.ok
*** ../vim-7.4b.019/src/ops.c 2013-07-14 13:07:51.0 +0200
Patch 7.4b.021
Problem:Pressing u after an external command results in multiple
press-enter messages. (glts)
Solution: Don't call hit_return_msg() when we have K_IGNORE. (Christian
Brabandt)
Files: src/message.c
*** ../vim-7.4b.020/src/message.c
Christian Brabandt wrote:
On Do, 08 Aug 2013, glts wrote:
When I run an external command like :!find I can see the output in the
messages area and the prompt
Press ENTER or type command to continue
By reflex I hit u to scroll up and I got
Press ENTER or type command to
Gary Johnson wrote:
The following problem appears in vim 7.3.882 and 7.4b.19 on Linux.
I've seen similar behavior on any version of vim. Are you sure
you have your synchronization buffer set high enough for your
lang? It seems to be a different variable for each language...
like
C,
On 2013-08-09, Linda W wrote:
Gary Johnson wrote:
The following problem appears in vim 7.3.882 and 7.4b.19 on Linux.
I've seen similar behavior on any version of vim. Are you sure
you have your synchronization buffer set high enough for your
lang? It seems to be a different variable
Hi,
I also found that some functions in os_win32.c don't use Unicode APIs.
* fname_case()
I think this should be fixed. Currently the case of a filename is not
set properly.
* mch_get_user_name()
Fixed with fix-utf8-username.patch.
* mch_get_host_name()
Fixed with
Hi,
WaitForChar() in os_win32.c doesn't wait properly when the result of
the GetTickCount() overflows. Attached patch fixes this.
Regards,
Ken Takata
--
--
You received this message from the vim_dev maillist.
Do not top-post! Type your reply below the text you are replying to.
For more
16 matches
Mail list logo