RFC: changing how text styling is done

[jthulhu]

I like very much Ply's philosophy and its simple yet expressive interface. In particular, I like the idea that Ply doesn't come with some hardwired stuff that makes the library unusable if you would want it differently. However, there is one exception to this: text styling.

I think the current state of affairs could be improved in three directions:

1. Ply parses text input and then styles off it. IMO, this is very bad because for the same reason C's printf is bad with respect to Rust's printf:

• If I want the user to be able to style their text, it enforces a given syntax.
• If I don't want the user to be able to style their text, I have to escape it, which is a fragile operation, and it will likely end up in having the same parser being implemented in two different parts of the code.
• if the styling allowed more than is currently allowed, as printf, it might lead to code sections which can be abused.

2. Ply's styling syntax is a little weird. This is mostly personal, but I think it's a little bit weird to have to separate arguments with _. This looks to me more like a quick and dirty solution because it's easy to parse without a "real" parsing backing it.
3. AFAIK, it's not possible to extend text styling (because it's hard-written), which goes against Ply's philosophy.

To solve these points, while keeping all the features that currently exist, I propose the following:

1. Split the API between the parsing, and styling: ie. instead of ui.text("..."), ui.text take a type that already encodes how the text is parsed, and have a separate parse function that turns the text into that representation. The API would become ui.text(parse("...")). At this point, one could also write it as a macro to avoid runtime parsing, which (besides the efficiency gain, which is probably negligible) prevents runtime styling injection.
   This way, the user is not tied to a particular string representation of text to be styled. For instance, I could be parsing and rendering Markdown, and I don't want to parse Markdown, then print it using Ply's syntax, then have Ply re-parse it.
2. Changing the syntax to something more familiar. For instance, one could go with {wave(speed = 3, amplitude = .3)|bla} (Python style), or {wave(speed: 3, amplitude: .3)|bla} (Typst style) or {(wave :speed 3 :amplitude .3)|bla} (Lisp style) or {wave speed=3 amplitude=.3|bla} (bash style) or {wave speed:3 amplitude:.3|bla} (OCaml style) or ... . One could even think of combining several styling at once, rather than nesting them, which is slightly more verbose than it needs to be: imagine {wave(speed = 3) pulse()|bla} (with whatever syntax you like better).
3. Have the rendering of text being subject to hooks. The idea is that one could register functions that modify how the rendering is done, and that are called specifically for the span of text that is styled with the corresponding style. Then, the currently provided styles should be implemented in "user space", ie. just by registering as a user could do with their own style. Currently, the styles are applied in a fixed order, regardless of how they were nested in the original text. This could be implemented, in the hook-based alternative, by giving each style a priority, and applying them in order.

I am open to suggestions. If this converges to a design that would be acceptable for Ply, I am willing to draft a working prototype, which would include all the features that I suggested here.

[TheRedDeveloper]

The _ thing was a quick fix to word wrapping. "Why is that?", you ask. Well, the text styling is a residue from the clayquad days, it was made in such a way that it was only needed to touch the rendering and just passed through the layout. Back in the days this was just all just a renderer and the layout engine was all written in C and was thus untouchable. So yeah this is definitely something that's ought to change in 2.0! Maybe this could even be a feature before then depending on how development is looking.

About the parsing thing. It looks like you're unhappy with the amount of time it takes to reparse these styles. Because everything is tied to only the rendering, the parsing actually happens every frame and can be split between different text render commands (for example if line wrapped):

ply-engine/src/renderer.rs

Lines 1958 to 2032 in 1e3b1c2

	let mut in_style_def = false;
	let mut escaped = false;
	let mut failed = false;
	let mut text_buffer = String::new();
	let mut style_buffer = String::new();
	let line = config.text.to_string();
	let mut segments: Vec<StyledSegment> = Vec::new();
	for c in line.chars() {
	if escaped {
	if in_style_def {
	style_buffer.push(c);
	} else {
	text_buffer.push(c);
	}
	escaped = false;
	continue;
	}
	match c {
	'\\' => {
	escaped = true;
	}
	'{' => {
	if in_style_def {
	style_buffer.push(c);
	} else {
	if !text_buffer.is_empty() {
	segments.push(StyledSegment {
	text: text_buffer.clone(),
	styles: state.style_stack.clone(),
	});
	text_buffer.clear();
	}
	in_style_def = true;
	}
	}
	'|' => {
	if in_style_def {
	state.style_stack.push(style_buffer.clone());
	style_buffer.clear();
	in_style_def = false;
	} else {
	text_buffer.push(c);
	}
	}
	'}' => {
	if in_style_def {
	style_buffer.push(c);
	} else {
	if !text_buffer.is_empty() {
	segments.push(StyledSegment {
	text: text_buffer.clone(),
	styles: state.style_stack.clone(),
	});
	text_buffer.clear();
	}
	if state.style_stack.pop().is_none() {
	failed = true;
	break;
	}
	}
	}
	_ => {
	if in_style_def {
	style_buffer.push(c);
	} else {
	text_buffer.push(c);
	}
	}
	}
	}

But the performance impact of that is probably really negligible. You are right tho that it doesn't quite seem efficient.

---

From an API perspective, I like the idea that people could write their own parsers and stuff. I also like the idea of separating the regular ui.text() from the styled ui.styled_text() and separating them in code as well. This is a really tricky situation for the text_input tho, we'll have to think about that more thoroughly. For the default parser I still think this is a good syntax as I initially designed it (where _ was still ). So for example {wave a=0.5 f=1.0|Wavy text} or {color=red|This text is red} It is really simple to parse and understand, and I like it. Within 2.0 we could maybe even increase the range of effects to include all sorts of warping, make the gradients better and add proper smooth shadows in the future.

I do not like your suggestion on "hooks" however. Hooks introduce quite a bit of complexity and callback overhead right inside the layout and rendering pipeline. Passing arbitrary functions into text rendering breaks everything and would be quite a mess. Instead allowing users to use custom parsers or (in 2.0 potentially using custom shaders), gives you all the flexibility you need.