So I’ve been sprinting lately and have perhaps been taking too much of a breathless approach to committing. Anyway, here’s an overview of what is already in git and what I plan on doing before the next dot releases.

Inoreader

The big one is Inoreader support has landed in canto-next git. It’s gone through a couple of revisions, but it seems to be working pretty well.

The first revision used Inoreader as the source for all Canto feed data, and that worked very well, was very tightly synchronized, but it had some down sides. Particularly, Inoreader seems to have trouble fetching some feeds on a regular basis (personal Reddit feeds, for example) so it finds far fewer items than Canto does, then when it does find items, Inoreader’s content has been filled with ads (obviously with a free account), and otherwise sterilized which means it’s missing interesting information custom to feeds that I’m not particularly happy with losing.

The second revision uses Canto’s standard fetch, and then grabs Inoreader’s data and correlates them. This means we’re not serving Inoreader ads, we don’t break reader-extras by losing content, and we can fetch as fast as possible… but as I discovered after writing this revision, on some fast moving, problematic feeds (Reddit, again) we get a different set of items between Canto and Inoreader. The end result is that you could have no unread items in Canto or Inoreader, but then the other would still have a bunch of unread items simply because they’re getting two different versions of the same feed. Of course, the silver lining there is that the unread items in one, you haven’t actually seen in the other so in the end you’re getting a broader range of items put in front of you… but at the same time it doesn’t feel synchronized when you’ve marked everything read in one place and the other has 200 items waiting. In addition, if you’re using Inoreader as a service to synchronize multiple Cantos, it can only sync items it knows about so you’d still have to use sync-rsync to get perfect synchronization between the Cantos.

Right now, I’m planning a third revision which will compromise between the two approaches. Canto will still fetch the data, and the true data will still be the primary data source (so for most feeds we don’t receive ads and still have custom content), but any items that Inoreader knows about and Canto doesn’t will be integrated (ads and all). This will fix the problem of marking everything as read in Canto, then going to Inoreader to find hundreds of waiting items and, most importantly, puts the most amount of content in front of the user. Unfortunately, I’m pretty sure fixing the opposite problem (marking everything in Inoreader read, and going to Canto to find unread items) is impossible to fix (without discarding items, which would be stupid) since Canto can’t advertise items to Inoreader. As such we’ll have to live with that. The only remaining foible, multiple Cantos becoming desynchronized on the items Inoreader doesn’t know about is also impossible to fix in this plugin, but is possible to workaround with sync-rsync if you really must.

Curses Color Config

Another improvement currently in git, is that the curses client has a much easier to use :color command, allowing you to do stuff like :color unread green instead of having to figure out what color pair is unread like before. This requires a configuration change, but current git should migrate most simple color changes on the first run of the new version. If it butchers your crazy color config, sorry, and please note the 0 at the front of the version number.

Finer Plugin Control

This keeps plugins not designed to work with a specific program from loading. Previously, every plugin would be loaded entirely even for uses of canto-remote. Because of the plugin architecture this wasn’t really a functional problem, but Python was generating some useless code. The end user will probably only notice that fewer plugins are listed in the logs (since incompatible plugins aren’t listed anymore) and maybe a small downtick in memory usage and startup time.

Non-debug CPU usage improved

A mass conversion to better use Python’s log.debug function to avoid doing the string formatting when the message won’t even be used. This causes a noticeable speedup when running the daemon/curses without the -v flag. In other news, I may be a log information addict.

Coming Soon

These are features that are either half-way implemented in git, or will be done before the next dot releases.

• Easier theming. The convoluted, Bash style escape sequences and shit are already gone. Themes will be implemented like plugins, overriding a function internal to the Story/Tag/Reader objects, allowing their appearance to be defined in regular old Python instead of a thousand character long tangle of codes. Along with this change will come the ability to manipulate Story/Tag appearance to filter or add content, similar to the abilities that already exist for the Reader.
• Better internal documentation of config options. :help set should list known variables that it makes sense to use with :set (i.e. rather than :bind or :color).
  

• Some old canto stuff that shouldn’t have been lost. Particularly, canto-remote should provide a way to get item read/unread/tag information out on the command line for integration into status bars, etc. as well as the cycles (i.e. old [ and ] binds to switch filters, sorts or visible tags).
• Further Inoreader tweaks as mentioned above.