GNU bug report logs - #62776
30.0.50; 'project-find-file' ignoring 'file-name-history'

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 62776 in the body.
You can then email your comments to 62776 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Rudolf Adamkovič <salutis <at> me.com>
To: bug-gnu-emacs <at> gnu.org
Subject: 30.0.50; 'project-find-file' ignoring 'file-name-history'
Date: Tue, 11 Apr 2023 17:21:24 +0200

I am on Emacs 30 with Vertico.  At some point during the Emacs 29/30
development cycle, C-x p f (project-find-file) stopped suggesting
recently opened files correctly.  More specifically, opening a project
file updates the 'file-name-history', but the command does not suggest
recent items based on the content of the variable.

C-x C-f (find-file) works well in this regard.

Perhaps bug#58447 created this problem?

Some of the items stored in the 'file-name-history':

"~/src/eg/core/db.fnl"          ; project ~/src/eg
"~/src/eg/core/atrium.fnl"      ; project ~/src/eg
"~/org/collatz-conjecture.org"  ; project ~/
"~/org/complement.org"          ; project ~/
...

Thank you in advance!

Rudy


In GNU Emacs 30.0.50 (build 1, aarch64-apple-darwin22.3.0, NS
 appkit-2299.40 Version 13.2.1 (Build 22D68)) of 2023-03-28 built on
 Rudolfs-MacBook-Air.local
Repository revision: 28a9438169f379cea6d79fb480a85fc56ad666f4
Repository branch: master
Windowing system distributor 'Apple', version 10.3.2299
System Description:  macOS 13.2.1

Configured using:
 'configure --with-json --with-xwidgets'

Configured features:
ACL GLIB GNUTLS JSON LCMS2 LIBXML2 MODULES NOTIFY KQUEUE NS PDUMPER PNG
RSVG SQLITE3 THREADS TOOLKIT_SCROLL_BARS TREE_SITTER WEBP XIM XWIDGETS
ZLIB

Important settings:
  value of $LC_ALL: en_US.UTF-8
  locale-coding-system: utf-8-unix

Major mode: rcirc

Minor modes in effect:
  rcirc-track-minor-mode: t
  telega-root-auto-fill-mode: t
  telega-active-locations-mode: t
  telega-patrons-mode: t
  telega-mode-line-mode: t
  vertico-mode: t
  corfu-history-mode: t
  global-corfu-mode: t
  corfu-mode: t
  global-hi-lock-mode: t
  hi-lock-mode: t
  global-hl-todo-mode: t
  global-diff-hl-mode: t
  savehist-mode: t
  flyspell-mode: t
  pixel-scroll-precision-mode: t
  delete-selection-mode: t
  global-goto-address-mode: t
  goto-address-mode: t
  global-subword-mode: t
  subword-mode: t
  save-place-mode: t
  global-auto-revert-mode: t
  shell-dirtrack-mode: t
  tooltip-mode: t
  global-eldoc-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  use-hard-newlines: t
  tab-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  context-menu-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  line-number-mode: t
  transient-mark-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t

Load-path shadows:
/Users/salutis/.emacs.d/elpa/modus-themes-20230331.1210/theme-loaddefs hides /Users/salutis/src/emacs/nextstep/Emacs.app/Contents/Resources/lisp/theme-loaddefs
/Users/salutis/.emacs.d/elpa/transient-20230315.1520/transient hides /Users/salutis/src/emacs/nextstep/Emacs.app/Contents/Resources/lisp/transient

