Digital Paint Discussion Board
Development => Bugs, Feature Requests, and Feedback => Official Feature Votes => Topic started by: Cobo on January 06, 2008, 12:24:48 AM
-
So you can have stuff like:
bind a "name "this is my name"; echo "I changed my name""
-
Do you mean Embedded quotes?
-
Yeah, I dont know if Jitspoe finally decided how he would do this.
I think he was going to hardcode some cvars as if they were "
-
or, he could just make it handle quotes like a programming language.
examples:
bind a "name 'this is my name'; echo 'I changed my name'"
bind a 'name "this is my name"; echo "I changed my name"'
bind a "name \"this is my name\"; echo \"I changed my name\""
bind a 'name \'this is my name\'; echo \'I changed my name\''
any of those ways.
-
Those'll work too.
-
Ok, I remember how he told me he may be doing it, since macro parsing was already implemented it would use a hardcoded cvar, and every time you embeded a string you would add a set of $. like this:
bind a $q$name $$q$$this is my name$$q$$; echo $$q$$I changed my name$$q$$ $q$
So when you do the bind, a's command would actually be set to this:
name $q$this is my name$q$; echo $q$I changed my name$q$
This is something that DP does already.
-
that's confusing to look at.
-
that's confusing to look at.
Exactly what I told him, but you could get used to it pretty easily.
-
http://dplogin.com/dplogin/featurevote/feature.php?id=10034
bind a "name ""this is my name""; echo ""I changed my name"""
Single quotes wouldn't work, though, because of situaitons like this
bind a "echo 'I can't use this.'"
-
Single quotes wouldn't work, though, because of situaitons like this
bind a "echo 'I can't use this.'"
exactly why i suggested being able to escape quotes (y'know, with a backslash). then it would become:
bind a "echo 'I can\'t use this.'"for example.
-
The escape char would be the obvious choice.
-
The escape character wouldnt work.
Here's why:
bind "a" "set \"mycvar\" \"my value\""
DP's parser simply doesnt know when to stop getting the next token. Will it tell you to set "mycvar" to "my value" or set "mycvar my value" to nothing.
This isnt the bets example of why, but it shows why it wouldnt work in dp. It works in languages because after a string you shouldnt have another string after it.
-
i hope you notice that escaped quotes are no worse than that $q$ and $$q$$ mess. the only difference is what characters are used.
-
i hope you notice that escaped quotes are no worse than that $q$ and $$q$$ mess. the only difference is what characters are used.
I hope you re-read my last post.
Obviously escape characters are better in every aspect.
I'll try to come up with a better example of why it woudlnt work...
-
The escape character wouldnt work.
Here's why:
bind "a" "set \"mycvar\" \"my value\""
DP's parser simply doesnt know when to stop getting the next token. Will it tell you to set "mycvar" to "my value" or set "mycvar my value" to nothing.
Writing a tokenizer with escape sequences is not hard...
-
Yep, for something that embeds strings until a certain level.
Imagine having 5 strings embedded in eachother. How does the parser knows when one starts and when one ends?
Thats why I said my example isnt the best.
-
oh it's possible. hard to look at, and probably complicated to code, but possible. computers are smart, they can do it. ;)
say a string starts with " - then the end of the string would be at the next occurence of that character, given that there is no backslash before it.
-
alias a " name Cobo; alias b \"name Oboc; alias c \"name Cobo\"\" "
DP parses alias
DP parses a
DP parses " name Cobo; alias b \"name Oboc; alias c \"name Cobo\"\" "
Now when dp parses " name Cobo; alias b \"name Oboc; alias c \"name Cobo\"\" " again it would go like this:
Dp parses name
Dp parses Cobo
DP parses ;
DP parses alias
DP parses b
Now when dp starts parsing \"name Oboc; alias c \"name Cobo\"\" it would go like this:
DP parses a \" this tells him we are in an embedded string.
Dp parses Oboc
Dp parses ;
Dp parses alias
DP parses c
Guess what Dp is going to do next.
Yep, you got it, dp will parse \" and not even the smartest computer will figure out that string shouldnt be over.
-
actually... yes that's true, but in that case you would not use \" around name Cobo.
there are 3 other characters you could use:
'
\'
or even \\" - double escaped ;)
and technically, you could nest quotes to limitless depth by using increasing numbers of backslashes for each depth of nesting.
and that, my friend, is how escaped quotes work.
-
Cobo, conventional backslash escaping uses multiple backslashes to escape multiple levels of quotes, as webhead has mentioned.
P.S. webhead beat me to the post =|
-
actually... yes that's true, but in that case you would not use \" around name Cobo.
there are 3 other characters you could use:
'
\'
or even \\" - double escaped ;)
and technically, you could nest quotes to limitless depth by using increasing numbers of backslashes for each depth of nesting.
and that, my friend, is how escaped quotes work.
That kind of defeats the purpose of the neatness of escape characters.
In such case, I believe adding "s is better than adding backslashes.
-
just multiple quote marks in a row?? now THAT's what would confuse the parser.
-
Escaping multiple levels can never be neat if you're working with more than one level. Adding ' instead of \ would completely prevent you from being able to use multiple levels of quotes.
-
just multiple quote marks in a row?? now THAT's what would confuse the parser.
Hm, I guess you're right there.
But thats what jitspoe said he was going to do, so idk.
-
computers are smart, they can do it. ;)
No, computers are very dumb. They only do exactly what you tell them to do. :P
-
::) fine, go ahead and pick apart my words. :P
i know that, i guess i should have used the word "capable" in place of "smart".
-
Writing a tokenizer with escape sequences is not hard...
But writing one that's compatible with the current tokenizer, and all the stuff that depends on it, is.
Double quotes seem to work fine for CSV parsers, and I think they could be implemented without breaking any of the current stuff
bind b "bind c ""say """"hello world"""""""
-> bind c "say ""hello world"""
-> say "hello world"
bind b "bind c \"say \\"hello world\\"\""
-> bind c "say \"hello world\""
-> say "hello world"
Perhaps the escape characters are cleaner, but we'd probably have to set up a full escape code set, with \t, \n, etc. What if somebody puts \n in their name? That could cause issues.
Oh, I just remembered something that caused headaches with my previous experiences: variables.
set somevar hello
bind a "say $somevar"
set somevar goodbye
pressing "a" will say "goodbye" as expected. But what if you wanted it to say hello? Putting quotes around something will make it absolute.
Also, say you wanted to use a command that cared about parameters? If you wanted it all in the first parameter, you'd have to put quotes around it, but if you put quotes around it, it won't parse out the variable.
set somevar "string with spaces"
bind a "somecmd $somevar"
Now when you press "a", it will execute:
somecmd (1)string (2)with (3)spaces
When you really wanted
somecmd (1)"string with spaces"
But if you do:
somecmd "$somevar"
you get
somecmd (1)$somevar