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

Allow opening current exercise in $EDITOR #2164

Open
thkoch2001 opened this issue Nov 24, 2024 · 4 comments
Open

Allow opening current exercise in $EDITOR #2164

thkoch2001 opened this issue Nov 24, 2024 · 4 comments
Labels
A-source Area: CLI source C-feature-request Category: Feature Request P-low Priority: Low

Comments

@thkoch2001
Copy link

People already suggested in previous issues that opening the current exercise in their editors should be easier: #1818, #1201, #709 and #281.

I'd propose to use the same thing (on Linux) that git commitdoes when the -m option is not given: Open $EDITOR.

Alternatively or additionally, there could be an option to copy the full path to the exercise file to the clipboard.

Please keep this issue open for a while so that we can brainstorm different ways of making it easy to open the exercise file.

@mo8it
Copy link
Contributor

mo8it commented Nov 24, 2024

I have commented on three of the linked issues. Opening a terminal editor means that Rustlings stays in the background, right? This shouldn't happen. Rustlings should always be in the foreground or the user should be able to switch to it while editing.

Even if we find some solution to the terminal editor problem, it is a bad idea to close the editor and open a new one for every exercise since Rust-Analyzer would need to reinitialize everything.

Are you familiar with the feature of terminal links added in version 6? Whenever a path to an exercise or solution is shown by Rustlings, you can click on it. Your terminal or OS takes care of opening it in the default editor.
In VS-Code for example, you can use Rustlings in the integrated terminal and click on the path to open its file.

I will keep this issue open for a while because you asked for that. But to be honest, I don't see a better way than what we currently offer with the links. I might be missing something though.

@thkoch2001
Copy link
Author

Thank you for keeping this open. I looked a bit at the source code of rustlings and believe I understand your concern. Rustlings must not be blocked by calling an external process. On the other hand there is emacsclient which can open a file in an already running emacs server without blocking. I don't know about similar features in other editors.

Thus rustlings could have an option --editcmd=$COMMAND and provide an edit key when this option is set, e.g.:

rustlings --editcmd="emacsclient -qn"

Rustlings would add the path of the exercise file after the editcmd. For anything more fancy, one can create a shell script to be calledby editcmd, e.g. for copying the filepath with xclips into the clipboard.

This would also be a nice newcomer contribution (e.g. for me) after I finished rustlings. I'm at chapter 09_strings now.

@thkoch2001
Copy link
Author

Apparently there are also helix users that would like an emacsclient-like feature: helix-editor/helix#2177

@mo8it
Copy link
Contributor

mo8it commented Nov 25, 2024

--edit-cmd sounds like a good opt-in solution :D

You are welcome to open a pull request :)

@mo8it mo8it added A-source Area: CLI source C-feature-request Category: Feature Request P-low Priority: Low labels Nov 25, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-source Area: CLI source C-feature-request Category: Feature Request P-low Priority: Low
Projects
None yet
Development

No branches or pull requests

2 participants