(:title:)
in dropdownsThis was a glaring omission!
However, the below code fragment in BBuildGroupList
should rectify the problem:
I would think I shouldn't have to take so many steps.
There's a good likelihood I'm missing something.
Or, it could be that the $page
variable has a funky format due to something else in the dropdown code.
I don't have good screenshots of this in action, since here all the blog-posts are dumped into the same dropdown.
On another (non-public) website I have them sub-divided into months, but the non-ISO format of the page-names means that BlogCal ignores them (that's another item on my long-term TODO list).
With this update, I could revert the page-name formatting back to an ISO date-standard.
It would obviate the fix for now -- but I would like something like BlogCal to use any arbitrary page - and use some other sort of marker for inclusion.
So I'll think about it....
DONE: commit the update to git
DONE: update it here, as well
I want to be able to search both my wiki(s) and my blog(s).
That is - a federated search.
Here are some notes for myself, mainly.
http://www.xradiograph.com/interference/?s=searchterm&feed=rss2
e.g.:http://www.xradiograph.com/interference/?s=gif&feed=rss2
http://codex.wordpress.org/WordPress_Feeds#Search
Using SharePoint FederatedSearch with WordPRess - from 2012. Might have some jumping-off points.
If you don't have aregistry entry under Applications
as below, then you can use ftype
:
ftype JSFile=C:\Program Files\nodejs\node.exe "%1"%*
I made use of the notes here, and then got it to work by trial-and-error, resulting in the following Data value:
"C:\Program Files\nodejs\node.exe" "%1"%*
%*
value is NOT in quotes, and has no space between it and previous double-quote.Without this, the parameters either did not get passed along, or came in with an extra space, and were ignored.
I've been using Geshi
for... years.
I was reading an article today, and particularly liked the look of its inline code:
Turns out it's the default theme of Prism.
I found a few other resources in the meantime if I want to poke around:
http://webdesign.tutsplus.com/articles/25-syntax-highlighters-tried-and-tested--cms-23931
https://github.com/ccampbell/rainbow
Let's say that you're at work, and a number of work-related web-apps just work better in Internet Explorer* so you've made it the default browser.
But you want to open up files from within Emacs inside of Firefox, not IE.
So, how d'ye do it?
That seems to do the trick.
* sigh
So, let's say you want most browser-destined items in Emacs to open in the non-default browser, and you've redefined the Emacs browser, as above.
How do you open certain URLs in the system default browser (because a number of work-related web-apps just work better only work in Internet Explorer*)?
Use open-path-external
-- this will trip the system's default handler for the protocol (http://
in this case).
Yeah, that's right. We're a Windows shop, using a Java application that only works in IE.
OH BRAVE NEW WORLD THAT HATH SUCH PEOPLE IN'T!
The other night I ported some node code to a small web-page.
I showed it off the next day to a friend, and after I hit SEND I though... why are the commit dates from 5 months ago?
I had re-invented my own wheel.
Re-ported it.
Anyway. It meant I was working on the project again, so that's good. I added all the new things I had introduced into the original project, and pushed it over to github.io, finally, as well: http://michaelpaulukonis.github.io/mispelr/
Linting the code for the browser. ("Helloooo, EsLint!"). Cleaning it up. Adding some functionality.
TODO: unit-testing the browser-based JS.
I haven't done this consistently.
I've unit-tested Node, but not the browser, outside of one-off code chunks for a few things.
So. High time I take care of this.
I've used vows
in the past, but will try working with Mocha
http://blog.codeship.com/mocha-js-chai-sinon-frontend-javascript-code-testing-tutorial/
http://kirbysayshi.com/2013/07/01/mocha-tests-node-and-browser.html
http://ariya.ofilabs.com/2013/12/code-coverage-of-mocha-tests-using-istanbul-and-karma.html
http://stackoverflow.com/questions/22201885/mocha-browser-tests-with-node-js-command-line-runner
This is pretty much based on the the one in this tutorial, but with some more annotations, and the mocha
and chai
dependencies pulled from a cdn
instead of being local in the repo.
I know I should be linting, but I just have been... lazy?
Yeah, lazy.
So, I've gotten back to working with eslint - the configurable, pluggable linter for JavaScript.
Here's the .eslintrc
that I'm using at the moment, having fiddled with it only briefly.
I'm working with node.js for utilities, not deployment, so console
statement are okay.
Or, do it via prompts with eslint --init
TODO: Now for the big question - can I integrate eslint into VisualStudio ?!!?
GitHub repo @ https://github.com/MichaelPaulukonis/pmwiki-list-categories
In case things change, as of now, the output above looked like this initially:
Then this, after using the SDV
configs, above:
uses the following css that was added to bootstrap-fluid\css\pmwiki.css
label
-anything. So, what this does, I don't remember.What could I have been doing? Some other experiment?
config.php
integrationTODO: figure out the Markdown bug.
I've got a long list of TODOs and projects that should be taken care of!
Not the least is imlementing things that I've done on a non-publicly-accessible PmWiki site that could/should be replicated here (not nesc. part of the 'kit).
Such as:
See notes and examples @ Blog.2014-08-22
Tag-cloud via Cookbook:ListCategories
Nice li'l tag-cloud. Added to BlogIt sidebar; then to main sidebar.
TODO: what on earth did I change? woo-hoo!
Cookbook:SiteInformation
View-only info at SiteAdmin.Information
The version I'm using here has been heavily rewritten.
TODO: should be added to version control.
My current dropdown code always has a sub-dropdown.
This is great when there is more than one group in a dropdown.
This is... not so greatAWFUL when there is only a single group in the dropdown.
Attach:mandatory.subgroup.png Δ
I want to have code output this:
Nor has this been committed to github.
No markup changes are required.
Existing markup that generates dropdown menus will produce a single dropdown (no sub-menu) when one group is present:
Existing markup that generates dropdown menus will produce a dropdown with sub-menus when more than one group is present:
Recent Comments