Re: Q: Is there a built-in way to read multiple file names?

Re: Q: Is there a built-in way to read multiple file names?

[Rahguzar]

> Sure, but I want the same thing to work for non-helm users.
> Preferably, without having to write helm-specific/ivy-specific/etc code.

If you want a mostly completing-read interface for this task, maybe the
function filechooser-read-file-names [1] from my GNU ELPA package
filechooser can help you. It uses a group-function to distinguish
selected files from the rest. It works pretty well with vertico but I
think should work with any UI which supports group-function well. It is
entangled with some details of the package so probably not directly
useful but I think adapting to an API similar to read-file-name is not
too hard and hopefully can help with something similar to serve Org's
needs.

There is also filechooser-dired for a dired based take.

[1] https://codeberg.org/rahguzar/filechooser/src/commit/62a9ef588331b06c818ea5db5a73e756f20fd13d/filechooser.el#L379

Rahguzar

Re: Q: Is there a built-in way to read multiple file names?

[Ihor Radchenko]

Rahguzar <rahguzar@zohomail.eu> writes:

>> Sure, but I want the same thing to work for non-helm users.
>> Preferably, without having to write helm-specific/ivy-specific/etc code.
>
> If you want a mostly completing-read interface for this task, maybe the
> function filechooser-read-file-names [1] from my GNU ELPA package
> filechooser can help you. It uses a group-function to distinguish
> selected files from the rest. It works pretty well with vertico but I
> think should work with any UI which supports group-function well. It is
> entangled with some details of the package so probably not directly
> useful but I think adapting to an API similar to read-file-name is not
> too hard and hopefully can help with something similar to serve Org's
> needs.

Yes, it is quite similar to what I described

	  ------------- completions -----------------
	  [selected files group]
	  -rw-r--r--  1 yantar92 yantar92 35151 Jun 25 10:22 COPYING <MARKED>
	  [candidates group]
	  drwxr-xr-x  8 yantar92 yantar92  4096 Jul 13 16:04 .git
	  -rw-r--r--  1 yantar92 yantar92  1044 Jun 25 10:22 .gitignore
	  -rw-r--r--  1 yantar92 yantar92    95 Jun 25 10:22 .gitmodules
	  ------------------- minibuffer ------------------------
	  Choose files: git

I tried using 

