From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Dmitry Gutov Newsgroups: gmane.emacs.devel Subject: Re: master b02c9bc: Improve documentation of new Xref options Date: Thu, 9 Sep 2021 04:22:48 +0300 Message-ID: <23668bf1-4e51-b3ba-a8f6-6fe45f4639bc@yandex.ru> References: <20210907130400.31609.90502@vcs0.savannah.gnu.org> <20210907130401.D074320A10@vcs0.savannah.gnu.org> <83a6kopeye.fsf@gnu.org> <8335qgpd64.fsf@gnu.org> <9aef615d-039a-0c9f-fda7-f3fb11db9d47@yandex.ru> <83lf47oajr.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="15947"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.13.0 Cc: emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Thu Sep 09 03:23:43 2021 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1mO8mz-0003yB-Nj for ged-emacs-devel@m.gmane-mx.org; Thu, 09 Sep 2021 03:23:41 +0200 Original-Received: from localhost ([::1]:44834 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mO8my-0006KR-9C for ged-emacs-devel@m.gmane-mx.org; Wed, 08 Sep 2021 21:23:40 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:53566) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mO8mE-0005dm-O4 for emacs-devel@gnu.org; Wed, 08 Sep 2021 21:22:54 -0400 Original-Received: from mail-wr1-x433.google.com ([2a00:1450:4864:20::433]:33564) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1mO8mC-0000On-NE; Wed, 08 Sep 2021 21:22:54 -0400 Original-Received: by mail-wr1-x433.google.com with SMTP id t18so80747wrb.0; Wed, 08 Sep 2021 18:22:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=sender:subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=eFVfWVeIbCiAKOfeNkndYtc+PnUWWl5KXM3P8imRstk=; b=bDIGkyb6oJPJjecOKnJ6SgjdyM81iTMRfO1ScCKDEgGreYtLhlYbV0ADedKE5ezMnr JxNBAP5JB+lPU/ixuFBCr+ntWpEpRoUVRWLacP8zPsYStyMeWiG0H3Y0cij1gDMAefsJ d/7YWtLcD3DTdxKdcmfMdBL9j+yN5z5kLY38foqUmcZeTSOg3l0gxEM2hYyDqL1z60TF QKJxD4tH8SkA4oxRZDCrevwPzeznaj3CN1rGh+Agkflk0EdpACGCLdEY1ycgRWUCDwE1 qE/W8sD9/oHit5Xmoog1CDzgtjLy1Zq7RGSuEZAZeE9ZUsM+hynvqVlSHKinQLcvUdWc JZxA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; 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=eFVfWVeIbCiAKOfeNkndYtc+PnUWWl5KXM3P8imRstk=; b=wEp3vMWrNaO7VGf47IK5zj1tjgMVJ5gCHpLsyX5DeumOSGZz4blanjX79Mre1Ld4sC JUle0hy3/Cf6lH3N1BcNmkojOUQ7yDCum5NXfVSj+aN9ozlhWTdY97vmfcdNljWlcAwg imxAoFu6Q0pfL6Nt4bBrNOiJVO/52snyVvKR/GuOXZ+lO2GElLNUZL+R/cX32qUSIT83 9Hj1YDv5KU2UoS9hpQjKvKjd3fpln63PoHKyITbAVjzWiR2TgMzMqIqgdeSVqcg0HIgX pcIj7Wbm+kTH6pfB2Lu4vRdmf9jwdwwui+NHBqfhUQm0/7Ob60D4slK+QPk6W3n23miL wdew== X-Gm-Message-State: AOAM533wPZtwC1NHGv680IQ2AcGp2UUUx9/vDQVbTbkIJr575bxd6Sum FEAhPDqo+rkVXKHeoN3RBYmahifadwo= X-Google-Smtp-Source: ABdhPJxxHv8APW/qE6mtInA5Q5VGxC+Mw+IejKTxpXGsDWiDn+EfOjg7wHMTrTPXeH98v2IXfzSJPw== X-Received: by 2002:a5d:6d42:: with SMTP id k2mr462360wri.116.1631150570745; Wed, 08 Sep 2021 18:22:50 -0700 (PDT) Original-Received: from [192.168.0.6] ([46.251.119.176]) by smtp.googlemail.com with ESMTPSA id s12sm220431wru.41.2021.09.08.18.22.49 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 08 Sep 2021 18:22:50 -0700 (PDT) In-Reply-To: <83lf47oajr.fsf@gnu.org> Content-Language: en-US Received-SPF: pass client-ip=2a00:1450:4864:20::433; envelope-from=raaahh@gmail.com; helo=mail-wr1-x433.google.com X-Spam_score_int: -33 X-Spam_score: -3.4 X-Spam_bar: --- X-Spam_report: (-3.4 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, NICE_REPLY_A=-1.922, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:274404 Archived-At: On 08.09.2021 09:18, Eli Zaretskii wrote: >> But the feature doesn't seem to be particularly popular/polished: the >> example value for Elisp, for instance, sets up search across all symbols >> (obarray), but subsequent navigation only works for commands, and only >> ones documented in the manual. > > I don't think we should be too bothered about that: once we have > replacements for all of those etags features, we could declare the > originals obsolete and point to replacements, something we cannot do > when the replacements are missing. So I think we should install this. Fair enough. I'd still like to see someone working on a better suggested default config for it, but it's not a blocker. >> (cl-defmethod xref-backend-apropos ((_backend (eql 'etags)) pattern) >> - (etags--xref-find-definitions (xref-apropos-regexp pattern) t)) >> + (let ((regexp (xref-apropos-regexp pattern))) >> + (nconc >> + (etags--xref-find-definitions regexp t) >> + (etags--xref-apropos-additional regexp)))) > > I'm not sure I understand why is this specific to the etags backend. > The spec seems to be more general, and xref-find-apropos is not > specific to etags, right? If as you say above it is for feature parity with 'M-x tags-apropos', then the previously sent patch should be enough. We are honoring the etags-specific variable (tags-apropos-additional-actions), so the result should be specific to the etags backend. > We'd also need a defcustom, similar to tags-apropos-additional-actions. Could we extend it to be the feature of 'M-x xref-find-apropos' in general rather than the etags backend? It's possible, if we see specific user demand for it. Here are considerations why I chose the other route: - As I said, the existing etags feature is not very polished. To bring it into the Xref API proper, we'd have to redesign it somehow, and since the feature doesn't seem to scratch any of my personal itches, I need feature requests to narrow down the design space. - It has been somewhat of a rule that backend methods don't change behavior based on some global user option, both in project.el and xref. Rather, each backend is more free to do its own thing and have backend-specific options for configuring. We can break this rule, of course, when presented with good reasons for it. - It's hard for me to say whether third-party backends will want this behavior added to their backends unconditionally. But even when we're talking about the elisp backend... do we? Want it there? - We don't need to make this choice now. It will be easy to install the already provided patch and then possibly extend the feature to all backends at some later point.