"/text-to-find" and "/text-to-find/" can be used to find strings. Commands
such as "n", etc., can be used to find next or preceding occurrences.
But, how can one find, not the first occurrence, not the next occurrence,
but, say the 173rd occurrence of a string?
Thank you.
--
David Grove
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
"I think not," said Descartes, and disappeared.
>I have consulted the O'Reilly VI book, as well as some web sites. I have
>also done some experimentation, and can't solve the problem.
>
>"/text-to-find" and "/text-to-find/" can be used to find strings. Commands
>such as "n", etc., can be used to find next or preceding occurrences.
>
>But, how can one find, not the first occurrence, not the next occurrence,
>but, say the 173rd occurrence of a string?
/text-to-find<enter>
172n
The first line finds the first occurrance. The second one finds the 172nd
one after that. Most vi commands allow repeat counts like that.
--
- Tim Roberts, ti...@probo.com
Providenza & Boekelheide, Inc.
One possible approach is:
ma/text-to-find
o^[0D173in^[0"ay$dd`a@a
Translation:
ma - mark location with label a
/text-to-find - find the first occurrence from the current location
o^[ - open a new blank line, followed by ESC
0D - delete any leading whitespace
173in^[ - insert 173 'n's, followed by ESC
0"ay$ - yank the 'n's into register a
dd - delete the 'n's
`a - jump back to the marked location
@a - invoke the contents of register a as a macro
Regards,
-- James
--
vi Reference: http://www.ungerhu.com/jxh/vi.html
If the registers in your vi cannot handle the 173 character input,
you can alter that step to some convenient multiple. Perhaps 86, in
this case. After the first @a, you can use @@ to jump to the 172nd
occurrence, and then use n to move to the 173rd.
ma/text-to-find
o^[0D86in^[0"ay$dd`a@a@@n
> o^[ - open a new blank line, followed by ESC
> 0D - delete any leading whitespace
I do this to make my vi maps work in vim also, but I wasn't
aware that you needed this for vi. In vim, nvi and HP-UX vi
any indent added by o when autoindent is set is removed when
ESC is pressed. Is it different on the version you are using?
Antony
Not on the one I am using at the moment. (At this moment, I am using
"Version 3.7, 6/7/85 (gritter) 9/3/03", which is essentially the stock
ex/vi available for download from BerliOS, with some minor modifications
for Cygwin).
I'm curious: why do you do it to make your vi maps work in vim when you
just pointed out it is unneeded?
I don't use autoindent, so when I first wrote the example, I didn't have
a 0D step. But, autoindent occurred to me just before I was about to
post, so I added it without testing. (To be fair to myself, I *did*
test to make sure the change would work, but I didn't observe the
behavior of each step, I just invoked the whole thing as a macro.)
I guess I could have done:
ma/text-to-find
o^[86in^[^"ay$dd`a@a@@n
That was one of the first things I tried.
No response: I just get a beep, like hitting ESC when already in command
mode.
I'm on a small SUN server (E250, I think) running Solaris 8.
DG
"Tim Roberts" <ti...@probo.com> wrote in message
news:etm3qvogagj51jf01...@4ax.com...
I tried it, and it works fine for "l;ow numbers". For example, I can find
the 100th occurrence easily. But, I had made up the number I used as an
example in my original question. I am actually rooting through a long SQL
script, and need to find the 2,383rd occurrence of the string, "CREATE
PROCEDURE". Unfortunately, the register size limit is somewhere between 100
and 150.
I will try to see if I can use a macro to execute another macro (create
another macro, call it "b". Have "b" contain "@a" multiple times, etc.)
DG
"James Hu" <j...@despammed.com> wrote in message
news:VrydnU5CL9n...@comcast.com...
That should work.
I might suggest a different approach for what seems to be a very large
text file. If the "CREATE PROCEDURE" pattern always appears on a
separate line, then you can try something along the lines of:
cat -n script.sql | grep "CREATE PROCEDURE" | head -2383 | tail -1
The output should tell you the line number of the 2383rd occurrence.
"James Hu" <j...@despammed.com> wrote in message
news:b33486ef.03103...@posting.google.com...
I decided to implement your idea...
" ---------------
" Powers of 10 for n and N commands.
" Clobbers mark label a.
" Uses registers a, b, c, and d.
" As written, requires \2[nN] to be invoked before \3[nN] can be used.
" --
map \0n n
map \0N N
map \1n nnnnnnnnnn
map \1N NNNNNNNNNN
map \2n ma:map \2n @a^Mo^[100in^[0"ad$dd`a@a
map \2N ma:map \2N @b^Mo^[100iN^[0"bd$dd`a@b
map \3n ma:map \3n @c^Mo^[10i@a^[0"cd$dd`a@c
map \3N ma:map \3N @d^Mo^[10i@b^[0"dd$dd`a@d
Now, to reach pattern occurrence 2383:
ma/text-to-find
`a\2n\2n\2n\2n\1N\1N\3n\3nnnn
> On 2003-10-31, Antony <ad_sc...@postmaster.co.uk> wrote:
> > James Hu wrote:
> >
> > > o^[ - open a new blank line, followed by ESC
> > > 0D - delete any leading whitespace
> >
> > I do this to make my vi maps work in vim also, but I
> > wasn't aware that you needed this for vi. In vim, nvi
> > and HP-UX vi any indent added by o when autoindent is
> > set is removed when ESC is pressed.
> [...]
>
> I'm curious: why do you do it to make your vi maps work
> in vim when you just pointed out it is unneeded?
Because I have vim set up to automatically insert the
comment leader if appropriate when pressing `o'. In this
case an indent after the comment leader is removed on
hitting <Esc> but not the comment leader.
> I don't use autoindent,
I guess you pipe code through indent then, but I'd still
find it a bit annoying personally. Are there occasions where
having autoindent set would cause problems for you?
Antony
>On 2003-10-31, David E. Grove <david...@correct.state.ak.us> wrote:
>> "/text-to-find" and "/text-to-find/" can be used to find strings.
>> Commands such as "n", etc., can be used to find next or preceding
>> occurrences.
>>
>> But, how can one find, not the first occurrence, not the next
>> occurrence, but, say the 173rd occurrence of a string?
>
>One possible approach is:
>
>ma/text-to-find
>o^[0D173in^[0"ay$dd`a@a
Help me understand what possible benefit your suggestion has over this much
easier to understand alternative:
/text-to-find
172n
> James Hu <j...@despammed.com> wrote:
>
> > On 2003-10-31, David E. Grove
> > <david...@correct.state.ak.us> wrote:
> > > "/text-to-find" and "/text-to-find/" can be used to
> > > find strings. Commands such as "n", etc., can be used
> > > to find next or preceding occurrences.
> > >
> > > But, how can one find, not the first occurrence, not
> > > the next occurrence, but, say the 173rd occurrence of
> > > a string?
> >
> > One possible approach is:
> >
> > ma/text-to-find o^[0D173in^[0"ay$dd`a@a
>
> Help me understand what possible benefit your suggestion
> has over this much easier to understand alternative:
> /text-to-find
> 172n
Now, that would be a vim solution, certainly.
Antony
The benefit is that works in vi. Your solution would only work in a
vi clone that supported that extension.
Regards,
-- James
I too often want to place text on a different column position
than where autoindent places the cursor, which causes me to
hit strange key sequences to change the column.
Why does it cause me to hit strange key sequences? Because in
vi, if the leading whitespace is inserted by autoindent, you can
use ^D to remove it. But, if you started the indentation of
a newline manually, you can't use ^D. You have to use backspace.
Then, if the whitespace was already there and you are appending,
and then you change your mind and want to go back an indentation
level, you can't use either ^D or backspace. You have to hit ESC
and use x.
So, I typically find myself using the single technique that works
all the time, which is to hit ESC, remove the whitespace, and then
resume appending text. Since I found it annoying to hit ESC all
the time, I just opted to not enable autoindent.
-- James
> On 2003-11-01, Antony <ad_sc...@postmaster.co.uk> wrote:
> > James Hu wrote:
> >
> > > I don't use autoindent,
> >
> > [why?]
>
> I too often want to place text on a different column
> position than where autoindent places the cursor, which
> causes me to hit strange key sequences to change the
> column.
>
> [detail snipped]
Thanks for the explanation, James. That makes sense.
Antony
> On 2003-10-31, James Hu <j...@despammed.com> wrote:
> > On 2003-10-31, David E. Grove
> > <david...@correct.state.ak.us> wrote:
> > > "/text-to-find" and "/text-to-find/" can be used to
> > > find strings. Commands such as "n", etc., can be used
> > > to find next or preceding occurrences.
> > >
> > > But, how can one find, not the first occurrence, not
> > > the next occurrence, but, say the 173rd occurrence of
> > > a string?
> >
> >
> > ma/text-to-find o^[0D173in^[0"ay$dd`a@a
>
> If the registers in your vi cannot handle the 173
> character input, you can alter that step to some
> convenient multiple. Perhaps 86, in this case. After
> the first @a, you can use @@ to jump to the 172nd
> occurrence, and then use n to move to the 173rd.
Just for the record, in HP-UX vi with a buffer containing
0123456789
as the only line, and with the cursor on the zero
/[0-9]
nnnn
leaves the cursor on `5' as you would expect.
0:map K n
KKKKK
also leaves the cursor on `5'.
0:map K nn
+ Pattern not found
(+ indicates a response from vi; I'm trying to find a
character that google won't mess about with.) Now, you think
that's weird?
on<Escape>
"ay$1G@a@@@@@@@@
leaves the cursor on `5' -- fine.
onn<Escape>
0"ay$1G@a
+ /n
leaves the cursor on the first `n' in the buffer. Truly
bizarre.
:version
+ HP Version 78.2.1.8 $ 32-bit NLS $
While I'm on the subject `;' inside macros sometimes works,
sometimes doesn't.
Antony
(vi has bugs? -- surprise.)
[...]
> 0:map K nn
> + Pattern not found
I am assuming you tried to hit K a couple of times.
Solaris vi and BerliOS vi doesn't have this problem.
> onn<Escape>
> 0"ay$1G@a
> + /n
>
> leaves the cursor on the first `n' in the buffer. Truly
> bizarre.
Solaris vi and BerliOS vi doesn't have this problem.
> :version
> + HP Version 78.2.1.8 $ 32-bit NLS $
Version SVR4.0, Solaris 2.5.0
Version 3.7, 6/7/85 (gritter) 9/3/03
> While I'm on the subject `;' inside macros sometimes works,
> sometimes doesn't.
The ';' inside a macro will not work for t and T, as repeating
the command yields the same position. So ';' will only move
the cursor for f and F if there is something to move to. If
there is nothing to move to, the failed ';' will interrupt the
macro, and the rest of the macro won't get processed.
I cannot confirm the "sometimes doesn't" for Solaris vi and
BerliOS vi. It seems to always work for the simple testing I
have done so far, modulo the caveats indicated above.
> (vi has bugs? -- surprise.)
Maybe you should stick with a vi clone, vi isn't for wimps :-).
-- James