LISTEN doesn't work the same

[brazilofmux]

Original issue 555 created by brazilofmux on 2009-01-13T21:07:56.000Z:

What version of the server are you using? On what operating system? What is the configuration or initial setup is required? MUX 2.7.4.25 # 1 [2008-OCT-11] Build date: Tue Oct 21 19:17:31 EDT 2008

What steps will reproduce the problem?

1. Logon to # 1
2. @create LISTENOBJ
3. @VA LISTENOBJ=^* says, "Bettle *":@pemit %#=Yes.
4. @set LISTENOBJ=MONITOR PUPPET TRACE VERBOSE
5. drop LISTENOBJ
6. say Bettle Bee.

What is the expected output? Yes.

What output do you see instead? Nothing. No trace, no verbose, no puppet response.

Please provide any additional information below. At least one other had this problem, don't know her version.

A 2.4 version didn't have this problem.

[brazilofmux]

Comment #1 originally posted by brazilofmux on 2009-01-13T21:10:51.000Z:

We may as well have an issue about it, but this was described in May 2008 with the following post to the TinyMUX list (See http://groups.google.com/group/tinymux/browse_thread/thread/ac0af1fceb01f0b7/63d6302a06456560?lnk=gst&q=listen# 63d6302a06456560):

say Testing.

Brazil says, “Testing.”

TinyMUX 2.7 generates the left and right double quote pair. Unicode clients see them, and for non-Unicode clients, they are down converted into vertical double quotes. This is potentially a breaking change for softcode because while clients see the original ASCII double quote, softcode sees the left and right double quote pair.

Instead of @listen Listener=* says, "*", you need the following:

@wait 0=@listen Listener=* says, [chr(8220)]*[chr(8221)]

This is similar to changing "says" to "says," but it is potentially more frustrating because if you are using a non-Unicode client, you may not see fancy quote marks.

I'm trying to think of a good workaround. Perhaps any use of double quote in a ^-listen or $-command can be made to match any style of double quote (there are at least five and possibly twelve).

Another option is to make the ASCII flag work for objects, but that would mean any text sent through that object would be stripped. I don't want to do that.

To a degree, we have'ta solve the ^-listen $-command problem anyway because clients and paritcularly IMEs on top of clients will generate these characters. The server is already matching U+201C to the say command because an IME for a foreign language won't generate a ASCII double-quote.

Brazil

[brazilofmux]

Comment #2 originally posted by brazilofmux on 2009-01-18T17:54:10.000Z:

When this is fixed, it should be back-ported to 2.7.

[brazilofmux]

Comment #3 originally posted by brazilofmux on 2009-11-24T14:10:22.000Z:

If we want to support patterns which will match folded punctuation at the same time support patterns which allow specific matching against unfolded punctuation, it could be supported by first testing whether the pattern contains any unfolded punctuation. If so, match against the unfolded text. On the other hand, if the pattern contains only 'normal' punctuation, match against the folded text.

If we don't want to support that, then both pattern and text need to be folded before matching is done.

[brazilofmux]

Comment #4 originally posted by brazilofmux on 2009-11-26T17:22:25.000Z:

<empty>

[brazilofmux]

Comment #5 originally posted by brazilofmux on 2011-06-10T23:34:30.000Z:

A potentially good way of solving this issue is to introduce a configurable equivalence class over the set of characters with defaults such that quotation characters are considered equivalent. (This would be especially nice if we provided it with equivalence class profiles which favor a high degree of flexibility, e.g. accent A's and A's are considered equivalent, and low flexibility, e.g. every character is equivalent to only itself, depending on the needs of the MUX.)

The conceptual equivalence class would only be used for matching characters -- be it delimiters, PCRE, and on. Handling the characters otherwise would deal with the actual characters themselves. That way UTF8-naive code can retain UTF-8 characters, although I admit perhaps haphazardly. However, in the common cases I can think of, the results would be favorable. Anything that uses ord() and chr() specially might run into trouble, though.

[kveroneau]

I have been experiencing this issue while going through the Amberyl's MUSH Manual and was getting rather frustrated and gave up on trying to build my own world in a MUSH using TinyMUX. This bug/issue I would imagine is used by a lot of softcode, as listening for what a character says in a room seems really natural for say talking to NPCs, and controlling other objects via speech. I am using the following build, and still experiencing this problem:

MUX 2.10.1.14 #1 [2017-AUG-05]
Build date: Sun Aug 23 16:01:58 UTC 2020

For my client, I am using KildClient 3.2.0. After realizing what the issue was, I tried to change the character set used by my client to ANSI_X3.4-1968, which is an alias for the standard ASCII character set. This did not work unfortunately.

[brazilofmux]

I'll copy/paste the discussion from the Google Groups link above.

say Testing. Brazil says, “Testing.”

TinyMUX 2.7 generates the left and right double quote pair. Unicode clients see them, and for non-Unicode clients, they are down converted into vertical double quotes. This is potentially a breaking change for softcode because while clients see the original ASCII double quote, softcode sees the left and right double quote pair.

Instead of @listen Listener= says, "", you need the following:

@wait 0=@listen Listener= says, [chr(8220)][chr(8221)]

This is similar to changing "says" to "says," but it is potentially more frustrating because if you are using a non-Unicode client, you may not see fancy quote marks.

I'm trying to think of a good workaround. Perhaps any use of double quote in a ^-listen or $-command can be made to match any style of double quote (there are at least five and possibly twelve).

Another option is to make the ASCII flag work for objects, but that would mean any text sent through that object would be stripped. I don't want to do that.

To a degree, we have'ta solve the ^-listen $-command problem anyway because clients and paritcularly IMEs on top of clients will generate these characters. The server is already matching U+201C to the say command because an IME for a foreign language won't generate a ASCII double-quote.

Brazil