Line by line regex matching

The simplest solution is to scan from the current cursor line upwards, testing lines against a regex to see if it's a test definition. This mostly works, though it can run into edge cases. For example, with Jest, test names are strings and may concatenated over multiple lines, which then requires more complex logic. Also, JUnit methods are marked as tests with the @Test annotation on the previous line. I don't remember exactly, but cases like these are likely why I switched to a more robust approach, rather than walking line by line in a Vim script.

Zippers

Currently, I try to avoid non-trivial logic in editor scripts and instead invoke a shell script. To find the test name for the current file and line, I parse the file with the tree-sitter CLI and produce an XML representation of a code's concrete syntax tree. That's provides all the information I need, but getting the name in a deeply nested tree structure can be tricky. By habit I used clojure.zip to navigate the tree and find the pieces I needed. The code ended up looking something like this (clojure.zip aliased to z, and a personal library of zipper utilities aliased to zip):

(let [loc (z/xml-zip tree)
      package (-> loc
                  (zip/go z/next (comp #{:package_declaration} :tag))
                  (zip/go z/next (comp #{:scoped_identifier} :tag))
                  z/node
                  :content
                  first)
      [class-name] (-> loc
                       (zip/go z/next (comp #{:class_declaration} :tag))
                       z/node
                       :content
                       (->> (filter (every-pred (comp #{:identifier} :tag)
                                                (comp #{"name"} :field :attrs))))
                       first
                       :content)
      test-name (when (and line (< 1 line))
                  (-> loc
                      (zip/iterate z/next)
                      (->> (filter (comp (partial includes-line line) z/node)))
                      last
                      (zip/go z/up (comp #{:method_declaration} :tag))
                      z/node
                      :content
                      (nth 2)
                      :content
                      first))])

That's a lot of code for a simple task, and it mostly worked, but every now and then would I run into a scenario that didn't quite work and have to fiddle with it. For as fond as I am of zippers, complex traversals begin to feel like imperative programming. Possibly I needed some more helper functions.

Meander

Instead of building out more zipper helpers, I tried Meander. Here are some matchers against an XML tree, which looks for a test class and method, or just a class, or just a function:

(m/search
  (m/$ {:tag :class_definition
        :attrs {:srow (m/pred #(<= (parse-long %) line))}
        :content (_ {:tag :identifier
                     :content ((m/and (m/pred test-class-name?) ?class))}
                    & (m/$ {:tag :function_definition
                            :attrs {:srow (m/app parse-long
                                                 (m/and (m/pred #(<= % line))
                                                        ?row))}
                            :content (m/scan {:tag :identifier
                                              :content ((m/and (m/pred test-function-name?)
                                                               ?fn))})}))})
  , {:row ?row :class ?class :function ?fn}
  (m/$ {:tag :class_definition
        :attrs {:srow (m/app parse-long
                             (m/and (m/pred #(<= % line))
                                    ?row))}
        :content (_ {:tag :identifier
                     :content ((m/and (m/pred test-class-name?)
                                      ?class))}
                    & _)})
  , {:row ?row :class ?class}
  (m/$ {:tag :function_definition
        :attrs {:srow (m/app parse-long (m/and (m/pred #(<= % line))
                                               ?row))}
        :content (_ {:tag :identifier
                     :content ((m/and (m/pred test-function-name?)
                                      ?fn))}
                    & _)})
  , {:row ?row :function ?fn})

:row is used to sort the results and find the match closest to a given line.

Meander's syntax can be tricky to get right, and I'm still wrapping my head around the order of expressions in (m/app f (m/and (m/pred g) ?x)), but in general I'm pleased with how declarative this version is. I don't have to manage traversing a tree, and the code looks a lot like the tree itself, making it easy to handle new scenarios.

At the moment, new cases are handled with new Meander patterns. If you have suggestions for alterative approaches, feel free to email me.

While building it, I added support for pushing and popping states with the [ and ] operators, which turned out to be relatively straight-forward. The conversion of commands such as [:turn 90] into a set of points looks like this:

(defmulti update-state (fn [_ [cmd]] cmd))

(defmethod update-state nil [state _]
  state)

(defmethod update-state :forward [state [_ param]]
  (let [{[x y] :point :keys [heading points]} state
        radians (* heading Math/PI (/ 180))
        x (+ x (* param (Math/sin radians)))
        y (+ y (* param (Math/cos radians)))]
    (assoc state :point [x y] :points (conj points [x y]))))

(defmethod update-state :turn [state [_ param]]
  (assoc state :heading (- (state :heading) param)))

(defmethod update-state :push-state [state _]
  (update state :states conj {:point (state :point) :heading (state :heading)}))

(defmethod update-state :pop-state [state _]
  (let [{:keys [point heading]} (-> state :states peek)]
    (-> state
        (assoc :point point :heading heading)
        (update :points conj :move point)
        (update :states pop))))

(defn coords [cmds]
  (:points
    (reduce update-state
            {:point [0 0]
             :heading 180
             :points [[0 0]]
             :states []}
            cmds)))

Note that when popping the state the list of points gets the non-coordinate value :move, which is recognized by the drawing code and tells it not to draw a line segment from the previous point to the new point.

I also improved the generation of random L-systems. I've noted some symmetries in the rules of systems that produce pleasing outputs, but in the playground I created symmetries by transforming a randomly generated base rule, then selectively reversing it, inverting it, and concatenating with the original rule to create new, related rules. It will also occasionally insert [ and ] commands, though not always in a meaningful way (e.g., [+]). The current system seems to have the best success rate of any of my previous attempts, more frequently generating non-trivial and visually distinctive patterns.

If you have suggestions for further improvements, please let me know.

Claude reproduced several known L-systems, spitting out a Koch snowflake, two Sierpiński triangles, and a dragon curve with 88-degree turns instead of 90-degree turns. It included several definitions that popped and pushed state, but I haven't added support for that to my L-system code, so I didn't draw any of those. The only remaining system was this wandering line:

ChatGPT produced some wandering lines like the one above, a sloped line made of squares, and this looping design:

It did, however, produce one interesting one, which it called a "hexagonal weave":

(def hex-weave
  '{:axiom [A]
    :rules {A [F + B - F - B + F]
            B [F - A + F + A - F]}
    :moves {+ [:turn 60]
            - [:turn -60]
            F [:forward 1]}})

I don't know if it derived the definition from some known system. If it looks familiar to you, let me know.

My prompt for ChatGPT and Claude was quite rudimentary, so if you have recommendations for how I might elicit more interesting designs, please email me.