styled_text: add compact style spans by waywardmonkeys · Pull Request #631 · linebender/parley

waywardmonkeys · 2026-05-26T15:11:57Z

Add styled_text as a first-slice crate for compact styled text storage.

The core crate stores resolved complete styles as compact StyleId spans over attributed_text, with layout and paint payloads interned separately so paint-only changes can share layout identity. It includes a builder that resolves overlapping patch ranges and reusable segment workspaces for downstream layout or paint passes.

This intentionally leaves lowering to Parley, cascading, editing policy, and application-specific style vocabularies outside the core styled_text crate.

waywardmonkeys · 2026-05-26T15:12:57Z

This was done with the assistance of Codex (GPT 5.3, 5.4, 5.5, medium, high, xhigh).

waywardmonkeys · 2026-05-26T15:15:12Z

Some things I have in mind for follow up PRs:

Public builder polish

Make the builder API feel like the obvious way to construct styled text.
Reduce “find a range, apply patch” ergonomics where possible.
Maybe add a push-oriented builder shape for appending text with current style state.

Base style / patch convenience

Provide a small default patch type or helper for common style updates.
Keep the trait-based StylePatch escape hatch, but avoid making every user define boilerplate for basic cases.

Better Parley adapter ergonomics

Make styled_text_parley easier to call from real code.
Keep the reusable workspace story front and center.
Avoid multiplying APIs; one good path is better than a pile of helpers.

Benchmarks / memory measurements

Add focused measurements for style interning, paint-only changes, lowering into Parley, and workspace reuse.
Maybe add malloc_size_of or equivalent only if we decide the dependency is acceptable.

PoignardAzur

Quick note: I think this code would be much easier to review if you split it into roughly one file per type. Right now it's kind of hard to find where types are defined without doing a lot of Ctrl+F.

waywardmonkeys · 2026-06-26T00:54:33Z

I have removed styled_text_parley from this PR leaving this one with just the base styled_text work ... I will be doing the styled_text_parley as a separate PR on top of this one.

Add `styled_text` as a first-slice crate for compact styled text storage. The core crate stores resolved complete styles as compact `StyleId` spans over `attributed_text`, with layout and paint payloads interned separately so paint-only changes can share layout identity. It includes a builder that resolves overlapping patch ranges and reusable segment workspaces for downstream layout or paint passes. This intentionally leaves lowering to Parley, cascading, editing policy, and application-specific style vocabularies outside the core `styled_text` crate.

DJMcNab

This seems reasonable to me.

Especially as we're not going to depend on this in Parley, it's fairly low-risk for experimentation. And it does unlock some doors for things we will need (HTML richtext copy/paste, etc.).

DJMcNab · 2026-06-29T22:42:54Z

+//! That keeps the core crate independent of any toolkit's style vocabulary
+//! while giving downstream code a simple stream of text ranges and full styles.
+//!
+//! ## Concepts


Nit:

Suggested change

//! ## Concepts

//! # Concepts

(Plus elsewhere in this file)

This isn't blocking, but it means that if I make the README changes before this lands then we get consistency.

DJMcNab · 2026-06-29T22:43:44Z

        run: cargo rdme --check --heading-base-level=0 --workspace-project=parlance

+      - name: Run cargo rdme (styled_text)
+        run: cargo rdme --check --heading-base-level=0 --workspace-project=styled_text


I know I need to go back to this repo and apply this change more widely, but we may as well start with the new best practise.

This previous mess was my fault, and I now know that the standard approach is to use h1 subheadings in Rust code.

Suggested change

run: cargo rdme --check --heading-base-level=0 --workspace-project=styled_text

run: cargo rdme --check --workspace-project=styled_text

DJMcNab · 2026-06-29T22:52:15Z

+///
+/// This record is exposed for diagnostics, invalidation decisions, and adapters
+/// that need to know whether two full styles share the same layout or paint
+/// payload. Text spans should store [`StyleId`], not this component record.


As a conceptual question, are the memory savings from interning a 2-id structure really worth much? Are we expecting to retain the same StyleId an average of more than twice for the majority of cases - or is this a play for handling huge documents (order of book length?)?

