Re: Using py commands to evaluate text for balloon commands..
On 5/24/06, Mohsin [EMAIL PROTECTED] wrote: I am trying to use the ':py' interface to evaluate text under cursor and show the result in a balloon text. I got the python and vim code to work easily, however I have problem communicating between the two (py and vim): 1. How do I access vim variables in py commands (like text under cursor, all the 'let variables', 'set options')? This is easy, see below 2. In the Balloon vim function, how do I access py variables. Note that I am not happy with just printing the py result on the message line - I want the py output (ot data structures in a vim variable to display it in a balloon. Note that :py commands are not available in the sandbox. I dont know whether Balloon function is executed in the sandbox. Maybe it is not (then :py is available in the Balloon func), maybe it is (then :py is not available in the Balloon func). If you find out, I'm interested to hear your result. To access vim variables in py commands (like text under cursor, all the 'let variables', 'set options'): Try along these lines: let vimstringvar=mystring let numericvar=123 :exe :py pythonvar=.numericvarwe got vim numericvar into pythonvar :exe :py pythonvar='.vimstringvar.'we got vim string var into pythonvar similarly for options. nb difference needed between string vs numeric :exe :py pythonvar=.readonly we got numeric vim option into pythonvar :exe :py pythonvar='.runtmepath.' we got string vim option into pythonvar NB if rhs string contains apostrophe, then additional care is needed. THis is what comes to mind. Maybe more direct method exists. I don't know. Yakov
RE: set readonly - strange?
-Original Message-
From: Eric Arnold [mailto:[EMAIL PROTECTED]
Sent: 23 May 2006 18:12
To: Yakov Lerner
Cc: Zdenek Sekera; vim-dev@vim.org
Subject: Re: set readonly - strange?
As far as I can tell, there are several instances where there are
transitory buffers as vim is starting, opening a new tab, probably
some in closing op.s.
That may be true, but...
I don't know if I used the right word by saying the buffer is
undefined, but I don't think it it's guaranteed to be usable until a
certain point, which is after -u, and at the first file loaded, i.e.
-c
If you open a buffer explicitly from inside .vimtest , then that's a
different story.
In my test case, buffer must exist, I am well passed the '-u ...'
phase because I can *see* the buffer when I do :set readable?'.
I think Yakov's test case is saying even more.
It's kinda bug-ish, but it's not a bug unless it's contrary to stated
behavior. It'll be interesting to see how Bram addresses it.
I also think it is bug.
---Zdenek
On 5/23/06, Yakov Lerner [EMAIL PROTECTED] wrote:
On 5/23/06, Zdenek Sekera [EMAIL PROTECTED] wrote:
create a file ~/.vimtest as follows:
cat .vimtest
set nocompatible
set readonly
C-D
and execute (g)vim:
vim .vimtest -u .vimtest
try :set readonly? and you'll get 'noreadonly'.
The buffer does exist when initfile is executed. The ':ls'
in initfile shows it.
Adding more printouts to initfile shows interesting results:
vim -u 1 1
- file called 1 ---
set nocompatible
ls
call input('before set readonly 111')
set readonly
set readonly?
ls
set readonly?
set readonly?
echo readonly=.readonly
call input('after set readonly 222')
-
In vim, ':verb set readonly?' shows that readonly is
misteriously reset.
The output differs between vim6 and vim7.
--- vim7 output --
1 %1line 1
before set readonly 111
1 % = 1line 1
readonly=1
after set readonly 222
Note the missing output of ':set readonly?'!!! It prints neither
'readonly' nor 'noreadonly'.
- vim6 output
1 %1line 1
before set readonly 111
before set readonly 111
1 % = 1line 1
readonly
readonly
readonly=1
after set readonly 222
-
Looks like a bug to me.
Yakov
Re: set readonly - strange?
On 5/24/06, Zdenek Sekera [EMAIL PROTECTED] wrote:
-Original Message-
From: Eric Arnold [mailto:[EMAIL PROTECTED]
Sent: 23 May 2006 18:12
To: Yakov Lerner
Cc: Zdenek Sekera; vim-dev@vim.org
Subject: Re: set readonly - strange?
As far as I can tell, there are several instances where there are
transitory buffers as vim is starting, opening a new tab, probably
some in closing op.s.
That may be true, but...
I don't know if I used the right word by saying the buffer is
undefined, but I don't think it it's guaranteed to be usable until a
certain point, which is after -u, and at the first file loaded, i.e.
-c
If you open a buffer explicitly from inside .vimtest , then that's a
different story.
In my test case, buffer must exist, I am well passed the '-u ...'
phase because I can *see* the buffer when I do :set readable?'.
I think Yakov's test case is saying even more.
It's not clear that the buffer exists when the :set ro command is
read according to the -u option, though it might exist in some form
since no error occurs. Even if a buffer does exist at that time, I'm
fairly sure that is was transitory, and that it's not the same buffer
that you actually see and type :set ro? at.
Secondly, you need to be past the -c or similar stage, where it states
that files have been loaded. It doesn't say that for -u.
You *are* past the loading state when you type :set ro? , but that's
not the same as when the -u file is processed.
It's kinda bug-ish, but it's not a bug unless it's contrary to stated
behavior. It'll be interesting to see how Bram addresses it.
I also think it is bug.
---Zdenek
On 5/23/06, Yakov Lerner [EMAIL PROTECTED] wrote:
On 5/23/06, Zdenek Sekera [EMAIL PROTECTED] wrote:
create a file ~/.vimtest as follows:
cat .vimtest
set nocompatible
set readonly
C-D
and execute (g)vim:
vim .vimtest -u .vimtest
try :set readonly? and you'll get 'noreadonly'.
The buffer does exist when initfile is executed. The ':ls'
in initfile shows it.
Adding more printouts to initfile shows interesting results:
vim -u 1 1
- file called 1 ---
set nocompatible
ls
call input('before set readonly 111')
set readonly
set readonly?
ls
set readonly?
set readonly?
echo readonly=.readonly
call input('after set readonly 222')
-
In vim, ':verb set readonly?' shows that readonly is
misteriously reset.
The output differs between vim6 and vim7.
--- vim7 output --
1 %1line 1
before set readonly 111
1 % = 1line 1
readonly=1
after set readonly 222
Note the missing output of ':set readonly?'!!! It prints neither
'readonly' nor 'noreadonly'.
- vim6 output
1 %1line 1
before set readonly 111
before set readonly 111
1 % = 1line 1
readonly
readonly
readonly=1
after set readonly 222
-
Looks like a bug to me.
Yakov
RE: set readonly - strange?
-Original Message-
From: Eric Arnold [mailto:[EMAIL PROTECTED]
Sent: 24 May 2006 11:21
To: Zdenek Sekera
Cc: Yakov Lerner; vim-dev@vim.org
Subject: Re: set readonly - strange?
On 5/24/06, Zdenek Sekera [EMAIL PROTECTED] wrote:
-Original Message-
From: Eric Arnold [mailto:[EMAIL PROTECTED]
Sent: 23 May 2006 18:12
To: Yakov Lerner
Cc: Zdenek Sekera; vim-dev@vim.org
Subject: Re: set readonly - strange?
As far as I can tell, there are several instances where there are
transitory buffers as vim is starting, opening a new tab, probably
some in closing op.s.
That may be true, but...
I don't know if I used the right word by saying the buffer is
undefined, but I don't think it it's guaranteed to be
usable until a
certain point, which is after -u, and at the first file
loaded, i.e.
-c
If you open a buffer explicitly from inside .vimtest ,
then that's a
different story.
In my test case, buffer must exist, I am well passed the '-u ...'
phase because I can *see* the buffer when I do :set readable?'.
I think Yakov's test case is saying even more.
It's not clear that the buffer exists when the :set ro command is
read according to the -u option, though it might exist in some form
since no error occurs. Even if a buffer does exist at that time, I'm
fairly sure that is was transitory, and that it's not the same buffer
that you actually see and type :set ro? at.
Secondly, you need to be past the -c or similar stage, where it states
that files have been loaded. It doesn't say that for -u.
You *are* past the loading state when you type :set ro? , but that's
not the same as when the -u file is processed.
I don't know to that depth as you do, but then we should
agree that 'set readonly' in .vimrc is useless, because
it would never work, right?
This is hard to accept. So it looks more and more just as a bug.
---Zdenek
It's kinda bug-ish, but it's not a bug unless it's
contrary to stated
behavior. It'll be interesting to see how Bram addresses it.
I also think it is bug.
---Zdenek
On 5/23/06, Yakov Lerner [EMAIL PROTECTED] wrote:
On 5/23/06, Zdenek Sekera [EMAIL PROTECTED] wrote:
create a file ~/.vimtest as follows:
cat .vimtest
set nocompatible
set readonly
C-D
and execute (g)vim:
vim .vimtest -u .vimtest
try :set readonly? and you'll get 'noreadonly'.
The buffer does exist when initfile is executed. The ':ls'
in initfile shows it.
Adding more printouts to initfile shows interesting results:
vim -u 1 1
- file called 1 ---
set nocompatible
ls
call input('before set readonly 111')
set readonly
set readonly?
ls
set readonly?
set readonly?
echo readonly=.readonly
call input('after set readonly 222')
-
In vim, ':verb set readonly?' shows that readonly is
misteriously reset.
The output differs between vim6 and vim7.
--- vim7 output --
1 %1line 1
before set readonly 111
1 % = 1line 1
readonly=1
after set readonly 222
Note the missing output of ':set readonly?'!!! It prints neither
'readonly' nor 'noreadonly'.
- vim6 output
1 %1line 1
before set readonly 111
before set readonly 111
1 % = 1line 1
readonly
readonly
readonly=1
after set readonly 222
-
Looks like a bug to me.
Yakov
Re: Using py commands to evaluate text for balloon commands..
Yakov Lerner wrote: [...] Note that :py commands are not available in the sandbox. I dont know whether Balloon function is executed in the sandbox. Maybe it is not (then :py is available in the Balloon func), maybe it is (then :py is not available in the Balloon func). If you find out, I'm interested to hear your result. [...] Sandbox and balloon function issue was discussed ~5 month ago and vim was patched allowing bexpr to run non-sandbox commands _if_ it wasn't set in a modeline (this is so that bexpr could potentially get values from an external debugger or somewhere via Python/Perl extensions).
RE: set readonly - strange?
-Original Message-
From: Eric Arnold [mailto:[EMAIL PROTECTED]
Sent: 24 May 2006 12:38
To: Zdenek Sekera
Cc: vim-dev@vim.org
Subject: Re: set readonly - strange?
I think 'readonly' does not belong in the .vimrc since it is a
buffer-local-only option.
Yes, but I have only one buffer...
However, you can use an autocommand to set it. What are you really
trying to do from the .vimrc ? Setting the readonly value for the
default empty starting buffer seems odd, and you can manage the
reaonly property several ways for files actually loaded into buffers.
Clearly, my example was a case simplyfied to the utmost,
but describing what I really want to do: display a buffer
for reading only. My real '.vimtest' has many more options,
of course, so I thought I can this one into it as well
(just as I wanted 'modifiable', 'modified', and more).
This was to make things simple, start 'vim -u this that'.
Since that doesn't work for some of those settings, I'll
have to settle for another way like 'vim -R ...'.
I wanted to avoid any additional parameter on the vim call
(for some reasons), but I have to now change my mind.
You maybe right it doesn't belong to '.vimrc', but that's
not explicitly stated anywhere (and for others), hence
my trying and discovering a hole, perhaps a bug.
Wouldn't you think that it should apply always to at least
the first buffer on the vim call? Or all if it's in .vimrc?
The implementation is not clear IMHO, perhaps the doc needs
some update.
It will be indeed interesting to see what will Bram decide
about it. Let's wait.
---Zdenek
On 5/24/06, Zdenek Sekera [EMAIL PROTECTED] wrote:
-Original Message-
From: Eric Arnold [mailto:[EMAIL PROTECTED]
Sent: 24 May 2006 11:21
To: Zdenek Sekera
Cc: Yakov Lerner; vim-dev@vim.org
Subject: Re: set readonly - strange?
On 5/24/06, Zdenek Sekera [EMAIL PROTECTED] wrote:
-Original Message-
From: Eric Arnold [mailto:[EMAIL PROTECTED]
Sent: 23 May 2006 18:12
To: Yakov Lerner
Cc: Zdenek Sekera; vim-dev@vim.org
Subject: Re: set readonly - strange?
As far as I can tell, there are several instances
where there are
transitory buffers as vim is starting, opening a new
tab, probably
some in closing op.s.
That may be true, but...
I don't know if I used the right word by saying the buffer is
undefined, but I don't think it it's guaranteed to be
usable until a
certain point, which is after -u, and at the first file
loaded, i.e.
-c
If you open a buffer explicitly from inside .vimtest ,
then that's a
different story.
In my test case, buffer must exist, I am well passed
the '-u ...'
phase because I can *see* the buffer when I do :set readable?'.
I think Yakov's test case is saying even more.
It's not clear that the buffer exists when the :set ro
command is
read according to the -u option, though it might exist in
some form
since no error occurs. Even if a buffer does exist at
that time, I'm
fairly sure that is was transitory, and that it's not the
same buffer
that you actually see and type :set ro? at.
Secondly, you need to be past the -c or similar stage,
where it states
that files have been loaded. It doesn't say that for -u.
You *are* past the loading state when you type :set ro?
, but that's
not the same as when the -u file is processed.
I don't know to that depth as you do, but then we should
agree that 'set readonly' in .vimrc is useless, because
it would never work, right?
This is hard to accept. So it looks more and more just as a bug.
---Zdenek
It's kinda bug-ish, but it's not a bug unless it's
contrary to stated
behavior. It'll be interesting to see how Bram addresses it.
I also think it is bug.
---Zdenek
On 5/23/06, Yakov Lerner [EMAIL PROTECTED] wrote:
On 5/23/06, Zdenek Sekera [EMAIL PROTECTED] wrote:
create a file ~/.vimtest as follows:
cat .vimtest
set nocompatible
set readonly
C-D
and execute (g)vim:
vim .vimtest -u .vimtest
try :set readonly? and you'll get 'noreadonly'.
The buffer does exist when initfile is executed. The ':ls'
in initfile shows it.
Adding more printouts to initfile shows interesting results:
vim -u 1 1
- file called 1 ---
set nocompatible
ls
call input('before set readonly 111')
set readonly
set readonly?
ls
set readonly?
set readonly?
echo readonly=.readonly
call input('after set readonly 222')
-
In vim, ':verb set readonly?' shows that readonly is
misteriously reset.
The output differs between vim6 and vim7.
Re: set readonly - strange?
On 5/24/06, Eric Arnold [EMAIL PROTECTED] wrote: I think 'readonly' does not belong in the .vimrc since it is a buffer-local-only option. If you try to set any other buffer-local option in .vimrc, you'll see that it works just fine. I tried 'set tw=22' in file opened as 'vim -u file file' and it works just fine. Yakov
Re: set readonly - strange?
On 5/24/06, Yakov Lerner [EMAIL PROTECTED] wrote: On 5/24/06, Eric Arnold [EMAIL PROTECTED] wrote: I think 'readonly' does not belong in the .vimrc since it is a buffer-local-only option. If you try to set any other buffer-local option in .vimrc, you'll see that it works just fine. I tried 'set tw=22' in file opened as 'vim -u file file' and it works just fine. True. Don't know for sure exactly what's going on. However, if you use: set nocp echomsg '1 bufnr ' . bufnr(%) . ', bufname ' . bufname( bufnr(%) ) echomsg '1 bufloaded ' . bufloaded( bufnr(%) ) edit somefile echomsg '2 bufnr ' . bufnr(%) . ', bufname ' . bufname( bufnr(%) ) echomsg '2 bufloaded ' . bufloaded( bufnr(%) ) set tw=71 set ro The first echomsg shows that it does indeed think that the file from the command line is in a buffer, however, bufloaded() shows that it isn't loaded. For all I can tell, the first buffer was created by :badd and doesn't become loaded until .vimrc is finished (and maybe even later). So, there must be some difference about which options can be applied to a buffer before it is loaded.
Re: Pattern questions
On Tue, May 23, 2006 at 02:22:32PM +0200, Zdenek Sekera wrote:
if (char =~ '\m[;|?:[EMAIL PROTECTED]*(){}\\_+-[\]/\]')
do something
endif
2. why when the pattern ends with '+' or '\+' do I get
an error?
Can you be more specific? I tried
:let char = a
:echo char =~ '\m[;|?:[EMAIL PROTECTED]*(){}\\_+-[\]/\]+'
:echo char =~ '\m[;|?:[EMAIL PROTECTED]*(){}\\_+-[\]/\]\+'
and neither generated an error.
HTH --Benji Fisher
Re: please unsubscribe me
On Wed, May 24, 2006 at 12:33:50PM +0200, Ulrich Lauther wrote: As the automatic unsubscribing process does not seem to work and mail to [EMAIL PROTECTED] doesn't help either, could please some kind soul remove me from the list? I think that moving the vim mailing lists to a new server is on Bram's TODO list when he gets back from vacation. Until then, I do not think there is anyone who can help. I have not tested myself, but judging from your post and others, the mail admin is MIA. :-( --Benji Fisher
RE: Pattern questions
Hi, Benji
On Tue, May 23, 2006 at 02:22:32PM +0200, Zdenek Sekera wrote:
if (char =~ '\m[;|?:[EMAIL PROTECTED]*(){}\\_+-[\]/\]')
do something
endif
2. why when the pattern ends with '+' or '\+' do I get
an error?
Can you be more specific? I tried
:let char = a
:echo char =~ '\m[;|?:[EMAIL PROTECTED]*(){}\\_+-[\]/\]+'
:echo char =~ '\m[;|?:[EMAIL PROTECTED]*(){}\\_+-[\]/\]\+'
Sorry, I should have been clearer:
Note the placement of the '+' in my pattern, somewhere
in the middle, there it doesn't cause any problem:
if (char =~ '\m[;|?:[EMAIL PROTECTED]*(){}\\_+-[\]/\]'
^
| here
The erroneous (in my judgement) patterns are (e.g.) are these:
if (char =~ '\m[;|?:[EMAIL PROTECTED]*(){}\\_-[\]/\+]')
if (char =~ '\m[;|?:[EMAIL PROTECTED]*(){}\\_-[\]/\\+]')
So the question is why is it OK to have '+' in the middle
and not at the end?
---Zdenek
Re: Pattern questions
Zdenek Sekera wrote:
Sorry, I should have been clearer:
Note the placement of the '+' in my pattern, somewhere
in the middle, there it doesn't cause any problem:
if (char =~ '\m[;|?:[EMAIL PROTECTED]*(){}\\_+-[\]/\]'
^
| here
The erroneous (in my judgement) patterns are (e.g.) are these:
if (char =~ '\m[;|?:[EMAIL PROTECTED]*(){}\\_-[\]/\+]')
if (char =~ '\m[;|?:[EMAIL PROTECTED]*(){}\\_-[\]/\\+]')
So the question is why is it OK to have '+' in the middle
and not at the end?
It has nothing to do with +, and everything to do with - . The - is a
range character,
more commonly seen with something like [a-z] (which stands for all lower
case characters).
You need to escape the minus sign (ie. \-).
Regards,
Chip Campbell
RE: Pattern questions
-Original Message-
From: Charles E Campbell Jr [mailto:[EMAIL PROTECTED]
Sent: 24 May 2006 15:55
To: Zdenek Sekera
Cc: vim-dev@vim.org
Subject: Re: Pattern questions
Zdenek Sekera wrote:
Sorry, I should have been clearer:
Note the placement of the '+' in my pattern, somewhere
in the middle, there it doesn't cause any problem:
if (char =~ '\m[;|?:[EMAIL PROTECTED]*(){}\\_+-[\]/\]'
^
| here
The erroneous (in my judgement) patterns are (e.g.) are these:
if (char =~ '\m[;|?:[EMAIL PROTECTED]*(){}\\_-[\]/\+]')
if (char =~ '\m[;|?:[EMAIL PROTECTED]*(){}\\_-[\]/\\+]')
So the question is why is it OK to have '+' in the middle
and not at the end?
It has nothing to do with +, and everything to do with - .
The - is a
range character,
more commonly seen with something like [a-z] (which stands
for all lower
case characters).
You need to escape the minus sign (ie. \-).
Ops, I missed that one. Obvious! Thanks.
---Zdenek
Re: [EMAIL PROTECTED]: vim7: formatoptions]
Benji Fisher wrote: Did you notice this thread on vim-dev? - Forwarded message from Thomas [EMAIL PROTECTED] - To: vim-dev@vim.org From: Thomas [EMAIL PROTECTED] Subject: vim7: formatoptions Date: Fri, 19 May 2006 13:48:51 +0200 I just realized that editing a directory removes t from formatoptions. E.g. set formatoptions+=rw fo = tcqrw e Foo fo = tcqrw e . fo = cqrw e Bar fo = cqrw This doesn't happen with the --noplugin switch so I'd assume that some standard vim plugin is causing this -- maybe netrw? Can somebody verify this? Netrw attempted to issue a warning about this problem, but apparently it gets wiped out before being seen. These two settings were problematical; I originally caught them as causing problems with the pluginkiller. The problem: netrw would hang. Anyway, I think I've worked around the two settings (fo=...ta...). Now, I must admit that I haven't done a comprehensive test of netrw and all its features with these two settings active. Please try the netrw v100j from my website: http://mysite.verizon.net/astronaut/vim/index.html#VimFuncs , see Network Oriented Reading, Writing, and Browsing. Regards, Chip Campbell
Re: netrw, winxp, and a problem...
A.J.Mechelynck wrote: Charles E Campbell Jr wrote: Hello, Tony! I've had several folks having a problem with WinXP and netrw. The problems seem to involve temporary files during attempts to use ftp; since temporary filenames are produced by tempname(), they're o/s dependent. Admittedly without having searched the source, I figure that these temporary files are in fact produced by the C function tmpnam() -- hmm, I did just do that search, and tmpnam() is used. Since that's a C-library function, these temporary files are presumably not only o/s dependent but compiler dependent. I generally compile my own vim using cygwin+gcc for Windows. I've never seen the problems these folks are having. So, last night I downloaded a copy of your compiled vim (7.0aa, perhaps patched to 213? - I don't recall exactly). I also installed my latest netrw, and used it in a dos (cmd.exe) window, and furthermore used vim -u NONE (also, set nocp and :so ..path-to-netrwPlugin.vim). I was hoping to finally see these problems, but I still was able to do remote browsing, readwrite and NreadNwrite without any problems. So, have you had any issues with remote browsing/ftp with netrw? Do you have any suspicions as to what the problem might be? What compiler do you use? Thank you, Chip Campbell Sorry, Dr. Chip, I can't help you there so I'm referring you to the vim-dev list: 1. As a rule, I don't edit over ftp, I edit my files locally and, when I'm satisfied with the result, I upload them with any available ftp client. If I want to make sure that my files look all right, I browse them with my favourite web browser (both locally with file: and remotely with http: or ftp; ) In essence, that's what netrw supports. Creation and opening of a temporary zero-length file with a unique name in a given directory is a well-documented system call on Dos-like systems; I wouldn't expect it to be compiler-dependent since the OS explicitly provides it. (I'm not familiar with specific Windows calls but there is a Dos system call for it since Dos 3 or maybe earlier.) I believe that cygwin does it differently, but even so, there's a possible compiler dependency concerning which directory the temporary file is made. If it works OK with your latest version of netrw, then maybe the trouble is that the version of netrw distributed with Vim 7.0 is _not_ the latest one? The latest is v100j, which I've just uploaded to my website. The distributed version is, alas, always likely to not be the latest one, except for a short window of time... Thank you, Chip Campbell
Regression in gvim 7.0.00x
Hello,
I've been observing a regression on gvim since the release of vim 7.0.
I'm observing it on gvim 7.0.000 on windows, gvim 7.0.015 (or 17, I do
not remember) on Linux (gui=GTK2/Athena). It seems I do not have it with
the console version on Linux -- I haven't had the opportunity to test
the following lines of code with the console version.
I don't remember the problem on gvim 7.0e (at least I do not have it on
vim 7.0a on windows)
The problem consists in the combination of a few things:
- a nmapping selects (as in select-mode) a few characters
- an imapping calls a function (through i_CTRL-R) that executes the
previous mapping with :normal, and then returns \esc to terminate
the INSERT-SELECT mode and finish in select-mode.
Here are a few VimL lines that reproduce the problems.
Go in insert mode and type !exp!, Three lines are inserted, and
toto should be selected. It is not anymore
Hitting !jp! in normal-mode, or in insert-mode, selects toto as
expected.
Note: I have found a VimL workaround by returning
\c-\\c-n\c-\\c-ngv\c-g from I_expand_n_jump().
But there is still a regression I cannot explain.
--- %
function! N_jump()
call search('toto')
let select = 'v' . virtcol('.').'|o'
if selection == 'exclusive' | let select = select . 'l' | endif
call search('toto\zs')
return select.\c-g
endfunction
nnoremap !jp! @=N_jump()cr
imap !jp! c-\c-n!jp!
function! I_expand_n_jump()
let str = toto\ntiti\ntutu
let l = line('.')
put=str
exe l
normal !jp!
return \esc\right
endfunction
inoremap !exp! c-r=I_expand_n_jump()cr
--- %
--
Luc Hermitte
http://hermitte.free.fr/vim/
Re: netrw, winxp, and a problem...
On Wed, 2006-05-24 at 12:04 -0400, Charles E Campbell Jr wrote: A.J.Mechelynck wrote: Charles E Campbell Jr wrote: I've had several folks having a problem with WinXP and netrw. The problems seem to involve temporary files during attempts to use ftp; since temporary filenames are produced by tempname(), they're o/s dependent. [snip] Sorry, Dr. Chip, I can't help you there so I'm referring you to the vim-dev list: I might be completely off the trail here, but this sounds suspiciously like my age old problem of using Vim-generated paths for Windows calls via system(), tempname() or the like. No matter how hard I've tried to maintain a Windows path in a var, it somehow always ends up with an escaped space or a forward slash. (It seems use of fnamemodify() or expand() resets them.) So a long time ago I gave up trying to keep slashes and backslashes straight in my variables in favor of a wrapper approach: let tmp = myvar system call prep if has(win32) remove trailing slash (Win95) let tmp = substitute(tmp, '\(\\\|/\)$', '', 'g') remove escaped spaces let tmp = substitute(tmp, '\ ', ' ', 'g') convert slashes to backslashes let tmp = substitute(tmp, '/', '\', 'g') endif set noshellslash call system(mkdir . '' . tmp . '') set shellslash Just assume all paths are Windows-hostile unless passed through such a wrapper. (I never see these errors on *nix, so I assume it's path related.) Unfortunately, it is difficult to make such a strategy reasonably modular since you want to maintain the space between the command, options and the final path-filename argument. Abstracting the path through one more function ends up confusing me more than just duplicating the wrapper where needed. You guys are both old pros, but I've been bushwhacked by this one so many times I figured I'd encourage you to take one more gander. -- Steve Hall [ digitect mindspring com ] :: Cream... something good to put in your Vim! :: http://cream.sourceforge.net
