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

Previous Next

Full log

View this message in rfc822 format

From: Juri Linkov <juri <at> linkov.net>
To: Bastian Beischer <bastian.beischer <at> gmail.com>
Cc: 22589 <at> debbugs.gnu.org
Subject: bug#22589: 25.0.90; First match found by isearch-forward-symbol is not necessarily a symbol.
Date: Wed, 10 Feb 2016 02:54:54 +0200

> 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.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.