I have done some troubleshooting and determined that the call to v->force_redraw(); on src/controller.cpp:894 is triggering this behaviour.

Looking at the code, if I comment out fa->get_form()->run(-1); on src/view.cpp:834, the errant behaviour seems to stop (but, I"m sure that are unintended side-effects; I can"t tell what fa->get_form()->run(-1); is trying to achieve.)

Technically this is a duplicate of #223, but I"m going to keep both issues open because you"ve already made some progress here. Thanks for that, by the way!

run(-1) simply renders the form. See stfl_run in STFL docs; the argument passed to our run is stfl_run"s timeout. This line—and, in fact, the whole force_redraw method—was introduced in 89a047a and pretty much didn"t change since. So I can"t really tell you why it"s even there.

I presume you"re now running a version with that line removed? If so, can you write back in a week or so to tell if you ran into any additional issues that went away if you bring the line back? Maybe that line is really useless and we can just drop it.

Thanks for the reply and keeping this open. I did some searching for previous issues but the title of #223 didn"t lend itself to being detected by my keywords.

That"s what I imagined run did, so I am hesitant to comment iit out in force_redraw, as the method is rendered inert. Much better, I thought, to detect what the current view is, and redraw only if it"s a list of the feeds. I couldn"t figure out a way to tell what the current view is (I"m not really a c++ person), so I had to satisfy myself with this current approach.

I will continue to run with run commented out in force_redraw, but if I could be pointed in the right direction for detecting what the "current view" is, I"d be happy to make a pull request that I was satisfied was a fix.

Much better, I thought, to detect what the current view is, and redraw only if it"s a list of the feeds.

Or article list; or URL view; or tag view; or something else. Anything but article view, where the problem happens.

It"d be hard to get this info in the view class. The way view is used is by composition with other classes that implement specifics of the form; for example, formaction_itemview implements the one where you read the article. Making view know which class it"s composed into will be a bad design, I think.

I was also wrong saying this is a duplicate of #223. The other issue is concerned only with your second point, the one where rubbish like "4294967295 unread, 0 total" is shown. This is important, because I think these are two separate bugs. If I"m right, you"re going to see #223 even with run(-1) line removed: if you"re reading an article and its feed is updated, you"re going to see rubbish next time you scroll. (You"ll have to scroll to force screen redrawing.)

Regarding your first point, the problem is probably that redraw doesn"t preserve the position in the dialog. Grep for "articleoffset" and see if you can make force_redraw to save it before redrawing and restore it afterwards.

I was also wrong saying this is a duplicate of #223. The other issue is concerned only with your second point, the one where rubbish like "4294967295 unread, 0 total" is shown. This is important, because I think these are two separate bugs. If I"m right, you"re going to see #223 even with run(-1) line removed: if you"re reading an article and its feed is updated, you"re going to see rubbish next time you scroll. (You"ll have to scroll to force screen redrawing.)

I"ve reverted my trial patch to be commenting out v->force_redraw() when reload-all is called, as I discovered that my later suggestion was buggy. My current patch seems to address both problems in this Issue; my suspicion was that the redraw doesn"t know where it is on the page, and so jumps around (part 2) and sometimes points to invalid bits of memory/garbage (part 1). So far testing has been congruent with this hypothesis.

I will continue testing for ~1 week, and submit a patch if no problems arise.

I discovered that my later suggestion was buggy

That"s interesting! What bug did you run into?

Commenting out the whole method is rather harsh and doesn"t give us much information about what causes the problems. This three-line method actually packs a lot of actions, as you can imagine from the names of the methods it calls.

To be clear: I don"t suggest commenting out run as the proper fix. It"s just something that lets us localize the problem and figure out where to dig for the root cause.

That"s interesting! What bug did you run into?

The bug I saw related to item 1: If the pager has been scrolled, the pager is reset after reload-all has completed (but because it doesn"t redraw, the reset occurs when something like "next line" is pressed).

Uncommenting the whole method does sound harsh, but upon testing, the screen is still redrawn with updated "new" items when viewing the feed list. I will continue testing.

I am happy with my code changes, I don"t think they create further bugs. Am happy to have further testing occur before release though. What is the process for branch creation? (Do I fork, create my own branch & merge request, or can I push new branches to this repo? Is there a naming convention?)

You fork, create your branch and send a pull request. Branch name doesn"t matter as Git won"t preserve it after merge.

I still don"t know what solution you"re proposing and what problem, exactly, does it solve, but let"s see the code—we"ll figure it all out during review.

It finally occurred to me to take a look at Git blame for src/controller.cpp, and sure enough, I found a commit that introduced that damned force_redraw: 11083e6. I think the intent of the author is clear: they wanted to make sure that their updates to feeds" statuses got displayed right away. I"m pretty sure there"s a way to achieve this without force_redraw; how do ordinary feeds to this?