Feature request: Select a range of files to edit
Rolv-Apneseth opened this issue · comments
Is your feature request related to a problem? Please describe.
Sometimes when I open lazygit, I see a couple of files with changes, and I want to have a closer look at or tweak more than one of them.
Describe the solution you'd like
I would like to be able to select a range of files, and open them all together with the editor. I imagine something like v, hover over range, then e, like I would do in, for example, a terminal file manager. Any way you deem best to achieve this would be great though.
Describe alternatives you've considered
Currently, this is only possible by editing one, closing the editor and going back to lazygit, then continuing to open the others one at a time.
On master we have range selection of list items already, no need to invent that. You can select ranges using v as you describe, or with shift-arrow-up/down.
Right now, editing files is only supported for a single-item selection though, like many other commands that we didn't get around to adapting for ranges yet. This is the only thing left to do, and it doesn't seem terribly hard.
Two problems I see with this:
- Currently,
eerrors out when you try to use it on a directory. When selecting multiple files in tree view we'd maybe have to filter out directories, because a range selection may span both files and directories. Or we ignore this problem and require users to type "`" to switch to list view and select the range there. - The feature only really makes sense for editor presets whose
editInTerminalflag is false, so that all files can be opened in one go. Otherwise, files would be opened one after another in the terminal, and if you had selected lots of files and decide to stop after a few, there'd be no way to do that. So, should we disable the command for editor presets that haveeditInTerminaltrue? Then it wouldn't work for nvim (but it would for nvim-remote).
So, should we disable the command for editor presets that have editInTerminal true? Then it wouldn't work for nvim (but it would for nvim-remote).
Unless we added yet another option for opening in terminal because vim supports the flag to open multiple files at once, divided into tabs, don't know about other editors.
On master we have range selection of list items already, no need to invent that. You can select ranges using
vas you describe, or with shift-arrow-up/down.
Cool, I didn't know that.
For the first point, filtering out sounds nice, as in as you're selecting, a j that would move to a directory should instead just move to the next file, if that's possible. Forcing the switch to list view is not ideal but doesn't sound too bad either.
The feature only really makes sense for editor presets whose
editInTerminalflag is false
Sorry I'm not familiar with this editInTerminal flag. Is it not possible to just pass a list of the selected file paths to the editor being opened within the terminal window? E.g. nvim path1.txt path2.txt
For the first point, filtering out sounds nice, as in as you're selecting, a
jthat would move to a directory should instead just move to the next file, if that's possible. Forcing the switch to list view is not ideal but doesn't sound too bad either.
I wasn't thinking about changing the selection behavior, it should still select items one by one as it does now. What I was thinking of is to have the e command only work on the files that are part of the selection, and ignore the directories. We can still show an error if only directories are selected.
Sorry I'm not familiar with this
editInTerminalflag. Is it not possible to just pass a list of the selected file paths to the editor being opened within the terminal window? E.g.nvim path1.txt path2.txt
And then hope that the editor does something sensible with them? Fine with me. I guess if you are using an editor that can't cope with multiple files (not sure there are any), it's a matter of "just don't do this", then.
And then hope that the editor does something sensible with them? Fine with me. I guess if you are using an editor that can't cope with multiple files (not sure there are any), it's a matter of "just don't do this", then.
Oh sorry, I did not even think that some might not support that. I know that Neovim and VSCode do, just testing now and even Nano does. I could check some others out if you want?
What I was thinking of is to have the
ecommand only work on the files that are part of the selection, and ignore the directories.
That sounds OK too.
As a side note, I was going to suggest that instead of throwing an error when e is pressed on a directory, it could instead just pass the directory to the editor, but I suppose that just runs into the same issue that not all editors are guaranteed to handle that case (Nano doesn't handle this one).
Oh sorry, I did not even think that some might not support that. I know that Neovim and VSCode do, just testing now and even Nano does. I could check some others out if you want?
I think it's fine. An editor that doesn't support it will probably either only open the first file, or return an error. Both is fine, users will learn not to do this (or switch to a better editor).
As a side note, I was going to suggest that instead of throwing an error when
eis pressed on a directory, it could instead just pass the directory to the editor, but I suppose that just runs into the same issue that not all editors are guaranteed to handle that case (Nano doesn't handle this one).
That, plus I think we should focus on things that are really desirable (versus things that we could also do while we're at it, but nobody really needs them).
Here's the PR: #3407 😄
@Rolv-Apneseth If you know how to build from source, it would be great if you could test it. And if you speak go, maybe even review it.
I'll figure it out yeah. Unfortunately I do not speak Go, one of these days I'll have to pick it up.
Fixed by #3407.