Ingo Karkat wrote:
On 03-Jan-08 17:25, aj wrote:
I am running gvim on a windows box, version 7.1.
There are a series of coldfusion source files located on another machine on
the network. I have a shortcut to the network directory containing these
files on my desktop.
When I try to open
Patch 7.1.197
Problem:Mac: make install doesn't work when prefix defined.
Solution: Pass different arguments to make installruntime. (Jjgod Jiang)
Files: src/Makefile
*** ../vim-7.1.196/src/Makefile Thu Jan 3 20:44:40 2008
--- src/MakefileThu Jan 3 18:30:02 2008
Patch 7.1.198
Problem:Hang when using :s/\n//gn. (Burak Gorkemli)
Solution: Set skip_match.
Files: src/ex_cmds.c
*** ../vim-7.1.197/src/ex_cmds.cWed Jan 2 13:58:17 2008
--- src/ex_cmds.c Fri Jan 4 14:46:34 2008
***
*** 4575,4580
--- 4575,4581
Tony Mechelynck wrote:
Ben Schmidt wrote:
The filenames were the strings above without the double quotes.
Backslash-escaping looked OK: I could edit the files and save them. Then
ls
t* in bash didn't show spurious filenames, and these files' lengths
weren't
zero anymore. If you have
Patch 7.1.199
Problem:Can't do command line completion for a specific file name
extension.
Solution: When the pattern ends in $ don't add a star for completion and
remove the $ before matching with file names.
Files: runtime/doc/cmdline.txt, src/ex_getln.c
A couple of problems were detected when the Unix shell is used to expand
file names containing characters such as a single quote. This applies
to completion on the command line and glob().
I made a patch that defines a function to echo each file name
separately. Inspired by a patch that Dasn
Ben Schmidt wrote:
The filenames were the strings above without the double quotes.
Backslash-escaping looked OK: I could edit the files and save them. Then ls
t* in bash didn't show spurious filenames, and these files' lengths weren't
zero anymore. If you have other cases in mind, I'm
The filenames were the strings above without the double quotes.
Backslash-escaping looked OK: I could edit the files and save them. Then ls
t* in bash didn't show spurious filenames, and these files' lengths weren't
zero anymore. If you have other cases in mind, I'm ready to check.
I will
Bram Moolenaar wrote:
A couple of problems were detected when the Unix shell is used to expand
file names containing characters such as a single quote. This applies
to completion on the command line and glob().
I made a patch that defines a function to echo each file name
separately.
Patch 7.1.200 (after 7.1.177 and 7.1.182)
Problem:Compiler warnings for uninitialized variables.
Solution: Init variables.
Files: src/ex_cmds2.c, src/ex_docmd.c
*** ../vim-7.1.199/src/ex_cmds2.c Tue Jan 1 14:16:42 2008
--- src/ex_cmds2.c Fri Jan 4 15:55:54 2008
Bram Moolenaar wrote:
A couple of problems were detected when the Unix shell is used to expand
file names containing characters such as a single quote. This applies
to completion on the command line and glob().
I made a patch that defines a function to echo each file name
separately.
Patch 7.1.201
Problem:When reading stdin 'fenc' and 'ff are not set.
Solution: Set the options after reading stdin. (Ben Schmidt)
Files: src/fileio.c
*** ../vim-7.1.200/src/fileio.c Wed Jan 2 21:07:32 2008
--- src/fileio.cFri Jan 4 16:18:27 2008
***
*** 221,231
Tony Mechelynck wrote:
Bram Moolenaar wrote:
A couple of problems were detected when the Unix shell is used to expand
file names containing characters such as a single quote. This applies
to completion on the command line and glob().
I made a patch that defines a function to
I wrote:
Tony Mechelynck wrote:
Bram Moolenaar wrote:
A couple of problems were detected when the Unix shell is used to expand
file names containing characters such as a single quote. This applies
to completion on the command line and glob().
I made a patch that
Patch 7.1.202
Problem:Incomplete utf-8 byte sequence is not checked for validity.
Solution: Check the bytes that are present for being valid. (Ben Schmidt)
Files: src/mbyte.c
*** ../vim-7.1.201/src/mbyte.c Thu Aug 30 13:51:52 2007
--- src/mbyte.c Fri Jan 4 17:30:16 2008
Bram Moolenaar wrote:
The comments in the patch contain non-ASCII characters. I've seen
before that these may cause trouble.
If you used the path from the e-mail you can first check if it's equal
to what is on the ftp site: ftp://ftp.vim.org/pub/vim/patches/7.1/7.1.193
Then check the lines in
Bram Moolenaar wrote:
[...]
It appears it all works fine when 'shell' is sh, but not when it is
bash. What is the difference between sh and bash considering
single quotes?
I'll try to find out, and the manpage for bash (which also describes how bash
reacts when invoked as sh) is extremely
Bram Moolenaar wrote:
[...]
Here is a replacement patch that should deal with bash as with sh:
[...]
Just tested with the new patch (and still in bash). Command-line completion is
now OK for the cases mentioned by Ben Schmidt (:e It\'s\ gTab). Session
file is unchanged BUT Vim accepts it --
Charles E Campbell Jr wrote:
Bram Moolenaar wrote:
The comments in the patch contain non-ASCII characters. I've seen
before that these may cause trouble.
If you used the path from the e-mail you can first check if it's equal
to what is on the ftp site:
Tony Mechelynck wrote:
It appears it all works fine when 'shell' is sh, but not when it is
bash. What is the difference between sh and bash considering
single quotes?
My fault. It has nothing to do with bash itself, just that bash is
four characters and sh is two :-). I'm glad
When I start vim 7.1.175 on my alpha running freebsd, I see a bunch of
unaligned accesses:
pid 74601 (vim): unaligned access: va=0x1202898cd pc=0x120057068
ra=0x120057044 op=ldl
pid 74601 (vim): unaligned access: va=0x1202898cd pc=0x12005708c
ra=0x12005707c op=ldl
pid 74601 (vim): unaligned
I tried adding this setting to my _vimrc (on Windows), to no avail. I still
get the massive delay.
Thanks for your insight, though. Very much appreciated.
-AJ
-Original Message-
From: Ingo Karkat [mailto:[EMAIL PROTECTED]
Sent: Friday, January 04, 2008 1:56 AM
To:
Quoting AJ Mieskolainen [EMAIL PROTECTED]:
I tried adding this setting to my _vimrc (on Windows), to no avail. I still
get the massive delay.
Thanks for your insight, though. Very much appreciated.
Try
gvim -u NONE -U NONE -X -n somefile
That'll start gvim up with no plugins, syntax,
On 04/01/08 18:27 +0100, Bram Moolenaar wrote:
! * STYLE_VIMGLOB:NL separated
! * If we use *sh*, we define vimglob().
I have been worried about the matched name which contains NL.
$ cat test.vim
call writefile([], {foo)
call writefile([], {foo\nfoo)
$ vim -c so
On Fri 4-Jan-08 4:55am -0600, Bram Moolenaar wrote:
The comments in the patch contain non-ASCII characters. I've seen
before that these may cause trouble.
If you used the path from the e-mail you can first check if it's equal
to what is on the ftp site:
25 matches
Mail list logo