Features:
(shadow sort notmuch notmuch-tree notmuch-jump notmuch-hello
notmuch-show notmuch-print notmuch-crypto notmuch-mua notmuch-message
notmuch-draft notmuch-maildir-fcc notmuch-address notmuch-company
notmuch-parser notmuch-wash coolj icalendar diary-lib diary-loaddefs
notmuch-tag crm notmuch-lib notmuch-version notmuch-compat mail-extr
password-store auth-source-pass with-editor server completion epa-file
rcirc files-x find-dired grep fennel-mode fennel-eldoc inf-lisp cl-print
loadhist org-goto macrostep-c cmacexp macrostep hl-line telega-obsolete
telega telega-tdlib-events telega-webpage visual-fill-column telega-root
telega-info telega-chat telega-modes telega-company telega-user
telega-notifications notifications telega-voip telega-msg telega-tme
telega-sticker telega-i18n telega-vvnote bindat telega-ffplay
telega-media telega-sort telega-filter telega-ins telega-folders
telega-inline telega-tdlib telega-util rainbow-identifiers dired-aux
telega-server telega-core cursor-sensor telega-customize emacsbug
embark-consult-autoloads embark-org embark embark-autoloads loaddefs-gen
lisp-mnt tar-mode mm-archive network-stream url-cache url-http url-auth
url-gw nsm misearch multi-isearch consult-register consult-imenu rng-xsd
xsd-regexp rng-cmpct rng-nxml rng-valid rng-loc rng-uri rng-parse
nxml-parse rng-match rng-dt rng-util rng-pttrn nxml-ns nxml-mode
nxml-outln nxml-rap nxml-util nxml-enc xmltok mhtml-mode css-mode smie
color js c-ts-common treesit imenu sgml-mode facemenu shortdoc tex-mode
whitespace tempo image-file image-converter disp-table char-fold
consult-vertico consult bookmark display-line-numbers
display-fill-column-indicator paredit edmacro kmacro vertico
corfu-history corfu hi-lock hl-todo compat diff-hl log-view pcvs-util
vc-dir ewoc vc cus-start orderless pdf-loader finder-inf ob-sqlite
ob-sql ob-lisp ob-scheme geiser-impl help-fns radix-tree geiser-custom
geiser-base geiser savehist ob-R ob-plantuml ob-org org-clock
modus-operandi-theme modus-themes ob-makefile ob-lua ob-latex ob-java
ob-dot slime apropos etags fileloop xref arc-mode archive-mode hyperspec
flyspell ispell fortune flymake-proc flymake project compile
pixel-scroll cua-base comp comp-cstr warnings delsel goto-addr cap-words
superword subword saveplace vc-git diff-mode easy-mmode vc-dispatcher
oc-basic cl-extra help-mode ffap org-element org-persist org-id
org-refile avl-tree generator ol-eww eww xdg url-queue thingatpt mm-url
ol-rmail ol-mhe ol-irc ol-info ol-gnus nnselect gnus-art mm-uu mml2015
mm-view mml-smime smime gnutls dig gnus-sum shr pixel-fill kinsoku
url-file svg dom gnus-group gnus-undo gnus-start gnus-dbus dbus xml
gnus-cloud nnimap nnmail mail-source utf7 nnoo parse-time gnus-spec
gnus-int gnus-range message yank-media puny rfc822 mml mml-sec epa
derived epg rfc6068 epg-config mm-decode mm-bodies mm-encode mail-parse
rfc2231 mailabbrev gmm-utils mailheader gnus-win gnus nnheader gnus-util
text-property-search range ol-docview doc-view jka-compr image-mode exif
ls-lisp dired dired-loaddefs ol-bibtex bibtex iso8601 ol-bbdb ol-w3m
ol-doi org-link-doi autorevert filenotify cus-edit pp cus-load wid-edit
ob-clojure ob-C cc-mode cc-fonts cc-guess cc-menus cc-cmds cc-styles
cc-align cc-engine cc-vars cc-defs bug-reference ob-shell shell org ob
ob-tangle ob-ref ob-lob ob-table ob-exp org-macro org-src ob-comint
org-pcomplete pcomplete comint ansi-osc ansi-color ring org-list
org-footnote org-faces org-entities time-date noutline outline icons
ob-emacs-lisp ob-core ob-eval org-cycle org-table ol rx org-fold
org-fold-core org-keys oc org-loaddefs find-func cal-menu calendar
cal-loaddefs org-version org-compat org-macs format-spec sendmail
rfc2047 rfc2045 ietf-drums mm-util mail-prsvr mail-utils
org-drill-autoloads cape-autoloads graphviz-dot-mode-autoloads
bbdb-autoloads paredit-autoloads modus-themes-autoloads
lua-mode-autoloads htmlize-autoloads kotlin-mode-autoloads
orderless-autoloads consult-autoloads geiser-guile-autoloads
geiser-autoloads emms-autoloads flymake-grammarly-autoloads
grammarly-autoloads bnf-mode-autoloads websocket-autoloads
rainbow-mode-autoloads fennel-mode-autoloads yaml-mode-autoloads
vertico-autoloads request-autoloads telega-autoloads
rainbow-identifiers-autoloads sql-indent-autoloads ess-autoloads
all-the-icons-autoloads hl-todo-autoloads cider-autoloads
spinner-autoloads parseedn-autoloads clojure-mode-autoloads
corfu-autoloads sesman-autoloads visual-fill-column-autoloads
mentor-autoloads async-autoloads xml-rpc-autoloads ebnf-mode-autoloads
markdown-mode-autoloads url-scgi-autoloads elfeed-tube-mpv-autoloads
mpv-autoloads elfeed-tube-autoloads aio-autoloads elfeed-autoloads
citar-autoloads citeproc-autoloads string-inflection-autoloads
queue-autoloads f-autoloads parsebib-autoloads magit-autoloads pcase
magit-section-autoloads git-commit-autoloads transient-autoloads
dash-autoloads slime-autoloads macrostep-autoloads parseclj-autoloads
persist-autoloads pdf-tools-autoloads tablist-autoloads chess-autoloads
diff-hl-autoloads marginalia-autoloads sqlup-mode-autoloads
password-store-autoloads with-editor-autoloads info compat-autoloads
s-autoloads swift-mode-autoloads package browse-url url url-proxy
url-privacy url-expand url-methods url-history url-cookie
generate-lisp-file url-domsuf url-util mailcap url-handlers url-parse
auth-source cl-seq eieio eieio-core cl-macs password-cache json subr-x
map byte-opt gv bytecomp byte-compile url-vars cl-loaddefs cl-lib rmc
iso-transl tooltip cconv eldoc paren electric uniquify ediff-hook
vc-hooks lisp-float-type elisp-mode mwheel term/ns-win ns-win
ucs-normalize mule-util term/common-win tool-bar dnd fontset image
regexp-opt fringe tabulated-list replace newcomment text-mode lisp-mode
prog-mode register page tab-bar menu-bar rfn-eshadow isearch easymenu
timer select scroll-bar mouse jit-lock font-lock syntax font-core
term/tty-colors frame minibuffer nadvice seq simple cl-generic
indonesian philippine cham georgian utf-8-lang misc-lang vietnamese
tibetan thai tai-viet lao korean japanese eucjp-ms cp51932 hebrew greek
romanian slovak czech european ethiopic indian cyrillic chinese
composite emoji-zwj charscript charprop case-table epa-hook
jka-cmpr-hook help abbrev obarray oclosure cl-preloaded button loaddefs
theme-loaddefs faces cus-face macroexp files window text-properties
overlay sha1 md5 base64 format env code-pages mule custom widget keymap
hashtable-print-readable backquote threads xwidget-internal kqueue cocoa
ns lcms2 multi-tty make-network-process emacs)

