#4315 closed defect (fixed)
linesep issue causes error when using start or end parameters
Reported by: | anonymous | Owned by: | Chris Heller |
---|---|---|---|
Priority: | normal | Component: | IncludeSourcePartialPlugin |
Severity: | normal | Keywords: | |
Cc: | Trac Release: | 0.11 |
Description
I get errors when trying to show only partial source using the start and end parameters. E.g.
Error: Macro IncludeSource( <snip> , start=13, end=26) failed 'str' object has no attribute 'generate'
It works fine when including the whole source.
I don't know Python so it took me a while to guess it might be related to line endings. I'm testing Trac on Windows with a sync'd svn repository but we mainly use Unix line endings. Hardcoding linesep = '\n' into IncludeSource.py has enabled the correct display of these particular files for my particular instance of Trac, but obviously isn't a proper solution.
(I'm not sure if this is a problem with this plugin or with the way I'm trying to use it. If the latter then sorry for filing this as a defect and please tell me how I should be using it!)
Attachments (0)
Change History (3)
comment:1 Changed 16 years ago by
Status: | new → assigned |
---|
comment:2 Changed 16 years ago by
Resolution: | → fixed |
---|---|
Status: | assigned → closed |
Fixed in changeset:5038.
comment:3 Changed 16 years ago by
Opened ticket:4317 for the case where you actually want to just include one line of source code. There is tentative patch there that has not been committed yet.
Yes, the plugin currently makes the assumption that the files have the same line-endings as the current operating system default (which isn't a good assumption).
Looking more closely at render() in mimeview/api.py I see that render can return a single string with xhtml text. It won't always return an iterable that yields the rendered output line by line. That explains the error message. The line separator problem causes render to return the whole thing as one line, so it just returns a string instead of a generator as it does when there is more than one line.
I'll open a separate ticket for how to handle the case where someone uses the macro and actually expects just one line of output.
For your issue, I think the best approach is to split the content by '\n' instead of the OS specific linesep. We just need to break apart the source into separate lines, and we know that we will have '\n' on both Unix and Windows. The extra '\r' on Windows shouldn't cause issues because we join the split lines together again so each line will have whatever line separator it started with.