Autocomplete with readline not working

[Joyje]

read -e turns on autocomplete for your readline inputs. However in lf if I try to run a command using read -e I get:

--: 3: read: Illegal option -e

This suggests that the command isn't being executed in a bash shell, since -e is something bash specific. This makes me wonder how lf executes my shell functions. I am only using bash on my system everywhere else and bash is my standard shell. Does lf expect some commands to be POSIX compatible and thus exclude some bash functionality or what is going on here?

If I instead run bash -c 'read -e my_var; some_command_using $my_var' I don't get any errors, just as expected, but auto completion won't work which seems unexpected. What the (s)hell is going on here?

[ilyagr]

lf runs commands in plain sh by default. You can use set shell bash to change it.

I'm not sure about the part of your question about why completion would or wouldn't work for read -e.

[ilyagr]

Yes, % will use lf's command-line input functionality and readline features won't work. That's just how it is, it seems to me like changing this would be difficult to impossible.

It seems weird since autocomplete usually work with pipes

I'm not sure what you mean here. readline_program | another_program will have readline work, but another_program | readline_program will not make any use of readline_program's readline support. The way lf works with % programs is similar to the latter, with lf being another_program.

[Joyje]

Could you please elaborate a little on what gets piped where exactly? I assumed %{{some_command}} would be the same as ${{some_command}} | bottom_statline but maybe I am wrong.

If I press any of the "read command" symbols : ! $ % & and press <space> autocomplete for file paths is already working by default. Is it possible to do something like &{{ %command1; $command2; !command3 }}? If it is we should be able to utilize this with something like read some_var <<< %<space> since we won't need the -e anymore.
I'm not sure how, or even if those "read command" symbols can be used inside of a cmd block though.

[ilyagr]

% is actually more complicated than every other mode. For background, the $ and ! modes connect the input and output of the program to the normal terminal (bypassing lf). The & mode doesn't connect the input or output to anything (so the output is ignored).

In % mode, on the other hand, lf captures both the input and the output of the program. This is impossible to achieve with normal pipes in shell commands as far as I know, but if we insisted on writing it in term of pipes it would look something like lf | program | lf.

What this actually means is:

• Whenever the program outputs something, lf receives this output and shows the last line of it in the status bar.

• Whenever the program asks for input, lf asks the user for input in its command line. The program waits and does nothing while the user is inputting something in the command line. (This functionality is nearly identical to when lf asks the user for a command or for a filename when you use the :rename command.) When the user presses Enter, lf takes the string the user entered and passes it to the program. At this point, the program continues execution.

Note that it makes no difference whether you use read or read -e in a % command since the readline library has no chance to interact with the user. In fact, I bet readline knows to disable itself whenever the input to the program (read -e in this case) is not directly from the terminal. Again, for % programs the input would be coming from lf as far as the program is concerned.

If I press any of the "read command" symbols : ! $ % & and press autocomplete for file paths is already working by default.

This is a very good and relevant point. As I said above, when a % command asks for input, this is very similar to the user entering a "read command' as far as lf is concerned. In principle we could make lf do filename completion in the command line input whenever a % program asks for input. The main problem with this is that lf has no way to know why the program is asking for input and whether filename completion is appropriate.

Update: Elsewhere, you observed that read -e does do filename completion, even though it also has no way of knowing what the input is for. That could be used to argue that maybe lf could do that too for % programs requesting input. I'm not completely sold on it being a good idea, though.

lf could also keep a history of everything entered in this command line, though it's unclear to me whether that's useful.

At the end of that paragraph you observe that "read won't need -e anymore" which sounds right.

Is it possible to do something like &{{ %command1; $command2; !command3 }}? If it is we should be able to utilize this with something like read some_var <<< %

I didn't understand what you meant here nor whether it can possibly make sense, but hopefully understanding a bit more about how % commands work will help address this as well.

[Joyje]

Thanks for your answer! It does clarify a few things.

What I am trying to achieve here is auto completion inside lf instead of being forced to type my input in a separate shell with read -e.

I didn't understand what you meant here nor whether it can possibly make sense, but hopefully understanding a bit more about how % commands work will help address this as well.

To clarify what I meant:
Since auto completion works by default in lf (as long as it isn't running a program waiting for input such as readline), I was thinking we can solve this by nesting functions that run in multiple shells.

Since as long as set shell bash:

! is essentially bash -c but with, "press key to exit" after.
$ is exactly the same as bash -c
% is somewhat analogous to lf -remote | bash -c > lf -remote if I understood you correctly.

So if I know how to use the correct syntax for something like cmd %{{}} inside of a cmd $ {{}} I can send the input from % without it waiting for input from a program, (meaning I get auto complete by default), back to the first shell running incmd ${{}}

It would be something like running shell 1 and start a program, the program is waiting for input, but from shell 2. Shell 1 is the one waiting for input though, and shell 2 isn't, but since it is started by shell 1, shell 2 will terminate as soon as input is sent back to shell 1. You see what I am trying to do here?

Consider this pseudo code:

cmd shell_1 ${{
read somevar < <(start_shell_2_running_with %)
do_something_with $somevar
}}

[Joyje]

I realized your answer actually answers my original question, even though it doesn't fix the issue. Marked it as answered now. Thanks for your input.

[Joyje]

After experimenting with this without getting it to work, I remembered that this whole thing started as a workaround, meaning I am actually doing a workaround of a workaround, and I should probably have reported the real issue instead to begin with.

This is the actual issue:
${{
command_that_toggles_files_by_user_input"
command_that_does_something_with_toggled_files
}}

The second command completes before the first command receives any user input.

If there is a workaround that doesn't use read I'd be happy to know. Even better if the issue gets fixed.

Even though the issue hasn't actually been solved, I asked the question in such a way so that what was stated by @ilyagr actually answered the original question.