Memory information:
((conses 16 1138080 189885)
 (symbols 48 52436 38)
 (strings 32 279515 7049)
 (string-bytes 1 7979030)
 (vectors 16 96681)
 (vector-slots 8 2043673 117144)
 (floats 8 14224 984)
 (intervals 56 26278 671)
 (buffers 984 43))

-- 
"Thinking is a momentary dismissal of irrelevancies."
-- Richard Buckminster Fuller, 1969

Rudolf Adamkovič <salutis <at> me.com> [he/him]
Studenohorská 25
84103 Bratislava
Slovakia

Message #8 received at 62776 <at> debbugs.gnu.org (full text, mbox):

From: Dmitry Gutov <dmitry <at> gutov.dev>
To: Rudolf Adamkovič <salutis <at> me.com>, 62776 <at> debbugs.gnu.org
Subject: Re: bug#62776: 30.0.50; 'project-find-file' ignoring
 'file-name-history'
Date: Wed, 12 Apr 2023 04:18:01 +0300

Hi! Thanks for the report.

On 11/04/2023 18:21, Rudolf Adamkovič via Bug reports for GNU Emacs, the 
Swiss army knife of text editors wrote:
> I am on Emacs 30 with Vertico.  At some point during the Emacs 29/30
> development cycle, C-x p f (project-find-file) stopped suggesting
> recently opened files correctly.  More specifically, opening a project
> file updates the 'file-name-history', but the command does not suggest
> recent items based on the content of the variable.
> 
> C-x C-f (find-file) works well in this regard.
> 
> Perhaps bug#58447 created this problem?
> 
> Some of the items stored in the 'file-name-history':
> 
> "~/src/eg/core/db.fnl"          ; project ~/src/eg
> "~/src/eg/core/atrium.fnl"      ; project ~/src/eg
> "~/org/collatz-conjecture.org"  ; project ~/
> "~/org/complement.org"          ; project ~/
> ...
> 
> Thank you in advance!

