* Handle a mode change on a renamed file.
I changed the diff parsing to cache the mode info from the old/new mode
lines until the parsing bumps into the start of the actual related diff,
finds the diff line for an unrelated diff, or runs out of input. This
allows the mode info to be output in conjunction with a file event
instead of as a separate heading (that used to have an empty name when
the mode change was for a rename).
The mode info is passed down into the draw routines as a separate
"addendum" string that the draw code can use as it likes. Currently that
means that it appends the addendum string to the non-raw string in
parens. I imagine that future draw routines could decide to put it in a
separate box or some other per-routine method. There is currently a
single function in src/handlers/draw.rs that joins the strings in the
same way for everyone.
A couple examples of how the new code looks:
Δ foo.rs (mode +x)
───────────────────────────────────────────────────
renamed: old-longer-name → shorter-name (mode +x)
───────────────────────────────────────────────────
Would it look better on its own line?
Δ foo.rs
• mode +x
───────────────────────────────────────────────────
renamed: old-longer-name → shorter-name
• mode +x
───────────────────────────────────────────────────
Would it look better appended after a "•" character?
Δ foo.rs • mode +x
───────────────────────────────────────────────────
renamed: old-longer-name → shorter-name • mode +x
───────────────────────────────────────────────────
Should it be a user option? If so, we can do that later.
Evolve grep output parsing heuristics
* Demand a non-space before extension
* New grep parse heuristic
If something like any of the following are seen then that is assumed
to be a file name with an extension followed by a line number. I.e. we
do not support file names with such patterns internally.
.xx-7-
.xx=7=
.xx:7:
* DeltaTest improvements
- Added .expect_contains(), .expect_raw_contains(), and
.expect_contains_once() member functions to DeltaTestOutput.
These functions also output some helpful debug info when the
assert fails.
- Separated .with_config_and_input() into .with_config() and (the
tweaked) .with_input().
- Made .with_config() create a DeltaTest object (like .with() does).
- Renamed .with() as .with_args().
- Moved .explain_ansi() from DeltaTestOutput to DeltaTest, which must
now be called prior to .with_input() since the latter stashes off both
the raw_output & the processed output in the object.
- Changed .expect() and .expect_skip() to return Self so that they can
continue a chain of multiple expect calls (e.g. a series of partial
matches with different skip values).
- The processed output text can be accessed via `test_obj.output` (see
also `test_obj.raw_output`).
- Renamed .expect_skip() to .expect_after_skip().
- Changed .expect() to start at the first line.
- Added .expect_after_header() that works like the old .expect().
- Renamed lines_match() to assert_lines_match() and made it match all
lines (no skip number).
- Added assert_lines_match_after_skip() to work like the old
lines_match() function, but with the .expect_after_skip() arg order.
- Converted some old-style tests into DeltaTest style tests.
- Renamed set_cfg as set_config
When using `--navigate` with files that get their mode modified, the
file-modified label was not being prefixed, so these changes were not
being marked as skip destinations. This is particularly bad if a file
has line changes along with the mode change AND the user has an empty
hunk label (since that would make the entire file's changes get skipped
with an "n").
I added a test of a mode-change with a line-change, and a test for a
mode change where the old & new mode values are not one of the two
expected value-pairs. I also used format_file() on the mode filenames
since the other format() calls were using it.
We currently have no way of computing correct line numbers: it seems that we would need to identify
wholly added and removed lines from the ANSI color sequences. side-by-side is (I imagine) almost
always used with line numbers, and it doesn't make much sense for word-diff anyway.
