This is sort of an inherent problem when dealing with Sass, because it's placed in the public folder so it can be served statically. One way that might cut down on time a little is to have a ./script/console session open and run "Sass::Plugin.update_stylesheets" instead of accessing a view over and over again. If you just want to check for errors, "./vendor/plugins/haml/bin/sass --stdout public/stylesheets/sass/style.sass" will print the result (or error) directly to the console, although it won't actually update the stylesheet.
- nathan Robin wrote: > I converted my project (about a dozen css files in all) to Sass over > the weekend and it's working great! > > However, I'm not sure I'm going about debugging in the best method > possible. If there's a syntax error in my .sass file, the CSS doesn't > render. Firebug doesn't show the source, presumably because it does > its own formatting and ignores the comment. > > So, what I do is open a new tab directly to the generated .css file, > review what's wrong, save my file and reload it again. Since Sass > doesn't regenerate the css unless you request an action, I can't > reload the tab with the generated css file, I have to switch back, > reload, then back to the source tab and reload that again if > something's wrong. > > While it's not the worst debugging system in the world, I wonder if > there's a better way to do it? > > > > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Haml" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/haml?hl=en -~----------~----~----~----~------~----~------~--~---
