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.help Subject: Re: Xref/tags/lsp possible bug Date: Mon, 25 Apr 2022 04:32:40 +0300 Message-ID: <94193a02-b468-5d32-a746-5c84dd70c0a8@yandex.ru> References: 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="24192"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.7.0 To: Alessandro Bertulli , help-gnu-emacs@gnu.org Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane-mx.org@gnu.org Mon Apr 25 03:33:49 2022 Return-path: Envelope-to: geh-help-gnu-emacs@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 1ninbp-00068x-94 for geh-help-gnu-emacs@m.gmane-mx.org; Mon, 25 Apr 2022 03:33:49 +0200 Original-Received: from localhost ([::1]:41028 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ninbn-0006IT-Iz for geh-help-gnu-emacs@m.gmane-mx.org; Sun, 24 Apr 2022 21:33:47 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:45342) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ninan-0006IG-Vc for help-gnu-emacs@gnu.org; Sun, 24 Apr 2022 21:32:45 -0400 Original-Received: from mail-wm1-x335.google.com ([2a00:1450:4864:20::335]:56275) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1ninam-00040w-0w for help-gnu-emacs@gnu.org; Sun, 24 Apr 2022 21:32:45 -0400 Original-Received: by mail-wm1-x335.google.com with SMTP id x3so8372418wmj.5 for ; Sun, 24 Apr 2022 18:32:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=sender:message-id:date:mime-version:user-agent:subject :content-language:to:references:from:in-reply-to :content-transfer-encoding; bh=M7kEGis6/IPQj4oCqovllGnDXx3H6BGILCqcvO50ZeA=; b=MfwsPUUteiKMugDqtCYz2tP6Gzlmokp5rz4thGvukTzKh4STGF70MQ5I0bObHCEIVP 3+ELiInuat/db8fCCIrP4rhFVH8Ekkl8m50tjnFLVyBdQAKGoomzsNQd7Rbt1jkbHm6y kWvV75ZggDs1XASWZBDjcIo1/fBzZqZ8Hzlesz76r3lzXMv8tqYaMgkB0CZ3Ba0r7nJ6 FrQMeyDXspIsbwFNopU4r1aUnfjKuWwsLbBv9yG1tv5xjJuESk5BIGT30H1hbX45fqFq ck/IJRlZW+ttI26rfL9wwzbwKxxdcS/QfW/cJLNvftD4S2E6mf4dzKFcfN/5tQgujCUa 4fSg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:sender:message-id:date:mime-version:user-agent :subject:content-language:to:references:from:in-reply-to :content-transfer-encoding; bh=M7kEGis6/IPQj4oCqovllGnDXx3H6BGILCqcvO50ZeA=; b=4823UrJqKmWQ/JGRppm9c5/ONwZhXRimTmSzH3mfX6sh1fnItiCh3tQ3IvbdcIuB23 oA/RAvE6+CvgRYF8ojMq7RdHuBF6KQWIYjfZQSoJLKp3m5q7tekYdeHPwjORdVvqykUq qZebmOMyg0uF+U1xCWijwSyAneaqXZubQIfCYl2PCjzPrCxkzv95UUznpzDD1rB0Cs1E leg48LyHvMJy48M0HWRgE9/NDTxXzSsUBlbSKS7dsrt1G40WJ2lpF2PVbqsBvHKzMMHU cMc1a8ZtgkiwoG15fsxusHWrXe8ME6Z0S26scnOeSe17CSPUIfuDFoYhO7ELx2cn0uG6 57fQ== X-Gm-Message-State: AOAM531qTaVUAiSFhhdM9fJjVM/C186XtiiBnzlRzGzIGK1E79Dc/X4I zbjJMjQ5XaCG6FCmrY7TRLU= X-Google-Smtp-Source: ABdhPJwVbGoUxudtdt/FxGEH379oJ/Xm6zfOBQHSGo97KaWLk4JrFZxrsC0pItjob30++V25ORMxEA== X-Received: by 2002:a05:600c:25c5:b0:38f:f0b9:4c8c with SMTP id 5-20020a05600c25c500b0038ff0b94c8cmr14809652wml.20.1650850362538; Sun, 24 Apr 2022 18:32:42 -0700 (PDT) Original-Received: from [192.168.0.6] ([46.251.119.176]) by smtp.googlemail.com with ESMTPSA id e16-20020a05600c2dd000b0038ed449cbdbsm10699602wmh.3.2022.04.24.18.32.41 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 24 Apr 2022 18:32:42 -0700 (PDT) Content-Language: en-US In-Reply-To: Received-SPF: pass client-ip=2a00:1450:4864:20::335; envelope-from=raaahh@gmail.com; helo=mail-wm1-x335.google.com X-Spam_score_int: -14 X-Spam_score: -1.5 X-Spam_bar: - X-Spam_report: (-1.5 / 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.249, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=no autolearn_force=no X-Spam_action: no action X-BeenThere: help-gnu-emacs@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Users list for the GNU Emacs text editor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: "help-gnu-emacs" Xref: news.gmane.io gmane.emacs.help:137018 Archived-At: Hi! On 23.04.2022 15:17, Alessandro Bertulli wrote: > Hi all! > > I just stumbled upon a very strange behavior of Emacs, I don't know if > it is a bug or an error of my configuration. Basically, I noticed two > things: > > - First, when using LSP modes (both lsp-mode and eglot), the command > xref-find-definitions only acts on the symbol under point. I > explain: usually, in vanilla Emacs (emacs -q) if point is on a > whitespace/not on a symbol, invoking the command (bound to M-.) will > prompt you for an identifier to search for. However, when LSP is > active, it directly searches for an empty symbol, for example > reporting something similar to: "Symbol not found" (not the double > space, which makes me think it searches for a symbol named ""). As I > said, this happend both for lsp-mode and eglot, so maybe is a > problem of xref? AFAIK it's a limitation of the LSP protocol: it's unable to perform completion on all symbol names globally. Nor is it able, in general, to find a symbol by name (it needs a location of an existing reference in some file). So that affects how lsp-mode's Xref integration works (and Eglot's). > - Second, and minor: while I was investigating, I noticed that, > depending on the loaded packages, when giving M-., xref sometimes > asks for the symbol to search, sometimes it asks the TAGS table > first. What package can be the problem? ivy-mode, probably. Though it's not necessarily a "problem". ivy-mode takes over the completing-read UI, and it tries to show the available completions right away. The identifier completion table provided by the default Xref backend uses tags, and when the table is not loaded, has to prompt for the file to load it from.