Date: Mon, 18 Mar 2019 12:43:16 +0300
From: Konstantin Kharlamov <address@hidden>
Cc: address@hidden
> I'm not talking about whitespace. I'm talking about a tags
table file
> that names a symbol 'foobar', say. If you search for a tag
"bar" and
> do not anchor the search at the beginning of a line, you will
decide
> that "bar" is present on the "foobar" line, although it really
isn't.
> Right?
Not exactly. Here's an alternative bad situation: let's say you do
anchor the text, and you search for tag 'foo'. And… you still
match
'foobar'!
That's expected, and how etags.el should work: it finds tags that
_begin_ with the specified text. Partial matches are filtered out by
higher-level routines, if needed.
But with your proposed change the match will be in the middle of a
symbol as well, something the callers don't expect.
#define FOO
#define FOO_BAR
If source code is intact, you should get FOO. But if code changed,
then
emacs tries to find where did it go, and may as well stumble upon
FOO_BAR.
That's okay, that's how this low-level stuff is supposed to work.
So, I suggest an improvement to my patch: how about we
1. anchor the regexp to the end of the line also
2. replace trailing space with "any whitespace" regex '\s-*'
?
etags.el is used by/supports many major modes, and in general I don't
think we want to assume that whitespace in a tag is insignificant,
certainly not as a global change in behavior.
So I would actually suggest to make one step back and describe in
more
detail the actual problem you had with the current code. The anjuta
issue to which you pointed doesn't have enough details, like why the
change in leading whitespace was deemed a problem, and so I cannot
make up my mind what is the actual problem and why it should be fixed
in etags.el.
Can you provide those additional details?