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