Skip to content

Allow opening single directory in Files panel with editor #4536

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

Open
wants to merge 2 commits into
base: master
Choose a base branch
from

Conversation

ivomac
Copy link

@ivomac ivomac commented May 5, 2025

  • PR Description

The openDirInEditor command is only used in the worktrees panel. It would make sense to use it in the Files panel if the user edits a directory by pressing e.

When a mix of directories and files are selected, the current behavior is to pass only the file paths to the editor, which is maintained. Editing only directories is currently disabled (ErrCannotEditDirectory). I have changed it so that it is possible to edit a single directory.

A new DisabledReason ErrCannotEditMultipleDirectories seems necessary.

Related Issue: #4512

  • Please check if the PR fulfills these requirements
  • Cheatsheets are up-to-date (run go generate ./...)
  • Code has been formatted (see here)
  • Tests have been added/updated (see here for the integration test guide)
    • I'm not sure where the tests that involve the editor are. A test that attempts to edit a single dir would make sense though.
  • Text is internationalised (see here)
    • Not relevant yet. Would be needed for a new disabled reason.
  • If a new UserConfig entry was added, make sure it can be hot-reloaded (see here)
    • New UserConfig not needed.
  • Docs have been updated if necessary
  • You've read through your own file changes for silly mistakes etc

@ivomac ivomac force-pushed the open_single_dir_with_e branch from 07d98c1 to a42b164 Compare May 8, 2025 01:08
@stefanhaller
Copy link
Collaborator

After thinking about this more, I think I changed my mind about the usefulness of the proposed behavior. What I would suggest instead is that if you select a directory, pressing e edits all the files in that directory (no matter if they are selected themselves or not). I would actually find this very useful, I just didn't realize it yet.

I often have the need to open all modified files, and currently my workaround is to switch to flat view (by pressing the backtick key) and then selecting all files there. This is cumbersome, it would be easier to just select the first directory and hit e.

Any thoughts? (@jesseduffield as well)

@ivomac
Copy link
Author

ivomac commented May 8, 2025

Yeah I can see that being useful.

I don't use range selection much, but I don't see a way to toggle selection of a single item, to pick several files that are not next to each other like a ctrl-click behavior in file explorers.

If this toggle existed (bound to V?), toggling a directory could select all files in it, like pressing enter shows/hides all files. Then you could have both both openDir and editAllFilesInDir, by selecting all files first or not.

@stefanhaller
Copy link
Collaborator

No, we don't have non-contiguous multiselections, and at this point I find it kind of unlikely that we will add it.

Personally I find an editAllFilesInDir function much more useful than an openDir function.

@ivomac
Copy link
Author

ivomac commented May 9, 2025

What if V selected all files in the same folder as the current selected file. That would to be easier to implement? It's related to the v command so seems easy to remember. And it's two keystrokes (V e) versus one/two keystrokes (e or Enter e).

I'm discussing ways of having both as being able to quickly open a directory is currently not possible. It's sometimes useful to open a directory in an editor/terminal file explorer.

Just another thought. If going the openDir with e route, could pressing e when no file is selected (empty Files) run openDirInEditor <git_dir> ? A custom command is fine but requires binding and remembering another key.

@stefanhaller
Copy link
Collaborator

What if V selected all files in the same folder as the current selected file.

That wouldn't address my need, which is to edit all currently modified files, no matter which folder they are in.

I'm discussing ways of having both as being able to quickly open a directory is currently not possible.

I'm challenging whether it's useful to open a directory that is not the repo root. I never had this need myself.

And even if we did offer this functionality, it would be a bit arbitrary which directories you would be able to open this way. For example, if the Files panel contains

▼ dir1/dir2/dir3
  M file.txt

then you would only be able to open dir3, but not dir2 or dir1, or the repo root.

Just another thought. If going the openDir with e route, could pressing e when no file is selected (empty Files) run openDirInEditor <git_dir> ?

Yeah, but what if you want to open the repo root when there are files in the list? There would be no way to do that. Just doesn't feel right to me.

I would be open to adding an extra keybinding for opening the repo root if we can find a good, free key for it, just so that users don't have to configure a custom command. But that's unrelated to this PR then. (And the functionality is already available by switching to the Worktrees tab and pressing o there.)

@ivomac
Copy link
Author

ivomac commented May 9, 2025

What if V selected all files in the same folder as the current selected file.

That wouldn't address my need, which is to edit all currently modified files, no matter which folder they are in.

Well, the selection could include the folders at the same level, and pressing it in a directory would include everything in it.

▼ dir1/dir2/dir3
  M file.txt

then you would only be able to open dir3, but not dir2 or dir1, or the repo root.

True. Forgot about this! Ok I see now that there is no nice way to openInEditor single folders and also the root with the same key. And yeah, editing single folders is ambiguous with the current Files structure.

Probably your use case is more common also. I can have a go at it.

A custom command to open root works fine with me. Maybe adding it to the documentation as an example is enough?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants