doing.still.art

June 24th, 2013

Blogging has still not been my top-priority this past month. I’ve got a few things in the pipeline, though….

So, what have I been doing since, and in light of, my last DOING updates?

  • My new project, a Pmwiki-Trello plugin is looking good, to me.
  • work on the Pmwiki-Bootstrap-Skin has slowed, but gotten some core-features closer to a state I wanted.
    • Want to get the skin into a shape where I can use it for my “vanity” site rework.
    • Possibly, I should finalize the rework FIRST, then look at using the skin.
    • Since neither the site nor rework currently use a CMS.
  • My study of node.js is limping along.
    • Looking into jake – j(avascript m)ake.
    • Which is half the reason I want to use node in the first place – using tools match my code.
  • I am using org-mode for my daily journaling, personal, and freelance.
  • Trying to keep up some activity on the EmacsWiki and PmWiki.
    • Tweaking wiki-notes is a (minor) contribution to a project.
    • This should be part of my thoughts on wiki(s)
  • Day-job remains! I enjoy it, and the company is doing well. We just had our summer picnic on Friday.

doing.art

May 30th, 2013

I’ve been working on a boostrap-theme/skin for PmWiki.

 

It’s beginning to take shape, but there’s a long way to go to make it a “real theme.” (I should note that it was extracted from a ready-to-install PmWiki “kit” with bootstrap in it; I’ve made it standalone, and am enhancing the feature-set and building documentation.).

 

I’ve been learning how to use git, GitHub, (guthub-flavored) markdown, more work with Bootstrap, deep-diving back into PmWiki development, playing with Emacs’ org-mode for journaling, and using Trello for planning.

 

PHP is annoying the !@#!@# out of me, as is GitHub’s wise advice to use relative links in a README.md, but making it impossible to use relative links to files in the wiki.

 

I’m hitting a bunch of tasks on my TODO list.

 

pmwiki.bootstrap.darkstrap.00

test.art

June 1st, 2012

This post is for viewing/testing the PmWiki Markup plugin I’m working on.

NOTHING TO SEE HERE… MOVE ALONG.

The test-area is bracketed with two wp-geshi blocks, with no intervening spaces in the source-markup. This should allow for top and bottom-border testing.

NOTE: wpautop is turned OFF (as it interferes with the (:markup:)...(:markupend:) output).

NOTE: ordered lists had no default formatting under my blog css

Show WP ordered list
  1. * whatever
    1. ** no, seriously
  2. * second main item
  3. * third
    1. ** indent
      1. *** indent further
    2. ** not as far
  4. * fourth
  1. public void main(string[] args) {
  2.  
  3.   //TODO: implement
  4.  
  5. }

toc-float

Links work fine, but CSS is missing
Also, the (hide) click is missing the javascript, so will not work
sigh
hrm, maybe IN THE ORIGINAL it uses JavaScript to even show up
that way, it will degrade to NON-APPEARANCE when the JS is not present (as in the markup extraction)

 

 

monospaced text

public void main(string[] args) {

  //TODO: implement

}

 

sourceblock

uses Geshi, so similar to raw WP geshi, above
However, the link element fails entirely

(:source lang=csharp:)
public void main(string[] args) {

  //TODO: implement

}
(:sourceend:)
public void main(string[] args) {

  //TODO: implement

}

 

URLs

All URLs show up as approved for the markup service, but must still go through approval back in the wiki:

 

http://net.tutsplus.com/tutorials/wordpress/creating-a-custom-wordpress-plugin-from-scratch/
http://wp.smashingmagazine.com/2011/09/30/how-to-create-a-wordpress-plugin/
http://css.maxdesign.com.au/selectutorial/

 

wikiwords

LinkWikiWords ShouldBe Off

[[SpaceWikiWords]] should be off.

LinkWikiWords ShouldBe Off

 

SpaceWikiWords? should be off.

