Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

Settings: multiline / textarea editor for long string values

Open
  • Is something wrong?
#1,019 0 comments 1 reaction 0 assignees View on GitHub

Nobody has claimed this yet.

Assessment

Difficulty
3/5
Estimated time
1-2 days
Newbie friendliness
66/100
Issue type
Feature
Clarity
Mostly clear
Activity status
Quiet
Tech stack
rust
Domain
frontend

Research direction

Start by locating the settings UI that renders string values as single-line text boxes, then read how setting metadata such as $name is parsed and used by that editor. Add support for $multiline: true and verify users can enter and read back newline-containing values; a monospace font is optional. The issue names no files or tests, so identify the relevant UI tests before making the change.

Written by the indexing model from the issue text.

Description

enhancement
Summary

String settings render as a single-line text box. That makes any setting whose
value is content rather than a short scalar awkward to author and unpleasant
to read back. I'd like a way for a mod to mark a string setting as multiline,
e.g. $multiline: true, and have the settings UI render a textarea.

Why

The settings block is otherwise a good fit for per-user configuration: it is
versioned with the mod, editable without touching disk, and reachable from both
the GUI and windhawk-cli. But the single-line control quietly rules out a
whole category of settings — anything holding CSS, a snippet of script, a
template, a list of rules, a JSON blob, or a multi-line message.

Authors work around it by moving the content to a file and putting only a path
in settings. That works, but it gives up the things settings are good at: the
value no longer travels with the mod's configuration, it needs a second file to
exist at a path the user has to manage, and it can't be set in one
windhawk-cli mod settings set call.

Evidence

I hit this building a mod that injects user-supplied CSS into Electron apps. It
supports CSS from files and from an InlineStyles setting, so short tweaks
need nothing on disk. The setting's own description ended up reading:

The snippet itself. CSS ignores whitespace, so a one-liner is fine in this
single-line field.

That sentence is a workaround wearing a documentation hat. CSS tolerates being
squashed onto one line; most other content doesn't, and even for CSS it makes
the value unreadable once it's more than a couple of rules. Anything
substantial has to go back to a file.

Suggested shape
- Snippet: ""
  $name: CSS
  $multiline: true

Nice-to-haves, in descending order of value and ascending order of cost:

  • a monospace font in the textarea — most multiline values are code
  • a rows hint ($rows: 8) so the control sizes sensibly
  • a language hint ($language: css) for syntax highlighting

Only the first is needed for the feature to be worth having.

Notes

  • Storage and the CLI already handle multiline values — verified on
    2.0.0-alpha.2.     Setting a value containing a newline succeeds and round-trips
    intact:

    {"key":"remapFont1","value":"line1\nline2","previousValue":"Maple Mono NF"}
{"key":"remapFont1","value":"line1\nline2"}

    So this is purely a UI-affordance request. Nothing in the schema or the storage
    layer has to change — the value is already a string, newlines and all, and the
    only thing missing is a control that lets a user enter and read one.

  • The one wrinkle is plain-text CLI output, which prints one key=value per
    line, so a multiline value breaks the format visually. Restoring the test value
    printed:

    remapFont1: line1
line2 -> Maple Mono NF

    --json is unambiguous, so this is a documentation note ("use --json for
    multiline values in scripts"), not a blocker.

Tested on 2.0.0-alpha.2.

Dominant language
Rust
Stars
9.3k
Forks
246
No merged PRs in 30d

Getting set up

This project ships no dev container, Dockerfile or contributing guide, so setting up is up to you: start from its README, and see our first-contribution guide for the general steps.

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from ramensoftware/windhawk

All issues in ramensoftware/windhawk

Similar issues

More Rust issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.