comment #7:

> I suspect that the white space will transform in
> renderer-specific way when being copied.

Fair point.

> I don't think any users regularly want to extract an exact
> copy from tracker comments; we don't support that.

Also fair, though I don't think this is communicated to users, who generally expect copy/paste to work everywhere on modern desktops.

> Agreed, both are wrong; but what really matters is that
> nobody has come up with a clear way to improve that.

...yet!  I remain optimistic. :-)

comment #5:

> comment #4:
> > there is a competing interest for verbatim blocks on whether they should look right in the browser, or copy correctly for later pasting.
> Copying is supported via the 'Quote' button; using browser facilities will lose many features like links, lists and so on.

Links, lists, and the like aren't relevant to verbatim blocks, the scope to which I limited comment #4.  Shell commands, code snippets, and patches -- the likeliest things to want to be pasted -- are often placed in verbatim blocks.

While the label "Quote" makes the purpose of the button a little unclear to the uninitiated, anyone who's used the savannah tracker knows Quote as a button for formulating replies within the tracker.  There is no indication to the user, nor (I strongly suspect) any widespread expectation, that "Quote" is required for copy/paste to work correctly, especially in verbatim blocks.  In fact, the button is particularly ill suited for this, as the quoted material gets a > prepended to each line, making it far less useful for copying than the text as displayed in the browser.  I'd be very surprised if any savannah users regularly hit Quote, edit out all the >'s, then select the text they want, rather than just highlighting it directly from the displayed comment.

> Yes; the other options I can see are:
>
> * leave tabs as is, and the browser will condense them to a single space;

This appears to be what is done outside verbatim blocks.  I'm not sure it's clearly the worse of the two systems demonstrated in comment #0: in neither case are the g's vertically aligned, so visually the two systems are just wrong in different ways.

But solving the visual problem and solving the copy problem may be mutually exclusive, so, if any changes are to be made, there might need to be a decision on which is deemed more important.

> * replace every tab with a single non-condensable space.

Agreed, I see no advantage to that approach.

On further thought, there is a competing interest for verbatim blocks on whether they should look right in the browser, or copy correctly for later pasting.

Viewing source on the original submission shows that the non-verbatim area has tab characters in the source (which the browser is condensing to a single space, a rendering decision that is arguably within the browser's purview), while the verbatim area has only sequences of " "s, which means savannah is altering the tabs that the user entered.  But it is doing this by converting each tab to a fixed number of spaces, which doesn't seem to serve either use case: it will never copy/paste as tabs, and it will often not display correctly in the browser, except in cases where every tab character happens to appear at a tab stop.

comment #1:

> I have no idea how this could be implemented in a simple way.

This could be implemented in terms of placing &#x09; (ASCII tab) in an HTML <pre/> tag.

Tab characters in bug comments do not behave the way users are used to tabs behaving in most other contexts.

In regular text, tabs are displayed as single spaces:

a g
abc g
abcdef g

In verbatim text, they are displayed at a fixed width rather than making the things after them align:

a        g
abc        g
abcdef        g

In both cases the tabs display as expected in the textbox when entering the comment, but not when it's previewed or rendered.

In verbatim text especially, which often includes code snippets (where tabs are sometimes used to align elements), it seems tabs ought to display the way they do in most terminals and text editors.

Thanks for considering this.