We can enable this feature without new 'inchlsearch' option and regardless 'hlsearch' with following patch.

But, I wonder is it really ok to make it default behavior. IncSearch and Search highlight is similar in some colorscheme and when you type ., all characters will be highlighted.
I thought someone may feel it's annoying behavior.

What do you think?

diff --git a/src/ex_getln.c b/src/ex_getln.c
index 578a7c5fd..adc226fbf 100644
--- a/src/ex_getln.c
+++ b/src/ex_getln.c
@@ -1681,10 +1681,12 @@ getcmdline(
 		{
 		    pos_T  t;
 		    int    search_flags = SEARCH_NOOF + SEARCH_PEEK;
+		    int    save_p_hls = p_hls;
 
 		    if (char_avail())
 			continue;
 		    save_last_search_pattern();
+		    p_hls = TRUE;
 		    cursor_off();
 		    out_flush();
 		    if (c == Ctrl_G)
@@ -1694,8 +1696,6 @@ getcmdline(
 		    }
 		    else
 			t = match_start;
-		    if (!p_ihls)
-			search_flags += SEARCH_KEEP;
 		    ++emsg_off;
 		    i = searchit(curwin, curbuf, &t,
 				 c == Ctrl_G ? FORWARD : BACKWARD,
@@ -1748,6 +1748,7 @@ getcmdline(
 			old_botline = curwin->w_botline;
 			update_screen(NOT_VALID);
 			restore_last_search_pattern();
+			p_hls = save_p_hls;
 			redrawcmdline();
 		    }
 		    else
@@ -1896,6 +1897,7 @@ cmdline_changed:
 #ifdef FEAT_RELTIME
 	    proftime_T	tm;
 #endif
+	    int save_p_hls = p_hls;
 
 	    /* if there is a character waiting, search and redraw later */
 	    if (char_avail())
@@ -1906,6 +1908,7 @@ cmdline_changed:
 	    incsearch_postponed = FALSE;
 	    curwin->w_cursor = search_start;  /* start at old position */
 	    save_last_search_pattern();
+	    p_hls = TRUE;
 
 	    /* If there is no command line, don't do anything */
 	    if (ccline.cmdlen == 0)
@@ -1923,8 +1926,6 @@ cmdline_changed:
 		/* Set the time limit to half a second. */
 		profile_setlimit(500L, &tm);
 #endif
-		if (!p_ihls)
-		    search_flags += SEARCH_KEEP;
 		i = do_search(NULL, firstc, ccline.cmdbuff, count,
 			search_flags,
 #ifdef FEAT_RELTIME
@@ -1984,6 +1985,7 @@ cmdline_changed:
 	    update_screen(SOME_VALID);
 	    restore_cmdline(&save_ccline);
 	    restore_last_search_pattern();
+	    p_hls = save_p_hls;
 
 	    /* Leave it at the end to make CTRL-R CTRL-W work. */
 	    if (i != 0)

did you check the build failure?

I don't think it is related to this PR, because the master branch also failed with the same error.
Not sure why lua fails.

It looks like #2203 will fix the build failure. Will update this pull-request to include the fix once #2203 included. (I ran CI against my fork repo and I confirmed CI passed in OSX too. haya14busa#5)

Codecov Report

Merging #2198 into master will increase coverage by 0.11%.
The diff coverage is 100%.

@@            Coverage Diff             @@
##           master    #2198      +/-   ##
==========================================
+ Coverage   74.31%   74.42%   +0.11%     
==========================================
  Files          90       90              
  Lines      132039   132089      +50     
  Branches    28994    29001       +7     
==========================================
+ Hits        98126    98310     +184     
+ Misses      33884    33750     -134     
  Partials       29       29

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update f8e8c06...ad1e575. Read the comment docs.

I added test for highlight while incremental searching by runnning vim with term_start().

I cannot find a way to test highlight while searching with Vim itself because
"redraw" command while searching turn of incserach and inchlsearch highlight.

We cannot test gVim with term_start, but I think it's better than nothing :)

Hi, Bram!

Could you tell me your thought about this patch?
I understand bug fixes have higher priority than new feature like this and I
won't say please merge it right now, but I want to hear your opinion and
improve this patch if needed.

(I updated the patch to fix the conflict with recent changes)

If this patch relied on incsearch option, then old behavior could not be preserved even with CmdlineEnter and CmdlineLeave events. It would be a pithy for those users who use search mostly as navigation tool.

I think idea of using hlsearch and autocommands is the best. It allows preservation of old behavior and is consistent with current current hlsearch option description.

But it does work when 'hlsearch' is always on?

Not sure what you mean with work...

I pulled the latest vim.git repo yesterday and it appears this patch was included (based on looking at the source files). However, I have both incsearch and hlsearch options set to On, but I don't get the new functionality provided by the patch. What am I missing?

it is not included yet.

Oh, that explains it. I guess when I pull'd what I thought was this patch based on a hash of 9fbe6fb, I didn't do it correctly and apparently got one of Bram's latest patches which was of course was already in the vim pull that I had done. Um, so how can I download the latest version of this patch?

Thanks very much for the reply.

Um, so how can I download the latest version of this patch?

Go to this link:
https://github.com/vim/vim/pull/2198.diff

Or:

git checkout -b haya14busa-incsearch-hi-all master
git pull https://github.com/haya14busa/vim.git incsearch-hi-all

Thanks very much for the link!

You don't have to checkout the contributors repository. You can also switch directly to a pull request using something like this:

git fetch origin pull/<ID>/head:branch
git checkout branch

Now you can build and test yourself.

See also the github documentation:
https://help.github.com/articles/checking-out-pull-requests-locally/

Hi!

I added tests for incremental highlight of <C-g> and <C-t> (I found that I forgot to write them...).
I think the tests covered enough cases for this patch now.

git fetch origin pull//head:branch
git checkout branch

bwt, this works well for first time, but there is no tracking information (no
upstream branch) for the created branch, so you cannot update the branch by
simple git pull command. Instead you need to run this following command.

$ git pull origin pull/2198/head

@chrisbra

Not sure what you mean with work...

Work like the GIF I pasted on the top comment?

Sorry for repeating it, but I assume you didn't use the latest patch.
Can you confirm that you used the latest patch?

If your report is true, it's certainly the problem of this patch, not the problem of the autocmd.
So, I want to confirm that and want to fix if the problem is reproducible with latest code.
Thanks!

@haya14busa

Sorry for repeating it, but I assume you didn't use the latest patch.

that was unrelated to your patch and was only a comment that setting the 'hlsearch' setting on CmdlineEnter/ CmdlineLeave autocommands won't work as expected.

Ok, then what is your expectation?

Last pattern should be highlighted right after pressing search command (/) instead of first character?

Or, you mentioned

it highlights the last search pattern .* instead of the typed one v

but, without my patch, it's totally expected behavior. Incremental searching won't change the last search pattern.

autocmd CmdlineEnter [/\?] :set hlsearch | redraw

By calling :redraw, last pattern will be highlighted right after pressing / or ?.

Other behavior you reported seems expected behavior. When :set hlsearch and :set incsearch, last pattern is highlighted same as before. The autocmd just turn on and off 'hlsearch' when entering/leaving cmdline.

Thank you for including it! ✨

The augroup provided in description of 'incsearch' doesn't work on Windows.

yeah, it looks like this:

		  autocmd CmdlineEnter [/\?] :set hlsearch

does not match on Windows. However this works:

		  autocmd CmdlineEnter /,\? :set hlsearch
		  autocmd CmdlineLeave /,\? :set nohlsearch

Why is backslash needed? It works without it.

I think it's used in a sense of wildcards not patterns. But when I tried to use autocommand with only ? (without backslahs) hlsearch wasn't enabled inside a search started with /. That's why I asked.

Hi all, I've noticed that after updating to vim 8.0.1250, my search behavior was a little weird. I think it's related to this patch, but it seems
/\v
matches every character in a file, where it didn't previously. When I got to search now (using my nnoremap / /\v), the entire file is highlighted by incsearch and hlsearch until I start typing my pattern. Further, if I hit <CR>, pressing n will simply take me character-by-character through the file.

This didn't occur before. Is this considered intended behavior (i.e. that an empty search pattern with the very-magic flag is a match for every character)?

@benknoble I saw the same behavior. For now at least, I removed my nnoremap / /\v mapping.

It is discussed at #2337.