Login
Changes To FIXMEs
Login

Changes to "FIXMEs" between 2021-10-10 03:03:35 and 2021-10-10 07:56:40

46
47
48
49
50
51
52
53

54
55

56
57
58
59
60
61
62
46
47
48
49
50
51
52

53
54

55
56
57
58
59
60
61
62







-
+

-
+







    54     58  static int f_vdiff_hash(fsl_card_F const * const fc,
```

Note how line numbers above and below the `~~~~~` (diff chunk separator) are consecutive. fossil(1) doesn't do that because it handles the chunk separator at a higher level of the API, whereas libf moves that into the diff builder interface. That change requires that libf forego a step fossil performs which tries to merge chunks of a diff together if the distance between them is smaller than the number of context lines. That change in libf is apparently the root cause of this. It's purely cosmetic, but it's annoying.

TODO: figure out how to adapt libf to (A) not require that the higher-level API know such details about the diff builder but (B) still be able to apply that "cosmetic optimization."

## Split Diff (a.k.a. side-by-side) Column Limit and Multibyte Characts
## Split Diff (a.k.a. side-by-side) Column Limit and Multibyte Characters

The split diff renderer can truncate multi-byte characters when a column width limitation is placed on it. It looks like it's time to finally port in some of the character-level fiddly bits for UTF8 handling.
The split diff renderer can truncate multi-byte characters when a column width limitation is placed on it. It looks like it's time to finally port in some of the character-level fiddly bits for UTF8 handling. A potential TODO is to modify `fsl_appendf()`'s precision handling for `%s` to count in UTF8 characters. Hmmm. That would eliminate the problem altogether. Hmmmm. And possibly create new ones. Hmmmm.


# Crosslinking...

2021-04-12: The issue described below may have been resolved by the bug fixed in [](2791e665cca2eae2).

Running `f-parseparty -t c --crosslink` generates the expected number of mlink/plink entries but *sometimes* leaves (as it were) some commit other than the tip marked as a leaf, which causes `fossil update` to warn about having multiple leaves. We can get around this by running `fsl_repo_leaves_rebuild()` after it crosslinks everything, but that would simply hide the bug (if it *is* a bug - see below), which would presumably appear again at some point after a single checkin gets processed.