Number Comments

[Schaatser]

Besides the date/time i would like to have a number in the comments, so refering to comments would be easier

[trac@…]

This is easy to do yourself — just the template named ticket.cs. I also make mine give permlinks, so I can point someone directly to a comment with a URL.

templates/ticket.cs

@@ -101 +101 @@
 <div id="changelog"><?cs
  each:change = ticket.changes ?>
   <h3 id="change_<?cs var:name(change) ?>" class="change"><?cs
-   var:change.date ?>: Modified by <?cs var:change.author ?></h3><?cs
+   var:change.date ?>: Modified by <?cs var:change.author ?> <a href="#change_<?cs var:name(change) ?>" title="Permalink to change <?cs var:name(change) ?>">#<?cs var:name(change) ?></a></h3><?cs
   if:len(change.fields) ?>
    <ul class="changes"><?cs
    each:field = change.fields ?>

[Christian Boos]

I elaborated a bit on the above:

Index: htdocs/css/trac.css
===================================================================
--- htdocs/css/trac.css	(revision 2873)
+++ htdocs/css/trac.css	(working copy)
@@ -42,6 +42,19 @@
  color: inherit;
 }
 
+/* Heading anchors */
+.anchor:link, .anchor:visited {
+ border: none;
+ color: #d7d7d7;
+ font-size: .8em;
+ vertical-align: text-top;
+ visibility: hidden;
+}
+h1:hover .anchor, h2:hover .anchor, h3:hover .anchor,
+h4:hover .anchor, h5:hover .anchor, h6:hover .anchor {
+ visibility: visible;
+}
+
 @media screen {
  a.ext-link .icon {
   background: url(../extlink.gif) left center no-repeat;
Index: htdocs/css/wiki.css
===================================================================
--- htdocs/css/wiki.css	(revision 2873)
+++ htdocs/css/wiki.css	(working copy)
@@ -22,19 +22,6 @@
 #overview .ipnr { color: #999; font-size: 80% }
 #overview .comment { padding: 1em 0 0 }
 
-/* Heading anchors */
-.anchor:link, .anchor:visited {
- border: none;
- color: #d7d7d7;
- font-size: .8em;
- vertical-align: text-top;
- visibility: hidden;
-}
-h1:hover .anchor, h2:hover .anchor, h3:hover .anchor,
-h4:hover .anchor, h5:hover .anchor, h6:hover .anchor {
- visibility: visible;
-}
-
 /* Styles for the page history table
    (extends the styles for "table.listing") */
 #wikihist td { padding: 0 .5em }
Index: templates/ticket.cs
===================================================================
--- templates/ticket.cs	(revision 2873)
+++ templates/ticket.cs	(working copy)
@@ -101,7 +101,10 @@
 <div id="changelog"><?cs
  each:change = ticket.changes ?>
   <h3 id="change_<?cs var:name(change) ?>" class="change"><?cs
-   var:change.date ?>: Modified by <?cs var:change.author ?></h3><?cs
+   var:change.date ?>: Modified by <?cs var:change.author ?>
+   <a href="#change_<?cs var:name(change) ?>" class="anchor"
+      title="Permalink to change comment:<?cs var:name(change) ?>">
+    &para;</a></h3><?cs
   if:len(change.fields) ?>
    <ul class="changes"><?cs
    each:field = change.fields ?>

This matches the visual used for Wiki headings (btw, what is the reason for adding those anchors using JavaScript, instead of directly having it in the template?)

The title also suggests the Wiki syntax I'd like to use for refering to comments:

Your comment:0 above.

That link resolver will of course be able to refer to comments of other tickets: comment:ticket:234:0.

[Christian Boos]

Permalinks to ticket comments, plus a wiki syntax for linking to them (comment:<number> or comment:ticket:<id>:<number>). Patch on r2975.

[Christian Boos]

Please review the attachment:ticket_comment_link.diff​, which adds permalink for ticket comments and a wiki syntax for refering to them.

[Christian Boos]

Ah, just thinking about one caveat: attachments can be removed or replaced, so the corresponding change also dissappears and therefore this modifies the change numbers for the subsequent changes. Damn…

[Christian Boos]

To solve this problem, fragment identifiers should be differents for comments and attachments history entries:

• for comment n → ...#comment:n
• for attachment name → ...#attachment:name

[Alec Thomas]

Perhaps the date/time of the change could be the link? eg. 20060419042646 for your last comment, or something slightly more readable like 2006-04-19,04:26:46

[Christian Boos]

As you're example suggests, that would also lead to some ambiguities… like what kind of date format to use (the locale can be modified, the comment will remain written the same).

Also, there's the problem of time conflict between attachments and comments, as described in #2805, so I think it's better to keep something simple (i.e. comment:1), which could be even extended to cover "threads" (i.e. comment:1.2, 2^nd answer to comment:1).

I'm not sure it's worth adding a way to reference attachments in the history, as there's already the attachement: syntax to refer to the real attachment.

[Christian Boos]

Added permalinks for ticket comments and a reply-to comment feature. On trunk@3280.

[Christian Boos]

Try out attachment:comment_permalink_and_reply_to.diff​ which I think implements the permalink and the comment: link resolver adequately.

As a bonus, there's also a [Reply] button for each comment, which will prefill the comment box with the replied to comment text, each line prefixed by '>'. Of course, that's meant to work in conjunction with the citation syntax introduced in #124.

[Christian Boos]

Patch on top of attachment:comment_permalink_and_reply_to.diff​ which uses a button instead of a [Reply] text link

[Christian Boos]

Adding Reply to ticket comments feature on top of r3323, with comment threading within the chronological view (in reply to: … - follow-ups: … … ). To apply, go in your trunk extraction and do patch -p1 < comment_threading-r3323.patch.

[Christian Boos]

New patch uploaded (attachment:comment_threading-r3323.patch​), which add threading to the Reply to feature.

Please test & review.

[Christopher Lenz]

This looks pretty cool now… but I must say don't like the “threaded numbering” you added in the last patch. Why not just number them sequentially? The in-reply-to and follow-ups links, not to mention the cited text, should be more than enough to know the context.

[Alec Thomas]

This is very cool cboos.

I think being able to style the levels would be nice though. Something like class="citation depth1", class="citation depth2" etc.

I also think the thread links in the comment header make it look a bit too "busy", and I agree with cmlenz that the numbering is quite odd.

[Christian Boos]

Well, the threaded numbering is actually used to hold all the necessary information for the in-reply-to and follow-ups links.

But maybe I can come up with a way to hide this internal number from the user interface, and only present a sequential number to the user. I'll have a try.

Alec: sure, I'll add the depth* classes.

[Christian Boos]

New iteration of the patch, taking into account feedback from cmlenz and alect

[Christian Boos]

second round, this time works with IE as well ;)

[Alec Thomas]

This should be closed no?

It might also be cool to add a reply button to the ticket body itself for the initial reply.

[Alec Thomas]

Also I'd like to propose the layout changes attached. What do you think?

[Alec Thomas]

Layout changes

[Alec Thomas]

You can see these layout changes in action at ​#TH413.

[Emmanuel Blot]

Nice feature, although I'm not really fond of the show/hide feature of the "reply" and "submit changes" buttons. It does not fit well with the actual Trac "(look and) feel", I would have voted for static links: I prefer simple GUIs.

[Christian Boos]

alect: your layout is actually exactly what I had in mind, but for some reason failed to achieve ;) Please apply!