NOTE: that’s also an example of a wiki-link to an unknown (and probably non-existent) page/group

 

 

 

 

This is an example header !!

sub-header !!!

level three !!!!

level four !!!!!

 

Unordered list

* whatever
** no, seriously
* second main item
* third
** indent
*** indent further
** not as far
* fourth
  • whatever
    • no, seriously
  • second main item
  • third
    • indent
      • indent further
    • not as far
  • fourth

 

 

Ordered list

# whatever
## no, seriously
# second main item
# third
## indent
### indent further
## not as far
# fourth
  1. whatever
    1. no, seriously
  2. second main item
  3. third
    1. indent
      1. indent further
    2. not as far
  4. fourth

 

 

link test

->[[http://www.google.com|search]]

XraysMonaLisa

 

XraysMonaLisa

 

this  is a random slashmark
this is a slashmark in singlequotes: ‘’
this is a double-slash in singlequote: ‘\’

 

this is strong while this is emphasized

 

clip lrindent

>>clip lrindent<<
This is some clip text
>><<

This is some clip text

 

 

comment and include test

requires admin permissions, so should not appear

(:comment the below is not rendered due to lack of permissions. hooray!:)
(:include SiteAdmin/AuthUser:)

Hopefully you saw nothing, since the include requires admin permission on the Pmwiki side to view — so it should NOT render

no strange permissions, should appear

(:include PrantedMutter/Ort:)

orts are small and smaller than warts which they are not no not warts are orts.

 

not big, not large, not by half nor in half, less than tiny or small, decidedly not tall, not at all.

  1. public void main(string[] args) {
  2.  
  3.   //TODO: implement
  4.  
  5. }
Ironically, tables are rendered correctly in a normal WP post with wp-autop I’m going to have to look at how the text is returned inside the plugin to keep working on this… It might have to do with plugin priority? The below code was ganked from the source of a render in pmwiki; it should look almost identical to some code above, unles wpatuop is turned on. In which case, the below will be correct, and the above will be a mess.

clip lrindent

>>clip lrindent<< This is some clip text >><< 

This is some clip text

 

 

below is the HTML generated by the conflict of Wp-Pmwiki-Markup and wpautop:
  1. wpautop is turned on:
    
  2.  
  3. <h2>
    
  4. <a id="toc10" name="toc10"></a>
    
  5. clip lrindent
    
  6. </h2>
    
  7. <td<br>
    
  8. class=’markup2′ valign=’top’&gt;
    
  9. <div class="clip lrindent">
    
  10. <p>This is some clip text </p>
    
  11. </div>
    
  12. </td<br>
    
  13. <table class="markup vert" align="center">
    
  14. <tbody>
    
  15. <tr>
    
  16. <td class="markup1" valign="top">
    
  17. <pre>&gt;&gt;clip lrindent&lt;&lt; This is some clip text &gt;&gt;&lt;&lt;

 

 

markup.art

May 31st, 2012

So, I implemented the custom-action in PmWiki last night, and updated the WordPress plugin to match.

This is much, much better, as there is no longer a mostly-duplicated, hacked version of PmWiki floating around.

I still have to handle CSS issues, and interaction with other markup.

I’m looking at the WP-GeSHi-Highlight plugin which has some great notes on avoiding such issues:

– WP-GeSHi-Highlight filters&replaces code snippets as early as possible. The
highlighted code is inserted as late as possible. Hence, interference with
other plugins is minimized.
– If it does not find any code snippet, it does not waste performance by
senseless inclusion of highlighter libraries etc. And it does not send its
css code to the user if not necessary (others do).

This is how the plugin works for all page requests
==================================================
I) “template_redirect hook”:

1) The user has sent his request. WordPress has set up its `$wp_query` object.
`$wp_query` has information about all the content potentially shown to the
user.
2) This plugin iterates over this content, i.e. over each post, including each
(approved) comment belonging to this post.
3) While iterating over the post and comment texts, occurrences of the pattern
<pre args> CODE </pre>
are searched.
4) If one such occurrence is found, the information (args and CODE basically)
is stored safely in a global variable, together with a “match index”.
5) Furthermore, the occurrence of <pre args> CODE </pre> in the original
content (post/comment text) is deleted and replaced by a unique identifier
containing the corresponding “match index”. Therefore, the content cannot be
altered by any other wordpress plugin afterwords.
6) Now GeSHi iterates over all code snippets. For each, it generates HTML code
that highlights the snippet according to the given programming language
(with or without line numbers).
7) Additionally, GeSHi generates optimized CSS code for each snippet. All CSS
code generated by GeSHi ends up in one string.
8) For each code snippet, highlighted HTML code AND the corresponding match
index is stored safely in a global variable.

