yesodweb / shakespeare Goto Github PK

ident parser for "$of" expression allows for alphanum expressions, but docToExp inside Text/Hamlet.hs uses either WildP in case of "_" or hardcoded ConP instead of LitP for strings and numbers which leads to this:

$case num
  $of 1
    (p)Just one
  $of 2
    (p)Two
  $of _
    (p)Lots

Handler/Blarg.hs:32:25:
    Illegal data constructor name: `0'
    When splicing a TH expression:

(code was fucked up by github, but still readable, it uses ``proper'' triangular brackets)

(by ``proper'' I mean that that's the same type of brackets as specified in hamlet spec, but not the type of formatting it makes sense to use in simplified layout language - % as specified in proper haml spec)

my lucius file:

@charset "utf-8";

#content ul
{
    list-style: none;
    padding: 0 5em;
    li
    {
        padding: 1em 0;
        a
        {
            color: #419a56;
            font-family: 'TeXGyreHerosBold',helvetica,arial,sans-serif;
            font-weight: bold;
            text-transform: uppercase;
            white-space: nowrap;
        }
    }
}

generates this:

@charset "utf-8";
#content ul{list-style:none;padding:0 5em}@charset "utf-8";
#content ul li{padding:1em 0}@charset "utf-8";
#content ul li a{color:#419a56;font-family:'TeXGyreHerosBold',helvetica,arial,sans-serif;font-weight:bold;text-transform:uppercase;white-space:nowrap}body{font-family:sans-serif}

@charset should appear at the top only.

Is there a way of inserting newlines into tags such as <pre> and <textarea>?
For example, the following does not have the desired result of 2 separate lines as you would have in regular html:

%textarea
  This is line number 1.
  This is line number 2.

There might be other related issues with preformatted text. I seem to remember that you can insert strings into <pre> you wouldn't be able to insert into normal html...?

Consider the following line:

$foralll item <- list

I would expect to get an error from hamlet such as

Parse error on line 2

Instead I get a TH error

Illegal data constructor name: `l'
When splicing a TH expression:
Data.Foldable.mapM_ (\(l item_0) -> do Yesod.Widget.addHtml

Hamlet doesn't support Tab characters in source files. But when file contains BOTH Tab chars and Unicode (non-ascii) chars, it fails with error message talking about non-ascii character:

Handler\Home.hs:19:50:
    Exception when trying to run compile-time code:
      "<table>
        <tr>
                <td>some text</td>

<ul>
 <li>K.Deniz Y<stderr>: hPutChar: invalid argument (invalid character)

i've uploaded source file to http://freearc.org/download/testing/test.hamlet

I was going to do this myself but it seems that the repo is not up-to-date (Hackage has 1.1.0.2, repo has 1.1.0.1).

Considering that Hamlet found inspiration in Haml and that there is html2haml utility (http://html2haml.heroku.com/), it would be nice to have something similar for Hamlet, iow, something like html2html so that one can easily convert (mostly) html template pages into Hamlet's equivalents.

works fine:
toWidget [coffee|alert "@{AuthR LoginR}"|]

fails when inserted via widgetFile
alert "@{AuthR LoginR}"

DerefBranch (DerefIdent (Ident "AuthR")) (DerefIdent (Ident "LoginR")): expected EUrl

Btw, widgetFile from default yesod scaffold is also broken - no support for coffeescript at all.

I wrote a simple "hello world" style program for shakespeare-js:

{-# LANGUAGE OverloadedStrings #-}
{-# LANGUAGE QuasiQuotes #-}

import Data.Text    (Text)
import Text.Julius

import qualified Data.Text.Lazy.IO as TLIO

shouldBeEscaped :: Text
shouldBeEscaped = "\" + alert('XSS') + \""

foo :: JavascriptUrl url
foo = [js|
    var s = "#{shouldBeEscaped}";
|]

main :: IO ()
main = TLIO.putStrLn $ renderJavascriptUrl (\_ _ -> undefined) foo

It turns out that no string escaping happens at all! This is what the program outputs:

var s = "" + alert('XSS') + "";

Is this a bug, or does shakespeare-js not automatically escape interpolated strings? I'm guessing the latter, based on this sentence buried in the Shakespearean Templates documentation:

Julius allows the three forms of interpolation we've mentioned so far, and otherwise applies no transformations to your content.

This might be intended behavior, but it is extremely worrisome:

• The documentation doesn't make it obvious that no escaping is done. Rather, it suggests the opposite, by vaunting principles of type safety and well-formed content.
• It is inconsistent with Hamlet's #{...} syntax, which does perform the appropriate escaping.
• What if a future version of shakespeare-js does perform escaping of some sort? That would silently break any programs that do their own escaping.

We should use something that looks closer to the actual tag and is more flexible like:

!doctype

Where if we wanted to we could support the different doctypes similarl to: http://slim-lang.com/docs.html

This is a minor issue, but a Lucius rule like this:

li {
    content: ";";
}

will give an error message like this:

(line 365, column 2):
unexpected end of input
expecting "/*", "}", "#", "@" or "{"
checkIfBlock

where the error message doesn't occur until the last line.

The parser doesn't seem to recognize that the semicolon is quoted. I tried "\;" but that has no effect. I believe CSS allows semicolons in strings and also allows backslash escaping (http://www.w3.org/TR/CSS2/syndata.html#characters).

I am using Shakespeare version shakespeare-0.10.3.1.

hello,

i am a newcomer to the haskell world and my primary task was to install hledger but on the way i had to install haskell and all the dependancies.

this is the error message that is displayed when building shakespeare.

$  cabal build 
Building shakespeare-1.0.1...
Preprocessing library shakespeare-1.0.1...
[1 of 2] Compiling Text.Shakespeare.Base ( Text/Shakespeare/Base.hs, dist/build/Text/Shakespeare/Base.o )

Text/Shakespeare/Base.hs:114:40:
    No instance for (Control.Applicative.Applicative
                       (GenParser Char ()))
      arising from a use of `<*'
    Possible fix:
      add an instance declaration for
      (Control.Applicative.Applicative (GenParser Char ()))
    In the second argument of `($)', namely `derefSingle <* delim'
    In the second argument of `($)', namely
      `try $ derefSingle <* delim'
    In a stmt of a 'do' block: xs <- many $ try $ derefSingle <* delim

so i need some guidance to resolve this issue.
the above occurs with either the tarball file or a git clone from this repo.

this is a learning exercise for me so if it is not a bug, dragging me to the answer by pointing to the path of self-discovery is ok. i have not been able to find in the docs/tutorial what this '<*' means. i known that i am not starting from something simple or at the beginning of learning haskell but i have a task to complete and fault finding is my job and process.

i run gentoo linux and have installed ghc 7.4.1 and the following gentoo pkgs

dev-haskell/cabal-1.14.0:0 dev-haskell/cabal-install-0.14.0:0
dev-haskell/http-4000.2.3:0 dev-haskell/mtl-2.1.1:0
dev-haskell/network-2.3.0.14:0 dev-haskell/parsec-2.1.0.1:0
dev-haskell/random-1.0.1.1:0 dev-haskell/time-1.2.0.3:0
dev-haskell/transformers-0.3.0.0:0 dev-haskell/zlib-0.5.3.1:0

and this gist https://gist.github.com/3309502# has list of all the installed haskell pkgs.

regards

john

Using @font-face declarations in Lucius does not behave as expected. An example of font-face usage:

@font-face {
  font-family: 'Whatever';
  src: url(somewhere);
}
@font-face {
  font-family: 'Whatever2';
  src: url(somewhere2);
}

The parser sees a variable declaration for a variable called "font-face {\n font-family" and sets it to "'Whatever'" (I inferred this from the generated CSS; I might be mistaken). The correct behavior should be to bail out on the "{" and leave the selector as-is.

Since shakespeare is mostly quasiquoters and template haskell things, it's difficult for new users to see how to use the code, no helpful type signatures. They could read the book, but I think a few short examples in the haddock are in order.

pull reqs welcome

Consider the following code:

html,body,div,span,object,iframe,h1,h2,h3,h4,h5,h6,p,blockquote,pre,a,abbr,address,cite,code,del,dfn,em,img,ins,q,small,strong,sub,sup,dl,dt,dd,ol,ul,li,fieldset,form,label,legend,table,caption,tbody,tfoot,thead,tr,th,td{border:0;margin:0;padding:0}article,aside,figure,figure img,figcaption,hgroup,footer,header,nav,section,video,object{display:block}a img{border:0}figure{position:relative}figure img{width:100%}

This already minified CSS reset will be ignored if not reformatted in idiomatic cassius style. While this obviously would be more readable if properly formatted, this bug will probably cause beginners some real confusion. Cassius should probably at least issue a warning.

seems that a user is getting a development error message

06:36 < michaelbaker> Hello, I'm on Ubuntu 10.10 trying to compile a yesod app and it's giving me the following error: FIXME cssFileDebug
                      does not support TopVar
06:36 < michaelbaker> What am I doing wrong here?

I get:

    Exception when trying to run compile-time code:
      (line 1, column 1):
unexpected end of input
expecting "#", "@" or "^"

A file with an empty line only (i.e. "\n") works flawlessly.

this sample program:

{-# LANGUAGE TypeFamilies, QuasiQuotes, MultiParamTypeClasses, TemplateHaskell, OverloadedStrings #-}
import Yesod

data HelloWorld = HelloWorld

mkYesod "HelloWorld" [parseRoutes|
/ HomeR GET
|]

instance Yesod HelloWorld where
    approot _ = ""

getHomeR = defaultLayout [whamlet|
Hello World!
<script>
    alert('ok');
</script>
|]

main = warpDebug 3000 HelloWorld

generates this output:

<!DOCTYPE html>
<html><head><title></title></head><body>Hello World!<script>alert('ok');</script></script><//script></body></html>

there should be a single </script> tag.

If you have trailing whitespace after the last argument of $maybe or directly after $nothing a compile error such as this occurs:

(line 38, column 4):\nunexpected \"n\"\nexpecting end of input, \"\\n\" or \"\\r\\n\""

Not sure if the same happens for other command like $if and such...

I don't really like Javascript as a language, and I've grown used to working with Coffeescript. So I am glad to hear that Yesod allows it in place of Julius.

In the scaffold, there is a pre-defined widgetFile function. I like the idea, if the templates have the same name, they get detected together. But .coffee files are excluded, so I tried to make my own:

widgetFile :: String -> Q Exp
#if DEVELOPMENT
widgetFile = widgetFileReload
#else
widgetFile = widgetFileNoReload
#endif

widgetFileNoReload :: FilePath -> Q Exp
widgetFileNoReload x = do
    let h = whenExists x "hamlet"  whamletFile
    let c = whenExists x "coffee"  coffeeFile
    let l = whenExists x "lucius"  luciusFile
    [|$h >> addJulius $c >> addLucius $l|]

widgetFileReload :: FilePath -> Q Exp
widgetFileReload x = do
    let h = whenExists x "hamlet"  whamletFile
    let c = whenExists x "coffee"  coffeeFileReload
    let l = whenExists x "lucius"  luciusFileReload
    [|$h >> addJulius $c >> addLucius $l|]

(cf. this gist)

I have the files default-layout.hamlet, default-layout.lucius and default-layout.coffee in my templates/ folder, but when I start the development server, the generated .js file is empty.

What can I do?

Having text in front of a tag causes conveniences attributes and 'optional' attributes to not work properly. Variable interpolation works, though.

Some text <a .external-link :makeGray:style="color:#AAA" href=#{yahoo}>Go to Yahoo!

The following works fine

<a .external-link :makeGray:style="color:#AAA" href=#{yahoo}>Go to Yahoo!

Another issue I have found, not documented, is using an operator in an $if, like so:

$if (length list) > 2
$if isValid (a+b)

And other examples (with ==) and such... they all produce the error 'Unexpected >' or 'Unexpected =' and so on. Is that intended? If I define a function

let eq = (==)

It works fine, and operators are just functions, so shouldn't that work?

Addition:

$if (length list) `eq` 1

yields the same problem.

The following CoffeeScript fails to compile:

addJulius [coffee|(
    # That's a wrap
    alert "Hi")|]

Take out the quote, or add one, and it works.

Fails on Cassius.hs, 100% cpu usage, gdb returns this:

#0  0x000000010cebf042 in __gmpn_gcd_1 ()
#1  0x000000010ceb8d81 in integer_cmm_gcdIntzh ()

Is it possible to add a clearer error message when mixing tabs with spaces by accident in cassius?
It currently says:

Internal Server Error 
Only LineSingle may have nested content 

Perhaps you could simply add "Did you accidentally mix tabs and spaces?" as a quick fix if that is possible...?

(This is using cassiusFileDebug)

It would be useful to be able to split up a cassius or lucius file into multiple files, as is already possible with CSS. This would be possible by extending @import statement functionality. The user would supply a resolver for @import URLs, and there would be default resolvers that either inserted the referenced files after they are processed into the @importing file directly, or used functionality to create separate files and URLs for the imported files.

An example of what would be valid Lucius code:

foo.lucius:

@import "bar.lucius";
@import "baz.lucius" print;
.foo {}
/* @import statements that aren't at the top of the file are ignored, like in CSS */

bar.lucius:

.bar {}

baz.lucius:

.baz {}

foo.css:

.bar {}
@media print {
  .baz {}
}
.foo {}

(Alternatively, generate CSS files for "bar.lucius" and "baz.lucius" and insert URLs into "foo.css")

E.g. [hamlet|</foo>|] is accepted, which produces "</foo><//foo>".

<!DOCTYPE html> gets changed to a div

I don't quite know how to write down this error, but I hope a few examples explain my problem:

This creates correct CSS:

#contents
    background: white

    p
        text-indent: 0.2in;

    a, a:visited
        color: #aaa
        text-decoration: none

    a:hover
        color: #ddd
        text-decoration: underline

Result is
#contents{background:white}p{text-indent:0.2in;}a, a:visited{color:#aaa;text-decoration:none}a:hover{color:#ddd;text-decoration:underline}

This correct, though not quite what I want and why I would prefer Cassius over pure CSS. But that is another issue ;)
But if I remove that p rule like so:
#contents
background: white

    a, a:visited
        color: #aaa
        text-decoration: none

    a:hover
        color: #ddd
        text-decoration: underline

This creates
#contents{background:white;a, a:visited;color:#aaa;text-decoration:none;a:hover;color:#ddd;text-decoration:underline}

Cassius seems to treat the pseudo-classes as CSS properties and embeds them. Of course, there is an easy work around, just remove the indentation, but then this should be a syntax issue. Since the indentation does not change the semantics in any way, this should be correct.

Also, coming from SASS, I kind of expect Cassius to automatically put #contents to each of the nested rules. Would be nice if it did.

Anyway, hope I was clear on my issue.

Like everyone else, I like to write my HTML on multiple lines. So for example I might write:

<p>
  This is a line.
  This is another line.
  This line is
  broken over two physical lines.

Unfortunately Hamlet renders this text as:

This is a line.This is another line.This line isbroken over two physical lines.

It works if I add a space at the end of the lines, but trailing whitespace is a bad thing.

This makes Hamlet unusable where significant amounts of text are involved, as in my current project.

Is there another way I should be doing this? (I would be averse to solutions that require me to add extra characters, like a trailing backslash etc., as this is terribly ugly.)

I am trying to write some inline hamlet for showing a profile:

getProfileR :: UserId -> Handler RepHtml
getProfileR uid = do
    muser <- runDB $ get uid
    mprof <- runDB $ selectList [ProfileOwnerEq uid] [] 0 0
    defaultLayout [$hamlet|
$maybe user <- muser
    $maybe profile <- mprof
        <p>#{profileName $ head profile} is a #{show $ profileGender $ head profile} #
        $maybe desc <- profileDesc $ head profile
            \ and left us a description:
            <p>#{desc}
        $nothing
        and has left us no description.
    $nothing
        <h1>This user has not yet set up a profile. Please come back later.
$nothing
    <h1>No such Person exists.
|]

It won't compile, and all I get as a Template Haskell error "unexpected nothing". So either $maybes cannot be nested, or I did some mistake with the Hamlet. I read the Book, told me nothing about that. I looked through the source of 'haskellers.com' and found no nested $maybes. If they are not supported, some remark would be nice.

Yeah, that one is quite strange, but it seems that all the and <script> tags are put inside the <title> tag. I have changed nothing in my code, it is from the scaffolded site, only found it strange that my cassius changes never appear. This is the created HTML:

This is the hamlet/yesod version from the hackage, though.
edit: Obivously it is impossible to format HTML code in issues.

A very recent update caused this:

 <script>
     $(function() {
       $(".accordion").accordion({
         collapsible: true,
         autoHeight:  false,                                                                                                                                                                                                                                                                                                
         active:      false
       });
    });

to all of sudden throw an "exception trying to run compile-time code...".

Changing to this:

  <script>
    \ $(function() {
    \   $(".accordion").accordion({
    \     collapsible: true,
    \     autoHeight:  false,                                                                                                                                                                                                                                                                                                
    \     active:      false
    \   });
    \ });

got it working, but I'd prefer to not need the extra escaping.

Any ideas why?

Hamlet doesn't support tuple syntax, i.e. it's impossible to write:

   @?{(ApprovedListR,[("page","1")]}

or

   $with a1 <- (,) (ApprovedListR) ([("page","1")])
   @?{a1}

I get the following error with a snippet of hamlet parsed with [whamlet|..]

Yesod/Widget/Pager.hs:65:8:
    Exception when trying to run compile-time code:
  "
$if (>) m 1
    <div class=#{cssClass opts}>
        <ul>
            $if showFirst opts
                <li.first.prev :p <= 1:.disabled>
                    <a href=#{urlGenerator opts 0}>
                        First
            $if showPrev opts
                <li.prev :p <= 1:.disabled>
                    <a href=#{urlGenerator opts prevP}>
                        Prev
            $forall n <- pageNums
                <li :n == p:.active>
                    <a href=#{urlGenerator opts n}>
                        #{n}
            $if showNext opts
                <li.next :p >= m:.disabled>
                    <a href=#{urlGenerator opts nextP}>
                        Next
            $if showLast opts
                <li.last.next :p >= m:.disabled>
                    <a href=#{urlGenerator opts m}>
                        Last
" (line 6, column 32):
unexpected ":"
expecting ">"

If I switch it to <li.first.prev :(<=) p 1:.disabled> then the error goes away. The error should be that the infix operator is invalid, as a colon-conditional is valid at that location. Note that the column location, 32, refers to the first colon of the conditional.

hamlet seems to build fine with bytestring 0.10 on the current ghc 7.5 head
:)
-Carter

The following CSS fails to parse in Lucius

@keyframes my-anim {
  from {
    color: rgba(125, 166, 182, 1.0);
  }
  to {
    color: rgba(125, 166, 182, 1.0);
  }
}

@-moz-keyframes my-anim {
  from {
    color: rgba(125, 166, 182, 1.0);
  }
  to {
    color: rgba(125, 166, 182, 1.0);
  }
}

Similarly for cassius:

@keyframes my-anim
  from
    color: rgba(125, 166, 182, 1.0)
  to
    color: rgba(125, 166, 182, 1.0)

The error message is:

configuring
[1 of 1] Compiling Main             ( Setup.lhs, Setup.o )
Linking Setup ...
Configuring shakespeare-js-0.11.0...
Flags chosen: test_coffee=False, test_export=False
Dependency base ==4.*: using base-4.3.1.0
Dependency shakespeare >=0.10.3 && <0.11: using shakespeare-0.10.3
Dependency template-haskell -any: using template-haskell-2.5.0.0
Dependency text >=0.7 && <0.12: using text-0.11.1.5
Using Cabal-1.10.2.0 compiled by ghc-7.0
Using compiler: ghc-7.0.4
Using install prefix:
/nix/store/l0fb2xn71m2f6m9lpqhrnd3sf2drnyyz-haskell-shakespeare-js-ghc7.0.4-0.11.0
Binaries installed in:
/nix/store/l0fb2xn71m2f6m9lpqhrnd3sf2drnyyz-haskell-shakespeare-js-ghc7.0.4-0.11.0/bin
Libraries installed in:
/nix/store/l0fb2xn71m2f6m9lpqhrnd3sf2drnyyz-haskell-shakespeare-js-ghc7.0.4-0.11.0/lib/shakespeare-js-0.11.0/ghc-7.0.4
Private binaries installed in:
/nix/store/l0fb2xn71m2f6m9lpqhrnd3sf2drnyyz-haskell-shakespeare-js-ghc7.0.4-0.11.0/libexec
Data files installed in:
/nix/store/l0fb2xn71m2f6m9lpqhrnd3sf2drnyyz-haskell-shakespeare-js-ghc7.0.4-0.11.0/share/shakespeare-js-0.11.0
Documentation installed in:
/nix/store/l0fb2xn71m2f6m9lpqhrnd3sf2drnyyz-haskell-shakespeare-js-ghc7.0.4-0.11.0/share/doc/shakespeare-js-0.11.0
No alex found
Using ar found on system at:
/nix/store/9b3q62czfh5zld9zg2p8sbk65hkbvpzi-binutils-2.21/bin/ar
No c2hs found
No cpphs found
No ffihugs found
Using gcc version 4.5.1 found on system at:
/nix/store/2yghakb86zfivd2da4x1ipcz03xmz6rd-gcc-wrapper-4.5.1/bin/gcc
Using ghc version 7.0.4 found on system at:
/nix/store/jb2rwifgwlknsm99bxhz69gpv25r8nj8-ghc-7.0.4-wrapper/bin/ghc
Using ghc-pkg version 7.0.4 found on system at:
/nix/store/jb2rwifgwlknsm99bxhz69gpv25r8nj8-ghc-7.0.4-wrapper/bin/ghc-pkg
No greencard found
Using haddock version 2.9.2 found on system at:
/nix/store/gccqlrsclnklv5bnk3ix2pj4l6v5ahzv-ghc-7.0.4/bin/haddock
No happy found
No hmake found
Using hsc2hs version 0.67 found on system at:
/nix/store/jb2rwifgwlknsm99bxhz69gpv25r8nj8-ghc-7.0.4-wrapper/bin/hsc2hs
No hscolour found
No hugs found
No jhc found
Using ld found on system at:
/nix/store/2yghakb86zfivd2da4x1ipcz03xmz6rd-gcc-wrapper-4.5.1/bin/ld
No lhc found
No lhc-pkg found
No nhc98 found
No pkg-config found
Using ranlib found on system at:
/nix/store/9b3q62czfh5zld9zg2p8sbk65hkbvpzi-binutils-2.21/bin/ranlib
Using strip found on system at:
/nix/store/9b3q62czfh5zld9zg2p8sbk65hkbvpzi-binutils-2.21/bin/strip
Using tar found on system at:
/nix/store/s0cvbvq23hv4xazpl7srpdm04gs1l78j-gnutar-1.25/bin/tar
No uhc found
building
Preprocessing library shakespeare-js-0.11.0...
Preprocessing test suites for shakespeare-js-0.11.0...
Building shakespeare-js-0.11.0...
[1 of 2] Compiling Text.Julius      ( Text/Julius.hs, dist/build/Text/Julius.o )
[2 of 2] Compiling Text.Coffee      ( Text/Coffee.hs, dist/build/Text/Coffee.o )
Registering shakespeare-js-0.11.0...
Running Haddock for shakespeare-js-0.11.0...
Preprocessing library shakespeare-js-0.11.0...
Preprocessing test suites for shakespeare-js-0.11.0...
Warning: The documentation for the following packages are not installed. No
links will be generated to these packages: ffi-1.0, rts-1.0

dist/build/tmp25510/Text/Coffee.hs:49:5:
    parse error on input `-- ^ backticks means the Coffeescript compiler will pass-through to javascript.'
haddock coverage for dist/build/tmp25510/Text/Julius.hs:   12/22  55%
builder for `/nix/store/w8frp5ybc5qsrfs0ypaggrs87ighzlns-haskell-shakespeare-js-ghc7.0.4-0.11.0.drv' failed with exit code 1

as suggested in the google group: http://groups.google.com/group/yesodweb/browse_thread/thread/abfe006a1573be9d/3ed101295c7fca16?lnk=gst&q=hamlet+foo#3ed101295c7fca16

<ul>
   $for al <- allAuthLevels
       <li>${show al}

However, that fails because it should be $forall, not $for, which causes
the later use of `al' to be undefined.

If this were to fail due to $for being unrecognised, that would be much
better, because it means that version n+m of hamlet files would fail to
compile on version n of hamlet when a new directive has been added. (ie.
better forward compatibility).

More specifically. When /.../ comment is placed at the end of a file yesod-devel errors when page is requested. Is some css is placed after comment error disappear.

Here is minimal CSS file which triggers error.

/* CRASH */

And error message from yesod-devel

Error handler errored out: InternalError "\"/* CRASH!!! */\" (line 1, column 15):\nunexpected end of input\nexpecting \"#\", \"@\", \"/*\", \",\" or \"{\""

[h1.foo#bar]Hello
[h1#foo.bar]World

Second variant works fine, while first one creates [h1 class="foo#bar"] which is invalid class name.

My first scaffolded yesod project: I put the following in my cassius/default-layout.cassius the following:

@font-face
  font-family: "LetsTracebasic"
  src: url(@{StaticR font_LetsTracebasic_otf})

hoping to pick up the LetsTracebasic font, which I'd put in static/font/LetsTracebasic.otf.

The following error resulted:

Error handler errored out: InternalError "DerefBranch (DerefIdent (Ident \"StaticR\")) (DerefIdent (Ident \"font_LetsTracebasic_otf\")): expected CDUrl"

gweber on #yesod suggested I file a bug report.

Other wish-list ideas:

1. a little tool that would warn about missing translations.
2. when creating a new translation, you can not just copy the default .msg
   file. The .msg file contains type annotations that do not belong in the
   other translation files
3. it would be nice if the translation files supported comments so that the
   original translations could be shown in the translation files for the
   translators to reference instead of having to look in two different files
4. a tool that would mark when translations changed in the master file

So, I guess this could all be handled by the same tool. You do do something
like:

$ i18n generate en.msg jbo.msg

And it would create a new jbo.msg translation file that looked like:

-- HelloThere: Hello there!
HelloThere: Hello there!
-- Goodbye: Goodbye
Goodbye: Goodbye

Then a translator could change the messages. (Or leave them the same. For
example, many lines in en-gb.msg might be the same as en.msg).

$ i18n check-missing en.msg jbo.msg

would show constructors that had been added to en.msg but not jbo.msg.

$ i18n update en.msg jbo.msg

would:

a) add missing constructors to jbo.msg
b) mark any translations that had changed

For example, if en.msg changed 'Hello there' to 'Howdy partner' then the
jbo.msg might be updated to:

-- OLD: HelloThere: Hello there!
-- NEW: HelloThere: Howdy partner!
HelloThere: Hello there
-- Goodbye: Goodbye
Goodbye: Goodbye

And the translator can decide if the translation needs to be updated.

Without that information, I think it is pretty hard for translators to know
what to update.. and since the changes could have legal implications, you
don't really want them lost.. Relying on smart tools like git seems overly
optimistic. In my experience, you want to be able to send a single editable
text document with all the information the translator needs and hope they
they manage to edit and send it back with out screwing up the utf-8
encoding. (And then when you get tired of them screwing up the encoding, you
build a website for it so they can just edit it in the browser).

I cannot install shakespeare-1.0.1.2 with GHC 7.4.1:

Text/Shakespeare.hs:118:49:
    Not in scope: data constructor `OccName'

Text/Shakespeare.hs:120:29:
    Not in scope: data constructor `ModName'

Text/Shakespeare.hs:120:52:
    Not in scope: data constructor `ModName'

Text/Shakespeare.hs:123:32:
    Not in scope: data constructor `PkgName'

Text/Shakespeare.hs:123:44:
    Not in scope: data constructor `ModName'

Text/Shakespeare.hs:123:80:
    Not in scope: data constructor `PkgName'

Text/Shakespeare.hs:123:100:
    Not in scope: data constructor `ModName'
cabal: Error: some packages failed to install:
shakespeare-1.0.1.2 failed during the building phase. The exception was:
ExitFailure 1

The use of @import statements in Lucius leads to them being removed. An example @import statement:

@import "test.css";
@import "test-print.css" print;
a.foo {
}

The @import is seen as a variable declaration without an assignment, and is removed from the file.

The message:

    Warning: default newline style has changed, using an explicit $newline is recommended

is displayed every time I use hamlet. That means not just for every template file, but for every use of [hamlet| ... |]. This is getting somewhat annoying.

Hey guys,

Seems that recent commit to hamlet has the Text.MkSizeType module missing, so cabal gets upset. Did we forget the old "git add" or am I missing something?

Many thanks for your help :)