Search first character in a file

[Cristian]

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]

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]

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]

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]

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

[Eric Marceau]

Cristian,

The "n", or "/ + Enter", are simply built-in substitutes for repeating the original search instruction, namely

•  "/a"

I am sure that "alias" definition is somewhere in VIM's software tree.  The design of the search function is such that it ignores the match starting at the current position. Otherwise, the search would never advance to the next instance.

Another way to look at it is

• You are already at the "first match" for what you are searching, "a". 
  
  
• If that is the case, why are you attempting any search ... if not for the next match???

Honestly, this is simply basic logic ... and ... very intuitive.

Hope that helps!

[rwmit...@gmail.com]

One possible reason to initiate a search while already on the thing being searched it to highlight all occurrences of that thing.

I have '*' mapped to do exactly that, it sets the search to the word under the cursor, highlighting all occurrences of that word.

Using 'n' and 'N' then searches as expected.  That search is being done on words, not characters.

It looks like '*' is mapped to <Plug>SearchHighlightingStar

if I'm understanding things correctly.