Practically, the concern I see in this additional `ls` call here is a slowdown when dired is used for remote locations. It is an added delay to the delay already incurred with read-file-name when called interactively.

On that note, dired-goto-file could just use the files already inserted in the buffer to provide options to the user to pick from. That could obviate the need to convert the read-file-name choice to what dired originally got from the insert-directory-program.

Listing the missing control characters is another option, but placing this conversion in dired is making it more complex when the insert-directory-program like "ls" is already handling it.

We could call here insert-directory-program instead of "ls", unless the escape option is not supported in this program. I don't know how we can find that out.

On Wed, Apr 5, 2023 at 12:45 AM Eli Zaretskii <eliz@gnu.org> wrote:

> From: Charles El Hourani <charlie.eh@gmail.com>
> Date: Tue, 4 Apr 2023 21:52:39 +0300
>
> Here is a way to solve the issue by calling `ls` directly, without re-implementing the "-b" functionality of ls in
> elisp.
>
> From 22962ffd84370ac05017ed05cca88286d010aa0e Mon Sep 17 00:00:00 2001
> From: Charlie El Hourani <charlie.eh@gmail.com>
> Date: Tue, 4 Apr 2023 21:26:07 +0300
> Subject: [PATCH] Fix dired goto file when -b is provided to ls (bug#10607)
>
> This fixes the goto file in dired mode for:
> - files containing a control character
> - and when dired uses ls with the "-b" flag
>
> The goto file function calls 'ls' to give it the escaped name.

Thanks, but is it really a good idea to invoke a program each time we
move in Dired? dired-goto-file is a function that is used very
frequently.

In any case, calling literally "ls" is not TRT, IMO, since the user
could have modified the value of insert-directory-program.