(let ((filechooser-filters '(("All" always . t)))
      (filechooser-use-popup-frame nil))
  (filechooser-read-file-names "Files: "))

M-TAB selects file.
I did not find how to remove selected file.

The main problem is that it is not built-in, and I would like to get
something in the core to cater multi-file prompts.

A side note: The usual /old/path/to/file/~/restart/path does not work as expected.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

Re: Q: Is there a built-in way to read multiple file names?

[Rahguzar]

Hi Ihor,
Ihor Radchenko <yantar92@posteo.net> writes:

> Rahguzar <rahguzar@zohomail.eu> writes:
>
>>> Sure, but I want the same thing to work for non-helm users.
>>> Preferably, without having to write helm-specific/ivy-specific/etc code.
>>
>> If you want a mostly completing-read interface for this task, maybe the
>> function filechooser-read-file-names [1] from my GNU ELPA package
>> filechooser can help you. It uses a group-function to distinguish
>> selected files from the rest. It works pretty well with vertico but I
>> think should work with any UI which supports group-function well. It is
>> entangled with some details of the package so probably not directly
>> useful but I think adapting to an API similar to read-file-name is not
>> too hard and hopefully can help with something similar to serve Org's
>> needs.
>
> Yes, it is quite similar to what I described
>
> 	  ------------- completions -----------------
> 	  [selected files group]
> 	  -rw-r--r--  1 yantar92 yantar92 35151 Jun 25 10:22 COPYING <MARKED>
> 	  [candidates group]
> 	  drwxr-xr-x  8 yantar92 yantar92  4096 Jul 13 16:04 .git
> 	  -rw-r--r--  1 yantar92 yantar92  1044 Jun 25 10:22 .gitignore
> 	  -rw-r--r--  1 yantar92 yantar92    95 Jun 25 10:22 .gitmodules
> 	  ------------------- minibuffer ------------------------
> 	  Choose files: git
>
> I tried using 
>
> (let ((filechooser-filters '(("All" always . t)))
>       (filechooser-use-popup-frame nil))
>   (filechooser-read-file-names "Files: "))
>
> M-TAB selects file.
> I did not find how to remove selected file.

M-TAB on a selected file deselects it. It is basically a toggle.

> The main problem is that it is not built-in, and I would like to get
> something in the core to cater multi-file prompts.

I would like that too, and if something like that is in the core I will
change current implementation to depend on it. I am also happy to try to
upstream the code if that is considered desirable.

> A side note: The usual /old/path/to/file/~/restart/path does not work as expected.

Can you please describe how it doesn't work? It works for me with
vertico. I thought let binding minibuffer-completing-file-name was
enough to get rfn-eshadow to work.

Rahguzar

Alternative UI for reading multiple choices (was: Q: Is there a built-in way to read multiple file names?)

[Ihor Radchenko]

Rahguzar <rahguzar@zohomail.eu> writes:

>> The main problem is that it is not built-in, and I would like to get
>> something in the core to cater multi-file prompts.
>
> I would like that too, and if something like that is in the core I will
> change current implementation to depend on it. I am also happy to try to
> upstream the code if that is considered desirable.

Let's change the subject then.
Eli favours a completely different approach for selecting files in
particular, but improving `completing-read-multiple' is also worth
discussing:

- Built-in `completing-read-multiple' works fine using its idea with
  separators, but it is a pain to remove previously selected choices,
  especially long and complex ones.
   
- filechooser implements an alternative way to read multiple choices by
  showing them as additional completion group on top of the normal
  completions

- This is conceptually similar to icicles, except that the highlights in
  icicles may work not as good when the number of completion candidates
  is too large. I feel that visual indication in a separate group is
  better, except when all possible completions can fit within
  *completions* buffer window

- As we discussed with Drew, the problem with not having all the
  completions listed in the minibuffer (like in
  `completing-read-multiple') is that it does not get stored in the
  minibuffer history. And it would be nice to have access to such
  history for multiple choice prompt.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

RE: [External] : Alternative UI for reading multiple choices (was: Q: Is there a built-in way to read multiple file names?)

[Drew Adams]

> - filechooser implements an alternative way to read multiple choices by
>   showing them as additional completion group on top of the normal
>   completions
> 
> - This is conceptually similar to icicles, except that the highlights in
>   icicles may work not as good when the number of completion candidates
>   is too large. I feel that visual indication in a separate group is
>   better, except when all possible completions can fit within
>   *completions* buffer window

The point, at that point, is to show the selected
candidates in the context of all candidates.

> - As we discussed with Drew, the problem with not having all the
>   completions listed in the minibuffer (like in
>   `completing-read-multiple') is that it does not get stored in the
>   minibuffer history. And it would be nice to have access to such
>   history for multiple choice prompt.

See my reply to your mail about that.

Retrieving a value from a history list is more
tedious than choosing a saved-candidates-set
variable from the set of such variables, using
completion.

That would be especially trie if your history
list contained also other stuff (e.g. values
returned from the minibuffer, as for normal
minibuffer histories).

ELPA package: filechooser (was: Q: Is there a built-in way to read multiple file names?)

[Ihor Radchenko]

Rahguzar <rahguzar@zohomail.eu> writes:

>> M-TAB selects file.
>> I did not find how to remove selected file.
>
> M-TAB on a selected file deselects it. It is basically a toggle.

Now got it. You are right. I did not realize that I need to narrow the
completions to the file I want to toggle. Just assumed that M-tab will
act on what is displayed on top in the completions buffer, which is the
first selected file - I was wrong.

>> A side note: The usual /old/path/to/file/~/restart/path does not work as expected.
>
> Can you please describe how it doesn't work? It works for me with
> vertico. I thought let binding minibuffer-completing-file-name was
> enough to get rfn-eshadow to work.

In short, I tried

1. Input ~/Git/emacs/src/xdisp.c
2. M-tab
3. ~/Git/emacs/src/~/

and the completion list is empty.

I recorded a short video demonstrating the problem.
https://0x0.st/XLFm.mkv

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

Re: ELPA package: filechooser

[Rahguzar]

Ihor Radchenko <yantar92@posteo.net> writes:

> Rahguzar <rahguzar@zohomail.eu> writes:
>
>>> M-TAB selects file.
>>> I did not find how to remove selected file.
>>
>> M-TAB on a selected file deselects it. It is basically a toggle.
>
> Now got it. You are right. I did not realize that I need to narrow the
> completions to the file I want to toggle. Just assumed that M-tab will
> act on what is displayed on top in the completions buffer, which is the
> first selected file - I was wrong.
>
>>> A side note: The usual /old/path/to/file/~/restart/path does not work as expected.
>>
>> Can you please describe how it doesn't work? It works for me with
>> vertico. I thought let binding minibuffer-completing-file-name was
>> enough to get rfn-eshadow to work.
>
> In short, I tried
>
> 1. Input ~/Git/emacs/src/xdisp.c
> 2. M-tab
> 3. ~/Git/emacs/src/~/
>
> and the completion list is empty.
>
> I recorded a short video demonstrating the problem.
> https://0x0.st/XLFm.mkv

You are right. The problem essentially boils down to this:

(let ((minibuffer-completing-file-name t))
 (completing-read "File: " #'completion-file-name-table))

The shadowing works as expected using vertico but not in the default
completion UI. I will try to figure out how exactly that is supposed to
be handled but I think the best place will be the
completion-file-name-table since otherwise every user of the table (or
the completion UI) needs to implement this behavior.

Rahguzar