DJMcNab · 2026-06-29T22:58:36Z

+            layout: self.get_layout(record.layout_id())?,
+            paint: self.get_paint(record.paint_id())?,


Should these unwrap, or debug assert or something? It seems to me that this can only fail if something has gone wrong in our own bookkeeping.

DJMcNab · 2026-06-29T23:03:17Z

+    id: StyleId,
+    record: StyleRecord,
+    layout: &'a L,
+    paint: &'a P,


Is there a conceptual reason these aren't public fields (potentially #[non_exhaustive])

DJMcNab · 2026-06-29T23:04:17Z

+/// Builder for [`StyleSet`] values.
+///
+/// Interning is currently a linear search over retained vectors. That keeps the
+/// first slice dependency-free and compact; callers can reuse a builder during


What is the "first slice" here?

oh, a note to myself that should be removed. First slice of the implementation.

DJMcNab · 2026-06-29T23:05:58Z

+        self.intern_style_record(StyleRecord { layout, paint })
+    }
+}
+


So to check my understanding, it's not possible to directly intern a style record which is a combination of two existing layouts and paints from ids?

DJMcNab · 2026-06-29T23:07:47Z

+/// [`apply_style`](Self::apply_style). To introduce new styles, rebuild through
+/// [`StyledTextBuilder`](crate::StyledTextBuilder) or a fresh [`StyleSet`].


First-pass comment: I wonder if we can expose Arc::make_mut in a sensible way here.

DJMcNab · 2026-06-29T23:12:51Z

+    /// Finishes the builder and returns compact resolved styled text.
+    ///
+    /// Overlapping patches are applied in the order they were applied to the
+    /// builder over a clone of the base layout and paint styles for each
+    /// resolved non-base segment.


This is (up to) $$\mathcal{O}(n^2)$$ in the number of patches, right?

DJMcNab · 2026-06-29T23:15:09Z

+        } else {
+            let mut resolved_spans = Vec::new();
+            let mut workspace = AttributeSegmentsWorkspace::new();
+            let mut pending: Option<(TextRange, StyleId)> = None;


I think this needs a comment here. I'm having a hard time grasping what this does.

waywardmonkeys requested review from taj-p, tomcur and xStrom May 26, 2026 16:18

This was referenced May 26, 2026

Add text_style + styled_text crates (CSS-like resolution + document blocks) #495

Closed

Consistent API between Label and Prose linebender/xilem#1795

Open

PoignardAzur reviewed May 28, 2026

View reviewed changes

waywardmonkeys removed the request for review from taj-p June 1, 2026 05:59

waywardmonkeys force-pushed the styled-text-first-slice branch 2 times, most recently from 30aec40 to bb51b0a Compare June 1, 2026 08:00

waywardmonkeys force-pushed the styled-text-first-slice branch from bb51b0a to 45f79cc Compare June 26, 2026 00:52

waywardmonkeys changed the title ~~styled_text: add compact style spans and Parley lowering~~ styled_text: add compact style spans Jun 26, 2026

waywardmonkeys force-pushed the styled-text-first-slice branch from 45f79cc to 4722b21 Compare June 26, 2026 01:37

DJMcNab approved these changes Jun 29, 2026

View reviewed changes

	run: cargo rdme --check --heading-base-level=0 --workspace-project=styled_text
	run: cargo rdme --check --workspace-project=styled_text

		layout: self.get_layout(record.layout_id())?,
		paint: self.get_paint(record.paint_id())?,

		/// [`apply_style`](Self::apply_style). To introduce new styles, rebuild through
		/// [`StyledTextBuilder`](crate::StyledTextBuilder) or a fresh [`StyleSet`].

Uh oh!

Conversation

waywardmonkeys commented May 26, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

waywardmonkeys commented May 26, 2026

Uh oh!

waywardmonkeys commented May 26, 2026

Uh oh!

PoignardAzur left a comment

Choose a reason for hiding this comment

Uh oh!

waywardmonkeys commented Jun 26, 2026

Uh oh!

DJMcNab left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

waywardmonkeys commented May 26, 2026 •

edited

Loading