Several people, including me, very much hate node titles that don't give any hint at how deep they are in a thread. A non-"Re" node should be a root note and is usually a question or a proprosal. A "Re:" node should be a reply and is usually an answer. A "Re^2:" is usually quite different than either of the preceeding types of nodes. A "Re^15:" is quite deep in a thread and, at that point, a "Re:" showing up for the same thread means it isn't just more of the same back-and-forth that I've been ignoring.

So part of the point of this patch is to encourage people to stop removing depth indicators that several people find quite useful. The hope is that the quite compact "Re^15:" is not so bothersome as to motivate people to mess with it.

I'd rather the depth in "Re^$depth:" be calculated based on the real depth of the node in a thread, but that requires other changes.

Thanks, demerphq for implementing this.

I'd rather the depth in "Re^$depth:" be calculated based on the real depth of the node in a thread, but that requires other changes.

Its on my todo list on the test site to do it this way. IMO there are some minor issues to resolve as I don't think the logic needed quite meshes with Everythings normal update logic.

Thanks, demerphq for implementing this.

No problem. Now that addnewform and addnewnoteform are somewhat refactored it should be easier to introduce better ways to do this.



---
demerphq


First they ignore you, then they laugh at you, then they fight you, then you win.
-- Gandhi

The depth of a node in a thread is a property of the node, not of its title. Just like with usenet and email, I think that root nodes should be non-Re titled, and so should articles that change the title. The rest should get "Re:", and nothing more.

Abigail (this is my 4000th posting - more worthy as a profound meditation, but I've no interesting subjects to write about at the moment. Perhaps when I reach posting 5000).

>   Perhaps when I reach posting 5000
... so let's see next month!

pelagic

As I said above one of the major advantages of this is that all the code for adding Re:'s to titles (which happens in a few places) has been refactored into a single htmlcode node which can be easily patched by the pmdev crew. So for instance if you pester one of them im sure they could whip up a user setting to do this. Personally, its not on my list though. :-( Sorry.

Put the ^\d+ part inside a <div class="redepth"> and people that didn't want it could make it disappear with div.redepth { display: none; }.

How is that supposed to work? You're forgetting that the Re:s are not generated from the database at display time — the Re:-collapsed form is used to populate the reply form, and HTML is not allowed in the title.

Makeshifts last the longest.

You probably mean <span class="redepth">, since <div> is (at least by default) a block level element.

if it were up to me, "Re: $original_title" would be enough with any reply (even up to a milion levels deep)

Agreed. This reply-marking-for-subject-lines stuff has all been tried every possible way and the advantages and disadvantages of various systems discussed and rediscussed to death over the course of thirty plus years for usenet and email, and the consensus after all that was, just one "Re: " and nothing more, unless the user manually changes the subject line. I was under the impression that everyone on the internet was aware of this, until I came to Perlmonks. Replacing Re: Re: Re: with Re^3: brings us up-to-date with what newsreaders and mailreaders were experimenting with in the 1980s that was subsequently determined to be the Wrong Thing (as eventually codified in the GNKSA).

Yes, I realize Perlmonks isn't usenet, but for all practical purposes the subject lines are doing exactly the same thing, and lessons learned about subject lines there do apply just as well here. Experimenting with alternatives that the rest of the world already tried and rejected is a waste; I wasn't going to say anything about it before because I figured it was something that just hadn't been gotten around to yet, but if we're going to go to the trouble to change the behavior, the behavior to shoot for is the behavior we already know will eventually be determined to be right, I would think.