mainSavannah Administration - Support: sr #110582, Bug comments should display tab...

 
 

sr #110582: Bug comments should display tab characters conventionally

Submitter:  Dave <barx>
Submitted:  Mon 13 Dec 2021 01:08:51 AM UTC
   
 
Category:  Savannah trackers - bugs, tasks, etc. Priority:  5 - Normal
Severity:  2 - Minor Status:  None
Privacy:  Public Assigned to:  None
Operating System:  None Open/Closed:  Open
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Thu 30 Mar 2023 12:55:01 PM UTC, comment #9: 


> > nobody has come up with a clear way to improve that.
>
> ...yet!  I remain optimistic. :-)


+1

Ineiev <ineiev>
Site Administrator
Wed 29 Mar 2023 05:14:45 PM UTC, comment #8: 

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. :-)

Dave <barx>
Mon 27 Mar 2023 11:10:00 AM UTC, comment #7: 

comment #6:

>
> Links, lists, and the like aren't relevant to verbatim blocks,


No, and I even tend to agree that the user may expect that browser built-in copying would be more likely to work with verbatim blocks; however, the browser will copy anything, verbatim blocks are just ordinary HTML for browsers, and I suspect that the white space will transform in renderer-specific way when being copied.

> While the label "Quote" makes the purpose of the button a little unclear to the uninitiated...  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.


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

> 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.


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

Ineiev <ineiev>
Site Administrator
Fri 24 Mar 2023 08:55:41 PM UTC, comment #6: 

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.

Dave <barx>
Thu 16 Mar 2023 06:56:33 AM UTC, comment #5: 

comment #4:

> 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.

Copying is supported via the 'Quote' button; using browser facilities will lose many features like links, lists and so on.

> ...savannah is altering the tabs that the user entered.  But it is doing this by converting each tab to a fixed number of spaces,

Yes; the other options I can see are:

  • leave tabs as is, and the browser will condense them to a single space;
  • replace every tab with a single non-condensable space.


Either looks worse to me.

Ineiev <ineiev>
Site Administrator
Tue 14 Mar 2023 10:59:45 PM UTC, comment #4: 

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 "&nbsp;"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.

Dave <barx>
Wed 25 May 2022 03:33:29 PM UTC, comment #3: 

We don't use <pre> in verbatim areas, it would introduce worse issues.

Ineiev <ineiev>
Site Administrator
Tue 24 May 2022 06:21:28 PM UTC, comment #2: 

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.

- <_312743>
Sat 18 Dec 2021 12:40:09 PM UTC, comment #1: 

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

Ineiev <ineiev>
Site Administrator
Mon 13 Dec 2021 01:08:51 AM UTC, original submission:  

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.

Dave <barx>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by ineiev (Posted a comment)
  • -email is unavailable- added by barx (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only logged-in users can vote.

     

    Follows 1 latest change.

    Date Changed by Updated Field Previous Value => Replaced by
    2023-03-27 ineiev Carbon-CopyRemoved 312743 -

    Back to the top

    Powered by Savane 3.13-f8d8.
    Corresponding source code