in reply to Title Re: collapsing revisited

A very good effort; I've just recently started going through my writeups and collapsing anything with more than double "Re:"s. My interjection is that I prefer the "Re^3:" style collapsing - but if collapsing happened automatically, I would likely not care enough to edit the node title. A bigger concern is that your code would break apart where it encounters a "Re^X:". It should probably try to match not /Re\((\d+)\):/ but rather something akin to /Re.(\d+).?:/.

Makeshifts last the longest.

Replies are listed 'Best First'.
Re: Re: Title Re: collapsing revisited
by Dog and Pony (Priest) on Jun 08, 2002 at 15:55 UTC
    Yep, jeffa pointed out a similar example ("2Re: "). That is another good reason to have it as a user setting. It isn't meant to enforce a style upon someone, after all...

    The solution would probably be to be able to set which style you prefer for out put, then have the engine look for all those cases and transforming them.

    I might take a stab at it later, but for adding that extra complexity, it would have to be both viable to do, and enough people that wants it.

    I had seen a few posts with Re^2 and friends, but I didn't think they were that common (plus this is more of a draft and first example). If we can have all the ways, I'm all for it. :)

    Personally though, I find the Re^2: style harder to read, even though perhaps more logically correct. :)


    Ok, I took the challenge. Following here is a new version, that handles both types (though not the "2Re:" style, at least not yet). It is about time to start refactoring though, it would seem, as it is getting really hairy. As a demonstration though, it will serve I think.

    Now we have some new subs, instead of the old ones, we call the same ones with an added _caret for the "Re^2:" style, and _paranthesis for the "Re(2):" style. This goes for both re_collapse_* and re_add_*. As an added bonus, it will also translate from one type to the chosen one, so you can have it all your style.

    Given this approach, and some refactoring, it should be possible to add yet more types. I'm not 100% sure this will hold for every possible case, but the tests I do have seems to indicate it would hold for most stuff.

    It also has removed the $& as was pointed out though I din't understand why at first... doh. :) But then, is @- and @+ free from this? I hope so.

    Anyhow, here it is - enjoy: