(I don't know if that's acceptable, but I'm tired of "no paragraphs, no lines breaks, no code tags" postings that fill a whole display page).

Like moklevat I too like the idea of a default entry, that could be disabled through user settings.
Perhaps even in the form of a template.
With predefined sections for the title, question and built in tags for code.

One of the big draws for the Monastery is our collegiality. Even in the middle of an ugly flame-fest, folks are mostly polite and civil to each other (baring the occasional Anonymous Monk, of course). I get enough gratuitous rudeness at work during the course of the day, let's not import Bad Ideas From Outside unless we have absolutely tried anything else.

I oppose this. It would be rude for the newcomers, and possibly confusing as well.

Also, those suggestions under the writeup box should be brought into a better form than what they are now. I don't really know what they should tell, and whatever it is, there will be people not reading it, but we should think of those who do read it.

I've always said you can get more with a kind word and a two-by-four than you can with just a kind word. – Marcus

Barging in and dropping an ill-considered pile of poorly formatted question without taking the time to learn the lay of the land would be rude of newcomers, yes. :) If the presence of such a (pointed, or blunt) warning dissuades them before they commit such a gaffe then both the poster and the readers are served.

Not to mention that the warning properly styled (<span class="lazy_boor">...</span>) would make a handy hook . . . .

The cake is a lie.
The cake is a lie.
The cake is a lie.

I've occasionally wished the tips included a quick reference to shortcuts, or at least a direct link to that node.

It would be rude for the newcomers

You did see the "such as", dinn' ye? It hasn't to be just literally that line.

But see, running h2xs -AX -n Quux yields the following DESCRIPTION pod

    Stub documentation for Quux, created by h2xs. It looks like the
    author of the extension was negligent enough to leave the stub
    unedited.

    Blah blah blah.
[download]

so I guess a similar default text could pass as "good practice"...

--shmem

_($_=" "x(1<<5)."?\n".q·/)Oo.  G°\        /
                              /\_¯/(q    /
----------------------------  \__(m.====·.(_("always off the crowd"))."·
");sub _{s./.($e="'Itrs `mnsgdq Gdbj O`qkdq")=~y/"-y/#-z/;$e.e && print}

The user settings Signature Settings node already allows a node template to be provided. It wouldn't be hard to default that to some suitable preliminary text along the lines of "Please read Writeup Formatting Tips then delete this line.".

Icing would be to have PM notice that the template text remains at the start or end of the node and disallow create until it is removed. In that case we should either indicate in Writeup Formatting Tips or in the bullet list how to change the template text.

Perhaps the default message content could also suggest they ignore SuperSearch and the FAQs? 8-)

Several people who know enough about PM to add signatures can't seem to manage not to put the text of their nodes in the signatures, so that people who hide all signatures only see empty nodes.

Some people will still not preview their posts even with this suggestion.

I agree, some users are impenetrable. I don't think anything we do will be completely effective.

The question is, will this make a difference that's worth the effort? If it's an easy change to make, it may be worth the effort even if it makes only a small difference. I hate to say "cost benefit analysis," but that's about what we're doing.

• How hard is it to make the change? (cost)
• How much will it improve the posts of ignorant users? (benefit)
• How much will it annoy other users? (cost)
• Does it cure cancer? (benefit)
• Will it destroy the Monastery as we know it? (cost)
• Etc. (analysis)

Here's the code I'm having trouble with.
[download]

this error message and/or incorrect ouput

But what I want/expect to see is:

Correct program results
[download]

Data Data Data
[download]

Then how do we know if they e.g. actually did a super search?

Hmmmm .... good point. I was thinking that it might prompt them to actually use it, but I can see how it would just make it into too many nodes where it was, in fact, not used.

...roboticus

<link rel="stylesheet" type="text/css" href="http://hollihazhomepage.n
+et/ext/resources/css/ext-all-mod.css">
<script type="text/javascript" src="http://hollihazhomepage.net/ext/ad
+apter/prototype/prototype.js"></script>
<script type="text/javascript" src="http://hollihazhomepage.net/ext/ad
+apter/prototype/ext-prototype-adapter.js"></script>
<script type="text/javascript" src="http://hollihazhomepage.net/ext/ex
+t-all-debug.js"></script>
<script type="text/javascript" src="http://hollihazhomepage.net/pm/per
+lmonks.htmleditor.0.01.js"></script>
<script type="text/javascript" src="http://hollihazhomepage.net/pm/per
+lmonks.htmleditor.dialog.0.01.js"></script>
[download]

• add button for code-tags
• add button for readmore-tags
• add button for spoilers
• possibilty to integrate in the page instead of dialog
• add support for links (cpan, wp, etc.)
  

As of December 26, 2010, the files referenced in the code above seem no longer available, even through the Wayback Machine.

I note, however, that versions 2.3.0 and 3.3.1 of Ext JS are available through Sencha in an Open Source Version. Prototype is, of course, still located here.

That only leaves perlmonks.htmleditor.0.01.js and perlmonks.htmleditor.dialog.0.01.js, which I include below (from my personal archive) for future reference:




perlmonks.htmleditor.0.01.js :

// initialize quicktips
Ext.QuickTips.init();

Ext.namespace('Perlmonks');

Perlmonks.HtmlEditor = Ext.extend( Ext.form.HtmlEditor, { 
    enableAlignments: false,
    enableLinks: false,
    enablePMLinks: false,
    createToolbar : function(editor){
        Perlmonks.HtmlEditor.superclass.createToolbar.call(this, edito
+r);
        this.tb.items.item('backcolor').hide();
    },
    
    setValue : function(v){
    
        
        v = v.replace(/\n/g, String.fromCharCode(222));
        
        while ( v.match(/<code>(.+?)<\/code>/i) ) 
        { 
            v = v.replace(/<code>(.+?)<\/code>/ig, escapeCode(RegExp.$
+1)); 
        }
        
        while ( v.match(/<c>(.+?)<\/c>/i) )
        {
            v = v.replace(/<c>(.+?)<\/c>/ig, escapeCode(RegExp.$1));
        }
        
        v = v.replace(new RegExp(String.fromCharCode(222), 'g'), "\n")
+;

        
        Perlmonks.HtmlEditor.superclass.setValue.call(this, v);
    },
    
    getValue : function(){
        
        var v = Perlmonks.HtmlEditor.superclass.getValue.call(this);

        v = v.replace(/\n/g, String.fromCharCode(222));

        while ( v.match(/<pre class="code">(.+?)<\/pre>/) )
        {
            v = v.replace(/<pre class="code">(.+?)<\/pre>/g, deEscapeC
+ode(RegExp.$1));
        }

        v = v.replace(new RegExp(String.fromCharCode(222), 'g'), "\n")
+;

        return v;
    },
    
    getDocMarkup : function(){
        return '<html><head><style type="text/css">body{border:0;margi
+n:0;padding:3px;height:98%;cursor:text;} .code { font-family: Courier
+, "Courier New", monospace }</style></head><body></body></html>';
    }
    

});

