Rewrite Terminal formatter with Prettyprinter by pbrisbin · Pull Request #74 · freckle/blammo

pbrisbin · 2025-12-08T14:58:20Z

This change removes the manual Text-building of our current terminal
formatter and instead uses Prettyprinter. This is a much better tool
for the job and produces very nice output in less code.

The actual resulting terminal output was improved in a few small ways:

The colors of attributes is improved, because Prettyprinter's
annotations system makes it easier to do fancier things
Long messages that themselves span the breakpoint are wrapped in a
hanging-indent style, since that too is easier to do with
Prettyprinter.

It may have been possible to do this in a way opaque to end-users,
except for one thing: colors.

The best-practice way to ansi-escape Prettyprinter output is to use
its annotations feature. Elements within a Doc are annotated with the
bits that should be colored at render time. It's also a best-practice
to annotate your Doc, not directly with color escapes, but with
semantic annotations (see our Ann type). Those can then be mapped
centrally to color escapes, again as part of rendering (see our
annToAnsi function).

This approach comes with a number of nice properties for our use-case in
Blammo: it means the choice of colors-or-not, and what those colors are,
need not be known and passed around at the time log messages are
built. Rather, it is centralized at the place where the log messages
are rendered.

Therefore, I decided to lean into this and entirely replace our Color
module with the Terminal.Doc.Ann type. For example, there is no longer
a feature like getLoggerColors, which was meant to provide end-users
colors-or-not as appropriate. Instead, such users can use Ann all the
time and the colors-or-not concern is handled later.

Most users, those who are not actually building and pushing messages
directly to Logger, are not affected by this, but those that are will
require pretty big changes with this new version.

This change removes the manual `Text`-building of our current terminal formatter and instead uses `Prettyprinter`. This is a much better tool for the job and produces very nice output in less code. The actual resulting terminal output was improved in a few small ways: 1. The colors of attributes is improved, because `Prettyprinter`'s annotations system makes it easier to do fancier things 2. Long messages that themselves span the breakpoint are wrapped in a hanging-indent style, since that too is easier to do with `Prettyprinter`. It may have been possible to do this in a way opaque to end-users, except for one thing: colors. The best-practice way to ansi-escape `Prettyprinter` output is to use its annotations feature. Elements within a `Doc` are annotated with the bits that should be colored at render timer. It's also a best-practice to annotate your `Doc`, not directly with color escapes, but with semantic annotations (see our `Ann` type). Those can then be mapped centrally to color escapes, again as part of rendering (see our `annToAnsi` function). This approach comes with a number of nice properties for our use-case in Blammo: it means the choice of colors-or-not, and what those colors are, need not be known and passed around at the time log messages are _built_. Rather, it is centralized at the place where the log messages are rendered. Therefore, I decided to lean into this and entirely replace our `Color` module with the `Terminal.Doc.Ann` type. For example, there is no longer a feature like `getLoggerColors`, which was meant to provide end-users colors-or-not as appropriate. Instead, such users can use `Ann` all the time and the colors-or-not concern is handled later. Most users, those who are not actually building and pushing messages directly to `Logger`, are not affected by this, but those that are will require pretty big changes with this new version.

pbrisbin · 2025-12-08T15:52:15Z

 getLoggerReformat = lReformat

 setLoggerReformat
- :: (LogSettings -> Colors -> LogLevel -> LoggedMessage -> ByteString)


An example simplification: the "reformat" concern doesn't need the settings or colors because those are now only necessary for layout, which happens in the rendering step (where those things were already available).

- Add lts21, 22, and 24 - Symlink stack.yaml to latest (lts24)

pbrisbin · 2026-05-06T20:50:17Z

This is blocked on prettyprinteracquiring new maintainers and releasing a new version with "dim" support.

We could do it without dim, but I'd like to wait.

pbrisbin · 2025-12-08T14:58:20Z

This change removes the manual Text-building of our current terminal
formatter and instead uses Prettyprinter. This is a much better tool
for the job and produces very nice output in less code.

The actual resulting terminal output was improved in a few small ways:

The colors of attributes is improved, because Prettyprinter's
annotations system makes it easier to do fancier things
Long messages that themselves span the breakpoint are wrapped in a
hanging-indent style, since that too is easier to do with
Prettyprinter.

It may have been possible to do this in a way opaque to end-users,
except for one thing: colors.

The best-practice way to ansi-escape Prettyprinter output is to use
its annotations feature. Elements within a Doc are annotated with the
bits that should be colored at render time. It's also a best-practice
to annotate your Doc, not directly with color escapes, but with
semantic annotations (see our Ann type). Those can then be mapped
centrally to color escapes, again as part of rendering (see our
annToAnsi function).

