-
-
Notifications
You must be signed in to change notification settings - Fork 1.6k
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
nix repl: add :edit command #3163
Conversation
This allows to have a repl-centric workflow to working on nixpkgs. Usage: :edit <package> - heuristic that find the package file path :edit <path> - just open the editor on the file path Once invoked, `nix repl` will open $EDITOR on that file path. Once the editor exits, `nix repl` will automatically reload itself.
The doc also needs to be amended with the new command. EDIT: the nix repl commands are completely undocumented right now but are also easy discoverable from the CLI |
extract the derivation to filename:lineno heuristic
This looks nice! It'd be good to have some test cases though. Something basic like this:
That can assert that it uses |
execvp(args.front().c_str(), stringsToCharPtrs(args).data()); | ||
|
||
throw SysError("cannot run editor '%s'", editor); | ||
std::string command; | ||
for (const auto &arg : args) command += " '" + arg + "'"; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Note a huge deal, but it'd be more idiomatic (and performant) to use a std::stringstream
here.
@@ -440,6 +441,7 @@ bool NixRepl::processLine(string line) | |||
<< " <x> = <expr> Bind expression to variable\n" | |||
<< " :a <expr> Add attributes from resulting set to scope\n" | |||
<< " :b <expr> Build derivation\n" | |||
<< " :e <expr> Open the derivation in $EDITOR\n" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Unrelated to this PR, but it probably makes sense to curate an (unreleased) doc/manual/release-notes/rl-2.4.xml
that gets updated with upcoming changes as we add them. That way @edolstra doesn't have to go through the git log and write them all himself when he wants to do a release, and users can see what unreleased changes have accumulated on master.
As an extra aside, it looks like we don't have man pages or manual documentation for the nix 2.0 CLI, so I guess this is the only place it needs to be documented?
This allows to have a repl-centric workflow to working on nixpkgs.
Usage:
Once invoked,
nix repl
will open $EDITOR on that file path. Once theeditor exits,
nix repl
will automatically reload itself.