About the reply to description: Well, all toplevel comments are implicitely replies to the ticket itself, so there would be no need to add a in reply to: link, but simply get the cited description text, right? I can have a try.

eblot: well, yes, maybe. Let's gather more feedback on this. Also note that this auto-hide feature is only available for Firefox and Opera, IExplorer presents them as static buttons. I simply found that having a button visible for each comment was visually a bit too intrusive. It would be even more so if in the future we add an Edit button to each comment, next to the Reply one.

[Emmanuel Blot]

About buttons: Safari also auto-hides them.

BTW, I did not have a look at the code, but is this feature is built with CSS only, or does it need Javascript?

Yes, the permanent buttons may be a bit intrusive, but the hidden approach brings its own issue: Joe user, who does not know the bit and pieces of Trac and who rarely RTFM, has few chances to know there is a hidden button somewhere in the page. He needs luck to hover the button with his mouse cursor (and this point assumes that he does use his mouse, not the tab key)

IMHO, this is a nice graphic effect, but not a handy feature.

Anyway, this reply feature is great.

[Christian Boos]

CSS only (that's why IExplorer has some problems with it, and the workarounds needed to make this feature work for IE are really unbelievably ugly, cf. ​:hovercraft)

Btw, that made me discover that the permalinks for wiki headings were never shown in IExplorer. So I made them also always visible in IE.

Lastly, Joe user would be really lucky to browse through a ticket without noticing the Reply buttons poping here and there, as the hover area used for triggering the visibility is pretty large… And, well, you know, Joe user probably uses his mouse rather than his keyboard :)