This approach comes with a number of nice properties for our use-case in
Blammo: it means the choice of colors-or-not, and what those colors are,
need not be known and passed around at the time log messages are
built. Rather, it is centralized at the place where the log messages
are rendered.

Therefore, I decided to lean into this and entirely replace our Color
module with the Terminal.Doc.Ann type. For example, there is no longer
a feature like getLoggerColors, which was meant to provide end-users
colors-or-not as appropriate. Instead, such users can use Ann all the
time and the colors-or-not concern is handled later.

Most users, those who are not actually building and pushing messages
directly to Logger, are not affected by this, but those that are will
require pretty big changes with this new version.

This change removes the manual `Text`-building of our current terminal formatter and instead uses `Prettyprinter`. This is a much better tool for the job and produces very nice output in less code. The actual resulting terminal output was improved in a few small ways: 1. The colors of attributes is improved, because `Prettyprinter`'s annotations system makes it easier to do fancier things 2. Long messages that themselves span the breakpoint are wrapped in a hanging-indent style, since that too is easier to do with `Prettyprinter`. It may have been possible to do this in a way opaque to end-users, except for one thing: colors. The best-practice way to ansi-escape `Prettyprinter` output is to use its annotations feature. Elements within a `Doc` are annotated with the bits that should be colored at render timer. It's also a best-practice to annotate your `Doc`, not directly with color escapes, but with semantic annotations (see our `Ann` type). Those can then be mapped centrally to color escapes, again as part of rendering (see our `annToAnsi` function). This approach comes with a number of nice properties for our use-case in Blammo: it means the choice of colors-or-not, and what those colors are, need not be known and passed around at the time log messages are _built_. Rather, it is centralized at the place where the log messages are rendered. Therefore, I decided to lean into this and entirely replace our `Color` module with the `Terminal.Doc.Ann` type. For example, there is no longer a feature like `getLoggerColors`, which was meant to provide end-users colors-or-not as appropriate. Instead, such users can use `Ann` all the time and the colors-or-not concern is handled later. Most users, those who are not actually building and pushing messages directly to `Logger`, are not affected by this, but those that are will require pretty big changes with this new version.

pbrisbin · 2025-12-08T15:52:15Z

 getLoggerReformat = lReformat

 setLoggerReformat
- :: (LogSettings -> Colors -> LogLevel -> LoggedMessage -> ByteString)


An example simplification: the "reformat" concern doesn't need the settings or colors because those are now only necessary for layout, which happens in the rendering step (where those things were already available).

- Add lts21, 22, and 24 - Symlink stack.yaml to latest (lts24)

pbrisbin · 2026-05-06T20:50:17Z

This is blocked on prettyprinteracquiring new maintainers and releasing a new version with "dim" support.

We could do it without dim, but I'd like to wait.

pbrisbin · 2025-12-08T14:58:20Z

This change removes the manual Text-building of our current terminal
formatter and instead uses Prettyprinter. This is a much better tool
for the job and produces very nice output in less code.

The actual resulting terminal output was improved in a few small ways:

The colors of attributes is improved, because Prettyprinter's
annotations system makes it easier to do fancier things
Long messages that themselves span the breakpoint are wrapped in a
hanging-indent style, since that too is easier to do with
Prettyprinter.

It may have been possible to do this in a way opaque to end-users,
except for one thing: colors.

The best-practice way to ansi-escape Prettyprinter output is to use
its annotations feature. Elements within a Doc are annotated with the
bits that should be colored at render time. It's also a best-practice
to annotate your Doc, not directly with color escapes, but with
semantic annotations (see our Ann type). Those can then be mapped
centrally to color escapes, again as part of rendering (see our
annToAnsi function).

This approach comes with a number of nice properties for our use-case in
Blammo: it means the choice of colors-or-not, and what those colors are,
need not be known and passed around at the time log messages are
built. Rather, it is centralized at the place where the log messages
are rendered.

Therefore, I decided to lean into this and entirely replace our Color
module with the Terminal.Doc.Ann type. For example, there is no longer
a feature like getLoggerColors, which was meant to provide end-users
colors-or-not as appropriate. Instead, such users can use Ann all the
time and the colors-or-not concern is handled later.

Most users, those who are not actually building and pushing messages
directly to Logger, are not affected by this, but those that are will
require pretty big changes with this new version.

