I find myself doing a ton of jQuery these days, so I started to abstract out some of the common things I do into snippets. I look forward to sharing these with the community, but I'm running into an issue right now.
The literals in snippets are defined by adding dollar signs ($) around the name of the literal to delimit where the value you would like to provide will go. This is difficult because jQuery uses the dollar sign notation in order to use a lot of its functionality.
What is the escape sequence for snippets, so I am able to use the dollar sign, and have my snippets still function?
To have a literal $ try doubling it: $$
This is the right way for Visual Studio Code: \\$.
This makes the $ a literal part of the snippet rather than the start of a $-prefixed construct.
There is an "Delimiter" attribute defined for a Code element. This defaults to $ but you can set it to a different character like ~ or so.
...
<Snippet>
<Code Language="JavaScript" Delimiter="~"><![CDATA[(function ($) {
$(document).ready(function () {
});
})(jQuery);]]></Code>
</Snippet>
...
Although the jQuery response is valid, it's a nicer syntax to use the $ notation.
I've found an answer: Making the $ character a literal with a default value of $.
<Literal Editable="true">
<ID>dollar</ID> <ToolTip>replace the dollar sign character</ToolTip> <Default>$</Default> <Function> </Function> </Literal>
I used this for a formattable string in C#. I used the example above from cory-fowler verbatim:
<Literal Editable="true">
<ID>dollar</ID>
<ToolTip>Replace the dollar sign character</ToolTip>
<Default>$</Default>
<Function></Function>
</Literal>
Usage (line breaks are added for clarity on Stack Overflow, not in the original.):
string errMessage = $dollar$"Error occurred in
{MethodBase.GetCurrentMethod().Module}, in procedure
{MethodBase.GetCurrentMethod().Name}: {ex.Message}".ToString();
Thanks, cory-fowler!
I found the above cory-fowler answer useful, but was frustrated that the literal $ was pre-selected when executing a C# snippet in VS 2019...
It was also ignoring my $end$ keyword...
<![CDATA[string Literal_edit_true = $dollar$"$end$";]]>
Simply changing to Editable=false resolved the issue and now the cursor appears at $end$ ready to type...
<Snippet>
<Code Language="CSharp">
<![CDATA[string Literal_edit_false = $dollar$"$end$";]]>
</Code>
<Declarations>
<Literal Editable="false">
<ID>dollar</ID>
<ToolTip>Replace the dollar sign character</ToolTip>
<Default>$</Default>
<Function></Function>
</Literal>
</Declarations>
</Snippet>
Related
The following rST directive doesn't support trailing spaces:
:code:`foo `
Example:
>>> from docutils import core
>>> whole = core.publish_parts(""":code:`x `""")['whole']
<string>:1: (WARNING/2) Inline interpreted text or phrase reference start-string without end-string.
Is there a way to get rid of this warning?
No. According to the docutils documentation of Inline markup recognition rules:
Inline markup end-strings must be immediately preceded by non-whitespace.
Sorry for the stupid question, but I have been stuck all afternoon with this simple problem. So I have a sample text file containing:
<product productId="123456" description="good apple, very green" publicPriceTTC="5,07" brand-id="152" />
<product productId="123457" description="fresh orange, very juicy" publicPriceTTC="12,47" brand-id="153" />
<product productId="123458" description="big banana, very yellow" publicPriceTTC="5,07" brand-id="154" />
And I'd like to modify this file into:
<product productId="123456" description="good apple, very green" publicPriceTTC="5.07" brand-id="152" />
<product productId="123457" description="fresh orange, very juicy" publicPriceTTC="12.47" brand-id="153" />
<product productId="123458" description="big banana, very yellow" publicPriceTTC="5.07" brand-id="154" />
Basically, I need to replace the "," (comma) by a "." (point) in all values of "publicPriceTTC". The trick here is that other attributes might have commas in their values ("description" in this example). I guess sed or awk can do that but I was unable to achieve it.
Can someone help me? Thank you very much for any help.
If you search for a comma to replace with a point, you will be doing a very coarse search/replace. Try something more especific. With sed, assume your input file is called xml:
sed -E 's/(publicPriceTTC="[0-9]+),([0-9]+")/\1.\2/' xml
You probably know that sed has the command s/<what you search>/<replacement>. We use that.
The -E option triggers the use of extended regular expressions. With that the s expression matches the whole tag + "=" + number within quotes, and uses the parenthesis to use the bit within them to be part of the substitution. \1 stands for the first bit between parenthesis block; \2 for the second.
You could of course make the search more robust to cope with whitespace between the tag and the equal sign and so on.
An awk solution to this might be:
awk '/<product/{for(i=1;i<=NF;i++){if($i~/^publicPriceTTC="/)sub(/,/,".",$i)}}1' file.xml
This steps through every whitespace-separated "field" on every <product>, looking for "words" that begin with the attribute you're trying to modify. If found, the entire attribute has its commas replaced with periods.
A simpler awk solution to emulate what others are doing with sed would be nice, except that awk does not support parenthesized subexpressions (i.e. \1 in your replacement string). Gawk supports them in the gensub() function, so the following might suffice:
gawk '{print gensub(/(publicPriceTTC="[0-9]+),/,"\\1.","g")}' file.xml
But ... you are solving the wrong problem here. Tools like sed and awk, which process files based on regular expressions, are not XML parsers. Either Javier's sed solution or my awk solutions could garble things accidentally, or miss certain things that are in perfectly valid XML files. Regex cannot be used to parse XML safely.
I recommend that you look into using python or perl or ruby or php or some other language with native XML support.
For example, turning your input into actual XML like this:
<p>
<product productId="123456" description="good apple, very green" publicPriceTTC="5,07" brand-id="152" />
<product productId="123457" description="fresh orange, very juicy" publicPriceTTC="12,47" brand-id="153" />
<product productId="123458" description="big banana, very yellow" publicPriceTTC="5,07" brand-id="154" />
</p>
We could run a PHP one-liner:
php -r '$x=new SimpleXMLElement(file_get_contents("file.xml")); foreach($x->product as $p) { $p["publicPriceTTC"]=str_replace(",",".",$p["publicPriceTTC"]); } print $x->asXML();'
Or split out for easier reading (and commenting):
<?php
// Read an XML file into an object
$x=new SimpleXMLElement(file_get_contents("file.xml"));
// Step through the object, fixing attributes as we find them
foreach($x->product as $p) {
$p["publicPriceTTC"] = str_replace(",",".",$p["publicPriceTTC"]);
}
// Print the result
print $x->asXML();
This will work on GNU
sed 's/\(publicPriceTTC="[0-9]*\),/\1./' fileName
Here using sub in awk is enough.
awk '{sub(/,/,".",$7)}1' file
When I use
``# ``
in my Sphinx documentation I get the following warning:
WARNING: Inline literal start-string without end-string.
Trying
:samp:`# `
leads to
WARNING: Inline interpreted text or phrase reference start-string without end-string.
The problem seems to be the trailing whitespace however I couldn't figure out a way of getting around this problem. Escaping the whitespace with a backslash (\) doesn't help either (for the first example the warning persists and for the second example the whitespace is omitted in the generated docs).
This answer doesn't work because the inline code section interprets the |space| as a literal string.
Experienced with Sphinx 1.6.2.
A workaround is to use a no-break space character (U+00A0) instead of a regular space (U+0020) for the trailing whitespace.
There are several ways to insert a literal no-break space character. See https://en.wikipedia.org/wiki/Non-breaking_space#Keyboard_entry_methods.
Use a "literal" role__ with an escaped space after the intended trailing space::
:literal:`# \ `
__https://docutils.sourceforge.io/docs/ref/rst/roles.html#literal
I recently used the <<- operator to output a multi-line string, like this:
<<-form
<h1>Name to say hi!</h1>
<form method="post">
<input type="text" name="name">
<input type="submit" value="send">
</form>
form
But I stole the <<- operator from some Open Source code, but I didn't find any documentation on it.
I kinda figured out that it works the same as in bash:
$ cat <<EOF >> form.html
> <h1>Name to say hi!</h1>
> <form method="post">
> <input type="text" name="name">
> <input type="submit" value="send">
> </form>
> EOF
Does it work that way? I just wanna find documentation on it.
From The Ruby Programming Language:
Here Documents
For long string literals, there may be no single character delimiter that can be used without worrying about remembering to escape characters within the literal. Ruby's solution to this problem is to allow you to specify an arbitrary sequence of characters to serve as the delimiter for the string. This kind of literal is borrowed from Unix shell syntax and is historically known as a here document. (Because the document is right here in the source code rather than in an external file.)
Here documents begin with << or <<-. These are followed immediately (no space is allowed, to prevent ambiguity with the left-shift operator) by an identifier or string that specifies the ending delimiter. The text of the string literal begins on the next line and continues until the text of the delimiter appears on a line by itself. For example:
document = <<HERE # This is how we begin a here document
This is a string literal.
It has two lines and abruptly ends...
HERE
The Ruby interpreter gets the contents of a string literal by reading a line at a time from its input. This does not mean, however, that the << must be the last thing on its own line. In fact, after reading the content of a here document, the Ruby interpreter goes back to the line it was on and continues parsing it. The following Ruby code, for example, creates a string by concatenating two here documents and a regular single-quoted string:
greeting = <<HERE + <<THERE + "World"
Hello
HERE
There
THERE
The <<HERE on line 1 causes the interpreter to read lines 2 and 3. And the <<THERE causes the interpreter to read lines 4 and 5. After these lines have been read, the three string literals are concatenated into one.
The ending delimiter of a here document really must appear on a line by itself: no comment may follow the delimiter. If the here document begins with <<, then the delimiter must start at the beginning of the line. If the literal begins with <<- instead, then the delimiter may have whitespace in front of it. The newline at the beginning of a here document is not part of the literal, but the newline at the end of the document is. Therefore, every here document ends with a line terminator, except for an empty here document, which is the same as "":
empty = <<END
END
If you use an unquoted identifier as the terminator, as in the previous examples, then the here document behaves like a double-quoted string for the purposes of interpreting backslash escapes and the # character. If you want to be very, very literal, allowing no escape characters whatsoever, place the delimiter in single quotes. Doing this also allows you to use spaces in your delimiter:
document = <<'THIS IS THE END, MY ONLY FRIEND, THE END'
.
. lots and lots of text goes here
. with no escaping at all.
.
THIS IS THE END, MY ONLY FRIEND, THE END
The single quotes around the delimiter hint that this string literal is like a single-quoted string. In fact, this kind of here document is even stricter. Because the single quote is not a delimiter, there is never a need to escape a single quote with a backslash. And because the backslash is never needed as an escape character, there is never a need to escape the backslash itself. In this kind of here document, therefore, backslashes are simply part of the string literal.
You may also use a double-quoted string literal as the delimiter for a here document. This is the same as using a single identifier, except that it allows spaces within the delimiter:
document = <<-"# # #" # This is the only place we can put a comment
<html><head><title>#{title}</title></head>
<body>
<h1>#{title}</h1>
#{body}
</body>
</html>
# # #
Note that there is no way to include a comment within a here document except on the first line after the << token and before the start of the literal. Of all the # characters in this code, one introduces a comment, three interpolate expressions into the literal, and the rest are the delimiter
http://www.ruby-doc.org/docs/ruby-doc-bundle/Manual/man-1.4/syntax.html#here_doc
This is the Ruby "here document" or heredoc syntax. The addition of the - indicates the indent.
The reason why you cannot find any documentation on the <<- operator is because it isn't an operator. It's literal syntax, like ' or ".
Specifically, it's the here document syntax which is one of the many syntactic forms of string literals in Ruby. Ruby here documents are similar to POSIX sh here documents, but handling of whitespace removal is different: in POSIX sh here documents delimited by <<-, only leading tabs are removed, but they are removed from the contents of the string, whereas in Ruby all leading whitespace is removed, but only from the delimiter.
This post will tell you everything you need to know about the "heredoc" string syntax. In addition, you can view the rubydoc page for string syntax.
I want to change this below using Regular Expression
<script type="text/javascript" language="javascript" src="/Common/Scripts/UserControls/Form.js"></script>
<script type="text/javascript" language="javascript" src="<%=VirtualPathUtility.ToAbsolute("~/Common/Scripts/UserControls/Form.js")%>></script>
You can try the following:
Find:
\<script type\=\"text\/javascript\" language\=\"javascript\" src="{[^"]+}"\>\<\/script\>
Replace:
<script type="text/javascript" language="javascript" src="<%=VirtualPathUtility.ToAbsolute("~\1")%>></script>
The key things to note:
You can match an expression for use in the replace section with braces {}. I use [^"]+ to capture all characters between the quotes - the [] matches a set of characters, where ^ means "not" - so [^"] matches anything except a quote. Then + means match one or more (non-quote characters).
Some characters have special meaning, so you can escape them with \. You can safely escape most chracters that don't have meaning if you put an extra \ unnecessarily in front of them, so I am overzealous just to be safe.
Use \1, \2, \3, etc. to use captured groups in the replace expression. So I'm using \1 to refer to the src attribute value matched in the find.