[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#62776: 30.0.50; 'project-find-file' ignoring 'file-name-history'
From: |
Daniel Mendler |
Subject: |
bug#62776: 30.0.50; 'project-find-file' ignoring 'file-name-history' |
Date: |
Wed, 19 Apr 2023 17:46:11 +0200 |
On 4/19/23 17:28, Dmitry Gutov wrote:
> On 19/04/2023 15:05, Daniel Mendler wrote:
>> All in all this makes `project-find-file` a special case which we could
>> handle specially in `vertico--history-hash`, but I try really hard to
>> avoid accumulating special cases in Vertico. Another alternative would
>> be to control the sorting directly in `project-find-file` by setting the
>> `display-sort-function` and `cycle-sort-function`, maybe via a
>> configuration variable. It is not really obvious where sorting is
>> handled best. For example in my Consult package, which offers "highly
>> tuned" completion commands, the commands usually try to control many
>> aspects of completion (including sorting), while for other simpler
>> commands it is better to let the completion UI do more of the work.
>
> From my outside perspective, it seems appropriate to handle inside this
> function, if it's at all possible to do without mentioning the exact
> command name, etc.
This seems almost not possible. The behavior would be quite specific for
`project-find-file` (or even only to the specific
`project-read-file-name-function`. If we need per-command special
handling one can always override `vertico-sort-function` manually.
> IIUC the issue is that is has (added) special handling for file name
> completion, and predicates that on the name of the history variable. It
> can/should be combined with an extra check which makes sure that the
> completion table uses '/' as field separators. Maybe using the
> `completion-boundaries` thingy. Or just straight calling
> `completion-boundaries` on the history elements to extract the first
> segment instead of hardcoding '/'.
Vertico already handles completion boundaries. This is how the base
string `vertico--base` is computed. But as already mentioned, this is
unfortunately not the only issue. The issue is also that
`project-find-file` removes the base directory. The entries in the
history hash would need the same treatment.
Daniel
- bug#62776: 30.0.50; 'project-find-file' ignoring 'file-name-history', Rudolf Adamkovič, 2023/04/11
- bug#62776: 30.0.50; 'project-find-file' ignoring 'file-name-history', Dmitry Gutov, 2023/04/11
- bug#62776: 30.0.50; 'project-find-file' ignoring 'file-name-history', Rudolf Adamkovič, 2023/04/18
- bug#62776: 30.0.50; 'project-find-file' ignoring 'file-name-history', Dmitry Gutov, 2023/04/18
- bug#62776: 30.0.50; 'project-find-file' ignoring 'file-name-history', Daniel Mendler, 2023/04/19
- bug#62776: 30.0.50; 'project-find-file' ignoring 'file-name-history', Dmitry Gutov, 2023/04/19
- bug#62776: 30.0.50; 'project-find-file' ignoring 'file-name-history', Daniel Mendler, 2023/04/19
- bug#62776: 30.0.50; 'project-find-file' ignoring 'file-name-history', Dmitry Gutov, 2023/04/19
- bug#62776: 30.0.50; 'project-find-file' ignoring 'file-name-history',
Daniel Mendler <=
- bug#62776: 30.0.50; 'project-find-file' ignoring 'file-name-history', Dmitry Gutov, 2023/04/19
- bug#62776: 30.0.50; 'project-find-file' ignoring 'file-name-history', Daniel Mendler, 2023/04/19
- bug#62776: 30.0.50; 'project-find-file' ignoring 'file-name-history', Dmitry Gutov, 2023/04/19
Message not available