This change removes the manual `Text`-building of our current terminal formatter and instead uses `Prettyprinter`. This is a much better tool for the job and produces very nice output in less code. The actual resulting terminal output was improved in a few small ways: 1. The colors of attributes is improved, because `Prettyprinter`'s annotations system makes it easier to do fancier things 2. Long messages that themselves span the breakpoint are wrapped in a hanging-indent style, since that too is easier to do with `Prettyprinter`. It may have been possible to do this in a way opaque to end-users, except for one thing: colors. The best-practice way to ansi-escape `Prettyprinter` output is to use its annotations feature. Elements within a `Doc` are annotated with the bits that should be colored at render timer. It's also a best-practice to annotate your `Doc`, not directly with color escapes, but with semantic annotations (see our `Ann` type). Those can then be mapped centrally to color escapes, again as part of rendering (see our `annToAnsi` function). This approach comes with a number of nice properties for our use-case in Blammo: it means the choice of colors-or-not, and what those colors are, need not be known and passed around at the time log messages are _built_. Rather, it is centralized at the place where the log messages are rendered. Therefore, I decided to lean into this and entirely replace our `Color` module with the `Terminal.Doc.Ann` type. For example, there is no longer a feature like `getLoggerColors`, which was meant to provide end-users colors-or-not as appropriate. Instead, such users can use `Ann` all the time and the colors-or-not concern is handled later. Most users, those who are not actually building and pushing messages directly to `Logger`, are not affected by this, but those that are will require pretty big changes with this new version.

pbrisbin · 2025-12-08T15:52:15Z

 getLoggerReformat = lReformat

 setLoggerReformat
- :: (LogSettings -> Colors -> LogLevel -> LoggedMessage -> ByteString)


An example simplification: the "reformat" concern doesn't need the settings or colors because those are now only necessary for layout, which happens in the rendering step (where those things were already available).

- Add lts21, 22, and 24 - Symlink stack.yaml to latest (lts24)

pbrisbin · 2026-05-06T20:50:17Z

This is blocked on prettyprinteracquiring new maintainers and releasing a new version with "dim" support.

We could do it without dim, but I'd like to wait.

pbrisbin · 2025-12-08T14:58:20Z

This change removes the manual Text-building of our current terminal
formatter and instead uses Prettyprinter. This is a much better tool
for the job and produces very nice output in less code.

The actual resulting terminal output was improved in a few small ways:

The colors of attributes is improved, because Prettyprinter's
annotations system makes it easier to do fancier things
Long messages that themselves span the breakpoint are wrapped in a
hanging-indent style, since that too is easier to do with
Prettyprinter.

It may have been possible to do this in a way opaque to end-users,
except for one thing: colors.

The best-practice way to ansi-escape Prettyprinter output is to use
its annotations feature. Elements within a Doc are annotated with the
bits that should be colored at render time. It's also a best-practice
to annotate your Doc, not directly with color escapes, but with
semantic annotations (see our Ann type). Those can then be mapped
centrally to color escapes, again as part of rendering (see our
annToAnsi function).

This approach comes with a number of nice properties for our use-case in
Blammo: it means the choice of colors-or-not, and what those colors are,
need not be known and passed around at the time log messages are
built. Rather, it is centralized at the place where the log messages
are rendered.

Therefore, I decided to lean into this and entirely replace our Color
module with the Terminal.Doc.Ann type. For example, there is no longer
a feature like getLoggerColors, which was meant to provide end-users
colors-or-not as appropriate. Instead, such users can use Ann all the
time and the colors-or-not concern is handled later.

Most users, those who are not actually building and pushing messages
directly to Logger, are not affected by this, but those that are will
require pretty big changes with this new version.

This change removes the manual `Text`-building of our current terminal formatter and instead uses `Prettyprinter`. This is a much better tool for the job and produces very nice output in less code. The actual resulting terminal output was improved in a few small ways: 1. The colors of attributes is improved, because `Prettyprinter`'s annotations system makes it easier to do fancier things 2. Long messages that themselves span the breakpoint are wrapped in a hanging-indent style, since that too is easier to do with `Prettyprinter`. It may have been possible to do this in a way opaque to end-users, except for one thing: colors. The best-practice way to ansi-escape `Prettyprinter` output is to use its annotations feature. Elements within a `Doc` are annotated with the bits that should be colored at render timer. It's also a best-practice to annotate your `Doc`, not directly with color escapes, but with semantic annotations (see our `Ann` type). Those can then be mapped centrally to color escapes, again as part of rendering (see our `annToAnsi` function). This approach comes with a number of nice properties for our use-case in Blammo: it means the choice of colors-or-not, and what those colors are, need not be known and passed around at the time log messages are _built_. Rather, it is centralized at the place where the log messages are rendered. Therefore, I decided to lean into this and entirely replace our `Color` module with the `Terminal.Doc.Ann` type. For example, there is no longer a feature like `getLoggerColors`, which was meant to provide end-users colors-or-not as appropriate. Instead, such users can use `Ann` all the time and the colors-or-not concern is handled later. Most users, those who are not actually building and pushing messages directly to `Logger`, are not affected by this, but those that are will require pretty big changes with this new version.

