Make Settings class more flexible, less brittle

I hadn't touched this class for about 4 years, and this morning had to
add another setting to it in order to fix a bug (see commit
2861dc1a7e52). With a more flexible design, I could have left it
untouched.

This commit implements that design, teaching the settings class to
fully mediate between the caller who wants to save/restore some
settings, and Vim. It records the settings that are to be changed, makes
the changes, and can restore the settings by "replaying" the recorded
settings.

Signed-off-by: Wincent Colaiuta <win@wincent.com>
Apply ghastly hack to fix failing spec

This is evidently breaking all the rules about encapsulation and not
testing implementation details, but it's the quickest way to get this
failing test passing again.

(And note, it is not strictly worse than what was there before either,
because the reason the test was broken was precisely because it was
wedded to implementation details; it turns out that this spec is an
assertion about implementation details...)

Signed-off-by: Wincent Colaiuta <win@wincent.com>
Move RubyFileScanner specs into subdirectory

We had 4 remaining spec failures in this file; this commit tries to
stick as close to being a straight move as possible to make it clear
what's happening, but just moving the code makes the specs pass.

The issue is that we recently factored some of the functionality of the
FileScanner class into a RubyFileScanner subclass, so the specs for the
FileScanner were seeking to verify behavior which was no longer present
in the class.

In this commit we split the specs out just as we split the FileScanner
and RubyFileScanner functionality out. It moves the code into another
file and changes the references to the FileScanner class to
RubyFileScanner.

Signed-off-by: Wincent Colaiuta <win@wincent.com>
Fix controller spec failures

With "judicious" stubbing. The amount of stubbing in this spec is an
immense smell, but pursuing the quick fix in the name of getting the
suite green again rather than engaging in a deeper reworking for now.

Signed-off-by: Wincent Colaiuta <win@wincent.com>
Further abstract local vs global distinction inside Settings class

Commit 514194c made the Settings class a little smarter. We can make the
MatchWindow class (the sole client of the Settings class) simpler by
burying the details about the distinction between local and global
settings inside of the Settings class.

Specifically, the Settings class knows which settings are global and
which are local, so the calling MatchWindow class just tells it to apply
settings and lets the Settings class worry about exactly how that should
happen.

This is a net increase in the number of lines, but worth it because the
Settings class will be infrequently touched, and the more
actively-modified MatchWindow class is simpler for it.

Signed-off-by: Wincent Colaiuta <win@wincent.com>
Add a tiny "DSL" to reduce settings verbosity in MatchWindow class

This reduces some of the noise in this file, at the minor cost of adding
a non-obfuscating level of indirection.

Signed-off-by: Wincent Colaiuta <win@wincent.com>
Convert a couple more settings manipulations in the MatchWindow class

I originally didn't include these in the recent refactorings of the
Settings class as they have a somewhat different lifecycle than the
other settings changes made by the MatchWindow class (ie. most of the
changes are made as a batch on initial display and restored at the end,
but the `#lock` and `#unlock` calls can be made at distinct moments as
the result of other methods being called).

Nevertheless, they are `:setlocal` calls, so routing them through the
Settings class is not going to disturb its internal state anyway. In the
interests of reducing noise in the MatchWindow class and getting maximum
re-use out of the Settings abstraction, this commit swaps them over to
use the "DSL".

Signed-off-by: Wincent Colaiuta <win@wincent.com>
Improve pthread detection

My initial attempts at this weren't ideal, as some people are having
trouble building Command-T, especially those with older versions of
Ruby:

  https://wincent.com/issues/2135
  https://wincent.com/issues/2153
  https://github.com/wincent/Command-T/issues/65

I'd forgotten about the `have_library` method in the `MakeMakefile`
module, which not only checks for the presence of the library, but also
modifies the list of libraries to be linked:

  http://ruby-doc.org/stdlib-2.1.0/libdoc/mkmf/rdoc/MakeMakefile.html#method-i-have_library

Note that I guard all of this inside a `THREAD_MODEL` check. I believe
this should prevent us from linking to pthread when the local Ruby has
explicitly opted out of using pthread (common in older Ruby versions due
to performance overhead).

I tested this against a few versions of Ruby on my OS X box:

  1.8.7-p249
  1.9.1-p430
  1.9.2-p326
  1.9.3-p545
  2.0.0-p451
  2.1.0
  2.1.1

With the command:

  ruby -r rbconfig -e 'puts RbConfig::CONFIG["THREAD_MODEL"]'

This prints "pthread" on 1.9.1 and up, and on 1.8.7 it prints "nil". On
2.0.0 and up `RbConfig` is always visible, so this works even without
the `require`.

Hopefully this will work pretty much everywhere. Fingers crossed.

Signed-off-by: Wincent Colaiuta <win@wincent.com>

diff --git a/ruby/command-t/extconf.rb b/ruby/command-t/extconf.rb
index eedeae0..44cfacc 100644
--- a/ruby/command-t/extconf.rb
+++ b/ruby/command-t/extconf.rb
@@ -1,4 +1,4 @@
-# Copyright 2010-2013 Wincent Colaiuta. All rights reserved.
+# Copyright 2010-2014 Wincent Colaiuta. All rights reserved.
 #
 # Redistribution and use in source and binary forms, with or without
 # modification, are permitted provided that the following conditions are met:
@@ -36,8 +36,10 @@ def header(item)
 header('stdlib.h')
 header('string.h')

-# optional headers
-have_header('pthread.h') # sets HAVE_PTHREAD_H if found
+# optional
+if RbConfig::CONFIG['THREAD_MODEL'] == 'pthread'
+  have_library('pthread', 'pthread_create') # sets HAVE_PTHREAD_H if found
+end

 RbConfig::MAKEFILE_CONFIG['CC'] = ENV['CC'] if ENV['CC']