bug#62776: 30.0.50; 'project-find-file' ignoring 'file-name-history'

[Daniel Mendler <mail@daniel-mendler.de>]

On 4/19/23 12:47, Dmitry Gutov wrote:
> On 19/04/2023 08:54, Daniel Mendler wrote:
>> On 4/19/23 03:54, Dmitry Gutov wrote:
>>> It's possible that vertico--history-hash is confused by our manipulation
>>> of the history entries -- like how they are stored as absolute file
>>> names now (bug#58447).
>> Yes, that's right. A tweak to the hash manipulation would be needed. On
>> the other hand we cannot handle all special cases in
>> vertico--history-hash. For such cases one can set the
>> vertico-sort-function or vertico-sort-override-function variables per
>> command.
> Perhaps there is some straightforward way to determine whether the 
> current completion table stops at separators or not, to be used here.

Yes, one could for example check if the base string is empty, stored in
`vertico--base`. Then the suffix should not be removed. However we would
still strip the `default-directory` (or project directory) from all the
candidates stored in the history, since the project file names are
relative. Iirc this was introduced in a recent change in project.el,
which was a good change in principle, but unfortunately breaks the
assumptions of sorting by history.

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.

Daniel