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 10:15 ПП (PM), 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 \x7f\x7ffile
>>>  > that names a symbol 'foobar', say.  If you search for a tag 
>>> "bar" \x7f\x7fand
>>>  > do not anchor the search at the beginning of a line, you will 
>>> \x7f\x7fdecide
>>>  > that "bar" is present on the "foobar" line, although it really 
>>> \x7f\x7fisn'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 
>>> \x7f\x7fmatch
>>>  '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, 
>>> \x7f\x7fthen
>>>  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.

…as long of course as word and symbols boundaries preserved. Just to 
make it more clear.

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