Any chance something is up in Vertico? Or with your config?

From what I can see, inserting previous historical entries during 
project file completion (with 'M-n') seems to work fine both when using 
the default completion UI, and with Counsel (which is what my current 
session is equipped with).

I also tried replacing the latter with 'M-x vertico-mode' just now, and 
'M-n' seemed to work fine there, suggesting the files visited previously 
with the same command. Tested in both Emacs 29 and 30.

Message #11 received at 62776 <at> debbugs.gnu.org (full text, mbox):

From: Rudolf Adamkovič <salutis <at> me.com>
To: Dmitry Gutov <dmitry <at> gutov.dev>, 62776 <at> debbugs.gnu.org
Subject: Re: bug#62776: 30.0.50; 'project-find-file' ignoring
 'file-name-history'
Date: Tue, 18 Apr 2023 23:38:53 +0200

Dmitry Gutov <dmitry <at> gutov.dev> writes:

> I also tried replacing the latter with 'M-x vertico-mode' just now, and 
> 'M-n' seemed to work fine there, suggesting the files visited previously 
> with the same command. Tested in both Emacs 29 and 30.

To avoid miscommunication, I shall provide a precise recipe.

(And, I apologize for not providing a recipe sooner.)

REPRODUCTION STEPS:

  1. mv ~/.emacs.d ~/.emacs.d.OLD
  2. navigate to some Git repository
  3. emacs -Q
  4. M-x package-refresh-contents RET
  5. M-x package-install RET
  6. M-x vertico RET
  7. M-x vertico-mode RET
  8. C-x p f <SOME-FILE-NAME> RET
  9. C-x p f

EXPECTED RESULT:

  Vertico pops up, showing 10 candidates.  The first candidate is
  <SOME-FILE-NAME>, the file that was opened most recently.

ACTUAL RESULTS:

  Vertico pops up, but the first candidate is not <SOME-FILE-NAME>.

NOTES:

  If I type M-x instead of C-x p f, Vertico pops up 10 most recently
  used commands, such as 'package-refresh-contents' or 'package-install'
  in this case.  All the other commands that have histories work the
  same way, only C-x p f does not work that way (anymore, but it used
  to).

Rudy
-- 
"Programming reliably -- must be an activity of an undeniably
mathematical nature […] You see, mathematics is about thinking, and
doing mathematics is always trying to think as well as possible."
-- Edsger W. Dijkstra, 1981

Rudolf Adamkovič <salutis <at> me.com> [he/him]
Studenohorská 25
84103 Bratislava
Slovakia

Message #14 received at 62776 <at> debbugs.gnu.org (full text, mbox):

From: Dmitry Gutov <dmitry <at> gutov.dev>
To: Rudolf Adamkovič <salutis <at> me.com>,
 62776 <at> debbugs.gnu.org, Daniel Mendler <mail <at> daniel-mendler.de>
Subject: Re: bug#62776: 30.0.50; 'project-find-file' ignoring
 'file-name-history'
Date: Wed, 19 Apr 2023 04:54:28 +0300

