I've been re-writing my resume from scratch (good way to start the new year, I think,) and I'm doing it as a webpage. Naturally I want all the HTML, CSS & Javascript in one file, so it'll be portable.
While working on it in Vim, I have the CSS, HTML, & Javascript sections of the document open in separate tabs. But as soon as I open a second tab, the syntax highlighting for the CSS turns off. The HTML and Javascript continue to be highlighted properly.
I'm not a Vim expert by any means, so I apologize if this is too basic a question, but I couldn't find any documentation (or existing posts on Stackoverflow) that address this issue.
Thanks in advance for any insight.
Because vim doesn't start looking for highlighting at the "top" of the file, but rather a few hundred lines up from the current on-screen view, you can sometimes get the highlighting to work by scrolling around a little.
If this works, you can tweak the syntax highlighting controls so that you don't have to waste your time scrolling around; for full details, see :help syn-sync. There's several options:
Forcing vim to start recognizing syntax from the very start of the file every time. This might lead to significant performance problems on huge files but that might also be an indication that your source could be better split apart.
:syntax sync fromstart
Increase the number of lines that are parsed. This reduces the chances of bad syntax recognition without necessarily incurring the expense of reparsing the entire file from the start each time.
:syntax sync minlines=200
Pick a number that is large enough to work almost all the time without significant performance penalties. This is probably the best approach to take, even 500 lines ought to be alright on most computers from the last decade.
If you're editing C-style code, vim can easily resynchronize using C-style comments. (Note, not the // newfangled variety but /* the original style */.) Probably not the best choice for HTML, CSS, JavaScript, but perhaps your code makes it more feasible:
:syntax sync ccomment
The fourth method uses "sync patterns", similar to the C-style comments, but more applicable to other environments. It has enough extra complications that I don't think describing it here is worth the effort -- :help syn-sync-fourth has all the details for the curious.
Any of these configuration options can be added to your ~/.vimrc file:
syntax sync fromstart
You can change the behavior based on what kind of files you're editing. Just leave off the leading : when adding lines to the file. Use autocmd to define it for types like this:
autocmd BufNewFile,BufRead *.html syntax sync fromstart
These may become relevant to provide an answer
what version of vim are you using? I'm assuming you're using Vim 7.3 (if not, you should - most linux distors have it, and there's an exe for Windows and MacVim for osx). It could be that your installation is old or broken.
Any plugins? A simple check will be to temporarily remove all your plugins, restart vim and see if this still happens.
Anything special in your .vimrc? If you customized it yourself then there are probably not too many surprises, but if you borrowed from someone else, you can do the same thing you did with the plugins folder (empty or bare-minimum file).
Hope this helps - good luck!
Related
Is it possible to have a CSS virus, or what could be the closer of it? (=a non virus but something harmful for the security)
What kind of security breaches could it exploit?
Not a virus, that would not be possible. The only thing that comes to mind is this:
https://hackaday.com/2018/02/25/css-steals-your-web-data/
It abuses the fact that you can select an element based on an attribute's value.
Really clever!
Edit: There is a deprecated CSS property that was usable in IE5.5 (I think) that allowed you to define arbitrary js to be executed at run time. Someone demonstrated that you could put the entirety of jQuery in the property value and it ran. Obviously, this is not very useful today, but interesting, nonetheless. If I find this I will add it to this response.
CSS is a browser side language there for the only way you would be able to execute harmful code in it would be to re-name the file to something like .exe or .php.
You can't get a virus via css. But this is an interesting article about fetching userdata with it https://www.bleepingcomputer.com/news/security/css-code-can-be-abused-to-collect-sensitive-user-data/
The answers that you have gotten stating it is not possible, are correct,
as long as everything works the way it is supposed to.
But since, at least with respect to security, everything on the internet is broken (and most other code as well) in one way or another, it is certainly possible for CSS to be a
carrier of maleficent CSS that exploits security holes either in the CSS parser or the execution of CSS script content.
Then again, that is of course not specific to CSS, but also true for HTML/JS/images etc,
or basically any input from an unsecured source being parsed by any piece of software on your machine.
The access gained from these attack vectors can then be used to inject or
create a virus on the fly.
I'm aware of the different abilities to highlight based on filetype, but what I'm looking for is something similar to how in a typical text editor you can highlight a line (not just change the color text).
Is this possible to do in the Atom editor? If so, how do you do it? Is there a plugin for this?
The reason I want to do this is for organizational purposes, and sometimes the files I am working in our custom files that are not necessarily code but documentation (usually both are together in the same file), and the documentation part is where I want to add these highlights.
The only Atom package I know of that has a somewhat similar functionality is the bookmarks package.
It is an Atom core package, so you most likely have it installed already.
It might not be exactly what you were looking for, since it only allows setting bookmarks on lines of your open files.
As soon as you close a file, the bookmarks are lost.
But while working on several opened files, it can be very useful to quickly navigate through these bookmarks.
The reason why no package like you asked for exists, probably is that it would be really hard or at least impractical to implement.
Imagine you set dozends of highlights on a file which is under version control (git, svn, etc.) and then pull in a newer version of this file where several lines were added, removed, changed, shifted ...
To still be able to show the highlights on the correct lines, the information of such highlights would need to be under the same version control. Essentially you would need to store this highlight on the line itself, which would mean everybody had the same highlights, which is probably not what you want. Because if you wanted that, you could just format your documentation with markdown or similar in the first place ;)
Does anyone know of a way to prevent Sublime Text 3 converting sass variables on pressing tab?
For example, I might type $variable-name and then press tab, intending to insert the : and space, which would be the normal CSS behaviour. Within doc type sass, I get 1variable-name:; instead.
It's rather annoying to have to correct every time, and I'm sure others get irritated with the same. I have the Sass and Emmet packages installed.
Many thanks. Your help is much appreciated.
Too long for a comment...
So I did a little digging last night, and from what I can tell this behavior is hard-coded into Sublime. The command that's executed when Tab is pressed right after a variable is expand_abbreviation_by_tab. Many times, Sublime commands are implemented in .py files, and can so be edited to suit your needs. Unfortunately, I was unable to find any mention of this command anywhere, leading me to believe that it's hard-coded. I suppose a workaround would be to enter a space before hitting Tab, if your end goal is to have the colons : aligned with each other. Another option would be to use the Alignment plugin, available through Package Control. It's very configurable, and I highly recommend it.
I had an idea for "cheap" version control of the css of one of my sites, but am thinking it may not be a good idea. Thought I'd throw it out here in case someone has a similar idea that works better (besides real svn, etc.)
My thought was to create a main css file like "sitename.css" then use #import inside this file to connect to the most recent file with updates. I'd name these imported files by date, eg: 20101222_css.css so I'd know when the last update was applied. When I have a change, I could make my edits, drop the update in the respective location, change the #import to the new file, and viola... updated on the site.
After reading about issues with #import, such as it loading AFTER the page finishes, I'm not too keen on this now.
Any ideas of a way to implement something similar without a full blown system? I do a lot of small project work for various people and thought this method may be a simple way to keep track of things.
Thanks for any ideas/suggestions.
Your idea would add additional page loads to your site for no good reason, which will be a performance hit. It would also expose your versioning to the outside world. And as you say it will suffer from slow loading speeds due to the way #import works.
But the real down-side of this technique is that it only works for CSS files. You haven't solved the problem for any other files on your site.
You seem to think it would be simpler to use than a real SVN setup, but if you end up coming up with different techniques like this for every type of file on your site, you could easily end up giving yourself more headaches than you solve.
SVN is actually quite straightforward to use. With a good GUI (try TortoiseSVN), it's so easy you almost forget its there. Seriously, use SVN. There's no need to come up with 'clever' alternatives.
Its not a good idea, especially if you push this into production. If you want "cheap" version control, download VisualSVN. Its free.
The guys at Yahoo use a technique that reminds me of what you describe:
<link rel="stylesheet" type="text/css" href="http://l.yimg.com/a/combo?arc/yui/reset_2.6.7.css&arc/yui/fonts_2.6.4.css&[....]/subfooter_0.0.12.css" />
It makes sense for them because it's a caching tecnique. They set HTTP headers so stuff never expires: if you load the site one year later and you haven't removed your browser's cache, you shouldn't need to fetch again any of the files that haven't changed.
However, it's by no means a sensible version control system. You already have a good bunch of real version control systems out there!
I just worked out, by trial-and-error, that IE 7 has an upper limit of 32 stylesheet includes (i.e. tags).
I'm working on the front-end of a very large website, in which we wish to break our CSS into as many separate files as we wish, since this makes developing and debugging much easier.
Performance isn't a concern, as we do compress all these files into a single package prior to deployment.
The problem is on the development side. How can we work with more than 32 stylesheets if IE 7 has an upper limit of 32?
Is there any means of hacking around this?
I'm trying to come up with solutions, but it seems that even if I loaded the stylesheets via Ajax, I'd still be writing out tags, which would still count towards the 32-stylesheet limit.
Is this the case? Am I stuck with the 32-file limit or is there a way around it?
NOTE: I'm asking for a client-side solution to this. Obviousy a server-side solution isn't necessary as we already have a compression system in place. I just don't want to have to do a re-compress every time I make one little CSS change that I want to test.
Don't support IE7.
To avoid confusion: I'm not seriously suggesting this as a real solution.
Create CSS files on the server side and merge all files that are needed for this certain page.
If you are using Apache or Lighttp consider using mod_concat
Write your stylesheet into an existing style block with JavaScript using the cssText property, like this:
document.styleSheets[0].cssText += ourCss;
More info here:
https://bushrobot.blogspot.com/2012/06/getting-around-31-stylesheet-limit-in.html
At my last company we solved this by mashing all the CSS into one big document and inserting a URL in the web page that referenced that one-shot document. This was all done on-the-fly, just before returning the page to the client (we had a bunch of stuff going on behind the scenes that generated dynamic CSS).
You might be able to get your web server to do something similar, depending on your setup, otherwise it sounds like you're stuck with only 32 files.
Or you could just not support IE7 ;)