bug#47012: xref copies keymap properties to minibuffer

[Dmitry Gutov <dgutov@yandex.ru>]

On 02.04.2021 11:25, Juri Linkov wrote:
>>>>>> 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.
> 
> Pushed now.

Thanks.

>> 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.
> 
> This is the simplest implementation:
> 
> #+begin_src emacs-lisp
> (defun project-find-word (regexp)
>    "Word-based version of ‘project-find-regexp’.
> Modifies the ‘xref-search-program-alist’ template
> to add the option ‘-w’ that matches whole words."
>    (interactive (list (project--read-regexp)))
>    (let ((xref-search-program-alist
>           (mapcar (lambda (p)
>                     (cons (car p) (replace-regexp-in-string "<C>" "-w \\&" (cdr p))))
>                   xref-search-program-alist)))
>      (project-find-regexp regexp)))
> #+end_src

Wouldn't it work the same if you instead modify the regexp to be 
surrounded with \b...\b?

> It has one minor issue:
> while it correctly filters out lines without word matches,
> when a line with a word match contains also the same string
> that is not a complete word, then both are highlighted as matches.
> There is no such problem in grep where matches are highlighted
> by the grep program itself.
> 
> BTW, the above implementation was based on a similar command for rgrep:

If you use the above suggestion, it should fix highlighting as well.

>> 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.
> 
> Sounds like a widget-based form-filling with fields.  Actually, such fields
> already exist in xref-search-program-alist template with placeholders
> <D>, <X>, <F>, <C>, <R> that are expanded by grep-expand-template.

As you can see, there are only two fields in the actual entries there. 
But we want to be able to modify more parameters.

In the spirit of Emacs, it should more keyboard-driven than, say, 
Customize widgets. I don't have the full workflow in mind yet, but it 
could use the same separator as query-replace history, only with more 
complex completion logic.