This is all in the documentation, although maybe not in so many words. See
the last paragraph of "2.11 The Context and Multipass Opcodes".
As far as I remember Christian just quoted me from an email in which I was
actually asking about the inner workings myself, long time ago (I looked it
up, 2010). What I wrote then was just what I was guessing based on
experimentation, John said it was correct and Christian just copied it to
the documentation. After reading it again, I don't think it's 100% accurate
though.
I get what you are trying to say with your example. I'm not sure what the
reason is for not advancing the cursor in the second case. I guess it's in
order to be able to more in a single pass. It's indeed not super-intuitive.
The important question is: are there cases in which we want to advance to
the end of the entire match, not just to the end of the square brackets?
The answer is yes: see for example the "pass2 []%englishLetter. @56" case.
So the next question is: are there any cases where this can't be be solved
with the asterisk? That is, instead use "pass2 %englishLetter. @56*", or
more general, convert "pass2 []<x> <y>" to "pass2 <x> <y>*".
If there are no such cases, I wouldn't touch the algorithm. If there are
such cases, we should try to find a solution.
2017-01-06 12:35 GMT+01:00 Michael Whapples <dmarc-noreply@xxxxxxxxxxxxx>:
Thank you that has actually made it very clear on why some rules with []
work when others get into the loop.
It seemed a bit odd that something before [] would advance the cursor when
something after does not. Take two rules like:
pass2 @1[] @1
pass2 []@1 @1
Why should the first rule advance the cursor when the second does not.
I understand from you explaining how the internals work, but without that
internal workings knowledge it does not seem logical or intuitive that
before and after are handled differently.
May be this also could be a documentation improvement, add something which
states that the cursor will be moved to the position just after the
replacement brackets when a rule is applied.
Another small note, it might be worth being extremely precise in
terminology here. The term "replacement" might mean the brackets [] or it
may mean what you are replacing it with. So may be for the brackets []
refer to them as the "replacement brackets" or the "replacement group".
Michael Whapples
On 06/01/2017 09:33, Bert Frees wrote:
Yes, it is like other translation rules. However, with both multipass and
other translation rules, it is not the first match that is used, but rather
the best match. Only one matching rule is used, the rest is ignored.
Processing resumes at the first character after the replacement. This means
that if the replacement starts at offset 0 and has length 0, the processing
resumes at the same place which results in an endless loop.
2017-01-06 8:09 GMT+01:00 Dave Mielke <dave@xxxxxxxxx>:
I'm having trouble understanding when a multipass opcode (e.g. pass2)
moves on
to the next character. It doesn't seem to be like translation rules where
the
first one that matches is used, the rest are skipped, and processing
resumes at
the next character after the replacement.
Are they all always processed, or is the first one that matches the only
one
that's processed?
Where does processing resume after a match?
--
Dave Mielke | 2213 Fox Crescent | The Bible is the very Word of
God.
Phone: 1-613-726-0014 | Ottawa, Ontario | http://Mielke.cc/bible/
EMail: Dave@xxxxxxxxx | Canada K2A 1H7 | http://FamilyRadio.org/
For a description of the software, to download it and links to
project pages go to http://liblouis.org
