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

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

В Вт, мар 19, 2019 at 2:13 ДП (AM), Konstantin Kharlamov 
<hi-angel@yandex.ru> написал:
> 
> 
> В Вт, мар 19, 2019 at 12:45 ДП (AM), Konstantin Kharlamov 
> <hi-angel@yandex.ru> написал:
>> 
>> 
>> В Пн, мар 18, 2019 at 11:16 ПП (PM), Eli Zaretskii 
>> \x7f<eliz@gnu.org> написал:
>>>>  Date: Mon, 18 Mar 2019 22:15:27 +0300
>>>>  From: Konstantin Kharlamov <hi-angel@yandex.ru>
>>>>  Cc: emacs-devel@gnu.org
>>>> 
>>>>  > Can you provide those additional details?
>>>> 
>>>>  I'm not sure what additional details you want.
>>> 
>>> OK, let me ask more specific questions:
>>> 
>>>   1. Why was the amount of whitespace in the tags table different 
>>> \x7f\x7ffrom
>>>      that in the source file?
>> 
>> It's a bug in anjuta-tags
>> 
>>>   2. What command(s) was/were used to produce the tags table?
>> 
>> anjuta-tags -e file.vala
>> 
>>>   3. Why are the issue and you talking about "trailing whitespace",
>>>      while the difference between Expected and Actual in the issue 
>>> is
>>>      in leading whitespace, not trailing whitespace?
>> 
>> Sorry for confusion here, I was imagining: given a string, 
>> whitespace \x7fmay "trail" on both sides of it. But I'm not a native 
>> speaker.
>> 
>>>>  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.
>>> 
>>> etags.el doesn't understand any languages, that is the job of the
>>> program that produces the tags table.  etags.el just follows the 
>>> \x7f\x7frules
>>> for the format of tags in the tags table.  I don't know about 
>>> \x7f\x7ftrailing
>>> whitespace, but tags for HTML files surely include embedded
>>> whitespace, for example.
>>> 
>>> So once again, I suggest to focus on the particular problem you had,
>>> because I'd like to find a solution for that without making
>>> backward-incompatible changes in behavior of etags.el.
>> 
>> Okay, whatever. I get your position. Though I disagree, but we 
>> \x7fclearly have different priorities here: while I'm focusing on a 
>> Emacs \x7fuser, you're focusing on technical correctness. I doubt this 
>> \x7fdiscussion can move anywhere further, let's leave it at it.
>> 
>> Can my 1-st patch from the series be merged though?
> 
> Oh, wait, I noticed despite going to a tag I'm getting "Rerun etags" 
> message. Something is wrong, let me investigate.

Oh, I found my bug, that sucks, don't know how I missed that, I've used 
that code for a while. I need to return t from the cycle. Basically, I 
need either "break", or recursion. The first isn't supported in Lisp, 
and the tail-recursion optimization is not supported in Emacs. So 
there's actually no way to improve this code.

The patch can be dropped too.