Skip to content
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

Folder Browser Create File in selected folder #78

Closed
danielnehrig opened this issue Jan 20, 2022 · 6 comments · Fixed by #79
Closed

Folder Browser Create File in selected folder #78

danielnehrig opened this issue Jan 20, 2022 · 6 comments · Fixed by #79
Labels
enhancement New feature or request

Comments

@danielnehrig
Copy link

Describe the solution you'd like
When entering the Folder Browser i'd like be able with the c button to create a file inside the fuzzy found folder.
Right now i'd have to enter the folder and create the file from the file browser

Describe alternatives you've considered
none :(

@danielnehrig danielnehrig added the enhancement New feature or request label Jan 20, 2022
@jamestrew
Copy link
Collaborator

jamestrew commented Jan 20, 2022

This would be easy to implement.
However the question becomes would we want to mimic this new behavior for the File Browser as well. If we were to, I'm thinking we'd have to add ./ into the File Browser so people would be able to create a file in the current folder (and maybe also by selecting an existing file in the folder).

If we don't mimic it, the create function will have slightly different behaviors depending on which browser a user is on. I don't think I like that.

Won't this feature really only be saving people one press of the enter key? Is that really worth tinkering with how files are created right now? 🤷‍♂️
Maybe we can have it as an opt-in feature.

@fdschmidt93
Copy link
Member

fdschmidt93 commented Jan 20, 2022

From the user perspective, what would change is the default path shown, which I think is a non-intrusive change.

Hence, I don't think we need to mirror behavior between file and folder browser here too closely. At the same time, fb_actions.create virtually has no utility (well I guess depending of config you could more easily create a file in cwd, which this change wouldn't obstruct). At the same time, this nicely makes depth=false a very sensible use case (see below).

Therefore, I'd say we should be practical and factor in this good suggestion.
I'm inclined to say that is how we should change move, copy, etc. as well. With depth=false, you could now turn the file browser into an enhanced find files and only select target directory through the folder browser.

@danielnehrig
Copy link
Author

very dope seeing this implemented now i can get rid of my makeshift version of this
big thanks

@danielnehrig
Copy link
Author

could we implement a option which would open the newly created file in a buffer after creating ? @fdschmidt93

@fdschmidt93
Copy link
Member

I'd be happy to, but a clean solution is quite a lot more complicated than you'd think.

What I would want to default to is putting the selection to the created file if possible (you eg can technically create file in file_browser mode not in the current folder).

Now, unfortunately that requires a lot of vim.schedule-ing gymnastics as we have to refresh the picker which is very async.

Why's that a problem?

Well, I'd want to support your use case with eg

["<A-c>"] = fb_actions.create + actions.select_vertical

as per upstream telescope, since I then don't have to make any assumptions how files are supposedly selected (or not) and it's the most maintainable.

The problem now is that that actions.select_vertical would have to await the scheduled fb_actions.create bit that puts the selection onto the newly created file.

It's probably easier/cleaner to circumvent picker:refresh and add straight to the finder's results, sort, and then set the selection in a synchronized fashion. But yeah, it's not that exciting work.

@danielnehrig
Copy link
Author

Fair enough, I can see that

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

Successfully merging a pull request may close this issue.

3 participants