sub handleLinks
{
    for(_test){ goto &$_ if $_ }
    my( $inner, $lastnodeid )= @_;
    my $title;
    my $HLS= getVars(getNode('handlelinks settings','setting'));
    my( $prefix, $nodeloc )= split( /:\/\//, $inner, 2 );
    if($nodeloc){
## change here
        $prefix = $1 if($$HLS{lc($prefix) =~ /^=(\w+)$/);
##
        ($nodeloc,$title)=split(/\|/,$nodeloc,2);
        my $cpantitle=$title || $nodeloc;
        my $escapedname=$query->escape($nodeloc);
        if($prefix){
            if($$HLS{lc($prefix)}){
                eval($$HLS{lc($prefix)});
            } else {
                return "[$prefix://$nodeloc]";
            }
        }
    } else {
       return linkNodeTitle($inner);
    }
}
[download]

C.

This node is no more. Use User Settings instead.

Update: Solved! Well, this is embarrassing: I discovered that the only problem was that I was attempting to retitle a node id that's not editable. ie, I just had the node ID wrong. Note to self: Improve error messages in PM::Mech::Janitor so that such situations are easier to identify! Sorry to bother you all.

On a side note, I have noticed that Inner Scriptorium nodes are not janitor editable either. The message is: "Not an editor editable type". I'm not sure that they need to be janitor editable, but since nodes in most other Monastery categories are janitor editable, an argument could be made that this section should be too.

---------- Original question, already resolved, follows: ----------

It was bound to happen sooner or later. Something's changed on the Janitors node edit page (displaytype=editors) that has broken my Janitor's Thread Retitler's ability to find the 'edit_node' form. Here's an example run, showing the problem:

perl retitle.pl -i 499080 -f "Perl n00b Qusetion" -t "How do I 
capture XML into a variable?" -nop

Retrieving thread for ID=499080
        Found 1 nodes.

Preparing changes.
 There is no form named "edit_node" at 
PerlMonks/Mechanized.pm line 79
Couldn't find 'edit_node' form in get_title.
[download]

I've viewed the raw HTML for the page, and can't see what has changed. Also looking at the PMDev patch history for the editor's displaytype has proven to not be helpful to me.

I'm sure it's something simple, but I guess I need another set of eyes (or maybe castaway could tell me what she's changed that could affect my scraping retitler).

The error message I'm getting seems to be generated by my get_title() method, which is part of the PerlMonks::Mechanized::Janitor class in the PerlMonks::Mechanized module, on display here. Maybe a night of sleep will provide me with the epiphany I need to conquer this minor hickup, but in the meantime if anyone else cares enough to take the time to have a look at it, I'd appreciate any hints.

• Restrict the viewing of edits to nodes, to those that can actually view those nodes (canReadNode).
• Add a flag for the editors to set, if a particular edit is sensitive (eg removing email/passwords).
• Remove the 'history' link from the editors nodelet, and add it to the approval and node status nodelets.
• Create a new superdoc for editors, to view all recent edits made (default currently, the last 50).
• Link to the new doc from the editors nodelet.

My original thought was, why isn't there a way for editors to view all recent edits made? (Sometimes I go through NTC, edit 8 of 20 nodes or so, come back the next day, and wonder what happened to the rest :). I also realised that the edithistory page has been visible to non-editors for a while, yet no link existed for them to look at it.

Original notes:

# Current: Anyone can view the edithistory page (displaytype), for any
+ node
# (including wikis!)
# Only editors can view the actual edit page of any node (or gods)
#
# Should be: anyone can view the edithistory page for any node that th
+ey can
# read anyway
# Anyone can view the actual edit page for nodes they can view, except
+ when
# these are marked private
# Editors have a chance to mark edits as private, should only be used 
+for
# extreme cases such as removing credit card numbers/email addresses
# A edit marked as private automagically sets any previous edits to pr
+ivate.
# These edits are viewable in the edithistory page, but only editors c
+an view
# the actual contents.
[download]

Comments?

C.

Looking at Re^2: Change readonly status of Win32::GUI::RichEdit, I was wondering why the article is so wide in Firefox. (It would seem to be rather normal in MSIE, but that is only because MSIE can wrap text where there is no whitespace, for example, right after a hyphen.) It's that first code snippet, over 160 characters long, that is to blame. It just doesn't wrap.

In case you don't see it like I do, here's a screenshot (for a few weeks, at least).

Apparently, code that doesn't contain a newline, doesn't wrap. See for yourself:

Inserting a newline anywhere in the code, allows the code wrapper to kick in:

Newline inserted at the front:

$mainform->tab->Page4->AddRichEdit(-name=>'articletext',-style=>WS_VIS
+IBLE|WS_VSCROLL,-multiline=>1,-text=>"",-width=>745,-height=>450,-lef
+t=>10,-top=>35,-readonly=>1);
[download]

Newline appended at the end:
$mainform->tab->Page4->AddRichEdit(-name=>'articletext',-style=>WS_VISIBLE|WS_VSCROLL,-multiline=>1,-text=>"",-width=>745,-height=>450,-left=>10,-top=>35,-readonly=>1);

Two lines of code with just a newline between them, but nowhere else:

$mainform->tab->Page4->AddRichEdit(-name=>'articletext',-style=>WS_VIS
+IBLE|WS_VSCROLL,-multiline=>1,-text=>"",-width=>745,-height=>450,-lef
+t=>10,-top=>35,-readonly=>1);
$mainform->tab->Page4->AddRichEdit(-name=>'articletext',-style=>WS_VIS
+IBLE|WS_VSCROLL,-multiline=>1,-text=>"",-width=>745,-height=>450,-lef
+t=>10,-top=>35,-readonly=>1);
[download]

Note that that is all I changed.

Update: Some people don't seem to get what I'm driving at. I think this is a bug. No node with code should ever act like that.

Update: In case your browser/user settings are vastly different than mine, here's a screenshot of this post, showing both what I find normal and not normal.

search.cpan.org is playing up again.. While people in the CB can just regive their links as kobe:// links, stuff already posted in nodes stick to whichever link was used. Would it be possible to have the actual cpan:// handling code work a little more dynamically? This would involve keeping track of whether the URL is actually reachable (I'm not sure if "every time a link is clicked" is sensible here), and redirecting the user to kobes, if it isn't.

The doc:// link could also benefit from this sort of dynamicness, I believe.

Currently I'm envisioning some sort of cron-type job that keeps tabs in the background, so that the link parsing code just has to link to a currently known-working URL.

C.

The following has been copied from the Editors Wiki (with minor modifications) at tye's request, as its intent is to prompt discussion, and that sort of intent is better suited to the Inner Scriptorium.

Happy New Year folks...
Put yourself on the Map -- correction has been considered for editing to linkify some of its text. I oppose doing this for the following reasons: (1) The node is 2.5 years old; if it hasn't been considered for this before, why now? (2) I don't think we should be getting in the habit of linkifying existing posts for people; once started down that road where do we stop? Plus, if the original author wanted links, he would (or should) have put them there him/herself. The node isn't harmed by not having them, it's just not as effective as it could be. But there are a lot of nodes that are less effective than they could be... we don't upgrade the quality of the content of peoples' posted nodes. If there is no significant argument to the contrary, I favor unconsidering this node and opting for inaction in this case. But based on the current consideration vote, I don't feel comfortable acting on my own without conferring with the rest of this clan.

Not all types have code associated to them. Thus 'viewcode' type actions wont do anything useful. For nodes like this the place where code is found is under the relevent display page for type X.

Lets use sourcecodesection as an example. These nodes are "dumb" in the sense that they dont have evaluatable code associated to them. However they do have an overriden display page: sourcecodesection display page and it is there that you would look to change how such a nodetype behaves. Some node types have many overriden display types, some only a few. All inherit a large number of display modes from the node type heirarchy. A good place to inspect this info in a holistic way is via the type tree and more specifically via the types own page.

Incidentally all of this can be seen in the pmdev nodelet. At the top of the nodelet it will say something like

#11911 = strangedoc via strangedoc display page

This node is a response to a question i received via /msg that I figured would be useful to others. Cheers.

de-merphq is borged. If someone unborgs him, then fullpage chat will start emitting server errors.

The root cause is that unpackVars (used by getVars) incorrectly returns undef instead of an empty hash (reference) for empty settings which causes an error in lines 36 and 37 of talkbar.

Please don't unborg de-merphq (or whoever demerphq replaces that with) until someone can fix this bug.

I was looking at the POD in XML/Fling.pm and thinking to myself… that really isn't such a great solution.

There's a new module on CPAN called XML::Genx, which is based on Genx, Tim Bray's library for generating XML.

Genx is a library, written in the C language, for generating XML. Its goals are high performance, a simple and intuitive API, and output that is guaranteed to be well-formed; […] Latest news: In production, carrying hundreds of thousands of subtitles per day; thinking of taking off the “beta” stamp.

Of course, the question is, how many places in the PM codebase use XML::Fling currently? If there are many, migrating directly will be a pain. However, it should be possible to rewrite XML::Fling as a thin wrapper around XML::Genx. Another simpler option might be to just start using them in parallel, going back through old tickers as tuits permit.

I'm making this proposition because I'm pretty sure that Genx will be both safer to use and faster than even Fling. I haven't benchmarked anything yet, but I wanted to know there's any interest before I sink any time into that.