This macro used to allow us to use the backslash in text. I would really like to be able to use it again, but it doesn't seem to exist anymore. If it isn't coming back anytime soon, is there a way to represent a backslash in html?
Z
ID:137533
 Oct 17 2001, 5:40 pm
|
|
Tom wrote:
I don't think we changed anything. As far as I can tell, "\\" still works in text output. Can you give me an example? "\\" won't compile. It thinks the second part is a \" macro. Z | |
Zilal wrote:
"\\" won't compile. It thinks the second part is a \" macro. Can you show me the line with the error? I tested the simple case: usr << "Test of \\" And it compiled (and ran) fine. | |
Tom wrote:
Can you show me the line with the error? if (msg == "\\") return usr.buffer[1] ...everything from the first " shows up in blue in the Dream Maker, and... what do you know, it is compiling now. It must have been some other error before that I didn't look very hard at. You know what happens when we assume. Okay, here's the next problem... I want it to be able to recognize two and three backslashes in a row too. Isn't there some proc that will convert macros to regular text? I looked in the reference but couldn't find anything on it. Z | |
Zilal wrote:
Tom wrote: Oops. The editor wasn't displaying it correctly, but the compiler was still working, as you noted. Fixed. Okay, here's the next problem... I want it to be able to recognize two and three backslashes in a row too. Isn't there some proc that will convert macros to regular text? I looked in the reference but couldn't find anything on it. You are probably thinking of html_encode(), which strips out macros. You'll just have to check for the backslashes yourself. Just do "\\ for one backslash, "\\\\" for two, etc. | |
Zilal wrote:
Tom wrote: That's the exact some problem I mentioned when trying to display ANCII images. | |
That's the exact some problem I mentioned when trying to display ANCII images. What'd I tell you about ASCII versus ANCII? =) | |
Tom wrote:
You are probably thinking of html_encode(), which strips out macros. You'll just have to check for the backslashes yourself. Just do "\\ for one backslash, "\\\\" for two, etc. What do you mean? (I'm thinking... I DO check for the backslashes myself.) I want the usr to be able to type \, \\, and \\\, and to be able to check for all of those. But nothing I try works. Now, on to the really weird html_encode() behavior. ZParser(msg) var/msg2 = msg usr << "msg is [msg]." msg = html_encode(msg) usr << "msg is [msg]." if (msg2 != msg) usr << "They don't match." For almost everything I pass into this parser proc (seen here with debugging output), everything works as planned. But text strings starting with a single quote ' get screwy. The text string *looks* exactly the same before and after going through html_encode(), but it trips the check for msg and msg2 being different. AND the rest of the parser fails to recognize that the ' is the first character in the string... even though if you print it out, it sure looks like it is. Fix me, baby! Z | |
Zilal wrote:
text strings starting with a single quote ' get screwy. The text string *looks* exactly the same before and after going through html_encode(), but it trips the check for msg and msg2 being different. AND the rest of the parser fails to recognize that the ' is the first character in the string... even though if you print it out, it sure looks like it is. Fix me, baby! It may be changing ' to ‘ or a similar HTML string. Try sticking <xmp> tags around the weird message when you display it to see how it might be different. | |
Zilal wrote:
What do you mean? (I'm thinking... I DO check for the backslashes myself.) I want the usr to be able to type \, \\, and \\\, and to be able to check for all of those. But nothing I try works. Oh, I see what you are saying now. Your problem is that the command-line parser automatically filters the user input, so that whenever they type a \ it doesn't come through to you literally. Is that right? Yeah, we will have to think about that case a bit. I think ideally you want all of the characters to be present in the string. The " character especially will cause a problem, I imagine. Hmm. Now, on to the really weird html_encode() behavior. Shadowdarke was right on the money with this one. The thing is, html_encode() changes html-specific characters (like <, >, and ') to their symbolic counterparts (' == '). The text output still displays these the same way, but internally they are different characters. You can see this by trying the following: for(var/i = 1, i<=lentext(msg), i++) Since the main purpose of this is simply to strip out html function calls though, we may want to provide, or soft-code, an alternate function that simply does that. The full symbolic replacement is really only used to embed html forms and links, and that has nothing to with your case. Since you are parsing the text already, you may just want to specifically look for and replace the '<' and '>' symbols instead of using html_encode(). | |
I will investigate this further, but one thing you should be aware of: client/Command(cmd as text) usr << cmd If you try that, you will see that all characters including quotes and backslash are passed through without interpretation. One big dissadvantage is that use of Command() can interfere with other verbs though. If you are doing total server-side parsing of commands, that might not be a concern. --Dan | |
Tom wrote:
Since the main purpose of this is simply to strip out html function calls though, we may want to provide, or soft-code, an alternate function that simply does that. The full symbolic replacement is really only used to embed html forms and links, and that has nothing to with your case. Since you are parsing the text already, you may just want to specifically look for and replace the '<' and '>' symbols instead of using html_encode(). Well, I didn't actually want to use html_encode()... I was just fiddling around with it since you brought it up and I noticed that strange thing. I will fiddle with client/Command(), but it's not in the reference. Anything else you can tell me about it? Z | |
Zilal wrote:
I will fiddle with client/Command(), but it's not in the reference. Anything else you can tell me about it? It's not in the reference because we haven't decided whether to make it an official part of the language or not. It is actually very useful for your particular case, but we'll probably just handle that with another input type (like "as text", but without the client-side filtering of \ and such). Anyway, client/Command() receives commands that are rejected by the server (ie- invalid verb combinations). The intention originally was for it to give you powerful control over the command-line, so that you wouldn't even have to use verbs at all. However, once we realized that <code>command_text = "> "</code> (or whatever) effectively does the same thing in a way compatible with the rest of the language, we felt that was the way to go. If you want to use client/Command() and the verb system, you run into some ambiguous parsing scenarios. Just declare: client/Command(command) to parse the command string. It will be literally passed in, so you don't have to worry about text substition that occurs with "as text". If you use this, you probably won't want to have any accessible verbs. As I said above, we will most likely either remove this or keep it unadvertised, but if that turns out to be the case we'll at least provide the plaintext "as text" alternative that you can use for your parsing needs. | |
I don't think we changed anything. As far as I can tell, "\\" still works in text output. Can you give me an example?