Re: [PATCH 2/3] lisp/progmodes/etags.el don't (forward-char) as it's overriden next line

[Eli Zaretskii <eliz@gnu.org>]

> Date: Mon, 18 Mar 2019 12:43:16 +0300
> From: Konstantin Kharlamov <hi-angel@yandex.ru>
> Cc: emacs-devel@gnu.org
> 
> > 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?

TIA