1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
//! Hash computation for hashline editing.
//!
//! Each line in a file gets a [`HASH_LEN`]-character content hash tag computed
//! via FNV-1a. The hash alphabet uses 16 visually-distinct letters (no O/0,
//! I/l confusion), giving `16^HASH_LEN` possible hash values per line.
//!
//! The tag width matters a lot. History, and the reason it is now 6:
//!
//! - A 2-char tag (256 values) made a 20-line read collide ~54% of the time and
//! a 60-line read ~99.9%, so `hashline_edit` refused most real edits (#573).
//! - A 4-char tag (65,536 values) fixed small files but not large ones: false
//! collisions grow as `n^2 / (2 * 65536)`, which is ~418 expected pairs in a
//! 7,400-line file. Two logged failures had nine lines sharing one tag at
//! evenly spaced positions, which is a narrow hash, not identical content.
//! - A 6-char tag (16,777,216 values) drops that to ~1.6 expected pairs in the
//! same file, for two extra characters per line of `read_file` output (#2202).
//!
//! Identical-content lines (blank lines, a repeated `}`) still share a tag at
//! any width. That is inherent, and it is handled by the collision path, which
//! points the caller at `edit_file`.
/// 16 visually-distinct uppercase letters for the hash alphabet.
/// Excludes: O (looks like 0), I (looks like l/1), A (looks like 4 in some fonts),
/// C (looks like G), D (looks like 0 in some fonts), E (looks like F),
/// G (looks like 6), H (looks like N in some fonts), L (looks like 1).
///
/// Kept: Z P M Q V R W S N K T X J B Y U
/// Actually let's use the same alphabet as oh-my-pi for consistency:
/// Z P M Q V R W S N K T X J B Y H
pub const HASH_ALPHABET: & = b"ZPMQVRWSNKTXJBYH";
/// Number of characters in a line-hash tag. Widened from 2 to 4 in #573 (a
/// 2-char tag has only 256 values, so distinct lines collided constantly), and
/// from 4 to 6 in #2202 (65,536 values still collides ~418 times in a
/// 7,400-line file). 6 chars gives 16,777,216 values.
pub const HASH_LEN: usize = 6;
// The tag is sliced out of a 32-bit FNV-1a hash, one nibble per character, so
// widening past 8 would shift out of the integer and panic at runtime. The
// width is a tuning knob now (#2202), so the limit is checked at compile time.
const _: = assert!;
/// FNV-1a 32-bit offset basis.
const FNV_OFFSET_BASIS: u32 = 2_166_136_261;
/// FNV-1a 32-bit prime.
const FNV_PRIME: u32 = 16_777_619;
/// Compute FNV-1a 32-bit hash over the given bytes.
/// Compute a [`HASH_LEN`]-character hash for a line.
///
/// The hash is computed over the line content only (stateless).
/// This ensures **reference stability**: inserting or deleting lines
/// at the top of a file does not invalidate hashes for the rest.
///
/// Identical content at different positions produces the same hash.
/// Ambiguity is handled by the edit tool via lazy context escalation
/// (see issue #105).
///
/// # Arguments
/// * `content` - the line content (without newline)
///
/// # Returns
/// A [`HASH_LEN`]-character string from HASH_ALPHABET.
/// Compute hashes for all lines in a file content.
///
/// Returns a Vec of (1-indexed line number, [`HASH_LEN`]-char hash) pairs.
/// Format a line with its hash tag: `ID|content`