I just realized this while setting up a snippet.
'.source':
'shrug':
'prefix': 'shrug'
'body': '¯\\\\_(ツ)_/¯'
In order to print the typical ¯\_(ツ)_/¯ shrug, you need 4 backslashes. Using 2 backslashes doesn't cause any errors, but the backslash won't be printed. I would understand it if why you'd need 2, but why 4?
The four backslashes in atom snippets is due to snippets using the generic CSON notation (Coffeescript style JSON).
It's well described in this comment on an issue from the atom-snippets repo
I think that four backslashes makes sense, however notationally
inconvenient.
It has to do with the levels of interpretation a snippet goes through
before it ends up in your text buffer:
The snippet is declared in a CSON file, the parsing of string elements
in this format is "backslash sensitive" i.e. \n represents the newline
character and a \ is represented as .
The snippet then has to be
parsed by the snippet body parser. The parser uses one \ to escape the
following character, e.g. \ becomes . So the process goes as follows:
\ --CSON--> \ --BodyParser--> \
The reason two backslashes used to work, was because the snippet body
parser never really handled escaped characters (the escape cases were
handled explicitly rather than in a generic way) this was why we had
bug #60.
The process could be made more notationally friendly if the snippets
were stored in a custom format. Then we would have more control over
how it is parsed, such as not interpreting backslashes before they are
being fed to the body parser.
Related
I noticed that when using the Pubspec Assist plugin, it wraps the description line when updating a dependency.
description: Have you been turned into a newt? Would you like to be? This
package can help. It has all of the newt-transmogrification functionality you
have been looking for.
In researching this wrapping, I found that yaml supports wrapping, but indicates to use > (or | for keeping newlines, which probably isn't recommended for Flutter apps?).
The pubspec page on dart.dev shows an example using >-, but its own description doesn't mention anything about long descriptions or wrapping.
description: >-
Have you been turned into a newt? Would you like to be?
This package can help. It has all of the
newt-transmogrification functionality you have been looking
for.
Does it matter, in a Flutter project, say from an app store's perspective, which method is used for wrapping long descriptions in the pubspec.yaml file? I've always just kept them as one long line.
Wrapping is a YAML syntax feature. Flutter applies semantics to the parsed content of your YAML file.
This means that it doesn't matter to Flutter how you represent your YAML scalars, as long as the result – as defined by the YAML syntax you use – yields a valid value for Flutter.
With some scalars, YAML employs line folding: Single line breaks are transformed into a space, while empty lines are transformed into line breaks. This happens both with plain scalars and folded block scalars:
droggeljug: This is a plain scalar.
It spans multiple lines but when parsed, contains a single line.
baked_beans: >-
This is a folded block scalar.
It also spans multiple lines.
The previous empty line yields a line break in the parsed value.
There are some differences to consider:
plain scalars get ended by various special characters, such as : (when followed by whitespace). This should be obvious seeing that it forms an implicit key.
folded block scalars only end when content at the indentation of a parent node is encountered. You can savely write any character into a folded block scalar, even # which would otherwise starte a comment.
some scalars may be parsed a non-strings when given as plain scalar. For example, true might be a boolean and 42 might be a number. Folded block scalars always yield strings no matter the content.
Apart from these, there are also single- and double-quoted scalars, and literal block scalars (starting with | instead of >). Literal block scalars parse line breaks as-is. Double-quoted scalars parse escape sequences. Single-quoted scalars just don't end until the second ' is encountered. All of these scalar types may be multiline and all except literal block scalars do line folding. You can choose any of them to encode your string value.
As to the question which one you should use, I'd say the folded block scalar >- is the right tool for the job: You can write anything without worrying about YAML special characters, escape sequences, etc.
I have an embedded word document in my worksheet, names "Rec1"
The fields code are same as below:
{LINK Excel.SheetMacroEnabled.12 "C:\\Documents and Settings\\user\\Desktop\\Salaries\\StaffSalaries.xlsm" مالي!R2C13 \a \f 4 \r \* MERGEFORMAT}
What is the different and using "\ \" (double BackSlash) character with "\" one?
Word field codes originate in the C programming language. In that language, the backslash is used to indicate what in Office are called "switches" (like parameters). You see this a lot in command-lines, as well.
So in the LINK field you show us, \a, \f 4, \r and * Mergeformat are telling Word how to manage the field code (more info at https://support.office.com/en-us/article/field-codes-link-field-09422d50-cde0-4b77-bca7-6a8b8e2cddbd?ui=en-US&rs=en-US&ad=US).
\a tells the field it should update automatically
\f 4 tells Word to maintain Excel's original formatting
\r instructs Word to use RTF conversion for displaying the content
* are formatting switches, in this case, manually applied formatting should be retained when the field is updated
Because a single backslash denotes a switch, when you want to pass a literal backslash you need to double it up. This is the case for a file path, for example.
A backslash \ is often used to escape characters in many applications and programming languages. But since it's an escape character, it also needs to escape itself, if you literally mean \.
So in an environment where \ is an escape character, you need a double blackslash \\ to mean \.
I'm implementing a syntax highlighter in Apple's Swift language by parsing .tmlanguage files and applying styles to a NSMutableAttributtedString.
I'm testing with javascript code, a javascript.tmlanguage file, and the monokai.tmtheme theme (both last included in sublime text 3) to check that the syntax get highlighted correctly. By applying each rule (patterns) in the .tmlanguage file in the same order they come, the syntax is almost perfectly highlighted.
The problem I'm having right now is that I don't know how to know that a quote (") should be escaped when it has a backslash before it (\"). Am I missing something in the .tmlanguage file that specifies that?. Other problem is that I have no idea how to know that other rules should be ignored when inside others, for example:
I'm getting double slashes taken as comments when inside strings: "http://stackoverflow.com/" a url is recognised as comment after //
Also double or single quotes are taken as strings when inside comments: // press "Enter" to continue, the word "Enter" gets highlighted as string when should be same color as comments
So, I don't know if there is some priority for some rules over others in the convention, or if there is something in the files that I haven't noticed.
Help please!
Update:
Here is a better example of what I meant by escape quotes:
I'm getting this: while all the letters should be yellow except for the escaped sequence (/") which should be blue.
The question is. How do I know that /" should be escaped? The rule for that piece of code is:
Maybe I am late to answer this. You can apply the following method.
(Ugly) In your end regex, use ([^/])(") and in your endCaptures, it would be
1 = string.quote.double.js
2 = punctuation.definition.string.end.js
If the string must be single line, you can use match=(")(.*)("), captures=
1 = punctuation.definition.string.begin.js
2 = string.quote.double.js
3 = punctuation.definition.string.end.js
and use your patterns
You can try applyEndPatternLast and see if it is allowed. Set applyEndPatternLast=1 will do.
The priority is that earlier rules in the file are prioritized over later rules. As an example, in my Python Improved language definition, I have a scope that contains a series of all-caps constants used in Django, a popular Python web framework. I also have a generic constant.other.allcaps.python scope that recognizes (just about) anything in all caps. Since the Django constants rule is before the allcaps rule in the .tmLanguage file, I can color it with a theme using one color, while the later-occurring "highlight everything in all caps" only grabs identifiers that are NOT part of the first list.
Because of this, you should put your "comments" scope(s) as early in the file as possible, then write your parser in such a way that it obeys the rule I described above. However, it's slightly more complicated than that, as I believe items in the repository are prioritized based on where their include line is, not where the repository rule is defined in the file. You may want to do some testing to verify that, though.
Unfortunately I'm not sure what you mean about the escaped quotes - could you expand on that, and maybe add an example or two?
Hope this helps.
Assuming that / is the correct character for escaping a double quote mark, the following should work:
"str_double_quote": {
"begin": "\"",
"end": "\"",
"name": "string.quoted.double.swift",
"patterns": [
{
"name": "constant.character.escape.swift",
"match": "/[\"/]"
}
]
}
You can match an escaped double quote mark (/") and a literal forward slash (//) in the patterns to consume them before the end marker is used to handle them.
If the character for escaping is actually a backslash, then the tricky bit is that there are two levels of escaping, for the JSON encoding as well as the regular expression syntax. To match \", the regular expression requires you to escape the backslash (\\"). JSON requires you to escape backslashes and double quotes, resulting in \\\\\" in a TextMate JSON grammar file. The match expression would thus be \\\\[\"\\\\].
My goal is to create a program, with which the user can learn Bible verses by getting shown a problem and solving it through input (e.g. "Quote vers Gen 3:15"). As the Bible translation, I have to work with, is German, it contains a ton of umlauts, which are never showing properly.
My PyGame file's header:
#!/usr/bin/python
# -*- coding: utf-8 -*-
Later on, I list the three German umlauts:
u'ö'.encode('utf-8')
u'ä'.encode('utf-8')
u'ü'.encode('utf-8')
The txt-file is parsed by this function:
def load_list(listname):
fullname = os.path.join("daten", listname + ".txt")
with codecs.open(fullname, "r", "utf-8-sig") as name:
lines = name.readlines()
for x in range(0, len(lines)):
lines[x] = lines[x].strip("\n")
lines[x] = lines[x].strip("\r")
print lines
I'm aware, that I could combine the two lines with the strip-commands, but that's not the topic here.
How can I get my PyGame to display the umlauts from the text-file correctly as well also display the user input's umlauts correctly? I checked hundreds of suggestions, I can't get anything really working here.
Any help is highly appreciated, before I lose my sane mind (well, as I'm sitting here, coding games, I probably did already anyway :D )
I'll try to summarize:
Printing something else than a string or unicode opject triggers that object's __repr__() method. If it is a sequence, this applies to the contained elements as well, causing any non-ascii character to be escaped with \xXX (or \uXXXX) notation. Note the difference between print 'text' and print ['text']: in the latter case, the string's quotes will be printed as well (besides the brackets of course). Use str.join() for concatenating lists of strings in order to control the way the output looks.
It's a good idea to always explicitely decode input (as you do by using codecs) and encode the output (which is not done in the code snippets in your question).
The source file encoding (the # coding: utf8 line in the header) has nothing to do with encoding of input and output. It only enables you to type non-ascii character in string literals (= characters inside quotes in the source file), instead of using \xXX escapes.
Hope that makes some things clearer. There's a lot that can go wrong that looks like an encoding error, and it's not always easy to find out what's actually happening.
I am getting problem while parsing xml files that contains some special characters like single quote,double quote (', "")etc.I am using NSXMLParser's parser:foundCharacters:method to collect characters in my code.
<synctext type = "word" >They raced to the park Arthur pointed to a sign "Whats that say" he asked Zoo said DW Easy as pie</synctext>
When i parse and save the text from above tag of my xml file,the resultant string is appearing,in GDB, as
"\n\t\tThey raced to the park Arthur pointed to a sign \"Whats that say\" he asked Zoo said DW Easy as pie";
Observe there are 2 issues:
1)Unwanted characters at the beginning of the string.
2)The double quotes around Whats that say.
Can any one please help me how to get rid of these unwanted characters and how to read special characters properly.
NSString*string =[string stringByTrimmingCharactersInSet:[NSCharacterSet characterSetWithCharactersInString:#" \n\t"]];
The parser is apparently returning exactly what's in the string. That is, the XML was coded with the starting tag on one line, a newline, two tabs, and the start of the string. And quotes in the string are obviously there in the original (and it's not clear in at least this example why you'd want to delete them).
But if you want these characters gone then you need to post-process the string. You can use Rams' statement to eliminate the newline and tabs, and stringByReplacingOccurrencesOfString:WithString: to zap the quotes.
(Note that some XML parsers can be instructed to return strings like this with the leading/trailing stuff stripped, but I'm not sure about this one. The quotes will always be there, though.)