pbrisbin · 2025-12-08T15:52:15Z

 getLoggerReformat = lReformat

 setLoggerReformat
- :: (LogSettings -> Colors -> LogLevel -> LoggedMessage -> ByteString)


An example simplification: the "reformat" concern doesn't need the settings or colors because those are now only necessary for layout, which happens in the rendering step (where those things were already available).

- Add lts21, 22, and 24 - Symlink stack.yaml to latest (lts24)

pbrisbin · 2026-05-06T20:50:17Z

This is blocked on prettyprinteracquiring new maintainers and releasing a new version with "dim" support.

We could do it without dim, but I'd like to wait.

pbrisbin · 2025-12-08T14:58:20Z

This change removes the manual Text-building of our current terminal
formatter and instead uses Prettyprinter. This is a much better tool
for the job and produces very nice output in less code.

The actual resulting terminal output was improved in a few small ways:

The colors of attributes is improved, because Prettyprinter's
annotations system makes it easier to do fancier things
Long messages that themselves span the breakpoint are wrapped in a
hanging-indent style, since that too is easier to do with
Prettyprinter.

It may have been possible to do this in a way opaque to end-users,
except for one thing: colors.

The best-practice way to ansi-escape Prettyprinter output is to use
its annotations feature. Elements within a Doc are annotated with the
bits that should be colored at render time. It's also a best-practice
to annotate your Doc, not directly with color escapes, but with
semantic annotations (see our Ann type). Those can then be mapped
centrally to color escapes, again as part of rendering (see our
annToAnsi function).

This approach comes with a number of nice properties for our use-case in
Blammo: it means the choice of colors-or-not, and what those colors are,
need not be known and passed around at the time log messages are
built. Rather, it is centralized at the place where the log messages
are rendered.

Therefore, I decided to lean into this and entirely replace our Color
module with the Terminal.Doc.Ann type. For example, there is no longer
a feature like getLoggerColors, which was meant to provide end-users
colors-or-not as appropriate. Instead, such users can use Ann all the
time and the colors-or-not concern is handled later.

Most users, those who are not actually building and pushing messages
directly to Logger, are not affected by this, but those that are will
require pretty big changes with this new version.

This change removes the manual `Text`-building of our current terminal formatter and instead uses `Prettyprinter`. This is a much better tool for the job and produces very nice output in less code. The actual resulting terminal output was improved in a few small ways: 1. The colors of attributes is improved, because `Prettyprinter`'s annotations system makes it easier to do fancier things 2. Long messages that themselves span the breakpoint are wrapped in a hanging-indent style, since that too is easier to do with `Prettyprinter`. It may have been possible to do this in a way opaque to end-users, except for one thing: colors. The best-practice way to ansi-escape `Prettyprinter` output is to use its annotations feature. Elements within a `Doc` are annotated with the bits that should be colored at render timer. It's also a best-practice to annotate your `Doc`, not directly with color escapes, but with semantic annotations (see our `Ann` type). Those can then be mapped centrally to color escapes, again as part of rendering (see our `annToAnsi` function). This approach comes with a number of nice properties for our use-case in Blammo: it means the choice of colors-or-not, and what those colors are, need not be known and passed around at the time log messages are _built_. Rather, it is centralized at the place where the log messages are rendered. Therefore, I decided to lean into this and entirely replace our `Color` module with the `Terminal.Doc.Ann` type. For example, there is no longer a feature like `getLoggerColors`, which was meant to provide end-users colors-or-not as appropriate. Instead, such users can use `Ann` all the time and the colors-or-not concern is handled later. Most users, those who are not actually building and pushing messages directly to `Logger`, are not affected by this, but those that are will require pretty big changes with this new version.

pbrisbin · 2025-12-08T15:52:15Z

 getLoggerReformat = lReformat

 setLoggerReformat
- :: (LogSettings -> Colors -> LogLevel -> LoggedMessage -> ByteString)


An example simplification: the "reformat" concern doesn't need the settings or colors because those are now only necessary for layout, which happens in the rendering step (where those things were already available).

- Add lts21, 22, and 24 - Symlink stack.yaml to latest (lts24)

