Out-of-sync (collation?) issue in TreeView

[alk0]

https://github.com/pfalcon/zim-desktop-wiki-markdown/commit/ce7fd4f448457294290eab56e21660843e59daf8

On real-world notebooks (containing Unicode filenames among everything) the "Index" tree view is totally unusable (out-of-sync, visual glitches, possible crash), the debug window may show numerous Gtk-CRITICAL errors.

(zim.py:414295): Gtk-CRITICAL **: 10:45:04.033: ../gtk/gtk/gtktreeview.c:5573 (gtk_tree_view_bin_draw): assertion `has_child' failed. There is a disparity between the internal view of the GtkTreeView, and the GtkTreeModel. This generally means that the model has changed without letting the view know. Any display from now on is likely to be incorrect.

Re-indexing the notebook doesn't help (and possibly leaves the index inconsistent — after deleting the files the tree continues to display deleted pages!)

The minimal notebook causing the problem (not yet Gtk-CRITICAL, but all the weird behavior) seems to be this:

a.md B.md

(Latin letters a and B, notebook.zim has default_file_format=zim_markdown and default_file_extension=.md. Note that both 'Ba' and 'aB' sorting orders are both "alphabetical", one case-sensitive, the other not.)

Although… zim-wiki notebooks seem to be affected, too.

[pfalcon]

Thanks for the report.

ce7fd4f

Are you sure this commit has any relation to the issue described? That doesn't (seem to) have any changes related to the collation order. OTOH, I submitted an upstream issue related to the collation order: https://github.com/zim-desktop-wiki/zim-desktop-wiki/issues/1442 , and tried to do something about it in my fork.

I also can confirm that I'm seeing the issue you describe. But in my list, it started when I made a big drop (~100 pages) of migrated pages (from my older personal wiki). There're some weird links in those migrated pages, which causes Zim to create phantom pages for them, and my hunch was that Zim itself might be confused as the result. And for me, the issue seems to be cleared by Zim restart, but after some time, it repeats again (until next restart).

While looking into those issues, I generally found Zim codebase to be umm, over-engineered, while definitely having bugs and issues on its own. So, having a fork, it's hard to tell if I didn't make all the needed changes to keep all parts in sync, or Zim just had issue on its own or doesn't support some usecase.

So, thanks for providing a reproduction instructions, I'll look into that as time permits. If you have any addition info/details which would point to a particular commit in this branch, that's welcome.

[alk0]

Are you sure this commit has any relation to the issue described?

Not at all, it was just my way of telling what version I was at when observing the bug. Sorry if I confused you. I haven't checked the project in a while, but I can't remember seeing this glitch before (~a month or two ago maybe). What about https://github.com/pfalcon/zim-desktop-wiki-markdown/commit/1c078f2b611122210c354b11640f8e107b7b4c19, it had something to do with sorting?..

About zim-wiki having its own bugs and quirks - sure, I'm suffering badly from some of them myself, and some just can't be easily fixed (due to upstream GTK bugs or heavy legacy in zim-wiki codebase itself). We do what we can. I can post bug reports :)

[Korodny]

I have the same problem, TreeView is completely messed up, GTK spouts warnings about being out of sync etc. In my case, this seems to have been triggered by Zim adding non-existing pages to the TreeView.

If you link to a page that doesn't exist yet, Zim will add the page to the tree (but display it in an italic font in a lighter color) so you can actually create it/fill it with content.

When I imported my existing Zim Wiki, I had lots of broken links, since zim2markdown is dumb and simply performs a lot of search&replace operations on a file. So I ended up with lots of links looking like that:

[Joe Biden](https*www.spiegel.de/thema/joe_biden.md/)

It's broken, obviously. Zim tries to parse that, but thinks it links to non-existing page in the wiki, hence it adds an entry for it to the TreeView. And the TreeView goes completely nuts.

As soon as I fix the last of these broken links for the Wiki branch currently displayed in the TreeView - i.e. no more non-existing pages added to the TreeView - things are back to normal. I might have had to close and reopen said branch to update the display properly - can't remember. But once the superfluous entries are gone, things are working again (except for a minor display bug, which I'm still trying to narrow down).

[pfalcon]

As soon as I fix the last of these broken links for the Wiki branch currently displayed in the TreeView - i.e. no more non-existing pages added to the TreeView - things are back to normal. I might have had to close and reopen said branch to update the display properly - can't remember. But once the superfluous entries are gone, things are working again (except for a minor display bug, which I'm still trying to narrow down).

@Korodny, thanks for the feedback and providing more data/insight. What you describe is pretty much what I experienced and how I dealt with it. I mass-imported a bunch of Trac pages, and that's (+/-) when the issue started. Those pages also have some broken links, and I even still didn't fix them all. The difference, is that I had only a few such, so it glitched on me from time to time, but I can't say that the whole thing was broken for me. The way you describe is also how I dealt with it - collapsing/expanding the tree, and/or restarting Zim.

That's of course all not good, and need to be looked into. But so far, during summer, I didn't find time for that, as again, it mostly works for me, just glitches sometimes. The real problem I have is that I can't collect and put all the data into my wiki, not how the tool works (again, it's pretty workable comparing to manual editing notes with a plain-text editor). However, I'm (still) using Zim for almost a year now, so I'm on the right track to keep looking into individual issues over the next years (unless I find a better tool, and that's one of the reasons I'm not in hurry).