bug#22589: 25.0.90; First match found by isearch-forward-symbol is not necessarily a symbol.

[Juri Linkov <juri@linkov.net>]

> What you are saying makes sense, but the bug I outlined above is more
> severe.
>
> For example: In this line:
>
> unsigned int i = 0;
>
> when searching for the symbol "i". Taking your comment into account I can
> see why the first match would be "int", although that's actually not a
> match for "\_<i\_>", because if we would match "i" directly, then there
> would be no way to go back to match "int" should the user enter more
> characters. However, what happens is that the "i" in unsIgned is matched,
> which is surely never going to be a symbol...

Thank you for the detailed test case.  The reason why “i” matches
in the middle of the symbol by not adding an anchor “\_<” is because
we need to support the symbol search backwards as well.  This means
that the symbol search should add “\_<” for searching forward,
and “\_>” for a backward search.  The same applies to the word search.

We could do this by adding an optional argument ‘backward’ to both
‘word-search-regexp’ and ‘isearch-symbol-regexp’.  One complication is that
this change is not backward-compatible.  Instead of this, I propose to use
different values of the existing arg ‘lax’, e.g. values ‘nil’
for a forward search, and ‘backward’ otherwise.

Then it will match at the beginning of the symbol for a forward search,
and at the end for a backward search.  Same for the word search.