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

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

On Пн, Mar 18, 2019 at 12:43:16, Konstantin Kharlamov 
<hi-angel@yandex.ru> wrote:
> 
> 
> On Пн, Mar 18, 2019 at 06:34:00, Eli Zaretskii <eliz@gnu.org> wrote:
>>>  Date: Sun, 17 Mar 2019 23:44:28 +0300
>>>  From: Konstantin Kharlamov <hi-angel@yandex.ru>
>>>  Cc: emacs-devel@gnu.org
>>> 
>>>  > But that's incorrect: a tag in a tags table always begins at the
>>>  > beginning of a line, so it must be a search anchored at the 
>>> \x7f\x7fbeginning
>>>  > of the line.  And in selective-display mode ^M counts as the 
>>> \x7f\x7fbeginning
>>>  > of a line.
>>> 
>>>  Great, now that we established that part, to reply your question 
>>> \x7f\x7fwhy we
>>>  don't care about the beginnging of the line let me quote my other 
>>> \x7f\x7fmail:
>>> 
>>>   > The pattern that this functions searches for determines the tag
>>>  uniquely. But here's a catch: no programming language creates 
>>> \x7f\x7fdistinc
>>>  entities (ones that end up in the tag), based only on trailing 
>>> \x7f\x7fspace.
>>>  I.e. "foo()" and " foo() " always refer to the same thing.
>> 
>> 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'!
> 
> Actually, it's interesting, that such name clashes are possible right 
> now: let's say we have:
> 
> 	#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.
> 
> 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-*'
> 
> ?

To be clear: I suggest that we keep anchoring to the beginning of a 
line in place, add anchoring to the end of line, and replace trailing 
whitespace with "any whitespace" regex.