Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Feature Request: open programs directly #1627

Open
Catalyn45 opened this issue Mar 6, 2024 · 1 comment
Open

Feature Request: open programs directly #1627

Catalyn45 opened this issue Mar 6, 2024 · 1 comment

Comments

@Catalyn45
Copy link
Contributor

Catalyn45 commented Mar 6, 2024

Hello,

I noticed that there is no way to open another process directly. Even if we don't have any shell logic ( just open an exe with some arguments ) we create a shell which will then open our program. Depending on the shell and on the shell config it may have some initialization logic which can take some time. For example this is my execution time when opening a new shell and neovim:
image

And without opening a new shell:
image

I know maybe 100-200 miliseconds is negligible for the majority of people ( or maybe other shells don't have this problem ) but I explored the code a bit and I ended up implementing something like this ( Not the only modification I did but this is the main one):
image

And in the lfrc file:
Screenshot 2024-03-06 151016

This could also have the benefit of some commands being shell/os agnostic.

This is just a little patch I made for myself which opens programs directly if the @ prefix is specified. I was wondering if this is of interest for other people too and if you think it could be a good idea to implement something like that.

@gokcehan
Copy link
Owner

gokcehan commented Mar 9, 2024

@Catalyn45 Thank you very much for the proposition and the prototype.

In my opinion, this is a quite interesting idea, but I think we are currently too much invested in the use of shell for our commands. In its current state, I think this would only be somewhat beneficial for the windows users. On unix, I think /bin/sh is rather quick in addition to having many additional features compared to this approach (e.g. control flows, variables). So in the end, I think this could have been an interesting way to develop a more minimalistic lf in an alternate universe, but I don't think it is orthogonal to our current feature set.

We can leave the issue open for a while for more discussion. I would be interested in hearing other people's opinions. Also maybe someone can come up with a suggestion to shave the execution time of commands on windows, maybe something like a lightweight shell.

Note, you can also keep the patch in your fork for other people that are interested in this. We have a dedicated wiki page where you can list your fork. If you want to improve it further, maybe you can consider adding $fs and $fx expansions in addition to $f. Also maybe proper shell lexing might be useful (e.g. shlex). If you implement shell lexing, maybe it would still be possible to define more complex commands with something like @sh -c "...".

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants