Feature request: Select a range of files to edit about lazygit HOT 9 CLOSED

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, e errors 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 editInTerminal flag 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 have editInTerminal true? Then it wouldn't work for nvim (but it would for nvim-remote).

from lazygit.

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.

from lazygit.

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.

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 editInTerminal flag 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

from lazygit.

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.

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 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

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.

from lazygit.

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 e command 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).

from lazygit.

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 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).

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).

from lazygit.

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.

from lazygit.

I'll figure it out yeah. Unfortunately I do not speak Go, one of these days I'll have to pick it up.

from lazygit.

Fixed by #3407.

from lazygit.