expansion of bookmarks has lost 2nd-through-Nth entries in ranges

[karlkleinpaste]

With a bookmark containing any dash-separated range, like this...

<Bookmark modulename="" key="Gen 2:18, 3:16; Deu 17:17, 24:5; 2Sam 12:8; 2Chr 24:3; Jer 3:6-11; Ezek 23:2-4; Matt 25:1-12; Rom 13:1; 1Cor 7:2,39; Gal 3:28; 1Tim 3:2; Rev 6:1" moduledescription=" " description=""/>

...the ranges (e.g. Jer 3:6-11; Ezek 23:2-4) get lost when interpolated into the verse list, reduced to just their first verse:

The ranges matter, and they shouldn't be elided to just their leading verse. In fact, I explicitly want the entire list. Prior to the bookmark rework for folder colors and popup menu (which is a fine feature on its own), this was the normal case, that is, the expansion of such lists was complete, with all the range-indicated verses appearing in the verse list.

This should be re-done to get back the previous semantic and verse list display. Yes, such displays are longer, but they matter.

[LAfricain]

Yes, I agree! I just realized that too when I started updating the help section (I'm working on it right now). Are you sure it wasn't the latest commits that broke this? If that's not the case, I could work on it at my own pace on Monday.

[karlkleinpaste]

I believe that behavior started as of the bookmark work for color and menu. I didn't want to mention it while so many other things were going on. I surely had nothing to do with how bookmark trees are built or how verse lists are expanded by what my recent commits have done.

You could try backing out a local source tree to just before and after those particular commits to see the change.

[karlkleinpaste]

Take a look at what was happening around this time.

[LAfricain]

Should be solved with #1377

[karlkleinpaste]

fixed by #1377

[karlkleinpaste]

Hm. I thought this was good and clean. But it seems to be one problem after all.

<Bookmark modulename="" key="1Tim 2:9-12" moduledescription=" " description="Conduct and authority"/>

Edit Item shows:

But somehow this bookmark does not get expanded. Click, and it navigates there, doesn't expand it into the verse list. Similar for when popup menu is enabled, it doesn't offer the menu, just navigates.

[karlkleinpaste]

Ohhhh... Variation on a theme:

The example above, for vv 9-12, does not expand in the verse list. But perversely when I hover over *b in the resulting colorized verses. that bookmark name appears once for v.9 and twice for all of vv.10-12. So those 3 verses are being inserted into the tag map 2 times each.

[LAfricain]

I think it makes sense that the verses aren't displayed if there's only one continuous series—xiphos takes us straight to the right place since the verses are a single sequence anyway. Don't you think that's good?

So those 3 verses are being inserted into the tag map 2 times each.

Actually, I see that. Do you have any idea why? Do you think it has something to do with my work?

That's actually the case for all references with dashes.

[LAfricain]

Here's what Claude told me:
I think I've identified the exact cause of the duplication. Take a close look at this part of Karl's commit:

c
/* The first color wins for the display of a given verse
 * but all other occurrences will be appended. */
gchar *element = (gchar *)g_hash_table_lookup(tag_color_map, ref2);
gchar *str = g_strconcat((element ? element : “”), effective, ..., NULL);
g_hash_table_insert(tag_color_map, ref2, str);

Karl changed the logic: instead of ignoring duplicates (“first come, first served”), it now accumulates all entries for the same verse (to allow multiple b links if multiple bookmarks reference the same verse).

However, we ourselves had added a second range expansion mechanism in build_tag_color_map()—the heuristic search for “:-” in the plain text—to correct 1 Cor 15:1-4, before we fixed the actual problem at the source in parse_verse_list(). Now that parse_verse_list() already expands ranges correctly (1 Tim 2:9-12 → 4 separate elements: 9, 10, 11, 12), our old redundant mechanism in display.cc also targets verses 10, 11, and 12 (those following the first one) and adds them a second time—hence the duplication only on those verses, never on verse 9 (the starting point).

We therefore need to remove our old fix, which is now redundant, from display.cc.