Very cool! I like the interface. For anyone interested in this and similar ideas, haiku/senryū detection is a feature of this old project of mine: https://versepad.com
I see a lot of comments here asking about practical motivations for this feature. One I'll share is that in a gem I help maintain, we benchmark git branches of the gem against `main`, and we also benchmark against multiple other gems that sometimes have namespace collisions with each other. To make this work, we use a third-party gem[0] and an anonymous module trick[1] that are each a bit hacky.
That being said, I have no particular stance on whether this feature is a good change to the language; in a decade of Ruby this is the only situation I can recall that really merited it, and the concerns articulated by byroot and others do resonate with me.
This is the keyboard I’ve been hoping Apple would make for years! I’ve currently got a UHK 60 but would probably switch to this if I could buy it. Especially if it had the standard Apple keyboard layout so my fingers don’t need to relearn things like arrow keys and cmd like when I switch between the UHK and MacBook keyboard.
Semi-related: years ago I made a silly little running pace converter site: https://pace.ninja/
I’m not a huge runner but still find myself using it all the time, both for my own occasional running goals and to satisfy my curiosity for questions like “how quickly would an elite sprinter’s pace finish a marathon?”
Thanks for the thoughtful feedback and questions! The meter detection algorithm is by far the most complex piece of this code, and you're right that it still sometimes generates unintuitive results. I'm always looking for more examples to add to my test suite to make improvements, so I really appreciate you sharing what you tried.
It tends to behave poorly when there's a word it doesn't recognize (like "doll'd"—I hope to add support for more of these poetic spellings just as I added support for spelling words like "dancing" as "dancin'"), so that might be partly at play with some of what you're seeing. But I think there's also something else going on here—it previously didn't ever generate so many consecutive syllables with the same stress, so I probably introduced a regression at some point. I'll investigate and add more tests for that too!
Lastly, a byproduct of my own background and the corpuses I use is that this does work better with "modern" poetry. For example, Shakespeare's Sonnet 29 starts with this line:
> When, in disgrace with fortune and men’s eyes
In the intended iambic pentameter, it would be:
> when, IN disGRACE with FORtune AND men's EYES
I don't know enough history to know if people ever spoke English like that, but that interpretation is way off to a modern reader. If I didn't know it was supposed to be iambic and was trying to diagram the stresses, I'd do something like:
Hi! You're right that rhyme detection can be improved, and rhyme scheme currently only considers words at the end of each line. I'd love to hear how you'd expect/want an internal rhyme feature to work. What would it look like? How would it avoid clutter when also showing syllables or meter?
Thanks for the feedback! I would love to eventually support multi-stanza forms like villanelles and sestinas but that requires some more thought. Are there other forms or features you'd use?
Thanks for the feedback! I made some changes a few years ago[1] to make Versepad work on my own iOS phone (the only mobile device I have). Can you share more details (or a video would be amazing) about your device and what behavior you're seeing so I can look into this?
I guess it depends on what you consider a default header. (I’m not too familiar with standards here; there may be some IETF definition you’re referring to?)
It turns out if you have enough control over your server you can make it do a lot of things! (Which may or may not conform to a spec.)