The Tar Pit

I suspect this will stir some sideways looks¹, given that:

mp_en_viaje: re http://logs.ossasepia.com/log/trilema/2019-10-23#1947933 leaving aside how it belonged in the orig thing, not as an afterthought, and focusing on the znc -c thing : there is a GREAT advantage of www-for-config over command-line-for-config that can not be underscored enough :
ossabot: Logged on 2019-10-23 19:59:48 asciilifeform: mp_en_viaje: if after all you dun need a znc , leave the thing switched on, i'ma reformat when next test pilot volunteers, until then will run trb , i want proper test of trb perf on apu1. but if you decide you want a znc, su znc ; znc -c will run promptistic configurator. then reboot, and you'll have it.
mp_en_viaje: www permits you to select, visually, a few target spots in a sea of possible target spots with default populations ; command line takes you through a serialization of the same thing.

While I definitely don't dispute this, let's consider a couple of things. First, that web browsers are absolutely terrible for editing long texts, i.e. anything over 500-word. For example if I want to scroll at the bottom of the post, I'm stuck moving my hand to the mouse and clicking around, while in vim the whole thing would reduce to a simple "esc" followed by a "G", while in emacs that's a "M->" or whatever. Not only that, but if I somehow run into the bad luck of my internet connection failing exactly when I press "save draft", then all my modifications will vanish into thin air, as if I'd never spent some considerable amount of time to write/edit some blogpost.

Second, that some of us are afflicted with this... how shall I call it, this mental disease which impinges techies to spend most of their lives in CLI/TUI² environments. And not only this, but their environment is driven by muscle memory trained over years, which makes it somewhat of a nightmare to switch from e.g. emacs to an in-browser editor.

Moreover, given that it's possible to script MP-WP database population, let's consider that said techies had a tool which allowed them to grab a particular post from the server directly into their emacs, edit it, then push the new version back. That'd be pretty cool, don't you think? I mean sure, I can't speak for others, but that would and indeed does improve my productivity quite a bit -- I haven't thoroughly evaluated what this "bit" means, but my time is probably cut in half just by working inside a plain text buffer instead of the admin interface.

Now what if our plain text MP-WP article looked like this:

---
ID: 336
post_author: spyked
post_title: Decoupling MP-WP post editing from the WWW interface
post_category: tech
post_status: draft
---

I suspect this will stir some sideways looks, given that:

...

Wouldn't that be cool? I might be getting a bit overexcited about this, but anyway, in my transition to MP-WP I've cooked up these two scripts, mpwp-get-post.php and mpwp-update-post.php, that can be used to, respectively, grab MP-WP posts in a so-called "plain-text editable" format and then update/add texts written in the same format to a MP-WP blog. My workflow then becomes:

$ cat template.txt
---
post_author: spyked
post_title: Decoupling MP-WP post editing from the WWW interface
post_category: tech
post_status: draft
---

$ php ~/wpworks/mpwp-update-post.php -n template.markdown
Inserted new post with ID 336.
$ php ~/wpworks/mpwp-get-post.php 336 > 336.markdown
$ emacs 336.markdown
... editing occurs here
$ php ~/wpworks/mpwp-update-post.php 336.markdown
Updated post 336.

then I can go to http://thetarpit.org?p=336 to preview the draft. Yes, I know I still need a login session cookie in order to be able to preview, but at least I've gotten rid of that annoying Firefox editor box.

Examined in more detail, all this does behind the scenes is to call wp_insert_post to insert a new WP-WP database entry, wp_get_single_post to grab it and wp_update_post to update it. Add to this some support for displaying/parsing and command-line processing and you get the scripts above.

The two scripts are available as a V patch, mp-wp_post-editing-tools.vpatch (seal), which places them in the wp-tools directory. Note that these are actually general-purpose tools for interacting with MP-WP posts, so you can use them for other stuff, e.g. mass post update, if you want to. Anyway, if anyone else wants to use these and doesn't know where to start, don't hesitate to write in!

Post blogum: Lately I find myself sorely missing the old btcbase V patch viewer; so in light of recent discussion about what a Vtron should or shouldn't contain, I'm wondering if it'd be worthwhile to have a minimal tool that takes a V tree and spits a representation of it in ASCII form, à la "pstree". v.pl already comes with a "graph" command, but that one requires Graphviz, which insists on pulling a shitload of dependencies on machines where I'm using V. On the other hand I entirely see the merits of pretty graphical representation e.g. as a web page, given that this enables folks to also explore each patch with a simple click in addition to looking at the V tree.

I don't know, so I'll just leave this here for future reference.

Filed under: computing.
RSS 2.0 feed. Comment. Send trackback.