Matches are found in this way. The first two characters at the cursor location
are used to make a hash into the rules
table. The longest rule at this location is compared to the input. If it
matches, the opcodde is used to se if the rule
is legal at this position. If so, ikt is accepted. If not, the next longest
rule string is tried. If no rule matches,
the single character at the cursor location is processed. In all cases, the
cursor is moved forward to the next
unmatched character. I'm pretty sure I remem ber that I set it up this way.
I submitted a fix some years ago that could use more than two characters to
make the hash function.
Sorry I'm not mucyh help now. I don't want to make any commitments or promises.
John
On Fri, Jan 06, 2017 at 05:27:32PM +0100, Bert Frees wrote:
I'm not sure how matches are sorted TBH. We have to look at the code for
that.
John, do you remember?
Could it be that you have not defined a character with 123 as the dots part?
2017-01-06 17:21 GMT+01:00 Dave Mielke <dave@xxxxxxxxx>:
[quoted lines by Bert Frees on 2017/01/06 at 10:33 +0100]
Yes, it is like other translation rules. However, with both multipass andrather
other translation rules, it is not the first match that is used, but
the best match.
Is it possible that best doesn't mean longest? I have a series of matches
for
specific dots, and then a $a rule to catch the rest. It seems that the $a
rule
is being used even though it's last. How can I write a rule to catch the
rest
which has a lower precedence?
Another issue is that lou_translate is giving me dot numbers (e.g. \123/),
rather than characters, for the [$a] rule. Note that this is for back
translation.
