I have been using Sublime for a few months with great enjoyment until yesterday when something was corrupted and I needed to reinstall.
Since I thought I had all the packages I used memorized, I didn't keep a backup and did a full uninstall/reinstall of the app and the application support folder.
One of the features I really liked was that if I pasted in copy from another source, like Word, all the characters like curly quotes, etc. would be highlighted in hot pink.
This is no longer working and I believe it must've been a package I installed and didn't realize it. It saves a lot of time if you have to convert text to HTML content.
Does anyone know what package that is or how to get that behavior back in ST2?
I have been all over Google and cannot figure out how this was working. My mistake for throwing my settings/packages away.
I recently wrote a plugin dedicated to this exact problem: highlighting non-ascii characters.
https://github.com/TuureKaunisto/highlight-dodgy-chars
The plugin works on a whitelist principle: all non-ascii characters that are not whitelisted in the settings get highlighted.
I think the package you're after is Highlighter. It highlights a few unicode characters in that hot pink you referred to. You can add more matches via settings (example).
Related
As I mentioned in the title, the power went of for 2 minutes, and my PC turned off while I was writing some HTML. After I turned it back on my code turned into binary and I don't know how to recover it. I use Sublime Text 3. I've also tried opening it in Notepad++, but it looks the same.
Sublime
Notepad++
Is this something that can help you?
I don't know if the binaries are the compiled HTML code or just plain text symbols calculated into binaries.
If the second one is the case then you might be able to recover it with something like the link above. Of course if sublime encodes with 16 or 32 bits "per sign" then you will have to use some other algorithm. This should not be too difficult to implement though (in Java for example).
If the text looks like
0101010001101000011001010010000001110001
then every sign is encoded with exacly the same number of bits so you can just try to split it every 8th bit (or 16th, or 32nd) and use the above or equal algorithm to decode that.
If your binaries is a compiled code then I am not aware of any way to decompile binaries into HTML although such algorithm should exist somewhere.
EDIT: Be aware that, since your editor broke unexpectedly, the file might be corrupt and the code will be slightly different or destroyed completely. In this case there is nothing you can do, unless the corruption can be undone.
I didn't find anything related to my problem in the whole web (so even not on stackoverflow) and I'm thinking that maybe I'm not searhcing with the right keywords...
Anyway here is my question:
Lately Visual Studio started to replace unicode escape sequences automatically with the real character e.g.: '\u00e4' will be replaced with 'ä'. It happens every time when I'm changing something on the json-file. If I'm doing the changes somewhere else I don't see that the replacement happened and Visual Studio doesn't mark this as a change (luckily SVN shows me this as change). Often I notice this problem not until I see it in the application.
Even when I try to correct this mistake with replacing 'ä' by copy & paste with '\u00e4' it will be directly converted to 'ä'. If I type '\u00e4' in manually everything is fine till next time.
What can cause this behaviour and how can I fix this? I'm also using Resharper and maybe this causes somehow the behaviour?
So I've been looking at a way to import GTFS data into an SQLdb for my application. I found a solution available on GitHub.
But, this is written using python. I don't think I can use this directly in my windows application. Please correct me if I am wrong here.
But I have no issues with understanding the logic behind the solution and creating my own 'parser'.
So, I opened the GTFS data file "calendar dates.txt" on Notepad and found its content confusing. It was like:
service_id,date,exception_type1,20151012,11,20151111,12,20150822,12,20150829,12.....
You can see that its confusing when there are no line breaks.
But I paste the code here to show it to you guys, and it automatically formats to:
service_id,date,exception_type
1,20151012,1
1,20151111,1
2,20150822,1
2,20150829,1
2
Now it clearly makes sense!! (There are spaces in between for parsing)..
But I don't understand. Is Notepad showing it wrong? How do I see the data "properly" then, in order to write my own parser?
Most likely your GTFS data is written with UNIX end-of-line characters (linefeed only) as opposed to MS-DOS/Windows characters (carriage return followed by linefeed). This is permitted by the GTFS spec, which says:
Each line must end with a CRLF or LF linebreak character.
Most application software available for Windows, including Notepad, recognizes only Windows end-of-line characters and opening a file created on UNIX will show the entire contents as a single line, as you've observed. However, tools like Notepad++ that are meant for developers, as well as most programming libraries (such as those meant to parse CSV files), are usually smart enough to recognize both formats and handle them appropriately.
Wikipedia has more information about end-of-line representations across operating systems if you're interested.
Finally, I'll mention that I've recently posted to Github my own GTFS-to-SQLite loading tool, which is written in C and uses libcsv to parse GTFS data. If you're developing in a language lower-level than Python you may find it useful as an example.
First of all copy your related GTFS(routes,shaps etc) and than paste in an online text editor(for example: http://www.editpad.org/)
And than copy from this online text editor and paste again to your original .txt.
I've started researching LDAP and started following a tutorial to at least start familiarizing with it. While doing that, I noticed that there is an odd (for me) notation in the /usr/share/slapd/slapd.conf file on my computer, namely #SUFFIX# and other things surrounding by the at sign. I think that this is supposed to be interpreted as some kind of a variable or substitution point, but any search on Google turned out nothing, as they ignore special characters.
How should I interpret this and where can I change it?
Sounds like you're talking about the slapd.conf template from the Debian package. #SUFFIX# and the other tokens in that file are replaced at configure time by the maintainer scripts.
(The package also contains a similar template for dynamic configuration; slapd.conf is no longer used.)
I think I am in a world of hurt right now. I have written a script in Eclpse. This is the first time I've used it. Because I work in ArcGIS a lot, I learned how to script using IDLE. I made the switch to Eclipse on the recommendation of a coworker and I love the environment, however, I've done something to my script that is messing up the indentation and to eb hoenst, I don't know how I did it. I get this weird behavior.
In Eclipse, I receive an error "inconsistent Indent at line....". It's weird, because that specific line appears to be in the right indented spot.
I will open the script in IDLE and the line appears to be in a different indented location than what I see in Eclipse. This would explain the error, but it doesn't explain why the line appears indented in one IDE and not in the other.
I think I learned that it has something to do with the space-tab, tab-space option under 'Source' in Eclipse and the Tabify/Untabify option under 'Format' in IDLE. I try to fix it in one IDE, but then it either tabs too much or too little in the other. I'm at a loss. I think I havea mix tab/space thing going on and I want to fix it so that isn't happening. Does this sound like what my problem is? How do I fix it? How do I set Eclipse so that when this error comes up, the line is displaying the indentation in the wrong location so that I can identify why this error is coming up?
IDEs have an option to replace tab char with spaces and another option to indent by 'n' chars per tab (whether it will be replaced by spaces or not). It sounds like your IDEs have different settings for these.
If you configure both IDEs to do the same thing for tab replacement and indent, then retabify the source once, you should be OK.