markup.art

May 30th, 2012

I have a rough-draft version of pm-wiki markup working here in WordPress!


[pmwiki]
!! This is a heading
This is some text

!! This is another heading
Wikipedia:PmWiki
[[http://www.google.com|search link]

[/pmwiki]

generates:

This is a heading

This is some text

 

This is another heading

Wikipedia:PmWiki – Intermap example

search link

 

This is accomplished with a WordPress plugin modeled on FsWiki, and a hacked version of PmWiki that doesn’t perform a page-directive (view) by default, allowing the front-end script to pass text to the markup function.

It is far from perfect — the CSS is wonky*, and I’m sure the PmWiki integration is g-dawful; I need to look into page-directives, see if adding a custom directive is the direction I need to go. Plus, the WP plugin ignores the code-directive, so I had to fudge it to get the example above.

But as a proof-of-concept that was started at 11pm, it only took 1.5 hours.

See original notes.

* The CSS is wonky for this entire blog. I’m no CSS-guru, but I seem to understand it a lot better today than when I pieced this thing together. Just look at how the blockquotes are padded weirdly….

UPDATE: A custom action is the direction I need to take.

wiki.art

May 29th, 2012

Although the progenitor of my having a website, this blog went on hiatus in January 2009, and only returned in April of 2012. That’s a good long break.

In the meantime, I was spending far less time on HTML and more time on dumping links onto pages, writing small amounts of text, and doing only small amounts (by comparison with re-installing WordPress and working on the poorly-designed-website) of bit-twiddling with PmWiki.

I much prefer the PmWiki markup to WordPress’ markup — especially since WordPress has a pseudo-HTML markup (that looks like HTML, but is re-processed invisibly on the backend and transformed in ways you’d least expect.

blah blah visual editor blah blah crap blah blah I miss WordPerfect 5.1 for DOS’s reveal codes blah blah blah

What I’d like is some way to tie the two together better.
One rendering engine for both, media-images use the same warehouse, etc.

The WP FreeStyle wiki plugin adds FreeStyle-wiki markup to WordPress. Nice!
But How?
It installs an entire working instance of FreeStyle Wiki inside of WordPress.

That’s a bit of overkill just for rendering posts.

Plus, I already have a working install of PmWiki — just not inside of WordPress.

So, I have to find some way to get allow WordPress to pass arbitrary text — hopefully with wiki-markup — to PmWiki and retrieve the HTML-ified text in return (and hope that WordPress doesn’t f**k it up).

The FsWiki plugin gives me a quick idea of how to pass off the text to a renderer — it’s getting it to and from PmWiki that concerns me.

Quite possibly not difficult — I just haven’t tried it yet.

MarkupToHTML($pagename, $str)

Converts the string $str with PmWiki markup into the corresponding HTML code, assuming the current page is $pagename.

(source)

Other avenues of research include the TextControl plugin.

  • syndicate

    • Add to MyMSN
    • Add to MyYahoo
    • Add to Google Reader
    • Add to Bloglines
    • Add to Newsgator
    • Add to NewsIsFree