Newbie.. sort of

Ahmet

Tael said:

Yae said:

My script is really basic, and I keep breaking the code box.  

Alias
Pattern: ^em +(.+)$
There's no reason to have the em in a group. The only reason to use a non-capturing group like that is if you want to quantify something with ?/*/+. And putting a + after the space like this means that if you accidentally type more than one space after the em, it won't end up as part of the emote.

Script:

if emoty == matches[2] then
    send("emote " .. emoty)
else
    send("showemote emote " .. matches[2])
    emoty = matches[2]
end

Simplified a little bit and formatted in a code block. You don't need to test for nil because emoty already won't equal matches[2] if emoty is nil. I took out the part where it sets emoty to nil right before the else in case you need to repeat an emote for some reason, but if you don't want that, you can just throw "emoty = nil" in right before the else.

I didn't read your second wall of text but you can use ?, * and + operators outside of capture groups. You use non-capture groups for delimiters (usually denoted by the pipe symbol, | ).

EDIT: Though I suppose if you're using the ?/*/+ on the whole capture group as opposed to single chars that makes sense.

Trevize

Ahmet said:

Tael said:

Yae said:

My script is really basic, and I keep breaking the code box.  

Alias
Pattern: ^em +(.+)$
There's no reason to have the em in a group. The only reason to use a non-capturing group like that is if you want to quantify something with ?/*/+. And putting a + after the space like this means that if you accidentally type more than one space after the em, it won't end up as part of the emote.

Script:

if emoty == matches[2] then
    send("emote " .. emoty)
else
    send("showemote emote " .. matches[2])
    emoty = matches[2]
end

Simplified a little bit and formatted in a code block. You don't need to test for nil because emoty already won't equal matches[2] if emoty is nil. I took out the part where it sets emoty to nil right before the else in case you need to repeat an emote for some reason, but if you don't want that, you can just throw "emoty = nil" in right before the else.

I didn't read your second wall of text but you can use ?, * and + operators outside of capture groups. You use non-capture groups for delimiters (usually denoted by the pipe symbol, | ).

EDIT: Though I suppose if you're using the ?/*/+ on the whole capture group as opposed to single chars that makes sense.

+ ? and * are what's called quantifiers - and they're actually shortcuts, at that. A quantifier says how many of the previous item (character, character set, group) should be matched. ? is {0,1}, + is {1,} , * is {0,}. A full quantifier consists of curly braces around two numbers, separated by a comma. The first is the minimum, the second is the maximum. The second number can be left blank to mean 'as many as can be found.' A single number can also be included to say 'exactly that many'.

For example, a{9} would match 'aaaaaaaaa' and that only. \d{2,3} would match 2 or 3 numbers, no more or less. \w{5,} would match words (letters, numbers or underscores) consisting of five or more characters.

Another fun fact is that \d and \w are also shortcuts, as is a period. They're all character classes. \d is the same as [0-9]. \w is [A-Za-z0-9_]. A period is basically [^] (by default a period does not match a newline). Lesser used here, but \D matches anything not a number, so basically [^0-9], same with \W and 'words'.

Another sometimes useful note is quantifiers are naturally greedy. a ? after a quantifier, rather than a character, turns the quantifier non-greedy. So assume you're matching this:

12345

the pattern: (\d+)(\d+)
would return matches[2] as 1234 and matches[3] as 5

But if you did, instead: (\d+?)(\d+)
it would return matches[2] as 1 and matches[3] as 2345

edit: For anyone still curious after that wall of text, you can also turn a quantifier possessive using + after it (I'm actually not sure if this works in mudlet, come to think of it it, I've never tried it - but generally speaking, it's not useful in matching lines from a MUD). What that means is a little odd - the regex engine backtracks in case something doesn't match the maximum possible. A possessive quantifier doesn't give up matches as the engine does that (where greedy and non-greedy - or lazy - do). Long story short, it speeds up the regex but prevents matches in certain cases, which for our uses, is bad.

Trevize

Also, to extend an offer, if anyone needs any help understanding anything about regex (pattern matching), give me a shout through PMs. I'd be glad to help! Regex is EXTREMELY powerful, and can match just about anything you'd like.

Tael

Ahmet said:

Tael said:

Yae said:

My script is really basic, and I keep breaking the code box.  

Alias
Pattern: ^em +(.+)$
There's no reason to have the em in a group. The only reason to use a non-capturing group like that is if you want to quantify something with ?/*/+. And putting a + after the space like this means that if you accidentally type more than one space after the em, it won't end up as part of the emote.

Script:

if emoty == matches[2] then
    send("emote " .. emoty)
else
    send("showemote emote " .. matches[2])
    emoty = matches[2]
end

Simplified a little bit and formatted in a code block. You don't need to test for nil because emoty already won't equal matches[2] if emoty is nil. I took out the part where it sets emoty to nil right before the else in case you need to repeat an emote for some reason, but if you don't want that, you can just throw "emoty = nil" in right before the else.

I didn't read your second wall of text but you can use ?, * and + operators outside of capture groups. You use non-capture groups for delimiters (usually denoted by the pipe symbol, | ).

EDIT: Though I suppose if you're using the ?/*/+ on the whole capture group as opposed to single chars that makes sense.

Yes, I was refering to the stuff in your EDIT, though I suppose they're handy for disjunctions too, yeah.

Ahmet

Trevize said:

Also, to extend an offer, if anyone needs any help understanding anything about regex (pattern matching), give me a shout through PMs. I'd be glad to help! Regex is EXTREMELY powerful, and can match just about anything you'd like.

When you start finding it easier (in web development terms) to steal info from a cURL via regex than using the established API, you know something has gone terribly horribly right.

Magierrah

"The key to learning this stuff is to just sit down and try to understand it. It's all very straightforward if you just take a second and try to break it down and plenty of people are willing to help explain it.

The biggest problem most people have is that they look at things like this, don't immediately understand it, and throw their hands in the air." .......................................................................................... I copied all of your messages in this thread. I'm determined to figure it out, so although the temptation to throw my hands in the air is mighty.... I WILL try and learn it. Tahquil has offered to let me practice the next time we are in the game together. What a sweetie. People here have been so kind and patient.

Magierrah

And I fumbled the quote option. Oh my stars.. sorry Tael. Thank you so much for taking the time to teach me my first programming lesson.

Antonius

Don't worry about quoting on the forums. It's awful and rarely works properly.