The GitSignsStagedTopdeleteCul highlight (especially the foreground) was
very hard to read. It seems the issue was that
GitSignsStagedTopdeleteCul incorrectly derived from
GitSignsStagedChangeCul instead of the expected GitSignsChangedeleteCul.
So I think the fg_factor ended up being 0.5 of 0.5 equals .25,
foreground extremely dim.
Likely just a simply cut-and-paste oversight.
With this change the dim problem goes away.
The default filetype detection algorithm only checks the last lines of
.txt files for "ft=help" before setting the filetype to "text". Since
there was an empty line at the end, the help page was getting marked as
having filetype text first, and then help, which meant both autocmds
were triggered. This fixes that by removing the extraneous newline; note
that there is still a newline at the end of file, as is customary, and
this just removes the second, unnecessary newline.
Furthermore, this simplifies the logic for "gen_help.lua" and increases
its robustness by using the "io.lines" function rather than reading the
entire file as a string and using regular expressions to split it into
lines.
Now the watcher handlers is debounced and throttled, the ignore list
is no longer necessary.
This avoids an issue where we sometimes trigger the handler too early
(as other files are still changing). Now the debounce and throttle logic
and take into account every single file change.
- Ensure ':Gitsigns blame' utilizes the blame cache.
- Rewrite the blame runner to process output incrementally.
- Make the blame cache more efficient.
- Move the blame processing code to a separate module.
- Also make relative time the default time format for current_line_blame_formatter
- When `current_line_blame_formatter` is passed as a function it is no
longer passed an opts argument.
Artem Vasenin