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

[cboos]

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.

[cboos]

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

[cboos]

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

[cboos]

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

[cboos]

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

[athomas]

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

[cboos]

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.

[cboos]

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

[cboos]

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.

[cboos]

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

[cboos]

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.

[cboos]

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

Please test & review.

[cmlenz]

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.

[athomas]

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.

[cboos]

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.

[cboos]

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

[cboos]

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

[athomas]

This should be closed no?

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

[athomas]

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

[athomas]

Layout changes

[athomas]

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

[eblot]

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.

[cboos]

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.

[eblot]

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.

[cboos]

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

[athomas]

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.

[athomas]

Fixed in r3374. Sexy!

[cboos]

Reply to description, on top of r3374.

[eblot]

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 ;-)

[cboos]

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.

[cboos]

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

[cboos]

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

[athomas]

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

[cboos]

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

[cboos]

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!)

[eblot]

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

[athomas]

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.

[athomas]

Reply button below heading

[cboos]

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?

[cboos]

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.