On 19/04/2023 00:38, Rudolf Adamkovič wrote:
> Dmitry Gutov<dmitry <at> gutov.dev>  writes:
> 
>> I also tried replacing the latter with 'M-x vertico-mode' just now, and
>> 'M-n' seemed to work fine there, suggesting the files visited previously
>> with the same command. Tested in both Emacs 29 and 30.
> To avoid miscommunication, I shall provide a precise recipe.
> 
> (And, I apologize for not providing a recipe sooner.)
> 
> REPRODUCTION STEPS:
> 
>    1. mv ~/.emacs.d ~/.emacs.d.OLD
>    2. navigate to some Git repository
>    3. emacs -Q
>    4. M-x package-refresh-contents RET
>    5. M-x package-install RET
>    6. M-x vertico RET
>    7. M-x vertico-mode RET
>    8. C-x p f <SOME-FILE-NAME> RET
>    9. C-x p f
> 
> EXPECTED RESULT:
> 
>    Vertico pops up, showing 10 candidates.  The first candidate is
>    <SOME-FILE-NAME>, the file that was opened most recently.
> 
> ACTUAL RESULTS:
> 
>    Vertico pops up, but the first candidate is not <SOME-FILE-NAME>.
> 
> NOTES:
> 
>    If I type M-x instead of C-x p f, Vertico pops up 10 most recently
>    used commands, such as 'package-refresh-contents' or 'package-install'
>    in this case.  All the other commands that have histories work the
>    same way, only C-x p f does not work that way (anymore, but it used
>    to).

Thanks!

If after step 9 I press M-p (previous-history-element), <SOME-FILE-NAME> 
relative to the repository root is inserted no problem. So it seems like 
the history var is used at least in some form.

But you're saying it is not used during sorting? And that used to happen?

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).

Ideally this will require just some tiny tweak in vertico. I wonder what 
Daniel thinks.

Message #17 received at 62776 <at> debbugs.gnu.org (full text, mbox):

From: Daniel Mendler <mail <at> daniel-mendler.de>
To: Dmitry Gutov <dmitry <at> gutov.dev>, Rudolf Adamkovič
 <salutis <at> me.com>, 62776 <at> debbugs.gnu.org
Subject: Re: bug#62776: 30.0.50; 'project-find-file' ignoring
 'file-name-history'
Date: Wed, 19 Apr 2023 07:54:24 +0200

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.

Daniel

Message #20 received at 62776 <at> debbugs.gnu.org (full text, mbox):

From: Dmitry Gutov <dmitry <at> gutov.dev>
To: Daniel Mendler <mail <at> daniel-mendler.de>, Rudolf Adamkovič
 <salutis <at> me.com>, 62776 <at> debbugs.gnu.org
Subject: Re: bug#62776: 30.0.50; 'project-find-file' ignoring
 'file-name-history'
Date: Wed, 19 Apr 2023 13:47:23 +0300

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.

Right. I wasn't sure what the special-ness of this case is, though.

At first I figured it might be because of the local binding for the 
history variable (this is something we changed recently, after all).

But now it just looks like if the variable is 'file-name-history', the 
hash only takes the first segment of file names from it. E.g., when 
history looked like this at the beginning:

  ("lisp/progmodes/ruby-mode.el")

the hash at the end is:

  #s(hash-table size 1 test equal rehash-size 1.5 rehash-threshold 
0.8125 data ("lisp/" 0))

I'm guessing this change is responsible for that: 
https://github.com/minad/vertico/commit/0bc58baba1904cefefccc1cd5510d2e942c181f1

Perhaps there is some straightforward way to determine whether the 
current completion table stops at separators or not, to be used here.

Message #23 received at 62776 <at> debbugs.gnu.org (full text, mbox):

From: Daniel Mendler <mail <at> daniel-mendler.de>
To: Dmitry Gutov <dmitry <at> gutov.dev>, Rudolf Adamkovič
 <salutis <at> me.com>, 62776 <at> debbugs.gnu.org
Subject: Re: bug#62776: 30.0.50; 'project-find-file' ignoring
 'file-name-history'
Date: Wed, 19 Apr 2023 14:05:27 +0200

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

Message #26 received at 62776 <at> debbugs.gnu.org (full text, mbox):

From: Dmitry Gutov <dmitry <at> gutov.dev>
To: Daniel Mendler <mail <at> daniel-mendler.de>, Rudolf Adamkovič
 <salutis <at> me.com>, 62776 <at> debbugs.gnu.org
Subject: Re: bug#62776: 30.0.50; 'project-find-file' ignoring
 'file-name-history'
Date: Wed, 19 Apr 2023 18:28:32 +0300

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.

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 '/'.

Message #29 received at 62776 <at> debbugs.gnu.org (full text, mbox):

From: Daniel Mendler <mail <at> daniel-mendler.de>
To: Dmitry Gutov <dmitry <at> gutov.dev>, Rudolf Adamkovič
 <salutis <at> me.com>, 62776 <at> debbugs.gnu.org
