Recognising RSpec files in the Textmate bundle

Hi

Did the RSpec TMBundle ever have multiple ways of recognising RSpec
files? I’m convinced it user to look for “spec_helper” on the first
line. The Ruby bundle does something similar, as it looks for
“firstLineMatch = ‘^#!/.*\bruby’;”

The reason I ask is because I now have several files that end
“_contract.rb”. Conceivably I might have other shared example files
with different suffices. But it’s fairly safe to say they will all
start with “require ‘spec_helper’”.

WDYT?

Cheers
Ash


http://www.patchspace.co.uk/
http://www.linkedin.com/in/ashleymoran

On Aug 7, 2010, at 5:28 PM, Ashley M. wrote:

Hi

Did the RSpec TMBundle ever have multiple ways of recognising RSpec files? I’m convinced it user to look for “spec_helper” on the first line.

I’m pretty sure it never did that.

The Ruby bundle does something similar, as it looks for “firstLineMatch = ‘^#!/.*\bruby’;”

The reason I ask is because I now have several files that end “_contract.rb”. Conceivably I might have other shared example files with different suffices. But it’s fairly safe to say they will all start with “require ‘spec_helper’”.

I can’t think of a case in which I’ve required spec_helper from a file
that defines shared groups. So in my case, that is not safe to say :slight_smile:

WDYT?

I think it’s good to do things that help end users, but we’d need a more
reliable convention to base this on. Anybody (including Ashley) got any
other suggestions?

Cheers,
David

On 2010-08-07 5:44 PM, David C. wrote:

I can’t think of a case in which I’ve required spec_helper from a file that defines shared groups. So in my case, that is not safe to say :slight_smile:
I have developed a system in which I require model_helper.rb in model
specs, controller_helper.rb in controllers, and (you guessed it!)
view_helper.rb in view specs. Each of those then require spec_helper.rb.
I did this because I wanted fine-grained control over what gets loaded
when, which started when I decided I wanted to use Remarkable for model
specs only and didn’t want it available during other specs. Plus, I keep
customizations out of spec_helper.rb, which is a very good thing.

WDYT?
I think it’s good to do things that help end users, but we’d need a more reliable convention to base this on. Anybody (including Ashley) got any other suggestions?

This is probably like trying to swat a fly with Mack truck, but what if
all files under spec/ were considered RSpec files? Or possibly some
variation of that?

Peace,
Phillip

On Aug 08, 2010, at 2:17 am, Phillip K. wrote:

I have developed a system in which I require model_helper.rb in model specs, controller_helper.rb in controllers, and (you guessed it!) view_helper.rb in view specs. Each of those then require spec_helper.rb. I did this because I wanted fine-grained control over what gets loaded when, which started when I decided I wanted to use Remarkable for model specs only and didn’t want it available during other specs. Plus, I keep customizations out of spec_helper.rb, which is a very good thing.

I think the way I worded by question may have made it sound like I was
expecting everyone using TextMate to use put “require ‘spec_helper’” at
the top of the file… I didn’t mean that! I was just suggesting that
if a file starts with that require, then TextMate should see it as an
RSpec file. As you’ve pointed out, this won’t get all files, like your
custom helpers. But I imagine it’d get a fairly high proportion.

This is probably like trying to swat a fly with Mack truck, but what if all files under spec/ were considered RSpec files? Or possibly some variation of that?

I just double checked, and spec_helper.rb isn’t considered an RSpec file

  • and actually, I don’t think it should be. Also, I have a spec/support
    folder in most projects, with matchers etc. They aren’t RSpec files
    either. So this route would probably give a lot of false positives.

It might work better if this was the default folder structure:

spec/
examples/
spec_helper.rb
support/

Then you could glob everything under “examples”. I actually do this
with Cucumber, where my folder structure is:

features/
descriptions/
step_definitions/
support/

But apparently I’m alone in the world not wanting to mix .feature files
in with the support folder!

Either way, I’m not convinced using the folder structure is the best
solution. It forces TextMate users to structure there project a certain
way. If you wanted a rails app like this:

