On Mon, Jan 19, 2009 at 2:24 PM, Janet Swisher <[email protected]> wrote:
> On Mon, Jan 19, 2009 at 8:28 AM, Tarantula
> <[email protected]> wrote:
>>
>> Hello, I've spent many hours with this problem and I want to share if
>> someone have the samee, I don't know if this solution will be commited
>> to some revision, by the way:
>>
>> I'm including a python file with:
>>
>> .. literalinclude:: file.py
>>
>> But the syntax highlight never worked, so I've seen on silent
>> exception on (highlighting.py), on line 148:
>>
>>        try:
>>            parser.suite(src)
>>        except parsing_exceptions, a:
>>            return False
>>        else:
>>            return True
>>
>> The parser was throwing an exception: "syntax error". But the source
>> was not with any syntax error. So I took a look in the code.py to see
>> how the file is open, and I saw:
>>
>> f = codecs.open(fn, 'r', encoding)
>>
>> The problem here, is that codecs.open will always open files in binary
>> mode to avoid data loss, so the automatic "\n" conversion is never
>> done on reading. My file.py is a CRLF (windows) and not LF (unix) end-
>> line terminated, so I have added this line of code in the code.py on
>> line 129:
>>
>> text = re.sub("\r\n", "\n", text)
>>
>> and have imported the "re" module on the head of the code.py file.
>>
>> This line will replace the CRLF with LF, so the parser will not throw
>> the exception and the pygments can do the job.
>
> Interesting. I have not seen the exception, but I have seen a problem
> with :literalinclude: on Windows, where the included code is
> double-spaced in the LaTeX output on Windows. This appears to be due
> to CRLFs in the code output, which are interpreted by TeX as
> double-spacing. This leads to the output being about twice as many
> pages as it needs to be. I will try your workaround and see if it
> helps my problem.

The workaround did help my problem, but not for the reason I expected.
When I looked at the .tex file in an editor that shows line endings, I
found that the lines brought in by :literalinclude: actually had
CRCRLF, not just CRLF. However, the substitution changed that to a
(Windows) normal CRLF, which was then properly treated by LaTeX. I
also now get syntax coloring, which I didn't before, probably for the
reason Tarantula noted.

Here's the patch:

diff -r cd94660a7f73 sphinx/directives/code.py
--- a/sphinx/directives/code.py Sun Jan 18 14:43:29 2009 +0100
+++ b/sphinx/directives/code.py Tue Jan 20 15:28:59 2009 -0600
@@ -10,6 +10,7 @@
 import sys
 import codecs
 from os import path
+import re

 from docutils import nodes
 from docutils.parsers.rst import directives
@@ -124,6 +125,7 @@
         lines = res

     text = ''.join(lines)
+    text = re.sub("\r\n", "\n", text)
     retnode = nodes.literal_block(text, text, source=fn)
     retnode.line = 1
     if options.get('language', ''):

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups 
"sphinx-dev" 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/sphinx-dev?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply via email to