FR: Squashing part of a file without using --interactive

[sgpthomas]

Is your feature request related to a problem? Please describe.
I'm working on building a simple jj frontend in Emacs and I want to enable a workflow where you view the diff of your current edits, and squash select edits into some other change. As far as I can tell, there is no way to express a squash from just a region of a file from the command line.

Describe the solution you'd like
I guess I'm looking for something like an extension to the fileset language where you can select regions of a file. So a command might look something like jj squash --to m "region(foo.rs, 13:2, 15:1)". Totally winging the syntax here, but hopefully you get the idea.

Describe alternatives you've considered
It seems like the only other way of doing this is to create a dummy diffeditor to use for the -i editor that supports this syntax and directly modifies the temporary files. While possible, this seems pretty hacky. I guess the other way would be to use the jj api? But I haven't looked into that yet and would be more complicated to integrate. But maybe that's the best way forward. I would appreciate any feedback you might have.

[joyously]

Your description made me think of sending a "patch" through email, which seems similar.

[PhilipMetzger]

Why does jj split -i not work for you? I think this request is also similar to #5312.

[sgpthomas]

I'm looking for something that doesn't use a TUI. I want to be able to fully specify what happens from the command arguments. In general, I think this would be useful for building tools on top of jj. But I also understand if that's not a direction you want to take the project.

[PhilipMetzger]

I'm looking for something that doesn't use a TUI.

Ah, OK. Maybe we should make it configurable e.g jj split -i --tool <your-tool> so you can wrap it for Emacs.

I want to be able to fully specify what happens from the command arguments. In general, I think this would be useful for building tools on top of jj. But I also understand if that's not a direction you want to take the project.

Yes, that's very understandable. I don't think there's anything blocking it and is something the project should support to gain a wider ecosystem around it.