acceptance/
app/
integration/
spec/

(or whatever) then path matching wouldn’t work.

On Aug 07, 2010, at 11:44 pm, David C. wrote:

I think it’s good to do things that help end users, but we’d need a more reliable convention to base this on. Anybody (including Ashley) got any other suggestions?

Actually, I’m stuck :-/ I didn’t think it’d be hard to identify RSpec
example group files! I’m not much of a TextMate developer though.
Anyone else got ideas?

Cheers
Ash


http://www.patchspace.co.uk/
http://www.linkedin.com/in/ashleymoran

On Sun, Aug 8, 2010 at 7:11 AM, Ashley M.
[email protected] wrote:

I just double checked, and spec_helper.rb isn’t considered an RSpec file - and actually, I don’t think it should be. Also, I have a spec/support folder in most projects, with matchers etc. They aren’t RSpec files either. So this route would probably give a lot of false positives.

Textmate only looks at the first line for patterns in a language
definition, typically that’s used to find the shebang line.

I think we want Textmate to use the Ruby language grammar for rspec
files for indentation, delimiter matching etc. and the cost of having
a separate language definition in the RSpec bundle in terms of
confusion and or maintenance probably isn’t worth it.

For more about how textmate detects file times see:

http://blog.macromates.com/2007/file-type-detection-rspec-rails/


Rick DeNatale

Blog: http://talklikeaduck.denhaven2.com/
Github: rubyredrick (Rick DeNatale) · GitHub
Twitter: @RickDeNatale
WWR: http://www.workingwithrails.com/person/9021-rick-denatale
LinkedIn: http://www.linkedin.com/in/rickdenatale

On 2010-08-08 6:11 AM, Ashley M. wrote:

On Aug 08, 2010, at 2:17 am, Phillip K. wrote:

I have developed a system in which I require model_helper.rb in model specs, controller_helper.rb in controllers, and (you guessed it!) view_helper.rb in view specs. Each of those then require spec_helper.rb. I did this because I wanted fine-grained control over what gets loaded when, which started when I decided I wanted to use Remarkable for model specs only and didn’t want it available during other specs. Plus, I keep customizations out of spec_helper.rb, which is a very good thing.
I think the way I worded by question may have made it sound like I was expecting everyone using TextMate to use put “require ‘spec_helper’” at the top of the file… I didn’t mean that! I was just suggesting that if a file starts with that require, then TextMate should see it as an RSpec file. As you’ve pointed out, this won’t get all files, like your custom helpers. But I imagine it’d get a fairly high proportion.

Yes, I think I misunderstood what you were getting at. I would agree
that the majority of RSpec users probably leave the “require
‘spec_helper’” line at the beginning of their specs and therefore the
vast majority of cases would be covered. Sadly (I guess…), I am, once
again, an outlier. I can’t think of a single example file that requires
spec_helper.

This is probably like trying to swat a fly with Mack truck, but what if all files under spec/ were considered RSpec files? Or possibly some variation of that?
I just double checked, and spec_helper.rb isn’t considered an RSpec file - and actually, I don’t think it should be.

I guess I also misunderstood what you meant by “RSpec file”. I assumed
it to mean any file belonging to RSpec, but I guess what it really means
is a file with examples in it?

features/
descriptions/
step_definitions/
support/

But apparently I’m alone in the world not wanting to mix .feature files in with the support folder!

I don’t think you are alone in your quest to achieve greater
organization. I am guessing that in your suggested RSpec folder
structure, the current folders of controllers|helpers|models|views would
all live under examples? I might go for that. I think some (many?) might
say that it’s an unnecessary level, but I think I’d prefer that. I might
even look into doing that anyway :slight_smile: After all, my Cucumber folder
structure is

cuke/
features/
steps/
support/

And I use subfolders under features and steps just like I do in RSpec.

Either way, I’m not convinced using the folder structure is the best solution. It forces TextMate users to structure there project a certain way. If you wanted a rails app like this:

acceptance/
app/
integration/
spec/

(or whatever) then path matching wouldn’t work.

