A few days ago I talked about what was currently getting my attention in the daemon. tl;dr multi-threading.

Part of the logic there was that the daemon was pretty stable and after a few days of tweaking around on the threading implementation I’m convinced that that’s true. I had one annoying thread bug squashed but, if anything, I take that as proof that the threading is actually working =P.

I mentioned that the curses interface was in much rougher shape. I took a year off from developing canto, but I still used it pretty much every day in the meantime and there are quite a few annoyances.

So here’s the current priority list:

• Threading. As I mentioned before, multi-threading the daemon was done mostly to allow better client behavior. This will require a bit of a redesign of the curses interface’s structure, but it shouldn’t be too bad. Problems I’d like to address with threading:
  • Unresponsive during item parsing
  • “Waiting on content…” after the initial load
  • Interface ceases updating while getting line input
• Command line overhaul with tab completion. I finally got down to brass tacks and hacked up a working interface to readline that will provide completions and line-editing in a standard fashion. The work to display test completions and route input through readline is already done, now generating deep completions and actually using them is TODO. This is actually made pretty easy thanks to how the command line worked before. I’m hoping that I can write this such that plugin commands could use built in completions or define their own without much overhead.
• Better plugins. The plugin system is extremely powerful and, in my opinion, already works pretty well with the daemon because most of the time you want to use it to modify feed content. However, for the curses interface, there are common tasks that are difficult to implement without looking at the code and that sucks. I want to fix this by adding more interesting hooks and more places where the default code will look for and use plugin attributes.
• Local config snippets. This is one that’s aimed squarely at a future where connecting to the daemon over LAN is fully supported. The interface will read settings from a local file so that you can have local configuration (especially useful for stuff like browser). This would also be a nice way to move around complex theme configurations.
• Polish. A lot of other little nits, like not mentioning how to close windows, or awkward configuration (although that will hopefully be addressed mostly with the tab completion).
• Defaults are going to change, because some of them don’t make sense. Auto-updating, for example, just doesn’t work. I mean, it’s functional, but it’s almost always bad behavior because it shifts the list around. It’s still a useful feature if you were going to, say, display the items on a screen without interacting, but that’s not your usual usecase.

In truth, I view making the command line more robust as priority one because it will make a lot of the dark corners of canto get a lot brighter, but it will be so much easier to do that after threading the interface (because I’ll be able to use the standard canto info boxes that show up to provide info instead of hacking up a expanded buffer that works while the rest of the interface is frozen) that it had to be bumped down.

The end goal is to get `canto-curses` to 0.9.0 in shape such that it can be used easily, predictably, and performantly.