pbrisbin · 2026-05-06T20:50:17Z

This is blocked on prettyprinteracquiring new maintainers and releasing a new version with "dim" support.

We could do it without dim, but I'd like to wait.

pbrisbin · 2025-12-08T14:58:20Z

This change removes the manual Text-building of our current terminal
formatter and instead uses Prettyprinter. This is a much better tool
for the job and produces very nice output in less code.

The actual resulting terminal output was improved in a few small ways:

The colors of attributes is improved, because Prettyprinter's
annotations system makes it easier to do fancier things
Long messages that themselves span the breakpoint are wrapped in a
hanging-indent style, since that too is easier to do with
Prettyprinter.

It may have been possible to do this in a way opaque to end-users,
except for one thing: colors.

The best-practice way to ansi-escape Prettyprinter output is to use
its annotations feature. Elements within a Doc are annotated with the
bits that should be colored at render time. It's also a best-practice
to annotate your Doc, not directly with color escapes, but with
semantic annotations (see our Ann type). Those can then be mapped
centrally to color escapes, again as part of rendering (see our
annToAnsi function).

This approach comes with a number of nice properties for our use-case in
Blammo: it means the choice of colors-or-not, and what those colors are,
need not be known and passed around at the time log messages are
built. Rather, it is centralized at the place where the log messages
are rendered.

Therefore, I decided to lean into this and entirely replace our Color
module with the Terminal.Doc.Ann type. For example, there is no longer
a feature like getLoggerColors, which was meant to provide end-users
colors-or-not as appropriate. Instead, such users can use Ann all the
time and the colors-or-not concern is handled later.

Most users, those who are not actually building and pushing messages
directly to Logger, are not affected by this, but those that are will
require pretty big changes with this new version.

This change removes the manual `Text`-building of our current terminal formatter and instead uses `Prettyprinter`. This is a much better tool for the job and produces very nice output in less code. The actual resulting terminal output was improved in a few small ways: 1. The colors of attributes is improved, because `Prettyprinter`'s annotations system makes it easier to do fancier things 2. Long messages that themselves span the breakpoint are wrapped in a hanging-indent style, since that too is easier to do with `Prettyprinter`. It may have been possible to do this in a way opaque to end-users, except for one thing: colors. The best-practice way to ansi-escape `Prettyprinter` output is to use its annotations feature. Elements within a `Doc` are annotated with the bits that should be colored at render timer. It's also a best-practice to annotate your `Doc`, not directly with color escapes, but with semantic annotations (see our `Ann` type). Those can then be mapped centrally to color escapes, again as part of rendering (see our `annToAnsi` function). This approach comes with a number of nice properties for our use-case in Blammo: it means the choice of colors-or-not, and what those colors are, need not be known and passed around at the time log messages are _built_. Rather, it is centralized at the place where the log messages are rendered. Therefore, I decided to lean into this and entirely replace our `Color` module with the `Terminal.Doc.Ann` type. For example, there is no longer a feature like `getLoggerColors`, which was meant to provide end-users colors-or-not as appropriate. Instead, such users can use `Ann` all the time and the colors-or-not concern is handled later. Most users, those who are not actually building and pushing messages directly to `Logger`, are not affected by this, but those that are will require pretty big changes with this new version.

pbrisbin · 2025-12-08T15:52:15Z

 getLoggerReformat = lReformat

 setLoggerReformat
- :: (LogSettings -> Colors -> LogLevel -> LoggedMessage -> ByteString)


An example simplification: the "reformat" concern doesn't need the settings or colors because those are now only necessary for layout, which happens in the rendering step (where those things were already available).

- Add lts21, 22, and 24 - Symlink stack.yaml to latest (lts24)

pbrisbin · 2026-05-06T20:50:17Z

This is blocked on prettyprinteracquiring new maintainers and releasing a new version with "dim" support.

We could do it without dim, but I'd like to wait.

pbrisbin · 2025-12-08T14:58:20Z

This change removes the manual Text-building of our current terminal
formatter and instead uses Prettyprinter. This is a much better tool
for the job and produces very nice output in less code.

The actual resulting terminal output was improved in a few small ways:

The colors of attributes is improved, because Prettyprinter's
annotations system makes it easier to do fancier things
Long messages that themselves span the breakpoint are wrapped in a
hanging-indent style, since that too is easier to do with
Prettyprinter.

It may have been possible to do this in a way opaque to end-users,
except for one thing: colors.

