I have some CoffeeScript in my Rails project, with which I'm trying to update a textarea. My CoffeeScript is:
$('#video_description').val(<%= #description %>")
The returned text is a string from the YT gem (a description from one of my YouTube videos). An example can be:
Testing that this works
Does this work?
When I load the page and inspect it with the Developer Tools in Chrome, the CoffeeScript looks like:
$('#video_description').val("Testing that this works
Does this work?")
The new line avoids the CoffeeScript from making sense to the interpreter, and it raises the following message:
Uncaught SyntaxError: Invalid or unexpected token
I've tried replacing the CoffeeScript with:
$('#video_description').val(<%= h #description %>")
This has no effect (other than to escape all the single quotes in the actual string). It has something to do with the fact the string is dropped into the quotes as is.
I need to have the text string to have \n instead of the carriage return.
Any help to solve this would be great.
Use the escape_javascript() method (shortcut: j())
$('#video_description').val("<%= j(#description) %>");
Related
I'm trying to replace a string stored in a list with an HTML tag in a file by doing:
links=[http://hexagon-dashboard-gbc-01/vboard/latest?regs=3281546<!--V68NUR-->]
str1="""%s<!--V68NUR-->"""%(vboard['V68N']['perf.tl'],vboard['V68N']['perf.tl'])
with open(html_file,'r+') as f:
content = f.read()
f.seek(0)
f.truncate()
f.write(content.replace(links[0],str1))
But I get the following error:
TypeError: replace() argument 1 must be str, not Tag.
What am I missing? Please help me with the modification I have to do.
Updated:
From what you posted, I suppose you are treating a html file as plain text and going to perform string replacement.
The replace() function only works when both of its arguments are strings.
The reason you got an error is that links[0] is not a string but a tag.
If you manage to get links like this (note the single quotes)
links=['http://hexagon-dashboard-gbc-01/vboard/latest?regs=3281546<!--V68NUR-->']
then
content.replace(links[0],str1)
would not produce any errors.
To edit html files, you can also use HTML Parser instead.
We're using Gatling jsonpath in scala to parse our JSON, and are using it like so as per the docs:
val jsonSample = (new ObjectMapper).readValue("""{"#a":"A","#b":"B"}""", classOf[Object])
JsonPath.query("$.#a", jsonSample).right.map(_.toVector)
However, this code fails, and we get an error message about "string matching regex '[$_\d... etc etc }]* expected, but # found".
I've tried using backslashes, but these do not work and give the same error message. Does anyone know how to escape the # symbol?
It's worth noting I also tried the solution with hex on this page, but it doesn't work for the above. How do you escape the # symbol in jsonpath?
Thanks!
Turns out using a different syntax fixes this:
JsonPath.query("$['#a']", jsonSample).right.map(_.toVector)
i'm about to write some test for my client UI.
the weird thing, my JSON string:
{"match":"\s?5\.7\s?\<=\>\s?7","success":"null-coalesce-operator"}
used to be parsed by JSON.parse by browser(Chrome) and looks like this:
{
match: "\s?5\.7\s?\<=\>\s?7",
success:"null-coalesce-operator"
}
everything is fine,
but when i run that part by mocha within node.js env, i get:
{"match":"\s?5\.7\s?\<=\>\s?7","success":"null-coalesce-operator"}
^
SyntaxError: Unexpected token s
at Object.parse (native)
...
did anyone experienced stuff like this. thx for any tipp.
node version is v5.7.1
mocha version is 2.4.5
UPDATE html string that i test is:
<!doctype html><html><body><div data-meta="{"match":"\\s?5\\.7\\s?\\<=\\>\\s?7","success":"null-coalesce-operator"}"></div></body></html>
it just a single line string without any \n newlines and the same.
I think it is because it also parse specials characaters (e.g \n => line feed, \r => carriage return, etc), what chrome did not. So because you want an antislash in you regex, before parsing in node, you need to replace each\ by \\:
json_string = json_string.replace(new RegExp('\\\\', 'g'), '\\\\') //we have to use regex, because when using replace with string, it only replaces the first occurence...
otherwise, when parsing, it will tell, à \s : 'It is a special character, identified by s. But I haven't any tokens s. So I throw an error."
I'm attempting to look up the word "flower" in Google's dictionary semi-api. Source:
https://gist.github.com/DelvarWorld/0a83a42abbc1297a6687
Long story short, I'm calling JSONP with a callback paramater then regexing it out.
But it hits this snag:
undefined:1
ple","terms":[{"type":"text","text":"I stopped to buy Bridget some \x3cem\x3ef
^
SyntaxError: Unexpected token x
at Object.parse (native)
Google is serving me escaped HTML characters, which is fine, but JSON.parse cannot handle them?? What's weirding me out is this works just fine:
$ node
> JSON.parse( '{"a":"\x3cem"}' )
{ a: '<em' }
I don't get why my thingle is crashing
Edit These are all nice informational repsonses, but none of them help me get rid of the stacktrace.
\xHH is not part of JSON, but is part of JavaScript. It is equivalent to \u00HH. Since the built-in JSON doesn't seem to support it and I doubt you'd want to go through the trouble of modifying a non-built-in JSON implementation, you might just want to run the code in a sandbox and collect the resulting object.
According to http://json.org, a string character in a JSON representation of string may be:
any-Unicode-character-
except-"-or--or-
control-character
\"
\
\/
\b
\f
\n
\r
\t
\u four-hex-digits
So according to that list, the "json" you are getting is malformed at \x3
The reason why it works is because these two are equivalent.
JSON.parse( '{"a":"\x3cem"}' )
and
JSON.parse( '{"a":"<em"}' )
you string is passed to JSON.parse already decoded since its a literal \x3cem is actually <em
Now, \xxx is valid in JavaScript but not in JSON, according to http://json.org/ the only characters you can have after a \ are "\/bfnrtu.
answer is correct, but needs couple of modifications. you might wanna try this one: https://gist.github.com/Selmanh/6973863
I have looked at how to embed HTML syntax in JavaScript string from HTML syntax highlighting in javascript strings in vim.
However, when I use CoffeeScript I cannot get the same thing working by editing coffee.vim syntax file in a similar way. I got recursive errors which said including html.vim make it too nested.
I have some HTML template in CoffeeScript like the following::
angular.module('m', [])
.directive(
'myDirective'
[
->
template: """
<div>
<div>This is <b>bold</b> text</div>
<div><i>This should be italic.</i></div>
</div>
"""
]
)
How do I get the template HTML syntax in CoffeeScript string properly highlighted in VIM?
I would proceed as follows:
Find out the syntax groups that should be highlighted as pure html would be. Add html syntax highlighting to these groups.
To find the valid syntax group under the cursor you can follow the instructions here.
In your example the syntax group of interest is coffeeHereDoc.
To add html highlighting to this group execute the following commands
unlet b:current_syntax
syntax include #HTML syntax/html.vim
syn region HtmlEmbeddedInCoffeeScript start="" end=""
\ contains=#HTML containedin=coffeeHereDoc
Since vim complains about recursion if you add these lines to coffee.vim i would go with an autocommand:
function! Coffee_syntax()
if !empty(b:current_syntax)
unlet b:current_syntax
endif
syn include #HTML syntax/html.vim
syn region HtmlEmbeddedInCoffeeScript start="" end="" contains=#HTML
\ containedin=coffeeHereDoc
endfunction
autocmd BufEnter *.coffee call Coffee_syntax()
I was also running into various issues while trying to get this to work. After some experimentation, here's what I came up with. Just create .vim/after/syntax/coffee.vim with the following contents:
unlet b:current_syntax
syntax include #HTML $VIMRUNTIME/syntax/html.vim
syntax region coffeeHtmlString matchgroup=coffeeHeredoc
\ start=+'''\\(\\_\\s*<\\w\\)\\#=+ end=+\\(\\w>\\_\\s*\\)\\#<='''+
\ contains=#HTML
syn sync minlines=300
The unlet b:current_syntax line disables the current syntax matching and lets the HTML syntax definition take over for matching regions.
Using an absolute path for the html.vim inclusion avoids the recursion problem (described more below).
The region definition matches heredoc strings that look like they contain HTML. Specifically, the start pattern looks for three single quotes followed by something that looks like the beginning of an HTML tag (there can be whitespace between the two), and the end pattern looks for the end of an HTML tag followed by three single quotes. Heredoc strings that don't look like they contain HTML are still matched using the coffeeHeredoc pattern. This works because this syntax file is being loaded after the syntax definitions from the coffeescript plugin, so we get a chance to make the more specific match (a heredoc containing HTML) before the more general match (the coffeeHeredoc region) happens.
The syn sync minlines=300 widens the matching region. My embedded HTML strings sometimes stretched over 50 lines, and Vim's syntax highlighter would get confused about how the string should be highlighted. For complete surety you could use syn sync fromstart, but for large files this could theoretically be slow (I didn't try it).
The recursion problem originally experienced by #heartbreaker was caused by the html.vim script that comes with the vim-coffeescript plugin (I'm assuming that was being used). That plugin's html.vim file includes the its coffee.vim syntax file to add coffeescript highlighting to HTML files. Using a relative syntax include, a la
syntax include #HTML syntax/html.vim
you get all the syntax/html.vim files in VIM's runtime path, including the one from the coffeescript plugin (which includes coffee.vim, hence the recursion). Using an absolute path will restrict you to only getting the particular syntax file you specify, but this seems like a reasonable tradeoff since the HTML one would embed in a coffeescript string is likely fairly simple.