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

Broken workflow: return to the old incremental numbering behaviour when pasting files #76752

Closed
axefrog opened this issue Jul 5, 2019 · 10 comments
Assignees
Labels
feature-request Request for new features or functionality file-explorer Explorer widget issues verification-needed Verification of issue is requested verified Verification succeeded
Milestone

Comments

@axefrog
Copy link

axefrog commented Jul 5, 2019

I do a lot of rapid iteration on prototype code and like to frequently copy deprecated code files into archive subdirectories so they are still readily available for me to refer to immediately, without the friction of having to do so via Git branch/commit/diff operations. I also write a lot of markdown notes in sequentially-numbered files, each of which I create by copying and pasting its predecessor which I then use as a base template that is conveniently already named correctly as soon as it is created.

Until now, the incremental numbering behaviour has been nice as it let me copy a file into a folder and it would simply increment the number at the end of the file without polluting the rest of the filename. After the latest release, it's now polluting the filename with "copy", which forces me to manually rename the file. This is one of those cases where a change to help a few users has had the opposite effect for others. Usually a change in behaviour in a new release is accompanied by a setting in recognition that different people have different workflow preferences. There is no setting in this case, so I have no choice but to accept the added friction in my workflow.

Would it be possible to include a setting to retain the old behaviour?

@WCSB
Copy link

WCSB commented Jul 6, 2019

I really need a digital incremental copy

@bpasero bpasero assigned isidorn and unassigned bpasero Jul 7, 2019
@isidorn isidorn added feature-request Request for new features or functionality file-explorer Explorer widget issues labels Jul 8, 2019
@isidorn
Copy link
Contributor

isidorn commented Jul 8, 2019

This is a fair request. We will not do it in the current milestone but will consider it in the future.

@isidorn isidorn added this to the Backlog milestone Jul 8, 2019
@axefrog
Copy link
Author

axefrog commented Jul 8, 2019

@isidorn Thanks!

@thomas-darling
Copy link

Yeah, I strongly prefer the previous number-based naming too, for all the same reason as @axefrog - and also because it ensured the new file would appear right next to the original file. With the new naming, the copy easily gets lost among the other files:

billing-method-status.ts
billing-method.ts
billing-plan copy.ts
billing-plan-interval.ts
billing-plan-status.ts
billing-plan.1.ts
billing-plan.ts
billing-service.ts

I'd encourage you to roll this change back asap, or alternatively introduce an option :-)

@lukasz21
Copy link

I also prefer the old method of copy. Perhaps an option could be add where the user can choose how the file is copied?

@isidorn
Copy link
Contributor

isidorn commented Jul 29, 2019

More details on the motivation why we did it #55128
Assigning to next milestone so we introduce an option for controlling this behavior.

@thomas-darling
Copy link

@isidorn Actually, I thought it would only increment the number postfix added at the end of the file name. I can certainly see how magically incrementing numbers in the middle of the file name could be surprising and confusing to users, and possibly even a source of bugs.

Personally, I'd prefer that if you copy a file, it simply adds the .1 postfix to the name of the copy, and if you then create a copy of the copy, it simply increments that postfix. This is a simple and predictable behavior, which ensures the original part of the file name remain unchanged.

@fhelwanger
Copy link

@thomas-darling It wouldn't work for the workflow I described in #55128 (comment) 😕

@isidorn
Copy link
Contributor

isidorn commented Aug 9, 2019

We have introduced a new setting
explorer.incrementalNaming which can have the values simple or smart.
simple appends the word "copy" at the end of the duplicated name potentially followed by a number. The current vscode stable behavior.
smart adds a number at the end of the duplicated name. If some number is already part of the name, tries to increase that number. The previous behavior.

The default value is simple.

You can try it out in vscode insiders in a couple of days.
Feedback is very welcome, especially on the setting / description wording.
Thanks!

@isidorn isidorn added the verification-needed Verification of issue is requested label Aug 9, 2019
@isidorn
Copy link
Contributor

isidorn commented Aug 26, 2019

To verify: make sure this setting behaves as described in my last comment and provide potential feedback on the naming of the setting.

@mjbvz mjbvz added the verified Verification succeeded label Aug 28, 2019
@vscodebot vscodebot bot locked and limited conversation to collaborators Sep 23, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
feature-request Request for new features or functionality file-explorer Explorer widget issues verification-needed Verification of issue is requested verified Verification succeeded
Projects
None yet
Development

No branches or pull requests

8 participants