Add inline_code_background field to TextViewStyle

[KlausUllrich]

Summary

Adds an inline_code: StyleRefinement field to TextViewStyle, giving consumers full style control over inline code spans (backtick text). Follows the same pattern as the existing code_block: StyleRefinement field.

Problem

Inline code currently uses cx.theme().accent as its background highlight. The accent color is designed for interactive/attention-grabbing elements (buttons, links, selections), which makes it visually heavy when applied to inline code mixed with body text. There's no way to customize this without forking or vendoring the crate.

Solution

Add a new StyleRefinement field to TextViewStyle with a builder method, matching code_block:

// In TextViewStyle:
pub inline_code: StyleRefinement,

// Builder:
pub fn inline_code(mut self, style: StyleRefinement) -> Self

Default behavior is unchanged — when the field is StyleRefinement::default(), inline code continues to use cx.theme().accent exactly as before. Consumers who want a different background can set it:

let mut inline_style = StyleRefinement::default();
inline_style.text.background_color = Some(my_color);
let style = TextViewStyle::default().inline_code(inline_style);

Implementation

Two files changed:

• crates/ui/src/text/style.rs: Added inline_code: StyleRefinement field, StyleRefinement::default() default, and builder method
• crates/ui/src/text/node.rs: In Paragraph::render(), reads node_cx.style.inline_code.text.background_color with fallback to cx.theme().accent

The render path uses text.background_color (not element-level background) because inline code renders as a text-run highlight via HighlightStyle, not a container div.

Backwards Compatibility

Fully backwards compatible:

• New field defaults to StyleRefinement::default() → existing behavior preserved
• No changes required for existing consumers
• API is consistent with code_block field

cargo check passes cleanly.

[huacnlee]

Use StyleRefinement like the code_block.

[KlausUllrich]

Thanks for the review! Good call — I've updated the PR to use StyleRefinement for consistency with code_block.

Changes:

• Renamed inline_code_background: Option<Hsla> → inline_code: StyleRefinement
• Builder method now matches code_block's signature
• Fully backwards compatible — StyleRefinement::default() preserves existing behavior

Implementation note: the render path reads inline_code.text.background_color (not element-level background) because inline code renders as a text-run highlight via HighlightStyle, not a container div. text.background_color maps directly to HighlightStyle.background_color — and since Background.solid is pub(crate) in gpui, extracting Hsla from Fill::Color isn't possible from downstream crates.

Will push the updated code shortly.

[huacnlee]

I just realized this is a HighlightStyle type.

1. If modifying the background_color is supported, then there will be other corresponding modifications.

2. Since the inline_code is an inline style, it should use HighlightStyle instead of StyleRefinement. However, HighlightStyle may not have a refine method, so this is more complex and cannot be modified so simply.

[KlausUllrich]

Thank you for the feedback. You were right — HighlightStyle is the correct abstraction for inline text spans. I have updated the PR:

• inline_code field is now HighlightStyle instead of StyleRefinement
• The render path merges via .highlight(), which means all HighlightStyle properties (color, weight, style, background, underline, strikethrough) are now supported for inline code
• Default behavior is unchanged: when no background is set, falls back to cx.theme().accent

Backwards compatible — HighlightStyle::default() preserves existing rendering for consumers who do not set a custom style.