feat: option to efficiently use horizontal space

[pankgeorg]

fixes: #73

[gemini-code-assist]

Summary of Changes

Hello @pankgeorg, I'm Gemini Code Assist¹! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!

This pull request introduces a new formatting option for the pretty formatter, messageNewLine, which allows users to control how log messages are displayed relative to their categories. By enabling this option, messages can be wrapped to a new line, effectively utilizing vertical space to conserve horizontal space, especially beneficial for terminals with limited width or when log entries have extensive metadata.

Highlights

• New messageNewLine Option: A new boolean option messageNewLine has been added to the pretty formatter configuration. When set to true, log messages will start on a new line, positioned below the log level and category, rather than continuing on the same line.
• Improved Horizontal Space Utilization: This feature addresses the need to efficiently use horizontal space, especially for long log messages or when displaying logs in narrow terminal windows, by leveraging vertical space instead.
• Adjusted Property Indentation: The formatting logic for log record properties has been updated to ensure proper indentation and alignment, adapting to whether the message starts on a new line or not.
• Comprehensive Test Coverage: A new dedicated test case has been added to verify the correct behavior and output format when the messageNewLine option is enabled, ensuring the feature works as intended.

Using Gemini Code Assist

The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.

Invoking Gemini

You can request assistance from Gemini at any point in your pull request via creating an issue comment (i.e. comment on the pull request page) using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands.

Feature	Command	Description
Code Review	/gemini review	Performs a code review for the current pull request in its current state.
Pull Request Summary	/gemini summary	Provides a summary of the current pull request in its current state.
Comment	@gemini-code-assist	Responds in comments when explicitly tagged, both in issue comments and review comments.
Help	/gemini help	Displays a list of available commands.

Customization

To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.

Limitations & Feedback

Gemini Code Assist is currently in preview and may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments to provide feedback.

You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension.

Footnotes

1. Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution. ↩

[gemini-code-assist]

Code Review

This pull request introduces a new messageNewLine option to the pretty formatter, allowing for more efficient use of horizontal space by placing the log message on a new line. The changes look good overall.

[dahlia]

Thanks for your contribution! Could you show me some screenshots with this new option?

[pankgeorg]

Thanks for your contribution! Could you show me some screenshots with this new option?

I'll get some nicer ones, but here is some for now!

compare this to

Not saying one is better (noone should be logging that much 🙈) but if you have to, the first is more compact :)

Thanks for your time in any case!

On a technical note, the magic constants (4, 6 etc) may be passed instead of the true; I'm not 100% sure how the API should look like. Please let me know of your thoughts!

[pankgeorg]

Hey @dahlia ! I cleaned this up a bit! Let me know if you need anything else!!

Here is also a script to test it

#!/usr/bin/env -S deno run --allow-all

import { configure, getLogger } from "./packages/logtape/src/mod.ts";
import { getPrettyFormatter } from "./packages/pretty/src/mod.ts";

// Configure logging with both formatters
const regularFormatter = getPrettyFormatter({
  colors: false,
  messageNewLine: false,
  properties: true,
});

const newLineFormatter = getPrettyFormatter({
  colors: false,
  messageNewLine: true,
  properties: true,
});

// Create a huge message (around 1000 characters)
const hugeMessage = "This is an extremely long log message that demonstrates the difference between regular formatting and the new messageNewLine option. " +
  "When you have very long messages like this one, the regular formatter will continue the message on the same line as the category, which can make it " +
  "difficult to read in narrow terminals or when you have long category names. The new messageNewLine option helps by placing the message on a new line " +
  "below the timestamp, level, and category information, which saves horizontal space and improves readability. This is particularly useful when you're " +
  "dealing with detailed log messages that contain lots of context information, error descriptions, or when you're logging complex data structures. " +
  "The feature addresses issue #73 by providing an efficient way to use horizontal space in logging output, making logs more readable in constrained environments " +
  "like narrow terminal windows or when viewing logs in split-pane editors where horizontal space is at a premium.";

console.log("=".repeat(80));
console.log("REGULAR FORMATTING (messageNewLine: false)");
console.log("=".repeat(80));

// Create a log record manually to format it
const logRecord = {
  level: "info" as const,
  category: ["my", "very", "long", "category", "name"],
  message: [hugeMessage],
  timestamp: Date.now(),
  properties: {
    userId: "12345",
    requestId: "abc-def-ghi",
    sessionId: "session-xyz-789",
    userAgent: "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36"
  }
};

const regularOutput = regularFormatter(logRecord);
console.log(regularOutput);

console.log("\n" + "=".repeat(80));
console.log("NEW LINE FORMATTING (messageNewLine: true)");
console.log("=".repeat(80));

const newLineOutput = newLineFormatter(logRecord);
console.log(newLineOutput);

console.log("=".repeat(80));
console.log("COMPARISON SUMMARY");
console.log("=".repeat(80));
console.log(`Regular output lines: ${regularOutput.split('\n').length - 1}`);
console.log(`NewLine output lines: ${newLineOutput.split('\n').length - 1}`);
console.log(`Message length: ${hugeMessage.length} characters`);

And some example output:

================================================================================
REGULAR FORMATTING (messageNewLine: false)
================================================================================
✨ info    my…name              This is an extremely long log
                                message that demonstrates the
                                difference between regular
                                formatting and the new
                                messageNewLine option. When you
                                have very long messages like this
                                one, the regular formatter will
                                continue the message on the same
                                line as the category, which can
                                make it difficult to read in
                                narrow terminals or when you have
                                long category names. The new
                                messageNewLine option helps by
                                placing the message on a new line
                                below the timestamp, level, and
                                category information, which saves
                                horizontal space and improves
                                readability. This is particularly
                                useful when you're dealing with
                                detailed log messages that
                                contain lots of context
                                information, error descriptions,
                                or when you're logging complex
                                data structures. The feature
                                addresses issue #73 by providing
                                an efficient way to use
                                horizontal space in logging
                                output, making logs more readable
                                in constrained environments like
                                narrow terminal windows or when
                                viewing logs in split-pane
                                editors where horizontal space is
                                at a premium.
                        userId: "12345"
                     requestId: "abc-def-ghi"
                     sessionId: "session-xyz-789"
                     userAgent: "Mozilla/5.0 (Windows NT 10.0;
                                Win64; x64) AppleWebKit/537.36"


================================================================================
NEW LINE FORMATTING (messageNewLine: true)
================================================================================
✨ info    my…name
    This is an extremely long log message that demonstrates the
    difference between regular formatting and the new
    messageNewLine option. When you have very long messages like
    this one, the regular formatter will continue the message on
    the same line as the category, which can make it difficult to
    read in narrow terminals or when you have long category
    names. The new messageNewLine option helps by placing the
    message on a new line below the timestamp, level, and
    category information, which saves horizontal space and
    improves readability. This is particularly useful when you're
    dealing with detailed log messages that contain lots of
    context information, error descriptions, or when you're
    logging complex data structures. The feature addresses issue
    #73 by providing an efficient way to use horizontal space in
    logging output, making logs more readable in constrained
    environments like narrow terminal windows or when viewing
    logs in split-pane editors where horizontal space is at a
    premium.
      userId: "12345"
      requestId: "abc-def-ghi"
      sessionId: "session-xyz-789"
      userAgent: "Mozilla/5.0 (Windows NT 10.0; Win64; x64)
    AppleWebKit/537.36"

================================================================================
COMPARISON SUMMARY
================================================================================
Regular output lines: 38
NewLine output lines: 24
Message length: 994 characters