`greedy-find` not setting `:checkpoint` about automat HOT 2 CLOSED

The checkpoint is mostly for internal use, but maybe this example will be a bit more illuminating:

user> (def foo (a/compile 
          (a/or [:d :d]
                [:d :d :g :h])))
#'user/foo
user>  (a/greedy-find foo nil [:d :d :g])
#automat.compiler.core.CompiledAutomatonState{:accepted? false, :checkpoint #automat.compiler.core.CompiledAutomatonState{:accepted? true, :checkpoint nil, :state-index 2, :start-index 0, :stream-index 2, :value nil}, :state-index 3, :start-index 0, :stream-index 3, :value nil}
user>  (a/greedy-find foo *1 [:z])
#automat.compiler.core.CompiledAutomatonState{:accepted? true, :checkpoint nil, :state-index 2, :start-index 0, :stream-index 2, :value nil}

All of your examples were accepted states, so they don't need to have a reference back to the previous accepted state. In this example, we're halfway between one accepted state and maybe a greedier one. Once we get something other than :h in the last input, it simply returns the checkpointed state.

The documentation could certainly be clearly here, but does that make sense?

from automat.

Aha, yes, thanks for the reply! I think that's clear, so basically my misunderstandings were:

• the checkpoint is not created for accepted? states
• if created, the checkpoint would contain another state value

In any case, as it turns out those semantics aren't useful to my use-case*, I suspect I need to roll something up with direct use of (a/advance) instead, so I'll play with that :-)

(* for example, I was musing on a key-binding parser. If the user types "dd", should we process the :first action, or wait a little longer to see if they go on to type a "g"?)

from automat.