From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Konstantin Kharlamov 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 22:25:35 +0300 Message-ID: <1552937135.7027.1@yandex.ru> References: <20190316015314.2335-1-Hi-Angel@yandex.ru> <20190316015314.2335-2-Hi-Angel@yandex.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="178508"; mail-complaints-to="usenet@blaine.gmane.org" Cc: emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Mar 18 20:25:53 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 1h5xtQ-000kKe-5v for ged-emacs-devel@m.gmane.org; Mon, 18 Mar 2019 20:25:52 +0100 Original-Received: from localhost ([127.0.0.1]:46418 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1h5xtP-0000qe-1T for ged-emacs-devel@m.gmane.org; Mon, 18 Mar 2019 15:25:51 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:48103) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1h5xtH-0000qY-89 for emacs-devel@gnu.org; Mon, 18 Mar 2019 15:25:44 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1h5xtG-0003hv-1Y for emacs-devel@gnu.org; Mon, 18 Mar 2019 15:25:42 -0400 Original-Received: from forward103p.mail.yandex.net ([2a02:6b8:0:1472:2741:0:8b7:106]:43045) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1h5xtD-0003gN-Q2; Mon, 18 Mar 2019 15:25:40 -0400 Original-Received: from mxback8j.mail.yandex.net (mxback8j.mail.yandex.net [IPv6:2a02:6b8:0:1619::111]) by forward103p.mail.yandex.net (Yandex) with ESMTP id C837D18C07D1; Mon, 18 Mar 2019 22:25:36 +0300 (MSK) Original-Received: from smtp4j.mail.yandex.net (smtp4j.mail.yandex.net [2a02:6b8:0:1619::15:6]) by mxback8j.mail.yandex.net (nwsmtp/Yandex) with ESMTP id Qc6zAggrK5-Pa1Wjap2; Mon, 18 Mar 2019 22:25:36 +0300 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1552937136; bh=vl3PiDzChq4ohCIOsxTB3OXy4vWK/3LRnyBE6uUEBqA=; h=In-Reply-To:Cc:To:Subject:From:References:Date:Message-Id; b=ukIW6kYKH2bvIS6wB5A0e0BA65pJh7gTxgVbe3qBLc4uRJbM9YNVyFhN8/dpHOKmx zYQPho+trNk44Xo3grfi2ObY5dDuAeJTgx63lf8aUDclbyOo0RZhzsaD2KvgEpjyy9 dTleeRaJZxy6Q49+tkj353NA/RWyXUP/xgMe0ahk= Authentication-Results: mxback8j.mail.yandex.net; dkim=pass header.i=@yandex.ru Original-Received: by smtp4j.mail.yandex.net (nwsmtp/Yandex) with ESMTPSA id rxeEbu6cPr-PZJenH5M; Mon, 18 Mar 2019 22:25:36 +0300 (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client certificate not present) In-Reply-To: <1552936527.7027.0@yandex.ru> X-Mailer: geary/master~g91967edc X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2a02:6b8:0:1472:2741:0:8b7:106 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:234337 Archived-At: =D0=92 =D0=9F=D0=BD, =D0=BC=D0=B0=D1=80 18, 2019 at 10:15 =D0=9F=D0=9F (PM)= , Konstantin Kharlamov=20 =D0=BD=D0=B0=D0=BF=D0=B8=D1=81=D0=B0=D0=BB: >=20 >=20 > =D0=92 =D0=9F=D0=BD, =D0=BC=D0=B0=D1=80 18, 2019 at 8:00 =D0=9F=D0=9F (PM= ), Eli Zaretskii=20 > =D0=BD=D0=B0=D0=BF=D0=B8=D1=81=D0=B0=D0=BB: >>> Date: Mon, 18 Mar 2019 12:43:16 +0300 >>> From: Konstantin Kharlamov >>> Cc: emacs-devel@gnu.org >>>=20 >>> > I'm not talking about whitespace. I'm talking about a tags=20 >>> table =7F=7Ffile >>> > that names a symbol 'foobar', say. If you search for a tag=20 >>> "bar" =7F=7Fand >>> > do not anchor the search at the beginning of a line, you will=20 >>> =7F=7Fdecide >>> > that "bar" is present on the "foobar" line, although it really=20 >>> =7F=7Fisn't. >>> > Right? >>>=20 >>> Not exactly. Here's an alternative bad situation: let's say you do >>> anchor the text, and you search for tag 'foo'. And=E2=80=A6 you still=20 >>> =7F=7Fmatch >>> 'foobar'! >>=20 >> 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. >>=20 >> But with your proposed change the match will be in the middle of a >> symbol as well, something the callers don't expect. >>=20 >>> #define FOO >>> #define FOO_BAR >>>=20 >>> If source code is intact, you should get FOO. But if code changed,=20 >>> =7F=7Fthen >>> emacs tries to find where did it go, and may as well stumble upon >>> FOO_BAR. >>=20 >> That's okay, that's how this low-level stuff is supposed to work. >>=20 >>> So, I suggest an improvement to my patch: how about we >>>=20 >>> 1. anchor the regexp to the end of the line also >>> 2. replace trailing space with "any whitespace" regex '\s-*' >>>=20 >>> ? >>=20 >> 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. >>=20 >> So I would actually suggest to make one step back and describe in=20 >> 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. >>=20 >> Can you provide those additional details? >=20 > I'm not sure what additional details you want. I found a usecase=20 > where heuristic for finding a tag can be improved. I can make even=20 > stronger statement: all whitespace within a tag is insignificant, not=20 > only the trailing part. =E2=80=A6as long of course as word and symbols boundaries preserved. Just t= o=20 make it more clear. > Let's make it the other way around: please, provide any language=20 > example, where having the trailing space may be significant for=20 > unambigiously determining the tag. =