Feature Summary
The palette is a file of hardcoded truecolor constants with no configuration and no fallback, NO_COLOR is ignored, and the script viewer shells out to bat with --theme "Solarized (light)" and --terminal-width=100 both fixed.
Motivation / Use Case
The bat half is a straight defect rather than a preference, and it can be fixed on its own without the rest of this. Solarized (light) renders dark text on a light background, which then gets drawn into a pane whose surrounding chrome is nearly black, so on a dark terminal the script pane is a bright rectangle with washed-out syntax colours. And because the width is pinned at 100, the box-drawing rules from --style=grid are 100 columns wide whatever the pane actually is, so in the default half-width split on an 80-column terminal every rule wraps and the script is unreadable. Both arguments were plausibly right on one terminal and are wrong everywhere else.
The palette half is mostly preference, but it has a correctness edge. Color::Rgb needs truecolor. ratatui degrades it on a 256-colour terminal, but on TERM=linux, which is an ordinary physical console on an HPC serial line, or under NO_COLOR, the result is a UI whose only state signal is colour that is not being rendered.
Proposed Solution
Three separable pieces.
Fix the bat call. Drop --theme so bat uses BAT_THEME or its own default, which respects the user's environment instead of overriding it, and pass the real pane width. run_bat is called from a spawned thread with no access to the pane geometry, which is why the width is a constant today. The simple version is to pass the width captured when the job was selected and accept that a resize needs a job switch to re-render, which is worth a comment saying so rather than a reload mechanism.
Honour NO_COLOR. Any non-empty value means emit no colour. Make the theme a struct of the same fields with a detect() that returns either the current palette or an all-Color::Reset one, resolved once at startup. Constants becoming fields is mechanical, the work is threading it through, and there are five more colour constants living outside theme.rs in filter_tree.rs and widget_selector.rs that it would absorb.
A config file, optional and later. Once the theme is a struct, reading it from a file is nearly free, but it should wait until #14 and #15 have settled the atomic-write and versioning story rather than adding a fifth unversioned config file.
Not worth building: a theme engine with named built-ins, live switching and a picker. One struct, one detect function, one optional file.
Feature Summary
The palette is a file of hardcoded truecolor constants with no configuration and no fallback,
NO_COLORis ignored, and the script viewer shells out tobatwith--theme "Solarized (light)"and--terminal-width=100both fixed.Motivation / Use Case
The
bathalf is a straight defect rather than a preference, and it can be fixed on its own without the rest of this. Solarized (light) renders dark text on a light background, which then gets drawn into a pane whose surrounding chrome is nearly black, so on a dark terminal the script pane is a bright rectangle with washed-out syntax colours. And because the width is pinned at 100, the box-drawing rules from--style=gridare 100 columns wide whatever the pane actually is, so in the default half-width split on an 80-column terminal every rule wraps and the script is unreadable. Both arguments were plausibly right on one terminal and are wrong everywhere else.The palette half is mostly preference, but it has a correctness edge.
Color::Rgbneeds truecolor. ratatui degrades it on a 256-colour terminal, but onTERM=linux, which is an ordinary physical console on an HPC serial line, or underNO_COLOR, the result is a UI whose only state signal is colour that is not being rendered.Proposed Solution
Three separable pieces.
Fix the bat call. Drop
--themeso bat usesBAT_THEMEor its own default, which respects the user's environment instead of overriding it, and pass the real pane width.run_batis called from a spawned thread with no access to the pane geometry, which is why the width is a constant today. The simple version is to pass the width captured when the job was selected and accept that a resize needs a job switch to re-render, which is worth a comment saying so rather than a reload mechanism.Honour
NO_COLOR. Any non-empty value means emit no colour. Make the theme a struct of the same fields with adetect()that returns either the current palette or an all-Color::Resetone, resolved once at startup. Constants becoming fields is mechanical, the work is threading it through, and there are five more colour constants living outsidetheme.rsinfilter_tree.rsandwidget_selector.rsthat it would absorb.A config file, optional and later. Once the theme is a struct, reading it from a file is nearly free, but it should wait until #14 and #15 have settled the atomic-write and versioning story rather than adding a fifth unversioned config file.
Not worth building: a theme engine with named built-ins, live switching and a picker. One struct, one detect function, one optional file.