Option to rename Cargo.lock

[alexxroche]

While learning rust I found myself editing Cargo.toml many times. I also noticed that I edited Cargo.lock zero times, (yet the name space collision of the two files is frustrating, and I wonder if its just old people with text editors and an aversion to using mice while writing code, or if there are literally dozens of us.)

I would like a ~/.cargo/config setting that would enable me to rename Cargo.lock to something like .Cargo.lock because it would permit me to edit Cargo.toml with 6 keystrokes rather than 8). "2 keystrokes? Is that all?" said someone that hasn't studied workflow, cognitive load and recursion. I don't need to see the lock file, and everything else that has a lock file finds a nice clean way to tuck it away. (Why isn't it in ~/.cargo/registry/lockfiles/ ? )

Even cargo_lock.toml would be better than the exiting Cargo.lock as $editor C{tab} would open Cargo.toml

I found someone else on a rust discord server that had raised a similar issue (which has been closed but I still face this problem.)

I also noticed a possibly related ticket that I was going to just comment on but realised that it is easier to combine issues into a project than to curate comments into a consistent correction.)

[joshtriplett]

You're not alone; many of us care about keyboard-first ergonomics.

With the benefit of hindsight, I agree that the prefix collision seems unfortunate. At this point, though, I also think the degree of churn and compatibility issues would be high enough to make this a problem to change, not least of which because many repositories have Cargo.lock files checked in.

I can imagine a way to transition this, such as reading Cargo.lock if it exists but writing to a different name if it doesn't. But that seems like an invasive change.

As an alternative, if you use bash, try setting FIGNORE=argo.lock. (Not a typo; FIGNORE doesn't work if set to a complete filename. I've reported that as a bug in bash.) That will cause tab completion to ignore Cargo.lock.

[ehuss]

I'm going to close, as I agree with @joshtriplett that the amount of churn and inconsistency this would cause is too high. I appreciate that it can be awkward with certain kinds of auto-completion, but I don't think we'll be making a change of this kind.