:A creates a new file if it does not exist

[bruno-]

In rails project (using rails.vim), when in lib/my_class.rb and I hit :A, I'll see an error if there's no spec file for my_class.rb.

I was surprised to discover that this project's :A creates a new buffer if the file does not exist!
Is this behavior different by accident? Or there's going to be a new "default"?

Personally, I'd prefer to get an error if the file does not exist, and then bang :A! to create it.

Btw. fantastic plugin, just what I need - love it!

[tpope]

This seemed like a good opportunity to experiment with a different default. It's pre-1.0 so it could change.

I'm not big on :A! because ! typically means "discard changes" for navigation commands. But I'm not ruling it out yet either. Maybe this could be a difference between :A! and :AE!, or something.

[tpope]

Still undecided about other navigation commands, but I've decided I'm against automatic alternate creation.

[tommcdo]

Hmm, I had considered using :A as a way to create chains of related files. What's the reasoning behind it not creating a file?

[bruno-]

The reason I don't prefer automatic file creation is: I set up vim-projectile for navigating ruby source code, just the standard library and related test files.
When it created a buffer for a test file that didn't exist I was hella confused. Is this empty file in ruby source code? Was the new file created or not? (it's not)

Also: buffer list is now dirty and alternate buffer command (C-^) takes me to this unwanted buffer.

I do think (or just guess) file creation could be useful in many other scenarios.
No matter the default, I would be pretty happy if this behavior could be configured.
TPope, you seemed pretty decided on the decision above, but have you maybe considered introducing a new flag for this?

[tpope]

The thing that finally swayed me was porting rake.vim to use projectile.vim, and realizing that there were 6 different lib to test alternate conventions. Creating a file is iffy but overwhelming odds of creating the wrong file? Feels like a deal breaker.

I vastly value predictability over configurability. I'm still open to some sort of a ! variant.

I'm not sure I understand this chain use case.

[tommcdo]

It's not really a big deal. The general workflow would have a .projections.json file kind of like this:

"foo/*.php": {
    "command: "foo",
    "alternate": "bar/{}.php"
},
"bar/*.php": {
    "command": "bar",
    "alternate": "baz/{}.php"
},
"baz/*.php": {
    "command": "baz",
    "alternate: "foo/{}.php"
}

The idea is that these 3 files are closely related, and all depend on each other in some way. I'd create a new foo with :Efoo new/thing, add some code, then :A would create the corresponding bar, add some code, then :A would create the baz.

In reality I'd probably never actually do this; it was just an idea.

[tommcdo]

This is probably better left to scaffolding tools or something.

[tpope]

I think an in-editor solution to that might work a bit like rails.vim's "affinity", but it's hard to say how to make that general purpose.

[AdamWhittingham]

Could it be controlled using an attribute? This would leave it to the users to decide which files were created and avoids needing :A!.

{
  "app/*.rb": {
    "alternate": "spec/{}_spec.rb", 
    "create_missing": "true"
  }
}

[jarednorman]

I was complaining just the other day that I wanted a way to do this in a way that I could configure for my particular workflow.

[mtscout6]

I would also like to have files created for me, since it reduces the need for me to make sure I'm naming the files correctly. Could we do either what @AdamWhittingham suggests of maybe have a global flag that can be opt-in to create if missing, ie. something like let g:projectionistcreate=1?

[mtscout6]

Or what if we added :AC which would create it?

[qstrahl]

And :ASC, and :AVC, and :ATC

[qstrahl]

So far, the best option looks like using !, conventions be damned.