Basically, sorts from the lowest percentage to the highest.

Because seeing this is not very helpful to spot defects

The tests will not pass anymore because the golden file testing strategy is a nightmare to work with, especially when you have blank lines filled with spaces, as you can see on the screenshot below.

Thanks for this tool, it is very convenient !

Caught panic:

runtime error: invalid memory address or nil pointer dereference

Restoring terminal...

goroutine 1 [running]:
runtime/debug.Stack()
        /usr/lib/go/src/runtime/debug/stack.go:24 +0x65
runtime/debug.PrintStack()
        /usr/lib/go/src/runtime/debug/stack.go:16 +0x19
github.com/charmbracelet/bubbletea.(*Program).StartReturningModel.func3()
        /home/tyler/go/pkg/mod/github.com/charmbracelet/[email protected]/tea.go:350 +0x95
panic({0x52c720, 0x660ae0})
        /usr/lib/go/src/runtime/panic.go:1047 +0x266
github.com/charmbracelet/bubbles/list.(*Model).updatePagination(0xc00011ac80)
        /home/tyler/go/pkg/mod/github.com/charmbracelet/[email protected]/list/list.go:656 +0x2d1
github.com/charmbracelet/bubbles/list.(*Model).SetItems(0xc00011ac80, {0xc000110500, 0x4, 0x4})
        /home/tyler/go/pkg/mod/github.com/charmbracelet/[email protected]/list/list.go:293 +0x108
github.com/orlangure/gocovsh/internal/model.(*Model).onProfilesLoaded(0xc00011ac80, {0xc000070540, 0x4, 0x0})
        /home/tyler/go/pkg/mod/github.com/orlangure/[email protected]/internal/model/model.go:210 +0x2db
github.com/orlangure/gocovsh/internal/model.(*Model).Update(0xc00011ac80, {0x522f40, 0xc00000c0f0})
        /home/tyler/go/pkg/mod/github.com/orlangure/[email protected]/internal/model/model.go:100 +0x308
github.com/charmbracelet/bubbletea.(*Program).StartReturningModel(0xc000138180)
        /home/tyler/go/pkg/mod/github.com/charmbracelet/[email protected]/tea.go:534 +0x139c
github.com/charmbracelet/bubbletea.(*Program).Start(...)
        /home/tyler/go/pkg/mod/github.com/charmbracelet/[email protected]/tea.go:543
github.com/orlangure/gocovsh/internal/program.(*Program).Run(0xc0001280b0)
        /home/tyler/go/pkg/mod/github.com/orlangure/[email protected]/internal/program/program.go:116 +0x36c
main.main()
        /home/tyler/go/pkg/mod/github.com/orlangure/[email protected]/main.go:21 +0x119

Describe the bug It doesn't work on windows

To Reproduce Steps to reproduce the behavior:

1. go install github.com/orlangure/gocovsh@latest
2. cd Some/Directory
3. git clone https://github.com/tsoding/snitch
4. cd snitch
5. go test -v -cover -coverprofile coverage.out
6. gocovsh --profile coverage.out
7. Enter on a selected file.

Expected behavior File paths are relative in the cover.out file eg. github.com/tsoding/snitch/logcmd.go:26.33,28.4 1 0. I don't think this issue is package-specific (snitch).

Screenshots Files After Opening a file

Desktop (please complete the following information):

• OS: Windows 10
• Info:

    Edition	Windows 10 Home Single Language
    Version	21H1
    Installed on	‎8/‎7/‎2020
    OS build	19043.1566
    Experience	Windows Feature Experience Pack 120.2212.4170.0
  

• Terminal emulator: cmd.exe, clink, alacritty

Additional context Not sure if this is windows specific but I'm on windows.

Hello, Hi!! 👋🏻

I like your project and I think broader Go community will benefit from it too.

Thus, I added it to the curated list of Go tools.

I hope this badge will serve as a mark of quality and appreciation to your project.

Once again, thank you for your work!!

❤️

-- Nikolay

Changes made:

• [x] Created a Theme struct for new themes and used Catppuccin themes as a starting point.

Supported themes:

• Catppuccin "mocha", "macchiatto", and "latte" (light theme)
• Default (anything other than those values

One thing I noticed and haven't been able to debug is that the first time I run gocovsh it gives a nil pointer reference, but the second time I run it, there's no problem. Attached a GIF for your reference which includes a demo of both the error and the working style for latte theme.

#4

Model.list didn't get properly initialized until Model.updateWindowSize got called. In some situations onProfilesLoaded can arrive before the terminal dimensions have been retrieved however, and calling it will call updatePagination which accesses the still uninitialized (nil) item delegate. This causes a crash.

Fixes #38.

In addition to supporting file list input, this commit adds support for raw "git diff" output. In this case, only the changed files will appear, and only the lines marked as "added" in the diff will be shown. For every such line, its coverage status will be reported of course (red/green/gray).

This enables read build info both on binaries built by goreleaser, as well as installed with go install directly.

More info: https://carlosbecker.com/posts/supply-chain-goreleaser-go-mod-proxy/

In larger projects, running gocovsh after making a small change will cause redundant work to find the changed files in the long, multi-page list. This flow appears to be the most common for a routine work: usually the developer will want to view their change coverage, and not the entire project coverage.

To achieve this goal, the list of files should be piped into gocovsh. It allows to keep the "list" operation abstract: it can be a git diff with any arguments the user desires, if the result is a simple multi-line list of files.

For example, the suggested usage would be:

git diff --name-only | gocovsh		# view non-stashed changes
git diff --name-only master | gocovsh	# view changes relative to master

The value should be displayed in both list and code views:

• in list view, next to every file name
• in code view, either near the name at the top, or at the bottom near the progress indicator

After a couple usages the keys should be memorized, so the users might want to hide the help completely to add another row to the code view/list.

In the future, help section state will be persisted in the optional configuration file, so that for every new gocovsh session the menu will be in the selected state.

Closes #3

For larger projects, it might be useful to support sorting the entries in the list by their total coverage. Another potentially useful mode could be sorting by the number of non-covered statements: show the files with the most potential improvements to make first.

https://github.com/golang/tools/blob/master/cmd/cover/html.go includes the logic of the built-in html based coverage viewer. It uses boundary objects that essentially mark where to start every color block. It should be more precise and battle tested than the original procedure that I wrote.