The best-practice way to ansi-escape Prettyprinter output is to use
its annotations feature. Elements within a Doc are annotated with the
bits that should be colored at render time. It's also a best-practice
to annotate your Doc, not directly with color escapes, but with
semantic annotations (see our Ann type). Those can then be mapped
centrally to color escapes, again as part of rendering (see our
annToAnsi function).

This approach comes with a number of nice properties for our use-case in
Blammo: it means the choice of colors-or-not, and what those colors are,
need not be known and passed around at the time log messages are
built. Rather, it is centralized at the place where the log messages
are rendered.

Therefore, I decided to lean into this and entirely replace our Color
module with the Terminal.Doc.Ann type. For example, there is no longer
a feature like getLoggerColors, which was meant to provide end-users
colors-or-not as appropriate. Instead, such users can use Ann all the
time and the colors-or-not concern is handled later.

Most users, those who are not actually building and pushing messages
directly to Logger, are not affected by this, but those that are will
require pretty big changes with this new version.

This change removes the manual `Text`-building of our current terminal formatter and instead uses `Prettyprinter`. This is a much better tool for the job and produces very nice output in less code. The actual resulting terminal output was improved in a few small ways: 1. The colors of attributes is improved, because `Prettyprinter`'s annotations system makes it easier to do fancier things 2. Long messages that themselves span the breakpoint are wrapped in a hanging-indent style, since that too is easier to do with `Prettyprinter`. It may have been possible to do this in a way opaque to end-users, except for one thing: colors. The best-practice way to ansi-escape `Prettyprinter` output is to use its annotations feature. Elements within a `Doc` are annotated with the bits that should be colored at render timer. It's also a best-practice to annotate your `Doc`, not directly with color escapes, but with semantic annotations (see our `Ann` type). Those can then be mapped centrally to color escapes, again as part of rendering (see our `annToAnsi` function). This approach comes with a number of nice properties for our use-case in Blammo: it means the choice of colors-or-not, and what those colors are, need not be known and passed around at the time log messages are _built_. Rather, it is centralized at the place where the log messages are rendered. Therefore, I decided to lean into this and entirely replace our `Color` module with the `Terminal.Doc.Ann` type. For example, there is no longer a feature like `getLoggerColors`, which was meant to provide end-users colors-or-not as appropriate. Instead, such users can use `Ann` all the time and the colors-or-not concern is handled later. Most users, those who are not actually building and pushing messages directly to `Logger`, are not affected by this, but those that are will require pretty big changes with this new version.

pbrisbin · 2025-12-08T15:52:15Z

 getLoggerReformat = lReformat

 setLoggerReformat
- :: (LogSettings -> Colors -> LogLevel -> LoggedMessage -> ByteString)


An example simplification: the "reformat" concern doesn't need the settings or colors because those are now only necessary for layout, which happens in the rendering step (where those things were already available).

- Add lts21, 22, and 24 - Symlink stack.yaml to latest (lts24)

pbrisbin · 2026-05-06T20:50:17Z

This is blocked on prettyprinteracquiring new maintainers and releasing a new version with "dim" support.

We could do it without dim, but I'd like to wait.

pbrisbin · 2025-12-08T14:58:20Z

This change removes the manual Text-building of our current terminal
formatter and instead uses Prettyprinter. This is a much better tool
for the job and produces very nice output in less code.

The actual resulting terminal output was improved in a few small ways:

The colors of attributes is improved, because Prettyprinter's
annotations system makes it easier to do fancier things
Long messages that themselves span the breakpoint are wrapped in a
hanging-indent style, since that too is easier to do with
Prettyprinter.

It may have been possible to do this in a way opaque to end-users,
except for one thing: colors.

The best-practice way to ansi-escape Prettyprinter output is to use
its annotations feature. Elements within a Doc are annotated with the
bits that should be colored at render time. It's also a best-practice
to annotate your Doc, not directly with color escapes, but with
semantic annotations (see our Ann type). Those can then be mapped
centrally to color escapes, again as part of rendering (see our
annToAnsi function).

This approach comes with a number of nice properties for our use-case in
Blammo: it means the choice of colors-or-not, and what those colors are,
need not be known and passed around at the time log messages are
built. Rather, it is centralized at the place where the log messages
are rendered.

Therefore, I decided to lean into this and entirely replace our Color
module with the Terminal.Doc.Ann type. For example, there is no longer
a feature like getLoggerColors, which was meant to provide end-users
colors-or-not as appropriate. Instead, such users can use Ann all the
time and the colors-or-not concern is handled later.

Most users, those who are not actually building and pushing messages
directly to Logger, are not affected by this, but those that are will
require pretty big changes with this new version.

