Last requests before feature freeze

User avatar
Heiko
Site Admin
Posts: 1548
Joined: Wed Mar 11, 2009 6:26 pm

Re: Last requests before feature freeze

Post by Heiko » Mon Jun 22, 2009 9:11 am

Ryan wrote:An option for multiline/AND triggers to require conditions to match on different lines. For instance, if I have a multi-line trigger with A as pattern 1 and B as pattern 2, the option would make it so the trigger won't fire on a single line that contains both A and B.
This feature is already included. Chose the logical and trigger option and set line delta to 0. The trigger will only match if all conditions on the list are true on the same line.
Ryan wrote:An option to choose which capture groups will be passed to a filter's children would be nice, too, but this one hasn't caused as many problems for me so far.
This feature is also included. Substring and begin of line substring patterns always pass the pattern itself as matches[1] as there is no way in the pattern syntax to specify capture groups.
Color triggers always pass all characters that have the specified trigger color as capture groups.

Consequently, you want to use perl regex patterns. If you use a pattern like this:
(?:cobble) (?:stone) (road) you define 3 capture groups, but the ?: at the beginning of capture group #1 and #2 indicates that these capture groups are not supposed to capture anything. As a result capture group #3 i. e. (road) will be passed as the only capture group to the table matches or pass the filter if you use the trigger as a filter.
Ryan wrote:And a way to combine AND and OR conditions in a single trigger would be well-received (at least by me).
This is actually something I'd like to do myself very much, but so far I couldn't find a suitable graphical representation of the problem that would be efficient enough for the user to be useful without being utterly confusing. If you have a good idea of how exactly this should look like, please let me know.
Right now you have to resort to using more complex regex patterns to solve this sort of problem.

Caled
Posts: 399
Joined: Thu Apr 09, 2009 4:45 am

Re: Last requests before feature freeze

Post by Caled » Mon Jun 22, 2009 5:45 pm

(01:12:00) vadi2: and, in the api requests thread, ask for a variable of the location of the profile
(01:12:11) vadi2: I don't remember if I asked that or no, but been meaning to
(01:12:30) vadi2: so you can just use a var to find the .config/mudlet in a cross-platform manner

Ryan
Posts: 10
Joined: Mon Jun 22, 2009 1:15 am

Re: Last requests before feature freeze

Post by Ryan » Mon Jun 22, 2009 7:19 pm

Heiko wrote:This feature is already included. Chose the logical and trigger option and set line delta to 0. The trigger will only match if all conditions on the list are true on the same line.
Then how do I make a multi-line trigger that explicitly _doesn't_ match on the same line? As an example, say I want to colour the line immediately following "Line 1". I can make a multiline trigger that has condition 1 as an exact match for "Line 1", and then I can make condition 2 be a regex "^(.*)$", and I can colour that capture group. But it doesn't work, because condition 2 is always checked against the same line that matches condition 1. The workaround I'm using right now is to have one trigger match "Line 1" and create a temporary line trigger that will enable a second trigger. Then the second trigger will colour, or chain, or whatever--and disable itself every time it fires. (Actually, that's one of about eight different workarounds I've tried, and only one of about three that work and I currently use.)
Heiko wrote:This feature is also included. Substring and begin of line substring patterns always pass the pattern itself as matches[1] as there is no way in the pattern syntax to specify capture groups.
Color triggers always pass all characters that have the specified trigger color as capture groups.

Consequently, you want to use perl regex patterns. If you use a pattern like this:
(?:cobble) (?:stone) (road) you define 3 capture groups, but the ?: at the beginning of capture group #1 and #2 indicates that these capture groups are not supposed to capture anything. As a result capture group #3 i. e. (road) will be passed as the only capture group to the table matches or pass the filter if you use the trigger as a filter.
But what if I need to capture cobble and stone to do something with? Like with the prompt example: the pattern is "^^(\d+)h, (\d+)m, (\d+)e, (\d+)w", to catch health/mana/etc, and that chained to a second trigger: "^\d+h, \d+m, \d+e, \d+w (.*)", which filtered to a bunch of others to catch whether you have balance, etc. The whole thing could be simplified to just one filter if you could specify a way to pass only the fifth capture group (matches[6]) on to the filter's children. This one isn't a big problem for me, because when it comes right down to it, I can use that workaround or just ignore it and let the children fire on all matches (which is usually harmless). But it'd be nice.
Heiko wrote:This is actually something I'd like to do myself very much, but so far I couldn't find a suitable graphical representation of the problem that would be efficient enough for the user to be useful without being utterly confusing. If you have a good idea of how exactly this should look like, please let me know.
Right now you have to resort to using more complex regex patterns to solve this sort of problem.
I was thinking about it, and this is all I've got at the moment. The ugly colours are just to show where the boxes would go, of course. The idea is that each sub-condition is collapsable and name-able. So, for instance, if I click on the yellow OR box, lines 1 and 2 will collapse together. The pattern type dropdown will change to a dropdown where you select between "OR" and "AND" (and possibly other logical operators). And in a clearly different font, the pattern field will say "subcondition 5", or a simple default like that, and you can just type in there to rename that subcondition.

As for how to create the subconditions, maybe put "OR" and "AND" in the pattern type all the time, and if you select them, the line will immediately change to a collapsed subcondition. Then as long as it's smart enough to recognise that (A or (B or C)) can be reduced to (A or B or C), it should work okay.

It's not perfect, but I think it's functional. But maybe it just seems unconfusing to me because I actually drew it. :?

User avatar
Vadi
Posts: 4721
Joined: Sat Mar 14, 2009 3:13 pm

Re: Last requests before feature freeze