[Alec Thomas]

Committed layout changes in r3373 (though I noticed after committing that the ¶ is now showing up on the left :()

I'm +1 for the :hover buttons as they are now. I tried it with them always visible and it made the page too intrusive, as cboos said.

[Alec Thomas]

Fixed in r3374. Sexy!

[Christian Boos]

Reply to description, on top of r3374.

[Emmanuel Blot]

There are several alternatives to these hidden buttons if they clutter the GUI:

We could use simple text links, we could also use small icons as shown in the Timeline view (with alt. text description) or the ones from the wiki edit area, etc. I guess this is just about personal feelings, but the hidden buttons just don't fit with the rest of the Trac GUI. One of the most important "pro" for Trac is that it shows a really intuitive interface.
Wiki permalink is an advanced feature, which is nice but rarely used. Comment reply is a very important feature, I'm really not sure that hidding it is the way to go. As long as it is pure CSS, it's easy to disable it, so this is not a real issue (but a documentation effort).

cboos: I had to search with the mouse to find a way to reply, because I did not first get that they were hidden button somewhere - I don't use the tab key ;-)

[Christian Boos]

Use unobtrusive static Reply buttons, instead of the auto-hide ones. The patch also contains the reply to description changes from above, adapted to the new style. Patch on r3379.

[Christian Boos]

There's a new attachment:reply_to_description_static_buttons.diff​ which should (hopefully ;) make everyone happy!

[Christian Boos]

Same as above, with a few more fixes. Ready to commit ;)

[Alec Thomas]

Is there some mechanism for linking to ticket comments from outside the ticket itself? (eg. in SandBox, ticket:1#comment:3?)

[Christian Boos]

ticket:1#comment:3 would work if I finish to implement #2168. That would also have the advantage of making it work for InterTrac links.

An alternative (already implemented) is to use syntax similar to the attachment: links, e.g. comment:ticket:2703:3

[Christian Boos]

In r3394, I've committed the last patch, with a few modifications.

This is probably not the final word on the feature's look and feel, but as of now, it's functional enough and follows the Trac look and feel closely enough (i.e. no more auto-hide) so that I think it's safe to close the ticket.

Final thanks to Tim Hatch for having bootstrapped the whole thing (I had ticket comment threading in mind for so long but never got around to actually implementing the thing!)

[Emmanuel Blot]

I did not get a chance yet to try the final version, but thanks for the non-auto-hide buttons anyway.

[Alec Thomas]

I updated to latest trunk and the buttons do indeed look very nice, and also unobtrusive.

However I really, really preferred the button when it was below the heading underline, as it made it very clear which comment the reply was associated with.

Attached patch.

[Alec Thomas]

Reply button below heading

[Christian Boos]

Well, the attachment:reply-below.diff​ looks OK, except:

• there shouldn't be a Reply button for attachments (test for cnum)
• the Reply button from the description should also be put near the top of the description, then

Let's see what others think.

+ some css fixes for IE are needed (randomly disappearing <h3> underline)

[anonymous]

Replying to cboos:

• there shouldn't be a Reply button for attachments (test for cnum)

Why shouldn't you be able to reply to an attachment comment?

[Christian Boos]

It's a limitation due to an implementation detail: attachments comments are currently generated from the list of attachments, the date of the attachment operation is taken into account for interleaving the attachment comments with the other change comments. If the attachment is replaced, the corresponding comment will suddenly move downwards; if the attachment is deleted, the corresponding comment will also disappear.

I felt that this would have been even more annoying than not being able to comment on attachments in the first place. Of course, if we happen to change the way attachment operations are recorded (hint: TracDev/Proposals/Journaling), this limitation will go away.

As a workaround, simply create a new comment and refer to the attachment using the "attachment:" TracLinks, as in comment:29.