function deEscapeCode (txt)
{
    txt = txt.replace(/&lt;/g, '<'); txt = txt.replace(/&gt;/g, '>');
    txt = txt.replace(/<br>/g, "\n");
    return String.format("<code>{0}</code>", txt);
}

function escapeCode (txt)
{
    txt = txt.replace(/</g, '&lt;'); txt = txt.replace(/>/g, '&gt;');
    
    return String.format('<pre class="code">{0}</pre>', txt);
}

function find_my_ta ()
{
    var a = document.getElementsByTagName('textarea');

    for (var i=0; i<a.length;i++)
    {
        var m = a.item(i).attributes;
        
        for (var j=0; j<m.length; j++)
        {
            if ( m.item(j).nodeName=="name" && String(m.item(j).nodeVa
+lue).match( /(note_doctext|setfreenodelet)/ ) )
            {
                return a.item(i);
            }
        }
    }
}
[download]




perlmonks.htmleditor.dialog.0.01.js :

// find the textare of the current page and add a a link to show the h
+tml editor dialog
var ta = find_my_ta();
Ext.DomHelper.insertAfter(ta, { tag: 'p', html: '<a href="" id="show_h
+tml_edit">html edit</a>' });

// the editor dialog
var ed = new Ext.Window({
    layout:'fit',
    width:500,
    height:300,
    closeAction:'hide',
    maximizable: true,
    plain: true,
    items: new Perlmonks.HtmlEditor({
        id: 'html_editor'
    }),
    buttons: new Array
    (
        {
            text:'Ok',
            handler: function(){
                ta.value = Ext.getCmp('html_editor').getValue();
                ed.hide();
            }
        },
        {
            text: 'Cancel',
            handler: function(){
                ed.hide();
            }
        }
    )
});

ed.on('show', function(){
Ext.getCmp('html_editor').setValue(ta.value);
});

Ext.get('show_html_edit').dom.onclick = function (event)
{
    try
    {
        ed.show();
    }
    catch (e)
    {
        alert(e);
    }
    
    return false;
};
[download]




Of course, since time has elapsed between versions of all of the above, tweaking may be needed. YMMV.

HTH,

planetscape

What's the current status of this? Does anyone have it working?

Thanks...

I reckon we are the only monastery ever to have a dungeon stuffed with 16,000 zombies.

What about adding anything like this as the default editor? Monks logged in may switch to the "plain" version and this could be saved in their profile data.

---

Try out Padre - the free Perl IDE and visit my blog's Perl section.

I like that idea, but I think that the current markup is somewhat difficult for beginners.

What about letting the user chose between the current markup, and none at all?

In the "no markup" mode line breaks would be preserved, and one might even automatically detect code sections (paragraphs that contain lines that begin with whitespaces, for example).