From 6b83e57e7d8de573dbac055e1845de2811e94862 Mon Sep 17 00:00:00 2001 From: Matt <85322+mattmassicotte@users.noreply.github.com> Date: Mon, 25 Nov 2024 11:26:15 -0500 Subject: [PATCH] Clarify and expand on the role of TokenProvider --- Sources/Neon/Token.swift | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/Sources/Neon/Token.swift b/Sources/Neon/Token.swift index 5e80794..ec0995e 100644 --- a/Sources/Neon/Token.swift +++ b/Sources/Neon/Token.swift @@ -43,9 +43,11 @@ public struct TokenApplication: Hashable, Sendable { public static let noChange = TokenApplication(tokens: [], action: .apply) } -/// A type that assigns semantic value to a range of text either syncrhonously or asychrnoously. +/// A type that assigns semantic value to a range of text either synchronously or asynchronously. /// -/// The input will be an `NSRange` representing the text that needs styling, and the output is a `TokenApplication`. +/// The underlying parsing system must be able to translate a request for tokens expressed as an `NSRange` into a `TokenApplication`. +/// +/// This would be a lot easier to implement if the interface was purely asynchronous. However, Neon provides a fully synchronous styling path. Avoiding the need for an async context can be very useful, and makes it possible to provide a flicker-free guarantee if the underlying parsing system can process the work required in reasonable time. Your actual implementation, however, does not actually have to implement the synchronous path if that's too difficult. public typealias TokenProvider = HybridValueProvider extension TokenProvider {