Right. I wouldn’t want a particular structure to be forced upon me, so
I’d rather not see that happen to anyone.

On Aug 07, 2010, at 11:44 pm, David C. wrote:

I think it’s good to do things that help end users, but we’d need a more reliable convention to base this on. Anybody (including Ashley) got any other suggestions?
Actually, I’m stuck :-/ I didn’t think it’d be hard to identify RSpec example group files! I’m not much of a TextMate developer though. Anyone else got ideas?

Cheers
Ash

Here’s another idea that’s not so great, but maybe it will spur some
thinking in someone else. What about a custom generator (or a flag on
the official one) that added something like a shebang line at the
beginning of example files. A short comment that identifies the file,
like “# RSpec”. Then a TM bundle could pick up on that and be happy. I
don’t know about vim or any other editor, though.

Peace,
Phillip

On Sun, Aug 8, 2010 at 3:53 PM, Phillip K.
[email protected]wrote:

Here’s another idea that’s not so great, but maybe it will spur some
thinking in someone else. What about a custom generator (or a flag on the
official one) that added something like a shebang line at the beginning of
example files. A short comment that identifies the file, like “# RSpec”.
Then a TM bundle could pick up on that and be happy.

Putting aside the fact that this is solving a very specific problem…
what
about #!/usr/bin/env spec ? 99% of the time the shebang won’t be used,
I’d
wager, so it’d pretty much be harmless.

– Elliot

On Sun, Aug 8, 2010 at 11:45 PM, Elliot W.
[email protected] wrote:

about #!/usr/bin/env spec ? 99% of the time the shebang won’t be used, I’d
wager, so it’d pretty much be harmless.

As I tried to point out, textmate looks for shebang lines to compare
against in the language definitions. Right now the rspec bundle
doesn’t have a language definition since rspec files are really ruby
files and want to use that language definition.

I guess I just don’t see what’s wrong with using the convention of
naming spec files with the suffix _spec.rb as Mr. Textmate suggests
http://blog.macromates.com/2007/file-type-detection-rspec-rails/

It’s worked well for me for quite some time.


Rick DeNatale

Blog: http://talklikeaduck.denhaven2.com/
Github: rubyredrick (Rick DeNatale) · GitHub
Twitter: @RickDeNatale
WWR: http://www.workingwithrails.com/person/9021-rick-denatale
LinkedIn: http://www.linkedin.com/in/rickdenatale

On Mon, Aug 9, 2010 at 11:23 AM, David C. [email protected]
wrote:

official one) that added something like a shebang line at the beginning of
files and want to use that language definition.

I guess I just don’t see what’s wrong with using the convention of
naming spec files with the suffix _spec.rb as Mr. Textmate suggests
File Type Detection (RSpec & Rails)

It’s worked well for me for quite some time.

Hey Rick,

Shared groups are typically stored in a file that has a different name, and ppl want access to all the code completion and syntax highlighting of spec files in those files.

Well, I’d still use a different file name suffix which I could set
textmate to recognize as a spec

_sspec.rb or _sgroup.rb

something like that.

If TM 2 ever sees the light of day, maybe there will be alternatives,
but …


Rick DeNatale

Blog: http://talklikeaduck.denhaven2.com/
Github: rubyredrick (Rick DeNatale) · GitHub
Twitter: @RickDeNatale
WWR: http://www.workingwithrails.com/person/9021-rick-denatale
LinkedIn: http://www.linkedin.com/in/rickdenatale

On Aug 9, 2010, at 9:56 AM, Rick DeNatale wrote:

naming spec files with the suffix _spec.rb as Mr. Textmate suggests
File Type Detection (RSpec & Rails)

It’s worked well for me for quite some time.

Hey Rick,

Shared groups are typically stored in a file that has a different name,
and ppl want access to all the code completion and syntax highlighting
of spec files in those files.

HTH,
David

On 8 Aug 2010, at 21:53, Phillip K. wrote:

