: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.

[blueyed]

I've expected :A! to work, too.
But given this discussion, I would prefer :AC now - it's more explicit and leaves the bang to be passed as is to edit.

[qstrahl]

@tpope How about a config variable that controls the behaviour? Pick a safe default and let the users who want different behaviour decide how it works. I know it's not your preferred solution but given how long we've gone without something to address this issue, maybe it's worth considering

[tommcdo]

I don't like the config variable option because it doesn't allow for easy case-by-case control. I think separate commands (the :AC family) is best, as it's too hard to reconcile the "edit without write" scenario that :A! would handle -- even though this isn't necessary for :AS and other new-window variants.

[tpope]

I experimentally added a prompt to create if the file doesn't exist. Let me know what you think. No promises I won't revert.

[AdamWhittingham]

I love it! 😄

Thank you for the time and effort, I appreciate the amount you do for the Vim community.

[rspeicher]

👍 Love this change, hoping it can be supported in vim-rails too.

[tpope]

It's a lot harder on that crufty old code base, but I hope so too.

[alex-tan]

+1 for vim-rails support. That would ease one of the most annoying parts of my workflow, esp. in older projects that don't have spec files.

[jondkinney]

+1 for vim-rails support for this also! I'm in the same boat that was previously mentioned of needing to generate lots of spec files for a project that wasn't previously tested.

[sagotsky]

I'd love to see this feature too. :A! was the first thing I reached for when :A told me there was no file. I work with a legacy codebase, so it's pretty common that a file already exists and there's no test for it. :e %<TAB><Left><Left><Left>_test<Ctrl-a>test/<CR> is my workaround :-P