Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Package description parser interprets curly braces in the description field #774

Closed
bos opened this issue May 24, 2012 · 2 comments
Closed

Comments

@bos
Copy link
Contributor

bos commented May 24, 2012

(Imported from Trac #784, reported by guest on 2010-12-29)

If you have a description like this:

description: Here is some C code:
             .
             > for(i = 0; i < 100; i++){
             >   printf("%d\n",i);
             > }
             .
Cabal will strip out the brackets. You can use @..@ syntax with &#123; and &#125; except that then the whitespace is off in your code block and you have to escape any symbols that haddock knows. Putting a blackslash () in front the braces does not help.

The above example works fine in plain haddock leading me the conclusion that cabal is eating the braces.

@manzyuk
Copy link
Contributor

manzyuk commented May 3, 2013

Braces play a special role in .cabal files as they delimit sections and branches of conditionals. They are stripped by the parser as soon as the boundaries of sections / branches have been figured out. One could augment the tokenizer so that the lines beginning with '>' are left intact. I tried that and this fixes the above example.

Is it a good / right way to fix this issue? Am I overlooking anything?

This change doesn't fix stripping of the curly braces in code blocks delimited by @...@, which haddock seems to handle fine. I suppose this could also be fixed by changing the tokenizer.

@23Skidoo
Copy link
Member

23Skidoo commented May 3, 2013

@manzyuk

One could augment the tokenizer so that the lines beginning with '>' are left intact. I tried that and this fixes the above example.
Is it a good / right way to fix this issue? Am I overlooking anything?

Please submit a pull request, and we'll take a look at it.

@ttuegel ttuegel added this to the _|_ milestone Apr 23, 2015
@ttuegel ttuegel changed the title Cabal strips out { and } in literate code blocks of the description field Package description parser interprets curly braces in the description field Apr 23, 2015
phadej added a commit to phadej/cabal that referenced this issue Aug 17, 2017
phadej added a commit to phadej/cabal that referenced this issue Aug 17, 2017
@phadej phadej closed this as completed in c34debf Aug 18, 2017
phadej added a commit that referenced this issue Aug 18, 2017
Add regression test. Resolves #774
@phadej phadej modified the milestones: 2.2, Aug 20, 2017
@phadej phadej moved this from todo to done in Parsec Parser Aug 20, 2017
lyokha added a commit to lyokha/cabal that referenced this issue Aug 27, 2022
Note that this commit modifies regression check for issue haskell#774.
jneira pushed a commit to lyokha/cabal that referenced this issue Aug 30, 2022
Note that this commit modifies regression check for issue haskell#774.
Mikolaj pushed a commit that referenced this issue Aug 31, 2022
* Remove warning on option -threaded when building libraries

Fixes #8431. Accompanied by option -flink-rts, option -threaded defines
the flavour of the ghc RTS library the built library will be linked
against. Note that bare ghc does not warn when option -threaded is used
for building a library either.

* Cabal no longer warns on -threaded option when building libraries

Note that this commit modifies regression check for issue #774.

* A small changelog was added
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Development

No branches or pull requests

6 participants