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
Re: viminfo feature not working after upgrade from vim6.2-vim7.0
Hi James , Mechelynck and Bram, What do you mean by code snippet here ?. Why is it not automatically not working in vim7.0. Why should there be extra work to be done ? Thanks, Srini... On Tue, 2006-05-23 at 17:50, James Vega wrote: On Tue, May 23, 2006 at 05:30:37PM +0530, Srinivas Rao. M wrote: Hi, When i upgraded my vim from vim6.2 to vim7.0, i am finding that the feature viminfo is not working. (Viminfo remembers last position in the file when we reopen file). I had set the viminfo option in my .vimrc file as. set viminfo='1000,f1,\500 Do i have to add any special options for vim7 ?. That feature isn't an option that's set, but an autocommand that is run. It was probably in your system-wide vimrc before you upgraded. You can add the code snippet at :help last-position-jump to your .vimrc to re-enable that behavior. James
rdfinable boudaries of sections, paragraphs
vim still doesn't have redefinable (per filetype) boundaries (like, regexp) for sections, paragraphs (and other text objects and motions), correct ? Yakov
Re: rdfinable boudaries of sections, paragraphs
I haven't used them, but Vim has options for 'paragraphs' , 'options', etc. They are global, but could be set by file type. They accept NROFF syntax instead of regex, so I don't know whether that's good enough or not. On 5/24/06, Yakov Lerner [EMAIL PROTECTED] wrote: vim still doesn't have redefinable (per filetype) boundaries (like, regexp) for sections, paragraphs (and other text objects and motions), correct ? Yakov
RE: How to get cygwin command line to know where it is - seems okay now
All the suggestions worked. 1. I put everything in .bash_profile (just easier) 2. I have the following statements in my _vimrc set shell=C:/cygwin/bin/bash set shellxquote=\ set shellcmdflag=-c let $BASH_ENV='~/.bash_profile -Original Message- From: A.J.Mechelynck [mailto:[EMAIL PROTECTED] Sent: Tuesday, May 23, 2006 7:06 PM To: Gerald Lai Cc: Eric Arnold; Furash Gary; Gary Johnson; vim@vim.org Subject: Re: How to get cygwin command line to know where it is Gerald Lai wrote: On Wed, 24 May 2006, A.J.Mechelynck wrote: Eric Arnold wrote: Off hand, I can't remember the exact name, but I think that there is a special rc filename that is executed even when it isn't a login shell. [...] Yes, I think so too, and I don't remember it offhand either, but man bash (which is quite long for a manpage) will tell you. Perhaps it's called .bashenv? Not sure. I use ZSH. It's equivalent is .zshenv. -- Gerald As said under INVOCATION in the bash manpage: Login shell: /etc/profile (if found), then the first one (if any) found readable among ~/.bash_profile, ~/.bash_login, ~/.profile (all this unless --noprofile). At exit: ~/.bash_logout (if found). Non-login interactive shell: ~/.bashrc (if found) unless --norc Non-interactive shell: does as if executing if [ -n BASH_ENV ]; then . $BASH_ENV; fi but doesn't search the $PATH There are more details about what bash does when invoked as sh, when invoked in posix mode, when invoked by the remote shell daemon, or when invoked in suid mode. Under FILES, two additional files (for readline initialization) are mentioned. Best regards, Tony.
Line Numbers
In my old VIM version (5.4) I could put the line set nu in my .exrc file and have line numbers on the file I was editing. Since I upgraded to VIM 7.0, I've discovered no option for the .vimrc file to do the same thing. Have I missed something? Joel
Re: Line Numbers
In my old VIM version (5.4) I could put the line set nu in my .exrc file and have line numbers on the file I was editing. Since I upgraded to VIM 7.0, I've discovered no option for the .vimrc file to do the same thing. Have I missed something? Putting the set nu in your vimrc *should* do exactly as you expect. However, some plugin or something of the sort may be changing the setting later in the course of startup. You can try :verbose set nu? from the command line after starting up, and it should tell you from whence it was last set. If it's not your vimrc (which it *should* be), it should indicate what's happening. Another remote possibility is that, with vim7, there's a 'numberwidth' setting that controls the width of the column in which the line-numbers are displayed. You might have this set to its minimum of 1 perhaps? To demonstrate that it *should* work, you can create a file called vimrc_justnumber, containing the single line set nu, and then start vim with vim -u vimrc_justnumber which should use this custom vimrc and set *only* that one option. HTH, -tim
Re: viminfo feature not working after upgrade from vim6.2-vim7.0
On Wed, 24 May 2006, Srinivas Rao. M wrote: Thanks Tony, It works after adding those 4 lines into my ~/.vimrc. But i never used to do this in my older version of vim6.3. How come it used to work then ? It may be a possibility but check your system-wide .vimrc at /etc/vimrc for when you had the old 6.3 version. I know mine has the 4 lines that would make Vim remember the last cursor position. -- Gerald
vim7: broken bar separator after user commands
This was working fine in Vim6.3, but in Vim7 I get E488. Here is how to reproduce: :command! TT :echo TT :TT | TT You get: E488: Trailing characters Looks like the user commands can't be followed by other commands anymore. -- Thanks, Hari __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Re: vim7: broken bar separator after user commands
Hi Hari, On 5/24/06, Hari Krishna Dara [EMAIL PROTECTED] wrote: This was working fine in Vim6.3, but in Vim7 I get E488. Here is how to reproduce: :command! TT :echo TT :TT | TT You get: E488: Trailing characters Looks like the user commands can't be followed by other commands anymore. You should use the -bar argument to :command: :command! -bar TT :echo TT - Yegappan
Re: vim7: broken bar separator after user commands
On Wed, 24 May 2006 at 2:37pm, Yegappan Lakshmanan wrote: Hi Hari, On 5/24/06, Hari Krishna Dara [EMAIL PROTECTED] wrote: This was working fine in Vim6.3, but in Vim7 I get E488. Here is how to reproduce: :command! TT :echo TT :TT | TT You get: E488: Trailing characters Looks like the user commands can't be followed by other commands anymore. You should use the -bar argument to :command: :command! -bar TT :echo TT - Yegappan The -bar option is different. It just says that | in the arguments should be treated as an argument (not as a command separator). Without -bar option, the | character should really act as a command separator. If you run the above exact test in Vim 6.3, you don't get this error and it works really as a command separator. -- Thanks, Hari __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Re: vim7: broken bar separator after user commands
Hari Krishna Dara wrote: On Wed, 24 May 2006 at 2:37pm, Yegappan Lakshmanan wrote: Hi Hari, On 5/24/06, Hari Krishna Dara [EMAIL PROTECTED] wrote: This was working fine in Vim6.3, but in Vim7 I get E488. Here is how to reproduce: :command! TT :echo TT :TT | TT You get: E488: Trailing characters Looks like the user commands can't be followed by other commands anymore. You should use the -bar argument to :command: :command! -bar TT :echo TT - Yegappan The -bar option is different. It just says that | in the arguments should be treated as an argument (not as a command separator). Without -bar option, the | character should really act as a command separator. If you run the above exact test in Vim 6.3, you don't get this error and it works really as a command separator. You have it backwards, see :help E177 and scroll down by 24 lines. -bar in the arguments means that a bar can be used to separate the newly-defined command from a subsequent command. Without -bar, a bar, if present, and whatever follows it, are understood as part of the argument string. IIRC, it was aleeady like this in 6.1 Best regards, Tony.
Please help
Dear all I have a very large file containing 7000 lines of data in a single column. Below is a sample. Many of them are 7 digit numbers and others are 8 digit numbers. For those 7 digit numbers, I need to add number 0 at the beginning of it. Can someone please show me a command to do it all in one hit? Those 7 digits numbers have no regular patterns, except that they have 7 digits, and the order of all numbers in the column has to remain unchanged. Your help is greatly appreciated. 21520041 21520041 1210050 1210080 1210080 1690061 1210080 11210080 21510011 Kind regards tien
Re: Please help
On 5/24/06, Tien Pham [EMAIL PROTECTED] wrote:
Dear all
I have a very large file containing 7000 lines of data in a single column.
Below is a sample. Many of them are 7 digit numbers and others are 8 digit
numbers. For those 7 digit numbers, I need to add number 0 at the beginning
of it. Can someone please show me a command to do it all in one hit? Those
7 digits numbers have no regular patterns, except that they have 7 digits,
and the order of all numbers in the column has to remain unchanged.
Can't you simply replace seven digits surrounded by new lines?
Something like this:
:%s/^\(\d\{7\}\n\)/0\1/
Hope this helps,
Ricky
Re: Please help
On 2006-05-25, Tien Pham [EMAIL PROTECTED] wrote:
Dear all
I have a very large file containing 7000 lines of data in a single column.
Below is a sample. Many of them are 7 digit numbers and others are 8 digit
numbers. For those 7 digit numbers, I need to add number 0 at the beginning
of it. Can someone please show me a command to do it all in one hit? Those
7 digits numbers have no regular patterns, except that they have 7 digits,
and the order of all numbers in the column has to remain unchanged.
g/^\d\{7}$/s/^/0/
HTH,
Gary
--
Gary Johnson | Agilent Technologies
[EMAIL PROTECTED] | Wireless Division
| Spokane, Washington, USA
Re: Please help
On Thu, 2006-05-25 at 10:55 +1000, Tien Pham wrote: I have a very large file containing 7000 lines of data in a single column. Below is a sample. Many of them are 7 digit numbers and others are 8 digit numbers. For those 7 digit numbers, I need to add number 0 at the beginning of it. Can someone please show me a command to do it all in one hit? Those 7 digits numbers have no regular patterns, except that they have 7 digits, and the order of all numbers in the column has to remain unchanged. %s/^\(\d\d\d\d\d\d\d\)$/0\1/ge See :help :substitute :help pattern-overview -- Steve Hall [ digitect mindspring com ] :: Cream... something good to put in your Vim! :: http://cream.sourceforge.net
Re: Please help
Hi Ricky, Pete, Gary and Alan
Wonderful, thanks all of you very much for your kind and prompt help. It
works very well Pete.
Regards
tien
At 11:07 AM 25/05/2006 +1000, Pete Johns wrote:
On Thu, 2006-05-25 at 10:55:51 +1000, Tien Pham sent:
Dear all
Hi Tien
I have a very large file containing 7000 lines of data in a
single column. Below is a sample. Many of them are 7 digit
numbers and others are 8 digit numbers. For those 7 digit
numbers, I need to add number 0 at the beginning of it. Can
someone please show me a command to do it all in one hit? Those
7 digits numbers have no regular patterns, except that they have
7 digits, and the order of all numbers in the column has to
remain unchanged.
:%s/^\d\{7}$/0/
On every line that has exactly seven digits replace the match
with a zero followed by the entire match.
See :help :s
Your help is greatly appreciated.
You're very welcome;
--paj
--
Pete Johns http://johnsy.com/
Tel/Fax numbers and IM information http://johnsy.com/contact/
Road Tripping Storyhttp://johnsy.com/20060522123211
Re: vim7: broken bar separator after user commands
On Thu, 25 May 2006 at 1:33am, A.J.Mechelynck wrote: Hari Krishna Dara wrote: On Wed, 24 May 2006 at 2:37pm, Yegappan Lakshmanan wrote: Hi Hari, On 5/24/06, Hari Krishna Dara [EMAIL PROTECTED] wrote: This was working fine in Vim6.3, but in Vim7 I get E488. Here is how to reproduce: :command! TT :echo TT :TT | TT You get: E488: Trailing characters Looks like the user commands can't be followed by other commands anymore. You should use the -bar argument to :command: :command! -bar TT :echo TT - Yegappan The -bar option is different. It just says that | in the arguments should be treated as an argument (not as a command separator). Without -bar option, the | character should really act as a command separator. If you run the above exact test in Vim 6.3, you don't get this error and it works really as a command separator. You have it backwards, see :help E177 and scroll down by 24 lines. -bar in the arguments means that a bar can be used to separate the newly-defined command from a subsequent command. Without -bar, a bar, if present, and whatever follows it, are understood as part of the argument string. IIRC, it was aleeady like this in 6.1 Best regards, Tony. You are right, I got it backwards. It looks like this was a bug in 6.3 that allowed me to use bar with out the -bar option. In fact, it may be that what is after the | was totally ignored, and I didn't really observe the difference (it was just a refresh). Thanks for the clarification. -- Thanks, Hari __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Working directory problems
Hi, I have some issues with the working directory in vim that I really cannot get to the bottom of. I have tried looking through the help, and I've searched the Interweb too, to no avail, so I thought I would turn to this trusty mailing list! I operate a single vim instance with multiple files open in multiple splits. The common working directory for my code files is c:\project\main\source\, and the majority of the files therein lie in ai\filename. Normally the vim split status line shows the file as being ai\filename, namely the relative path from the working directory of c:\project\main\source\. When I open a new file - which I invariably do using sf filename, as I have all the appropriate directories in my path - occasionally the statusline shows as the absolute path, namely c:\project\main\source\ai\filename. If I perform the command cd c:\project\main\source, then the status line fixes itself. It should be noted that the status line is only incorrect for the new file; existing files are still fine. Now I wouldn't normally be bothered by this, but I have a function in vim which I have bound to F6 that will check the current source file out of our source depot, and if the status line is showing the absolute path then it will fail, because the information about the source depot lies only within the c:\project\main directories. God, I hope that makes sense. It seems like such a trivial problem, but it really irks me, and I wonder if anyone could give me a hand! Cheers, Max -- Max Dyckhoff AI Engineer Bungie Studios
Re: Working directory problems
I'm not sure how your bound function works. Have you tried using fnamemodify() to manipulate the filename? You can use the :h option to strip the path, and :s?? to substitute the relative path. On 5/24/06, Max Dyckhoff [EMAIL PROTECTED] wrote: Hi, I have some issues with the working directory in vim that I really cannot get to the bottom of. I have tried looking through the help, and I've searched the Interweb too, to no avail, so I thought I would turn to this trusty mailing list! I operate a single vim instance with multiple files open in multiple splits. The common working directory for my code files is c:\project\main\source\, and the majority of the files therein lie in ai\filename. Normally the vim split status line shows the file as being ai\filename, namely the relative path from the working directory of c:\project\main\source\. When I open a new file - which I invariably do using sf filename, as I have all the appropriate directories in my path - occasionally the statusline shows as the absolute path, namely c:\project\main\source\ai\filename. If I perform the command cd c:\project\main\source, then the status line fixes itself. It should be noted that the status line is only incorrect for the new file; existing files are still fine. Now I wouldn't normally be bothered by this, but I have a function in vim which I have bound to F6 that will check the current source file out of our source depot, and if the status line is showing the absolute path then it will fail, because the information about the source depot lies only within the c:\project\main directories. God, I hope that makes sense. It seems like such a trivial problem, but it really irks me, and I wonder if anyone could give me a hand! Cheers, Max -- Max Dyckhoff AI Engineer Bungie Studios