This change removes the manual `Text`-building of our current terminal formatter and instead uses `Prettyprinter`. This is a much better tool for the job and produces very nice output in less code. The actual resulting terminal output was improved in a few small ways: 1. The colors of attributes is improved, because `Prettyprinter`'s annotations system makes it easier to do fancier things 2. Long messages that themselves span the breakpoint are wrapped in a hanging-indent style, since that too is easier to do with `Prettyprinter`. It may have been possible to do this in a way opaque to end-users, except for one thing: colors. The best-practice way to ansi-escape `Prettyprinter` output is to use its annotations feature. Elements within a `Doc` are annotated with the bits that should be colored at render timer. It's also a best-practice to annotate your `Doc`, not directly with color escapes, but with semantic annotations (see our `Ann` type). Those can then be mapped centrally to color escapes, again as part of rendering (see our `annToAnsi` function). This approach comes with a number of nice properties for our use-case in Blammo: it means the choice of colors-or-not, and what those colors are, need not be known and passed around at the time log messages are _built_. Rather, it is centralized at the place where the log messages are rendered. Therefore, I decided to lean into this and entirely replace our `Color` module with the `Terminal.Doc.Ann` type. For example, there is no longer a feature like `getLoggerColors`, which was meant to provide end-users colors-or-not as appropriate. Instead, such users can use `Ann` all the time and the colors-or-not concern is handled later. Most users, those who are not actually building and pushing messages directly to `Logger`, are not affected by this, but those that are will require pretty big changes with this new version.

pbrisbin · 2025-12-08T15:52:15Z

 getLoggerReformat = lReformat

 setLoggerReformat
- :: (LogSettings -> Colors -> LogLevel -> LoggedMessage -> ByteString)


An example simplification: the "reformat" concern doesn't need the settings or colors because those are now only necessary for layout, which happens in the rendering step (where those things were already available).

- Add lts21, 22, and 24 - Symlink stack.yaml to latest (lts24)

pbrisbin · 2026-05-06T20:50:17Z

This is blocked on prettyprinteracquiring new maintainers and releasing a new version with "dim" support.

We could do it without dim, but I'd like to wait.

pbrisbin force-pushed the pb/pretty branch from 4f1ff79 to 80c1c0aCompare December 8, 2025 15:48

pbrisbin commented Dec 8, 2025
View reviewed changes

pbrisbin added 7 commits December 8, 2025 11:20

Set prettyprinter lower bound
ed8341a

Use Data.Aeson.Compat for Key type
b625c6f

Fixup stack resolvers
e646e94
- Add lts21, 22, and 24 - Symlink stack.yaml to latest (lts24)

Add prettyprinter extra-dep to lts16
44ebe3b

Tweak haddock
cf349bf

Add deterministic meta sorting to match test suite expectation
ede1de0

Sort lts16 extra-deps
d570f3c

pbrisbin force-pushed the pb/pretty branch from 4f1ff79 to 80c1c0aCompare December 8, 2025 15:48

pbrisbin commented Dec 8, 2025
View reviewed changes

pbrisbin added 7 commits December 8, 2025 11:20

Set prettyprinter lower bound
ed8341a

Use Data.Aeson.Compat for Key type
b625c6f

Fixup stack resolvers
e646e94
- Add lts21, 22, and 24 - Symlink stack.yaml to latest (lts24)

Add prettyprinter extra-dep to lts16
44ebe3b

Tweak haddock
cf349bf

Add deterministic meta sorting to match test suite expectation
ede1de0

Sort lts16 extra-deps
d570f3c

pbrisbin force-pushed the pb/pretty branch from 4f1ff79 to 80c1c0aCompare December 8, 2025 15:48

pbrisbin commented Dec 8, 2025
View reviewed changes

pbrisbin added 7 commits December 8, 2025 11:20

Set prettyprinter lower bound
ed8341a

Use Data.Aeson.Compat for Key type
b625c6f

Fixup stack resolvers
e646e94
- Add lts21, 22, and 24 - Symlink stack.yaml to latest (lts24)

Add prettyprinter extra-dep to lts16
44ebe3b

Tweak haddock
cf349bf

Add deterministic meta sorting to match test suite expectation
ede1de0

Sort lts16 extra-deps
d570f3c

pbrisbin force-pushed the pb/pretty branch from 4f1ff79 to 80c1c0aCompare December 8, 2025 15:48

pbrisbin commented Dec 8, 2025
View reviewed changes

pbrisbin added 7 commits December 8, 2025 11:20

Set prettyprinter lower bound
ed8341a

Use Data.Aeson.Compat for Key type
b625c6f

