This is a formatting issue that's been bugging me. I like to use leading commas in my grouped variable declarations, ie:
var something = true
, anotherVar = false
Debate about whether that's good or not, aside... I've noticed when I cut and paste this in the Atom editor it drops the leading tab /spacing so that the comma is directly under the "v" in var and the variable names are misaligned.
Might seem trivial but it causes my OCD to flare up. Are there any known workarounds? Thanks!
Found a workaround:
Settings > Language Javascript (Package) > Uncheck Auto Indent On Paste
Will report back if there's any adverse consequences, so far seems to work as expected.
Related
As part of my feature engineering, I need to parse text strings from different languages and keep text enclosed within parentheses. Everything was going well until I encountered a very strange phenomenon. For some languages, the parentheses I need to find look slightly different, and various regexp options fail.
I'm pasting screen-shots because strangely, copying and pasting the strange parentheses changes it to a 'normal' one, so I can't set up a different regex to find those separately.
Notice that the parentheses in the first entry look normal, but for the second entry, it appears sort of 'sharp'
If I use stringr's str_extract, the first instance works fine, but the second fails.
But, the encodings are the same. Anyone know what's going on?
[Edit: here are the results of dput on these same examples. dput apparently sees the parentheses as equivalent, even though grep does not]
c("Obnaružena poterâ šaga na (Motor šprica pipettora R1).", "(STAT tàn zhen Z zhóu ma dá) tàn cè dào diu bù<U+3002>")
Finally, I am actually copy and pasting the two parentheses from R into the code window below; they do appear different this way. First is normal, second is the strange one.
( （
I'm having trouble reading this table into R:
http://www.census.gov/popest/about/geo/state_geocodes_v2012.txt
I tried all of the following:
read.table("http://www.census.gov/popest/about/geo/state_geocodes_v2012.txt")
read.table("http://www.census.gov/popest/about/geo/state_geocodes_v2012.txt",skip=7,header=FALSE)
read.table("http://www.census.gov/popest/about/geo/state_geocodes_v2012.txt",skip=8,header=FALSE)
read.table("http://www.census.gov/popest/about/geo/state_geocodes_v2012.txt",skip=10,header=FALSE)
If I tell it that the separator is a tab, i get the wrong table:
d = read.table(file="http://www.census.gov/popest/about/geo/state_geocodes_v2012.txt",header=FALSE,skip=7,sep="\t")
the only thing that seems to work is readLines. but then i don't know how to get a data.frame out of each line.
d =readLines("http://www.census.gov/popest/about/geo/state_geocodes_v2012.txt")
any suggestions? thanks.
I agree that read.fwf will work, once you've worked out the widths.
But, Yeah -- I just hate people who allow whitespace inside elements (e.g. "SouthDakota" ) . One other thing you can do is edit the source text file, replacing {2,N} spaces with a tab. That will leave the state names as-is but give you a workable delimiter.
I am belatedly setting up Aptana to use four spaces instead of tabs. I've made the necessary changes to the preferences so every new tab inserts four spaces.
All the existing tabs remain, however, and so I get Mixed spaces and tab errors. How can you do a Replace all to fix this? I've tried ^t, <TAB> etc but it just searches for these as normal strings. What are the correct ways to specify a space and a tab?
I've found myself in similar situation and copying whole source code and repasting it helped me out. Just do as follow on your source code Ctrl+A, Ctrl+C, then Del whole code and Ctrl+V it again. You will get only spaces if have set it in options like you mentioned above.
There's an option in the refactor source menu to convert between tabs and space-tabs.
This worked for me: Edit > Find/Replace... (CTRL+F), check Regular Expressions, type \t and type 4 spaces (I use 4 spaces for tab).
I have two CSS files where most of the whitespace have been removed. I wonder whether there's a way to get a meaningful diff out of them.
Run each file through a CSS prettifier, and then diff them the normal way.
A quick google search turned up this online prettifier: http://procssor.com/
Do a search and replace through the css file and insert a new line after every '{', '}' and ';' character. Then, you can use ordinary diff to compare them.
Use Pretty Diff. That tool is a language aware diff tool, so trivial things like white space and comments are filtered out as false positives.
How can one insert a Unicode string CSS into CleverCSS?
In particular, how could one produce the following CSS using CleverCSS:
li:after {
content: "\00BB \0020";
}
I've figured out CleverCSS's parsing rules, but suffice that the permutations I've thought sensible have failed, for example:
li:
content: "\\00BB \\0020" // becomes content: 'BB 0'
EDIT: My other examples and the rest of my post weren't saved. Suffice to say that I had a longer list of examples that's missing.
I'd be grateful for any thoughts and input.
Brian
EDIT: I noted that inserting the unicode was one of the problems (once you start uploading CSS with utf-8 encoding it's fine). The wrapping of quote characters is another, which I solved that with something crazy likeso:
content: "'".string() + " ".string() ».string() + "'".string()
Hope that helps someone else.
This may be silly, but why still bother with escape sequences when you can just type/paste the actual characters? "A CSS style sheet is a sequence of characters from the Universal Character Set".
That is a lot easier on the eye, and is especially useful when maintaining existing code.
Or is CleverCSS not Unicode-enabled?
In looking at the code (CleverCSS 0.1) it would appear that the partial regular expression _r_string (defined on line 414) is where you would need to start. This is used to define several other REs, including _string_re which is used in the parsing rules (line 1374). This leads us to process_string() (line 1359) which looks like it was meant to accept Unicode.
Unfortunately, hand-built parsers tend to get a bit strange and the code is not exactly swimming in comments. If you really need to do this, I would focus on process_string() and put a bunch of before/after print statements in there and see if you can understand the goes-intos and goes-outofs.
You might also try bribing the original author with beer or ??? Good luck.