I don’t think you are alone in your quest to achieve greater organization. I am guessing that in your suggested RSpec folder structure, the current folders of controllers|helpers|models|views would all live under examples? I might go for that. I think some (many?) might say that it’s an unnecessary level, but I think I’d prefer that. I might even look into doing that anyway :slight_smile: After all, my Cucumber folder structure is

cuke/
features/
steps/
support/

And I use subfolders under features and steps just like I do in RSpec.

Right. I wouldn’t want a particular structure to be forced upon me, so I’d rather not see that happen to anyone.

The biggest problem I can see is the RSpec TMBundle’s “Alternate File”
command, which I would probably sacrifice a finger to keep*. Autotest
is easy enough to reconfigure to look in different spec subdirs.

If only there was some way of integrating Alternate File and Autotest
mappings…

Ash

  • But since I’m still typing 9-fingered after I trapped one under a
    weight in a gym, I consider this pre-payed. So nobody mess with
    Alternate File!!! Until my finger is better anyway.


http://www.patchspace.co.uk/
http://www.linkedin.com/in/ashleymoran

On Tue, Aug 10, 2010 at 9:40 AM, Ashley M.
[email protected] wrote:

Hi Rick,

I think that was what David was saying? (If I understood you both correctly, that is.)

It’s not enough to treat RSpec files as Ruby because they have too many specific highlighting rules and completions etc, which we don’t want mixed into plain Ruby source.

Yeah, I see that the RSpec bundle actually does have a Language
definition, somehow I missed that when I looked before.

My specific example is I now have three files “*_contract.rb” that I’d like highlighted. But if everyone chipped in with their own convention we’d probably end in chaos.

I like the “_sgroup.rb” idea though. Or maybe “_examples.rb”? That’s fairly generic.

And easy to add yourself by just editing the bundle.

Or… how about an actual dot-suffix, “.rspec”, eg, “active_record_associations.rspec”, which would be designed to indicate an RSpec-loadable file (prob shared example groups), but one that doesn’t make sense to run alone (or can’t be)? Any legs in that idea?

I don’t think I like that. For one thing most folks don’t include the
dot suffix in require ‘statements’.


Rick DeNatale

Blog: http://talklikeaduck.denhaven2.com/
Github: rubyredrick (Rick DeNatale) · GitHub
Twitter: @RickDeNatale
WWR: http://www.workingwithrails.com/person/9021-rick-denatale
LinkedIn: http://www.linkedin.com/in/rickdenatale

On 10 Aug 2010, at 15:03, Rick DeNatale wrote:

And easy to add yourself by just editing the bundle.

I’ve tried this before. Unfortunately, it just leads to pain when you
try to update the bundle via Git

Or… how about an actual dot-suffix, “.rspec”, eg, “active_record_associations.rspec”, which would be designed to indicate an RSpec-loadable file (prob shared example groups), but one that doesn’t make sense to run alone (or can’t be)? Any legs in that idea?

I don’t think I like that. For one thing most folks don’t include the
dot suffix in require ‘statements’.

Good point, I forgot about that.

Cheers
Ash


http://www.patchspace.co.uk/
http://www.linkedin.com/in/ashleymoran

On 9 Aug 2010, at 17:37, Rick DeNatale wrote:

Well, I’d still use a different file name suffix which I could set
textmate to recognize as a spec

_sspec.rb or _sgroup.rb

something like that.

Hi Rick,

I think that was what David was saying? (If I understood you both
correctly, that is.)

It’s not enough to treat RSpec files as Ruby because they have too many
specific highlighting rules and completions etc, which we don’t want
mixed into plain Ruby source.

My specific example is I now have three files “*_contract.rb” that I’d
like highlighted. But if everyone chipped in with their own convention
we’d probably end in chaos.

I like the “_sgroup.rb” idea though. Or maybe “_examples.rb”? That’s
fairly generic.

Or… how about an actual dot-suffix, “.rspec”, eg,
“active_record_associations.rspec”, which would be designed to indicate
an RSpec-loadable file (prob shared example groups), but one that
doesn’t make sense to run alone (or can’t be)? Any legs in that idea?

Cheers
Ash


http://www.patchspace.co.uk/
http://www.linkedin.com/in/ashleymoran