From d3d2dc33b786d64750e3dec19dfdf6ef6b3530e3 Mon Sep 17 00:00:00 2001 From: Jean-Pierre Martineau Date: Wed, 7 Oct 2026 01:50:04 -0400 Subject: [PATCH] The Records screen docstring records the guess for a short hop A hop that the topology could not resolve keeps its short hash, and the area drawing places it at the first node that matches. The score leaves such a hop out. JP chose on 2026-10-07 to keep the guess: the probable shape is more useful than a shape that has lost a point. Co-Authored-By: Claude Opus 5.5 (1M context) --- meshterm/ui/records_screen.py | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/meshterm/ui/records_screen.py b/meshterm/ui/records_screen.py index cc416e5..678e9f4 100644 --- a/meshterm/ui/records_screen.py +++ b/meshterm/ui/records_screen.py @@ -809,6 +809,13 @@ def node_geo_lookup( A record stores canonical ids. Thus the lookup matches them the same as the resolver does: a prefix on either side. + A hop that the topology could not resolve keeps its short hash (``3d``), and several + nodes can start with it. The lookup then makes a guess: the first entry that matches. + The score leaves such a hop out, so the drawing can show a point that the score did not + measure. JP chose this on 2026-10-07: the probable shape is more useful than a shape + that has lost a point. The name resolver makes the same guess, so the name and the pin + of a hop always agree. + Args: heard: The heard nodes of the history (:meth:`Repository.heard_nodes`). contacts: The contacts of the device.