-
-
Notifications
You must be signed in to change notification settings - Fork 11
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
withfaces
doesn't apply to constructed StyledStrings
#87
Comments
Mmmm, from this I take it that some of the nuances with the system could be better explained in the docs. I can see how one might imagine Let's add this to the discussion we've lined up. Just so it's out of Slack, I'll also reproduce the list of benefits/annoyances of the current system I wrote and you suggested edits to. Key points I like with the current system:
Key points of annoyance with the current system:
|
Sounds good to me! FWIW I would naively have expected |
And here's a gist sketching the "palette" idea that I brought up on Slack: https://gist.github.com/topolarity/f4e422c70441a002af88510750788048 The main idea here is to go from a single-level namespace to a two-level namespace, w/ more explicit inheritance - The goal is to make it easier to answer questions like:
|
This is step #1 to eliminating our type-piracy problems StyledStrings needs to put some type that it owns into its AnnotatedStrings so that we have a right to hook into the display logic (and the display logic can know which copy of StyledStrings to delegate to. It is also a semantic change to how constructing StyledStrings behaves, but overall I think it's a lot more intuitive to have a StyledString actually compute its style information at construction Resolves #87
This is step 1 to eliminating our type-piracy problems StyledStrings needs to put some type that it owns into its AnnotatedStrings so that we have a right to hook into the display logic (and the display logic can know which copy of StyledStrings to delegate to. It is also a semantic change to how constructing StyledStrings behaves, but overall I think it's a lot more intuitive to have a StyledString actually compute its style information at construction Resolves #87
This is step 1 to eliminating our type-piracy problems StyledStrings needs to put some type that it owns into its AnnotatedStrings so that we have a right to hook into the display logic (and the display logic can know which copy of StyledStrings to delegate to). It is also a semantic change to how constructing StyledStrings behaves, but overall I think it's a lot more intuitive to have a StyledString actually compute its style information at construction Resolves #87
This is step 1 to eliminating our type-piracy problems StyledStrings needs to put some type that it owns into its AnnotatedStrings so that we have a right to hook into the display logic (and the display logic can know which copy of StyledStrings to delegate to). It is also a semantic change to how constructing StyledStrings behaves, but overall I think it's a lot more intuitive to have a StyledString actually compute its style information at construction Resolves #87
I'd have expected styling to be applied at string construction, so that:
prints "text" in red. Instead, it prints without styling.
IMO this is a subtle but important difference between what I'd expect to be a StyledString vs. an AnnotatedString.
If you want to carry around style information with your string (I almost always do), I have to shuttle around the Faces I need to the presentation layer somehow - which is especially unclear how to do if I wanted to do
AbstractString
-style operations on this in a way that preserves styling.The text was updated successfully, but these errors were encountered: