emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Konstantin Kharlamov
Subject: Re: [PATCH 2/3] lisp/progmodes/etags.el don't (forward-char) as it's overriden next line
Date: Mon, 18 Mar 2019 22:15:27 +0300



В Пн, мар 18, 2019 at 8:00 ПП (PM), Eli Zaretskii <address@hidden> написал:
 Date: Mon, 18 Mar 2019 12:43:16 +0300
 From: Konstantin Kharlamov <address@hidden>
 Cc: address@hidden

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





reply via email to

[Prev in Thread] Current Thread [Next in Thread]