Ok.. Two things have occured to me that I think are major problems with a look-back method. 1) coloring lines and 2) omitting from output.
Both of these are issues because while you use a buffer to do the look-back, the actual lines in the display are not necessarilly going to correspond to where they are in the output. This requires not only keeping track of where those lines are in the output. Ironically, it causes another odd problem. If a user types a command or a script generates a note when these lines are being displayed, then the trigger will correctly match and theoretically could color the right line, but the command, note or tell could cause a break in that line, which means it would see the right line, start to color it, then incorrectly color everything else posted to that line, though it is not actually part of the line that matched. This gets even more confusing if a) your are using the trigger to 'omit from output' or need to correctly retrieve the style information for the lines matched, since there is no practical way to know which line is really the start and if the line gets broken, the styles retrieved won't match, even though the actual contents for the line returned is correct inside the wildcard. Simply disabling these features for such triggers would more or less solve the problem, but begs the question of how useful they really are when you need to both use the data and color the information.
In the case of the stat roller, where a clever person might use colourtell, colournote and 'omit from output' to not just have the mud reroll things, but show a colorized version of the results of each roll, to get a sense of the trend the rolls are taking. While this specific instance may not quite be that helpful, since it is automated, a mud which will never give optimal results may require a less automated system, but use the same trigger to provide such a visual comparison. Other similar things could be tracked 'in-game' (say space ports stats or the like in a space trading mud) where, as I mentioned, commands or displayed lines could royally muck up the function of such a trigger. Not that they don't unfortunately tend to sometimes do so on a small scale already, but this requires still another level of complexity to partially fix the problem. A complete fix would require some way to mark lines that get broken internally, so that the commands to return styles or other line info can find the part that got chopped off. Of course since triggers also fail to match lines that get broken that way...
Anyway, it is another possible issue to consider.
I am almost tempted to try to write a PCRE parser that does properly manage streamed text. The only real hang up is getting it to split on $ or \n, which is easy and deal properly with stuff like (^...$){1,10}. From a practical standpoint it means pre-parsing the regexp to break it into seperate triggers and adding logic so it knows when each one can be expected to find a match. Not exactly an impossibility, but it would admittedly take a bit of work. In the case of something like:
^You see\:$(.*\n){1,}^$
it would simply need to create internal logic to do:
if Trigger "^You see\:" matched then
call sub, etc.
loop
if match = "$(.*\n)" then
call sub, etc.
until if match = "^$" then
call subs, etc.
If you used {1,10} and added ^Exits\: .*$, then:
if Trigger "^You see\:" matched then
call sub, etc.
loop
if match = "$(.*\n)" then
call sub, etc.
until count = 10 or if match = "^$" then
call subs, etc.
if match = "^Exits\: .*$" then
call sub, etc.
reset trigger to first state.
The only real issue is having the pre-parser figure out how the bits get seperated out. Would probably take me forever to get right though. :( I still think it is a better design and uses PCRE syntax correctly, while your design actually ignores the rules to provide a feature that is in theory already in the syntax. I'm not entirely sure all the extra stuff you are doing, like the look-back buffer isn't actually more complicated that a good pre-parser, for generating a set of rules like above, to guide the trigger behaviour. It may be easier to design, but more efficient or less complicated overall? Hard to say. Sometimes 'easy to design' is a synonim for bad idea. I'm just not a good enough programmer to tell the difference most times. I suspect that is true about most of us.
On a side note: Interesting quirk with the above idea. If the pre-parser actually built vbscript, or javascript, etc. to handle it and used the scripts regexp parsing to handle the matching it would be even easier, no need to design a messy internal method to do the logic, just one to build the script. But that's not likely that practical and you never know what version of PCRE the available script engines will properly support, if actually any. Still, it is kind of an interesting idea. lol Never know where anything with Mushclient will take you. ;) |
![[Previous page]](/images/thin_prev.gif){kind=small}
1
2
3 4
![[Next page]](/images/thin_next.gif){kind=small}
![[Go to top]](/images/gototop.gif){kind=small}
top