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

Open in a terminal editor despite the GUI passthrough #18

Open
eugenesvk opened this issue Mar 15, 2023 · 7 comments · May be fixed by #22
Open

Open in a terminal editor despite the GUI passthrough #18

eugenesvk opened this issue Mar 15, 2023 · 7 comments · May be fixed by #22

Comments

@eugenesvk
Copy link
Contributor

I've noticed that clicking on a link with terminal editor set as $EDITOR doesn't launch it (e.g., vim complains that ​Vim: Warning: Output is not to a terminal Vim: Warning: Input is not from a terminal)
I guess this is due to the fact that the click invokes the GUI bundle app as a passthrough entity

Is there some hack to make the original terminal run the command despite the GUI wrapper?

@dandavison
Copy link
Owner

There are always hacks I guess! hammerspoon, tmux send-keys? Personally I've been assuming so far that this is for GUI editor applications.

@eugenesvk
Copy link
Contributor Author

Does the app actually know who called it (to be able to ask that terminal to open the file in a term editor)? Or the OS "erases" that info and the GUI wrapper is only aware of the arguments?

In this case I guess you wouldn't be able to know exactly which terminal to request to open in, and I guess it should be done via the terminal by somehow registering another url scheme that'd open a file in a cli app instead of a gui app

@eugenesvk
Copy link
Contributor Author

eugenesvk commented Mar 16, 2023

FYI I've added a tip on how to set a custom handler within WezTerm terminal itself wezterm/wezterm#3261, which opens a new tab with the path:ln:col in a given editor

Otherwise I'm not sure it's possible to do it universally precisely because the GUI app is not aware of who called it, so not sure there is anything you can do (but if someone has a better idea, you're welcome to share it!, as far as I understood tmux send-keys would need to know the target, so would the hammerspoon trick?)

@dandavison
Copy link
Owner

One concern I have is that the shell prompt may not be available -- e.g. the link may be displayed by a pager process which is still running -- in which case even if we're opening in a terminal-based editor, we'd have to spawn a new terminal window or something to do so.

@eugenesvk
Copy link
Contributor Author

eugenesvk commented Mar 16, 2023

yeah, good point, has bumped into it, changed to always launch in a new tab just like a GUI editor would (would also remove the need to worry about existing text in the command line)

@eugenesvk
Copy link
Contributor Author

By the way, maybe we could ask the user to setenv another variable TERMINAL that would have all the flags needed to ask the given terminal to open a new tab/pane with a path, and then the gui wrapper would launch that command and just add the path?
This still wouldn't be dynamic, so clicking in one terminal could open another, so not great, but not bad?

@eugenesvk eugenesvk linked a pull request Mar 17, 2023 that will close this issue
@LRitzdorf
Copy link

I see there's already a PR here, but thought it might be worth posting a thing I put together that accomplishes the same(?) result.

In my particular case, this was built to deal with the fact that Neovim doesn't spawn its own terminal (so when xdg-open launches it, it promptly dies without doing anything). The solution to this is a simple wrapper script that launches a "host" terminal first, and passes through all of its arguments to the real Neovim. To use, just set OPEN_IN_EDITOR to point to that script on your system, probably after placing it somewhere on your PATH.

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

Successfully merging a pull request may close this issue.

3 participants