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
//! The window's §8.5 search results — coverage-excluded glue like the rest of
//! `src/shell/*`: the reading is [`crate::search`]'s, the routing is
//! [`AppModel::open`]'s, and this file only paints rows and reports clicks.
//!
//! It has **no RAM of its own**. The pane is a view of the published answer, so
//! it appears when there is one and vanishes when a search with no text clears
//! it — the same relationship every other surface has with the derivation it
//! renders (§7.2). There is no "search mode" to enter or leave: since bl-1ca2
//! the answer is a **center tab focus** ([`super::center`]) that the strip
//! offers exactly while there is an answer, rather than a 220 pt scroller
//! growing out of the composer and pushing the conversation off its own pane.
//!
//! Which is why the answer arrives as an argument: the tab strip has already
//! read it to decide whether to offer the tab at all, and reading it twice per
//! frame would be two clones of the same published value.
use crateAppModel;
use crate;
use ShellState;
/// What a result row does when pressed — the §11 discoverability rule.
const OPEN_HINT: &str = "Go to this result: select the thing it names, exactly as clicking it in \
the roster would. Nothing is changed. No key of its own: Tab reaches the row, \
Space presses it — and Ctrl+F asks the next `/search`.";
/// Paint the landed answer. A click goes where the hit says and hands the
/// keyboard back (§11 focus discipline: a pointer selection ends with the
/// cursor in the box — and on the Conversation tab, which is where the thing
/// it selected lives).
pub