Imperfect polymode testing

Unfortunately, no good way to test font-lock as font-lock-mode won't
activate under noninteractive ecukes (can try --no-win or --win, but
won't fly under travis)

In practice, polymode font-lock bugs often manifest themselves much as
issue #456 did.  The rear-nonsticky property on the input prompt gets
washed away by font-lock and brokenness ensues.

features/polymode.feature

@@ -12,3 +12,27 @@ Scenario: selection spans cells
   Then newlined region should be "In [ ]:\n\n\nIn [ ]:\n"
   And I press "C-g"
   Then the region should not be active
+
+@poly
+Scenario: markdown often erroneously fontifies the whole buffer
+  Given new python notebook
+  And I press "C-c C-t"
+  And I type "# Header"
+  And I press "RET"
+  And I press "C-p"
+  And I press "C-p"
+  And I press "C-e"
+  Then text property at point includes "rear-nonsticky"
+
+@poly
+Scenario: moving cells requires refontification
+  Given new python notebook
+  And I press "C-c C-t"
+  And I type "# Header"
+  And I press "RET"
+  And I press "C-c C-b"
+  And I type "import math"
+  And I press "C-c C-c"
+  And I press "M-<up>"
+  And I press "C-<down>"
+  And I go to word "Header"

features/step-definitions/ein-steps.el

@@ -476,3 +476,10 @@
 (When "I evaluate the python code \"\\(.+\\)\"$"
       (lambda (code-str)
         (ein:shared-output-eval-string nil code-str nil)))
+
+(When "^text property at point includes \"\\(.+\\)\"$"
+      (lambda (properties)
+        (should-not
+         (mapcan (lambda (prop)
+                   (not (get-text-property (point) (intern prop))))
+                 (split-string properties ",")))))