As predicted, iTune’s party shuffle playlist has helped kickstart discussion on adding similar functionality to rhythmbox.
Snark aside, it’s actually an interesting discussion; open source people can/do think about how to do the right think in the UI. Whether they actually do the right thing in this case remains to be seen.
Note to self:
When adding ‘#’ to the character class [-. ], what you do not want to do is:
[#-. ]
but rather:
[-#. ].
For those who don’t spend a lot of time with regular expressions: the stuff between [ and ] represents a character class, which means that whatever is in there can match a single character in your target string (e.g. if you have [abc], it can match the ‘a’ in at, the ‘b’ in bog, and the ‘c’ in cut. What you can also do is specify ranges, so [a-z] will match all lower-case letters from a through z. If you want to match a literal ‘-‘, it needs to be the first character in the character class. Therefore, when I added ‘#’ to the front of the character class, I was saying I wanted to match all characters between ‘#’ and ‘.’. In case you’re curious, that is the equivalent of [#$%&'()*+,-.]. This, needless to say, caused some unexpected errors.
On the plus side, I don’t think I’ll make that mistake again…
After whining about how all the work I did to write this post, I should probably go ahead and write it, no?
The programs I can’t really live without:
So that’s my toolkit, or at least the parts of it I can think of right now. What I haven’t described is all the little ways I’ve tweaked things to make this setup mine; I think what I’m generally after is to not think about how to make things happen, they should just happen. Something for a follow-up post!
One of the little annoyances in using a xml configuration-heavy framework like struts is that every once in a while things don’t work, and the ultimate reason turns out to be that you missed a > in your struts-config.xml, or some subsidiary config file like validation.xml. Turns out that the answer has been lying around waiting to be used: ant’s xml validate task. Make it a requirement of your deploys and you’ll catch potential errors earlier rather than later.
So yesterday, I was going to do an essentials type post, listing all the software that I couldn’t really function without. First up on my list, of course, is xemacs, but writing that made me feel guilty about the fact that I’ve been neglecting mt.el, choosing instead to go through the web interface for posting to mt. Mostly this was because I hadn’t yet adapted it to set the text filter on posts, and I really like textile 2. So, I figured I’d dig in and get that working. Couple hours, tops.
Well.
First problem: I’d neglected things long enough that my lisp knowledge was once again on the oh-that’s-the-language-with-parens level, so I mucked about for a while getting my bearings. Once things like:
(let ((form `(lambda (limit) (let ((start (point))) (save-restriction (widen)
no longer looked completely bizarre to me, I started digging. First off, some upgrade of xml-rpc.el or xml.el or something had caused blank excerpt and extended entries to be set to 0. Replacing '0 with "" in the appropriate functions fixed this.
Having made this change, I quickly run GNU emacs to see if everything works ok there. It doesn’t, but for what appears to be a completely different reason: (concat "foo" 2) no longer works in emacs 21; you have to do concat "foo" (number-to-string 2)). Making this change breaks mt.el in xemacs.
Time passes…
Ultimately, the problem is that I’ve been storing the weblog-id as a string, but somehow in emacs it’s seen as an integer (or I do something that causes this, I dunno. At this point it’s a bit of a blur, honestly.) The solution: store it as an integer, so I can reliably do number-to-string whenever using weblog-id.
(For those still paying attention, all this work has gotten me to the point where I can start adding the functionality I originally opened the file to work on. I don’t call it Deft Code for nothin’, baby.)
I get setting text filter working without too much trouble, but immediately run into another issue: autofill and textile do not get along too well. For non-emacs users out there: autofill is what wraps lines in a paragraph, it basically takes long lines and breaks them with newlines at the appropriate place. The problem is that textile converts single newlines to <br />. So, I need an unfill function. After a bit of hacking about, I’ve got one that isn’t too cringeworthy (i.e., doesn’t rely on regular expressions). I have things re-autofilled when they’re returned, and all is well: things look right on the website, and things look the way I want them to in an emacs buffer.
But.
In textile, you define lists with successive lines beginning with either # (ordered) or * (unordered). However, when unfilling lines, emacs sees:
# one # two # three
and assumes what you want is:
# one # two #three
This, needless to say, is not what I want. Much manual digging later, I figure out that I can tell emacs that lines beginning with * or # indicate the beginning of a paragraph. This is tantalizingly close to what I want, but now when the content of a post is brought back, this:
# This is a really long line that wraps, so it should be all part of one bullet point .
is being autofilled into:
# This is a really long line that wraps, so it should be all part of # one bullet point
Which just will not do at all. The reason that this is happening is that emacs fill mode is CLEVER, and treats certain characters as a fill-prefix which should be used to begin each line. This is excellent if you’re wanting to quote a long line for an email with >, but not so nifty for me. It is possible, however, to turn this off locally in my fill-paragraph function with the magic incantation of let ((adaptive-fill-mode nil)).
At which point I begin to write this post, whereupon I realize halfway through that a few other things will likely break upon submission. Let’s find out…
Update: not too bad, but I think I still have a lot of work to do on handling block sections. I was hoping I wasn’t going to have to write my own fill-paragraph function, but…
For the time being though, I think it’s good enough for the textile functionality I make use of regularly. The funny part is that the only reason I’m having to do any of this is because I don’t want to turn off auto-fill in emacs.