From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: [PATCH 2/3] lisp/progmodes/etags.el don't (forward-char) as it's overriden next line Date: Mon, 18 Mar 2019 19:00:49 +0200 Message-ID: <83zhpsunge.fsf@gnu.org> References: <20190316015314.2335-1-Hi-Angel@yandex.ru> <20190316015314.2335-2-Hi-Angel@yandex.ru> <1552902196.12639.1@yandex.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1251 Content-Transfer-Encoding: 8bit Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="75600"; mail-complaints-to="usenet@blaine.gmane.org" Cc: emacs-devel@gnu.org To: Konstantin Kharlamov Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Mar 18 18:02:13 2019 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([209.51.188.17]) by blaine.gmane.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1h5veL-000JT0-4e for ged-emacs-devel@m.gmane.org; Mon, 18 Mar 2019 18:02:09 +0100 Original-Received: from localhost ([127.0.0.1]:44607 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1h5veK-0006fi-1N for ged-emacs-devel@m.gmane.org; Mon, 18 Mar 2019 13:02:08 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:50659) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1h5vdE-0006dT-ML for emacs-devel@gnu.org; Mon, 18 Mar 2019 13:01:01 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:41680) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1h5vdE-0001UC-4s; Mon, 18 Mar 2019 13:01:00 -0400 Original-Received: from [176.228.60.248] (port=4096 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1h5vdD-0008Fa-9R; Mon, 18 Mar 2019 13:00:59 -0400 In-reply-to: <1552902196.12639.1@yandex.ru> (message from Konstantin Kharlamov on Mon, 18 Mar 2019 12:43:16 +0300) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:234332 Archived-At: > Date: Mon, 18 Mar 2019 12:43:16 +0300 > From: Konstantin Kharlamov > 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? TIA