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 On Wednesday, January 21, 2026 at 3:04:53 PM UTC+1 Tony Mechelynck wrote: > On Wed, Jan 21, 2026 at 2:58 PM Cristian <[email protected]> wrote: > > > > 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 > > 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. > -- -- You received this message from the "vim_use" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_use" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion visit https://groups.google.com/d/msgid/vim_use/c21fd8a3-50bc-4d15-9533-31f9617610c9n%40googlegroups.com.
