When and how is the “First Line Match” setting of language grammars considered?
In my experiments it doesn't seem to have any effect at all: For example, I'd like TextMate to use the RSpec grammar for all *.rb having a first line matching '.*spec_helper.*', but it seems to always use the Rails grammar instead (even for newly created files). I suspect TextMate remembers some kind of manual override – if so, how can I reset this override? Is there any way to see (debug) how TextMate choses the grammar?
On 23 Oct 2014, at 11:42, Stefan Daschek wrote:
When and how is the “First Line Match” setting of language grammars considered?
It is used after checking for explicit bindings (from tm properties). The explicit bindings are recorded in the Global.tmProperties when the user change language for an open file.
In my experiments it doesn't seem to have any effect at all: For example, I'd like TextMate to use the RSpec grammar for all *.rb having a first line matching '.*spec_helper.*', but it seems to always use the Rails grammar instead (even for newly created files). I suspect TextMate remembers some kind of manual override – if so, how can I reset this override? Is there any way to see (debug) how TextMate choses the grammar?
With a *.rb file open you should be able to use ⌃⌘T, switch to settings, and then enter ‘filetype’ to find your explicit binding for *.rb → Rails in Global.tmProperties (although clicking Edit doesn’t take you to the proper line yet).
Making it work for RSpec files, assuming these still follow the file_spec.rb naming convention, you would need to change the setting to:
[ *.rb~*_spec.rb ] fileType = source.ruby.rails
Am 24.10.14 um 09:24 schrieb Allan Odgaard:
On 23 Oct 2014, at 11:42, Stefan Daschek wrote:
When and how is the “First Line Match” setting of language grammars considered?
It is used after checking for explicit bindings (from tm properties). The explicit bindings are recorded in the Global.tmProperties when the user change language for an open file.
Makes sense! So the precendence is like this?
1. Use explicit binding from Global.tmProperties. 2. If none found, use first line match. 3. If none found, use file types (extension).
If more than one bundle claims a file type by extension, is it “longest match wins“? (The RSpec bundle uses `_spec.rb` which seems to take precedence over Ruby's `rb` even for empty files.) And what happens if two bundles claim the exact same extension? (Both Ruby and Rails claim `rb`, and apparently the Ruby bundle “wins”.)
With a *.rb file open you should be able to use ⌃⌘T, switch to settings, and then enter ‘filetype’ to find your explicit binding for *.rb → Rails in Global.tmProperties (although clicking Edit doesn’t take you to the proper line yet).
Great, this has already proven itself very helpful. Thanks!
Making it work for RSpec files, assuming these still follow the file_spec.rb naming convention, you would need to change the setting to:
[ *.rb~*_spec.rb ] fileType = source.ruby.rails
Cool – didn't know that it's possible to combine wildcards like this!
On 25 Oct 2014, at 0:04, Stefan Daschek wrote:
Makes sense! So the precendence is like this?
- Use explicit binding from Global.tmProperties.
- If none found, use first line match.
- If none found, use file types (extension).
Yes.
If more than one bundle claims a file type by extension, is it “longest match wins“? (The RSpec bundle uses `_spec.rb` which seems to take precedence over Ruby's `rb` even for empty files.)
Yes, longest wins.
And what happens if two bundles claim the exact same extension? (Both Ruby and Rails claim `rb`, and apparently the Ruby bundle “wins”.)
This is undefined.
[ *.rb~*_spec.rb ] fileType = source.ruby.rails
Cool – didn't know that it's possible to combine wildcards like this!
This is also useful when doing folder searches, and one can add multiple exclusions.
Am 29.10.14 um 15:06 schrieb Allan Odgaard:
On 25 Oct 2014, at 0:04, Stefan Daschek wrote:
“longest match wins“? (The RSpec bundle uses `_spec.rb` which seems to take precedence over Ruby's `rb` even for empty files.)
Yes, longest wins.
Cool, that means that we can remove the first line match setting from the RSpec bundle entirely (because `_spec.rb` will catch all RSpec files anyway). Simplify all the things! :-D
And what happens if two bundles claim the exact same extension? (Both Ruby and Rails claim `rb`, and apparently the Ruby bundle “wins”.)
This is undefined.
Hmm … it'd be great if Ruby files in Rails projects (only) could use the Rails grammar. Would it be possible to use a project scope (`attr.project.rails`) for that?
On 29 Oct 2014, at 15:32, Stefan Daschek wrote:
This is undefined.
Hmm … it'd be great if Ruby files in Rails projects (only) could use the Rails grammar. Would it be possible to use a project scope (`attr.project.rails`) for that?
Can we identify Rails projects (for the project scope)?
Am 29.10.14 um 16:10 schrieb Allan Odgaard:
On 29 Oct 2014, at 15:32, Stefan Daschek wrote:
Hmm … it'd be great if Ruby files in Rails projects (only) could use the Rails grammar. Would it be possible to use a project scope (`attr.project.rails`) for that?
Can we identify Rails projects (for the project scope)?
Maybe by checking if there's a toplevel `Gemfile` with a line matching `gem\s+'rails'`?
Most newer Rails projects use binstubs, so checking for the existence of `bin/rails` would also be possible. (But there are still many Rails projects without binstubs.)
Is it possible to specify the project scope in a (local) .tm_properties file?
On 29 Oct 2014, at 17:03, Stefan Daschek wrote:
Can we identify Rails projects (for the project scope)?
Maybe by checking if there's a toplevel `Gemfile` with a line matching `gem\s+'rails'`?
Most newer Rails projects use binstubs, so checking for the existence of `bin/rails` would also be possible. (But there are still many Rails projects without binstubs.)
The current system (to identify projects) looks for a file (glob) in a file’s current or ancestor directory. It can’t check the content of other files or similar.
Is it possible to specify the project scope in a (local) .tm_properties file?
Yes, that is done simply by using scopeAttributes — but if you have a local .tm_properties you might as well just set the .rb → Rails directly in there.
On Wed, Oct 29, 2014 at 5:56 PM, Allan Odgaard mailinglist@textmate.org wrote:
On 29 Oct 2014, at 17:03, Stefan Daschek wrote:
Can we identify Rails projects (for the project scope)?
Maybe by checking if there's a toplevel `Gemfile` with a line matching `gem\s+'rails'`?
Most newer Rails projects use binstubs, so checking for the existence of `bin/rails` would also be possible. (But there are still many Rails projects without binstubs.)
The current system (to identify projects) looks for a file (glob) in a file’s current or ancestor directory. It can’t check the content of other files or similar.
The RSpec bundle decides if the current project is a Rails project by looking for a ./config/boot.rb file.
-- :: dip --
Am 29.10.14 um 15:06 schrieb Allan Odgaard:
And what happens if two bundles claim the exact same extension? (Both Ruby and Rails claim `rb`, and apparently the Ruby bundle “wins”.)
This is undefined.
So does it make any sense for the Rails bundle to claim the `rb` extension? Should I prepare a PR removing it?
On 3 Nov 2014, at 23:25, Stefan Daschek wrote:
So does it make any sense for the Rails bundle to claim the `rb` extension? Should I prepare a PR removing it?
I would have said yes (remove it), but thinking some more about this, I think TextMate should be changed to perfer the default bundle over non-default bundles, incase of a conflict.
That way, we can keep this information (in the bundle), and TextMate will be able to use it in various places, for example even with the Ruby bundle installed by default, it might still make sense to inform the user that “this file type can also be handled as Ruby on Rails” (e.g. when right-clicking the file or similar).
-
Allan Odgaard -
dipnlik -
Stefan Daschek