Lars Ingebrigtsen <larsi@HIDDEN>
to control <at> debbugs.gnu.org.
Full text available.Received: (at 32034) by debbugs.gnu.org; 10 Aug 2020 20:42:30 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Mon Aug 10 16:42:30 2020 Received: from localhost ([127.0.0.1]:37589 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1k5Eco-0002D3-CM for submit <at> debbugs.gnu.org; Mon, 10 Aug 2020 16:42:30 -0400 Received: from mail-wr1-f46.google.com ([209.85.221.46]:42454) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <joaotavora@HIDDEN>) id 1k5Ecl-0002Ci-Du for 32034 <at> debbugs.gnu.org; Mon, 10 Aug 2020 16:42:29 -0400 Received: by mail-wr1-f46.google.com with SMTP id r4so9416792wrx.9 for <32034 <at> debbugs.gnu.org>; Mon, 10 Aug 2020 13:42:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version:content-transfer-encoding; bh=HxjkXTmUH35mYtAiV1SsVEmuyMTzSSOulqOSfRzULvQ=; b=OX+Cb/h/W3Xr1TWllENwQkMWSGMr+SZ5lEcDXljleTx2xSUTETWFAP12vfiGNhV8cH MH5LDiW9W7KoPSEu1Dn/Sw+QqoRt67kSPqm6VL0XMuPsLVRd9UHtTLmKPS5SUetFtsDq OMJnPla0FEE0D+DLUCfhvY3FbJi40hR9OQqaWWNDSKtr7Im8zzBcMRXou9eXxVSXrw7n D02wJW9tS3VaXtq4O6q0G5GXRnX9TMFbAqZkKsPtIFweAwwv+uALTLhbvZp0oqz6TrYs 2M9Pqeja7quvIMSdnx6gWqYvSBxOFny52SouLx8k77AnYWy7+DKww4YKBcnSayqtQyE9 9nbg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:references:date:in-reply-to :message-id:user-agent:mime-version:content-transfer-encoding; bh=HxjkXTmUH35mYtAiV1SsVEmuyMTzSSOulqOSfRzULvQ=; b=t4ADDnwsnbCfinuQVZ8wNVZWk0+g7Hd+71fz/AAOPc/cBhiow6xNpzuPy2EpEyHIwE GYFWnRyAZ1kS1JS8HauPt/pmUzjjEzy7SGFym2G/KER9Uh6tRRkJlRfzYjYGq/Gm3xuy tcJmzJkUDQtyPoVblbWxRam3fzPHr01TjymsM6Q0RH+KTnaaR7z1iCBYgsrQJYRXW7/0 rN6lBQmVjcRRBbn82koCE5CuMVEwNPR2mljEj26VQtOkvUAc96rqvVI63REtrJw9bdpl wZOFb9194Qcqa5VQofM0orralzlz4RRGPPTVejaQ6ofMkxOnsob4hXzqBz9GAc9igFwd 5kPw== X-Gm-Message-State: AOAM5321/TWH2t9E6ER6y5Ei64UKfekiy58krRLO6Zv6M5pHMXIswOUZ d6sFskoCKCF9ZyUzYCsN8ek= X-Google-Smtp-Source: ABdhPJxCt4PObpwRDz60Aa6qrF5GHTDQd4DRP3Vbp8irf8Q4CDbZYBXhj3ot+DfYc2uifPLtruyALw== X-Received: by 2002:adf:aa9e:: with SMTP id h30mr25170682wrc.377.1597092141314; Mon, 10 Aug 2020 13:42:21 -0700 (PDT) Received: from krug (89-180-144-39.net.novis.pt. [89.180.144.39]) by smtp.gmail.com with ESMTPSA id b203sm1244415wmc.22.2020.08.10.13.42.20 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 10 Aug 2020 13:42:20 -0700 (PDT) From: =?utf-8?B?Sm/Do28gVMOhdm9yYQ==?= <joaotavora@HIDDEN> To: Lars Ingebrigtsen <larsi@HIDDEN> Subject: Re: bug#32034: 26.1; [PACTH] better xref-location-marker for imperfect file locations References: <87y3etsqb7.fsf@HIDDEN> <83601xlmno.fsf@HIDDEN> <87muv9sll6.fsf@HIDDEN> <83po05k5rx.fsf@HIDDEN> <87bmbpskl8.fsf@HIDDEN> <83muv9k38v.fsf@HIDDEN> <87o9fpfuhe.fsf@HIDDEN> <83lgatk0ku.fsf@HIDDEN> <87zh724pya.fsf@HIDDEN> <e595ae8f-3826-4614-6834-87c7aab55539@HIDDEN> Date: Mon, 10 Aug 2020 21:42:18 +0100 In-Reply-To: <e595ae8f-3826-4614-6834-87c7aab55539@HIDDEN> (Dmitry Gutov's message of "Mon, 10 Aug 2020 21:53:32 +0300") Message-ID: <87y2mm44id.fsf@HIDDEN> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 32034 Cc: Eli Zaretskii <eliz@HIDDEN>, 32034 <at> debbugs.gnu.org, Helmut Eller <eller.helmut@HIDDEN>, Dmitry Gutov <dgutov@HIDDEN> X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.0 (-) On 10.08.2020 15:59, Lars Ingebrigtsen wrote: Hi Lars, thanks for pinging me. > This was over two years ago, and there was some followup discussion > between Dmitry and Jo=C3=A3o, but I think the consensus here was that the > patches fixes a real problem, ans should probably be applied? As far as > I can see, that never happened. I read the discussion. As far as I know the problem reported originally persists. A small patch does exist, has two parts: 1 and 2. Part 2 apparently had some real problem that I don't understand anymore, not sure if it still applies. I seem to have said it was easy to fix, though it wouldn't much matter if we could devise a much better fix, later known as number 3. The rest of the discussion consists of hypothetical problems (about seemingly hypothetical backends), leveled against that nr. 3 patch, which seems never to have seen the light of day: I made the mistake of tagging along with the hypotheticals and then probably ran out of time. If I recall correctly, that better patch, were it to exist, would do what is done by SLIME, the thing xref.el was based on when it was originally written by Helmut Eller. SLIME has done it for a very long time and quite successfully: the objects that represent cross-references contain optional extra bits of information -- hints -- which help, heuristically, when locating the thing being looked for. My fork of SLIME, SLY, hasn't yet switched to xref.el partly because of xref.el's limitations in this regard. Eglot would also benefit (the original report concerns Eglot). Alas, that nr 3 patch is vapourware. Maybe I or someone will make it in the future, and then we can talk about real stuff. I think we should look to SLIME (and maybe Helmut?) for inspiration in fixing this, but I don't have time to do this right now. The original thread where xref.el is originally discussed is relevant here, for posterity: https://lists.gnu.org/archive/html/emacs-devel/2014-12/msg01253.html Jo=C3=A3o
bug-gnu-emacs@HIDDEN:bug#32034; Package emacs.
Full text available.Received: (at 32034) by debbugs.gnu.org; 10 Aug 2020 18:53:46 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Mon Aug 10 14:53:46 2020 Received: from localhost ([127.0.0.1]:37508 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1k5Cva-0007qP-8W for submit <at> debbugs.gnu.org; Mon, 10 Aug 2020 14:53:46 -0400 Received: from mail-wr1-f49.google.com ([209.85.221.49]:42886) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <raaahh@HIDDEN>) id 1k5CvY-0007q8-89 for 32034 <at> debbugs.gnu.org; Mon, 10 Aug 2020 14:53:44 -0400 Received: by mail-wr1-f49.google.com with SMTP id r4so9159563wrx.9 for <32034 <at> debbugs.gnu.org>; Mon, 10 Aug 2020 11:53:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=dQA4L7Yu8fCzKKNn/NDAIRDltM/VimLCwfRuYM5tTD8=; b=WbTrsEl39JICPHtHcVRriT8H/mlGvaHFS+3Rv22/4ZsNwJEoltyO6nFH7//qlUcGoA bPXWf8+ppwfUCn1sUZ0Onyf3LrCKQbGamht2bNB4EL3pfHokfdWbMqb7yeAT6K6v9slo 2JRLJCbUZ4fJd2N15OicoXcNjFXMpFdTgJ1+ohKHzj2c/Un1SYeIJTa55I+lOFqE9LnK dMdw5dt2h0ikyK+EEn/O+j5sc/MNsdeQppMaNVXpCg8Jv/59Q8M5SH/+tS34XqSzICR5 yO/AcLOOMM6CX05YzgI6OYrdxdFoOKT8D4p/CSah9Ah5ILFup3rnv3i9If6VCpuC4Vrw G3rA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:subject:to:cc:references:from:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=dQA4L7Yu8fCzKKNn/NDAIRDltM/VimLCwfRuYM5tTD8=; b=VEmqSN68FOEhDWhb5gVrxL0u01q/8NzFCK5bPD2ZPPYsWRlA9e6To1xBIz/V1eDjr4 EtA5s1aWc2Zltqp/DPi5Zo6P7lmPZU0MaT691Lpx463npwOntsoVH23ZcAnnr2UUpzox 6J3oqwVMHMWfYhFYfTYVP7pFqiThuoxVms/H1MCogfgWxhoeEBGkPB8/tcheH8eu0Ric XtqyO2hxQNEBqkaOaENHjTFAZNmKgRFiOUf/0/JSDK5y5gIo90aDI5vKUoMYeNAIH6J8 cuY53gVIVQnpWjzHTxXyqXNru9L5XsvqM6v3o0tT5cm1onsaBdE3+sEm0heeiLA/OYl7 zwxg== X-Gm-Message-State: AOAM530/6olxUHwl7xYUghprPhCJFBYZy0OMoPFpnWObwIwTjLbCykBu 4rz5GsCyiTjWF+yS/DFZ9Wq3TnjV X-Google-Smtp-Source: ABdhPJwRERx/z5kLDF97af8KwIMJXujNwgSqtmNAq4xQUKe15CRmw8wSOfPIU5ICszS3n72MdZrZVQ== X-Received: by 2002:adf:f44b:: with SMTP id f11mr2788287wrp.114.1597085614984; Mon, 10 Aug 2020 11:53:34 -0700 (PDT) Received: from [192.168.0.3] ([66.205.73.129]) by smtp.googlemail.com with ESMTPSA id p3sm698568wma.44.2020.08.10.11.53.33 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 10 Aug 2020 11:53:34 -0700 (PDT) Subject: Re: bug#32034: 26.1; [PACTH] better xref-location-marker for imperfect file locations To: Lars Ingebrigtsen <larsi@HIDDEN>, Eli Zaretskii <eliz@HIDDEN> References: <87y3etsqb7.fsf@HIDDEN> <83601xlmno.fsf@HIDDEN> <87muv9sll6.fsf@HIDDEN> <83po05k5rx.fsf@HIDDEN> <87bmbpskl8.fsf@HIDDEN> <83muv9k38v.fsf@HIDDEN> <87o9fpfuhe.fsf@HIDDEN> <83lgatk0ku.fsf@HIDDEN> <87zh724pya.fsf@HIDDEN> From: Dmitry Gutov <dgutov@HIDDEN> Message-ID: <e595ae8f-3826-4614-6834-87c7aab55539@HIDDEN> Date: Mon, 10 Aug 2020 21:53:32 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: <87zh724pya.fsf@HIDDEN> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 32034 Cc: 32034 <at> debbugs.gnu.org, =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= <joaotavora@HIDDEN> X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.0 (-) On 10.08.2020 15:59, Lars Ingebrigtsen wrote: > This was over two years ago, and there was some followup discussion > between Dmitry and João, but I think the consensus here was that the > patches fixes a real problem, ans should probably be applied? As far as > I can see, that never happened. Nope, that wasn't the consensus. The proposed patch had problems, and we haven't reached any next version.
bug-gnu-emacs@HIDDEN:bug#32034; Package emacs.
Full text available.Received: (at 32034) by debbugs.gnu.org; 10 Aug 2020 12:59:25 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Mon Aug 10 08:59:25 2020 Received: from localhost ([127.0.0.1]:34890 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1k57Of-00074J-01 for submit <at> debbugs.gnu.org; Mon, 10 Aug 2020 08:59:25 -0400 Received: from quimby.gnus.org ([95.216.78.240]:47428) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <larsi@HIDDEN>) id 1k57Oc-000744-Lw for 32034 <at> debbugs.gnu.org; Mon, 10 Aug 2020 08:59:23 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnus.org; s=20200322; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Message-ID :In-Reply-To:Date:References:Subject:Cc:To:From:Sender:Reply-To:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=U20Lmy8HHZCKmI/9L6luzVpZdKXppsfM03b5oAhKJJs=; b=BNxEIFV5yckZrHiJvtYlEsk5MU DHqTCdh2NtLQr3G+gElw/zJnkttH9zICcidqnUqaQcvujCCVDIDn8JyMgNO9TJpE7JcyrDQQh03Ny C+jHcrA47/+4Mc76cXXyXhz9k3J0jWbNAGnNyCdjH2oICD7dwFrByFcj76KROA10pspc=; Received: from cm-84.212.202.86.getinternet.no ([84.212.202.86] helo=xo) by quimby with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from <larsi@HIDDEN>) id 1k57OR-00043I-Hc; Mon, 10 Aug 2020 14:59:15 +0200 From: Lars Ingebrigtsen <larsi@HIDDEN> To: Eli Zaretskii <eliz@HIDDEN> Subject: Re: bug#32034: 26.1; [PACTH] better xref-location-marker for imperfect file locations References: <87y3etsqb7.fsf@HIDDEN> <83601xlmno.fsf@HIDDEN> <87muv9sll6.fsf@HIDDEN> <83po05k5rx.fsf@HIDDEN> <87bmbpskl8.fsf@HIDDEN> <83muv9k38v.fsf@HIDDEN> <87o9fpfuhe.fsf@HIDDEN> <83lgatk0ku.fsf@HIDDEN> Date: Mon, 10 Aug 2020 14:59:09 +0200 In-Reply-To: <83lgatk0ku.fsf@HIDDEN> (Eli Zaretskii's message of "Mon, 02 Jul 2018 20:29:53 +0300") Message-ID: <87zh724pya.fsf@HIDDEN> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Report: Spam detection software, running on the system "quimby.gnus.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see @@CONTACT_ADDRESS@@ for details. Content preview: Eli Zaretskii <eliz@HIDDEN> writes: > No. I'm okay with your solution for 1 to go to emacs-26. I had > reservations about your solution for 2, but now I understand it won't > affect the existing back-ends, so I'm okay with it on emacs-2 [...] Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 32034 Cc: 32034 <at> debbugs.gnu.org, =?utf-8?B?Sm/Do28gVMOhdm9yYQ==?= <joaotavora@HIDDEN>, dgutov@HIDDEN X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.0 (-) Eli Zaretskii <eliz@HIDDEN> writes: > No. I'm okay with your solution for 1 to go to emacs-26. I had > reservations about your solution for 2, but now I understand it won't > affect the existing back-ends, so I'm okay with it on emacs-26, too > (but will probably suggest a clearer message text if Dmitry agrees > with the solution). > > 3 should indeed go to master. This was over two years ago, and there was some followup discussion between Dmitry and Jo=C3=A3o, but I think the consensus here was that the patches fixes a real problem, ans should probably be applied? As far as I can see, that never happened. --=20 (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no
bug-gnu-emacs@HIDDEN:bug#32034; Package emacs.
Full text available.Received: (at 32034) by debbugs.gnu.org; 4 Jul 2018 19:17:04 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Wed Jul 04 15:17:04 2018 Received: from localhost ([127.0.0.1]:46995 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1fanGy-0007bd-J0 for submit <at> debbugs.gnu.org; Wed, 04 Jul 2018 15:17:04 -0400 Received: from mail-wm0-f42.google.com ([74.125.82.42]:36564) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <joaotavora@HIDDEN>) id 1fanGw-0007b6-Jx for 32034 <at> debbugs.gnu.org; Wed, 04 Jul 2018 15:17:03 -0400 Received: by mail-wm0-f42.google.com with SMTP id s14-v6so7465853wmc.1 for <32034 <at> debbugs.gnu.org>; Wed, 04 Jul 2018 12:17:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version:content-transfer-encoding; bh=6+Ir8DBMkkbabpNrGowloL4t9eCo7TKYPlKgl0Cic98=; b=hhBln/JGeTjqWWKNNaUtYmLFAvZNq53HaeMvUrizZLJQowTyUovn2lUIqkbamVURjd hba67Qjhhq0EYTE7TyPrrQkw6+P5F19MvI0FduoiXD6xehr+lzZVQrINbcIK0cZcChSK pSJNeuhvPlqaz9kX0+FjzUCcv10cIELdUJ4TpXQtAWmgGe/11owXThAi6OPomb2fc0aV hthWPpkmswdYOPTCdP1QZLdJn+c9YydhjfbRtolKsOfprIJ0b0a9y0WM58nnWfp+9gIe MeNC11LUAWX9D7FgIYMyBKRBcWy1qJXiwOR4r1NpxEpC6UQtPQKcXL8i8A7yqtN4frS6 ndUA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:references:date:in-reply-to :message-id:user-agent:mime-version:content-transfer-encoding; bh=6+Ir8DBMkkbabpNrGowloL4t9eCo7TKYPlKgl0Cic98=; b=UBklbLM3Rcx/vXW0mX913vznONO+qWZFWUXRIeHtwqv38+p2++CiU2ezoFktvymdcX dOdhmFckyDHNyrr+LM9T51L9i7lm0rzhYrci+9+Bqzobxx2zJT6nnTGYQ0E/fwHRXe79 J62Nuz0HqKbSRMyScXwPLSOiHP5liKbygIXsXiRjOMylZAwbil2ikOIIqSL5yAybN3j4 JUts3u4ytkckhCsN+5ytorat61PFC4xpfLHT2sKwx2J9hhZDJ7xTisuHXaxoIALfzPuk jFVGUe1LaNs0Mid2AYsBbtOV67OqUf50Pd19kKD6HF4vuy4rt2WqgNV8T2KCdIQqCti9 se5w== X-Gm-Message-State: APt69E3xPa9iSF3cldZFHuboIhR688ZcH2WWlPhYHJNGbe06KXArA7Mo +u/dNaqqNCxjx1DXZOOZ+hN1Jif4 X-Google-Smtp-Source: AAOMgpcVtKdWEykqHT0akzHNEjN23Te8CPlFyGD5zIluKzI+Ha3GDRSUX0t5szm/7aZgDy16NnlOSw== X-Received: by 2002:adf:e6d0:: with SMTP id y16-v6mr2604352wrm.35.1530731816459; Wed, 04 Jul 2018 12:16:56 -0700 (PDT) Received: from lolita.yourcompany.com (188.139.62.94.rev.vodafone.pt. [94.62.139.188]) by smtp.gmail.com with ESMTPSA id x6-v6sm5728905wrd.57.2018.07.04.12.16.55 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Wed, 04 Jul 2018 12:16:55 -0700 (PDT) From: =?utf-8?B?Sm/Do28gVMOhdm9yYQ==?= <joaotavora@HIDDEN> To: Dmitry Gutov <dgutov@HIDDEN> Subject: Re: bug#32034: 26.1; [PACTH] better xref-location-marker for imperfect file locations References: <87y3etsqb7.fsf@HIDDEN> <5ab17038-c13d-3dde-2db9-4bc9a1042235@HIDDEN> <CALDnm50Ed=8vAKCPJZUOYgKnZEuqg31-YDOT5VMYRQ1CNK53Fg@HIDDEN> <eb06fbb5-89e1-9cf4-2c1e-337f41ab6553@HIDDEN> <CALDnm52Ay=DTYebh1j=86E8=iminsn-UXkNMr+H-dbWYYrnP3w@HIDDEN> <f6298956-3a94-e48e-05a1-953e2b3894dd@HIDDEN> <8736wzf7f0.fsf@HIDDEN> <54af7707-12a6-4d89-de8d-b07ac626c898@HIDDEN> <87po03dpcg.fsf@HIDDEN> <7cb55086-b6c0-c7ad-d14b-fe3b81757452@HIDDEN> Date: Wed, 04 Jul 2018 20:16:51 +0100 In-Reply-To: <7cb55086-b6c0-c7ad-d14b-fe3b81757452@HIDDEN> (Dmitry Gutov's message of "Wed, 4 Jul 2018 18:08:08 +0300") Message-ID: <87lgaqerq4.fsf@HIDDEN> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.1 (/) X-Debbugs-Envelope-To: 32034 Cc: 32034 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -0.9 (/) Dmitry Gutov <dgutov@HIDDEN> writes: > On 7/4/18 5:53 PM, Jo=C3=A3o T=C3=A1vora wrote: > >> I don't understand. Will _successful_ navigation ever land me on a spot >> where the identifier I looked for _isn't_ there? > A similar string in the buffer, yes. But it might be not its definition. > > Like in the example I made up, clojure.core/cons -> "(defn cons". If this backend already exists, then I think it is flawed. If it doesn't, then it shouldn't be designed like this. In a better design xref-backend-identifier-at-point would return "cons", propertized with some contextual information (in this case the fact that it belongs to the "clojure.core/" namespace). > And I *do* think, when a hint is not found, the method should raise an > error. This will be helpful for the search-replace functionality. Then maybe that functionality should bind some global variable to control this behavior (in CL this would be done more elegantly with restarts, but we don't have those yet). >>> Similarly if xref-file-location grows a new optional field which >>> defaults to nil. >> >> Only in this case it's more code in the backend, and repeated across >> backends. > > Err, no? In particular, if the new code is in xref-file-location, any > class inheriting from it could use it automatically. No need to repeat > it. We seem to be misunderstanding each other, and perhaps this is not so important. I merely meant that if the behaviour is not the default, then backends will have to repeatedly activate it explicitly. Simplistically, if the default behaviour were good enough for more than 50% of such backends, we're better off making it the default. >> So it would be a good idea to have this in grep/xref grep results after >> all? > > A good one, yes, but not so easily-implemented one. Indeed, I don't fully understand what you have in mind. But maybe (actually hopefully) it could be implemented on top of my simplistic approach. >>> If we use an optional field, we could call ignore-errors around >>> forward-char if that field is present (your proposal number 1). >> >> I don't fully understand this, but I just remembered that it's better to >> have a separate class for another, probably more interesting reason. We >> should just make it a mix-in: that way, we can give "hinted" semantics >> to existing location classes, not just xref-file-location. > > It sounds useful, but I'm not sure how useful it's going to be in > practice. E.g. elisp locations already have their own logic for > that. Etags does, too. Yes, and it could/should be refactored to use the new mixin. Also you're ignoring stuff outside Emacs. The main reason I'm interested in this is, obviously, my own itch. Which in this case is SLY and Eglot. Both need locations and both need hinting. Incidentally, SLY's ancestor SLIME is where all this xref rubbish was lifted from in the first place (mighty fine rubbish mind you :-)). > And if another backend decides not to use xref-file-location, it will > likely do so for reasons incompatible with this mixin's implementation > too. No. Precisely the contrary. In this proposal, the two classes are independent so you needn't scratch one if you just don't like the other. > > Anyway, if you'd like to propose a patch, that could be easier to discuss. >> Regarding ignore-errors, we should (quite independently of the remaining >> discussion) first agree if xref-location-marker should be allowed to >> error at all, and what should happen if it does. > > I think it should. > > (cl-defmethod xref-location-marker ((l xref-bogus-location)) > (user-error "%s" (oref l message))) > > is the canonical example. Yes, but we have to agree how/if to unwind. There are at least three situations: a) Error before the file is found (and buffer created) b) Error after the file is found c) No error I think a) should always happen, but b) should only happen if a global flag is bound (that seems to help your replacer, right?) > And then xref-query-replace-in-results should catch them. I thought > it's doing that already. :-( Jo=C3=A3o
bug-gnu-emacs@HIDDEN:bug#32034; Package emacs.
Full text available.Received: (at 32034) by debbugs.gnu.org; 4 Jul 2018 15:08:20 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Wed Jul 04 11:08:20 2018
Received: from localhost ([127.0.0.1]:46845 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1fajOE-00089D-Jk
for submit <at> debbugs.gnu.org; Wed, 04 Jul 2018 11:08:20 -0400
Received: from mail-ed1-f47.google.com ([209.85.208.47]:39252)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <raaahh@HIDDEN>) id 1fajOC-000890-OL
for 32034 <at> debbugs.gnu.org; Wed, 04 Jul 2018 11:08:18 -0400
Received: by mail-ed1-f47.google.com with SMTP id w14-v6so4279669eds.6
for <32034 <at> debbugs.gnu.org>; Wed, 04 Jul 2018 08:08:16 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
h=sender:subject:to:cc:references:from:message-id:date:user-agent
:mime-version:in-reply-to:content-language:content-transfer-encoding;
bh=qs1DyJzRhYEHXeSFsczP8ofTWa9S3D/JfcyNrXOzal8=;
b=pfMB8l4nWh1cTSkSv20H9AL4ZYrbXfwEe79nZ1KdrGUz0YBPpZFF/ndeOt/KkPYDHw
/QtmojJdRJi3n76h30B9jeYZQXSJnN/RVdxpAqnD5/rD9OO5SjsOcWqOkQ0ExQVrzad8
VcwLdzHhNNNVuCvTAL/2wH49aoKxV7AHVfXjr5JqLIf9CjGJGQ+gJcFjd41rtpIEvsrc
5KvZ1JGQa2HfBHMt9JEc5DnquapCeGjFVfpRDVEIB9uJ7x7NIaroShKBrBMy7ZeR5d+F
UgA7shhG4QepVLiDQFUgx0BFTu6wp4I3gaL5MshDxjVlFESRjBNp2oKh1op0NPtvKerO
zHZw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20161025;
h=x-gm-message-state:sender:subject:to:cc:references:from:message-id
:date:user-agent:mime-version:in-reply-to:content-language
:content-transfer-encoding;
bh=qs1DyJzRhYEHXeSFsczP8ofTWa9S3D/JfcyNrXOzal8=;
b=UOl02VUbBnyn6y/Vt2eVaSiuKvGA1+pzqiFld+u0NUu9+YY8kDINBIYHtdoA6HgMJu
Y0kHbWe9fK+DiSZFqy4bfrt0JUAi/HMMk27hHSYPRNG4x8zx5UjoAq0uSZh3cXZApqdm
qj8dgsWlQ8B31JsTCYjFSgVmVmxKamg0eilYzYpfJj7UJX0yg3jVTZENdGcTct+bQiJc
n/ZWwRCJF9UrLcKoHRL+8mIfbhl59+NHj2JOJw74VB29EDO91IrxbMcnMVRxNJ6FLqwl
M5mzVqQivh8xlqHs0y6RO/RkoAJj0L6FgrWBj1ro3fRb/z99FrJN6DVWIysG6W2D5MzJ
XYbQ==
X-Gm-Message-State: APt69E1amEZzll9JyZjbiTU6AT0d/XrzEvWl8ECrXdTkEiioWWrhQTMo
WeJz/j/IRah9TtzFQx6154hJzZoR
X-Google-Smtp-Source: AAOMgpdFcMbzLFtWnXDgYoAkNmEAkdpP3gAam/A5JSNlcQe90Ag4sqCQ3xY5ozw38DKK0dW8blOrPg==
X-Received: by 2002:a50:afa3:: with SMTP id
h32-v6mr3116983edd.129.1530716890639;
Wed, 04 Jul 2018 08:08:10 -0700 (PDT)
Received: from [192.168.0.200] ([109.110.245.170])
by smtp.googlemail.com with ESMTPSA id
l4-v6sm2828039edk.53.2018.07.04.08.08.08
(version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
Wed, 04 Jul 2018 08:08:09 -0700 (PDT)
Subject: Re: bug#32034: 26.1; [PACTH] better xref-location-marker for
imperfect file locations
To: =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= <joaotavora@HIDDEN>
References: <87y3etsqb7.fsf@HIDDEN>
<5ab17038-c13d-3dde-2db9-4bc9a1042235@HIDDEN>
<CALDnm50Ed=8vAKCPJZUOYgKnZEuqg31-YDOT5VMYRQ1CNK53Fg@HIDDEN>
<eb06fbb5-89e1-9cf4-2c1e-337f41ab6553@HIDDEN>
<CALDnm52Ay=DTYebh1j=86E8=iminsn-UXkNMr+H-dbWYYrnP3w@HIDDEN>
<f6298956-3a94-e48e-05a1-953e2b3894dd@HIDDEN> <8736wzf7f0.fsf@HIDDEN>
<54af7707-12a6-4d89-de8d-b07ac626c898@HIDDEN> <87po03dpcg.fsf@HIDDEN>
From: Dmitry Gutov <dgutov@HIDDEN>
Message-ID: <7cb55086-b6c0-c7ad-d14b-fe3b81757452@HIDDEN>
Date: Wed, 4 Jul 2018 18:08:08 +0300
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101
Thunderbird/60.0
MIME-Version: 1.0
In-Reply-To: <87po03dpcg.fsf@HIDDEN>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-Spam-Score: 0.5 (/)
X-Debbugs-Envelope-To: 32034
Cc: 32034 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -0.5 (/)
On 7/4/18 5:53 PM, João Távora wrote:
> I don't understand. Will _successful_ navigation ever land me on a spot
> where the identifier I looked for _isn't_ there?
A similar string in the buffer, yes. But it might be not its definition.
Like in the example I made up, clojure.core/cons -> "(defn cons".
And I *do* think, when a hint is not found, the method should raise an
error. This will be helpful for the search-replace functionality.
>> Similarly if xref-file-location grows a new optional field which
>> defaults to nil.
>
> Only in this case it's more code in the backend, and repeated across
> backends.
Err, no? In particular, if the new code is in xref-file-location, any
class inheriting from it could use it automatically. No need to repeat it.
> So it would be a good idea to have this in grep/xref grep results after
> all?
A good one, yes, but not so easily-implemented one.
>> If we use an optional field, we could call ignore-errors around
>> forward-char if that field is present (your proposal number 1).
>
> I don't fully understand this, but I just remembered that it's better to
> have a separate class for another, probably more interesting reason. We
> should just make it a mix-in: that way, we can give "hinted" semantics
> to existing location classes, not just xref-file-location.
It sounds useful, but I'm not sure how useful it's going to be in
practice. E.g. elisp locations already have their own logic for that.
Etags does, too.
And if another backend decides not to use xref-file-location, it will
likely do so for reasons incompatible with this mixin's implementation too.
Anyway, if you'd like to propose a patch, that could be easier to discuss.
> Regarding ignore-errors, we should (quite independently of the remaining
> discussion) first agree if xref-location-marker should be allowed to
> error at all, and what should happen if it does.
I think it should.
(cl-defmethod xref-location-marker ((l xref-bogus-location))
(user-error "%s" (oref l message)))
is the canonical example.
And then xref-query-replace-in-results should catch them. I thought it's
doing that already. :-(
bug-gnu-emacs@HIDDEN:bug#32034; Package emacs.
Full text available.Received: (at 32034) by debbugs.gnu.org; 4 Jul 2018 14:53:47 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Wed Jul 04 10:53:46 2018 Received: from localhost ([127.0.0.1]:46832 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1fajAA-0007n3-L2 for submit <at> debbugs.gnu.org; Wed, 04 Jul 2018 10:53:46 -0400 Received: from mail-wm0-f50.google.com ([74.125.82.50]:39880) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <joaotavora@HIDDEN>) id 1fajA8-0007mp-Jk for 32034 <at> debbugs.gnu.org; Wed, 04 Jul 2018 10:53:45 -0400 Received: by mail-wm0-f50.google.com with SMTP id p11-v6so6119618wmc.4 for <32034 <at> debbugs.gnu.org>; Wed, 04 Jul 2018 07:53:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version:content-transfer-encoding; bh=xzqUnVIY90aAiaQ6hJvyouDoukqW8gRTiVLGHUoQflI=; b=Fk3l1tA5guP0hCKDGvj9ZhZCRGAjAi1QAawDAg1GF0+ztYvtkJjbl1Uz98c6EJl8Y4 qxgwjL5LoXKcl3/PhKNKYyE8xeEgEFDxxCcj44hdgCq4BOh3EGyRBQWPtL83Or8Vbp8x 6yAY1+wxeTBAGG9yb/0JgqTGwFp1qm02WvjgzKBV19aTXw8gULBewGd+qamN91ZZbrZr WH4g70Nl8q54eJuWrqSixjfPVVcXfTXmVtfH0RdM/lMpfSS3xrIGb1hbTaG7jKJYtI1F tZur8WvRLoMHPZFnhytkl50zfCafaiFNjtmW6ykvAAVnMfA9pkmUCkn0HgPrkm3bSmwz JHYg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:references:date:in-reply-to :message-id:user-agent:mime-version:content-transfer-encoding; bh=xzqUnVIY90aAiaQ6hJvyouDoukqW8gRTiVLGHUoQflI=; b=B4/6wUY+leDWQG09Q/J/BtnGAu3ynRd9MDtuAc6SbVQ8rdu/dIqwc6szrVLIXfGobZ iw7wQsVLNgzqZPyIO0DsmS6jUwh6zP5u7CeTlnP2CLAUZZQPYEBioCDN7EorWq7PvmBE ZWldDzIUPnY1f+2lnGHGSOJB/AP2t6t4fH8aapWaChoz2gMXas5C0P6mkQXpKhPro+s0 KaFVqo8sbA476YMInCvVhD/z1FbuFyIjz2KT2Qm6qFtLptNqUAeQaNgvqP/wlb4s2MWn ZVNH/kWua1h2lnN2wcChrBenIBj/gtWiCLbouKxY/819O5qZv5efawrHMY0yQ8RKxGAN vZyg== X-Gm-Message-State: APt69E16e8F12JTygtmLDqOVCanvlpLJIJaswGA60n5TuqQZn/h0/hxl MRRDyv0X7XXLksz9AkOIqv5Hji+I X-Google-Smtp-Source: AAOMgpciVPvhuFlo8KjTP1MkIiN2BHTAZGm3NCan0MajSFtYkBQJ6PosH0NB6HV3yYC+KlV3H/V4pQ== X-Received: by 2002:a1c:e3d5:: with SMTP id a204-v6mr1798260wmh.20.1530716018560; Wed, 04 Jul 2018 07:53:38 -0700 (PDT) Received: from lolita.yourcompany.com (188.139.62.94.rev.vodafone.pt. [94.62.139.188]) by smtp.gmail.com with ESMTPSA id b190-v6sm7476371wma.24.2018.07.04.07.53.37 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Wed, 04 Jul 2018 07:53:37 -0700 (PDT) From: =?utf-8?B?Sm/Do28gVMOhdm9yYQ==?= <joaotavora@HIDDEN> To: Dmitry Gutov <dgutov@HIDDEN> Subject: Re: bug#32034: 26.1; [PACTH] better xref-location-marker for imperfect file locations References: <87y3etsqb7.fsf@HIDDEN> <5ab17038-c13d-3dde-2db9-4bc9a1042235@HIDDEN> <CALDnm50Ed=8vAKCPJZUOYgKnZEuqg31-YDOT5VMYRQ1CNK53Fg@HIDDEN> <eb06fbb5-89e1-9cf4-2c1e-337f41ab6553@HIDDEN> <CALDnm52Ay=DTYebh1j=86E8=iminsn-UXkNMr+H-dbWYYrnP3w@HIDDEN> <f6298956-3a94-e48e-05a1-953e2b3894dd@HIDDEN> <8736wzf7f0.fsf@HIDDEN> <54af7707-12a6-4d89-de8d-b07ac626c898@HIDDEN> Date: Wed, 04 Jul 2018 15:53:35 +0100 In-Reply-To: <54af7707-12a6-4d89-de8d-b07ac626c898@HIDDEN> (Dmitry Gutov's message of "Wed, 4 Jul 2018 17:33:42 +0300") Message-ID: <87po03dpcg.fsf@HIDDEN> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.1 (/) X-Debbugs-Envelope-To: 32034 Cc: 32034 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -0.9 (/) Dmitry Gutov <dgutov@HIDDEN> writes: > On 7/4/18 4:37 PM, Jo=C3=A3o T=C3=A1vora wrote: > >> Still better than failing randomly. Especially if you hint that the >> match was approximate (much like the way diff tell you about "fuzz"). > > The problem is it will "break" correct navigations sometimes. I don't understand. Will _successful_ navigation ever land me on a spot where the identifier I looked for _isn't_ there? >> Anyway, those totally hypothetic future users of the class could well >> and polish the default behaviour if they decided it's worth it. > > Suppose we use a new class. If the hint argument is mandatory, then > there should be no problem: the backend explicitly asked for this > behavior. Yes, we agree. > Similarly if xref-file-location grows a new optional field which > defaults to nil. Only in this case it's more code in the backend, and repeated across backends. >>> It can certainly become outdated if the user has added or deleted a >>> couple of lines there. >> >> But then, in that case, isn't it much better to find an actual match >> (and perhaps warn) than to land the user in nowhereland? > > Yes. And in Grep results, it might be beneficial to use the new > behavior. The code creating the locations will pass line's contents as > the "hint" (and maybe we should make the hint a regexp, to be able to > use the line-beginning and line-ending anchors). In that use case, > though, it would be better to error out if the hint is not found. > > I'm somewhat worried about what will happen if a hint misdetects a > match anyway, and we're in many-automatic-edits land (such as > xref-query-replace-in-results), but on the balance, it'll probably be > better than the current behavior anyway. > > Except for, err... lines with several matches on them. Not sure what > to do about those. A special class, probably. So it would be a good idea to have this in grep/xref grep results after all? >> Because I want something with some default behaviour. Behaviour that is >> admittely half-decent, but nevertheless better than current behaviour. >> But since you showed that xref-location-marker is used by your grep >> substitute, I don't want to cause any regressions in its existing, >> broken behaviour, whatever that may be exactly. >> >>> It might be shorter implementation-wise, too. >> >> This is how I imagine the implementation: >> >> (defclass xref-hinted-location (xref-file-location) >> ((hint :initarg :hint)))) >> (cl-defmethod xref-location-marker :around ((l >> xref-hinted-location)) >> <...code to search around...>) >> >> Compared to the "add optional field" approach, there would be about 1 ex= tra line, >> the defclass one. > > If we use an optional field, we could call ignore-errors around > forward-char if that field is present (your proposal number 1). I don't fully understand this, but I just remembered that it's better to have a separate class for another, probably more interesting reason. We should just make it a mix-in: that way, we can give "hinted" semantics to existing location classes, not just xref-file-location. Regarding ignore-errors, we should (quite independently of the remaining discussion) first agree if xref-location-marker should be allowed to error at all, and what should happen if it does.
bug-gnu-emacs@HIDDEN:bug#32034; Package emacs.
Full text available.Received: (at 32034) by debbugs.gnu.org; 4 Jul 2018 14:33:54 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Wed Jul 04 10:33:54 2018 Received: from localhost ([127.0.0.1]:46825 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1faiqv-0007LS-TB for submit <at> debbugs.gnu.org; Wed, 04 Jul 2018 10:33:54 -0400 Received: from mail-ed1-f47.google.com ([209.85.208.47]:39538) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <raaahh@HIDDEN>) id 1faiqu-0007LF-7k for 32034 <at> debbugs.gnu.org; Wed, 04 Jul 2018 10:33:52 -0400 Received: by mail-ed1-f47.google.com with SMTP id w14-v6so4206467eds.6 for <32034 <at> debbugs.gnu.org>; Wed, 04 Jul 2018 07:33:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=4XZ3SjtZOnexdAtKFZTmvDvFw/vNw4xEb+uITWKyPhw=; b=OV6nKhR5L9KN0me+ndSV9jq/rVJtikImPEsdtDOO+T8h2t6KfvR7aWdMAx6MmqslVl 63KlHU9NejQdTM5wu3Ts+FhR0B+UQdy0WqERri48DphvMmna71oyFz5ob00lKS5xBzSx YcC3Pwyon/6FoM6w9EWmRRY2NbnIT9uA+uoVZC1bKIqikWmJu5fKeRyn3XgE/dZuzf56 LPPndqjM0hN2H+apzqEZBGgQWW25Qdz6dBep3VrFEK2a2T6aOGXbPj/V7+SS6Uc8VBvP c0i+NEuWeHzUsMbIDxakxqvmKUmV82Gg92L+Y1jPawCNT8D5X3dzLIMYo5tqrnDMjHOO cLJA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:subject:to:cc:references:from:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=4XZ3SjtZOnexdAtKFZTmvDvFw/vNw4xEb+uITWKyPhw=; b=K5/mQPBiTPIZh8dKRbpRISBaXcb99XFt1evge4KKgnlvV74AJ8QaAGZDHySSv6kI7W 7dmX0M0tpCRS3wBXvFk0yzRfc9bIRkBY+DvEVmS9ljOOuJ0LUllRkMRnbaN2in9U32BR 7GccD+JN16FMKSV6nyzsShvA3/8j2Vi6yu+qKSXsCE1VnV4BGUiTA4SI7zT+SNIi+IcB Hv9sEHeRpG9CV3FMUl/QaJ3buMZJl0p3uN8xOFygeF2MGcEHKUxuZnx28Zb1aN+k3gUj /7LxpLuxe/wn1PT0+tSXiQocyojMx0XwbglC11WsFjC28qb0LwT/IAcNQKEPtfxBt1P1 L+zA== X-Gm-Message-State: APt69E1OJHCIIKqKrdZvdFfWzDjMpuhkt3OFjXq/OLDuYEOeYqQ6kC8J Td+gF7IEu8slhGms4BAjaciZU+7Q X-Google-Smtp-Source: AAOMgpdvLR9NMsX9JtVxOp7C3EG+ZLMYhPSILd7mMRbjxzL85SwLxjsIy3dlaGwii5V73xHvxfDwug== X-Received: by 2002:a50:b613:: with SMTP id b19-v6mr3006127ede.255.1530714826145; Wed, 04 Jul 2018 07:33:46 -0700 (PDT) Received: from [192.168.0.200] ([109.110.245.170]) by smtp.googlemail.com with ESMTPSA id c21-v6sm1838714edr.78.2018.07.04.07.33.44 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 04 Jul 2018 07:33:45 -0700 (PDT) Subject: Re: bug#32034: 26.1; [PACTH] better xref-location-marker for imperfect file locations To: =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= <joaotavora@HIDDEN> References: <87y3etsqb7.fsf@HIDDEN> <5ab17038-c13d-3dde-2db9-4bc9a1042235@HIDDEN> <CALDnm50Ed=8vAKCPJZUOYgKnZEuqg31-YDOT5VMYRQ1CNK53Fg@HIDDEN> <eb06fbb5-89e1-9cf4-2c1e-337f41ab6553@HIDDEN> <CALDnm52Ay=DTYebh1j=86E8=iminsn-UXkNMr+H-dbWYYrnP3w@HIDDEN> <f6298956-3a94-e48e-05a1-953e2b3894dd@HIDDEN> <8736wzf7f0.fsf@HIDDEN> From: Dmitry Gutov <dgutov@HIDDEN> Message-ID: <54af7707-12a6-4d89-de8d-b07ac626c898@HIDDEN> Date: Wed, 4 Jul 2018 17:33:42 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.0 MIME-Version: 1.0 In-Reply-To: <8736wzf7f0.fsf@HIDDEN> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Spam-Score: 0.5 (/) X-Debbugs-Envelope-To: 32034 Cc: 32034 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -0.5 (/) On 7/4/18 4:37 PM, João Távora wrote: > Still better than failing randomly. Especially if you hint that the > match was approximate (much like the way diff tell you about "fuzz"). The problem is it will "break" correct navigations sometimes. > Anyway, those totally hypothetic future users of the class could well > and polish the default behaviour if they decided it's worth it. Suppose we use a new class. If the hint argument is mandatory, then there should be no problem: the backend explicitly asked for this behavior. Similarly if xref-file-location grows a new optional field which defaults to nil. >> It can certainly become outdated if the user has added or deleted a >> couple of lines there. > > But then, in that case, isn't it much better to find an actual match > (and perhaps warn) than to land the user in nowhereland? Yes. And in Grep results, it might be beneficial to use the new behavior. The code creating the locations will pass line's contents as the "hint" (and maybe we should make the hint a regexp, to be able to use the line-beginning and line-ending anchors). In that use case, though, it would be better to error out if the hint is not found. I'm somewhat worried about what will happen if a hint misdetects a match anyway, and we're in many-automatic-edits land (such as xref-query-replace-in-results), but on the balance, it'll probably be better than the current behavior anyway. Except for, err... lines with several matches on them. Not sure what to do about those. A special class, probably. > Because I want something with some default behaviour. Behaviour that is > admittely half-decent, but nevertheless better than current behaviour. > But since you showed that xref-location-marker is used by your grep > substitute, I don't want to cause any regressions in its existing, > broken behaviour, whatever that may be exactly. > >> It might be shorter implementation-wise, too. > > This is how I imagine the implementation: > > (defclass xref-hinted-location (xref-file-location) > ((hint :initarg :hint)))) > > (cl-defmethod xref-location-marker :around ((l xref-hinted-location)) > <...code to search around...>) > > Compared to the "add optional field" approach, there would be about 1 extra line, > the defclass one. If we use an optional field, we could call ignore-errors around forward-char if that field is present (your proposal number 1).
bug-gnu-emacs@HIDDEN:bug#32034; Package emacs.
Full text available.Received: (at 32034) by debbugs.gnu.org; 4 Jul 2018 13:38:08 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Wed Jul 04 09:38:08 2018
Received: from localhost ([127.0.0.1]:46030 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1fahyx-0005qs-KX
for submit <at> debbugs.gnu.org; Wed, 04 Jul 2018 09:38:07 -0400
Received: from mail-wm0-f51.google.com ([74.125.82.51]:38512)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <joaotavora@HIDDEN>) id 1fahyv-0005qJ-4X
for 32034 <at> debbugs.gnu.org; Wed, 04 Jul 2018 09:38:05 -0400
Received: by mail-wm0-f51.google.com with SMTP id 69-v6so5741455wmf.3
for <32034 <at> debbugs.gnu.org>; Wed, 04 Jul 2018 06:38:05 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
h=from:to:cc:subject:references:date:in-reply-to:message-id
:user-agent:mime-version:content-transfer-encoding;
bh=UbErWz8R3KnmzBJ5dI75VnDUI1ashHxr6OvT7783FA0=;
b=WSLeq2e/9CU6aTY4ZYZz6fYKNaMijnrxFgGV1EAU93oWV4Bbx0hpCnTjVejc7cwQ/+
L4UNNbOuvgEOZWJN6B4GgYHme+yrlyJVAqA2OQtk/jQsiDnMAgLt6qXemgb9pbPK+8VS
9j7nEZyFoq2I8Tn475NV3IOVMxJL7GA081uB9w7xLR695hW6sCUAVTvZKhUmJNVH1dn8
/HageWUUzG4vrgFWv0ZyfZAXxlyUESizypb/Va/1/E/tVqriWzOHhnVIW093/aCRJUDi
QyEHLk/jUlv/DyUL3GWThLDdJmgP84hQqNe3uLRXkg2z4s8WvVms634Q8GzzOjhVmKyJ
SmmQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20161025;
h=x-gm-message-state:from:to:cc:subject:references:date:in-reply-to
:message-id:user-agent:mime-version:content-transfer-encoding;
bh=UbErWz8R3KnmzBJ5dI75VnDUI1ashHxr6OvT7783FA0=;
b=IaQy6Ep5rEbKaWny6J6LE/mbErVsgJu12yTU19putLQQKP4BGRyvEbKtY7/tD+4ZNA
OjS0jhjkCISXYqDFyNfbf3X2GUEu9xiHyJBehVP4xRI78eEweWezMGJY1t0Oj0DEwDAs
bG7qx9mfQueAbGF7Y/PJxa4ucM2rZriYPY1vk/QG1ZE5fvZYQGA0CzY7m9IpmLBEitWZ
inp5BWAs9rGkzR9dBCtOm8s/uHXba2L06ibmRmw8kvk1LWr1Kfbn9VyE6tuaC36RdoI6
5Jue1WJPxf/FTWYkthL06UYd+aqMmfrYvbNToSiO9/r4jgVA+rTwiVKty9Mn7hJzrHc4
cBlg==
X-Gm-Message-State: APt69E3BrHyDpwZdxCcIIaVOVzErilAbQz9jrBHgx+BD0hu9953G5eDn
X9f5ChTveAOeRNULpbN6IQ0AENks
X-Google-Smtp-Source: AAOMgpcYOs2JXKwzCRY4Enuth4MTjT0k1JNzoandHuM0u2wpO6+IlXPTfziHTmd54KwrlaV1mTnKxQ==
X-Received: by 2002:a1c:8010:: with SMTP id
b16-v6mr1762814wmd.41.1530711479056;
Wed, 04 Jul 2018 06:37:59 -0700 (PDT)
Received: from lolita.yourcompany.com (188.139.62.94.rev.vodafone.pt.
[94.62.139.188])
by smtp.gmail.com with ESMTPSA id s200-v6sm8520154wmb.44.2018.07.04.06.37.57
(version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256);
Wed, 04 Jul 2018 06:37:58 -0700 (PDT)
From: =?utf-8?B?Sm/Do28gVMOhdm9yYQ==?= <joaotavora@HIDDEN>
To: Dmitry Gutov <dgutov@HIDDEN>
Subject: Re: bug#32034: 26.1;
[PACTH] better xref-location-marker for imperfect file locations
References: <87y3etsqb7.fsf@HIDDEN>
<5ab17038-c13d-3dde-2db9-4bc9a1042235@HIDDEN>
<CALDnm50Ed=8vAKCPJZUOYgKnZEuqg31-YDOT5VMYRQ1CNK53Fg@HIDDEN>
<eb06fbb5-89e1-9cf4-2c1e-337f41ab6553@HIDDEN>
<CALDnm52Ay=DTYebh1j=86E8=iminsn-UXkNMr+H-dbWYYrnP3w@HIDDEN>
<f6298956-3a94-e48e-05a1-953e2b3894dd@HIDDEN>
Date: Wed, 04 Jul 2018 14:37:55 +0100
In-Reply-To: <f6298956-3a94-e48e-05a1-953e2b3894dd@HIDDEN> (Dmitry Gutov's
message of "Wed, 4 Jul 2018 15:58:53 +0300")
Message-ID: <8736wzf7f0.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: 0.1 (/)
X-Debbugs-Envelope-To: 32034
Cc: 32034 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -0.9 (/)
Dmitry Gutov <dgutov@HIDDEN> writes:
> On 7/3/18 6:43 PM, Jo=C3=A3o T=C3=A1vora wrote:
>
> Maybe it's not in a docstring, but in some macro definition, or passed
> verbatim in some other language construct. Maybe it's part of some
> other definition name (separate definitions for methods in C++ come to
> mind).
Still better than failing randomly. Especially if you hint that the
match was approximate (much like the way diff tell you about "fuzz").
Anyway, those totally hypothetic future users of the class could well
and polish the default behaviour if they decided it's worth it.
> It can certainly become outdated if the user has added or deleted a
> couple of lines there.
But then, in that case, isn't it much better to find an actual match
(and perhaps warn) than to land the user in nowhereland?
Sure it won't probably won't beat the etags backend in the percentage of
times it gets it right. But that's a quantitative difference, not
qualitative.
> I'm not sure we really need a subclass if a new optional field would
> work just as well.
Because I want something with some default behaviour. Behaviour that is
admittely half-decent, but nevertheless better than current behaviour.
But since you showed that xref-location-marker is used by your grep
substitute, I don't want to cause any regressions in its existing,
broken behaviour, whatever that may be exactly.
> It might be shorter implementation-wise, too.
This is how I imagine the implementation:
(defclass xref-hinted-location (xref-file-location)
((hint :initarg :hint))))
=20=20=20=20
(cl-defmethod xref-location-marker :around ((l xref-hinted-location))
<...code to search around...>)
Compared to the "add optional field" approach, there would be about 1 extra=
line,
the defclass one.
Jo=C3=A3o
bug-gnu-emacs@HIDDEN:bug#32034; Package emacs.
Full text available.Received: (at 32034) by debbugs.gnu.org; 4 Jul 2018 12:59:06 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Wed Jul 04 08:59:06 2018 Received: from localhost ([127.0.0.1]:46009 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1fahNC-0004rv-2g for submit <at> debbugs.gnu.org; Wed, 04 Jul 2018 08:59:06 -0400 Received: from mail-ed1-f43.google.com ([209.85.208.43]:39704) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <raaahh@HIDDEN>) id 1fahN9-0004rJ-22 for 32034 <at> debbugs.gnu.org; Wed, 04 Jul 2018 08:59:03 -0400 Received: by mail-ed1-f43.google.com with SMTP id w14-v6so3999511eds.6 for <32034 <at> debbugs.gnu.org>; Wed, 04 Jul 2018 05:59:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=yMUWW5s/+19vpbQmFQdNPFi4xKyHnxmzzfPxXSSo37Y=; b=bHunUl96TDQs0cUh7V+0Yf5GTCCYa8XsfNNSLW1mG9UVZ596MY0QdlhZPuM+PJIwQx KuwNzIpR3zuEIL07bOhqCO1/psa41AYKm6tgSAwGrxNc2Hc6th4DP5WSBHdqY2mmFf/8 fJTQbsWdvOdaJAOe3FLwcomzRaMfVh1cKQ36npbjbWVbGzbcIwzW6NmJYNf/5W3Mscj5 B2zDRtR9hLTK2yss8AIERTiF+fMce8DDhwpAeNPoovQe4lMRmlKrsAa6jN5rGbDnQP0G cdJjDnai4LukC5t2DR9eNBuE3Nosl6GIDfEsKZP6CSF5f5ZadvNafsqBqo+D7g7yqTAq L7SA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:subject:to:cc:references:from:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=yMUWW5s/+19vpbQmFQdNPFi4xKyHnxmzzfPxXSSo37Y=; b=HMCRkeGi3f+Qz9yjBnjyKk5QMlfF2o0m+Mel5Joc0tKTk83RuF/lEKFJQSLCiZjXIH mY9eQ329+hQDTarXeQ+FR+H0JI57y3pAu7sDS+YAeeQMB0bYWp0nwVy4rSPUu+LePQfU dd32B5MdnlBUY+v3OK96eu++J8uQvnwSO0GUweGYsAq6yyUmx0UDasa3rKqQumQxozrG UGgdWMFy54es6sjAuY9T6DoALaeflfH8R09jbt0GkF0KF3+JcV76MZAUrZFuYIjkrQ+Y hedkFxcX0GQ3K6e2isw1Rly5fxBNOjYxf0MUojfGbmhTnQt11ru5BVmjB9I3o/j/NkhB SdfQ== X-Gm-Message-State: APt69E3NHYCtnM0uHUHSthTmZrer6X2C29qe4A2ucg95mktNyjBdYKP3 RjO/7Jc1iJqnt6TEku2b2X8SsU2g X-Google-Smtp-Source: AAOMgpeTa7jkeNVXeyzfLANwA3k0b2PFl4JkB0vNfegE9h9Me28aVK6dlegcIrJ4ZzZr1VGF4AyLHw== X-Received: by 2002:a50:a846:: with SMTP id j64-v6mr2648463edc.210.1530709136981; Wed, 04 Jul 2018 05:58:56 -0700 (PDT) Received: from [192.168.0.200] ([109.110.245.170]) by smtp.googlemail.com with ESMTPSA id x11-v6sm4309783edb.39.2018.07.04.05.58.55 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 04 Jul 2018 05:58:55 -0700 (PDT) Subject: Re: bug#32034: 26.1; [PACTH] better xref-location-marker for imperfect file locations To: =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= <joaotavora@HIDDEN> References: <87y3etsqb7.fsf@HIDDEN> <5ab17038-c13d-3dde-2db9-4bc9a1042235@HIDDEN> <CALDnm50Ed=8vAKCPJZUOYgKnZEuqg31-YDOT5VMYRQ1CNK53Fg@HIDDEN> <eb06fbb5-89e1-9cf4-2c1e-337f41ab6553@HIDDEN> <CALDnm52Ay=DTYebh1j=86E8=iminsn-UXkNMr+H-dbWYYrnP3w@HIDDEN> From: Dmitry Gutov <dgutov@HIDDEN> Message-ID: <f6298956-3a94-e48e-05a1-953e2b3894dd@HIDDEN> Date: Wed, 4 Jul 2018 15:58:53 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.0 MIME-Version: 1.0 In-Reply-To: <CALDnm52Ay=DTYebh1j=86E8=iminsn-UXkNMr+H-dbWYYrnP3w@HIDDEN> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Spam-Score: 0.5 (/) X-Debbugs-Envelope-To: 32034 Cc: 32034 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -0.5 (/) On 7/3/18 6:43 PM, João Távora wrote: > No, no error. Stays put. So no worse. If it doesn't find the qualified symbol name somewhere else verbatim. > We could avoid that (particulary far fetched) case (and the string case) > by checking syntax. I wouldn't say it's far-fetched. More importantly, it adds a non-obvious condition on how symbol names should be presented in the completion table. Even if this gun doesn't shoot most of the time. Maybe it's not in a docstring, but in some macro definition, or passed verbatim in some other language construct. Maybe it's part of some other definition name (separate definitions for methods in C++ come to mind). > Oh, I must have misgrepped then. Excuse my ignorance, but are these > grep-like tools? If so, they shouldn't ever suffer from the "outdated" > malaise, right? Well, the grep results buffer can (and often does) live after the user has opened one of the search results and made a change there. It can certainly become outdated if the user has added or deleted a couple of lines there. > I guess a new xref-hinted-location subclass would be the way to go, if > not too much work. But still think we should do something by default > that will do just as bad on the worst case. "won't do"? I'm unclear on your meaning here. I'm not sure we really need a subclass if a new optional field would work just as well. It might be shorter implementation-wise, too.
bug-gnu-emacs@HIDDEN:bug#32034; Package emacs.
Full text available.Received: (at 32034) by debbugs.gnu.org; 3 Jul 2018 15:43:46 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Tue Jul 03 11:43:46 2018 Received: from localhost ([127.0.0.1]:45617 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1faNSz-0002FC-Lf for submit <at> debbugs.gnu.org; Tue, 03 Jul 2018 11:43:45 -0400 Received: from mail-it0-f46.google.com ([209.85.214.46]:32771) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <joaotavora@HIDDEN>) id 1faNSy-0002Ey-2d for 32034 <at> debbugs.gnu.org; Tue, 03 Jul 2018 11:43:44 -0400 Received: by mail-it0-f46.google.com with SMTP id y124-v6so4084862itc.0 for <32034 <at> debbugs.gnu.org>; Tue, 03 Jul 2018 08:43:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=BBQ4KUdSxvkCrZnV5xfLck+0OYfm+YWD6jsVF6iNGms=; b=JlfGEb5F1xsH5aDd4ORViHp4wI31X5fxVk2DYctWmqozv/hJd0lluLkgRTIE4/fdCy OyBkPRgoc+wU0bozfZ8suVcTtcfHGS6huPsAnR8T5RgDLC9mK5j2bkEdQh5EdELqoNB7 aO93661O7Z1A1j4sYTG+q+Rgb6sI3yOa0/L86OWJkJYQegsqC+luRoCPfKuyCZDJOEvf A9m00luqFCyYlRbqh+wRr+Gt4YW0Dbq9B6QPDt8WWA6546TAiN3Or/ue6oSKC0FchdhK cyLduF2RgAGaocOVWzj+Ylc0A048fwUfQ2USaqRe1PI0iI+g5j1X7YEessGYn8aleqDe U6Fg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=BBQ4KUdSxvkCrZnV5xfLck+0OYfm+YWD6jsVF6iNGms=; b=Gt47ucrQg4i0AlE3u/8zivR85sHEV+KsqHA7I2fimNgNu3TPe43UOMN88TTZo0UgRY lUOrLjk5XbAtkPEsYBmvv3LlGm4dICTmECf7WUnYObmgt9AMjcllsTJ/+USvvY8dkN8/ dbtYrT8BKFE9CkB9kg4ZalnZ8k7Hi7Qkve4mhdboVIVYn03NVm9b1nSEb1hMKtZKfIF/ o4f+QqQfPAW0K7Y4jozkPdnAtETw+Ub7ET8q72Hrd4hwJ4tlXwhY2suglUD9Oh8pMbDQ VvMX2Wh6da7dFpn48l7aUMfoNrhOh4ATNu1mM9mnfc3lQTfA6+erzogdN3VeF5swrq2u VQ7g== X-Gm-Message-State: APt69E285seeiQgy9lFTAt3wqj72lzuk+r02BaVyCSW79XMNJQubCEtn 90zWlDAgbIPfcyWwG378PPuhldw4xw+F5EwcP6w= X-Google-Smtp-Source: AAOMgpdFV8BZVTrQrxTilyR733gTlFb4yjdtiQOaco+wdxeROFztodrYpz2MXXsT9oQfNnZvvKq283/AQiJwewEwOhA= X-Received: by 2002:a02:664b:: with SMTP id l11-v6mr25351830jaf.70.1530632618279; Tue, 03 Jul 2018 08:43:38 -0700 (PDT) MIME-Version: 1.0 References: <87y3etsqb7.fsf@HIDDEN> <5ab17038-c13d-3dde-2db9-4bc9a1042235@HIDDEN> <CALDnm50Ed=8vAKCPJZUOYgKnZEuqg31-YDOT5VMYRQ1CNK53Fg@HIDDEN> <eb06fbb5-89e1-9cf4-2c1e-337f41ab6553@HIDDEN> In-Reply-To: <eb06fbb5-89e1-9cf4-2c1e-337f41ab6553@HIDDEN> From: =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= <joaotavora@HIDDEN> Date: Tue, 3 Jul 2018 16:43:26 +0100 Message-ID: <CALDnm52Ay=DTYebh1j=86E8=iminsn-UXkNMr+H-dbWYYrnP3w@HIDDEN> Subject: Re: bug#32034: 26.1; [PACTH] better xref-location-marker for imperfect file locations To: Dmitry Gutov <dgutov@HIDDEN> Content-Type: multipart/alternative; boundary="0000000000007e944805701a2d2d" X-Spam-Score: 0.1 (/) X-Debbugs-Envelope-To: 32034 Cc: 32034 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -0.9 (/) --0000000000007e944805701a2d2d Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Jul 3, 2018, 16:07 Dmitry Gutov <dgutov@HIDDEN> wrote: > On 7/3/18 5:50 PM, Jo=C3=A3o T=C3=A1vora wrote: > > > Right, this should go into xref-goto-xref (or whatever it is called) or > > xref-find-definitions. Or scratched, if it's too much work, because > > it's not terribly useful. > > I'm sure it will be useful in some situations, I'm just not sure about > the odds. > > > In that special case we will do no worse than the current version, > > wouldn't we? > > We would. > > Say, we're looking for clojure.core/cons, and the marker leads us to > "(defn cons" (the example is largely made up). The code looks for > clojure.core/cons, doesn't find it, and signals an error (will it?). > No, no error. Stays put. So no worse. > > Or worse, searches around and finds a verbatim reference to > clojure.core/cons in a docstring somewhere in that file, and returns > *that* location. > We could avoid that (particulary far fetched) case (and the string case) by checking syntax. > > At this point, I'm thinking of dismissing the whole thing, and voting t= o > > deprecate xref-file-location entirely. Nobody uses it and Eglot will > > probably use something else before this issue is solved. > > Err, it is used: in xref--collect-matches-1. And through it, in > xref-collect-matches and xref-collect-references. > Oh, I must have misgrepped then. Excuse my ignorance, but are these grep-like tools? If so, they shouldn't ever suffer from the "outdated" malaise, right? > > > It's a shame > > we can't share code, but if we can't give a default class any kind of > > useful behavior, we might as well not have this class in the first plac= e. > > We could. As long as we don't default to the identifier, and the backend > has to explicitly provide the hint, we could be fine. > I guess a new xref-hinted-location subclass would be the way to go, if not too much work. But still think we should do something by default that will do just as bad on the worst case. And if we use a new subclass, we're guaranteed that. > --0000000000007e944805701a2d2d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir=3D"auto"><div><div class=3D"gmail_quote"><div dir=3D"ltr">On Tue, = Jul 3, 2018, 16:07 Dmitry Gutov <<a href=3D"mailto:dgutov@HIDDEN">dgu= tov@HIDDEN</a>> wrote:<br></div><blockquote class=3D"gmail_quote" sty= le=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 7/3= /18 5:50 PM, Jo=C3=A3o T=C3=A1vora wrote:<br> <br> > Right, this should go into xref-goto-xref (or whatever it is called) o= r <br> > xref-find-definitions.=C2=A0 Or scratched, if it's too much work, = because <br> > it's not terribly useful.<br> <br> I'm sure it will be useful in some situations, I'm just not sure ab= out <br> the odds.<br> <br> > In that special case we will do no worse than the current version, <br= > > wouldn't we?<br> <br> We would.<br> <br> Say, we're looking for clojure.core/cons, and the marker leads us to <b= r> "(defn cons" (the example is largely made up). The code looks for= <br> clojure.core/cons, doesn't find it, and signals an error (will it?).<br= ></blockquote></div></div><div dir=3D"auto"><br></div><div dir=3D"auto">No,= no error. Stays put. So no worse.</div><div dir=3D"auto"><div class=3D"gma= il_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bord= er-left:1px #ccc solid;padding-left:1ex"><br> Or worse, searches around and finds a verbatim reference to <br> clojure.core/cons in a docstring somewhere in that file, and returns <br> *that* location.<br></blockquote></div></div><div dir=3D"auto"><br></div><d= iv dir=3D"auto">We could avoid that (particulary far fetched) case (and the= string case) by checking syntax.</div><div dir=3D"auto"><br></div><div dir= =3D"auto"><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" styl= e=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br> > At this point, I'm thinking of dismissing the whole thing, and vot= ing to <br> > deprecate xref-file-location entirely. Nobody uses it and Eglot will <= br> > probably use something else before this issue is solved. <br> <br> Err, it is used: in xref--collect-matches-1. And through it, in <br> xref-collect-matches and xref-collect-references.<br></blockquote></div></d= iv><div dir=3D"auto"><br></div><div dir=3D"auto">Oh, I must have misgrepped= then. Excuse my ignorance, but are these grep-like tools? If so, they shou= ldn't ever suffer from the "outdated" malaise, right?</div><d= iv dir=3D"auto"><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote= " style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> <br> > It's a shame <br> > we can't share code, but if we can't give a default class any = kind of <br> > useful behavior, we might as well not have this class in the first pla= ce.<br> <br> We could. As long as we don't default to the identifier, and the backen= d <br> has to explicitly provide the hint, we could be fine.<br></blockquote></div= ></div><div dir=3D"auto"><br></div><div dir=3D"auto">I guess a new xref-hin= ted-location subclass would be the way to go, if not too much work.=C2=A0 B= ut still think we should do something by default that will do just as bad o= n the worst case. And if we use a new subclass, we're guaranteed that.<= /div><div dir=3D"auto"><div class=3D"gmail_quote"><blockquote class=3D"gmai= l_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left= :1ex"></blockquote></div></div><div dir=3D"auto"><br></div><div dir=3D"auto= "><br></div><div dir=3D"auto"><div class=3D"gmail_quote"><blockquote class= =3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd= ing-left:1ex"> </blockquote></div></div></div> --0000000000007e944805701a2d2d--
bug-gnu-emacs@HIDDEN:bug#32034; Package emacs.
Full text available.Received: (at 32034) by debbugs.gnu.org; 3 Jul 2018 15:08:05 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Tue Jul 03 11:08:05 2018 Received: from localhost ([127.0.0.1]:45589 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1faMuS-0001Np-Qc for submit <at> debbugs.gnu.org; Tue, 03 Jul 2018 11:08:04 -0400 Received: from mail-ed1-f54.google.com ([209.85.208.54]:42332) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <raaahh@HIDDEN>) id 1faMuR-0001NL-EF for 32034 <at> debbugs.gnu.org; Tue, 03 Jul 2018 11:08:03 -0400 Received: by mail-ed1-f54.google.com with SMTP id g12-v6so1863131edi.9 for <32034 <at> debbugs.gnu.org>; Tue, 03 Jul 2018 08:08:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=9AYBIU/HHPXSiBbXXIbfDgF/3TML1OTGwDVpO4/j14A=; b=kOXwmc5WKEPsypopmTWvby3eFG2VyHf7935FmdfccVuEuZNCcxNPPitnIhsmY2pL9a gADPcGQbHj3quU1DN+RnwZ2INdvITKMH2E/oAC0o7t46G1dG43Ad/oX2VR3W3oV/DTWq i5Fr+GrSc9wE0pZ8rwjClTKeo7wdJLBEcPzEsJaAf4/vY+Mg5KAQ83JJGmXUNMFFSQsb sKWt4j7NBb19Uk3UjRc/0q1qLMtc26STRIkl4lOGu+AtXxo7dVf+4TDxX/W+No1UF2Bz yvV0M7gqIcmhofXy3Fhd6oPC7hIxtkQw8dpW5OQR8Q449z+Cxg+9d/shBIFWn71CmmtL 2UWw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:subject:to:cc:references:from:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=9AYBIU/HHPXSiBbXXIbfDgF/3TML1OTGwDVpO4/j14A=; b=UvdHCcsO4t6b3wKDJyMDSGivyIncm0kGk8T/bEf5ql9xx0oxdvMPIHq7Ijny/cefHX frrcfSjlifdxsusMQUPi5mXZZ5Bd5RDhmEGmTDXsVUt95jQC5dbyN5djAFhTKS0dsedp 7DKSZvHxy+Krye1HvjufBx5Qj3pxmk+hbkCP0HMY8q9zJxQ9FCiIaYrHUjkznX6JenB9 ahrFVpXhSUmcbe4aPcc1NmZe0wG3bFHhjWy3jrknGaRM0zwS4Ic7ZkTm6JjRRjSFEOxn WiOJzX8S7BRxLZCcRiZ3VVpNMP1Et9p1nl24+9Cj/dhAHaTSSqQHrol5XszMkdZh35UN aXKg== X-Gm-Message-State: APt69E2cyXjAfXielA8RcnEYIhIrET71IHpxaIfTHfN2mHncqYnDBc6U j1zpjXurP8kRT6vh3DdgdCiW3+D/ X-Google-Smtp-Source: AAOMgpcAI01tBT1rrKbjb9InxGkWq792yDBEhhPwKCJgiMbTYiOD/v7KXsGYVdXM4fc2gFIcWijV6A== X-Received: by 2002:a50:93c5:: with SMTP id o63-v6mr28492696eda.311.1530630477475; Tue, 03 Jul 2018 08:07:57 -0700 (PDT) Received: from [192.168.0.200] ([109.110.245.170]) by smtp.googlemail.com with ESMTPSA id z11-v6sm776576edq.71.2018.07.03.08.07.55 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 03 Jul 2018 08:07:56 -0700 (PDT) Subject: Re: bug#32034: 26.1; [PACTH] better xref-location-marker for imperfect file locations To: =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= <joaotavora@HIDDEN> References: <87y3etsqb7.fsf@HIDDEN> <5ab17038-c13d-3dde-2db9-4bc9a1042235@HIDDEN> <CALDnm50Ed=8vAKCPJZUOYgKnZEuqg31-YDOT5VMYRQ1CNK53Fg@HIDDEN> From: Dmitry Gutov <dgutov@HIDDEN> Message-ID: <eb06fbb5-89e1-9cf4-2c1e-337f41ab6553@HIDDEN> Date: Tue, 3 Jul 2018 18:07:54 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.0 MIME-Version: 1.0 In-Reply-To: <CALDnm50Ed=8vAKCPJZUOYgKnZEuqg31-YDOT5VMYRQ1CNK53Fg@HIDDEN> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Spam-Score: 0.5 (/) X-Debbugs-Envelope-To: 32034 Cc: 32034 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -0.5 (/) On 7/3/18 5:50 PM, João Távora wrote: > Right, this should go into xref-goto-xref (or whatever it is called) or > xref-find-definitions. Or scratched, if it's too much work, because > it's not terribly useful. I'm sure it will be useful in some situations, I'm just not sure about the odds. > In that special case we will do no worse than the current version, > wouldn't we? We would. Say, we're looking for clojure.core/cons, and the marker leads us to "(defn cons" (the example is largely made up). The code looks for clojure.core/cons, doesn't find it, and signals an error (will it?). Or worse, searches around and finds a verbatim reference to clojure.core/cons in a docstring somewhere in that file, and returns *that* location. > At this point, I'm thinking of dismissing the whole thing, and voting to > deprecate xref-file-location entirely. Nobody uses it and Eglot will > probably use something else before this issue is solved. Err, it is used: in xref--collect-matches-1. And through it, in xref-collect-matches and xref-collect-references. > It's a shame > we can't share code, but if we can't give a default class any kind of > useful behavior, we might as well not have this class in the first place. We could. As long as we don't default to the identifier, and the backend has to explicitly provide the hint, we could be fine.
bug-gnu-emacs@HIDDEN:bug#32034; Package emacs.
Full text available.Received: (at 32034) by debbugs.gnu.org; 3 Jul 2018 14:50:32 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Tue Jul 03 10:50:32 2018 Received: from localhost ([127.0.0.1]:45585 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1faMdU-0000xx-6C for submit <at> debbugs.gnu.org; Tue, 03 Jul 2018 10:50:32 -0400 Received: from mail-it0-f43.google.com ([209.85.214.43]:35642) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <joaotavora@HIDDEN>) id 1faMdS-0000xj-4I for 32034 <at> debbugs.gnu.org; Tue, 03 Jul 2018 10:50:30 -0400 Received: by mail-it0-f43.google.com with SMTP id l16-v6so3528799ita.0 for <32034 <at> debbugs.gnu.org>; Tue, 03 Jul 2018 07:50:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=BNOx+AL1/4CtB1fqlafL0W98C3+ETcs4sa98G3i1sLc=; b=qoBIcnjZA6f+feL0Vue8vVCowOq+xW8kivXJx4+tBJDKg8aH7rE8tmWrRp5ighifBq j0MKjjUhmvnjBgVLTkGBw1S4Pml846rjzQwquKZoZJqmDNtxCc5XnEG082fDsE0iW7gq aqnj6aF6kqFF8YEVyi1jwFt0dxDDlMgKLO4pIRg5i+ybcOkFN4G6R+7FhVROrNO+KiKs bZECctu13f9celH372OBjLhiMA9XHfGqn2zg5W2DPp7TqcbRQV/sNuVKiQ79ndQU1Vu4 dbiDsoOJnPtiPwAH4Nr0sML+YUW+0ZTIfGbaXXOmWMqhPqsAeX9DUiW0CHuCCF08Sxhr mlhA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=BNOx+AL1/4CtB1fqlafL0W98C3+ETcs4sa98G3i1sLc=; b=ba/cNMquI1gK9WtcXFUYhel5k1zTakBUtG6koNFHliWFlOwy6DPpK5og1vi9UYD4nJ pBKzcdEn9mga0781FnBA4I5qyOSqiQw3l4RlXylS7Yl/NozE0IEsB/SVhrkGAuWhE6nT 49B5ExLB4BLEfBLzT+o6ZOCjT69uqXCZ2QcgaCRRzzJY/KHJBT9nAEwNk7Bj4bnRgL7C vlYRr/+NmBAcTeU+MFyliOOAkERdjEZx1m5hspHCPnhIZbt/X5qUbV2J7w4V7CINxDs7 QtWQkRvCi23/cSanzSRcTXuLiOxsb8vdfaq39L0K/mxh1OdUXUSm/Bft0s9hbomfb5L9 X6bQ== X-Gm-Message-State: APt69E2jkjZom1Ki/orAnX20BDWshBUC7CwV+LMYG26kX9gdyhW11uoV B2NJW9zC8QK+Y+fkH6kzDfwaCwjmFyLS2czOHsM= X-Google-Smtp-Source: AAOMgpclGgh179yuyBJ3p3ivGq53KPdBz23RORsBnVBMe3WBtooyDP1pBbnknl7vVLUtpGYlYPNt7ZKRcyIGEZVkcFA= X-Received: by 2002:a24:a342:: with SMTP id p63-v6mr13658176ite.67.1530629424280; Tue, 03 Jul 2018 07:50:24 -0700 (PDT) MIME-Version: 1.0 References: <87y3etsqb7.fsf@HIDDEN> <5ab17038-c13d-3dde-2db9-4bc9a1042235@HIDDEN> In-Reply-To: <5ab17038-c13d-3dde-2db9-4bc9a1042235@HIDDEN> From: =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= <joaotavora@HIDDEN> Date: Tue, 3 Jul 2018 15:50:05 +0100 Message-ID: <CALDnm50Ed=8vAKCPJZUOYgKnZEuqg31-YDOT5VMYRQ1CNK53Fg@HIDDEN> Subject: Re: bug#32034: 26.1; [PACTH] better xref-location-marker for imperfect file locations To: Dmitry Gutov <dgutov@HIDDEN> Content-Type: multipart/alternative; boundary="0000000000001df8c60570196fbe" X-Spam-Score: 0.1 (/) X-Debbugs-Envelope-To: 32034 Cc: Eli Zaretskii <eliz@HIDDEN>, 32034 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -0.9 (/) --0000000000001df8c60570196fbe Content-Type: text/plain; charset="UTF-8" On Tue, Jul 3, 2018, 14:56 Dmitry Gutov <dgutov@HIDDEN> wrote: > > > When xref-location-marker is inaccurate, it may lead to problems, like > xref-query-replace-in-results sometimes performing replacements at the > "auto-corrected", wrong positions. > > Maybe we can add a laxer version of this function that is only used when > we know the user will be looking at the result directly (e.g. from > xref-find-definitions, but not from xref-query-replace-in-results). I'm > on the fence about xref-fined-references regarding this, because it also > supports automatic replacement. > Right, this should go into xref-goto-xref (or whatever it is called) or xref-find-definitions. Or scratched, if it's too much work, because it's not terribly useful. > > > > 3. Number 2. could turn out to be brittle and annoying if we have > > changed the file in the meantime (but probably not more so than jumping > > to a wrong location). So we could have a "hint" field in > > xref-file-location (or a xref-hinted-file-location) that helps in > > looking around the landing point for, say, a regexp, and puts point > > there. Historically, this technique is successfully used in SLIME. We > > could also reasonably default that field to the identifier being looked > > for. > > I'm not sure this is a good idea. Certainly not the "defaulting to the > identifier" bit. Because the identifier could e.g. look like > namespace-name/symbol-name, where only "symbol-name" appears verbatim in > the definition. In that special case we will do no worse than the current version, wouldn't we? So still a win on my book. And to do better for languages which do present this problem would take very little work, especially if we take advantage of inheritance and eieio slot methods. I don't have much experience with LSP, but I imagine > this could happen there, too (unless it only supports navigation to > unqualified identifiers). > > Now, if hint is optional (and disabled by default), and extracting the > relevant code from Etags is natural, I say go for it. > > But overall, I think individual backends that want "smarter" behavior > should create their own "location" class, like Elisp does. > At this point, I'm thinking of dismissing the whole thing, and voting to deprecate xref-file-location entirely. Nobody uses it and Eglot will probably use something else before this issue is solved. It's a shame we can't share code, but if we can't give a default class any kind of useful behavior, we might as well not have this class in the first place. > --0000000000001df8c60570196fbe Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir=3D"auto"><div><br><div class=3D"gmail_quote"><div dir=3D"ltr">On T= ue, Jul 3, 2018, 14:56 Dmitry Gutov <<a href=3D"mailto:dgutov@HIDDEN"= >dgutov@HIDDEN</a>> wrote:<br></div><blockquote class=3D"gmail_quote"= style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><b= r> <br> When xref-location-marker is inaccurate, it may lead to problems, like <br> xref-query-replace-in-results sometimes performing replacements at the <br> "auto-corrected", wrong positions.<br> <br> Maybe we can add a laxer version of this function that is only used when <b= r> we know the user will be looking at the result directly (e.g. from <br> xref-find-definitions, but not from xref-query-replace-in-results). I'm= <br> on the fence about xref-fined-references regarding this, because it also <b= r> supports automatic replacement.<br></blockquote></div></div><div dir=3D"aut= o"><br></div><div dir=3D"auto">Right, this should go into xref-goto-xref (o= r whatever it is called) or xref-find-definitions.=C2=A0 Or scratched, if i= t's too much work, because it's not terribly useful.</div><div dir= =3D"auto"><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" styl= e=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br></b= lockquote><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bord= er-left:1px #ccc solid;padding-left:1ex"><br> > 3. Number 2. could turn out to be brittle and annoying if we have<br> > changed the file in the meantime (but probably not more so than jumpin= g<br> > to a wrong location).=C2=A0 So we could have a "hint" field = in<br> > xref-file-location (or a xref-hinted-file-location) that helps in<br> > looking around the landing point for, say, a regexp, and puts point<br= > > there.=C2=A0 Historically, this technique is successfully used in SLIM= E.=C2=A0 We<br> > could also reasonably default that field to the identifier being looke= d<br> > for.<br> <br> I'm not sure this is a good idea. Certainly not the "defaulting to= the <br> identifier" bit. Because the identifier could e.g. look like <br> namespace-name/symbol-name, where only "symbol-name" appears verb= atim in <br> the definition.</blockquote></div></div><div dir=3D"auto"><br></div><div di= r=3D"auto"><br></div><div dir=3D"auto">In that special case we will do no w= orse than the current version, wouldn't we? So still a win on my book. = And to do better for languages which do present this problem would take ver= y little work, especially if we take advantage of inheritance and eieio slo= t methods.</div><div dir=3D"auto"><br></div><div dir=3D"auto"><br></div><di= v dir=3D"auto"><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote"= style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> I= don't have much experience with LSP, but I imagine <br> this could happen there, too (unless it only supports navigation to <br> unqualified identifiers).<br> <br> Now, if hint is optional (and disabled by default), and extracting the <br> relevant code from Etags is natural, I say go for it.<br> <br> But overall, I think individual backends that want "smarter" beha= vior <br> should create their own "location" class, like Elisp does.<br></b= lockquote></div></div><div dir=3D"auto"><br></div><div dir=3D"auto">At this= point, I'm thinking of dismissing the whole thing, and voting to depre= cate xref-file-location entirely. Nobody uses it and Eglot will probably us= e something else before this issue is solved.=C2=A0 It's a shame we can= 't share code, but if we can't give a default class any kind of use= ful behavior, we might as well not have this class in the first place.</div= ><div dir=3D"auto"><div class=3D"gmail_quote"><blockquote class=3D"gmail_qu= ote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex= "> </blockquote></div></div></div> --0000000000001df8c60570196fbe--
bug-gnu-emacs@HIDDEN:bug#32034; Package emacs.
Full text available.Received: (at 32034) by debbugs.gnu.org; 3 Jul 2018 13:56:53 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Tue Jul 03 09:56:53 2018
Received: from localhost ([127.0.0.1]:45573 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1faLnY-0007pT-On
for submit <at> debbugs.gnu.org; Tue, 03 Jul 2018 09:56:52 -0400
Received: from mail-wm0-f54.google.com ([74.125.82.54]:38646)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <raaahh@HIDDEN>) id 1faLnX-0007pE-GP
for 32034 <at> debbugs.gnu.org; Tue, 03 Jul 2018 09:56:51 -0400
Received: by mail-wm0-f54.google.com with SMTP id 69-v6so2381545wmf.3
for <32034 <at> debbugs.gnu.org>; Tue, 03 Jul 2018 06:56:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
h=sender:subject:to:references:cc:from:message-id:date:user-agent
:mime-version:in-reply-to:content-language:content-transfer-encoding;
bh=2nHZHGSsVjz3jdWh/9qCSmgfeMer5Z01TW3MLX+rDkU=;
b=dZn2QqgCIN/RkuvD13OgKR7Qf9pJwRCnage+sexlIs7KN+2oXWQqSqWG0hFOk4WeNZ
Qotl+lpSxChWk77CvOPDfyMb1aNieemvsuOlibLqsK64jFHYTiv3N/3/Cg5aa7JkZoMR
pbCOWLhwpP5LrzAFetybiY/uw//65crS3F+aCZmbOzxTFGtmF7ItYj3WgMHTCX/f/d/7
Appoq4CpTNKgAJAWLAdbYepNw49xBxVkShLwLAPHXDu9Q/CNvt74fS3/Y+yG7e3SPCuv
pnd3iMlIc1Ys1HDMkgFpMI8MzPADruQgsEgjkKsOMfyq9/ZutN0wPjUBHfNdc3vmmtf5
UquQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20161025;
h=x-gm-message-state:sender:subject:to:references:cc:from:message-id
:date:user-agent:mime-version:in-reply-to:content-language
:content-transfer-encoding;
bh=2nHZHGSsVjz3jdWh/9qCSmgfeMer5Z01TW3MLX+rDkU=;
b=lUSXBciIX7Ud30iQpsy2yICx0EW0yqC5qINdA8p/TvCXVYwKw/1XMgMflPsUcif/GY
qGK1VkmLAtl72a2Vo3der3GKdCxwfKIIfyGdsX8pemmKAki3zFOlPMoutaxUg56mopnz
frP6Dvntkhd+KQ7CQt8nYPbbNQmy36CU/0z8eCy3IMUGv39yf1nEmFsa0cMhsfZFAJMQ
nr4LK3rPmDMByDh1yG1PYVnz40+1OpSU7CPWE7rZEJhLvvOjgugHWc1MYROX5p/PWlbW
X4Z9fjEv2dLZz6HbG/ABcZZZSC+8diA5cBSbmRyVcuZ0Ovua81EpBTk4p/utG1lma7du
n27w==
X-Gm-Message-State: APt69E3Z46FfB84JUpTUjwiTWdPksgtgATEhue8rRYH4YYra6nFYhpZS
wp9hzw1nJW+983psORWB8mg=
X-Google-Smtp-Source: AAOMgpfQsws9E/bLu0h1N9kTEZ46CN+pISNPCsdwiZRMe0aFTnn6d2WUQVIpV43rAY2nQryMayNpnA==
X-Received: by 2002:a1c:4d09:: with SMTP id
o9-v6mr8886637wmh.111.1530626205583;
Tue, 03 Jul 2018 06:56:45 -0700 (PDT)
Received: from [192.168.0.200] ([109.110.245.170])
by smtp.googlemail.com with ESMTPSA id
72-v6sm2217394wmo.26.2018.07.03.06.56.43
(version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
Tue, 03 Jul 2018 06:56:44 -0700 (PDT)
Subject: Re: bug#32034: 26.1; [PACTH] better xref-location-marker for
imperfect file locations
To: =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= <joaotavora@HIDDEN>,
32034 <at> debbugs.gnu.org
References: <87y3etsqb7.fsf@HIDDEN>
From: Dmitry Gutov <dgutov@HIDDEN>
Message-ID: <5ab17038-c13d-3dde-2db9-4bc9a1042235@HIDDEN>
Date: Tue, 3 Jul 2018 16:56:42 +0300
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101
Thunderbird/60.0
MIME-Version: 1.0
In-Reply-To: <87y3etsqb7.fsf@HIDDEN>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-Spam-Score: 0.5 (/)
X-Debbugs-Envelope-To: 32034
Cc: Eli Zaretskii <eliz@HIDDEN>
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -0.5 (/)
Hi guys,
I've read up on the discussion.
On 7/2/18 4:46 PM, João Távora wrote:
> 1. xref-location-marker should check for `file-readable-p' before trying
> to open the file, and if that fails issues an error ("File %s can't be
> found.").
I'm fine with this, naturally.
> 2. if the file is found, xref-location-marker should detect if the
> location is indeed available in the file, and if it isn't, issue a
> message. In that case it should return a marker to the nearest possible
> location.
When xref-location-marker is inaccurate, it may lead to problems, like
xref-query-replace-in-results sometimes performing replacements at the
"auto-corrected", wrong positions.
Maybe we can add a laxer version of this function that is only used when
we know the user will be looking at the result directly (e.g. from
xref-find-definitions, but not from xref-query-replace-in-results). I'm
on the fence about xref-fined-references regarding this, because it also
supports automatic replacement.
> 3. Number 2. could turn out to be brittle and annoying if we have
> changed the file in the meantime (but probably not more so than jumping
> to a wrong location). So we could have a "hint" field in
> xref-file-location (or a xref-hinted-file-location) that helps in
> looking around the landing point for, say, a regexp, and puts point
> there. Historically, this technique is successfully used in SLIME. We
> could also reasonably default that field to the identifier being looked
> for.
I'm not sure this is a good idea. Certainly not the "defaulting to the
identifier" bit. Because the identifier could e.g. look like
namespace-name/symbol-name, where only "symbol-name" appears verbatim in
the definition. I don't have much experience with LSP, but I imagine
this could happen there, too (unless it only supports navigation to
unqualified identifiers).
Now, if hint is optional (and disabled by default), and extracting the
relevant code from Etags is natural, I say go for it.
But overall, I think individual backends that want "smarter" behavior
should create their own "location" class, like Elisp does.
bug-gnu-emacs@HIDDEN:bug#32034; Package emacs.
Full text available.Received: (at 32034) by debbugs.gnu.org; 2 Jul 2018 17:30:23 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Mon Jul 02 13:30:23 2018 Received: from localhost ([127.0.0.1]:43873 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1fa2ed-0000qT-D7 for submit <at> debbugs.gnu.org; Mon, 02 Jul 2018 13:30:23 -0400 Received: from eggs.gnu.org ([208.118.235.92]:58517) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1fa2eb-0000qH-Fx for 32034 <at> debbugs.gnu.org; Mon, 02 Jul 2018 13:30:21 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from <eliz@HIDDEN>) id 1fa2eV-0003SX-K2 for 32034 <at> debbugs.gnu.org; Mon, 02 Jul 2018 13:30:16 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=0.8 required=5.0 tests=BAYES_50 autolearn=disabled version=3.3.2 Received: from fencepost.gnu.org ([2001:4830:134:3::e]:33181) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from <eliz@HIDDEN>) id 1fa2eM-0003E8-UL; Mon, 02 Jul 2018 13:30:06 -0400 Received: from [176.228.60.248] (port=1388 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from <eliz@HIDDEN>) id 1fa2eM-0001QX-1N; Mon, 02 Jul 2018 13:30:06 -0400 Date: Mon, 02 Jul 2018 20:29:53 +0300 Message-Id: <83lgatk0ku.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: =?utf-8?B?Sm/Do28gVMOhdm9yYQ==?= <joaotavora@HIDDEN> In-reply-to: <87o9fpfuhe.fsf@HIDDEN> (message from =?utf-8?B?Sm/Do28g?= =?utf-8?B?VMOhdm9yYQ==?= on Mon, 02 Jul 2018 17:55:09 +0100) Subject: Re: bug#32034: 26.1; [PACTH] better xref-location-marker for imperfect file locations References: <87y3etsqb7.fsf@HIDDEN> <83601xlmno.fsf@HIDDEN> <87muv9sll6.fsf@HIDDEN> <83po05k5rx.fsf@HIDDEN> <87bmbpskl8.fsf@HIDDEN> <83muv9k38v.fsf@HIDDEN> <87o9fpfuhe.fsf@HIDDEN> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-Spam-Score: -5.0 (-----) X-Debbugs-Envelope-To: 32034 Cc: 32034 <at> debbugs.gnu.org, dgutov@HIDDEN X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -6.0 (------) > From: João Távora <joaotavora@HIDDEN> > Cc: 32034 <at> debbugs.gnu.org, dgutov@HIDDEN > Date: Mon, 02 Jul 2018 17:55:09 +0100 > > OK, let's give Dmitry time. But, without trying to annoy you :-) there > are 3 parts to this: > > 1. bug fix for when file doesn't exist (should error instead of making it) > 2. bug fix for when file exists, but not location (it currently errors) > 3. new feature, for robustness, search for id around landing point. > > 1 and 2 were in my patch. But now I'm assuming you want 1, 2 and 3 in > emacs-26, in which case I'll try to base the id-searching bit from etags. No. I'm okay with your solution for 1 to go to emacs-26. I had reservations about your solution for 2, but now I understand it won't affect the existing back-ends, so I'm okay with it on emacs-26, too (but will probably suggest a clearer message text if Dmitry agrees with the solution). 3 should indeed go to master.
bug-gnu-emacs@HIDDEN:bug#32034; Package emacs.
Full text available.Received: (at 32034) by debbugs.gnu.org; 2 Jul 2018 16:55:22 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Mon Jul 02 12:55:22 2018
Received: from localhost ([127.0.0.1]:43854 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1fa26j-0008T4-Pk
for submit <at> debbugs.gnu.org; Mon, 02 Jul 2018 12:55:22 -0400
Received: from mail-wm0-f42.google.com ([74.125.82.42]:52322)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <joaotavora@HIDDEN>) id 1fa26i-0008Sr-10
for 32034 <at> debbugs.gnu.org; Mon, 02 Jul 2018 12:55:20 -0400
Received: by mail-wm0-f42.google.com with SMTP id w16-v6so9090758wmc.2
for <32034 <at> debbugs.gnu.org>; Mon, 02 Jul 2018 09:55:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
h=from:to:cc:subject:references:date:in-reply-to:message-id
:user-agent:mime-version:content-transfer-encoding;
bh=Mj9oOOlMCVai30SecQF94ZZXFKAlrbRga7FIT2j50I0=;
b=awEZi22aHtV5nPcHjx5rrii57uuAMX+N8BvdNZ7/adlIRPWrLQGNdXHDOqohkB7EE2
sLamsyIcIyx70Sb7JRHb4BGsd+22R0tuzsgPd5qwmsZg6SS2idwTLysY1J6lR1MbvtWs
uob6zVvFSaYmd+AiQQnnXM5kBP0i4UbtEzJ5DJotq5QRtkiiHSa5Q9qVQoY2ZVxukFKy
BtHqb/OdfdDBLkiTo382fuPHM7AJwOm0f0VOzqH8I0fY9keDK98dU+c1vRFfTUkZTJjQ
ziGhdnegL8BoCu4MLCrye46soOkdUnnUTnySUrio2Ar2700dqRzZI9YY2JvkA7uy7E02
mcyw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20161025;
h=x-gm-message-state:from:to:cc:subject:references:date:in-reply-to
:message-id:user-agent:mime-version:content-transfer-encoding;
bh=Mj9oOOlMCVai30SecQF94ZZXFKAlrbRga7FIT2j50I0=;
b=K1RLPG72YPFLxl2/lwyDrsR4lfDQm2cJGMkkTcdtVyzFt6KcIlq1z5Xsq9P+ag4/ts
20o95ERJEaXSlwLPHAQ1e/8KKrcakjBmLHIWWEctxcoVqGsZ1cKjhYw7LgA4WdamHFSE
ZTPD8+HBYVtJ+jH+oAUP8c8X6gc34MLw+25vOpw/O5ZvJW8Y9h/6VfJa3ymLpwqXzaa4
fB+KL4AHX75Rbc/YCpB3NcCvaREw1ynmtHG8lfSjDPDWCIwTx0vYj4HKwh5veO3sOlsd
xV2QPz0nWP/zuVgz3H2S1z0gze60Qd2OJGxWcvVKJQh5YH+NBmLdXYpCPaZdIoUektMS
usNg==
X-Gm-Message-State: APt69E0SSrlTy223EO1x3lHw9ljaugeeulCDRTp3sN15OsX0KPhpCUdl
/uOL+uVSKP23qKWT6M45RSU=
X-Google-Smtp-Source: AAOMgpcNRvVUzP9CP62h0rM04OFzx0JV3kTPrWwJARRp8FMmhYDHw9wvPv0+YwH9cspsMOxgMvXarw==
X-Received: by 2002:a1c:b484:: with SMTP id
d126-v6mr8740869wmf.17.1530550514160;
Mon, 02 Jul 2018 09:55:14 -0700 (PDT)
Received: from lolita.yourcompany.com (188.139.62.94.rev.vodafone.pt.
[94.62.139.188])
by smtp.gmail.com with ESMTPSA id r2-v6sm12839369wmb.39.2018.07.02.09.55.13
(version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256);
Mon, 02 Jul 2018 09:55:13 -0700 (PDT)
From: =?utf-8?B?Sm/Do28gVMOhdm9yYQ==?= <joaotavora@HIDDEN>
To: Eli Zaretskii <eliz@HIDDEN>
Subject: Re: bug#32034: 26.1;
[PACTH] better xref-location-marker for imperfect file locations
References: <87y3etsqb7.fsf@HIDDEN> <83601xlmno.fsf@HIDDEN>
<87muv9sll6.fsf@HIDDEN> <83po05k5rx.fsf@HIDDEN>
<87bmbpskl8.fsf@HIDDEN> <83muv9k38v.fsf@HIDDEN>
Date: Mon, 02 Jul 2018 17:55:09 +0100
In-Reply-To: <83muv9k38v.fsf@HIDDEN> (Eli Zaretskii's message of "Mon, 02 Jul
2018 19:32:16 +0300")
Message-ID: <87o9fpfuhe.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: 1.1 (+)
X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org",
has NOT identified this incoming email as spam. The original
message has been attached to this so you can view it or label
similar future email. If you have any questions, see
the administrator of that system for details.
Content preview: Eli Zaretskii writes: >> From: joaotavora@HIDDEN (João
Távora) >> Cc: 32034 <at> debbugs.gnu.org, dgutov@HIDDEN >> Date: Mon, 02
Jul 2018 16:50:27 +0100 >> >> > And display the message, right? >> Not necessarily,
if that line and column still exists. > I was explicitly thinking about the
case where they don't, for some > reason, or that the line is there, but
the column isn't (e.g., due to > some TABs). [...]
Content analysis details: (1.1 points, 10.0 required)
pts rule name description
---- ---------------------- --------------------------------------------------
-0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/, no
trust
[74.125.82.42 listed in list.dnswl.org]
-0.0 SPF_PASS SPF: sender matches SPF record
0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider
(joaotavora[at]gmail.com)
-0.0 RCVD_IN_MSPIKE_H3 RBL: Good reputation (+3)
[74.125.82.42 listed in wl.mailspike.net]
0.1 FROM_EXCESS_BASE64 From: base64 encoded unnecessarily
0.0 T_DKIM_INVALID DKIM-Signature header exists but is not valid
-0.0 RCVD_IN_MSPIKE_WL Mailspike good senders
1.0 FREEMAIL_REPLY From and body contain different freemails
X-Debbugs-Envelope-To: 32034
Cc: 32034 <at> debbugs.gnu.org, dgutov@HIDDEN
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -0.9 (/)
Eli Zaretskii <eliz@HIDDEN> writes:
>> From: joaotavora@HIDDEN (Jo=C3=A3o T=C3=A1vora)
>> Cc: 32034 <at> debbugs.gnu.org, dgutov@HIDDEN
>> Date: Mon, 02 Jul 2018 16:50:27 +0100
>>=20
>> > And display the message, right?
>> Not necessarily, if that line and column still exists.
> I was explicitly thinking about the case where they don't, for some
> reason, or that the line is there, but the column isn't (e.g., due to
> some TABs).
Yeah, but in those cases I want the message to display. The definition
isn't there probably, so it's nice to display the message.
>> > If so, the message would be an annoyance if displayed unconditionally,
>> > because at least the etags back-end can cope with these calamities,
>> > and users rely on that (it lets one re-generate TAGS only once in a
>> > blue moon).
>> That's what I wrote in the original message. I added it under the
>> assumption that it would be less of an annoyance than silently jumping
>> to the wrong spot int he file.
> If the back-end can do its job even under these conditions, then the
> message would look like a regression.
Well it can't, so it won't :-)
>> No, I think your understanding is fine. The current code is really
>> quite dumb. The reason you don't come across it often is that the elisp
>> and etags backend use their own "location" class, xref-etags-location
>> and xref-elisp-location. But eglot uses the xref-file-location class
>> bundled with xref (it could also use its own, but then what's the point
>> of having a built-in class for this? perhaps none, in this case I move
>> to delete it)
>
> So neither etags nor elisp back-ends will ever go through this code,
> and will never show this message? If so, maybe your patch is fine as
> it is. Otherwise, maybe we should exempt those two back-ends from
> displaying the message?
The first applies. What's more, noone in Emacs or in the ELPA repo uses
xref-file-location, directly or through inheritance.=20=20
>
>> When you can, please comment on the possibility of fixing this in
>> emacs-26 or master.
>
> In case it wasn't clear, what I wrote _was_ my comment on that. The
> code is a no-brainer, so the only aspect I worry about is whether it
> could introduce annoying messages where none are needed. Other than
> that, I have no objections with having this on emacs-26, but I'd like
> to give Dmitry time to comment.
OK, let's give Dmitry time. But, without trying to annoy you :-) there=20
are 3 parts to this:
1. bug fix for when file doesn't exist (should error instead of making it)
2. bug fix for when file exists, but not location (it currently errors)
3. new feature, for robustness, search for id around landing point.
1 and 2 were in my patch. But now I'm assuming you want 1, 2 and 3 in
emacs-26, in which case I'll try to base the id-searching bit from etags.
Jo=C3=A3o
bug-gnu-emacs@HIDDEN:bug#32034; Package emacs.
Full text available.Received: (at 32034) by debbugs.gnu.org; 2 Jul 2018 16:32:44 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Mon Jul 02 12:32:44 2018 Received: from localhost ([127.0.0.1]:43848 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1fa1kp-0007yT-R7 for submit <at> debbugs.gnu.org; Mon, 02 Jul 2018 12:32:44 -0400 Received: from eggs.gnu.org ([208.118.235.92]:55320) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1fa1ko-0007yH-D0 for 32034 <at> debbugs.gnu.org; Mon, 02 Jul 2018 12:32:42 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from <eliz@HIDDEN>) id 1fa1ki-0002fc-4e for 32034 <at> debbugs.gnu.org; Mon, 02 Jul 2018 12:32:37 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=0.8 required=5.0 tests=BAYES_50 autolearn=disabled version=3.3.2 Received: from fencepost.gnu.org ([2001:4830:134:3::e]:60780) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from <eliz@HIDDEN>) id 1fa1kb-0002Z9-5P; Mon, 02 Jul 2018 12:32:29 -0400 Received: from [176.228.60.248] (port=1685 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from <eliz@HIDDEN>) id 1fa1ka-0001Gf-Gu; Mon, 02 Jul 2018 12:32:28 -0400 Date: Mon, 02 Jul 2018 19:32:16 +0300 Message-Id: <83muv9k38v.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: joaotavora@HIDDEN (=?utf-8?B?Sm/Do28gVMOhdm9yYQ==?=) In-reply-to: <87bmbpskl8.fsf@HIDDEN> (joaotavora@HIDDEN) Subject: Re: bug#32034: 26.1; [PACTH] better xref-location-marker for imperfect file locations References: <87y3etsqb7.fsf@HIDDEN> <83601xlmno.fsf@HIDDEN> <87muv9sll6.fsf@HIDDEN> <83po05k5rx.fsf@HIDDEN> <87bmbpskl8.fsf@HIDDEN> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-Spam-Score: -5.0 (-----) X-Debbugs-Envelope-To: 32034 Cc: 32034 <at> debbugs.gnu.org, dgutov@HIDDEN X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -6.0 (------) > From: joaotavora@HIDDEN (João Távora) > Cc: 32034 <at> debbugs.gnu.org, dgutov@HIDDEN > Date: Mon, 02 Jul 2018 16:50:27 +0100 > > > And display the message, right? > > Not necessarily, if that line and column still exists. I was explicitly thinking about the case where they don't, for some reason, or that the line is there, but the column isn't (e.g., due to some TABs). > > If so, the message would be an annoyance if displayed unconditionally, > > because at least the etags back-end can cope with these calamities, > > and users rely on that (it lets one re-generate TAGS only once in a > > blue moon). > > That's what I wrote in the original message. I added it under the > assumption that it would be less of an annoyance than silently jumping > to the wrong spot int he file. If the back-end can do its job even under these conditions, then the message would look like a regression. > No, I think your understanding is fine. The current code is really > quite dumb. The reason you don't come across it often is that the elisp > and etags backend use their own "location" class, xref-etags-location > and xref-elisp-location. But eglot uses the xref-file-location class > bundled with xref (it could also use its own, but then what's the point > of having a built-in class for this? perhaps none, in this case I move > to delete it) So neither etags nor elisp back-ends will ever go through this code, and will never show this message? If so, maybe your patch is fine as it is. Otherwise, maybe we should exempt those two back-ends from displaying the message? > When you can, please comment on the possibility of fixing this in > emacs-26 or master. In case it wasn't clear, what I wrote _was_ my comment on that. The code is a no-brainer, so the only aspect I worry about is whether it could introduce annoying messages where none are needed. Other than that, I have no objections with having this on emacs-26, but I'd like to give Dmitry time to comment. Thanks.
bug-gnu-emacs@HIDDEN:bug#32034; Package emacs.
Full text available.Received: (at 32034) by debbugs.gnu.org; 2 Jul 2018 15:50:37 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Mon Jul 02 11:50:37 2018
Received: from localhost ([127.0.0.1]:43796 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1fa164-0006wL-TY
for submit <at> debbugs.gnu.org; Mon, 02 Jul 2018 11:50:37 -0400
Received: from mail-wr0-f179.google.com ([209.85.128.179]:46182)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <joaotavora@HIDDEN>) id 1fa163-0006w8-L2
for 32034 <at> debbugs.gnu.org; Mon, 02 Jul 2018 11:50:36 -0400
Received: by mail-wr0-f179.google.com with SMTP id s11-v6so6796602wra.13
for <32034 <at> debbugs.gnu.org>; Mon, 02 Jul 2018 08:50:35 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
h=from:to:cc:subject:references:date:in-reply-to:message-id
:user-agent:mime-version:content-transfer-encoding;
bh=83BzZa3riWYI+g0UbzR/jFLR88di/FA+jZZI3uAdTcw=;
b=WSwh2XxAobbqi/uepfruJFyWYEh1w0+rdjMdHaOkvClCGf148xG7gcoYCDuB1H3ZzN
IWM9KqZgUORa6g/hHNpYKVVVVk79EEyHxXSlgaHr+xb5pj+iY5VfcR/uD/pILbPmybSG
OrhqGT92QfVC5l8xnpGya+vxloGywgrk5iH2ENtxjrOzq25lDPwXm4QyHrWBdDDpWLHY
ndaH0mzvljEYeio6NkOKRSXAGXJDSrhVuXUvsCtJP2Nol5W4jwhOlwZzPRsFgiXaNSqE
Cx5cJA9deymmXK42O5yTHUPL7aXfcD6Mf8olmknqLTuN1pHnAE3zpR/z4t4QnS56QyIh
1gTQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20161025;
h=x-gm-message-state:from:to:cc:subject:references:date:in-reply-to
:message-id:user-agent:mime-version:content-transfer-encoding;
bh=83BzZa3riWYI+g0UbzR/jFLR88di/FA+jZZI3uAdTcw=;
b=sxmc9zOi6vT77JEL0FNC9f14JFYGbfOc9akiWetPG/cFe7FDLdDBIbQDyxQ1qJQLCe
vEfx4/iUm3JSwpbpwJEfSWsuY5kNaGhh9NPog0IeAQmYql31zsHvBGfmmk0ilqm3BuGf
/LYq7LfDx2qA/LCmhI1K1kgPBWeE3B29RC7Gts28HR3DiPjVx92s9w9CdLPu9f8vAlal
u521WX1Y4/sLAOzaU6AGxJZJ2xZTk6vWcHNQP0dVC4BbTorHuNt7tGQVFg1O6aGzXLd1
zSIb4Qnnua5wiIX/NMmTceiJpaT8hGJTZwaWgyTVgpkVuvZOaqFwo9Y7VhG1B5R6D7Zr
9Ubw==
X-Gm-Message-State: APt69E2LAOBCm6/PA8tJUXp9Wgs9OqW376UKHX6KNg+2uW8ujh4/uDG9
kr1A4XfbKKJVvE/MyT3uS/M=
X-Google-Smtp-Source: AAOMgpdmPXc2+ClUnLTdVYXiqWzrCILiO/uOS8rg1JMjYojYUxILLmNufM0xlK2Q4GNrozQDTDngwg==
X-Received: by 2002:adf:f210:: with SMTP id
p16-v6mr7768020wro.184.1530546629943;
Mon, 02 Jul 2018 08:50:29 -0700 (PDT)
Received: from lolita.yourcompany.com (188.139.62.94.rev.vodafone.pt.
[94.62.139.188])
by smtp.gmail.com with ESMTPSA id 131-v6sm20662998wmm.31.2018.07.02.08.50.28
(version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256);
Mon, 02 Jul 2018 08:50:29 -0700 (PDT)
From: joaotavora@HIDDEN (=?utf-8?B?Sm/Do28gVMOhdm9yYQ==?=)
To: Eli Zaretskii <eliz@HIDDEN>
Subject: Re: bug#32034: 26.1;
[PACTH] better xref-location-marker for imperfect file locations
References: <87y3etsqb7.fsf@HIDDEN> <83601xlmno.fsf@HIDDEN>
<87muv9sll6.fsf@HIDDEN> <83po05k5rx.fsf@HIDDEN>
Date: Mon, 02 Jul 2018 16:50:27 +0100
In-Reply-To: <83po05k5rx.fsf@HIDDEN> (Eli Zaretskii's message of "Mon, 02 Jul
2018 18:37:38 +0300")
Message-ID: <87bmbpskl8.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: 1.1 (+)
X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org",
has NOT identified this incoming email as spam. The original
message has been attached to this so you can view it or label
similar future email. If you have any questions, see
the administrator of that system for details.
Content preview: Eli Zaretskii writes: >> From: joaotavora@HIDDEN (João
Távora) >> Cc: 32034 <at> debbugs.gnu.org, dgutov@HIDDEN >> Date: Mon, 02
Jul 2018 16:28:53 +0100 >> >> Eli Zaretskii writes: >> >> >> (beginning-of-line
line) >> >> - (forward-char column) >> >> + (ignore-errors (forward-char
column)) >> >> + (unless (and (= (1+ (current-line)) line) >> >> + (= (current-column)
column)) >> >> + (message "Intended xref location was line=%d, column=%d"
>> >> + line column)) >> >> (point-marker)))))) >> > >> > What will the last
hunk do when a file changed, but the identifier was >> > still found? >>
>> The function is completely oblivious to the identifier being found or >>
not. So it would do what it does now: jump to the wrong location > > And
display the message, right? [...]
Content analysis details: (1.1 points, 10.0 required)
pts rule name description
---- ---------------------- --------------------------------------------------
-0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/, no
trust
[209.85.128.179 listed in list.dnswl.org]
-0.0 RCVD_IN_MSPIKE_H2 RBL: Average reputation (+2)
[209.85.128.179 listed in wl.mailspike.net]
-0.0 SPF_PASS SPF: sender matches SPF record
0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider
(joaotavora[at]gmail.com)
0.1 FROM_EXCESS_BASE64 From: base64 encoded unnecessarily
0.0 T_DKIM_INVALID DKIM-Signature header exists but is not valid
1.0 FREEMAIL_REPLY From and body contain different freemails
X-Debbugs-Envelope-To: 32034
Cc: 32034 <at> debbugs.gnu.org, dgutov@HIDDEN
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -0.9 (/)
Eli Zaretskii <eliz@HIDDEN> writes:
>> From: joaotavora@HIDDEN (Jo=C3=A3o T=C3=A1vora)
>> Cc: 32034 <at> debbugs.gnu.org, dgutov@HIDDEN
>> Date: Mon, 02 Jul 2018 16:28:53 +0100
>>=20
>> Eli Zaretskii <eliz@HIDDEN> writes:
>>=20
>> >> (beginning-of-line line)
>> >> - (forward-char column)
>> >> + (ignore-errors (forward-char column))
>> >> + (unless (and (=3D (1+ (current-line)) line)
>> >> + (=3D (current-column) column))
>> >> + (message "Intended xref location was line=3D%d, column=
=3D%d"
>> >> + line column))
>> >> (point-marker))))))
>> >
>> > What will the last hunk do when a file changed, but the identifier was
>> > still found?
>>=20
>> The function is completely oblivious to the identifier being found or
>> not. So it would do what it does now: jump to the wrong location
>
> And display the message, right?
Not necessarily, if that line and column still exists.
> If so, the message would be an annoyance if displayed unconditionally,
> because at least the etags back-end can cope with these calamities,
> and users rely on that (it lets one re-generate TAGS only once in a
> blue moon).
That's what I wrote in the original message. I added it under the
assumption that it would be less of an annoyance than silently jumping
to the wrong spot int he file. The feature you want to add to the
relevant xref-location-marker method makes a lot of sense, but it's a
new feature nevertheless.
> Or maybe I misunderstand the context in which this code runs, in
> which case ignore me.
No, I think your understanding is fine. The current code is really
quite dumb. The reason you don't come across it often is that the elisp
and etags backend use their own "location" class, xref-etags-location
and xref-elisp-location. But eglot uses the xref-file-location class
bundled with xref (it could also use its own, but then what's the point
of having a built-in class for this? perhaps none, in this case I move
to delete it)
>> > AFAIR, the etags back-end is capable of doing that
>> > (because it searches the file in the vicinity of the line/column if
>> > not found at the exact location), and it's a valuable feature, for
>> > obvious reasons.
>>=20
>> IIUC, that's what I'm proposing in my point 3: add a "hint" field to
>> xref-file-location and default that hint to the identifier being looked
>> for. If etags has code for that already, then great, we could try to
>> share it
>
> I don't think you can share that code, because it relies on the
> contents of the TAGS file, where the 'etags' utility records not only
> the position of the identifier, but also a string to search for it.
I meant the code that searches for the string then, if it isn't too
trivial.
When you can, please comment on the possibility of fixing this in
emacs-26 or master.
Jo=C3=A3o
bug-gnu-emacs@HIDDEN:bug#32034; Package emacs.
Full text available.Received: (at 32034) by debbugs.gnu.org; 2 Jul 2018 15:38:05 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Mon Jul 02 11:38:05 2018 Received: from localhost ([127.0.0.1]:43771 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1fa0tx-0006dY-7e for submit <at> debbugs.gnu.org; Mon, 02 Jul 2018 11:38:05 -0400 Received: from eggs.gnu.org ([208.118.235.92]:37525) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1fa0tv-0006d4-CE for 32034 <at> debbugs.gnu.org; Mon, 02 Jul 2018 11:38:03 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from <eliz@HIDDEN>) id 1fa0tp-0003TA-Ci for 32034 <at> debbugs.gnu.org; Mon, 02 Jul 2018 11:37:58 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=0.8 required=5.0 tests=BAYES_50 autolearn=disabled version=3.3.2 Received: from fencepost.gnu.org ([2001:4830:134:3::e]:59821) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from <eliz@HIDDEN>) id 1fa0ti-0003P6-Iy; Mon, 02 Jul 2018 11:37:50 -0400 Received: from [176.228.60.248] (port=2121 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from <eliz@HIDDEN>) id 1fa0ti-0001qo-19; Mon, 02 Jul 2018 11:37:50 -0400 Date: Mon, 02 Jul 2018 18:37:38 +0300 Message-Id: <83po05k5rx.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: joaotavora@HIDDEN (=?iso-8859-1?Q?Jo=E3o_T=E1vora?=) In-reply-to: <87muv9sll6.fsf@HIDDEN> (joaotavora@HIDDEN) Subject: Re: bug#32034: 26.1; [PACTH] better xref-location-marker for imperfect file locations References: <87y3etsqb7.fsf@HIDDEN> <83601xlmno.fsf@HIDDEN> <87muv9sll6.fsf@HIDDEN> MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-Spam-Score: -5.0 (-----) X-Debbugs-Envelope-To: 32034 Cc: 32034 <at> debbugs.gnu.org, dgutov@HIDDEN X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -6.0 (------) > From: joaotavora@HIDDEN (Jo�o T�vora) > Cc: 32034 <at> debbugs.gnu.org, dgutov@HIDDEN > Date: Mon, 02 Jul 2018 16:28:53 +0100 > > Eli Zaretskii <eliz@HIDDEN> writes: > > >> (beginning-of-line line) > >> - (forward-char column) > >> + (ignore-errors (forward-char column)) > >> + (unless (and (= (1+ (current-line)) line) > >> + (= (current-column) column)) > >> + (message "Intended xref location was line=%d, column=%d" > >> + line column)) > >> (point-marker)))))) > > > > What will the last hunk do when a file changed, but the identifier was > > still found? > > The function is completely oblivious to the identifier being found or > not. So it would do what it does now: jump to the wrong location And display the message, right? If so, the message would be an annoyance if displayed unconditionally, because at least the etags back-end can cope with these calamities, and users rely on that (it lets one re-generate TAGS only once in a blue moon). Or maybe I misunderstand the context in which this code runs, in which case ignore me. > > AFAIR, the etags back-end is capable of doing that > > (because it searches the file in the vicinity of the line/column if > > not found at the exact location), and it's a valuable feature, for > > obvious reasons. > > IIUC, that's what I'm proposing in my point 3: add a "hint" field to > xref-file-location and default that hint to the identifier being looked > for. If etags has code for that already, then great, we could try to > share it I don't think you can share that code, because it relies on the contents of the TAGS file, where the 'etags' utility records not only the position of the identifier, but also a string to search for it.
bug-gnu-emacs@HIDDEN:bug#32034; Package emacs.
Full text available.Received: (at 32034) by debbugs.gnu.org; 2 Jul 2018 15:29:08 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Mon Jul 02 11:29:07 2018 Received: from localhost ([127.0.0.1]:43739 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1fa0lH-0006O4-O2 for submit <at> debbugs.gnu.org; Mon, 02 Jul 2018 11:29:07 -0400 Received: from mail-wr0-f169.google.com ([209.85.128.169]:46508) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <joaotavora@HIDDEN>) id 1fa0lG-0006NT-SR for 32034 <at> debbugs.gnu.org; Mon, 02 Jul 2018 11:29:07 -0400 Received: by mail-wr0-f169.google.com with SMTP id s11-v6so6731047wra.13 for <32034 <at> debbugs.gnu.org>; Mon, 02 Jul 2018 08:29:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version; bh=K0iTcw1ElzouXTKC35Ih6BjHNzob7cbn0Lq/wVeygyU=; b=L+iMMhRiBLCmgC8lsVKMyh+GHaEaB4Oh/Ar9+/DwwlgvUxPbNWXnMv0EaZqO5xwnjd P8A67tcb0O0cDTQfYuweiIG3gRakYVGD2EdZcAm+RkMLktELEw6F5lXa0rmwd3FxgF1u A7WNSd3B+f0k5RshpbnqykXb+ROFma8zHbEhvkpbz6HIOPVdAqb9FcacjvSzEE/H7S4/ cTiabczTy6wEM7nZ9+yXke7+fdVZNBTyb2u+qaUzuHjTmC0qUGhyADSFakJkaMv8SfbL V/QYqtCZPE5lUoPMZ7xzMoZuYhP9ti7/PKiK/NX5u13Kmt1EerlmcrcItXLy2V9dJYFL ZdRQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:references:date:in-reply-to :message-id:user-agent:mime-version; bh=K0iTcw1ElzouXTKC35Ih6BjHNzob7cbn0Lq/wVeygyU=; b=ch2mAs5DBQ5YGIfNCg10Q0fq439xmV1B7IbAT2B7FWDQa0S4clwpBZi+B4vXqOv02j fnomXPh4//tHePyqFPqr0zxuLpp3+aTHbqLJO1vK2K8/J8W7tm1CkG4zoNGSaQwd9nj1 BOkWiNqHag1oZOk86ePKBf1JajKYyRESkT457UM2ASQ2Ao46BcmgBhZP17/zDDRL1WIO 3AfZIxkplfuZ7Kw4YQhV53BoE8P2A58md7oYBDL71C8/TRYj6tinMdFsACyyJHEAtPG+ Y5nlF6gb+yV0yJE24zCzF7L81kM0pu8AfH16HToLX4baA7wuLpe7rrlkmdQmQ4MUNtuC PDsw== X-Gm-Message-State: APt69E1zA6UQX+K0Ej7iMGMO3AO1pCJmlSbqvY8DoslG+nev+STz+3dB HILw8eyEcmLQBlnHFAiF8p8= X-Google-Smtp-Source: AAOMgpf2jQdO2SRq0z7QVxs5FW4R2Gp6TAJP2Qb4zm8q2gkWljAtyIsxUYXfBHrcz/9tmn23LXIBTA== X-Received: by 2002:adf:a706:: with SMTP id c6-v6mr20653757wrd.61.1530545340997; Mon, 02 Jul 2018 08:29:00 -0700 (PDT) Received: from lolita.yourcompany.com (188.139.62.94.rev.vodafone.pt. [94.62.139.188]) by smtp.gmail.com with ESMTPSA id 131-v6sm20574446wmm.31.2018.07.02.08.28.59 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Mon, 02 Jul 2018 08:29:00 -0700 (PDT) From: joaotavora@HIDDEN (=?utf-8?B?Sm/Do28gVMOhdm9yYQ==?=) To: Eli Zaretskii <eliz@HIDDEN> Subject: Re: bug#32034: 26.1; [PACTH] better xref-location-marker for imperfect file locations References: <87y3etsqb7.fsf@HIDDEN> <83601xlmno.fsf@HIDDEN> Date: Mon, 02 Jul 2018 16:28:53 +0100 In-Reply-To: <83601xlmno.fsf@HIDDEN> (Eli Zaretskii's message of "Mon, 02 Jul 2018 17:47:39 +0300") Message-ID: <87muv9sll6.fsf@HIDDEN> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.1 (/) X-Debbugs-Envelope-To: 32034 Cc: 32034 <at> debbugs.gnu.org, dgutov@HIDDEN X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -0.9 (/) Eli Zaretskii <eliz@HIDDEN> writes: >> (beginning-of-line line) >> - (forward-char column) >> + (ignore-errors (forward-char column)) >> + (unless (and (= (1+ (current-line)) line) >> + (= (current-column) column)) >> + (message "Intended xref location was line=%d, column=%d" >> + line column)) >> (point-marker)))))) > > What will the last hunk do when a file changed, but the identifier was > still found? The function is completely oblivious to the identifier being found or not. So it would do what it does now: jump to the wrong location (unless you're lucky and the change preserved the location of the definition you're after). > AFAIR, the etags back-end is capable of doing that > (because it searches the file in the vicinity of the line/column if > not found at the exact location), and it's a valuable feature, for > obvious reasons. IIUC, that's what I'm proposing in my point 3: add a "hint" field to xref-file-location and default that hint to the identifier being looked for. If etags has code for that already, then great, we could try to share it, but that would be for master right? Or can 1, 2 and 3 go into emacs-26?
bug-gnu-emacs@HIDDEN:bug#32034; Package emacs.
Full text available.Received: (at 32034) by debbugs.gnu.org; 2 Jul 2018 15:22:12 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Mon Jul 02 11:22:12 2018 Received: from localhost ([127.0.0.1]:43718 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1fa0eZ-0006D8-Qh for submit <at> debbugs.gnu.org; Mon, 02 Jul 2018 11:22:11 -0400 Received: from mail-wm0-f51.google.com ([74.125.82.51]:53969) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <joaotavora@HIDDEN>) id 1fa0eY-0006Cw-Mb for 32034 <at> debbugs.gnu.org; Mon, 02 Jul 2018 11:22:10 -0400 Received: by mail-wm0-f51.google.com with SMTP id b188-v6so9501538wme.3 for <32034 <at> debbugs.gnu.org>; Mon, 02 Jul 2018 08:22:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version:content-transfer-encoding; bh=+bRSVkT4xW19hD2gC03se5SzChXDBLBzi0ZZPslgZLE=; b=TwwMUNakNDueIRTiKVS11AKYcD/zHq8EKo7HNSefDKB/DvLozXuEjYQH5U9GZuDYg8 29YaIjbZbcw4SvhHu4Otq4lPtp7xJ1ceHboGimoG5jYa5KreSf8fK0+1ifS1Nq8R74uY seFgrCApJs6/xv27PKH4WOMnqFf8s6MYXKqVNNJ5mGCX8d73YHGXbdIyTdGAO0DcdMCn DVOwZ/c3lMNkWN05YUd57fUO4eaKpXax31eNYbtF8Hxase7xL7uK9vOyyJta5USxbOrt PEo8AiykupCGtSNTy2wxc3jaUW7QAhwFHlYRLkrwg/lsTsxg6f+GBrO9Op8VZar/Iao4 hfwg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:references:date:in-reply-to :message-id:user-agent:mime-version:content-transfer-encoding; bh=+bRSVkT4xW19hD2gC03se5SzChXDBLBzi0ZZPslgZLE=; b=TaL54XstOpRAoV94Q0mxFltyYll3idPUqDzRHlDaCzPrWce4hgIy0jl1afcgpD4cpo yBaJBIdoaYb2kuy+JP4i0ts+L4hJE1/KtRKLe/ZOm6ObC8JtAzH/XelhNmk4nX4NDnu/ GRG3tTu+ZVLihWSoN+4FUVarxk1BqcG2AKx0+z/XFsuuPYDnmO6j+IhyMs9uYCz3OYi+ JUm0KKhPmuVY2SiB6KQNbOjRLwVrE2CCpImdxg/4qg76xWE23GzQihqvDZ4opZPMCws+ vrqOkZLpbg88Odsjjm8nvjauck16ioI6dTIZFVCXHt3A2RLO5DlJ0gsp24oXGyW1pPub fFdg== X-Gm-Message-State: APt69E24yMlXJY1FBUc3sdg84xJnGG76XNv6KpNSSxN+yi11JYwNZaOQ lYkaCG0YeNCd/hB+RHHm51k= X-Google-Smtp-Source: AAOMgpdCQ+pKvSXJPPwl63Bpf85lTJB1iOzGkUNjhFIQWXsaz0P+lnMqG9aKYU6Q+FBtR4GE5mGESA== X-Received: by 2002:a1c:b8d2:: with SMTP id i201-v6mr6725792wmf.158.1530544924991; Mon, 02 Jul 2018 08:22:04 -0700 (PDT) Received: from lolita.yourcompany.com (188.139.62.94.rev.vodafone.pt. [94.62.139.188]) by smtp.gmail.com with ESMTPSA id g4-v6sm16108250wrq.32.2018.07.02.08.22.03 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Mon, 02 Jul 2018 08:22:04 -0700 (PDT) From: joaotavora@HIDDEN (=?utf-8?B?Sm/Do28gVMOhdm9yYQ==?=) To: 32034 <at> debbugs.gnu.org Subject: Re: bug#32034: 26.1; [PACTH] better xref-location-marker for imperfect file locations References: <87y3etsqb7.fsf@HIDDEN> <87po05d7tj.fsf@HIDDEN> Date: Mon, 02 Jul 2018 16:22:01 +0100 In-Reply-To: <87po05d7tj.fsf@HIDDEN> (Robert Pluim's message of "Mon, 02 Jul 2018 16:35:20 +0200") Message-ID: <87r2klslwm.fsf@HIDDEN> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.1 (/) X-Debbugs-Envelope-To: 32034 Cc: dgutov@HIDDEN X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -0.9 (/) Robert Pluim <rpluim@HIDDEN> writes: >> + (message "Intended xref location was line=3D%d, column=3D%d" >> + line column)) >> (point-marker)))))) > > I think the message could be clearer, the current one doesn=CA=BCt express > that something unexpected happened. How about > > "Xref intended location line=3D%d, column=3D%d is out of range" > > or similar. OK, sounds reasonable. Jo=C3=A3o
bug-gnu-emacs@HIDDEN:bug#32034; Package emacs.
Full text available.Received: (at 32034) by debbugs.gnu.org; 2 Jul 2018 14:48:28 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Mon Jul 02 10:48:28 2018 Received: from localhost ([127.0.0.1]:43666 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1fa07w-0005Md-Kq for submit <at> debbugs.gnu.org; Mon, 02 Jul 2018 10:48:28 -0400 Received: from eggs.gnu.org ([208.118.235.92]:46459) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1fa07v-0005MR-3M for 32034 <at> debbugs.gnu.org; Mon, 02 Jul 2018 10:48:27 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from <eliz@HIDDEN>) id 1fa07i-0003Ka-5K for 32034 <at> debbugs.gnu.org; Mon, 02 Jul 2018 10:48:21 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=0.8 required=5.0 tests=BAYES_50 autolearn=disabled version=3.3.2 Received: from fencepost.gnu.org ([2001:4830:134:3::e]:59039) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from <eliz@HIDDEN>) id 1fa07M-0002pr-RE; Mon, 02 Jul 2018 10:47:52 -0400 Received: from [176.228.60.248] (port=3023 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from <eliz@HIDDEN>) id 1fa07M-00012E-7C; Mon, 02 Jul 2018 10:47:52 -0400 Date: Mon, 02 Jul 2018 17:47:39 +0300 Message-Id: <83601xlmno.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: joaotavora@HIDDEN (=?utf-8?B?Sm/Do28gVMOhdm9yYQ==?=) In-reply-to: <87y3etsqb7.fsf@HIDDEN> (joaotavora@HIDDEN) Subject: Re: bug#32034: 26.1; [PACTH] better xref-location-marker for imperfect file locations References: <87y3etsqb7.fsf@HIDDEN> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-Spam-Score: -5.0 (-----) X-Debbugs-Envelope-To: 32034 Cc: 32034 <at> debbugs.gnu.org, dgutov@HIDDEN X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -6.0 (------) > From: joaotavora@HIDDEN (João Távora) > Date: Mon, 02 Jul 2018 14:46:52 +0100 > Cc: dgutov@HIDDEN > > The attached patch fixes 1. and 2. It should probably go into emacs-26 > > Then, I'd like to know your opinions on 3., to go into master. > > diff --git a/lisp/progmodes/xref.el b/lisp/progmodes/xref.el > index b0bdd62ae9..d38328cccd 100644ppp > --- a/lisp/progmodes/xref.el > +++ b/lisp/progmodes/xref.el > @@ -119,13 +119,19 @@ xref-make-file-location > (with-current-buffer > (or (get-file-buffer file) > (let ((find-file-suppress-same-file-warnings t)) > + (unless (file-exists-p file) > + (error "File %s doesn't exist!" file)) > (find-file-noselect file))) > (save-restriction > (widen) > (save-excursion > (goto-char (point-min)) > (beginning-of-line line) > - (forward-char column) > + (ignore-errors (forward-char column)) > + (unless (and (= (1+ (current-line)) line) > + (= (current-column) column)) > + (message "Intended xref location was line=%d, column=%d" > + line column)) > (point-marker)))))) What will the last hunk do when a file changed, but the identifier was still found? AFAIR, the etags back-end is capable of doing that (because it searches the file in the vicinity of the line/column if not found at the exact location), and it's a valuable feature, for obvious reasons.
bug-gnu-emacs@HIDDEN:bug#32034; Package emacs.
Full text available.Received: (at 32034) by debbugs.gnu.org; 2 Jul 2018 14:35:32 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Mon Jul 02 10:35:32 2018 Received: from localhost ([127.0.0.1]:43653 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1fZzvQ-00053v-0K for submit <at> debbugs.gnu.org; Mon, 02 Jul 2018 10:35:32 -0400 Received: from mail-wm0-f65.google.com ([74.125.82.65]:54282) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <rpluim@HIDDEN>) id 1fZzvL-00053g-Sx for 32034 <at> debbugs.gnu.org; Mon, 02 Jul 2018 10:35:30 -0400 Received: by mail-wm0-f65.google.com with SMTP id i139-v6so9276980wmf.4 for <32034 <at> debbugs.gnu.org>; Mon, 02 Jul 2018 07:35:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:references:mail-copies-to:gmane-reply-to-list :date:in-reply-to:message-id:mime-version:content-transfer-encoding; bh=yo/FcCK3BL+2bX3TIQJhM0XCoftKm+XYwrRqrXsUuv8=; b=k64M8VZXobOMvefJkeLTD/asfPPn3xSHjDkszdJPHkId+e74gwfExey8Exk9k1u0AF 2uQWnNK+p5mBJJVqpdpJUpDc0PNBBx97b9Ul0n+keUpk968LK0+zESpTOPS4C6jahj3y NIH2jpj4MyT3f9I5UYVu8i/pHlslKT3zsD4PwgGv3WhUXKPtQ0syFle+fTIICsYqzGkH lNAzVZmlxwhAHQILyW6nuoZ7itY0M1uDipx24EjUyqCA743W8JehpisgGhv84bFZrVs0 9WlkreZsES4rKka4VsFNKu4v6Tz2DjCEOYY7VnvMbrGPIJKtMMkuiGk8+8vr7hj9Qj+d +Nog== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:references:mail-copies-to :gmane-reply-to-list:date:in-reply-to:message-id:mime-version :content-transfer-encoding; bh=yo/FcCK3BL+2bX3TIQJhM0XCoftKm+XYwrRqrXsUuv8=; b=tWWaDxLphg+5Teg2bv58smyPwFuIAQpt9owPVfxewQk73varKWlqWMPrfpdAZFBSNF zytH+rWQLF982BGWmVi8DT2lDpbIS1d1v+ldZwAQMJwyUfHJ1cNgVMA50kD4RkQmQLTl ZeXX+zbdBsxqblca+Y34Qw1Bjdm1O9XGUlvUn6lbIhUEaqQcSEgvurOBMRLLDXH7Zn0T Lfu3kI7Z0BtqpMKYf+eGRi7dWqlVjSnsMZvpHBljU934jkSirFbgNV9A5aDXNEZGksnN yyxVaFWQ2VEwc2FBSrR/IahZEiPv6+zb9DTOHyVtcf69M1gfXUBx+HD1XAznc24fa3/K nG1w== X-Gm-Message-State: APt69E1jt/EPMsgBixZsi5qrZN6G6lICvcUZC54zKhnnzcl9NJjw7Hn5 fDPtaMCL70lnSNrgNDqpR84= X-Google-Smtp-Source: AAOMgpeKtmL45VVfvSitbwBS2HIl3fKJ9RABos4203EtO5OynqZso43lqvhCtK5LBLtHBLC49CeBFg== X-Received: by 2002:a1c:3b82:: with SMTP id i124-v6mr8814210wma.57.1530542122009; Mon, 02 Jul 2018 07:35:22 -0700 (PDT) Received: from rpluim-ubuntu ([149.5.228.1]) by smtp.gmail.com with ESMTPSA id q14-v6sm14901329wmd.20.2018.07.02.07.35.21 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 02 Jul 2018 07:35:21 -0700 (PDT) From: Robert Pluim <rpluim@HIDDEN> To: joaotavora@HIDDEN (=?utf-8?B?Sm/Do28gVMOhdm9yYQ==?=) Subject: Re: bug#32034: 26.1; [PACTH] better xref-location-marker for imperfect file locations References: <87y3etsqb7.fsf@HIDDEN> X-Debbugs-No-Ack: yes Mail-Copies-To: never Gmane-Reply-To-List: yes Date: Mon, 02 Jul 2018 16:35:20 +0200 In-Reply-To: <87y3etsqb7.fsf@HIDDEN> (=?utf-8?Q?=22Jo=C3=A3o_T=C3=A1vor?= =?utf-8?Q?a=22's?= message of "Mon, 02 Jul 2018 14:46:52 +0100") Message-ID: <87po05d7tj.fsf@HIDDEN> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: 32034 Cc: 32034 <at> debbugs.gnu.org, dgutov@HIDDEN X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.0 (-) joaotavora@HIDDEN (Jo=C3=A3o T=C3=A1vora) writes: > > diff --git a/lisp/progmodes/xref.el b/lisp/progmodes/xref.el > index b0bdd62ae9..d38328cccd 100644ppp > --- a/lisp/progmodes/xref.el > +++ b/lisp/progmodes/xref.el > @@ -119,13 +119,19 @@ xref-make-file-location > (with-current-buffer > (or (get-file-buffer file) > (let ((find-file-suppress-same-file-warnings t)) > + (unless (file-exists-p file) > + (error "File %s doesn't exist!" file)) > (find-file-noselect file))) > (save-restriction > (widen) > (save-excursion > (goto-char (point-min)) > (beginning-of-line line) > - (forward-char column) > + (ignore-errors (forward-char column)) > + (unless (and (=3D (1+ (current-line)) line) > + (=3D (current-column) column)) > + (message "Intended xref location was line=3D%d, column=3D%d" > + line column)) > (point-marker)))))) I think the message could be clearer, the current one doesn=CA=BCt express that something unexpected happened. How about "Xref intended location line=3D%d, column=3D%d is out of range" or similar. Regards Robert
bug-gnu-emacs@HIDDEN:bug#32034; Package emacs.
Full text available.Received: (at submit) by debbugs.gnu.org; 2 Jul 2018 13:47:09 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Mon Jul 02 09:47:09 2018
Received: from localhost ([127.0.0.1]:42717 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1fZzAb-0003hh-CO
for submit <at> debbugs.gnu.org; Mon, 02 Jul 2018 09:47:09 -0400
Received: from eggs.gnu.org ([208.118.235.92]:53889)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <joaotavora@HIDDEN>) id 1fZzAZ-0003hT-VP
for submit <at> debbugs.gnu.org; Mon, 02 Jul 2018 09:47:08 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
(envelope-from <joaotavora@HIDDEN>) id 1fZzAT-0002ET-VZ
for submit <at> debbugs.gnu.org; Mon, 02 Jul 2018 09:47:02 -0400
X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org
X-Spam-Level: *
X-Spam-Status: No, score=1.8 required=5.0 tests=BAYES_50,FREEMAIL_FROM,
FROM_EXCESS_BASE64,T_DKIM_INVALID autolearn=disabled version=3.3.2
Received: from lists.gnu.org ([2001:4830:134:3::11]:45883)
by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32)
(Exim 4.71) (envelope-from <joaotavora@HIDDEN>)
id 1fZzAT-0002EM-Rv
for submit <at> debbugs.gnu.org; Mon, 02 Jul 2018 09:47:01 -0400
Received: from eggs.gnu.org ([2001:4830:134:3::10]:44855)
by lists.gnu.org with esmtp (Exim 4.71)
(envelope-from <joaotavora@HIDDEN>) id 1fZzAS-0006jj-Jf
for bug-gnu-emacs@HIDDEN; Mon, 02 Jul 2018 09:47:01 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
(envelope-from <joaotavora@HIDDEN>) id 1fZzAP-0002CZ-Fl
for bug-gnu-emacs@HIDDEN; Mon, 02 Jul 2018 09:47:00 -0400
Received: from mail-wm0-x22f.google.com ([2a00:1450:400c:c09::22f]:51479)
by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16)
(Exim 4.71) (envelope-from <joaotavora@HIDDEN>)
id 1fZzAP-0002C3-92
for bug-gnu-emacs@HIDDEN; Mon, 02 Jul 2018 09:46:57 -0400
Received: by mail-wm0-x22f.google.com with SMTP id s12-v6so151263wmc.1
for <bug-gnu-emacs@HIDDEN>; Mon, 02 Jul 2018 06:46:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
h=from:to:cc:subject:date:message-id:user-agent:mime-version
:content-transfer-encoding;
bh=GVDzqMWpQo0kx2tnHjh9Nb9ukDjfldrcdl7mwfD3RlI=;
b=NeFKetG4kx8/kL11a05Q0b/OdtX1V645qOiXwjFSn7U1nJ06MDgJIVpr/T0Vz4vU4z
tC/I8/rNbuqEXjc/hlMz3FZUj5aIiiKRnaXwTgcKgN1UAmbTq8JLkES5dEkWsdURTEfQ
cWGanrOrRHwuinEEDsi5OyRtQ9nmrESLipkYe4q39wcD9zkHtvBel/BFvn68r8aIsYd3
FekFY0oZUmW8TpmV3Q/2LcEuG9XQb0QCpR1bJPocOSezvaIULaslgW3j11NHQr95h6Zw
Na6/O4aBiV3+VyWMz8ApsM3uQNuRcXifsPceoNwkF38mnw+4JZr8cBboxJnDFyVF5iI+
dZNA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20161025;
h=x-gm-message-state:from:to:cc:subject:date:message-id:user-agent
:mime-version:content-transfer-encoding;
bh=GVDzqMWpQo0kx2tnHjh9Nb9ukDjfldrcdl7mwfD3RlI=;
b=bDu30EFWJ402IzisRF/Qgy/+svBQb00z/rg7hH2ObOwp++pltemWAnrkuQ90O87L6/
eKiKXJVt6CYEzdp2xO8UK6RmEv78HlT99BsOUEh7xMfqKX8zbw8X9exGqPBkkepVfZMD
5mReMV4er0fSAz3FBAiVit9y8jr8deqUoZEWFDdfuPeW4vD5CAfnSRBf+djkncxquLq7
/fINAqsPklw6DY+IJGY++X8XJ6j73vBby1ViQEFgPYnwiIdxjoujOKf5hbE/C7/cLrlZ
u170S3PIvFaYPnXJGf11+vv6bSQF6OkWUjfyyJ3VqmtgrNY9/plG9Ylu/U8SG4tG7PhY
2ZlQ==
X-Gm-Message-State: APt69E1u+FomKGmsy/Z9603U0fQBIncKTyV0bKlUul70iJYlIJlP3DTl
DND2xRs0VC8NcEiIbFBbUFk=
X-Google-Smtp-Source: AAOMgpfiL8pLV7myZC6IWymp220numNqALgvPiS07fMi4u7h0vYkU0PmcHcUDYC+JR9DdXEi42+m4g==
X-Received: by 2002:a1c:8f0e:: with SMTP id
r14-v6mr7666275wmd.79.1530539215847;
Mon, 02 Jul 2018 06:46:55 -0700 (PDT)
Received: from lolita.yourcompany.com (188.139.62.94.rev.vodafone.pt.
[94.62.139.188])
by smtp.gmail.com with ESMTPSA id m145-v6sm8923606wma.19.2018.07.02.06.46.54
(version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256);
Mon, 02 Jul 2018 06:46:54 -0700 (PDT)
From: joaotavora@HIDDEN (=?utf-8?B?Sm/Do28gVMOhdm9yYQ==?=)
To: bug-gnu-emacs@HIDDEN
Subject: 26.1; [PACTH] better xref-location-marker for imperfect file locations
Date: Mon, 02 Jul 2018 14:46:52 +0100
Message-ID: <87y3etsqb7.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-detected-operating-system: by eggs.gnu.org: Genre and OS details not
recognized.
X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x
X-Received-From: 2001:4830:134:3::11
X-Spam-Score: -3.9 (---)
X-Debbugs-Envelope-To: submit
Cc: dgutov@HIDDEN
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -4.9 (----)
Hi maintainers,
Observed this when working on Eglot, an Emacs LSP client. Some LSP
servers, when asked about symbol definitions, make the mistake of
sending an non-existent or outdated path and location.
On the other hand, because xrefs come in potentially large numbers, a
sane xref backend will not check if a file exists before making
xref-file-location objects (neither should it check if the file contains
the purported location of the definition). This can only reasonably be
done when the user decides to visit such a location.
So, currently, if the user chooses to visit a xref-file-location
pointing to a non-existing file, that file buffer is created
automatically and the command will probably error with an cryptic "End
of buffer" because of the `forward-char' call in the corresponding
xref-location-marker method. The new empty buffer isn't even shown
which would at least help the user recognize the problem.
So:
1. xref-location-marker should check for `file-readable-p' before trying
to open the file, and if that fails issues an error ("File %s can't be
found.").
2. if the file is found, xref-location-marker should detect if the
location is indeed available in the file, and if it isn't, issue a
message. In that case it should return a marker to the nearest possible
location.
3. Number 2. could turn out to be brittle and annoying if we have
changed the file in the meantime (but probably not more so than jumping
to a wrong location). So we could have a "hint" field in
xref-file-location (or a xref-hinted-file-location) that helps in
looking around the landing point for, say, a regexp, and puts point
there. Historically, this technique is successfully used in SLIME. We
could also reasonably default that field to the identifier being looked
for.
The attached patch fixes 1. and 2. It should probably go into emacs-26
Then, I'd like to know your opinions on 3., to go into master.
diff --git a/lisp/progmodes/xref.el b/lisp/progmodes/xref.el
index b0bdd62ae9..d38328cccd 100644ppp
--- a/lisp/progmodes/xref.el
+++ b/lisp/progmodes/xref.el
@@ -119,13 +119,19 @@ xref-make-file-location
(with-current-buffer
(or (get-file-buffer file)
(let ((find-file-suppress-same-file-warnings t))
+ (unless (file-exists-p file)
+ (error "File %s doesn't exist!" file))
(find-file-noselect file)))
(save-restriction
(widen)
(save-excursion
(goto-char (point-min))
(beginning-of-line line)
- (forward-char column)
+ (ignore-errors (forward-char column))
+ (unless (and (=3D (1+ (current-line)) line)
+ (=3D (current-column) column))
+ (message "Intended xref location was line=3D%d, column=3D%d"
+ line column))
(point-marker))))))
=20
(cl-defmethod xref-location-group ((l xref-file-location))
Jo=C3=A3o
joaotavora@HIDDEN (João Távora):bug-gnu-emacs@HIDDEN.
Full text available.bug-gnu-emacs@HIDDEN:bug#32034; Package emacs.
Full text available.
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997 nCipher Corporation Ltd,
1994-97 Ian Jackson.