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

[Konstantin Kharlamov <hi-angel@yandex.ru>]

В Пн, мар 18, 2019 at 8:00 ПП (PM), 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?

I'm not sure what additional details you want. I found a usecase where 
heuristic for finding a tag can be improved. I can make even stronger 
statement: all whitespace within a tag is insignificant, not only the 
trailing part.

Let's make it the other way around: please, provide any language 
example, where having the trailing space may be significant for 
unambigiously determining the tag.