-
-
Notifications
You must be signed in to change notification settings - Fork 121
Description
I'm just getting acquainted with consult
, and find consult-buffer
really nifty. There's one thing in it that I think could be improved though, thus this feature request. Candidates coming from recentf
can be quite long, since they include the full path of the file (well, almost full, just abbreviate-file-name
). I probably use longer file names than the average, but it is not difficult to get some larger than the window's width. This brings some inconvenience and problems. Even if it doesn't get actually truncated, it might be more information than (some) people would like to search for. If it does get truncated, the most important information gets literally out of view. Besides, it makes the marginalia annotations be pushed to the side, easily becoming completely hidden. And, once they get beyond the margin, they never come back, not even when only shorter candidates are displayed again.
So, the suggestion would be to shorten these candidates. file-name-nondirectory
would probably be insufficient here since there might well be two recent files with the same one, but in different directories. So, something in the lines of uniquify
's forward
style would be much welcome. I presume as an option, since I can also see that people might also want the full path as it currently is.
I've tried to look into it, but I couldn't get far. Anything related to text properties or overlays wouldn't work at all, since we want to see what we are searching. On the other hand, playing with consult--source-recent-file
's :item
field, I tried pushing a cons to items
(so that I'd have an alist of candidates from which I could grab the cdr later on), but it seems a string is expected there (as far as I could tell, at least). So I hit a bumper, I can't see a handle I could grab, hence the request.
PS: A slight side comment on consult-buffer
which I think deserves mention, but probably not a dedicated request. I think the narrowing key for the "Hidden Buffer" group is quite a premium one, and reserved for the possibly the least used case. I get why it was chosen, but I personally would like to use it for the "Buffer" group, and I did set it like that (with an "h" for the hidden ones, and stole back "b" for bookmarks). However, I noticed that you filter out the space from consult-narrow-help
and, as a result, the "Buffer" group is not shown in it. How about not filtering 32
out from consult-narrow-help
, and letting users grab that premium key?