Subject: Re: 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

Message #32 received at 62776 <at> debbugs.gnu.org (full text, mbox):

From: Dmitry Gutov <dmitry <at> gutov.dev>
To: Daniel Mendler <mail <at> daniel-mendler.de>, Rudolf Adamkovič
 <salutis <at> me.com>, 62776 <at> debbugs.gnu.org
Subject: Re: bug#62776: 30.0.50; 'project-find-file' ignoring
 'file-name-history'
Date: Wed, 19 Apr 2023 18:49:39 +0300

On 19/04/2023 18:46, Daniel Mendler wrote:
>> 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.

But they do: the dynamically bound value of file-name-history at the 
moment when completing-read is called contain only the relative file 
names (with base directory removed).

That was the recent change in project.el we are referring to.

Message #35 received at 62776 <at> debbugs.gnu.org (full text, mbox):

From: Daniel Mendler <mail <at> daniel-mendler.de>
To: Dmitry Gutov <dmitry <at> gutov.dev>, Rudolf Adamkovič
 <salutis <at> me.com>, 62776 <at> debbugs.gnu.org
Subject: Re: bug#62776: 30.0.50; 'project-find-file' ignoring
 'file-name-history'
Date: Wed, 19 Apr 2023 19:07:15 +0200

On 4/19/23 17:49, Dmitry Gutov wrote:
> On 19/04/2023 18:46, Daniel Mendler wrote:
>>> 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.
> 
> But they do: the dynamically bound value of file-name-history at the 
> moment when completing-read is called contain only the relative file 
> names (with base directory removed).
> 
> That was the recent change in project.el we are referring to.

Ok okay, thanks! I didn't understand that. This makes a lot of sense
since then the history only contains valid values. Then you are right
that it is actually quite easy to repair the completion boundary issue
in `vertico--history-hash`.

Daniel

Message #40 received at 62776-done <at> debbugs.gnu.org (full text, mbox):

From: Dmitry Gutov <dmitry <at> gutov.dev>
To: Daniel Mendler <mail <at> daniel-mendler.de>, Rudolf Adamkovič
 <salutis <at> me.com>, 62776-done <at> debbugs.gnu.org
Subject: Re: bug#62776: 30.0.50; 'project-find-file' ignoring
 'file-name-history'
Date: Thu, 20 Apr 2023 01:24:04 +0300

On 19/04/2023 20:07, Daniel Mendler wrote:
> On 4/19/23 17:49, Dmitry Gutov wrote:
>> On 19/04/2023 18:46, Daniel Mendler wrote:
>>>> 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.
>> But they do: the dynamically bound value of file-name-history at the
>> moment when completing-read is called contain only the relative file
>> names (with base directory removed).
>>
>> That was the recent change in project.el we are referring to.
> Ok okay, thanks! I didn't understand that. This makes a lot of sense
> since then the history only contains valid values. Then you are right
> that it is actually quite easy to repair the completion boundary issue
> in `vertico--history-hash`.

Now fixed in 
https://github.com/minad/vertico/commit/ee148c0cb72f8ea306bf6bab3ef83f928cf82005.

Thanks all! Closing.

Message #43 received at 62776 <at> debbugs.gnu.org (full text, mbox):

From: Rudolf Adamkovič <salutis <at> me.com>
To: 62776 <at> debbugs.gnu.org
Subject: Re: bug#62776: closed (Re: bug#62776: 30.0.50; 'project-find-file'
 ignoring 'file-name-history')
Date: Mon, 24 Apr 2023 11:20:12 +0200

help-debbugs <at> gnu.org (GNU bug Tracking System) writes:

> Now fixed in 
> https://github.com/minad/vertico/commit/ee148c0cb72f8ea306bf6bab3ef83f928cf82005.
>
> Thanks all! Closing.

I would like to confirm, as the original bug reporter, that the problem
has been resolved on my side too.  Thank you all!

Rudy
-- 
"Logic is a science of the necessary laws of thought, without which no
employment of the understanding and the reason takes place."
-- Immanuel Kant, 1785

Rudolf Adamkovič <salutis <at> me.com> [he/him]
Studenohorská 25
84103 Bratislava
Slovakia

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.