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.bugs Subject: bug#47012: xref copies keymap properties to minibuffer Date: Fri, 2 Apr 2021 01:43:24 +0300 Message-ID: <2da88387-25ad-c615-922d-718e1b7a49d1@yandex.ru> References: <87czw9tnu9.fsf@mail.linkov.net> <3aad442a-7319-5db5-2fc6-560bb032c34d@yandex.ru> <87a6r9v24b.fsf@mail.linkov.net> <87sg4kb839.fsf@mail.linkov.net> <871rc3bls6.fsf@mail.linkov.net> <871rc2ly7x.fsf@mail.linkov.net> <4228b128-039c-2bcd-002c-5ac830d7a4d3@yandex.ru> <87pmzgtr80.fsf@mail.linkov.net> <186b46fa-3716-a76d-db85-09638d7805c7@yandex.ru> <87v99745jj.fsf@mail.linkov.net> <87zgyiv03f.fsf@mail.linkov.net> <4d3edf81-97d8-4e0e-51c0-7b2d71b57889@yandex.ru> <87o8exsv1p.fsf@mail.linkov.net> 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="2224"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.7.1 Cc: 47012@debbugs.gnu.org To: Juri Linkov Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Fri Apr 02 00:44:10 2021 Return-path: Envelope-to: geb-bug-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 1lS62r-0000RE-CI for geb-bug-gnu-emacs@m.gmane-mx.org; Fri, 02 Apr 2021 00:44:09 +0200 Original-Received: from localhost ([::1]:45354 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lS62q-0002wU-EP for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 01 Apr 2021 18:44:08 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:56442) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lS62j-0002wN-Rk for bug-gnu-emacs@gnu.org; Thu, 01 Apr 2021 18:44:01 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:47274) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1lS62j-0000hN-Ki for bug-gnu-emacs@gnu.org; Thu, 01 Apr 2021 18:44:01 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1lS62j-0005yM-IB for bug-gnu-emacs@gnu.org; Thu, 01 Apr 2021 18:44:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 01 Apr 2021 22:44:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 47012 X-GNU-PR-Package: emacs Original-Received: via spool by 47012-submit@debbugs.gnu.org id=B47012.161731701522917 (code B ref 47012); Thu, 01 Apr 2021 22:44:01 +0000 Original-Received: (at 47012) by debbugs.gnu.org; 1 Apr 2021 22:43:35 +0000 Original-Received: from localhost ([127.0.0.1]:58820 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lS62I-0005xZ-MQ for submit@debbugs.gnu.org; Thu, 01 Apr 2021 18:43:35 -0400 Original-Received: from mail-wr1-f54.google.com ([209.85.221.54]:39680) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lS62G-0005xJ-LQ for 47012@debbugs.gnu.org; Thu, 01 Apr 2021 18:43:33 -0400 Original-Received: by mail-wr1-f54.google.com with SMTP id e18so3220009wrt.6 for <47012@debbugs.gnu.org>; Thu, 01 Apr 2021 15:43:32 -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=gdlcpecX0r91Uv/Jl7KNOczU6R+9D8730KI9gxiatYs=; b=NRcB3dRsQtN+CFS3aM9IppaZnxggohRzibTddnTEezouauX7hK27nnOZ4RAoMEJT3F PlCUQYYFHDF9vCPhSpxUjnmrREzsxCG9UU22x0Iha1eRX5fqThdXhgvCGJOPpFwb3jVM PEhCfYZhzPW+6TIVu5osdgaP/oyXHxu++Fm4knlAbx8yW+rgIp/NOBUJRBwgZdpFY0Vt kate335FmJdbAB4MGHX8afAY6Vudy5eopkCykIG76IJH/woErg8qW3vAsBTcQhac1Kgq 2R/b2ZnciHrq7SEHCVM/GtvI8gdlnfyMGcFXfHFdZBHdWyithTBOJwKd3dXcmY5Ul96N q0Zw== 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=gdlcpecX0r91Uv/Jl7KNOczU6R+9D8730KI9gxiatYs=; b=o8Hn68ur6TZyfhfK4cOoPK47kvcSNP+4wJ0bBF7U9fqhO4HMVU+/25v7VT6xpy/JHK AZja39JuxL5b76wDPj2EBaoAzvefDaQscpR8dYht8kqTNEr3D3kvYHvRlTgqg8zvWips iN0NWVnLJfAWTBTCBv6EJWJ/y3x+pEDquav3B4OXWK2Z45h2/oLDps2wZP48rgSn+6XG XstjnQ9NKlc9MLAdyeFIvsIAoudBbv2Tat7UrHt1D6NTZeaO1q0FyzmCHgRm32Sedg5x QqQ9pzTlfXz3YR/mjsaPG0H3wZoAk0w8OxDts9qhhXF0iQPq5LKvjSEESNW38dLYkhZE OBXA== X-Gm-Message-State: AOAM532Aoi2G7QVdOzBzLswBpjgWUdWkiUftethKURgq8koxnsgCkZB/ /xidEwcSTeNyoVEmcwv7fg219JyzVbY= X-Google-Smtp-Source: ABdhPJxAl7Z9l+ynNRAILpVyw/AeH8sxCXVp18/ermNUGockem80NL8Gm4HOb9rBGARARGkIclHTLA== X-Received: by 2002:adf:e38a:: with SMTP id e10mr12187262wrm.37.1617317006575; Thu, 01 Apr 2021 15:43:26 -0700 (PDT) Original-Received: from [192.168.0.6] ([46.251.119.176]) by smtp.googlemail.com with ESMTPSA id m9sm12247064wro.52.2021.04.01.15.43.24 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 01 Apr 2021 15:43:25 -0700 (PDT) In-Reply-To: <87o8exsv1p.fsf@mail.linkov.net> Content-Language: en-US X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.io gmane.emacs.bugs:203451 Archived-At: On 01.04.2021 21:45, Juri Linkov wrote: >> Additionally, what do you think about toning down 'match''s background >> color? Maybe use some subtler yellow like "lemon chiffon" or "khaki1"? Or >> "light goldenrod". > > Such toning down is welcome since currently match's background is too intense. > Actually, I customized it long ago to "#ffff88" on one display, > and to "#ffffbb" on another display. I guess "#ffffbb" is too radical, > but "#ffff88" should be fine and close to "khaki1" that is nicely looking as well. > Another variant is to update gradually, i.e. start with "#ffff66", > then after some time to "#ffff88". I like either of these, just not #ffff66 (still too bright). Perhaps some darker variant would be a better option if being easy-to-notice becomes a problem (as Eli's response seems to indicate). Maybe we should ask others as well. Anyway, let's hold off on this part of the change until further discussion. >>>> Please try (setq xref-file-name-display 'project-relative). >>> Thanks, I didn't know about this. Shouldn't this be the default value >>> since this is what's displayed by grep and ripgrep. >> >> I wouldn't mind, personally. > > This is added to the patch below too. LGTM. >>> Actually, there is no exact option for what grep and ripgrep do, >>> because they display file names relative to the search directory. >>> But currently there is no xref option to display file names >>> relative to the subdirectory specified by 'C-u C-x p g'. >> >> This issue is tricky because xref-find-definitions does not assume the >> presence of a project, or even of any kind of containing directory. And >> yet, it's handy to show its results with relative file names when possible, >> too. So I picked "relative to the project" as the option value, and the >> corresponding logic. >> >> I think what you're talking about is only a problem when the directory has >> no containing project at all. In that case we could probably default to the >> value of default-directory as the reference. > > Maybe it would be nice to default to default-directory even when > 'C-u C-x p g' is used in a project. That's not the question, though. The question is whether we default to default-directory when outside of recognizable projects. Or how to differentiate 'C-u C-x p g' from other cases, such as xref-find-definitions. If this is not urgent, let's leave it for a separate bug report. > What is the real problem for me is that after navigating to > a project's subdirectory (with e.g. dired) and typing 'C-u C-x p g', > it doesn't provide the current directory as the default value. > It inserts the project root by default, not its subdirectory: > > Base directory: /project/root/ > > whereas 'M-x rgrep' conveniently provides default-directory as default. Makes sense, fixed in 4798dc0c51, please check it out. > BTW, is it possible to make 'project-find-regexp' more compatible with 'rgrep' > in other features too? What is missing is a way to modify the constructed > command line. For example, often I need to add "-w" to the constructed command > to match words only. In 'C-u M-x rgrep', this is easy to do, > but not in 'C-u C-x p g'. That's not so easy to do: the exact command is concealed inside the helper function in another package (xref). I suppose it's possible to rearrange things such that command creation and its execution are two different phases, but TBH I wouldn't love the result. Though I agree it might be handy. What I've been thinking we should have instead, is some kind of graphical prompt with multiple fields, where you can by default input the regexp and press RET, but you can also see the other options (like the file name glob to filter by, whether to search the "external roots" or not, whether to search only a particular directory, whether to ignore case, whether to search in the project-ignored files as well; options which modify the regexp or matching logic like your -w could be added too). Note that several of the options enumerated above are not something we could expose in the "edit the command" interface, because the command gets the list of files from stdin. Maybe it would be presented like one-line prompt where you can reach further fields using TAB, and maybe expand into some multiline pane (still inside the minibuffer) if some options can't fit on the same line, and you reach the end of that line by TAB-bing. To sum up, if we managed to create some visual interface for specifying the options that project-find-regexp has control over, maybe it would both result in a less complex interaction between packages, as well as in a more powerful UI which more people will be happy with.