Have you ever found yourself in the middle of replying to a node just to find that you didn't have the original thread anywhere on screen and had to go looking for it, but there was no direct link to it?

Once the reply has been submitted, it will show those links (when viewed as a singular node):

in reply to Title of node replied to
in thread Title of thread replied in

What would you all think of including them in the reply-auhoring node as well, so you would see not only the node you're replying to, but also a link to its parent and the thread?

Michael

Update:

tye's trick "File -> New window" then Back. will not work on Mozilla either.

Anyway, I don't want a new window. I would like to be able to decide where to open a link just as Abigail-II explained.

I also do not see tye's argument that the inclusion of these links would increase problems for users that click on a link during authoring. If they wanted to do that without considering the consequences, there would already be enough links to choose from in the nodelets etc.

  • Comment on meta-information in reply-authoring node

Replies are listed 'Best First'.
Re: meta-information in reply-authoring node (replying to again)
by tye (Sage) on Jun 10, 2004 at 06:59 UTC

    See Re^3: Jump to head (replying to).

    Update: Replying to a node by adding an update to your node isn't the best choice if you actually want your reply read.

    If your browser doesn't give you the choice to open a window or not then I'd think you want to fix your browser or its configuration.

    If they wanted to do that without considering the consequences, there would already be enough links to choose from in the nodelets etc.

    There is a big difference between a link specificly designed for use during preview and having misc. links on a page while you are concentrating on writing a node. If you take a diversion via one of those links unrelated to your composition work, then you are likely to think and open the link in a new window, though you make a good point; we should probably add <base target="_new"> during previews to eliminate this problem. Thanks for the idea.

    Not wanting to contribe to the frustration of losing something you've been working hard on composing, I won't be adding the link w/o target="_new". My conscience won't allow me.

    But I don't really care to endure the wrath of those who have an undying hatred of target="_new" in all forms (and yet refuse to help themselves, *shrug*), so I doubt I'll add it with target="_new".

    BTW, y'all need to go write a petition or something to have the existing uses of target="_new" removed from PerlMonks. I haven't heard any complaints about any of them (other than the ones I complained about and had changed already), but I'm sure y'all can remedy that.

    - tye        

[reply]
      Not everyone uses Microsoft Internet Explorer. In Opera, for instance, this trick will not work.
[reply]
        That's what this bookmarlet is for: javascript:dT30FfN3b=new Date();void(window.open(location.href,'w'+dT30FfN3b.getTime()))

        C-n + History works well too.

        --
        I'm not belgian but I play one on TV.

[reply]
[d/l]
      tye, now I don't want to fuss with either your conscience nor any wrath you might invite upon yourself :-) , so I won't pursue the original suggestion further. You have however given me another idea that may suit all:

      How about adding these links to the Node Status nodelet or the Node Navigator nodelet or to a still-to-be-created Hierarchy nodelet?

      BTW: thanks for the update/reply tip.

[reply]

        Actually, I think it should be pretty much where and how you proposed (except make it a bit distinctive to help prevent adding to the illusion that the node has already been posted).

        But I've been burned by my cache losing a node I just barely left too many times and still recall how maddening that is. And I've heard several others complain.

        Once the ability to recall your most recent preview gets added, this will reduce the loss in such cases to the changes you made since the last time you push the 'preview' button. But even that isn't something I want to be responsible for increasing the frequency of. Doing so would feel just like I was laying a trap to catch the occasional unlucky sole.

        And it sounds like the target="_new" is much more despised than the link is desired. Since my conscience isn't cleared by the vote, I've got two choices left. The consensus regarding those two choices seems pretty clear at this point.

        I currently predict someone else will add the link w/o target="_new", maybe even test it and not get bitten. [ This was one of those cases where the browser seemed to sense things and would allow me to quickly jump away from previews for weeks or months without problems, lullling me into confidence that I knew not to go "too far" and then, when a lot of work went into a preview and I was particularly pressed for time, suddenly it'd throw away a preview, but only after I'd gone not quite as far as last time so I'd continue to think I could get away with this if I was just a little more careful. Finally one day it was forced to throw away my hard work (around the 5th or 6th time by then, after years) after a single-hop diversion of only a few seconds right after the preview had been fetched. Then I knew there was no "safe distance" and the caching decisions were too chaotic for me to predict (I could still often load cached preview results from several days ago). ]

        But it is still early. I'll wait and see how the signs point...

        - tye        

[reply]

Back to Perl Monks Discussion