* try fix bad alignment in unicode (#1144)
* use width instead of count in wrap_line
* fix fmt
* 3 tests do not need fail
* fix tests
Co-authored-by: Thomas Otto <th1000s@posteo.net>
* ci: improve formatting
* ci.yaml: apply new formatting
* ci: release apple arm binary
* use cross for mac arm
* wip
* do not use cross
* install targets
* Stop ignoring a passing test
edits::tests::test_infer_edits_12 passes so there is no need to ignore
it.
* Refactor Levenshtein tests
Reduce the amount of repetition and specify the Levenshtein distance
explicitly in preparation for changing the Levenshtein calculation and
adding more tests in a future commit. As there are quite a few inputs to
each test use a struct rather than a plain function for the tests as
this effectively provides named parameters for the inputs.
* Highlight deletions before insertions
When a token has moved within a line try to highlight it as a deletion
followed by an insertion. Currently
-'b '
+' b'
is highlighted as
-'b[ ]'
+'[ ]b'
as if the space has moved to the left, instead highlight it as
-'[b] '
+' [b]'
as if the "b" has moved to the right. As the changes to the tests show
this also tends to favor a longer match at the start of the line.
* Don't highlight an unchanged trailing space
Only unchanged space between changed tokens should be highlighted, if
the line ends with an unchanged space then the space should not be
highlighted.
* Try to group highlighted changes together
Sometimes the highlighting of a change is not as clear as it could
be. For example the change
-printf "%s\n" s y y ...
+test_write_lines s y n ...
is highlighted as
-[printf "%]s[\n"] [s ]y y ...
+[test_write_lines ]s y y ...
rather than
-[printf "%s\n"] s y n ...
+[test_write_lines] s y y ...
This is because the Levenshtein distance calculation only checks if
the current tokens match without considering if the previous tokens
matched or not. Adding a small penalty for starting a run of changed
tokens forces the changes to be grouped together whenever possible. A
knock on effect of adding the penalty is that the cost a substitution
needs to be increased relative to the cost of an insertion/deletion
otherwise the lowest cost for "ab" -> "ba" is two substitutions rather
than an insertion, match and deletion.
There are several changes to the tests
- the Levenshtein distance is updated to reflect the new calculation in
tests::align::*
- several new tests are added to tests::align to check the grouping of
different combinations of insertions and deletions
- tests::edits::test_infer_edits_10 shows an improvement in the
highlighting as the unchanged space at the end of the changed tokens
is no longer highlighted. This is because it is no longer considered
to be deleted by the Levenshtein matching as deleting the space
between the deleted words now has a lower cost.
- there is a new test in tests::edits using the example in this
message.
* Stop using substitutions in Levenshtein calculation
Now that the lowest cost edit path groups deletions and insertions
together there seems to be little point in keeping substitutions. Indeed
the lower cost of substitutions compared to a deletion followed by an
insertion can adversely affect the highlighting. If the length of the
line does not change delta will prefer to use substitutions over
deletions and insertions even if it results in unchanged tokens being
marked as changed. For example in
-[a] a a a a a [b b b]
+[c] a a a a a [a c c]
unchanged tokens are marked as deleted and inserted. Without
substitutions this is highlighted as
-a a a a a a [b b b]
+[c ]a a a a a a [c c]
which highlights the insertion at the beginning of the line and the
change at the end of the line more clearly.
There is a change to the distance calculation as substitutions only
contributed the length of the deletion whereas now the same change will
add the length of both the deletion and the insertion. This is addressed
by doubling the contribution of unchanged sections so that the
denominator equals the sum of the distance contributions of the plus
line and minus line.
Remove Provides in Debian package as this is incorrect usage of this flag.
To provide two versions of packages `Conflicts` as used is sufficient.
See Debian Policy Manual (v4.6.1.1) section 7.5
When at it Remove trailing dot in Description header to comply with section 5.6.13
Fixes: https://github.com/dandavison/delta/issues/1210
Following fixes are included:
* derive_partial_eq_without_eq:
Eq trait was added by running `cargo clippy --fix --no-deps`.
* get_first:
Function was replaced by running `cargo clippy --fix --no-deps`.
* unnecessary_to_owned:
This check was disabled for ANSIString as to_string call is required
to enforce formatting. Otherwise the underlying string was returned
directly (probably due to Deref implementation).
* type_complexity:
Closure type was simplified and Box<> usage was removed.
* Fix git-grep match-highlighting at line-start
This commit fixes highlighting the part of the line of code that matches
the git grep query in cases where the match starts at the beginning of
the lines.
Fixes#1056.
* Fix handling of non-match highlight
In some cases, `git grep` will customize the foreground-color for more
than just the subset of the line that matches the grep pattern. This
breaks the current match-detection behavior, which considers any
characters with a non-default "foreground color" within the "code" part
of a git-grep-ouput-line to be part of the match. This commit makes
match-detection check for boldness and a red foreground instead of just
checking for a non-default foreground-color.
git grep matches are bold and red by default. But git grep isn't the
only reason input to delta may contain color codes; there may still be
cases where the highlighting looks wrong here.
Prior to this commit, syntax highlighting of scala code was not
correct in `git show $commit:$path` output. It was working for other
languages as far as I know. I'm not sure why.
