git/userdiff.c, branch gitk-resize-error

userdiff-cpp: back out the digit-separators in numbers

2021-10-25T15:47:44Z

The implementation of digit-separating single-quotes introduced a note-worthy regression: the change of a character literal with a digit would splice the digit and the closing single-quote. For example, the change from 'a' to '2' is now tokenized as '[-a'-]{+2'+} instead of '[-a-]{+2+}'. The options to fix the regression are: - Tighten the regular expression such that the single-quote can only occur between digits (that would match the official syntax). - Remove support for digit separators. I chose to remove support, because - I have not seen a lot of code make use of digit separators. - If code does use digit separators, then the numbers are typically long. If a change in one of the segments occurs, it is actually better visible if only that segment is highlighted as the word that changed instead of the whole long number. This choice does introduce another minor regression, though, which is highlighted in the test case: when a change occurs in the second or later segment of a hexadecimal number where the segment begins with a digit, but also has letters, the segment is mistaken as consisting of a number and an identifier. I can live with that. Signed-off-by: Johannes Sixt Signed-off-by: Junio C Hamano

userdiff-cpp: learn the C++ spaceship operator

2021-10-10T22:24:21Z

Since C++20, the language has a generalized comparison operator <=>. Teach the cpp driver not to separate it into <= and > tokens. Signed-off-by: Johannes Sixt Signed-off-by: Junio C Hamano

userdiff-cpp: permit the digit-separating single-quote in numbers

2021-10-10T22:24:21Z

Since C++17, the single-quote can be used as digit separator: 3.141'592'654 1'000'000 0xdead'beaf Make it known to the word regex of the cpp driver, so that numbers are not split into separate tokens at the single-quotes. Signed-off-by: Johannes Sixt Signed-off-by: Junio C Hamano

userdiff-cpp: tighten word regex

2021-10-08T20:04:07Z

Generally, word regex can be written such that they match tokens liberally and need not model the actual syntax because it can be assumed that the regex will only be applied to syntactically correct text. The regex for cpp (C/C++) is too liberal, though. It regards these sequences as single tokens: 1+2 1.5-e+2+f and the following amalgams as one token: .l as in str.length .f as in str.find .e as in str.erase Tighten the regex in the following way: - Accept + and - only in one position in the exponent. + and - are no longer regarded as the sign of a number and are treated by the catcher-all that is not visible in the driver's regex. - Accept a leading decimal point only when it is followed by a digit. For readability, factor hex- and binary numbers into an own term. As a drive-by, this fixes that floating point numbers such as 12E5 (with upper-case E) were split into two tokens. Signed-off-by: Johannes Sixt Signed-off-by: Junio C Hamano

Merge branch 'uk/userdiff-php-enum'

2021-09-10T18:46:27Z

Update the userdiff pattern for PHP. * uk/userdiff-php-enum: userdiff: support enum keyword in PHP hunk header

userdiff: support enum keyword in PHP hunk header

2021-08-31T19:13:36Z

"enum" keyword will be introduced in PHP 8.1. https://wiki.php.net/rfc/enumerations Signed-off-by: USAMI Kenta Signed-off-by: Junio C Hamano

Merge branch 'th/userdiff-more-java'

2021-08-30T23:06:05Z

The userdiff pattern for "java" language has been updated. * th/userdiff-more-java: userdiff: improve java hunk header regex

Merge branch 'jc/userdiff-pattern-hint'

2021-08-30T23:06:03Z

Remind developers that the userdiff patterns should be kept simple and permissive, assuming that the contents they apply are always syntactically correct. * jc/userdiff-pattern-hint: userdiff: comment on the builtin patterns

userdiff: improve java hunk header regex

2021-08-11T18:11:30Z

Currently, the git diff hunk headers show the wrong method signature if the method has a qualified return type, an array return type, or a generic return type because the regex doesn't allow dots (.), [], or < and > in the return type. Also, type parameter declarations couldn't be matched. Add several t4018 tests asserting the right hunk headers for different cases: - enum constant change - change in generic method with bounded type parameters - change in generic method with wildcard - field change in a nested class Signed-off-by: Tassilo Horn Signed-off-by: Junio C Hamano

userdiff: comment on the builtin patterns

2021-08-11T18:02:59Z

Remind developers that they do not need to go overboard to implement patterns to prepare for invalid constructs. They only have to be sufficiently permissive, assuming that the payload is syntactically correct, and that may allow them to be simpler. Text stolen mostly from, and further improved by, Johannes Sixt. Signed-off-by: Junio C Hamano