[BUG] Command `zk --list` fails to encode correctly

[MrDwarf7]

Check if applicable

• [x] I have searched the existing issues (required)
• [x] I'm willing to help fix the problem and contribute a pull request

Describe the bug

Running zk list from the root after creating a new notebook and a new note (via zk new --title "Wow very cool") fails to correctly encode ascii escape sequences.

Running zk list outputs:

ESC[1;33mWow very coolESC[0m ESC[4;36my48e.mdESC[0m (11 minutes ago)

  ‣ Very interesting **AND** very cool!

ESC[1;33mwowESC[0m ESC[4;36mpr7b.mdESC[0m (5 minutes ago)

  ‣ Some text here!

(END)

Running zk list > t.txt && bat t.txt however will render correctly:

 ❯ zk list > t.txt && bat t.txt

Found 2 notes
───────┬────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────
       │ File: t.txt
───────┼────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────
   1   │ Wow very cool y48e.md (12 minutes ago)
   2   │
   3   │   ‣ Very interesting **AND** very cool!
   4   │
   5   │ wow pr7b.md (6 minutes ago)
   6   │
   7   │   ‣ Some text here!
   8   │
───────┴────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────

How to reproduce?

1. zk init zett
2. zk new --title "wow"
3. zk list

Observe broken output. Interestingly, running zk list > wow.txt followed by bat wow.txt will correctly handle the encoding output; displaying the little arrow and the various indentation(s) levels.

zk configuration

Entirely stock - Just installed it and it hasn't generated anything nor have I created one.

Environment

Direct output from copy paste:


zk 0.15.1
system: `uname -srmo`


Likely intended output:


zk 0.15.1
system: Linux 6.17.1-arch1-1 x86_64 GNU/Linux


-----------
prefer using something like: `bash -c 'zk --version && echo "system: `uname -srmo`"'` in your copy-paste block above for shell agnostic.

[MrDwarf7]

Note: I'm open to attempting a fix, but I'm primarily a Rust developer and don't generally write Go code lol

[mcDevnagh]

I'm not sure how it would fail to correctly encode ansi escape codes. We use https://github.com/fatih/color and it works on my machine

Can you set up the following test project on your system to verify its an issue with zk and not with your system or upstream?

./main.go

package main

import "github.com/fatih/color"

func main() {
	color.Yellow("YELLOW")
	color.Cyan("CYAN")
}

./go.mod

module test

go 1.21

require github.com/fatih/color v1.13.0

require (
	github.com/mattn/go-colorable v0.1.12 // indirect
	github.com/mattn/go-isatty v0.0.14 // indirect
	golang.org/x/sys v0.28.0 // indirect
)

you'll need to install go v1.21 then set up with $ go mod tidy and run with $ go run main.go

[MrDwarf7]

@mcDevnagh - I've setup a little project and tested it, these calls to the faith/color lib work fine.

When calling it these show up correctly as their respective colors on the command line.

I'm using fish inside of Ghostty as my terminal, but have also tested with WezTerm and the same outcome with encoding issues.

The lil hosting site for the imgs and terminal dump is this: https://0x0.st/ seen it mentioned in other repos (for screenshots etc).

Actual files in color here: zk_faith_color_test.png -> link zk_list_output.png -> link

Terminal output if its useful for you as well. test_bin_terminal_output.txt -> link

[WhyNotHugo]

I'm using fish inside of Ghostty as my terminal, but have also tested with WezTerm and the same outcome with encoding issues.

Can you try zsh or bash (on that same host/environment) and see if you get the same result? I want to discard some potential incompatibility with fish.

[MrDwarf7]

@WhyNotHugo - Still occurs via the use of bash and zsh

[tjex]

would it be possible to try with kitty? And running zk list -P -q (i.e, no pager and quiet) also yields the same result?

[MrDwarf7]

@tjex - Running via kitty terminal I tested running zk list -P -q for fish, bash and zsh; all of these output correctly (with correct colored sections for headers and filenames etc.).

[tjex]

So then it would seem like something is up with your pager no? (by dfault less, which can be troublesome with displaying colors properly, particulary when being piped to). Because zk is outputing color codes properly, as evinced by zk list -P -q. Without -P it gets piped to your pager, which is outside of zk's config / control.

[WhyNotHugo]

Does zk list --no-pager also print garbled results?

[MrDwarf7]

@WhyNotHugo - No, the pager causes the issue (-P <-> --no-pager from running zk list --help). I've run all of these commands from new shells or using no config options (for the shells), so as far as potential pager options go I'm not sure why the library that's used for this causes these problems.