Search first character in a file

24 views
Skip to first unread message

Cristian

unread,
Jan 21, 2026, 8:58:56 AM (yesterday) Jan 21
to vim_use
Hello all,

1. I have this file:

--- begin testfile.txt ---
a
a
a
b
--- end testfile.txt ---

2. I run the command:

$ vim testfile.txt

3. Inside when the cursor is positioned on the first character I type:
/a<ENTER>

The first "a" is not found. Unless I type "n" until I get to the end of the file and then another "n".

Is it possible to search the first character in the file immediately after you open the file?
Is this a bug or a design decision ?

Thank you.
Cristian 



Tony Mechelynck

unread,
Jan 21, 2026, 9:04:53 AM (yesterday) Jan 21
to vim...@googlegroups.com
I think it's a feature, not a bug: if by hitting n when the cursor is
on a match, you wouldn't make it move, then repeatedly hitting n would
never move the cursor. To find the first a when already on it, then
hit n followed by N. By doing that when not on a match, you would find
the last match, however.

Best regards,
Tony.

Tim Chase

unread,
Jan 21, 2026, 9:08:42 AM (yesterday) Jan 21
to vim...@googlegroups.com
On 2026-01-21 05:57, Cristian wrote:
> --- begin testfile.txt ---
> a
> a
> a
> b
> --- end testfile.txt ---
[snip]
> 3. Inside when the cursor is positioned on the first character I type:
> /a<ENTER>
>
> The first "a" is not found. Unless I type "n" until I get to the end of the
> file and then another "n".
>
> Is it possible to search the first character in the file immediately after
> you open the file?

Typically the way I've resolved this is to start the search from the
last line (as long as 'wrapscan' is set, which it is by default so you'd
only need to mess with it if you've unset it explicitly)

:set wrapscan
:$/a

> Is this a bug or a design decision ?

As Tony notes, I'm pretty sure this was a design decision because it
starts the search after the cursor so you don't just keep finding the
same thing.

-tim
--





Cristian

unread,
Jan 21, 2026, 10:21:27 AM (yesterday) Jan 21
to vim_use

Thank you for the explanation — that makes sense for the behavior of the n key.

That said, I was wondering whether, for the initial search (the one
NOT triggered by n), it might also be reasonable for vi to start
searching from the character currently under the cursor.

This could make the behavior a bit more intuitive when the cursor
is already on a match.

Best regards,
Cristian

Doug Kearns

unread,
7:04 AM (9 hours ago) 7:04 AM
to vim...@googlegroups.com
On Thu, 22 Jan 2026 at 02:21, Cristian <cristia...@gmail.com> wrote:
>
>
> Thank you for the explanation — that makes sense for the behavior of the n key.
>
> That said, I was wondering whether, for the initial search (the one
> NOT triggered by n), it might also be reasonable for vi to start
> searching from the character currently under the cursor.

As others have pointed out, the behaviour is fundamental[1].

> This could make the behavior a bit more intuitive when the cursor
> is already on a match.

I think your intuition is incorrect. You wouldn't expect 'w', for
example, not to move to the next word because the cursor was already
at the start of a word.

You can think of '/' as executing something like :let @/ = 'pattern' | normal! n

The best solution, if you don't want to adjust to how it works, is
probably to remap '/' to a user function that calls search('pattern',
'c') and sets the '@/' register. Anything else, like :-;/pattern,
won't work well for multiple matches per line.

Regards,
Doug

1. https://pubs.opengroup.org/onlinepubs/9799919799/utilities/vi.html#tag_20_146_13_36
Reply all
Reply to author
Forward
0 new messages