Ticket #1691 (closed defect: fixed)
Opened 7 years ago
Last modified 5 years ago
Escape tabs in HTML preview of files
| Reported by: | jyrki@… | Owned by: | cmlenz |
|---|---|---|---|
| Priority: | normal | Milestone: | 0.9 |
| Component: | version control/browser | Version: | devel |
| Severity: | normal | Keywords: | enscript white-space css |
| Cc: | |||
| Release Notes: | |||
| API Changes: | |||
Description
Displaying files where leading (or trailing) white-space matters is broken with the current development version. For example viewing Makefiles is broken because of this.
Adding "white-space: pre;" line to code.css's "table.code-block tbody td" block fixes the problem.
I'm currently using enscript for code highlighting. I'm not sure if the problem exists with silvercity.
Attachments
Change History
comment:1 Changed 7 years ago by cmlenz
- Milestone set to 0.9
- Owner changed from jonas to cmlenz
- Status changed from new to assigned
comment:2 Changed 7 years ago by cboos
On a related note, when no highlighter is used,
the display of C/C++ files containing tabs is
indeed messed up (a tab should be replaced by
the appropriate number of <space> pairs).
comment:3 Changed 7 years ago by jyrki@…
Here's the output from enscript, leading tab characters in the rm lines
<B><FONT COLOR="#A020F0">clean-state:</FONT></B> -rm -f $(<B><FONT COLOR="#5F9EA0">STATEDIR</FONT></B>)/* <B><FONT COLOR="#A020F0">clean-state-%:</FONT></B> -rm -f $(<B><FONT COLOR="#5F9EA0">STATEDIR</FONT></B>)/$*
And here's the Trac's output, also has tab characters in front of "-rm -f ..."
<tr><th id="l75">75</th> <td> -rm -f $(<B><span class="code-keyword">STATEDIR</span></B>)/*</td> </tr><tr><th id="l76">76</th> <td></td> </tr><tr><th id="l77">77</th> <td><B><span class="code-lang">clean-state-%:</span></B></td> </tr><tr><th id="l78">78</th> <td> -rm -f $(<B><span class="code-keyword">STATEDIR</span></B>)/$*</td> </tr><tr>
Now that I think of it, it is true that "white-space: pre;" doesn't allow line wrapping. But replacing every tab character with a static amount of (non-breaking) spaces isn't the right solution either.
comment:4 Changed 7 years ago by cmlenz
But replacing every tab character with a static amount of (non-breaking) spaces isn't the right solution either.
Why? Or, what would be the right solution?
comment:5 Changed 7 years ago by jyrki@…
IMHO, it's better to let the long lines be long. An overkill solution would be to calculate the right amount of spaces to insert. For example in the following expand tabs to 5 and 4 spaces
foo\tbar xyzz\tasdf foo bar xyzz asdf
And well, there is a way to do it in CSS, but it's a butt ugly solution too. Check the first code block of this blog entry (has some other good points of CSS's white-space stuff too).
comment:6 Changed 7 years ago by cmlenz
Python has a string.expandtabs() function built right in, so it's not overkill to implement properly.
comment:7 Changed 7 years ago by jyrki@…
Oh, I'm impressed. Well that's the cleanest solution then.
comment:8 Changed 7 years ago by cmlenz
- Summary changed from code.css should have "white-space: pre;" in code-block cells to Escape tabs in HTML preview of files
comment:9 Changed 7 years ago by cmlenz
- Resolution set to fixed
- Status changed from assigned to closed
Actually, tabs were already being replaced with spaces, but the number of spaces were not configurable.
[1944] adds this configurability. In trac.ini, you can say:
[mimeviewer] tab_width = 4
to configure a displayed tab width of 4.
Anyway, I'm not sure whether this fixes the issue raised in this ticket, as I had suspected that tabs were not getting escaped, when in fact they were. Reopen if you're still seeing a problem here.



The spaces should be replaced by non-breaking spaces. The problem with white-space: pre is that it completely disables line-breaks. If white-space: pre-wrap were better supported, we'd use that. Unfortunately, it isn't.
Can you please paste a snippet of the generated HTML? Maybe it's the tabs that are messing up the display?