Post by Vadi » Mon Jun 22, 2009 10:06 pm

I don't don't see people understanding Polish notation (proper term?) that easily.

My idea would be to express it just like you did in what will happen - an equation. Given each pattern a number, the person can write a simple equation like:

1 and 2

or

(1 and 2) or (3 and 1)

And I think that would make more sense. It would require a separate line entry for this to be showing if the user decides to make a multi-pattern trigger.

User avatar
Heiko
Site Admin
Posts: 1548
Joined: Wed Mar 11, 2009 6:26 pm

Re: Last requests before feature freeze

Post by Heiko » Wed Jun 24, 2009 11:02 pm

Ryan wrote:
Heiko wrote:This feature is already included. Chose the logical and trigger option and set line delta to 0. The trigger will only match if all conditions on the list are true on the same line.
Then how do I make a multi-line trigger that explicitly _doesn't_ match on the same line? As an example, say I want to colour the line immediately following "Line 1". I can make a multiline trigger that has condition 1 as an exact match for "Line 1", and then I can make condition 2 be a regex "^(.*)$", and I can colour that capture group. But it doesn't work, because condition 2 is always checked against the same line that matches condition 1. The workaround I'm using right now is to have one trigger match "Line 1" and create a temporary line trigger that will enable a second trigger. Then the second trigger will colour, or chain, or whatever--and disable itself every time it fires. (Actually, that's one of about eight different workarounds I've tried, and only one of about three that work and I currently use.)
Heiko wrote:This feature is also included. Substring and begin of line substring patterns always pass the pattern itself as matches[1] as there is no way in the pattern syntax to specify capture groups.
Color triggers always pass all characters that have the specified trigger color as capture groups.

Consequently, you want to use perl regex patterns. If you use a pattern like this:
(?:cobble) (?:stone) (road) you define 3 capture groups, but the ?: at the beginning of capture group #1 and #2 indicates that these capture groups are not supposed to capture anything. As a result capture group #3 i. e. (road) will be passed as the only capture group to the table matches or pass the filter if you use the trigger as a filter.
But what if I need to capture cobble and stone to do something with? Like with the prompt example: the pattern is "^^(\d+)h, (\d+)m, (\d+)e, (\d+)w", to catch health/mana/etc, and that chained to a second trigger: "^\d+h, \d+m, \d+e, \d+w (.*)", which filtered to a bunch of others to catch whether you have balance, etc. The whole thing could be simplified to just one filter if you could specify a way to pass only the fifth capture group (matches[6]) on to the filter's children. This one isn't a big problem for me, because when it comes right down to it, I can use that workaround or just ignore it and let the children fire on all matches (which is usually harmless). But it'd be nice.
Heiko wrote:This is actually something I'd like to do myself very much, but so far I couldn't find a suitable graphical representation of the problem that would be efficient enough for the user to be useful without being utterly confusing. If you have a good idea of how exactly this should look like, please let me know.
Right now you have to resort to using more complex regex patterns to solve this sort of problem.
I was thinking about it, and this is all I've got at the moment. The ugly colours are just to show where the boxes would go, of course. The idea is that each sub-condition is collapsable and name-able. So, for instance, if I click on the yellow OR box, lines 1 and 2 will collapse together. The pattern type dropdown will change to a dropdown where you select between "OR" and "AND" (and possibly other logical operators). And in a clearly different font, the pattern field will say "subcondition 5", or a simple default like that, and you can just type in there to rename that subcondition.

As for how to create the subconditions, maybe put "OR" and "AND" in the pattern type all the time, and if you select them, the line will immediately change to a collapsed subcondition. Then as long as it's smart enough to recognise that (A or (B or C)) can be reduced to (A or B or C), it should work okay.

It's not perfect, but I think it's functional. But maybe it just seems unconfusing to me because I actually drew it. :?
This posting and your related posting in another thread are both high quality and got me thinking. I need more time to analyse the problem in greater detail.

Caled has suggested to add a minimum line delta for each condition or all conditions that would act as an additional condition qualifier e.g. condition #1<at least 1 line>condition#2. This can be done easily and it is a powerful feature that makes up for some of the problems discussed in your 2 postings, but it doesn't fully take away the need to add more complex logic to the state machine.

kuei
Posts: 4
Joined: Sat Jun 27, 2009 3:05 am

Re: Last requests before feature freeze

Post by kuei » Sat Jun 27, 2009 3:55 am

A button to sort triggers, alias, scripts, or keys in ascending order.

Caled
Posts: 399
Joined: Thu Apr 09, 2009 4:45 am

Re: Last requests before feature freeze

Post by Caled » Thu Jul 09, 2009 4:36 pm

1. When I highlight some text in the main output screen, it would be nice to be able to use ctrl+c to copy this, rather than being required to right-click and select copy. Not everyone uses a mouse, and touch-pads are slower, making keyboard shortcuts more desirable.

2. Even better would be for all highlighted text to automatically be copied to the clipboard, mimicking zmud behaviour. I understand that this particular one might not be liked by everyone, of course.

3. Would it be possible for double/triple clicking a word in the main output window to select that word, or the entire line if triple clicked?

I find it very cumbersome to highlight text for triggers, particularly in a live session. If a new line arrives from the mud while I am doing it, half the screen gets selected and I have to deselect and try again.

4. Can it be possible to select more than a screen's worth of text from the scroll-back buffer? If while holding down left click and moving the cursor downwards, the cursor reaches the bottom of the viewable scrollback, then the screen should scroll down. Hopefully that makes sense. I was trying to copy a conversation to paste to a forum, and found it impossible to select the whole thing in one hit.

Post Reply

Who is online

Users browsing this forum: No registered users and 3 guests