Add `:write` to nix repl

janik commented

2024-03-25 16:12:30 +00:00

Member

Often I quickly try things in the repl to see if they work but it's annoying to then type them twice or copy and paste it by hand.

Describe the solution you'd like

It would be nice to have something like :w/:write that expects a path and just writes a file with all successfully evaled "commands" and removes repl specific things like :p from the code. Additionally it would also be nice if it also ran a formatter on the code before writing to the file (for example nixfmt-rfc-style since it's now the default for nixpkgs)

## Is your feature request related to a problem? Please describe. Often I quickly try things in the repl to see if they work but it's annoying to then type them twice or copy and paste it by hand. ## Describe the solution you'd like It would be nice to have something like `:w`/`:write` that expects a path and just writes a file with all successfully evaled "commands" and removes repl specific things like `:p` from the code. Additionally it would also be nice if it also ran a formatter on the code before writing to the file (for example nixfmt-rfc-style since it's now the default for nixpkgs)

lunaphied added the

ux

label 2024-03-25 16:15:57 +00:00

gabriella439 commented

2024-03-25 16:17:56 +00:00

Owner

Can you elaborate a bit more on the use case for mirroring REPL commands to a file?

Part of the reason I'm asking is that many REPLs provide a .history file containing commands the user has entered, but it sounds like that's not exactly what you're looking for but I want to better understand how you intend to use this.

Can you elaborate a bit more on the use case for mirroring REPL commands to a file? Part of the reason I'm asking is that many REPLs provide a `.history` file containing commands the user has entered, but it sounds like that's not *exactly* what you're looking for but I want to better understand how you intend to use this.

qyriad commented

2024-03-25 16:28:25 +00:00

Owner

Minor complication worthy of note: the REPL supports lines of the form key = value that add bindings scoped to the REPL session, which can be overridden with later commands. These would need to be translated (presumably to let bindings), but they also interact differently than let bindings (they aren't recursive iwrc), so there'd need to be some figuring-out of the correct semantics there.

Minor complication worthy of note: the REPL supports lines of the form `key = value` that add bindings scoped to the REPL session, which can be overridden with later commands. These would need to be translated (presumably to let bindings), but they also interact differently than let bindings (they aren't recursive iwrc), so there'd need to be some figuring-out of the correct semantics there.

janik commented

2024-03-25 16:32:36 +00:00

Author

Member

Can you elaborate a bit more on the use case for mirroring REPL commands to a file?

Uh sure, I often draft up some stuff stuff in the repl and it would be convenient not to have to type it twice so writing it to a file would be quite nice to not have to type it twice.
(I'm aware that I can also just write the code in a editor and use nix repl --file $file)

> Can you elaborate a bit more on the use case for mirroring REPL commands to a file? Uh sure, I often draft up some stuff stuff in the repl and it would be convenient not to have to type it twice so writing it to a file would be quite nice to not have to type it twice. (I'm aware that I can also just write the code in a editor and use `nix repl --file $file`)

qyriad commented

2024-03-25 16:33:11 +00:00

Owner

(…TWL about nix repl --file. Damn.)

(…TWL about `nix repl --file`. Damn.)

gabriella439 commented

2024-03-25 16:36:53 +00:00

Owner

Would a .history file solve your issue? That seems to be like a more standard REPL feature that lots of line editing packages support out of the box. I think that would be simpler than rolling our own custom thing that filters post-processes the commands before they are written out.

Would a `.history` file solve your issue? That seems to be like a more standard REPL feature that lots of line editing packages support out of the box. I think that would be simpler than rolling our own custom thing that filters post-processes the commands before they are written out.

jade commented

2024-03-25 16:41:46 +00:00

Owner

The thing about a history file is it doesn't let you grab the current session only. I think that's part of the requirements here.

gabriella439 commented

2024-03-25 16:44:36 +00:00

Owner

I believe making the history file location configurable (e.g. via a command-line option or REPL command) would address that

janik commented

2024-03-25 18:04:38 +00:00

Author

Member

This is just a nice to have thing, I would personally be interested in, bun non of you have to spend any time on this.

I believe making the history file location configurable (e.g. via a command-line option or REPL command) would address that

I don't think so because as jade said having a per session history would be required here, but I may be missing your point.

This is just a nice to have thing, I would personally be interested in, bun non of you have to spend any time on this. > I believe making the history file location configurable (e.g. via a command-line option or REPL command) would address that I don't think so because as jade said having a per session history would be required here, but I may be missing your point.

gabriella439 commented

2024-03-25 18:08:56 +00:00

Owner

What I'm proposing is that if we added support for history files then we could include support for specifying the path to use for the history file in the REPL, like this:

nix-repl> :history foo.txt

In other words, I'm suggesting two amendments to your original proposal:

The command would be :history/:h instead of :write/:w
The history file would store all REPL commands (without post-processing) instead of filtering them

Unless I'm missing something I think that still addresses your use case

What I'm proposing is that if we added support for history files then we could include support for specifying the path to use for the history file in the REPL, like this: ``` nix-repl> :history foo.txt ``` In other words, I'm suggesting two amendments to your original proposal: - The command would be `:history`/`:h` instead of `:write`/`:w` - The history file would store all REPL commands (without post-processing) instead of filtering them Unless I'm missing something I *think* that still addresses your use case

👍 1

jade commented

2024-03-25 19:38:08 +00:00

Owner

one issue with this is that you can't do it retroactively which is a bit of a limitation, i think?

gabriella439 commented

2024-03-25 20:16:44 +00:00

Owner

Yeah, that's true, although the commands wouldn't have been lost; they would have just been written to the default history file path.

Another possible option that might give the best of both worlds is to automatically generate a unique history file path for each session by default so that the user doesn't even have to run any command.

Yeah, that's true, although the commands wouldn't have been lost; they would have just been written to the default history file path. Another possible option that might give the best of both worlds is to automatically generate a unique history file path for each session by default so that the user doesn't even have to run any command.

jade added the

Area/repl

label 2024-05-30 07:12:29 +00:00

Add :write to nix repl #182

Is your feature request related to a problem? Please describe.

Describe the solution you'd like

Add `:write` to nix repl #182