Bit of a change for the update titles, as I realized that it was going to be confusing going on for years =P.

Anyway, if you look at my GitHub you’ll see that it’s been quite a productive five days since I returned from the beach.

I implemented the custom tag stuff. I made completions work better. I hooked up more commands, got aliases to work, fixed some readline bugs (which unfortunately required more C because the Python standard library is making some… poor assumptions). I also updated the yank plugin for canto-curses that’s in git.

The input line isn’t quite rock solid, but with the extra readline work it seems to be pretty close. I’ve copped out on some completions, but I consider that pretty low priority compared to some of the other stuff.

My last few have patches been getting plugins up to a more acceptable level. In particular, allowing plugins (like yank) to “suggest” binds, i.e. non-destructively update a key bind. So, for example, dropping the yank plugin into the .canto-ng/plugins directory will automatically bind ‘y’ and ‘Y’ the next time you run canto-curses, unless those keys already have bindings.

Another change I just committed is similarly intended to make bracketing displayed content from plugins a lot easier. For example, a “favorites” plugin that adds the user tag “favorite” is able to trivially add different markers (i.e. a star character or a different color). This would also make something that, say, colorized items based on domain, or based on a Bayesian heat map a lot easier (more on that in the future).

These two changes have made canto-curses plugins way more useful and, as a bonus, they work flawlessly with the new command infrastructure so plugins get completion basically for free. In addition, the new command format makes it a thousand times easier to use the command interfaces for objects because they take natural args. For example, tagging an item from a “favorites” plugin is as easy as doing taglist.cmd_tag_item('favorites', [ items ]) instead of having to decode a bunch of bullshit in an abused key word argument dict.

I’m pleased that things seem to be coming together so well.

My next immediate push is to complete the custom individual item tag work, in particular making it easy to shift between custom tags as part of completing the “favorites” plugin. I think the best way to work on that is two-fold. First, a command that will filter on tag, most likely by using the InTags filter (like from the example in the manual). The second is to make it easy to operate on tagged items inline by automatically supporting domains for the item-list argument type. So, for example, you could go through and “favorite” items, and then do something like goto favorite,* and all of the other item-list taking commands work for free.

I’m trying to make a conscious effort to separate some of the uglier workings from the user and push that into the plugin space. This was already sort of done by adding the config variables to the format string so you could change stuff like the selected and marked formats without changing the whole string. But stuff like temp-transform just isn’t useful enough, and I don’t believe that I ever want users manually twiddling configs themselves unless they’re into that level of control so stuff like toggle and set will be gone in favor of more specific commands like toggle-enumerated or the aliases like browser.