Fixup stack resolvers
e646e94
- Add lts21, 22, and 24 - Symlink stack.yaml to latest (lts24)

Add prettyprinter extra-dep to lts16
44ebe3b

Tweak haddock
cf349bf

Add deterministic meta sorting to match test suite expectation
ede1de0

Sort lts16 extra-deps
d570f3c

pbrisbin force-pushed the pb/pretty branch from 4f1ff79 to 80c1c0aCompare December 8, 2025 15:48

pbrisbin commented Dec 8, 2025
View reviewed changes

pbrisbin added 7 commits December 8, 2025 11:20

Set prettyprinter lower bound
ed8341a

Use Data.Aeson.Compat for Key type
b625c6f

Fixup stack resolvers
e646e94
- Add lts21, 22, and 24 - Symlink stack.yaml to latest (lts24)

Add prettyprinter extra-dep to lts16
44ebe3b

Tweak haddock
cf349bf

Add deterministic meta sorting to match test suite expectation
ede1de0

Sort lts16 extra-deps
d570f3c

pbrisbin force-pushed the pb/pretty branch from 4f1ff79 to 80c1c0aCompare December 8, 2025 15:48

pbrisbin commented Dec 8, 2025
View reviewed changes

pbrisbin added 7 commits December 8, 2025 11:20

Set prettyprinter lower bound
ed8341a

Use Data.Aeson.Compat for Key type
b625c6f

Fixup stack resolvers
e646e94
- Add lts21, 22, and 24 - Symlink stack.yaml to latest (lts24)

Add prettyprinter extra-dep to lts16
44ebe3b

Tweak haddock
cf349bf

Add deterministic meta sorting to match test suite expectation
ede1de0

Sort lts16 extra-deps
d570f3c

pbrisbin force-pushed the pb/pretty branch from 4f1ff79 to 80c1c0aCompare December 8, 2025 15:48

pbrisbin commented Dec 8, 2025
View reviewed changes

pbrisbin added 7 commits December 8, 2025 11:20

Set prettyprinter lower bound
ed8341a

Use Data.Aeson.Compat for Key type
b625c6f

Fixup stack resolvers
e646e94
- Add lts21, 22, and 24 - Symlink stack.yaml to latest (lts24)

Add prettyprinter extra-dep to lts16
44ebe3b

Tweak haddock
cf349bf

Add deterministic meta sorting to match test suite expectation
ede1de0

Sort lts16 extra-deps
d570f3c

pbrisbin force-pushed the pb/pretty branch from 4f1ff79 to 80c1c0aCompare December 8, 2025 15:48

pbrisbin commented Dec 8, 2025
View reviewed changes

pbrisbin added 7 commits December 8, 2025 11:20

Set prettyprinter lower bound
ed8341a

Use Data.Aeson.Compat for Key type
b625c6f

Fixup stack resolvers
e646e94
- Add lts21, 22, and 24 - Symlink stack.yaml to latest (lts24)

Add prettyprinter extra-dep to lts16
44ebe3b

Tweak haddock
cf349bf

Add deterministic meta sorting to match test suite expectation
ede1de0

Sort lts16 extra-deps
d570f3c

Uh oh!

Conversation

pbrisbin commented Dec 8, 2025• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Uh oh!

pbrisbinDec 8, 2025• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

pbrisbin commented May 6, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

1 participant

Uh oh!

Conversation

pbrisbin commented Dec 8, 2025• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Uh oh!

pbrisbinDec 8, 2025• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

pbrisbin commented May 6, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

1 participant

Uh oh!

Conversation

pbrisbin commented Dec 8, 2025• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Uh oh!

pbrisbinDec 8, 2025• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

pbrisbin commented May 6, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

1 participant

Uh oh!

Conversation

pbrisbin commented Dec 8, 2025• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Uh oh!

pbrisbinDec 8, 2025• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

pbrisbin commented May 6, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

1 participant

pbrisbin commented Dec 8, 2025•
edited
Loading

pbrisbinDec 8, 2025•
edited
Loading

pbrisbin commented Dec 8, 2025•
edited
Loading

pbrisbinDec 8, 2025•
edited
Loading

pbrisbin commented Dec 8, 2025•
edited
Loading

pbrisbinDec 8, 2025•
edited
Loading

pbrisbin commented Dec 8, 2025•
edited
Loading

pbrisbinDec 8, 2025•
edited
Loading

pbrisbin commented Dec 8, 2025•
edited
Loading

pbrisbinDec 8, 2025•
edited
Loading

pbrisbin commented Dec 8, 2025•
edited
Loading

pbrisbinDec 8, 2025•
edited
Loading