Different behaviour between "item-state read" and "item-state -read"? about canto-curses HOT 5 CLOSED

My guess is that you're still updating with an interval, and item-state -read causes a tag change that then updates your screen. This isn't good behavior (although it's still supported) which is why 0.9.0 changed the default to manual, i.e. you have to request an update.

If you do ":set update.auto.enabled False" do you still get this bad behavior?

from canto-curses.

Unfortunately yes. It still appears even with deactivated auto update (And I suppose it was disabled previously. Didn't had this option in the conf, so I suppose I were using default)
Only an interval option is in the update --> auto section of the conf, which should propably be removed, but shouldn't do any harm in that case?

from canto-curses.

Yeah, the interval won't do any harm if it's disabled.

Not really clear on what you're seeing then though. Locally, if I just do those commands, it behaves as expected (one item changes color, basically).

Do you think you can reproduce with a git version of canto-curses -v and gist or email the .canto-ng/curses_log to me ([email protected])?

from canto-curses.

With latest git it isn't occuring anymore.

(But I was greeted by this message (daemon is also latest git)
https://paste.archlinux.de/s8qQVV/
https://gist.github.com/Narrat/15474b6dbdb3448a07f8#file-cc
But cannot be much of problem, as I cannot reproduce it)

Switching back to 0.9.0 and the problem appears again. So I assume it is fixed as it isn't happening with latest git :)

from canto-curses.

Okay. I'm closing this and am probably going to put out 0.9.1 pretty soon.

I've never seen that "Failed to parse" message before, but it stems from JSON failing to parse something which shouldn't happen - at least not on the curses side. If you see it again, open a separate bug.

from canto-curses.