mirror of
https://github.com/dandavison/delta.git
synced 2026-05-29 11:19:34 +02:00
Dan Davison
2 lines
1022 KiB
JSON
2 lines
1022 KiB
JSON
[{"body":"I use Kitty terminal and occasionally take advantage of its open hyperlink feature to edit files over ssh. \r\n\r\nFor any file, kitty creates a link like `file://{host}{path}`, and clicking the link opens my editor regardless of if the file is over ssh or not. Also this is defined by RFC 8089.\r\n\r\nAt this moment, delta creates links like `file://{path}`, and this makes kitty unable to open the correct file to edit over ssh.","comments":[],"number":1899,"title":"🚀 expose {host} or {url} in hyperlinks"},{"body":"I am using Ubuntu (WSL on Windows). The default `git diff` is immediate, while `delta` has a noticeable lag. As a rule of thumb, anything under 30ms feels immediate, but over 30ms you will notice a lag.\r\n\r\nI don't know if the issue is with `delta` itself, or if this extra 65ms overhead is caused by launching the `delta` program from `git`, but unfortunately that makes it too slow for me, since I want these command line tools to feel immediate, the extra lag distracts me.\r\n\r\nIn VSCode console, default `git diff`:\r\n```console\r\n$ time git diff\r\ndiff --git a/src/lfortran/parser/preprocessor.re b/src/lfortran/parser/preprocessor.re\r\nindex 1f39b3c58..67643a220 100644\r\n--- a/src/lfortran/parser/preprocessor.re\r\n+++ b/src/lfortran/parser/preprocessor.re\r\n@@ -433,7 +433,7 @@ std::string CPreprocessor::run(const std::string &input, LocationManager &lm,\r\n interval_end_type_0(lm, output.size(), cur-string_start);\r\n continue;\r\n }\r\n- \"#\" whitespace? \"include\" whitespace '\"' @t1 [^\"\\x00]* @t2 '\"' [^\\n\\x00]* newline {\r\n+ \"#\" whitespace? \"include\" whitespace ('\"' | '<') @t1 [^\"\\x00]* @t2 ('\"' | '>') [^\\n\\x00]* newline {\r\n if (!branch_enabled) continue;\r\n std::string filename = token(t1, t2);\r\n std::vector<std::filesystem::path> include_dirs;\r\n\r\nreal 0m0.011s\r\nuser 0m0.013s\r\nsys 0m0.000s\r\n```\r\nAnd `delta`:\r\n```console\r\n$ time git diff\r\n\r\nΔ src/lfortran/parser/preprocessor.re\r\n─────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────\r\n\r\n─────────────────────────────────────────────────────────────────────────────────────┐\r\n• 433: std::string CPreprocessor::run(const std::string &input, LocationManager &lm, │\r\n─────────────────────────────────────────────────────────────────────────────────────┘\r\n interval_end_type_0(lm, output.size(), cur-string_start);\r\n continue;\r\n }\r\n \"#\" whitespace? \"include\" whitespace '\"' @t1 [^\"\\x00]* @t2 '\"' [^\\n\\x00]* newline {\r\n \"#\" whitespace? \"include\" whitespace ('\"' | '<') @t1 [^\"\\x00]* @t2 ('\"' | '>') [^\\n\\x00]* newline {\r\n if (!branch_enabled) continue;\r\n std::string filename = token(t1, t2);\r\n std::vector<std::filesystem::path> include_dirs;\r\n\r\nreal 0m0.076s\r\nuser 0m0.034s\r\nsys 0m0.004s\r\n```\r\n\r\n\r\n\r\nI also tried the same thing directly in Terminal, and there I get 8ms with `git diff` and 27ms with `delta`, which is still a huge overhead, but fortunately it is under 30ms, and so it feels immediate.\r\n\r\nSo there are two separate issues:\r\n* large overhead of `delta` compared to native `git diff` (3x slower in Terminal, 6x slower in VSCode)\r\n* VSCode seems tiny bit slower for `git diff`, but a lot slower for `delta`\r\n\r\n\r\nIf you have any tips that I could try, let me know, I am happy to help debug.","comments":[{"id":"IC_kwDOC4j8g86TKAcE","author":{"login":"dandavison"},"authorAssociation":"OWNER","body":"Hi @certik,\r\n\r\nIt could well be time to do some profiling and optimization. I haven't profiled properly but from very quick ad-hoc experimenting it looks like I'm getting results that are similar to yours in some ways:\r\n\r\nThis is on a MacOS M2, testing a one-line diff via `git diff` like you:\r\n\r\n| | Without Delta | With Delta |\r\n|-----------|---------------|------------|\r\n| Alacritty | ~20ms | ~35-40ms |\r\n| VSCode | ~20ms | ~65-70ms |\r\n\r\n\r\nSo at minimum, it looks like we have one concrete question: why is delta slower in VSCode? Perhaps simply because delta emits more ANSI escape sequences and the VSCode terminal isn't performing as well on them as other terminal emulators?","createdAt":"2024-11-11T19:22:00Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[{"content":"THUMBS_UP","users":{"totalCount":1}}],"url":"https://github.com/dandavison/delta/issues/1897#issuecomment-2468873988","viewerDidAuthor":true},{"id":"IC_kwDOC4j8g86TKCl6","author":{"login":"certik"},"authorAssociation":"NONE","body":"@dandavison awesome, I am glad you can reproduce it on macOS also. \r\n\r\n\r\n\r\n> why is delta slower in VSCode? Perhaps simply because delta emits more ANSI escape sequences and the VSCode terminal isn't performing as well on them as other terminal emulators?\r\n\r\nLet's figure it out: we can test this hypothesis by making `delta` emit output without ANSI escape sequences, to either confirm or rule it out. This would be useful even for Alacritty / Terminal to see if they get faster.\r\n\r\nNote: I installed `delta` using conda-forge, here is the build command: https://github.com/conda-forge/git-delta-feedstock/blob/565fea2fbdf4aea4f40a88d260445be75b3b7d62/recipe/build.sh#L13, I think this builds with Rust in Release mode (enables all optimizations)?","createdAt":"2024-11-11T19:28:08Z","includesCreatedEdit":true,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/1897#issuecomment-2468882810","viewerDidAuthor":false},{"id":"IC_kwDOC4j8g86TKG0e","author":{"login":"dandavison"},"authorAssociation":"OWNER","body":"Here's another experiment. This experiment does not involve the terminal emulator rendering anything, and it doesn't involve git invoking delta; instead we invoke delta explicitly via a shell pipe. This seems to suggest that (a) delta's execution costs around 6ms and (b) much of the total execution time of delta is due to terminal emulator activity, especially in VSCode.\r\n\r\n(You probably know this, but beware of things like `git diff > /dev/null` -- git will not invoke delta even if it's configured to do so.)\r\n\r\n### Alacritty\r\n\r\n```\r\n$ hyperfine --warmup 500 'git diff | delta > /dev/null'\r\nBenchmark 1: git diff | delta > /dev/null\r\n Time (mean ± σ): 14.2 ms ± 2.4 ms [User: 9.5 ms, System: 7.7 ms]\r\n Range (min … max): 10.0 ms … 21.1 ms 117 runs\r\n\r\n$ hyperfine --warmup 500 'git diff > /dev/null'\r\nBenchmark 1: git diff > /dev/null\r\n Time (mean ± σ): 8.7 ms ± 2.0 ms [User: 3.4 ms, System: 3.3 ms]\r\n Range (min … max): 5.6 ms … 14.9 ms 146 runs\r\n```\r\n\r\n\r\n### VSCode\r\n```\r\n$ hyperfine --warmup 500 'git diff | delta > /dev/null'\r\nBenchmark 1: git diff | delta > /dev/null\r\n Time (mean ± σ): 14.9 ms ± 2.8 ms [User: 10.3 ms, System: 7.5 ms]\r\n Range (min … max): 10.1 ms … 30.1 ms 109 runs\r\n \r\n\r\n$ hyperfine --warmup 500 'git diff > /dev/null'\r\nBenchmark 1: git diff > /dev/null\r\n Time (mean ± σ): 8.0 ms ± 3.2 ms [User: 3.4 ms, System: 3.6 ms]\r\n Range (min … max): 2.8 ms … 21.6 ms 132 runs\r\n```","createdAt":"2024-11-11T19:40:05Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/1897#issuecomment-2468900126","viewerDidAuthor":true}],"number":1897,"title":"🐛 delta is slow (noticeable lag) compared to default diff (11ms -> 76ms) in VSCode"},{"body":"raw text output from `git --no-pager diff ...`\r\n```\r\ndiff --git a/.gitignore b/.gitignore\r\nindex 2659310..5e94189 100644\r\n--- a/.gitignore\r\n+++ b/.gitignore\r\n@@ -61,3 +61,4 @@ venv/\r\n\r\n # specific to this project:\r\n sandbox.ipynb\r\n+sandbox.py\r\n```\r\n\r\nDelta's output `git --no-pager diff ... | delta --show-themes`\r\n```\r\n• .gitignore:61: venv/\r\n────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────\r\n 61 ⋮.gitignore│\r\n 62 ⋮.gitignore│# specific to this project:\r\n 63 ⋮.gitignore│sandbox.ipynb\r\n ⋮.gitignore│sandbox.py\r\n\r\n\r\nTheme: calochortus-lyallii\r\n\r\n\r\n[M] .gitignore\r\n\r\n• .gitignore:61: venv/\r\n 61 ⋮.gitignore│\r\n 62 ⋮.gitignore│# specific to this project:\r\n 63 ⋮.gitignore│sandbox.ipynb\r\n ⋮.gitignore│sandbox.py\r\n\r\n```\r\n[output truncated]\r\n\r\nnotice the .gitignore instead of the linenumber.","comments":[],"number":1887,"title":"🐛 show-themes right-side-line-numbers qreplaced with filename"},{"body":"Hi, I've noticed that delta highlights poorly this diff: \r\n[deltabug.txt](https://github.com/user-attachments/files/17453082/deltabug.txt)\r\n\r\nThe result:\r\n\r\n\r\nIf I remove a couple of lines in the middle, the pairing is good ([deltabug-ok.txt](https://github.com/user-attachments/files/17453090/deltabug-ok.txt)):\r\n\r\n\r\n\r\ndelta version is 0.18.2","comments":[],"number":1882,"title":"🐛 Unfortunate pairing when commenting out a large chunk of code"},{"body":"It seems like there is a race condition between delta and less when setting the terminal raw mode. See details in https://github.com/gwsw/less/issues/579.\r\n\r\n---\r\n\r\nRaw diff output:\r\n\r\n```diff\r\ndiff --git a/bun.lockb b/bun.lockb\r\nindex 6e77ff9..5ad9c73 100755\r\n--- a/bun.lockb\r\n+++ b/bun.lockb\r\n@@ -1,30 +1,30 @@\r\n # THIS IS AN AUTOGENERATED FILE. DO NOT EDIT THIS FILE DIRECTLY.\r\n # yarn lockfile v1\r\n-# bun ./bun.lockb --hash: E7A8918271656BAE-4fe268304deac5d4-4AD032B6865CD714-16943c77077cbeeb\r\n+# bun ./bun.lockb --hash: 974DCA90254370C7-0f6e1b631608181f-F5E2DDA39E8F3ADB-92ef899f5f642846\r\n \r\n \r\n \"@babel/code-frame@^7.0.0\":\r\n- version \"7.24.7\"\r\n- resolved \"https://registry.npmjs.org/@babel/code-frame/-/code-frame-7.24.7.tgz\"\r\n- integrity sha512-BcYH1CVJBO9tvyIZ2jVeXgSIMvGZ2FDRvDdOIVQyuklNKSsx+eppDEBq/g47Ayw+RqNFE+URvOShmf+f/qwAlA==\r\n+ version \"7.25.7\"\r\n+ resolved \"https://registry.npmjs.org/@babel/code-frame/-/code-frame-7.25.7.tgz\"\r\n+ integrity sha512-0xZJFNE5XMpENsgfHYTw8FbX4kv53mFLn2i3XPoq69LyhYSCBJtitaHx9QnsVTrsogI4Z3+HtEfZ2/GFPOtf5g==\r\n dependencies:\r\n+ \"@babel/highlight\" \"^7.25.7\"\r\n picocolors \"^1.0.0\"\r\n- \"@babel/highlight\" \"^7.24.7\"\r\n \r\n-\"@babel/helper-validator-identifier@^7.24.7\":\r\n- version \"7.24.7\"\r\n- resolved \"https://registry.npmjs.org/@babel/helper-validator-identifier/-/helper-validator-identifier-7.24.7.tgz\"\r\n- integrity sha512-rR+PBcQ1SMQDDyF6X0wxtG8QyLCgUB0eRAGguqRLfkCA87l7yAP7ehq8SNj96OOGTO8OBV70KhuFYcIkHXOg0w==\r\n+\"@babel/helper-validator-identifier@^7.25.7\":\r\n+ version \"7.25.7\"\r\n+ resolved \"https://registry.npmjs.org/@babel/helper-validator-identifier/-/helper-validator-identifier-7.25.7.tgz\"\r\n+ integrity sha512-AM6TzwYqGChO45oiuPqwL2t20/HdMC1rTPAesnBCgPCSF1x3oN9MVUwQV2iyz4xqWrctwK5RNC8LV22kaQCNYg==\r\n \r\n-\"@babel/highlight@^7.24.7\":\r\n- version \"7.24.7\"\r\n- resolved \"https://registry.npmjs.org/@babel/highlight/-/highlight-7.24.7.tgz\"\r\n- integrity sha512-EStJpq4OuY8xYfhGVXngigBJRWxftKX9ksiGDnmlY3o7B/V7KIAc9X4oiK87uPJSc/vs5L869bem5fhZa8caZw==\r\n+\"@babel/highlight@^7.25.7\":\r\n+ version \"7.25.7\"\r\n+ resolved \"https://registry.npmjs.org/@babel/highlight/-/highlight-7.25.7.tgz\"\r\n+ integrity sha512-iYyACpW3iW8Fw+ZybQK+drQre+ns/tKpXbNESfrhNnPLIklLbXr7MYJ6gPEd0iETGLOK+SxMjVvKb/ffmk+FEw==\r\n dependencies:\r\n+ \"@babel/helper-validator-identifier\" \"^7.25.7\"\r\n chalk \"^2.4.2\"\r\n js-tokens \"^4.0.0\"\r\n picocolors \"^1.0.0\"\r\n- \"@babel/helper-validator-identifier\" \"^7.24.7\"\r\n \r\n \"@eslint/eslintrc@^0.3.0\":\r\n version \"0.3.0\"\r\n@@ -527,9 +527,9 @@ eslint-import-resolver-node@^0.3.6:\r\n resolve \"^1.22.4\"\r\n \r\n eslint-module-utils@^2.6.2:\r\n- version \"2.11.0\"\r\n- resolved \"https://registry.npmjs.org/eslint-module-utils/-/eslint-module-utils-2.11.0.tgz\"\r\n- integrity sha512-gbBE5Hitek/oG6MUVj6sFuzEjA/ClzNflVrLovHi/JgLdC7fiN5gLAY1WIPW1a0V5I999MnsrvVrCOGmmVqDBQ==\r\n+ version \"2.12.0\"\r\n+ resolved \"https://registry.npmjs.org/eslint-module-utils/-/eslint-module-utils-2.12.0.tgz\"\r\n+ integrity sha512-wALZ0HFoytlyh/1+4wuZ9FJCD/leWHQzzrxJ8+rebyReSLk7LApMyd3WJaLVoN+D5+WIdJyDK1c6JnE65V4Zyg==\r\n dependencies:\r\n debug \"^3.2.7\"\r\n \r\n@@ -682,9 +682,9 @@ fast-levenshtein@^2.0.6:\r\n integrity sha512-DCXu6Ifhqcks7TZKY3Hxp3y6qphY5SJZmrWMDrKcERSOXWQdMhU9Ig/PYrzyw/ul9jOIyh0N4M0tbC5hodg8dw==\r\n \r\n fast-uri@^3.0.1:\r\n- version \"3.0.1\"\r\n- resolved \"https://registry.npmjs.org/fast-uri/-/fast-uri-3.0.1.tgz\"\r\n- integrity sha512-MWipKbbYiYI0UC7cl8m/i/IWTqfC8YXsqjzybjddLsFjStroQzsHXkc73JutMvBiXmOvapk+axIl79ig5t55Bw==\r\n+ version \"3.0.3\"\r\n+ resolved \"https://registry.npmjs.org/fast-uri/-/fast-uri-3.0.3.tgz\"\r\n+ integrity sha512-aLrHthzCjH5He4Z2H9YZ+v6Ujb9ocRuW6ZzkJQOrTxleEijANq4v1TsaPaVG1PZcuurEzrLcWRyYBYXD5cEiaw==\r\n \r\n file-entry-cache@^6.0.0:\r\n version \"6.0.1\"\r\n@@ -712,9 +712,9 @@ flat-cache@^3.0.4:\r\n resolved \"https://registry.npmjs.org/flat-cache/-/flat-cache-3.2.0.tgz\"\r\n integrity sha512-CYcENa+FtcUKLmhhqyctpclsq7QF38pKjZHsGNiSQF5r4FtoKDWabFDl3hzaEQMvT1LHEysw5twgLvpYYb4vbw==\r\n dependencies:\r\n- flatted \"^3.2.9\"\r\n keyv \"^4.5.3\"\r\n rimraf \"^3.0.2\"\r\n+ flatted \"^3.2.9\"\r\n \r\n flatted@^3.2.9:\r\n version \"3.3.1\"\r\n@@ -1389,9 +1389,9 @@ path-type@^3.0.0:\r\n pify \"^3.0.0\"\r\n \r\n picocolors@^1.0.0:\r\n- version \"1.1.0\"\r\n- resolved \"https://registry.npmjs.org/picocolors/-/picocolors-1.1.0.tgz\"\r\n- integrity sha512-TQ92mBOW0l3LeMeyLV6mzy/kWr8lkd/hp3mTg7wYK7zJhuBStmGMBG0BdeDZS/dZx1IukaX6Bk11zcln25o1Aw==\r\n+ version \"1.1.1\"\r\n+ resolved \"https://registry.npmjs.org/picocolors/-/picocolors-1.1.1.tgz\"\r\n+ integrity sha512-xceH2snhtb5M9liqDsmEw56le376mTZkEX/jEb/RxNFyegNul7eNslCXP9FDj/Lcu0X8KEyMceP2ntpaHrDEVA==\r\n \r\n pify@^3.0.0:\r\n version \"3.0.0\"\r\n@@ -1470,14 +1470,14 @@ read-pkg-up@^3.0.0:\r\n read-pkg \"^3.0.0\"\r\n \r\n regexp.prototype.flags@^1.5.2:\r\n- version \"1.5.2\"\r\n- resolved \"https://registry.npmjs.org/regexp.prototype.flags/-/regexp.prototype.flags-1.5.2.tgz\"\r\n- integrity sha512-NcDiDkTLuPR+++OCKB0nWafEmhg/Da8aUPLPMQbK+bxKKCm1/S5he+AqYa4PlMCVBalb4/yxIRub6qkEx5yJbw==\r\n+ version \"1.5.3\"\r\n+ resolved \"https://registry.npmjs.org/regexp.prototype.flags/-/regexp.prototype.flags-1.5.3.tgz\"\r\n+ integrity sha512-vqlC04+RQoFalODCbCumG2xIOvapzVMHwsyIGM/SIE8fRhFFsXeH8/QQ+s0T0kDAhKc4k30s73/0ydkHQz6HlQ==\r\n dependencies:\r\n- call-bind \"^1.0.6\"\r\n+ call-bind \"^1.0.7\"\r\n define-properties \"^1.2.1\"\r\n es-errors \"^1.3.0\"\r\n- set-function-name \"^2.0.1\"\r\n+ set-function-name \"^2.0.2\"\r\n \r\n regexpp@^3.0.0, regexpp@^3.1.0:\r\n version \"3.2.0\"\r\n@@ -1565,7 +1565,7 @@ set-function-length@^1.2.1:\r\n gopd \"^1.0.1\"\r\n has-property-descriptors \"^1.0.2\"\r\n \r\n-set-function-name@^2.0.1, set-function-name@^2.0.2:\r\n+set-function-name@^2.0.2:\r\n version \"2.0.2\"\r\n resolved \"https://registry.npmjs.org/set-function-name/-/set-function-name-2.0.2.tgz\"\r\n integrity sha512-7PGFlmtwsEADb0WYyvCMa1t+yke6daIG4Wirafur5kcf+MhUnPms1UeR0CKQdTZD81yESwMHbtn+TR+dMviakQ==\r\n```","comments":[{"id":"IC_kwDOC4j8g86QRb2E","author":{"login":"avih"},"authorAssociation":"NONE","body":"Just to add here what the linked \"less\" issue has, and might be related:\r\n\r\nOn Windows delta sets the console codepage to UTF8 even when stdout is not a tty, which causes issues when piped to other applications (because it restores the codepage when delta exits, but the other app doesn't know that).\r\n\r\nSo it might be a general delta issue where the terminal is initialized even when stdout is not a tty - but in such case it shouldn't touch the terminal state.","createdAt":"2024-10-17T20:26:35Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/1880#issuecomment-2420489604","viewerDidAuthor":false},{"id":"IC_kwDOC4j8g86QRd-F","author":{"login":"injust"},"authorAssociation":"CONTRIBUTOR","body":"> On Windows delta sets the console codepage to UTF8 even when stdout is not a tty, which causes issues when piped to other applications\r\n\r\nJust to clarify: For my problem, stdout _is_ a tty. I am not piping delta to less -- delta is running less by itself. So from delta's perspective, stdout is a tty.","createdAt":"2024-10-17T20:32:09Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/1880#issuecomment-2420498309","viewerDidAuthor":false},{"id":"IC_kwDOC4j8g86QRfXY","author":{"login":"avih"},"authorAssociation":"NONE","body":"> Just to clarify: For my problem, stdout _is_ a tty. I am not piping delta to less -- delta is running less by itself. So from delta's perspective, stdout is a tty.\r\n\r\nOh. But still, depending on how it's implemented, it might still be piping into less. But good point. I didn't realize it's not piped into less \"externally\".","createdAt":"2024-10-17T20:35:30Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/1880#issuecomment-2420504024","viewerDidAuthor":false}],"number":1880,"title":"🐛 Terminal raw mode race condition with less"},{"body":"When using `git {add,reset,...} -p`, I'd like the screen to be cleared for each hunk. When adding changes that mix a lot of single line edits that sometimes present as a single hunk and other times are grouped together, it's easy to accidentally review only the final part of a hunk. For example, this diff:\r\n\r\n```diff\r\n@@ -267,7 +259,7 @@ class MyClass:\r\n\r\n @final\r\n-class MyClass2(Gen[Old]):\r\n+class MyClass2(Gen[New]):\r\n\r\n(3/13) Apply this hunk to index [y,n,q,a,d,K,j,J,g,/,e,p,?]? y\r\n@@ -276,7 +268,7 @@ class MyClass2(New):\r\n\r\n- def a(self, deps: Old):\r\n+ def a(self, deps: New):\r\n return 42\r\n\r\n(4/13) Apply this hunk to index [y,n,q,a,d,K,j,J,g,/,e,p,?]? y\r\n@@ -287,23 +279,23 @@ class MyClass2(New):\r\n\r\n- def b(self, deps: Old):\r\n+ def b(self, deps: New\r\n return 42\r\n\r\n- def c(self, deps: Old):\r\n+ def c(self, deps: New):\r\n return 42\r\n\r\n- def d(self, deps: Old)\r\n+ def d(self, deps: New)\r\n return 42\r\n\r\n- def e(self, deps: Old):\r\n+ def e(self, deps: New):\r\n return 42\r\n(5/13) Apply this hunk to index [y,n,q,a,d,K,j,J,g,/,s,e,p,?]? n\r\n```\r\n\r\nwill print one after the other so the prompt is *always* at the bottom of the screen and the bottom part of each hunk looks about the same when churning through a lot of these. However, note that the last hunk groups multiple edits and has a bug where the `b` method is missing the trailing `):` - but that's easy to miss when your eyes are trained to focus on the bottom of the page (just above the prompt).\r\n\r\nInstead, I'd like the page to be cleared before showing each hunk so that each hunk effectively starts from the top of the console. This way, there will be a much better visual cue that a hunk is larger/smaller than the last (which might prompt you to split it).","comments":[{"id":"IC_kwDOC4j8g86PiIbV","author":{"login":"bash"},"authorAssociation":"CONTRIBUTOR","body":"Maybe setting [`interactive.diffFilter`](https://git-scm.com/docs/git-config#Documentation/git-config.txt-interactivediffFilter) to something like `clear; delta --color-only --features=interactive` already does the trick (I'm not on my computer atm so can't test this myself). ","createdAt":"2024-10-11T20:36:11Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/1875#issuecomment-2408089301","viewerDidAuthor":false}],"number":1875,"title":"🚀 Clear the screen before each hunk when using `--patch`"},{"body":"So far it's only the `-` character that I've noticed.\r\n\r\nthing | value\r\n--- | ---\r\ndelta | 0.18.2\r\ngit | 2.39.5\r\nLANG | en_US.UTF-8\r\nPRETTY_NAME | Debian GNU/Linux 12 (bookworm)\r\n\r\n### Raw output:\r\n```\r\n$ git --no-pager grep --name-only airflow:CreateCli\r\ndev-account/policy.tf\r\n```\r\n### Delta output:\r\n```\r\n$ git config pager.grep\r\ndelta\r\n\r\n$ git grep --name-only airflow:CreateCli\r\n dev:account/policy.tf\r\n```\r\n\r\n### Delta output without --name-only\r\n```\r\n$ git grep airflow:CreateCli\r\n dev-account/policy.tf: \"airflow:CreateCliToken\",\r\n```\r\n","comments":[{"id":"IC_kwDOC4j8g86QRFCK","author":{"login":"lucasoshiro"},"authorAssociation":"NONE","body":"I just found the same thing here. At first I thought it was a Git bug, but I inspected it and it only happens when using `delta` as pager.\r\n\r\nIt also happens when `git grep`ping binary files","createdAt":"2024-10-17T19:48:24Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/1869#issuecomment-2420396170","viewerDidAuthor":false},{"id":"IC_kwDOC4j8g86QRmnX","author":{"login":"dandavison"},"authorAssociation":"OWNER","body":"Hi, thanks for the report. Perhaps delta can be modified to behave differently when `--name-only` is in effect; either by inferring that from the output, or by inspecting the calling process command line (we are already forced to do this in some other situations, so there are utilities to do it performantly).\r\n\r\nIn general, traditional grep output (i.e. not the sort produced by `--name-only`) is subject to inevitable parse ambiguities involving the separator characters used. So, I think that's what's going on here, but like I say, if we actually know we're working with `--name-only` then we shouldn't be getting it wrong! Also not claiming that delta's regexps are optimal -- there are lots of tests and we'd welcome improvements to them -- I'm just claiming that there's not a perfect solution.\r\n\r\nI know that `git grep` does things that `ripgrep` cannot but, if it is an option, then do consider `rg --json` since then there are no parse ambiguities.","createdAt":"2024-10-17T20:42:17Z","includesCreatedEdit":true,"isMinimized":false,"minimizedReason":"","reactionGroups":[{"content":"THUMBS_UP","users":{"totalCount":1}}],"url":"https://github.com/dandavison/delta/issues/1869#issuecomment-2420533719","viewerDidAuthor":true}],"number":1869,"title":"🐛 delta replaces characters when used with `git grep --name-only`"},{"body":"It would be great if Delta was published to PyPi so I could add Delta as a dependency to my Python project to ensure the executable exists and is installed automatically along with my Python package. Several other Rust projects publish to PyPi today (e.g., [git-cliff](https://github.com/orhun/git-cliff)).\r\n","comments":[],"number":1867,"title":"🚀 Publish to PyPi"},{"body":"It seems there's a naming convention there: despite the config names being case-insensitive, they don't usually have dashes in them. Git went so far as to deprecate some dash spellings (kebab case) in favor or dash-less. And they're usually documented in lowerCamelCase (a.k.a. dromedary case).\r\n\r\nI was looking at my git config and realized delta configuration requires the dashes. Can we make them optional so `delta.lineNumbers` work just as well as `delta.line-numbers`?","comments":[],"number":1866,"title":"🚀 Use lowerCamelCase for configurations in git config file"},{"body":"Delta currently has an amazing support for git patch files (generated with `git format-patch`). But it would be nice if delta had some level of syntax highlight also in the patch frontmatter just like some terminal text editors do when one's writting a commit.\r\n\r\nFields like `Subject`, `From`, `Date`, etc could be colored with some special color, and also email strings like `<me@mymail.com>`\r\n\r\n## Example\r\n\r\nHelix editor: the `signed-off-by` and other markers in the footer of a commit message are highlighted.\r\n\r\n\r\n","comments":[{"id":"IC_kwDOC4j8g86MwSui","author":{"login":"dandavison"},"authorAssociation":"OWNER","body":"Hi @OJarrisonn, could you post an example plain text snippet that you'd like delta to syntax highlight?","createdAt":"2024-09-19T16:23:50Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/1863#issuecomment-2361469858","viewerDidAuthor":true},{"id":"IC_kwDOC4j8g86Mxd_a","author":{"login":"OJarrisonn"},"authorAssociation":"NONE","body":"Sure thing\r\n\r\n```\r\nFrom git@z Thu Jan 1 00:00:00 1970\r\nSubject: [PATCH v1 1/2] accel-config/test: Add parameter for specifying dev\r\n and wq\r\nFrom: Rex Zhang <rex.zhang@intel.com>\r\nDate: Wed, 25 Oct 2023 16:52:58 +0800\r\nMessage-Id: <20231025085259.2958695-1-rex.zhang@intel.com>\r\nMIME-Version: 1.0\r\nContent-Type: text/plain; charset=\"utf-8\"\r\nContent-Transfer-Encoding: 7bit\r\n\r\nAbout the script iaa_user_test_runner.sh, previously, the only one behavior\r\nis to enable dev and wq firstly than invoke iaa_test, then the iaa_test\r\nwill find which dev and wq are enabled automatically.\r\nFor enabling the dev and wq outside the script, the script indentify the\r\nenabled dev and wq, then pass the dev and wq into iaa_test as a parameter.\r\n\r\nSigned-off-by: Rex Zhang <rex.zhang@intel.com>\r\n---\r\n test/iaa_user_test_runner.sh | 149 +++++++++++++++++++----------------\r\n 1 file changed, 83 insertions(+), 66 deletions(-)\r\n\r\ndiff --git a/test/iaa_user_test_runner.sh b/test/iaa_user_test_runner.sh\r\nindex e3a6663..d85d043 100755\r\n--- a/test/iaa_user_test_runner.sh\r\n+++ b/test/iaa_user_test_runner.sh\r\n@@ -6,7 +6,18 @@\r\n \r\n rc=\"$EXIT_SKIP\"\r\n \r\n-IAA=iax1\r\n+DEV_OPT=\"\"\r\n+input1=$1\r\n+if [ \"$input1\" == \"--skip-config\" ]; then\r\n+ DEV=`ls /dev/iax/ | sed -ne 's|wq\\([^.]\\+\\)\\(.*\\)|iax\\1/wq\\1\\2|p'`\r\n+ DEV=`echo $DEV | cut -f1 -d' '`\r\n+ IAA=`echo $DEV | cut -f1 -d/`\r\n+ DEV_OPT=\"-d $DEV\"\r\n+ echo \"$DEV\"\r\n+else\r\n+ IAA=iax1\r\n+fi\r\n+echo \"$IAA\"\r\n WQ0=wq1.4\r\n WQ1=wq1.1\r\n DBDF=`ls -l /sys/bus/dsa/devices/iax3 | awk -F '/' '{print $(NF - 1)}'`\r\n@@ -149,10 +160,10 @@ test_op()\r\n if [ \"$extra_flag\" != \"\" ]\r\n then\r\n \"$IAATEST\" -w \"$wq_mode_code\" -l \"$xfer_size\" -o \"$opcode\" \\\r\n- -f \"$flag\" -1 \"$extra_flag\" -t 5000 -v\r\n```\r\n\r\nThis is part of a patch from lore.kernel.org. It would be cool if delta could both render the diff part at the bottom and highlight the fields (like `Date: `, `Message-Id: `, `[PATCH v1 1/2] `, etc) at the frontmatter (before the `---`)","createdAt":"2024-09-19T17:22:03Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/1863#issuecomment-2361778138","viewerDidAuthor":false}],"number":1863,"title":"🚀 Syntax highlight for git patches frontmatter"},{"body":"Every package manager has git-delta... except ubuntu. But, having used https://github.com/wagoodman/dive before, they have a smart installation suggestion for their latest debs. I tried it out for delta, and it worked pretty slick, low fuss. I've reproduced it below.\r\n``` bash\r\nDELTA_VERSION=$(curl -sL \"https://api.github.com/repos/dandavison/delta/releases/latest\" | awk -F\\\" '/\"tag_name\":/{print $(NF-1)}')\r\nmkdir -p ~/Downloads && cd ~/Downloads\r\n# Replace 'git-delta' below with 'git-delta-musl' for musl\r\ncurl -OL https://github.com/dandavison/delta/releases/download/${DELTA_VERSION}/git-delta_${DELTA_VERSION}_amd64.deb\r\nsudo apt install ./git-delta_${DELTA_VERSION}_amd64.deb\r\ncd -\r\n```","comments":[],"number":1862,"title":"🚀 Suggested Installation Docs update for Ubuntu"},{"body":"It might be nice to indicate that submodules are \"dirty\" rather than showing red and green with the same commit hash.\r\n\r\n<img width=\"400\" alt=\"image\" src=\"https://github.com/user-attachments/assets/dc0f4971-bb88-4afc-82d1-8a25fe0827d6\">\r\n","comments":[],"number":1838,"title":"🚀 Indicate submodule dirty state"},{"body":"The Catppuccin theme used to enable line numbers for delta by default, but after discussion in https://github.com/catppuccin/delta/issues/12, line numbers were disabled by default in https://github.com/catppuccin/delta/commit/f294e84bdb7c4aba1dde09005765f23a75899168. The commit removed `line-numbers = true` in the feature, so the user could choose where to set `--line-numbers` themselves.\r\n\r\nBut when you run `delta --line-numbers`, you get non-Catppuccin line numbers.\r\n\r\nThis also happens if you add a feature for line numbers, e.g.\r\n\r\n```gitconfig\r\n[delta \"line-numbers\"]\r\n\tline-numbers = true\r\n```\r\n\r\nand then run delta with `DELTA_FEATURES=+line-numbers delta`.\r\n\r\nNo matter how line numbers are enabled, it seems to override previously configured styles.","comments":[],"number":1837,"title":"🐛 `line-numbers-*-style` from feature is ignored if line numbers are enabled elsewhere"},{"body":"- [x] Please include the raw text output from git, so that we can reproduce the problem.\r\n (You can use `git --no-pager` to produce the raw text output.)\r\n- [x] A screenshot of Delta's output is often helpful also.\r\n\r\nHow can I change the background color?\r\n\r\n`git show | bat --light` which get a dark background color.\r\n\r\n<img width=\"818\" alt=\"image\" src=\"https://github.com/user-attachments/assets/52d072cd-eb59-4c35-bc19-2db0d323e873\">\r\n\r\nI want a background color like this:\r\n\r\n\r\nThe iterm2 background color is dark.\r\n\r\n[#87](https://github.com/dandavison/delta/issues/87)\r\n","comments":[],"number":1835,"title":"🚀 override terminal background color"},{"body":"While updating my Void Linux system, I noticed that delta was updated from 0.17 to 0.18.\r\n\r\n\"Cool, let's check what's new.\"\r\n\r\nNope, there is no changelog in the source tree. And checking the git commit log is not an acceptable alternative.\r\n\r\nPleas just provide a simple list like:\r\n\r\n```\r\nversion x.y.z\r\n=============\r\n\r\n- Add this new feature.\r\n- Fixed that bug.\r\n- ...\r\n```","comments":[{"id":"IC_kwDOC4j8g86Kd4z3","author":{"login":"injust"},"authorAssociation":"CONTRIBUTOR","body":"There's a changelog for each release, e.g. https://github.com/dandavison/delta/releases/tag/0.18.0.","createdAt":"2024-09-01T00:38:53Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/1833#issuecomment-2323090679","viewerDidAuthor":false},{"id":"IC_kwDOC4j8g86KmXZA","author":{"login":"th1000s"},"authorAssociation":"COLLABORATOR","body":"That changelog is not that interesting for users, e.g. \"CI: fix macOS build\". A simple file is a good idea, I'll prepare one for the next release.","createdAt":"2024-09-02T21:25:35Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[{"content":"THUMBS_UP","users":{"totalCount":1}}],"url":"https://github.com/dandavison/delta/issues/1833#issuecomment-2325313088","viewerDidAuthor":false}],"number":1833,"title":"add a changelog file (CHANGES.txt, or something like that)"},{"body":"```diff\r\ndiff --git i/test.json w/test.json\r\nindex d89de76..34d7810 100644\r\n--- i/test.json\r\n+++ w/test.json\r\n@@ -1,4 +1,4 @@\r\n {\r\n \"foo\": \"bar\",\r\n- \"baz\": \"qux\"\r\n-}\r\n\\ No newline at end of file\r\n+ \"baz\": \"\"\r\n+}\r\n```\r\n\r\n<img width=\"250\" alt=\"image\" src=\"https://github.com/user-attachments/assets/32aca17c-2651-4dc1-9eb9-c1376a5769c3\">\r\n","comments":[{"id":"IC_kwDOC4j8g86I0tZL","author":{"login":"injust"},"authorAssociation":"CONTRIBUTOR","body":"This seems to happen if the `\\ No newline at end of file` line appears between the old/new lines in the diff.\r\n\r\nSyntax highlighting works in this case:\r\n\r\n```diff\r\ndiff --git i/test.json w/test.json\r\nindex 41557a1..eb5fe05 100644\r\n--- i/test.json\r\n+++ w/test.json\r\n@@ -1,4 +1,4 @@\r\n {\r\n- \"foo\": \"bar\",\r\n+ \"foo\": \"\",\r\n \"baz\": \"qux\"\r\n-}\r\n\\ No newline at end of file\r\n+}\r\n```\r\n\r\n<img width=\"244\" alt=\"image\" src=\"https://github.com/user-attachments/assets/5a1e674d-06b0-4ced-af54-6612349a809a\">\r\n","createdAt":"2024-08-19T01:49:43Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/1812#issuecomment-2295518795","viewerDidAuthor":false}],"number":1812,"title":"🐛 No syntax highlighting if hunk includes added/removed newline at EOF"},{"body":"We are sometimes forgetting on release to update the binary URLs in `manual/src/installation.md`.\r\nSee (constantly work-in-progress) `etc/release.Makefile`.","comments":[],"number":1810,"title":"🚀 Automatically update binary URLs in installation section of manual"},{"body":"When delta truncates a line because `wrap-max-lines` has been reached, it adds a hardcoded `→` character that can't be customized like `--wrap-left-symbol` and that doesn't follow `inline-hint-style`.\r\n\r\nThe truncation character is defined in `config.rs` as:\r\n```truncation_symbol: format!(\"{}→{}\", ansi::ANSI_SGR_REVERSE, ansi::ANSI_SGR_RESET),```\r\n\r\nIdeally it would follow `inline-hint-style` and the character could be customized with something like `--truncation-symbol`\r\n\r\nIn the screenshot below, note how the wrap markings have a magenta background and the truncation symbol shows with a white background.\r\n\r\n\r\n\r\n","comments":[],"number":1790,"title":"🐛 When a line of text is truncated, delta inserts a hardcoded → character in reverse text"},{"body":"The code section within the output of `git log -p` is limited to 80 characters:\r\n\r\n\r\nIs this a bug or misconfiguration?","comments":[{"id":"IC_kwDOC4j8g86HTUx2","author":{"login":"th1000s"},"authorAssociation":"COLLABORATOR","body":"Delta uses the width reported by the terminal, that seems to fail here so the fallback value of 80 is used. Which terminal or terminal multiplexer are you using on what OS?","createdAt":"2024-08-05T21:57:41Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/1788#issuecomment-2269990006","viewerDidAuthor":false},{"id":"IC_kwDOC4j8g86HVGoI","author":{"login":"Mmkldb"},"authorAssociation":"NONE","body":"I see .. I'm using Alacritty, starting a wsl1 on windows, there I use fish as the shell. \r\nInterestingly it is working fine with other commands, like `git diff`, `git show` and `git blame`. So there must be a little difference how `git log -p` is trying to fetch the width from the terminal application.","createdAt":"2024-08-06T06:06:47Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/1788#issuecomment-2270456328","viewerDidAuthor":false},{"id":"IC_kwDOC4j8g86IMd17","author":{"login":"th1000s"},"authorAssociation":"COLLABORATOR","body":"Other commands work fine? `git show HEAD` (or `git show HEAD | delta`) uses the correct width, but `git log -p HEAD [ | delta]` does not (also when alternating between these commands repeatedly)? They all use the same terminal width logic. WSL1 not getting some terminal syscalls quite right isn't surprising, but this variation is :)","createdAt":"2024-08-12T21:54:07Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/1788#issuecomment-2284969339","viewerDidAuthor":false}],"number":1788,"title":"🐛 Width of code section of \"git log -p\" is limited to 80 chars"},{"body":"If compare two text files in `key: value` format, differences on some lines aren't highlighted. \r\nThat also remains if I emulate other tool:\r\n\r\n- [x] The raw text output from diff:\r\n```diff\r\n--- 1.txt 2024-07-31 12:08:29.959299492 +0300\r\n+++ 2.txt 2024-07-31 12:08:56.531841921 +0300\r\n@@ -1,6 +1,6 @@\r\n boot: order=scsi0;ide2;net0\r\n-cores: 96\r\n+cores: 2\r\n scsihw: virtio-scsi-single\r\n-smbios1: uuid=50aa1e50-3ad9-45f1-b9d6-28245cdac1c6\r\n+smbios1: uuid=56097496-497e-4c39-abc4-fccbbf693e68\r\n sockets: 1\r\n-vmgenid: 93d2f111-f51d-40a5-8108-53e1f575e883\r\n+vmgenid: 1d7f5161-973e-4f5d-9d03-fb8f23f77907\r\n```\r\n\r\n- [x] The screenshot of Delta's output:\r\n\r\n\r\n\r\nDifferences in line `cores:` are colorized\r\nDifferences in lines `smbios1:` and `vmgenid:` are not.\r\n\r\nHowever, if I rename `.txt` into `.conf`, the latter differences got some highlight (even if incomplete):\r\n\r\n\r\n","comments":[],"number":1776,"title":"🐛 Some differences in `key: value` format are not highlighted"},{"body":"Running code from commit 5d538b23039058d50f218611f714ff40d5cd883d\r\n\r\non macos\r\n\r\nwhen trying to do git diff HEAD..FETCH_HEAD I get the crash below\r\n\r\n```\r\nthread 'main' panicked at library/alloc/src/raw_vec.rs:25:5:\r\ncapacity overflow\r\nstack backtrace:\r\n 0: 0x100acedb0 - <std::sys_common::backtrace::_print::DisplayBacktrace as core::fmt::Display>::fmt::h7fda799bfa435f0f\r\n 1: 0x100adb2d0 - core::fmt::write::h149c43f8c649a127\r\n 2: 0x100abf880 - std::io::Write::write_fmt::hc658f220ee6401ee\r\n 3: 0x100acec04 - std::sys_common::backtrace::print::hd320cb51e23d85e7\r\n 4: 0x100aca6f8 - std::panicking::default_hook::{{closure}}::h2a019217d59e304e\r\n 5: 0x100aca414 - std::panicking::default_hook::h7115745ac0da2b42\r\n 6: 0x100acaa94 - std::panicking::rust_panic_with_hook::hcaae50c6a8446a46\r\n 7: 0x100acf160 - std::panicking::begin_panic_handler::{{closure}}::h3511e01278c0eee1\r\n 8: 0x100acefdc - std::sys_common::backtrace::__rust_end_short_backtrace::hb40ac48f98b88c7f\r\n 9: 0x100aca7dc - _rust_begin_unwind\r\n 10: 0x100af9a5c - core::panicking::panic_fmt::hd81673e1b116ffee\r\n 11: 0x100ada570 - alloc::raw_vec::capacity_overflow::he177c4fad30c3064\r\n 12: 0x100af99f4 - alloc::raw_vec::handle_error::h814061ff56cfdcc0\r\n 13: 0x100ada494 - alloc::slice::<impl [T]>::repeat::heea357c6bbc4f473\r\n 14: 0x1008b47fc - delta::paint::Painter::paint_lines::h2270367d410b0326\r\n 15: 0x1008b439c - delta::paint::Painter::paint_zero_line::h6c548bfff5cbc41f\r\n 16: 0x1008da244 - delta::handlers::hunk::<impl delta::delta::StateMachine>::handle_hunk_line::h2d0a5765982fdc3b\r\n 17: 0x1008d4100 - delta::delta::delta::hab6a5759a13c6797\r\n 18: 0x1008b9d78 - delta::main::h5909ee6f2ee73102\r\n 19: 0x100909d88 - std::sys_common::backtrace::__rust_begin_short_backtrace::h7d1b12fed2fc7b08\r\n 20: 0x1008df6dc - std::rt::lang_start::{{closure}}::h92cf623c35598587\r\n 21: 0x100aca730 - std::panicking::try::hd72586cf9ddb09aa\r\n 22: 0x100ab809c - std::rt::lang_start_internal::ha2b1bf612bcbfcfb\r\n 23: 0x1008bae70 - _main\r\n```","comments":[{"id":"IC_kwDOC4j8g86E7z-c","author":{"login":"th1000s"},"authorAssociation":"COLLABORATOR","body":"Oh, `capacity_overflow`! In what repo were when you called `diff`, and can you reconstruct where `HEAD` and `FETCH_HEAD` (that one is tricky as it is quite ephemeral) were at?","createdAt":"2024-07-16T08:02:55Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/1760#issuecomment-2230271900","viewerDidAuthor":false},{"id":"IC_kwDOC4j8g86FAhlj","author":{"login":"lrfurtado"},"authorAssociation":"NONE","body":"Sorry for the lack of information on the original report.\r\n\r\n```\r\n(ins)> cd projects/delta/\r\n(ins)> git rev-parse HEAD\r\n5d538b23039058d50f218611f714ff40d5cd883d\r\n(ins)> git rev-parse FETCH_HEAD\r\n4127abc8075d9e0d2385f7148db9e34a99340ad7\r\n(ins)> git remote -v\r\norigin https://github.com/dandavison/delta (fetch)\r\norigin https://github.com/dandavison/delta (push)\r\n(ins)>\r\n```\r\n\r\nOn Tue, Jul 16, 2024 at 3:03 AM Thomas Otto ***@***.***>\r\nwrote:\r\n\r\n> Oh, capacity_overflow! In what repo were when you called diff, and can\r\n> you reconstruct where HEAD and FETCH_HEAD (that one is tricky as it is\r\n> quite ephemeral) were at?\r\n>\r\n> —\r\n> Reply to this email directly, view it on GitHub\r\n> <https://github.com/dandavison/delta/issues/1760#issuecomment-2230271900>,\r\n> or unsubscribe\r\n> <https://github.com/notifications/unsubscribe-auth/AAHGIWXUYBK7RSQ7TRVYQZLZMTHUJAVCNFSM6AAAAABK5BWAWKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDEMZQGI3TCOJQGA>\r\n> .\r\n> You are receiving this because you authored the thread.Message ID:\r\n> ***@***.***>\r\n>\r\n","createdAt":"2024-07-16T18:03:36Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/1760#issuecomment-2231507299","viewerDidAuthor":false},{"id":"IC_kwDOC4j8g86FHL1c","author":{"login":"lrfurtado"},"authorAssociation":"NONE","body":"Was able to do debug build and reproduce\r\n\r\n```\r\n-> state: HunkZero(Unified, None)\r\n 140⋮ 140│## Features\r\n-> state: HunkZero(Unified, None)\r\n 141⋮ 141│\r\n-> state: HunkZero(Unified, None)\r\nthread 'main' panicked at src/paint.rs:266:43:\r\nattempt to subtract with overflow\r\nstack backtrace:\r\n 0: 0x102f0a5a4 - <std::sys_common::backtrace::_print::DisplayBacktrace as core::fmt::Display>::fmt::h7fda799bfa435f0f\r\n 1: 0x102f16b50 - core::fmt::write::h149c43f8c649a127\r\n 2: 0x102efb074 - std::io::Write::write_fmt::hc658f220ee6401ee\r\n 3: 0x102f0a3f8 - std::sys_common::backtrace::print::hd320cb51e23d85e7\r\n 4: 0x102f05eec - std::panicking::default_hook::{{closure}}::h2a019217d59e304e\r\n 5: 0x102f05c08 - std::panicking::default_hook::h7115745ac0da2b42\r\n 6: 0x102f06288 - std::panicking::rust_panic_with_hook::hcaae50c6a8446a46\r\n 7: 0x102f0a954 - std::panicking::begin_panic_handler::{{closure}}::h3511e01278c0eee1\r\n 8: 0x102f0a7d0 - std::sys_common::backtrace::__rust_end_short_backtrace::hb40ac48f98b88c7f\r\n 9: 0x102f05fd0 - _rust_begin_unwind\r\n 10: 0x102f37280 - core::panicking::panic_fmt::hd81673e1b116ffee\r\n 11: 0x102f376ac - core::panicking::panic_const::panic_const_sub_overflow::hcf454aa206276e25\r\n 12: 0x10295567c - delta::paint::Painter::paint_lines::h8947a5e580b4338d\r\n at /Users/l.furtado/projects/delta/src/paint.rs:266:43\r\n 13: 0x10295504c - delta::paint::Painter::paint_zero_line::h9a1e57c297b5329b\r\n at /Users/l.furtado/projects/delta/src/paint.rs:198:13\r\n 14: 0x102996408 - delta::handlers::hunk::<impl delta::delta::StateMachine>::handle_hunk_line::hdbadcccc6ab12167\r\n at /Users/l.furtado/projects/delta/src/handlers/hunk.rs:113:17\r\n 15: 0x1029dd4c4 - delta::delta::StateMachine::consume::h7a4d5a5d0e021dfc\r\n at /Users/l.furtado/projects/delta/src/delta.rs:171:20\r\n 16: 0x1029dcc40 - delta::delta::delta::h12334100afa0cfe8\r\n at /Users/l.furtado/projects/delta/src/delta.rs:120:5\r\n 17: 0x102962e6c - delta::run_app::hb0d42b3d18bfd5e4\r\n at /Users/l.furtado/projects/delta/src/main.rs:143:25\r\n 18: 0x102962500 - delta::main::h787972296b3c44a8\r\n at /Users/l.furtado/projects/delta/src/main.rs:67:21\r\n 19: 0x1028a6ce8 - core::ops::function::FnOnce::call_once::hf2da28e6984ca297\r\n at /private/tmp/rust-20240614-8052-s56n23/rustc-1.79.0-src/library/core/src/ops/function.rs:250:5\r\n 20: 0x1029b27ac - std::sys_common::backtrace::__rust_begin_short_backtrace::h6dc1b15fbd88db03\r\n at /private/tmp/rust-20240614-8052-s56n23/rustc-1.79.0-src/library/std/src/sys_common/backtrace.rs:155:18\r\n 21: 0x1028fcb54 - std::rt::lang_start::{{closure}}::h00df7bbe2afe4c15\r\n at /private/tmp/rust-20240614-8052-s56n23/rustc-1.79.0-src/library/std/src/rt.rs:159:18\r\n 22: 0x102f05f24 - std::panicking::try::hd72586cf9ddb09aa\r\n 23: 0x102ef3890 - std::rt::lang_start_internal::ha2b1bf612bcbfcfb\r\n 24: 0x1028fcb20 - std::rt::lang_start::h95111824976377b2\r\n at /private/tmp/rust-20240614-8052-s56n23/rustc-1.79.0-src/library/std/src/rt.rs:158:17\r\n 25: 0x102963258 - _main\r\n(ins)>\r\n(ins)>\r\n\r\n\r\n```","createdAt":"2024-07-17T12:53:31Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/1760#issuecomment-2233253212","viewerDidAuthor":false},{"id":"IC_kwDOC4j8g86FHNZ3","author":{"login":"lrfurtado"},"authorAssociation":"NONE","body":"<img width=\"1728\" alt=\"image\" src=\"https://github.com/user-attachments/assets/d28d9708-0e34-447a-a19a-d4806b08a310\">\r\n","createdAt":"2024-07-17T12:56:38Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/1760#issuecomment-2233259639","viewerDidAuthor":false}],"number":1760,"title":"🐛 Crash while doing git diff HEAD..FETCH_HEAD on latest delta code running on MacOS"},{"body":"May I suggest you to use the groups feature in dependabot?\n\nhttps://docs.github.com/en/code-security/dependabot/dependabot-version-updates/configuration-options-for-the-dependabot.yml-file#groups\n\nThis could reduce the number of PRs\n\nYou can have a look at what was done in this repository when I suggested it\n\nZxilly/go-size-analyzer@ec9c028\n\nIt would drastically reduce the number of PRs opened by dependabot because they will be grouped.\n\n","comments":[{"id":"IC_kwDOC4j8g86HKZvj","author":{"login":"th1000s"},"authorAssociation":"COLLABORATOR","body":"I also thought grouping was a solution, but in another PR `git bisect` happened to hit a dependency update commit. Separate commits for each dependency chain are probably a good idea for at least that reason. Ideally there would be a way to \"summon\" dependabot so the large number of PRs is only generated on demand.","createdAt":"2024-08-04T19:55:16Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/1759#issuecomment-2267651043","viewerDidAuthor":false}],"number":1759,"title":"Suggestion for dependabot"},{"body":"The [documentation for `--syntax-theme`](https://github.com/dandavison/delta/blob/f5b37173fe88a62e37208a9587a0ab4fec0ef107/manual/src/full---help-output.md?plain=1#L552-L555) says that it defaults to the value of the `BAT_THEME` environment variable (if it contains a valid theme name).\r\n\r\nI don't have `BAT_THEME` set. Instead, I configured `bat` by following [`catppuccin/bat`'s instructions](https://github.com/catppuccin/bat/blob/d714cc1d358ea51bfc02550dabab693f70cccea0/README.md#configuration-file), i.e. `--theme=\"Catppuccin Mocha\"` in `~/.config/bat/config`.\r\n\r\nIn order of descending priority, `delta` seems to use:\r\n1. `syntax-theme` option in the `git` config file\r\n2. `BAT_THEME` environment variable\r\n3. `theme` option in the `bat` config file\r\n\r\nThe documentation should be updated to reflect this.","comments":[{"id":"IC_kwDOC4j8g86EAa6d","author":{"login":"l-armstrong"},"authorAssociation":"NONE","body":"Is this issue still open for me to work on it?","createdAt":"2024-07-08T16:58:48Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/1736#issuecomment-2214702749","viewerDidAuthor":false},{"id":"IC_kwDOC4j8g86EAeFX","author":{"login":"injust"},"authorAssociation":"CONTRIBUTOR","body":"@l-armstrong I haven't found time to work on this. If you'd like to contribute, please go for it!","createdAt":"2024-07-08T17:02:33Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/1736#issuecomment-2214715735","viewerDidAuthor":false}],"number":1736,"title":"🐛 doc: document sources of `syntax-theme` config option"},{"body":" A lot of CJK environments assume that East Asian Ambiguous Width characters are double width, whereas Eastern enviroments single. In former, the borders are displayed with double width and wrapped.It would be preferrable if there was an option to treat those characters as double width or to use ASCII characters to draw borders.\r\n\r\nTo reproduce:\r\n- Use a terminal that is configurable so that Ambiguous Width characters are double width (e.g. iTerm2)\r\n\r\n\r\n\r\n\r\n","comments":[{"id":"IC_kwDOC4j8g86HTVlh","author":{"login":"th1000s"},"authorAssociation":"COLLABORATOR","body":"I see, delta is using ambiguous chars there, e.g. `─` BOX DRAWINGS LIGHT HORIZONTAL, full list at https://www.unicode.org/reports/tr11-2/.\r\n\r\nAlso, when determining the width of chars in the diff itself [UnicodeWidthStr::width()](https://docs.rs/unicode-width/0.1.13/unicode_width/trait.UnicodeWidthStr.html#tymethod.width) is always called with no option to switch to `width_cjk()`. This is most noticeable in side-by-side views so you may also have seen that.","createdAt":"2024-08-05T22:00:13Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/1727#issuecomment-2269993313","viewerDidAuthor":false},{"id":"IC_kwDOC4j8g86LSVW8","author":{"login":"th1000s"},"authorAssociation":"COLLABORATOR","body":"FTR: On Linux, GNOME Terminal supports setting ambiguous chars to double width (have not found other terms yet). Preferences -> Profile -> Tab \"Compatibility\" -> Ambiguous-width characters: Wide","createdAt":"2024-09-08T22:04:47Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/1727#issuecomment-2336839100","viewerDidAuthor":false}],"number":1727,"title":"🐛 Borders displayed too long in environment with East Asian Ambiguous Width == 2"},{"body":"I scan through help can't find a way to flip the default layout of side-by-side, why new change is showing at right I'm confused.","comments":[],"number":1722,"title":"Side by Side show current in left? "},{"body":"Versions 0.1.12 and 0.1.13 of the unicode-width crate changes its behaviour to be more in line with the Unicode standard, but it looks like many projects (especially test suites) relied on the old behaviour - including delta.\r\n\r\nUpstream does not consider the behaviour change a breaking change:\r\nhttps://github.com/unicode-rs/unicode-width/issues/55\r\n\r\nTrying to build git-delta v0.17.0 and running its tests for Fedora Linux, I get the following failures with unicode-width v0.1.13:\r\n\r\n```\r\nfailures:\r\n---- ansi::tests::test_measure_text_width stdout ----\r\nthread 'ansi::tests::test_measure_text_width' panicked at src/ansi/mod.rs:205:9:\r\nassertion `left == right` failed\r\n left: 4\r\n right: 2\r\nnote: run with `RUST_BACKTRACE=1` environment variable to display a backtrace\r\n---- features::side_by_side::tests::test_two_plus_lines_exact_fit stdout ----\r\nthread 'features::side_by_side::tests::test_two_plus_lines_exact_fit' panicked at src/wrapping.rs:469:9:\r\nassertion `left == right` failed: syntax and diff wrapping differs (-) [*r*]\r\n left: (1, 2)\r\n right: (1, 3)\r\n---- features::line_numbers::tests::test_line_numbers_continue_correctly_after_wrapping stdout ----\r\nthread 'features::line_numbers::tests::test_line_numbers_continue_correctly_after_wrapping' panicked at src/tests/integration_test_utils.rs:150:9:\r\nassertion `left == right` failed: on line 3 of input:\r\n▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼\r\na/a.py ⟶ b/b.py\r\n──────────────────────────────────────────\r\n───┐\r\n1: │\r\n───┘\r\n│ 1 │abc │ 1 │abc\r\n│ 2 │a = one side │ 2 │a = one longer@\r\n│ │ │ │ side\r\n│ 3 │xyz │ 3 │xyz\r\n▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲\r\n left: \"│ │ │ │ > side\"\r\n right: \"│ │ │ │ side\"\r\n---- wrapping::tests::test_alignment_1_line_vs_3_lines stdout ----\r\nthread 'wrapping::tests::test_alignment_1_line_vs_3_lines' panicked at src/wrapping.rs:469:9:\r\nassertion `left == right` failed: syntax and diff wrapping differs [*l*] (r)\r\n left: (0, 2)\r\n right: (0, 1)\r\n---- wrapping::tests::test_alignment_2_lines_vs_3_lines stdout ----\r\nthread 'wrapping::tests::test_alignment_2_lines_vs_3_lines' panicked at src/tests/integration_test_utils.rs:150:9:\r\nassertion `left == right` failed: on line 2 of input:\r\n▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼\r\na ⟶ b\r\n───────────────────────────────────────────────────────\r\n───┐\r\n1: │\r\n───┘\r\n│ 1 │.........1.........2< │ 1 │.........1.........2+\r\n│ │ >.... │ │.........3.........4+\r\n│ │ │ │.........5.........6\r\n▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲\r\n left: \"│ │ >.... │ │.........3.........4+\"\r\n right: \"│ │ >.... │ │.........3.........4+\"\r\n---- wrapping::tests::test_wrap_line_newlines stdout ----\r\nthread 'wrapping::tests::test_wrap_line_newlines' panicked at src/wrapping.rs:873:13:\r\nassertion `left == right` failed\r\n left: [[(Style { <aeorSd> }, \"012\"), (Style { <aEorsd> }, \"34\"), (Style { <aeorsd> }, \"<\")], [(Style { <aeorsd> }, \" \"), (Style { <aeorsd> }, \">\"), (Style { <aEorsd> }, \"5\\n\")]]\r\n right: [[(Style { <aeorSd> }, \"012\"), (Style { <aEorsd> }, \"345\\n\")]]\r\nfailures:\r\n ansi::tests::test_measure_text_width\r\n features::line_numbers::tests::test_line_numbers_continue_correctly_after_wrapping\r\n features::side_by_side::tests::test_two_plus_lines_exact_fit\r\n wrapping::tests::test_alignment_1_line_vs_3_lines\r\n wrapping::tests::test_alignment_2_lines_vs_3_lines\r\n wrapping::tests::test_wrap_line_newlines\r\ntest result: FAILED. 372 passed; 6 failed; 8 ignored; 0 measured; 0 filtered out; finished in 0.91s\r\n```\r\n\r\nSo it looks like the tests will need to be adapted for the changes in unicode-width.\r\n\r\nFor example, the `\\u{1}` character can no longer be assumed to have width 0. Replacing it with a zero-width space might work, as seen here: https://github.com/ratatui-org/ratatui/pull/1171\r\n","comments":[{"id":"IC_kwDOC4j8g86LkVgA","author":{"login":"th1000s"},"authorAssociation":"COLLABORATOR","body":"Nice, a package maintainer provided an essential hint long before the first reported panic, see [#1726](https://github.com/dandavison/delta/issues/1726#issuecomment-2339307377). But `cargo install` not defaulting to `--locked`, or at least performing or checking for a successful `cargo test` run somewhere and blindly trusting some semver definition is the real culprit. \r\n","createdAt":"2024-09-10T17:31:11Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/1718#issuecomment-2341558272","viewerDidAuthor":false},{"id":"IC_kwDOC4j8g86NXcqM","author":{"login":"decathorpe"},"authorAssociation":"NONE","body":"It looks like updating to v0.1.14, which reverted the problematic changes from v0.1.13, should resolve this issue. And v0.1.13 was re-published as v0.2.0, so this shouldn't happen again without explicitly bumping the dependency.","createdAt":"2024-09-24T16:10:40Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[{"content":"HOORAY","users":{"totalCount":1}}],"url":"https://github.com/dandavison/delta/issues/1718#issuecomment-2371734156","viewerDidAuthor":false}],"number":1718,"title":"some tests fail with unicode-width v0.1.13"},{"body":"When diffing a move of a large file tree the current output is very repetitive with every file individually listed. Given a small testcase (where I noticed this was with a ~220 file move):\r\n\r\n```console\r\n> mkdir -p {left/foo,right/food}/{bar,baz,qux} && echo 'bar\\nbar\\nbar' | tee {left/foo,right/food}/bar/text >/dev/null && echo 'baz\\nbaz\\nbaz' | tee {left/foo,right/food}/baz/text >/dev/null && echo 'qux\\nqux\\nqux' > left/foo/qux/text && echo 'qux\\nquack\\nqux' > right/food/qux/text\r\n> delta --no-gitconfig left right\r\n```\r\n\r\n\r\n\r\n\r\nIt would be nice if this could just show the `left/foo -> right/food` directory rename, and highlight any few actually changed files within that.","comments":[],"number":1717,"title":"🚀 Show when a directory as a whole was renamed, instead of each file inside it"},{"body":"After install a non root user gets a memory error. Running as root works fine.\r\n\r\n```bash\r\n❯ sudo delta\r\n[sudo] password for lance:\r\nThe main way to use delta is to configure it as the pager for git: see https://github.com/dandavison/delta#get-started. You can also use delta to diff two files: `delta file_A file_B`.\r\n❯ ls -laF /usr/bin/delta\r\n-rwxr-xr-x 1 root root 7059472 Mar 16 07:28 /usr/bin/delta*\r\n❯ ldd /usr/bin/delta\r\n linux-vdso.so.1 (0x00007ffc8659b000)\r\n libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007f9701de0000)\r\n libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f9701dc0000)\r\n libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f9701cd9000)\r\n libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f9701ab0000)\r\n /lib64/ld-linux-x86-64.so.2 (0x00007f97024c2000)\r\n❯ delta\r\nmemory allocation of 1970324836974592 bytes failed\r\n[1] 11340 IOT instruction delta\r\n❯ sudo delta\r\nThe main way to use delta is to configure it as the pager for git: see https://github.com/dandavison/delta#get-started. You can also use delta to diff two files: `delta file_A file_B`.\r\n❯ uname -a\r\nLinux DESKTOP-UE7J8VS 5.15.146.1-microsoft-standard-WSL2 #1 SMP Thu Jan 11 04:09:03 UTC 2024 x86_64 x86_64 x86_64 GNU/Linux\r\n❯ lsb_release -a\r\nNo LSB modules are available.\r\nDistributor ID: Ubuntu\r\nDescription: Ubuntu 22.04.4 LTS\r\nRelease: 22.04\r\nCodename: jammy\r\n\r\n```\r\n\r\nWindows 11, WSL2, Ubuntu 22.04\r\n\r\nDelta version: https://github.com/dandavison/delta/releases/download/0.17.0/git-delta_0.17.0_amd64.deb","comments":[{"id":"IC_kwDOC4j8g85-Xm_-","author":{"login":"dandavison"},"authorAssociation":"OWNER","body":"Hi @rljohnsn, this memory allocation error has come up several times before in delta issues: https://github.com/dandavison/delta/issues?q=is%3Aissue+%22memory+allocation%22\r\n\r\nIt seems that it's always something to do with stale syntect syntax definitions. Can you try some of the remedies in those threads, such as installing bat and\r\n\r\n```\r\nbat cache --clear\r\nbat cache --build\r\n```\r\n","createdAt":"2024-05-20T10:05:15Z","includesCreatedEdit":true,"isMinimized":false,"minimizedReason":"","reactionGroups":[{"content":"THUMBS_UP","users":{"totalCount":1}}],"url":"https://github.com/dandavison/delta/issues/1712#issuecomment-2120118270","viewerDidAuthor":true}],"number":1712,"title":"🐛 Memory allocation error for non root user"},{"body":"When the old and new files being compared are HTML (or markdown), it would be convenient to have the ability to opt into a mode where the output is the original file, with the differences marked with the html [`<ins>`](https://html.spec.whatwg.org/multipage/edits.html#the-ins-element) and [`<del>`](https://html.spec.whatwg.org/multipage/edits.html#the-del-element) elements.\r\n\r\nFor example:\r\nOld:\r\n```html\r\n<!doctype html>\r\n <p>Hello wrodl.\r\n```\r\nNew:\r\n```html\r\n<!doctype html>\r\n <p>Hello world.\r\n```\r\nOutput:\r\n```html\r\n<!doctype>\r\n <p>Hello <del>wrodl</del><ins>world</ins>.\r\n```\r\n\r\nSince git-delta already has the ability to detect word-level diff, it seems this could be achievable.\r\n\r\nThe reason why this would be useful is that when making changes to human readable documents, the source diff isn't always the most user-friendly, and a rendered diff can make life much easier for reviewers.\r\nThere already exist a number of standalone htmldiff tools, but:\r\n* none of them have the git integration that git-delta has, which makes them much less convenient\r\n* many of them tend to mangle the source formatting in various ways, destroying formatting / spacing / line breaking along the way, in a way that a real diff tool wouldn't do.\r\n\r\nI guess the biggest challenge is that this would need some degree of syntax awareness, to avoid injecting tags in the middle of html attributes or other invalid locations.","comments":[],"number":1703,"title":"🚀 output using html <ins> and <del> tags"},{"body":"delta pager with mouse scroll not working in jetbrains ide's terminal.\r\nBut bat and less works good.\r\nHere is my env\r\n\r\n```\r\n# pager\r\nexport PAGER=\"less -RF --mouse\"\r\n\r\n# bat\r\nexport BAT_PAGER=\"${PAGER}\"\r\n\r\n# delta\r\nexport DELTA_PAGER=\"${PAGER}\"\r\n```\r\n","comments":[{"id":"IC_kwDOC4j8g86QXO_x","author":{"login":"arthur-fontaine"},"authorAssociation":"NONE","body":"It didn't work in Zed either, I had to set\r\n\r\n```json\r\n\"terminal\": {\r\n \"alternate_scroll\": \"on\"\r\n }\r\n```\r\n\r\nin my Zed settings. Check if there is a similar setting in Jetbrains.","createdAt":"2024-10-18T09:49:41Z","includesCreatedEdit":true,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/1698#issuecomment-2422009841","viewerDidAuthor":false},{"id":"IC_kwDOC4j8g86QmZMm","author":{"login":"xiaozhuai"},"authorAssociation":"NONE","body":"> Check if there is a similar setting in Jetbrains.\r\n\r\n@arthur-fontaine Thanks bro. I can't find such a setting in Jetbrains.","createdAt":"2024-10-21T08:33:06Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/1698#issuecomment-2425983782","viewerDidAuthor":false}],"number":1698,"title":"🐛 Mouse scroll not working in jetbrains ide's terminal"},{"body":"I set the Pager environment variable to use ov as the pager with the -F option:\r\n\r\n```\r\nexport PAGER='ov -F'\r\n```\r\n\r\nPager environment variables work, but the `-F` parameter does not take effect, `-F` stands for quit if the output fits on one screen. I guess it may be because it is not included in quotes when passing delta paging, causing the `-F` parameter to be lost.\r\n\r\n`-F` in the env variables not take effects, still in the pager:\r\n<img width=\"1113\" alt=\"image\" src=\"https://github.com/dandavison/delta/assets/10527522/2611fcf7-8899-4dc9-8aa4-b30f1785f47f\">\r\n\r\n\r\nI have to config pager in git config files, will take the `-F` options:\r\n\r\n```\r\n pager = delta --pager='ov -F'\r\n```\r\n\r\n`-F` in the git config files works:\r\n\r\n<img width=\"1116\" alt=\"image\" src=\"https://github.com/dandavison/delta/assets/10527522/621b81bf-787f-45aa-bae6-239e5a4fb962\">\r\n\r\n","comments":[],"number":1684,"title":"🐛 PAGER env variable will omit command line parameters"},{"body":"Consider the following text file containing a UTF character followed by newline:\r\n\r\n```zsh\r\n❯ cat foo.txt\r\n━\r\n```\r\n\r\nHere is the hex dump for clarity:\r\n\r\n```zsh\r\n❯ xxd -p foo.txt\r\ne294810a\r\n```\r\n\r\nDelta will interpret regular `rg` output just fine:\r\n\r\n```zsh\r\n❯ rg \"\" foo.txt | delta\r\n━\r\n```\r\n\r\nBut it will panic when using JSON output:\r\n\r\n```zsh\r\n❯ rg --json \"\" foo.txt | RUST_BACKTRACE=1 delta\r\nthread 'main' panicked at src/handlers/grep.rs:389:50:\r\nbyte index 1 is not a char boundary; it is inside '━' (bytes 0..3) of `━`\r\nstack backtrace:\r\n• foo.txt\r\n 0: _rust_begin_unwind\r\n 1: core::panicking::panic_fmt\r\n 2: core::str::slice_error_fail_rt\r\n 3: core::str::slice_error_fail\r\n 4: delta::handlers::grep::make_style_sections\r\n 5: delta::handlers::grep::<impl delta::delta::StateMachine>::handle_grep_line\r\n 6: delta::delta::delta\r\n 7: delta::main\r\nnote: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.\r\n```","comments":[],"number":1679,"title":"🐛 ripgrep JSON output causes panic with UTF character"},{"body":"I want to specify light and dark themes simultaneously, and auto-switch based on the system's appearance like the default behavior.","comments":[{"id":"IC_kwDOC4j8g859Eg0v","author":{"login":"bash"},"authorAssociation":"CONTRIBUTOR","body":"Since delta supports bat's `BAT_THEME` environment variable it might be a good idea to wait for bat to implement this first. I have opened a PR for this a while back: https://github.com/sharkdp/bat/pull/2896.\r\n\r\nThe mentioned PR for bat adds two new options / environment variables:\r\n* `--theme-dark` / `BAT_THEME_DARK`\r\n* `--theme-light` / `BAT_THEME_LIGHT`\r\n","createdAt":"2024-05-07T12:51:14Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/1678#issuecomment-2098335023","viewerDidAuthor":false}],"number":1678,"title":"Specify light and dark themes simultaneously, and auto-switch based on system appearance"},{"body":"`lorem_ipsum_1a.py`:\r\n```\r\n\"\"\"\r\n\r\nLorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua.\r\nPurus semper eget duis at tellus at.\r\nLeo vel orci porta non pulvinar.\r\nCursus in hac habitasse platea dictumst quisque.\r\nArcu cursus euismod quis viverra nibh cras pulvinar mattis nunc.\r\n```\r\n`lorem_ipsum_1b.py`:\r\n```\r\n\"\"\"\r\nLorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua.\r\nPurus semper eget duis at tellus at.\r\nLeo vel orci porta non pulvinar.\r\nCursus in hac habitasse platea dictumst quisque.\r\nArcu cursus euismod quis viverra nibh cras pulvinar mattis nunc.\r\n```\r\nhere, the diff is just removing line 2, which is blank\r\n`$ delta lorem_ipsum_1a.py lorem_ipsum_1b.py --no-gitconfig`:\r\n\r\nsomething in my config makes it work fine for this case\r\n\r\n\r\nI'm not really sure what, though. I commented out my whole `~/.gitconfig` and it still is different with `--no-gitconfig` than without\r\n\r\nthis is an issue even with my config when I have\r\n`lorem_ipsum_2a.py`:\r\n```\r\n\"\"\"\r\n\r\nLorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua.\r\nPurus semper eget duis at tellus at.\r\nLeo vel orci porta non pulvinar.\r\nCursus in hac habitasse platea dictumst quisque.\r\nArcu cursus euismod quis viverra nibh cras pulvinar mattis nunc.\r\nTortor at auctor urna nunc id cursus metus aliquam.\r\nFaucibus interdum posuere lorem ipsum dolor sit amet.\r\nDuis tristique sollicitudin nibh sit amet commodo nulla facilisi.\r\nAmet purus gravida quis blandit turpis cursus.\r\nImperdiet nulla malesuada pellentesque elit eget gravida.\r\nTincidunt praesent semper feugiat nibh sed pulvinar proin.\r\nAmet commodo nulla facilisi nullam vehicula ipsum.\r\nSed turpis tincidunt id aliquet risus feugiat.\r\nIaculis eu non diam phasellus vestibulum.\r\nSed vulputate odio ut enim.\r\nGravida dictum fusce ut placerat orci nulla pellentesque dignissim enim.\r\nUltrices eros in cursus turpis massa.\r\nSed libero enim sed faucibus turpis in eu.\r\nErat nam at lectus urna duis convallis convallis tellus.\r\nIn tellus integer feugiat scelerisque varius morbi enim nunc.\r\nMi bibendum neque egestas congue quisque egestas diam in.\r\nOrci a scelerisque purus semper eget duis at tellus.\r\nArcu dictum varius duis at consectetur lorem.\r\nRhoncus aenean vel elit scelerisque mauris pellentesque pulvinar pellentesque habitant.\r\nTellus molestie nunc non blandit massa enim nec dui nunc.\r\nFaucibus a pellentesque sit amet porttitor eget dolor morbi non.\r\nEst ullamcorper eget nulla facilisi etiam dignissim diam quis enim.\r\nNulla facilisi nullam vehicula ipsum a arcu cursus vitae.\r\nQuis auctor elit sed vulputate mi.\r\n\r\nTempus egestas sed sed risus pretium quam vulputate dignissim suspendisse.\r\nNetus et malesuada fames ac turpis.\r\n\"\"\"\r\ndef\r\n```\r\n`lorem_ipsum_2b.py`:\r\n```\r\n\"\"\"\r\nLorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua.\r\nPurus semper eget duis at tellus at.\r\nLeo vel orci porta non pulvinar.\r\nCursus in hac habitasse platea dictumst quisque.\r\nArcu cursus euismod quis viverra nibh cras pulvinar mattis nunc.\r\nTortor at auctor urna nunc id cursus metus aliquam.\r\nFaucibus interdum posuere lorem ipsum dolor sit amet.\r\nDuis tristique sollicitudin nibh sit amet commodo nulla facilisi.\r\nAmet purus gravida quis blandit turpis cursus.\r\nImperdiet nulla malesuada pellentesque elit eget gravida.\r\nTincidunt praesent semper feugiat nibh sed pulvinar proin.\r\nAmet commodo nulla facilisi nullam vehicula ipsum.\r\nSed turpis tincidunt id aliquet risus feugiat.\r\nIaculis eu non diam phasellus vestibulum.\r\nSed vulputate odio ut enim.\r\nGravida dictum fusce ut placerat orci nulla pellentesque dignissim enim.\r\nUltrices eros in cursus turpis massa.\r\nSed libero enim sed faucibus turpis in eu.\r\nErat nam at lectus urna duis convallis convallis tellus.\r\nIn tellus integer feugiat scelerisque varius morbi enim nunc.\r\nMi bibendum neque egestas congue quisque egestas diam in.\r\nOrci a scelerisque purus semper eget duis at tellus.\r\nArcu dictum varius duis at consectetur lorem.\r\nRhoncus aenean vel elit scelerisque mauris pellentesque pulvinar pellentesque habitant.\r\nTellus molestie nunc non blandit massa enim nec dui nunc.\r\nFaucibus a pellentesque sit amet porttitor eget dolor morbi non.\r\nEst ullamcorper eget nulla facilisi etiam dignissim diam quis enim.\r\nNulla facilisi nullam vehicula ipsum a arcu cursus vitae.\r\nQuis auctor elit sed vulputate mi.\r\nTempus egestas sed sed risus pretium quam vulputate dignissim suspendisse.\r\nNetus et malesuada fames ac turpis.\r\n\"\"\"\r\n\r\nabc\r\n```\r\nhere, the diff includes adding a blank line before `abc`\r\n\r\n","comments":[],"number":1677,"title":"🐛 inserted/deleted blank lines are sometimes hard to see"},{"body":"**To reproduce:**\r\n\r\n1. Enable Delta in gitconfig.\r\n2. Find some content in a file that has a `-` in it's filename or path.\r\n3. Execute `git grep -l \"<the-content>\"`.\r\n4. Notice that the first `-` is replaced with a `:`.\r\n\r\n**Expected:** That it is not replaced.\r\n\r\n**Version:**\r\n```\r\n$ delta --version\r\ndelta 0.17.0\r\n```","comments":[{"id":"IC_kwDOC4j8g85_trPe","author":{"login":"jmcfarlane"},"authorAssociation":"NONE","body":"Same behavior even without `-l`. Am currently using `0.16.5`. For example:\r\n\r\n```sh\r\n$ echo abcdefg > test-file\r\n$ git add test-file \r\n$ git grep abcdefg \r\ntest:file:abcdefg\r\n$ \r\n$ delta --version\r\ndelta 0.16.5\r\n$ \r\n```","createdAt":"2024-05-31T17:19:02Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/1674#issuecomment-2142680030","viewerDidAuthor":false}],"number":1674,"title":"`git grep -l` replaces first `-` with a `:`"},{"body":"Hi, thank you for creating this amazing tool 👍 \r\n\r\nI'm not sure if the feature already exists or not, but I would like to have a new indicator that shows \"how far you've read the diff\" (in percentage or line of code, e.g. 1234/5000).\r\n\r\nThis indicator will be very helpful especially when I code-review someone's gigantic pull request locally and figure out how big the changes are and how far I've read, so that for example, I can pause the review at some percentage and come back later a bit more easily.","comments":[],"number":1673,"title":"[Feature Request] Show percentage of how far the entire diff has been read"},{"body":"```bash\r\n$ delta /proc/sys/kernel/seccomp/actions_*\r\n$ echo $?\r\n0\r\n$ git diff /proc/sys/kernel/seccomp/actions_*\r\n$ echo $?\r\n0\r\n$ cp /proc/sys/kernel/seccomp/actions_* /tmp\r\n$ delta /tmp/actions_*\r\n\r\ntmp/actions_logged:1:\r\n1|kill_process kill_thread trap errno user_notif trace log allow 1┊kill_process kill_thread trap errno user_notif trace log\r\n$ echo $?\r\n1\r\n$ git diff /tmp/actions_*\r\n\r\ntmp/actions_logged:1:\r\n1|kill_process kill_thread trap errno user_notif trace log allow 1┊kill_process kill_thread trap errno user_notif trace log\r\n$ echo $?\r\n1\r\n```\r\n","comments":[],"number":1671,"title":"🐛 Empty diff for proc files"},{"body":"This is a pretty small nitpick, but I figure I'd file an issue anyways in case it's bothering anybody else.\r\n\r\nIn outputs with where diffs are displayed, it seems like there's an extra newline right before the diff. These screenshots don't have any custom Delta config set.\r\n\r\n- Output of `git diff`:\r\n\r\n \r\n\r\n- Output of `git show`:\r\n\r\n \r\n\r\nI've selected the lines in question to make it clearer. You can also see it in the screenshot for `git show` in the `README`:\r\n\r\n\r\n\r\nIn my opinion, the newline is unnecessary and should be removed.","comments":[],"number":1670,"title":"🐛 Extra newline before diffs"},{"body":"**Environment**\r\n- OS: macOS 14.3.1\r\n- zsh: zsh 5.9 (arm-apple-darwin21.3.0)\r\n- delta: delta 0.17.0\r\n- ripgrep: ripgrep 14.1.0\r\n\r\n**Test steps**\r\n1. Prepare test.py as below:\r\n```\r\nnum = 407\r\n\r\n# To take input from the user\r\n#num = int(input(\"Enter a number: \"))\r\n\r\nif num == 1:\r\n print(num, \"is not a prime number\")\r\nelif num > 1:\r\n # check for factors\r\n for i in range(2,num):\r\n if (num % i) == 0:\r\n print(num,\"is not a prime number\")\r\n print(i,\"times\",num//i,\"is\",num)\r\n break\r\n else:\r\n print(num,\"is a prime number\")\r\n \r\n# if input number is less than\r\n# or equal to 1, it is not prime\r\nelse:\r\n print(num,\"is not a prime number\") \r\n```\r\n2. Run command:\r\n```\r\ncommand rg --no-config -C 2 print ./test.py --json | delta --syntax-theme=\"Nord\" \r\n```\r\n\r\n**Expected result**\r\n1. Keyword 'print' should be highlighted\r\n2. Python syntax should be identified and highlighted correctly\r\n\r\n**Actual result**\r\nSyntax highlighting is not correct:\r\n<img width=\"373\" alt=\"ScreenShot 2024-04-01 at 13 27 02 \" src=\"https://github.com/dandavison/delta/assets/7710361/977c2d70-7122-48f1-97e5-3acba4c2483c\">\r\n\r\nThe code after comment tag \"#\" is treated as comment as well\r\n\r\n***Others***\r\n1. It seems shell script which uses \"#\" for comment as Python has the same issue\r\n2. As for other comment tag (\"//\", e.g.), works correctly\r\n\r\nPlease let me know if more verifications required and thanks for the assistance.","comments":[],"number":1668,"title":"🐛 Incorrect syntax-highlight with comment tag \"#\""},{"body":"\n> yaml-rust is unmaintained.\n\n| Details | |\n| ------------------- | ---------------------------------------------- |\n| Status | unmaintained |\n| Package | `yaml-rust` |\n| Version | `0.4.5` |\n| URL | [https://github.com/rustsec/advisory-db/issues/1921](https://github.com/rustsec/advisory-db/issues/1921) |\n| Date | 2024-03-20 |\n\nThe maintainer seems [unreachable](https://github.com/chyh1990/yaml-rust/issues/197).\n\nMany issues and pull requests have been submitted over the years\nwithout any [response](https://github.com/chyh1990/yaml-rust/issues/160).\n\n## Alternatives\n\nConsider switching to the actively maintained `yaml-rust2` fork of the original project:\n\n- [yaml-rust2](https://github.com/Ethiraric/yaml-rust2)\n- [yaml-rust2 @ crates.io](https://crates.io/crates/yaml-rust2))\n\nSee [advisory page](https://rustsec.org/advisories/RUSTSEC-2024-0320.html) for additional details.\n","comments":[],"number":1667,"title":"RUSTSEC-2024-0320: yaml-rust is unmaintained."},{"body":"Possibly a misunderstanding? But when I turn on navigation, do `git diff` and press `n`, the screen advances to the next hunk, even if it is in the same file.\r\n\r\nI'm using delta 0.16.5, from Fedora repos. Running inside tmux on Alacritty, if that is relevant.","comments":[{"id":"IC_kwDOC4j8g859W_MP","author":{"login":"jasonmobley"},"authorAssociation":"NONE","body":"Seeing the same in delta 0.17.0","createdAt":"2024-05-09T18:12:46Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/1666#issuecomment-2103177999","viewerDidAuthor":false},{"id":"IC_kwDOC4j8g85_0v0W","author":{"login":"dandavison"},"authorAssociation":"OWNER","body":"Just want to say that I sympathise with this! I also find that if I'm using navigate to jump, then by-hunk jumps often feel too small. So I'm open to interface design change proposals here. \r\n\r\nA related variant is to increase our diff context, i.e. with `git ... -U99 | delta` or\r\n\r\n```gitconfig\r\n[diff]\r\n context = 99\r\n```\r\n\r\nIf we set that number large enough, then there are no within-file hunks any longer hence navigate jumps become by-file! Of course it can sometimes not be exactly what you want to have to scroll past large sections of unchanged content, but sometimes the lack of hunk breaks makes diffs easier to understand.","createdAt":"2024-06-03T08:04:13Z","includesCreatedEdit":true,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/1666#issuecomment-2144533782","viewerDidAuthor":true}],"number":1666,"title":"🐛 --navigate n/N jumps to next/prev hunk, not file?"},{"body":"After updating to the 0.17.0 release, I can no longer read git diffs due to `delta` using a light theme on my dark terminal background.\r\n\r\nMy setup consists of Alacritty with Zellij and Fish. I tested on a stock GNOME Terminal as well with un-modified bash, and the problem happens there, as well. My `.gitconfig` options for diffing matches that in the Delta readme.\r\n\r\n- [x] Please include the raw text output from git, so that we can reproduce the problem.\r\n (You can use `git --no-pager` to produce the raw text output.)\r\n ```diff\r\n diff --git a/packages/a/adw-gtk3-theme/package.yml b/packages/a/adw-gtk3-theme/package.yml\r\n index aeb8a25200..06017a5c30 100644\r\n --- a/packages/a/adw-gtk3-theme/package.yml\r\n +++ b/packages/a/adw-gtk3-theme/package.yml @@ -1,8 +1,8 @@\r\n name : adw-gtk3-theme\r\n -version : '5.2'\r\n -release : 12\r\n +version : '5.3'\r\n +release : 13\r\n source :\r\n - - https://github.com/lassekongo83/adw-gtk3/archive/refs/tags/v5.2.tar.gz : 1265b9dbc933bf602da1c419e515752bc8d7b9e6f8a09eafd740315d321501d7\r\n + - https://github.com/lassekongo83/adw-gtk3/releases/download/v5.3/adw-gtk3v5.3.tar.xz : 2e6e87935bef30936e40d07c7af4fd20754e77917be224f61c4346867196bef0\r\n license : LGPL-2.1-only\r\n homepage : https://github.com/lassekongo83/adw-gtk3\r\n component : desktop.them\r\n ```\r\n- [x] A screenshot of Delta's output is often helpful also.\r\n\r\n\r\n\r\n","comments":[{"id":"IC_kwDOC4j8g854DDIO","author":{"login":"dandavison"},"authorAssociation":"OWNER","body":"Hi @EbonJaeger, sorry about that. Please add `dark = true` or `--dark` to your delta config / invocations to force colors for dark backgrounds.\r\n\r\ndelta in 0.17.0 should autodetect in the absence of the `light/dark` setting. I wonder if it could be an issue with Zellij cc @bash -- any thoughts? ","createdAt":"2024-03-21T23:56:04Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/1663#issuecomment-2014065166","viewerDidAuthor":true},{"id":"IC_kwDOC4j8g854EhCZ","author":{"login":"rsmmr"},"authorAssociation":"NONE","body":"I'm seeing the same issue but only when I'm inside a `tmux` shell. Outside `tmux` it works fine.","createdAt":"2024-03-22T06:37:27Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/1663#issuecomment-2014449817","viewerDidAuthor":false},{"id":"IC_kwDOC4j8g854FQhB","author":{"login":"bash"},"authorAssociation":"CONTRIBUTOR","body":"Hi @EbonJaeger :wave: Thank you for reporting the bug! \r\nIn your GNOME Terminal setup, are you running Bash inside of Zellij or directly in GNOME Terminal?\r\n\r\nI would be surprised if the issue happened in GNOME Terminal directly as it has always correctly reported colors in my experience.\r\n\r\n@dandavison From a quick glance and some preliminary tests it does seem like Zellij reports incorrect colors (happens to me both in Alacritty and GNOME Terminal). If will try to dig further next week or so.\r\n\r\n","createdAt":"2024-03-22T08:58:49Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/1663#issuecomment-2014644289","viewerDidAuthor":false},{"id":"IC_kwDOC4j8g854FRMG","author":{"login":"bash"},"authorAssociation":"CONTRIBUTOR","body":"@rsmmr What version of tmux are you running? Color detection should work OK in the latest version from git iirc.\r\n","createdAt":"2024-03-22T09:00:41Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/1663#issuecomment-2014647046","viewerDidAuthor":false},{"id":"IC_kwDOC4j8g854HT82","author":{"login":"EbonJaeger"},"authorAssociation":"NONE","body":"@bash I was not using Zellij or tmux in GNOME terminal; just straight Bash. I'll try the workaround later. 😃","createdAt":"2024-03-22T14:06:00Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/1663#issuecomment-2015182646","viewerDidAuthor":false},{"id":"IC_kwDOC4j8g854H3Yl","author":{"login":"EbonJaeger"},"authorAssociation":"NONE","body":"I tried again with GNOME terminal this morning and it is working as expected. Maybe I didn't start a new session or something last night after trying to force the dark theme. Sorry about that. So that just leaves Zellij.\r\n\r\nThe workaround of setting `dark = true` in the `.gitconfig` works, though! Thanks!","createdAt":"2024-03-22T15:19:08Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[{"content":"THUMBS_UP","users":{"totalCount":2}}],"url":"https://github.com/dandavison/delta/issues/1663#issuecomment-2015327781","viewerDidAuthor":false},{"id":"IC_kwDOC4j8g854H4eo","author":{"login":"bash"},"authorAssociation":"CONTRIBUTOR","body":"That's great to hear! I was worried there for a second since GNOME Terminal always worked well in my experience 😆 ","createdAt":"2024-03-22T15:21:32Z","includesCreatedEdit":true,"isMinimized":false,"minimizedReason":"","reactionGroups":[{"content":"LAUGH","users":{"totalCount":2}}],"url":"https://github.com/dandavison/delta/issues/1663#issuecomment-2015332264","viewerDidAuthor":false},{"id":"IC_kwDOC4j8g854nzlf","author":{"login":"lilyball"},"authorAssociation":"NONE","body":"I've hit this too. It works fine in tmux, but not in zellij. What's more annoying is that the new `--detect-dark-light` flag cannot be set through gitconfig, which means my only option is to force dark on all the time instead of letting it infer from my theme.","createdAt":"2024-03-27T18:44:45Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/1663#issuecomment-2023700831","viewerDidAuthor":false},{"id":"IC_kwDOC4j8g854n0nD","author":{"login":"lilyball"},"authorAssociation":"NONE","body":"Also I will note that Zellij sets a few env vars that can be used to detect that we're running in Zellij.","createdAt":"2024-03-27T18:47:24Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/1663#issuecomment-2023705027","viewerDidAuthor":false}],"number":1663,"title":"🐛 Always using light theme on dark background"},{"body":"When building a `detla` package for ALT from the tag `0.17.0` tests fail with:\r\n```\r\n[00:00:50] + cargo test -j32 --release --no-fail-fast\r\n...\r\n[00:01:08] failures:\r\n[00:01:08] \r\n[00:01:08] ---- env::tests::test_env_parsing_with_pager_set_to_bat stdout ----\r\n[00:01:08] thread 'env::tests::test_env_parsing_with_pager_set_to_bat' panicked at src/env.rs:79:9:\r\n[00:01:08] assertion `left == right` failed: Expected env.pagers.1 == Some(bat) but was Some(\"less\")\r\n[00:01:08] left: Some(\"less\")\r\n[00:01:08] right: Some(\"bat\")\r\n[00:01:08] note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace\r\n[00:01:08] \r\n[00:01:08] \r\n[00:01:08] failures:\r\n[00:01:08] env::tests::test_env_parsing_with_pager_set_to_bat\r\n[00:01:08] \r\n[00:01:08] test result: FAILED. 377 passed; 1 failed; 8 ignored; 0 measured; 0 filtered out; finished in 0.42s\r\n[00:01:08] \r\n[00:01:08] error: test failed, to rerun pass `--bin delta`\r\n[00:01:08] error: 1 target failed:\r\n[00:01:08] `--bin delta`\r\n```\r\nTemporary build log: https://git.altlinux.org/tasks/342942/build/100/x86_64/log\r\n\r\nInterestingly, when I try to reproduce this on other host with the **same build env** it does not fail:\r\n```\r\n21:23:11 test env::tests::test_env_parsing_with_pager_set_to_bat ... ok\r\n```\r\nBoth envs do not have `bat` binary. If `bat` binary is installed the test fails anyway.\r\n\r\nps. It looks like the test fails probabilistically. But because we have 4 build architectures, it fails with a high probability when build for all of them. Stat from different build runs:\r\n```\r\nsubtask name aarch64 i586 ppc64le x86_64\r\n #100 delta 3:54 failed 4:17 failed\r\n\r\nsubtask name aarch64 i586 ppc64le x86_64\r\n #100 delta 3:53 2:11 failed failed\r\n\r\nsubtask name aarch64 i586 ppc64le x86_64\r\n #100 delta 3:55 failed failed failed\r\n```\r\n","comments":[{"id":"IC_kwDOC4j8g853XOCh","author":{"login":"dandavison"},"authorAssociation":"OWNER","body":"Hi, thanks for the issue. This is a flaky test that relies on setting environment variables (which in general does not work with Rust tests seeing as they are executed concurrently by default). It needs to be re-written, perhaps using something like https://github.com/vmx/temp-env","createdAt":"2024-03-17T18:46:34Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[{"content":"THUMBS_UP","users":{"totalCount":1}}],"url":"https://github.com/dandavison/delta/issues/1660#issuecomment-2002575521","viewerDidAuthor":true},{"id":"IC_kwDOC4j8g853XQL5","author":{"login":"vt-alt"},"authorAssociation":"NONE","body":"IC. Thanks for answer! I will run them with `cargo test ... -- --test-threads=1` (already tested to work OK).","createdAt":"2024-03-17T19:15:20Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[{"content":"THUMBS_UP","users":{"totalCount":1}}],"url":"https://github.com/dandavison/delta/issues/1660#issuecomment-2002584313","viewerDidAuthor":false},{"id":"IC_kwDOC4j8g853XQ7E","author":{"login":"dandavison"},"authorAssociation":"OWNER","body":"Great! Sorry about that; we will fix it soon.","createdAt":"2024-03-17T19:26:15Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/1660#issuecomment-2002587332","viewerDidAuthor":true},{"id":"IC_kwDOC4j8g853XVgr","author":{"login":"sashkab"},"authorAssociation":"NONE","body":"same issue on [armhf build for alpine](https://gitlab.alpinelinux.org/sashk/aports/-/jobs/1307374#L922). Will try @vt-alt's suggestion.","createdAt":"2024-03-17T20:24:46Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/1660#issuecomment-2002606123","viewerDidAuthor":false}],"number":1660,"title":"🐛 test env::tests::test_env_parsing_with_pager_set_to_bat ... FAILED"},{"body":"This is a weird one but after trying to figure it out for the last few hours I'm giving up for now and reporting what I've found so far.\r\n\r\nWhen running `delta` against two input files the output will have the wrong foreground colour for certain lines, but only on Windows when using a \"native\" copy of `less` (i.e. no dependency on any Unix compatibility layer). The `less` binary you get from `scoop` meets this criteria, but the `less` binary included with Git for Windows does not as it depends on MSYS2 and `ncurses`.\r\n\r\nThis means that you can't typically reproduce the problem using `git diff` as that will use the `less` binary included with Git for Windows unless you've messed about with the `PATH` environment variable first. The easiest way to reproduce it is to directly call `delta` from a PowerShell or Command Prompt terminal. Git Bash or Git CMD won't work for the same reason as `git diff` won't out-of-the-box.\r\n\r\nOne other requirement: the issue only appears if line numbers or side-by-side view is enabled (or both). I've attached some screenshots to better illustrate the issue. Note that I've changed the \"bright black\" colour from the default grey to a bright red to make it clearer.\r\n\r\n**Broken behaviour**\r\n\r\n\r\n**Correct behaviour**\r\n\r\n\r\n**Additional notes**\r\n1. The issue only seems to occur for new lines. It does not appear to occur for the right-side when side-by-side view is enabled.\r\n2. The same `delta` binary is being used in all cases. I've tested with the latest stable release (`v0.16.5`) and built from latest source.\r\n3. Although the `less` binary differs they're both version 643. They use different regex engines, but that feels unlikely to be relevant.\r\n4. The issue occurs in a standard Console Host in addition to Windows Terminal (as in the earlier screenshots).\r\n\r\n**Final thoughts**\r\nI suspect this is probably not a bug in `less` but I'm not suggesting it's definitely a `delta` bug either. I wonder if there's some edge case which the MSYS2 or `ncurses` libraries handle correctly or work around but the \"native\" Windows terminal does not? Even if so, fixing it in `delta` may be easier at least in the short term if that actually is the case.","comments":[],"number":1653,"title":"🐛 Incorrect use of bright-black background with native less pager on Windows"},{"body":"I used to update `git-delta` to latest commit for quite some time, through ArchLinux's AUR, from https://aur.archlinux.org/packages/git-delta-git\r\nRecently, Arch changed building defaults to enable `lto` by default for everything.\r\n\r\nIt caused some of these packages to fail to build under `lto` option, and `delta` is one of them.\r\n\r\nI didn't see any report of the failing build with `lto` so it felt like it's always worth a report, even if it's to explain that it's intended.\r\n\r\nThe build/link errors are the following ones:\r\n\r\n```\r\n[…]\r\n Compiling syntect v5.0.0\r\n Compiling git2 v0.17.2\r\n Compiling git-delta v0.16.5 (/home/clement/.cache/yay/git-delta-git/src/delta)\r\nerror: linking with `cc` failed: exit status: 1\r\n |\r\n = note: LC_ALL=\"C\" PATH=\"/usr/lib64/rustlib/x86_64-unknown-linux-gnu/bin:/usr/local/bin:/usr/bin:/usr/local/sbin:/var/lib/flatpak/exports/bin:/usr/bin/site_perl:/usr/bin/vendor_perl:/usr/bin/core_perl\" VSLANG=\"1033\" \"cc\" \"-m64\" \"/tmp/rustckAXkMr/symbols.o\" \"/home/clement/.cache/yay/git-delta-git/src/delta/target/release/deps/delta-340c855f98c02c6b.delta.f0b890de4f8c8231-cgu.00.rcgu.o\" \"/home/clement/.cache/yay/git-delta-git/src/delta/target/release/deps/delta-340c855f98c02c6b.delta.f0b890de4f8c8231-cgu.01.rcgu.o\" \"/home/clement/.cache/yay/git-delta-git/src/delta/target/release/deps/delta-340c855f98c02c6b.delta.f0b890de4f8c8231-cgu.02.rcgu.o\" \"/home/clement/.cache/yay/git-delta-git/src/delta/target/release/deps/delta-340c855f98c02c6b.delta.f0b890de4f8c8231-cgu.03.rcgu.o\" \"/home/clement/.cache/yay/git-delta-git/src/delta/target/release/deps/delta-340c855f98c02c6b.delta.f0b890de4f8c8231-cgu.04.rcgu.o\" \"/home/clement/.cache/yay/git-delta-git/src/delta/target/release/deps/delta-340c855f98c02c6b.delta.f0b890de4f8c8231-cgu.05.rcgu.o\" \"/home/clement/.cache/yay/git-delta-git/src/delta/target/release/deps/delta-340c855f98c02c6b.delta.f0b890de4f8c8231-cgu.06.rcgu.o\" \"/home/clement/.cache/yay/git-delta-git/src/delta/target/release/deps/delta-340c855f98c02c6b.delta.f0b890de4f8c8231-cgu.07.rcgu.o\" \"/home/clement/.cache/yay/git-delta-git/src/delta/target/release/deps/delta-340c855f98c02c6b.delta.f0b890de4f8c8231-cgu.08.rcgu.o\" \"/home/clement/.cache/yay/git-delta-git/src/delta/target/release/deps/delta-340c855f98c02c6b.delta.f0b890de4f8c8231-cgu.09.rcgu.o\" \"/home/clement/.cache/yay/git-delta-git/src/delta/target/release/deps/delta-340c855f98c02c6b.delta.f0b890de4f8c8231-cgu.10.rcgu.o\" \"/home/clement/.cache/yay/git-delta-git/src/delta/target/release/deps/delta-340c855f98c02c6b.delta.f0b890de4f8c8231-cgu.11.rcgu.o\" \"/home/clement/.cache/yay/git-delta-git/src/delta/target/release/deps/delta-340c855f98c02c6b.delta.f0b890de4f8c8231-cgu.12.rcgu.o\" \"/home/clement/.cache/yay/git-delta-git/src/delta/target/release/deps/delta-340c855f98c02c6b.delta.f0b890de4f8c8231-cgu.13.rcgu.o\" \"/home/clement/.cache/yay/git-delta-git/src/delta/target/release/deps/delta-340c855f98c02c6b.delta.f0b890de4f8c8231-cgu.14.rcgu.o\" \"/home/clement/.cache/yay/git-delta-git/src/delta/target/release/deps/delta-340c855f98c02c6b.delta.f0b890de4f8c8231-cgu.15.rcgu.o\" \"/home/clement/.cache/yay/git-delta-git/src/delta/target/release/deps/delta-340c855f98c02c6b.1pwm0cnj1ubtt639.rcgu.o\" \"-Wl,--as-needed\" \"-L\" \"/home/clement/.cache/yay/git-delta-git/src/delta/target/release/deps\" \"-L\" \"/home/clement/.cache/yay/git-delta-git/src/delta/target/release/build/onig_sys-9f4eaa7c8b8303ee/out\" \"-L\" \"/home/clement/.cache/yay/git-delta-git/src/delta/target/release/build/libgit2-sys-69c41211096908ce/out/build\" \"-L\" \"/usr/lib64/rustlib/x86_64-unknown-linux-gnu/lib\" \"-Wl,-Bstatic\" \"/home/clement/.cache/yay/git-delta-git/src/delta/target/release/deps/libctrlc-bbb6852a2a48df02.rlib\" \"/home/clement/.cache/yay/git-delta-git/src/delta/target/release/deps/libnix-2c603f546327d8b3.rlib\" \"/home/clement/.cache/yay/git-delta-git/src/delta/target/release/deps/libpalette-3fab71efec26a952.rlib\" \"/home/clement/.cache/yay/git-delta-git/src/delta/target/release/deps/libfast_srgb8-fa282ec935783f93.rlib\" \"/home/clement/.cache/yay/git-delta-git/src/delta/target/release/deps/libphf-c41b9af61c5b09f8.rlib\" \"/home/clement/.cache/yay/git-delta-git/src/delta/target/release/deps/libphf_shared-dc879fcfe3ce1d2d.rlib\" \"/home/clement/.cache/yay/git-delta-git/src/delta/target/release/deps/libsiphasher-4aea6efb24f6a23a.rlib\" \"/home/clement/.cache/yay/git-delta-git/src/delta/target/release/deps/libapprox-f681af22ad0c7065.rlib\" \"/home/clement/.cache/yay/git-delta-git/src/delta/target/release/deps/libbox_drawing-825d183d526b60d5.rlib\" \"/home/clement/.cache/yay/git-delta-git/src/delta/target/release/deps/libpathdiff-6332c249af60e8d2.rlib\" \"/home/clement/.cache/yay/git-delta-git/src/delta/target/release/deps/libchrono_humanize-1011312ae02d5270.rlib\" \"/home/clement/.cache/yay/git-delta-git/src/delta/target/release/deps/libgit2-5c456929a04fdb71.rlib\" \"/home/clement/.cache/yay/git-delta-git/src/delta/target/release/deps/liburl-1a9de0f15b790a54.rlib\" \"/home/clement/.cache/yay/git-delta-git/src/delta/target/release/deps/libidna-c61073d16e0285b9.rlib\" \"/home/clement/.cache/yay/git-delta-git/src/delta/target/release/deps/libunicode_normalization-1a6f09432bfd9185.rlib\" \"/home/clement/.cache/yay/git-delta-git/src/delta/target/release/deps/libtinyvec-cf2359632ce71d41.rlib\" \"/home/clement/.cache/yay/git-delta-git/src/delta/target/release/deps/libtinyvec_macros-b6076bda174af30b.rlib\" \"/home/clement/.cache/yay/git-delta-git/src/delta/target/release/deps/libunicode_bidi-ba45a1a103d9b6ab.rlib\" \"/home/clement/.cache/yay/git-delta-git/src/delta/target/release/deps/libform_urlencoded-ca67f2d74be0f12e.rlib\" \"/home/clement/.cache/yay/git-delta-git/src/delta/target/release/deps/libpercent_encoding-46c771d8d0efc6bf.rlib\" \"/home/clement/.cache/yay/git-delta-git/src/delta/target/release/deps/liblibgit2_sys-48f6f901be762756.rlib\" \"/home/clement/.cache/yay/git-delta-git/src/delta/target/release/deps/liblibz_sys-b96f27272bce4eff.rlib\" \"/home/clement/.cache/yay/git-delta-git/src/delta/target/release/deps/libdirs-d32b83cfc75f5451.rlib\" \"/home/clement/.cache/yay/git-delta-git/src/delta/target/release/deps/libdirs_sys-fe36d3f9fb7fb28c.rlib\" \"/home/clement/.cache/yay/git-delta-git/src/delta/target/release/deps/liboption_ext-d27b8a32b2953563.rlib\" \"/home/clement/.cache/yay/git-delta-git/src/delta/target/release/deps/libxdg-910a2cd980cbb3d6.rlib\" \"/home/clement/.cache/yay/git-delta-git/src/delta/target/release/deps/libhome-701154559386eaa5.rlib\" \"/home/clement/.cache/yay/git-delta-git/src/delta/target/release/deps/libanyhow-041e139ed51b5278.rlib\" \"/home/clement/.cache/yay/git-delta-git/src/delta/target/release/deps/libsysinfo-d6981df5d13c701f.rlib\" \"/home/clement/.cache/yay/git-delta-git/src/delta/target/release/deps/libchrono-5f1fe9bb3e869958.rlib\" \"/home/clement/.cache/yay/git-delta-git/src/delta/target/release/deps/libnum_traits-4a70d6101d7867c7.rlib\" \"/home/clement/.cache/yay/git-delta-git/src/delta/target/release/deps/libiana_time_zone-390cbebb61b58c44.rlib\" \"/home/clement/.cache/yay/git-delta-git/src/delta/target/release/deps/libtime-e12536e1cd315a58.rlib\" \"/home/clement/.cache/yay/git-delta-git/src/delta/target/release/deps/libsmol_str-d96edf6673de401d.rlib\" \"/home/clement/.cache/yay/git-delta-git/src/delta/target/release/deps/libbytelines-1ee9920f0bbac399.rlib\" \"/home/clement/.cache/yay/git-delta-git/src/delta/target/release/deps/libclap_complete-2fea54e620019c2c.rlib\" \"/home/clement/.cache/yay/git-delta-git/src/delta/target/release/deps/libclap-ab8b7c6d67f8457f.rlib\" \"/home/clement/.cache/yay/git-delta-git/src/delta/target/release/deps/libclap_builder-875dea4fd4afc772.rlib\" \"/home/clement/.cache/yay/git-delta-git/src/delta/target/release/deps/libterminal_size-b004c2ebf8868729.rlib\" \"/home/clement/.cache/yay/git-delta-git/src/delta/target/release/deps/librustix-e37da1fda6730ec3.rlib\" \"/home/clement/.cache/yay/git-delta-git/src/delta/target/release/deps/libio_lifetimes-821b6f47339654ea.rlib\" \"/home/clement/.cache/yay/git-delta-git/src/delta/target/release/deps/liblinux_raw_sys-a5ffed5acf204dc1.rlib\" \"/home/clement/.cache/yay/git-delta-git/src/delta/target/release/deps/libstrsim-21887bedd3871408.rlib\" \"/home/clement/.cache/yay/git-delta-git/src/delta/target/release/deps/libanstream-7e2a1cd77936c581.rlib\" \"/home/clement/.cache/yay/git-delta-git/src/delta/target/release/deps/libanstyle_query-513146763e7f89cb.rlib\" \"/home/clement/.cache/yay/git-delta-git/src/delta/target/release/deps/libis_terminal-3409342eb8e237a2.rlib\" \"/home/clement/.cache/yay/git-delta-git/src/delta/target/release/deps/librustix-00d00e98b0538732.rlib\" \"/home/clement/.cache/yay/git-delta-git/src/delta/target/release/deps/libbitflags-a3028726d8f5bd2c.rlib\" \"/home/clement/.cache/yay/git-delta-git/src/delta/target/release/deps/liblinux_raw_sys-908c4669b82a765e.rlib\" \"/home/clement/.cache/yay/git-delta-git/src/delta/target/release/deps/libanstyle-18d471c5d09516ac.rlib\" \"/home/clement/.cache/yay/git-delta-git/src/delta/target/release/deps/libcolorchoice-229f2f1a20349974.rlib\" \"/home/clement/.cache/yay/git-delta-git/src/delta/target/release/deps/libanstyle_parse-e819a1f89401032e.rlib\" \"/home/clement/.cache/yay/git-delta-git/src/delta/target/release/deps/libclap_lex-0cbaf51f0e542e94.rlib\" \"/home/clement/.cache/yay/git-delta-git/src/delta/target/release/deps/libbat-6739e671aee20958.rlib\" \"/home/clement/.cache/yay/git-delta-git/src/delta/target/release/deps/libansi_colours-c61e45e0b63265de.rlib\" \"/home/clement/.cache/yay/git-delta-git/src/delta/target/release/deps/librgb-2d68aa7956261bc4.rlib\" \"/home/clement/.cache/yay/git-delta-git/src/delta/target/release/deps/libbytemuck-d2a173ffb709c3d2.rlib\" \"/home/clement/.cache/yay/git-delta-git/src/delta/target/release/deps/libgrep_cli-bfb7d1043b793d88.rlib\" \"/home/clement/.cache/yay/git-delta-git/src/delta/target/release/deps/libtermcolor-702994de4c47d155.rlib\" \"/home/clement/.cache/yay/git-delta-git/src/delta/target/release/deps/libserde_yaml-d4b8336479bbe732.rlib\" \"/home/clement/.cache/yay/git-delta-git/src/delta/target/release/deps/libglobset-d726ca7a202de5b1.rlib\" \"/home/clement/.cache/yay/git-delta-git/src/delta/target/release/deps/liblog-a5955c1bdfd5fada.rlib\" \"/home/clement/.cache/yay/git-delta-git/src/delta/target/release/deps/libregex-cfec84b4d9688a43.rlib\" \"/home/clement/.cache/yay/git-delta-git/src/delta/target/release/deps/libbstr-064d2b354f16c78a.rlib\" \"/home/clement/.cache/yay/git-delta-git/src/delta/target/release/deps/libregex_automata-caffe34bd21b1143.rlib\" \"/home/clement/.cache/yay/git-delta-git/src/delta/target/release/deps/libregex_syntax-63057b219945ce5b.rlib\" \"/home/clement/.cache/yay/git-delta-git/src/delta/target/release/deps/libaho_corasick-893f0ab2233c6dc5.rlib\" \"/home/clement/.cache/yay/git-delta-git/src/delta/target/release/deps/libencoding-6f08135db997f7b0.rlib\" \"/home/clement/.cache/yay/git-delta-git/src/delta/target/release/deps/libencoding_index_tradchinese-5b988073813a7d9b.rlib\" \"/home/clement/.cache/yay/git-delta-git/src/delta/target/release/deps/libencoding_index_simpchinese-186a74c69b13e695.rlib\" \"/home/clement/.cache/yay/git-delta-git/src/delta/target/release/deps/libencoding_index_japanese-4cf754936452d52c.rlib\" \"/home/clement/.cache/yay/git-delta-git/src/delta/target/release/deps/libencoding_index_korean-940985a951a18469.rlib\" \"/home/clement/.cache/yay/git-delta-git/src/delta/target/release/deps/libencoding_index_singlebyte-954e6f7fcd2ac5dd.rlib\" \"/home/clement/.cache/yay/git-delta-git/src/delta/target/release/deps/libbytesize-4b9c2a26c737dfbe.rlib\" \"/home/clement/.cache/yay/git-delta-git/src/delta/target/release/deps/libconsole-4cea73df08457ae3.rlib\" \"/home/clement/.cache/yay/git-delta-git/src/delta/target/release/deps/libshell_words-0d0f1b5d20b5abc8.rlib\" \"/home/clement/.cache/yay/git-delta-git/src/delta/target/release/deps/libcontent_inspector-5ef783ad39ab7da1.rlib\" \"/home/clement/.cache/yay/git-delta-git/src/delta/target/release/deps/libnu_ansi_term-16fda7009c7e43e4.rlib\" \"/home/clement/.cache/yay/git-delta-git/src/delta/target/release/deps/libclircle-5ab5a0bb3fd78403.rlib\" \"/home/clement/.cache/yay/git-delta-git/src/delta/target/release/deps/liblibc-64cf10aaecc96d59.rlib\" \"/home/clement/.cache/yay/git-delta-git/src/delta/target/release/deps/libsemver-bca6528c8bc13805.rlib\" \"/home/clement/.cache/yay/git-delta-git/src/delta/target/release/deps/libpath_abs-01bf2e93658a4342.rlib\" \"/home/clement/.cache/yay/git-delta-git/src/delta/target/release/deps/libstd_prelude-4dce925a45ee7119.rlib\" \"/home/clement/.cache/yay/git-delta-git/src/delta/target/release/deps/libsyntect-eab86f2473421451.rlib\" \"/home/clement/.cache/yay/git-delta-git/src/delta/target/release/deps/libthiserror-e5432c71934f52c6.rlib\" \"/home/clement/.cache/yay/git-delta-git/src/delta/target/release/deps/libwalkdir-108a8667a6a7685e.rlib\" \"/home/clement/.cache/yay/git-delta-git/src/delta/target/release/deps/libsame_file-ec2dfbd72fbea145.rlib\" \"/home/clement/.cache/yay/git-delta-git/src/delta/target/release/deps/libonig-45f5d891c751d818.rlib\" \"/home/clement/.cache/yay/git-delta-git/src/delta/target/release/deps/libonig_sys-a028435a0d393a47.rlib\" \"/home/clement/.cache/yay/git-delta-git/src/delta/target/release/deps/libyaml_rust-08e31f67aa564ca5.rlib\" \"/home/clement/.cache/yay/git-delta-git/src/delta/target/release/deps/liblinked_hash_map-79c59b20acb3b899.rlib\" \"/home/clement/.cache/yay/git-delta-git/src/delta/target/release/deps/libregex_syntax-b7e7b870a75c13c4.rlib\" \"/home/clement/.cache/yay/git-delta-git/src/delta/target/release/deps/libfnv-dd53d7bf1af72b3a.rlib\" \"/home/clement/.cache/yay/git-delta-git/src/delta/target/release/deps/libbitflags-2d3fb3aa751004a9.rlib\" \"/home/clement/.cache/yay/git-delta-git/src/delta/target/release/deps/libserde_json-38b46d231a716079.rlib\" \"/home/clement/.cache/yay/git-delta-git/src/delta/target/release/deps/libryu-cbfbab7eab8a4de1.rlib\" \"/home/clement/.cache/yay/git-delta-git/src/delta/target/release/deps/libplist-5bfcebc7b900f661.rlib\" \"/home/clement/.cache/yay/git-delta-git/src/delta/target/release/deps/libline_wrap-fa5db947b36d0cef.rlib\" \"/home/clement/.cache/yay/git-delta-git/src/delta/target/release/deps/libsafemem-38077433f3d46895.rlib\" \"/home/clement/.cache/yay/git-delta-git/src/delta/target/release/deps/libtime-0842cbd1ef86e1af.rlib\" \"/home/clement/.cache/yay/git-delta-git/src/delta/target/release/deps/libitoa-ffa09a849e18fbaa.rlib\" \"/home/clement/.cache/yay/git-delta-git/src/delta/target/release/deps/libtime_core-40de2277850661c6.rlib\" \"/home/clement/.cache/yay/git-delta-git/src/delta/target/release/deps/libquick_xml-841c45cd9c6c1528.rlib\" \"/home/clement/.cache/yay/git-delta-git/src/delta/target/release/deps/libmemchr-b9f7cdd7a0ccceef.rlib\" \"/home/clement/.cache/yay/git-delta-git/src/delta/target/release/deps/libbase64-08e958696c850dc8.rlib\" \"/home/clement/.cache/yay/git-delta-git/src/delta/target/release/deps/libindexmap-70bbfa52bcdbe274.rlib\" \"/home/clement/.cache/yay/git-delta-git/src/delta/target/release/deps/libhashbrown-97e897e1b4acae82.rlib\" \"/home/clement/.cache/yay/git-delta-git/src/delta/target/release/deps/libflate2-9d2486d8af64bc86.rlib\" \"/home/clement/.cache/yay/git-delta-git/src/delta/target/release/deps/libminiz_oxide-107d99311751d868.rlib\" \"/home/clement/.cache/yay/git-delta-git/src/delta/target/release/deps/libadler-c80b88fc3cb29575.rlib\" \"/home/clement/.cache/yay/git-delta-git/src/delta/target/release/deps/libcrc32fast-2c2b918d38088358.rlib\" \"/home/clement/.cache/yay/git-delta-git/src/delta/target/release/deps/libcfg_if-ff378949fa9efc6d.rlib\" \"/home/clement/.cache/yay/git-delta-git/src/delta/target/release/deps/libbincode-cc83d116251a6fad.rlib\" \"/home/clement/.cache/yay/git-delta-git/src/delta/target/release/deps/libserde-83b26c87a5299bcb.rlib\" \"/home/clement/.cache/yay/git-delta-git/src/delta/target/release/deps/liblazy_static-ed85c14336dd57f7.rlib\" \"/home/clement/.cache/yay/git-delta-git/src/delta/target/release/deps/libonce_cell-5504836c02d3a354.rlib\" \"/home/clement/.cache/yay/git-delta-git/src/delta/target/release/deps/libunicode_width-f970aa16a71d9967.rlib\" \"/home/clement/.cache/yay/git-delta-git/src/delta/target/release/deps/libunicode_segmentation-7e08fff408690820.rlib\" \"/home/clement/.cache/yay/git-delta-git/src/delta/target/release/deps/libitertools-a012ca4b7b0daa87.rlib\" \"/home/clement/.cache/yay/git-delta-git/src/delta/target/release/deps/libeither-f5d4a523c33aea4c.rlib\" \"/home/clement/.cache/yay/git-delta-git/src/delta/target/release/deps/libansi_term-6b10db8b1e3c8fdb.rlib\" \"/home/clement/.cache/yay/git-delta-git/src/delta/target/release/deps/libvte-212e78d1433e9eda.rlib\" \"/home/clement/.cache/yay/git-delta-git/src/delta/target/release/deps/libutf8parse-c3f0bfa1f33e3523.rlib\" \"/home/clement/.cache/yay/git-delta-git/src/delta/target/release/deps/libarrayvec-070e05729dfc8ade.rlib\" \"/usr/lib64/rustlib/x86_64-unknown-linux-gnu/lib/libstd-dce4da11b2ccc789.rlib\" \"/usr/lib64/rustlib/x86_64-unknown-linux-gnu/lib/libpanic_unwind-c5aff1055622daf3.rlib\" \"/usr/lib64/rustlib/x86_64-unknown-linux-gnu/lib/libobject-9027304ca17f2680.rlib\" \"/usr/lib64/rustlib/x86_64-unknown-linux-gnu/lib/libmemchr-c5fb359364fdb009.rlib\" \"/usr/lib64/rustlib/x86_64-unknown-linux-gnu/lib/libaddr2line-19a4ac3a15b73927.rlib\" \"/usr/lib64/rustlib/x86_64-unknown-linux-gnu/lib/libgimli-545ef01c478e3996.rlib\" \"/usr/lib64/rustlib/x86_64-unknown-linux-gnu/lib/librustc_demangle-6ac5c2838ec4f836.rlib\" \"/usr/lib64/rustlib/x86_64-unknown-linux-gnu/lib/libstd_detect-290b884672cd911f.rlib\" \"/usr/lib64/rustlib/x86_64-unknown-linux-gnu/lib/libhashbrown-f9093be1927a1602.rlib\" \"/usr/lib64/rustlib/x86_64-unknown-linux-gnu/lib/librustc_std_workspace_alloc-19087ab4fa333a2c.rlib\" \"/usr/lib64/rustlib/x86_64-unknown-linux-gnu/lib/libminiz_oxide-f66fa5fbf4547710.rlib\" \"/usr/lib64/rustlib/x86_64-unknown-linux-gnu/lib/libadler-d7285f96d8856fea.rlib\" \"/usr/lib64/rustlib/x86_64-unknown-linux-gnu/lib/libunwind-406c5a4d6fa7f15b.rlib\" \"/usr/lib64/rustlib/x86_64-unknown-linux-gnu/lib/libcfg_if-43d91895302c1941.rlib\" \"/usr/lib64/rustlib/x86_64-unknown-linux-gnu/lib/liblibc-8e42f4a5e7a1d2d4.rlib\" \"/usr/lib64/rustlib/x86_64-unknown-linux-gnu/lib/liballoc-79b317ec80906222.rlib\" \"/usr/lib64/rustlib/x86_64-unknown-linux-gnu/lib/librustc_std_workspace_core-099918608866d404.rlib\" \"/usr/lib64/rustlib/x86_64-unknown-linux-gnu/lib/libcore-9a01eccf23a84d5b.rlib\" \"/usr/lib64/rustlib/x86_64-unknown-linux-gnu/lib/libcompiler_builtins-dc359f8c64813cd3.rlib\" \"-Wl,-Bdynamic\" \"-lz\" \"-lgcc_s\" \"-lutil\" \"-lrt\" \"-lpthread\" \"-lm\" \"-ldl\" \"-lc\" \"-Wl,--eh-frame-hdr\" \"-Wl,-z,noexecstack\" \"-L\" \"/usr/lib64/rustlib/x86_64-unknown-linux-gnu/lib\" \"-o\" \"/home/clement/.cache/yay/git-delta-git/src/delta/target/release/deps/delta-340c855f98c02c6b\" \"-Wl,--gc-sections\" \"-pie\" \"-Wl,-z,relro,-z,now\" \"-Wl,-O1\" \"-nodefaultlibs\"\r\n = note: /usr/bin/ld: /home/clement/.cache/yay/git-delta-git/src/delta/target/release/deps/liblibgit2_sys-48f6f901be762756.rlib(libgit2_sys-48f6f901be762756.libgit2_sys.dd2e6843b1b72bd7-cgu.0.rcgu.o): in function `libgit2_sys::init::{{closure}}':\r\n /home/clement/.cargo/registry/src/index.crates.io-6f17d22bba15001f/libgit2-sys-0.15.2+1.6.4/lib.rs:4243:(.text.unlikely._ZN3std10sys_common4once5futex4Once4call17h8addfb411a121b0aE+0xb0): undefined reference to `git_libgit2_init'\r\n /usr/bin/ld: /home/clement/.cargo/registry/src/index.crates.io-6f17d22bba15001f/libgit2-sys-0.15.2+1.6.4/lib.rs:4252:(.text.unlikely._ZN3std10sys_common4once5futex4Once4call17h8addfb411a121b0aE+0x15c): undefined reference to `git_error_last'\r\n /usr/bin/ld: /home/clement/.cache/yay/git-delta-git/src/delta/target/release/deps/libsyntect-eab86f2473421451.rlib(syntect-eab86f2473421451.syntect.f641a764216d1ef6-cgu.12.rcgu.o): in function `onig::syntax::Syntax::default':\r\n /home/clement/.cargo/registry/src/index.crates.io-6f17d22bba15001f/onig-6.4.0/src/syntax.rs:97:(.text._ZN4core3ops8function6FnOnce40call_once$u7b$$u7b$vtable.shim$u7d$$u7d$17h7fa14eb015c2042fE.llvm.7893781050962898617+0x28): undefined reference to `OnigDefaultSyntax'\r\n /usr/bin/ld: /home/clement/.cargo/registry/src/index.crates.io-6f17d22bba15001f/onig-6.4.0/src/syntax.rs:97:(.text._ZN9once_cell3imp17OnceCell$LT$T$GT$10initialize28_$u7b$$u7b$closure$u7d$$u7d$17h8b2bb4e58f56d232E.llvm.7893781050962898617+0x27): undefined reference to `OnigDefaultSyntax'\r\n /usr/bin/ld: /home/clement/.cache/yay/git-delta-git/src/delta/target/release/deps/libonig-45f5d891c751d818.rlib(onig-45f5d891c751d818.onig.36b05d929265f9b6-cgu.1.rcgu.o): in function `<onig::match_param::MatchParam as core::default::Default>::default':\r\n /home/clement/.cargo/registry/src/index.crates.io-6f17d22bba15001f/onig-6.4.0/src/match_param.rs:37:(.text._ZN72_$LT$onig..match_param..MatchParam$u20$as$u20$core..default..Default$GT$7default17h30dd42d2acfa5d0eE+0x3): undefined reference to `onig_new_match_param'\r\n /usr/bin/ld: /home/clement/.cargo/registry/src/index.crates.io-6f17d22bba15001f/onig-6.4.0/src/match_param.rs:38:(.text._ZN72_$LT$onig..match_param..MatchParam$u20$as$u20$core..default..Default$GT$7default17h30dd42d2acfa5d0eE+0xf): undefined reference to `onig_initialize_match_param'\r\n /usr/bin/ld: /home/clement/.cache/yay/git-delta-git/src/delta/target/release/deps/libonig-45f5d891c751d818.rlib(onig-45f5d891c751d818.onig.36b05d929265f9b6-cgu.1.rcgu.o): in function `<onig::match_param::MatchParam as core::ops::drop::Drop>::drop':\r\n /home/clement/.cargo/registry/src/index.crates.io-6f17d22bba15001f/onig-6.4.0/src/match_param.rs:48:(.text._ZN71_$LT$onig..match_param..MatchParam$u20$as$u20$core..ops..drop..Drop$GT$4drop17hbaeadb2ca8e276e0E+0x5): undefined reference to `onig_free_match_param'\r\n /usr/bin/ld: /home/clement/.cache/yay/git-delta-git/src/delta/target/release/deps/libonig-45f5d891c751d818.rlib(onig-45f5d891c751d818.onig.36b05d929265f9b6-cgu.2.rcgu.o): in function `<onig::region::Region as core::ops::drop::Drop>::drop':\r\n /home/clement/.cargo/registry/src/index.crates.io-6f17d22bba15001f/onig-6.4.0/src/region.rs:208:(.text._ZN4core3ptr41drop_in_place$LT$onig..region..Region$GT$17h3d95ac49061210f2E+0x4): undefined reference to `onig_region_free'\r\n /usr/bin/ld: /home/clement/.cache/yay/git-delta-git/src/delta/target/release/deps/libonig-45f5d891c751d818.rlib(onig-45f5d891c751d818.onig.36b05d929265f9b6-cgu.2.rcgu.o): in function `onig::region::Region::reserve':\r\n /home/clement/.cargo/registry/src/index.crates.io-6f17d22bba15001f/onig-6.4.0/src/region.rs:81:(.text._ZN4onig6region6Region13with_capacity17ha6b46158920f961cE+0x19): undefined reference to `onig_region_resize'\r\n /usr/bin/ld: /home/clement/.cache/yay/git-delta-git/src/delta/target/release/deps/libonig-45f5d891c751d818.rlib(onig-45f5d891c751d818.onig.36b05d929265f9b6-cgu.2.rcgu.o): in function `<onig::region::Region as core::ops::drop::Drop>::drop':\r\n /home/clement/.cargo/registry/src/index.crates.io-6f17d22bba15001f/onig-6.4.0/src/region.rs:208:(.text._ZN62_$LT$onig..region..Region$u20$as$u20$core..ops..drop..Drop$GT$4drop17h0288d0a83ab14cb4E+0x4): undefined reference to `onig_region_free'\r\n /usr/bin/ld: /home/clement/.cache/yay/git-delta-git/src/delta/target/release/deps/libonig-45f5d891c751d818.rlib(onig-45f5d891c751d818.onig.36b05d929265f9b6-cgu.2.rcgu.o): in function `onig::region::Region::clone_from_raw':\r\n /home/clement/.cargo/registry/src/index.crates.io-6f17d22bba15001f/onig-6.4.0/src/region.rs:52:(.text._ZN59_$LT$onig..region..Region$u20$as$u20$core..clone..Clone$GT$5clone17h1438b1195e932864E+0x19): undefined reference to `onig_region_copy'\r\n /usr/bin/ld: /home/clement/.cache/yay/git-delta-git/src/delta/target/release/deps/delta-340c855f98c02c6b.delta.f0b890de4f8c8231-cgu.08.rcgu.o: in function `git2::repo::Repository::discover':\r\n /home/clement/.cargo/registry/src/index.crates.io-6f17d22bba15001f/git2-0.17.2/src/repo.rs:254:(.text._ZN4git24repo10Repository8discover17h20c779139a3cddebE+0x6b): undefined reference to `git_repository_discover'\r\n /usr/bin/ld: /home/clement/.cache/yay/git-delta-git/src/delta/target/release/deps/delta-340c855f98c02c6b.delta.f0b890de4f8c8231-cgu.08.rcgu.o: in function `git2::repo::Repository::open':\r\n /home/clement/.cargo/registry/src/index.crates.io-6f17d22bba15001f/git2-0.17.2/src/repo.rs:137:(.text._ZN4git24repo10Repository8discover17h20c779139a3cddebE+0xda): undefined reference to `git_repository_open'\r\n /usr/bin/ld: /home/clement/.cache/yay/git-delta-git/src/delta/target/release/deps/libgit2-5c456929a04fdb71.rlib(git2-5c456929a04fdb71.git2.e001ce5ee71611f4-cgu.00.rcgu.o): in function `git2::repo::Repository::find_remote':\r\n /home/clement/.cargo/registry/src/index.crates.io-6f17d22bba15001f/git2-0.17.2/src/repo.rs:592:(.text._ZN4git24repo10Repository11find_remote17haa669d284156d8f2E+0x59): undefined reference to `git_remote_lookup'\r\n /usr/bin/ld: /home/clement/.cache/yay/git-delta-git/src/delta/target/release/deps/libgit2-5c456929a04fdb71.rlib(git2-5c456929a04fdb71.git2.e001ce5ee71611f4-cgu.00.rcgu.o): in function `git2::repo::Repository::config':\r\n /home/clement/.cargo/registry/src/index.crates.io-6f17d22bba15001f/git2-0.17.2/src/repo.rs:1062:(.text._ZN4git24repo10Repository6config17h93daff0580d2f683E+0x1b): undefined reference to `git_repository_config'\r\n /usr/bin/ld: /home/clement/.cache/yay/git-delta-git/src/delta/target/release/deps/libgit2-5c456929a04fdb71.rlib(git2-5c456929a04fdb71.git2.e001ce5ee71611f4-cgu.00.rcgu.o): in function `<git2::repo::Repository as core::ops::drop::Drop>::drop':\r\n /home/clement/.cargo/registry/src/index.crates.io-6f17d22bba15001f/git2-0.17.2/src/repo.rs:3233:(.text._ZN64_$LT$git2..repo..Repository$u20$as$u20$core..ops..drop..Drop$GT$4drop17h76d6220ef68f9b44E+0x5): undefined reference to `git_repository_free'\r\n /usr/bin/ld: /home/clement/.cache/yay/git-delta-git/src/delta/target/release/deps/libgit2-5c456929a04fdb71.rlib(git2-5c456929a04fdb71.git2.e001ce5ee71611f4-cgu.08.rcgu.o): in function `<git2::buf::Buf as core::ops::drop::Drop>::drop':\r\n /home/clement/.cargo/registry/src/index.crates.io-6f17d22bba15001f/git2-0.17.2/src/buf.rs:69:(.text._ZN4core3ptr35drop_in_place$LT$git2..buf..Buf$GT$17hf670157c6536d3cbE+0x2): undefined reference to `git_buf_dispose'\r\n /usr/bin/ld: /home/clement/.cache/yay/git-delta-git/src/delta/target/release/deps/libgit2-5c456929a04fdb71.rlib(git2-5c456929a04fdb71.git2.e001ce5ee71611f4-cgu.08.rcgu.o): in function `git2::config::Config::open':\r\n /home/clement/.cargo/registry/src/index.crates.io-6f17d22bba15001f/git2-0.17.2/src/config.rs:83:(.text._ZN4git26config6Config4open17h2133e4ab40614708E+0x7e): undefined reference to `git_config_open_ondisk'\r\n /usr/bin/ld: /home/clement/.cache/yay/git-delta-git/src/delta/target/release/deps/libgit2-5c456929a04fdb71.rlib(git2-5c456929a04fdb71.git2.e001ce5ee71611f4-cgu.08.rcgu.o): in function `git2::config::Config::open_default':\r\n /home/clement/.cargo/registry/src/index.crates.io-6f17d22bba15001f/git2-0.17.2/src/config.rs:97:(.text._ZN4git26config6Config12open_default17h8da040e53af389a7E+0x2d): undefined reference to `git_config_open_default'\r\n /usr/bin/ld: /home/clement/.cache/yay/git-delta-git/src/delta/target/release/deps/libgit2-5c456929a04fdb71.rlib(git2-5c456929a04fdb71.git2.e001ce5ee71611f4-cgu.08.rcgu.o): in function `git2::config::Config::get_bool':\r\n /home/clement/.cargo/registry/src/index.crates.io-6f17d22bba15001f/git2-0.17.2/src/config.rs:203:(.text._ZN4git26config6Config8get_bool17h1ac5d5758ca681b5E+0x58): undefined reference to `git_config_get_bool'\r\n /usr/bin/ld: /home/clement/.cache/yay/git-delta-git/src/delta/target/release/deps/libgit2-5c456929a04fdb71.rlib(git2-5c456929a04fdb71.git2.e001ce5ee71611f4-cgu.08.rcgu.o): in function `git2::config::Config::get_i64':\r\n /home/clement/.cargo/registry/src/index.crates.io-6f17d22bba15001f/git2-0.17.2/src/config.rs:231:(.text._ZN4git26config6Config7get_i6417h25735a2fd4cbe5c5E+0x59): undefined reference to `git_config_get_int64'\r\n /usr/bin/ld: /home/clement/.cache/yay/git-delta-git/src/delta/target/release/deps/libgit2-5c456929a04fdb71.rlib(git2-5c456929a04fdb71.git2.e001ce5ee71611f4-cgu.08.rcgu.o): in function `git2::config::Config::get_string':\r\n /home/clement/.cargo/registry/src/index.crates.io-6f17d22bba15001f/git2-0.17.2/src/config.rs:270:(.text._ZN4git26config6Config10get_string17hef3fe166632a5672E+0x81): undefined reference to `git_config_get_string_buf'\r\n /usr/bin/ld: /home/clement/.cargo/registry/src/index.crates.io-6f17d22bba15001f/git2-0.17.2/src/config.rs:275:(.text._ZN4git26config6Config10get_string17hef3fe166632a5672E+0x31b): undefined reference to `git_buf_dispose'\r\n /usr/bin/ld: /home/clement/.cache/yay/git-delta-git/src/delta/target/release/deps/libgit2-5c456929a04fdb71.rlib(git2-5c456929a04fdb71.git2.e001ce5ee71611f4-cgu.08.rcgu.o): in function `git2::config::Config::entries':\r\n /home/clement/.cargo/registry/src/index.crates.io-6f17d22bba15001f/git2-0.17.2/src/config.rs:336:(.text._ZN4git26config6Config7entries17h94037dc5f3ce814eE+0x5e): undefined reference to `git_config_iterator_glob_new'\r\n /usr/bin/ld: /home/clement/.cargo/registry/src/index.crates.io-6f17d22bba15001f/git2-0.17.2/src/config.rs:339:(.text._ZN4git26config6Config7entries17h94037dc5f3ce814eE+0x91): undefined reference to `git_config_iterator_new'\r\n /usr/bin/ld: /home/clement/.cache/yay/git-delta-git/src/delta/target/release/deps/libgit2-5c456929a04fdb71.rlib(git2-5c456929a04fdb71.git2.e001ce5ee71611f4-cgu.08.rcgu.o): in function `git2::config::Config::snapshot':\r\n /home/clement/.cargo/registry/src/index.crates.io-6f17d22bba15001f/git2-0.17.2/src/config.rs:458:(.text._ZN4git26config6Config8snapshot17hfb67222d8e39c709E+0x1b): undefined reference to `git_config_snapshot'\r\n /usr/bin/ld: /home/clement/.cache/yay/git-delta-git/src/delta/target/release/deps/libgit2-5c456929a04fdb71.rlib(git2-5c456929a04fdb71.git2.e001ce5ee71611f4-cgu.08.rcgu.o): in function `<git2::config::Config as core::ops::drop::Drop>::drop':\r\n /home/clement/.cargo/registry/src/index.crates.io-6f17d22bba15001f/git2-0.17.2/src/config.rs:514:(.text._ZN62_$LT$git2..config..Config$u20$as$u20$core..ops..drop..Drop$GT$4drop17h637459f95eb740c0E+0x5): undefined reference to `git_config_free'\r\n /usr/bin/ld: /home/clement/.cache/yay/git-delta-git/src/delta/target/release/deps/libgit2-5c456929a04fdb71.rlib(git2-5c456929a04fdb71.git2.e001ce5ee71611f4-cgu.08.rcgu.o): in function `<git2::config::ConfigEntry as core::ops::drop::Drop>::drop':\r\n /home/clement/.cargo/registry/src/index.crates.io-6f17d22bba15001f/git2-0.17.2/src/config.rs:637:(.text._ZN4git26config13ConfigEntries4next17h304ee4a055cba1abE+0x27): undefined reference to `git_config_entry_free'\r\n /usr/bin/ld: /home/clement/.cache/yay/git-delta-git/src/delta/target/release/deps/libgit2-5c456929a04fdb71.rlib(git2-5c456929a04fdb71.git2.e001ce5ee71611f4-cgu.08.rcgu.o): in function `git2::config::ConfigEntries::next':\r\n /home/clement/.cargo/registry/src/index.crates.io-6f17d22bba15001f/git2-0.17.2/src/config.rs:607:(.text._ZN4git26config13ConfigEntries4next17h304ee4a055cba1abE+0x33): undefined reference to `git_config_next'\r\n /usr/bin/ld: /home/clement/.cache/yay/git-delta-git/src/delta/target/release/deps/libgit2-5c456929a04fdb71.rlib(git2-5c456929a04fdb71.git2.e001ce5ee71611f4-cgu.08.rcgu.o): in function `<git2::config::ConfigEntries as core::ops::drop::Drop>::drop':\r\n /home/clement/.cargo/registry/src/index.crates.io-6f17d22bba15001f/git2-0.17.2/src/config.rs:630:(.text._ZN69_$LT$git2..config..ConfigEntries$u20$as$u20$core..ops..drop..Drop$GT$4drop17h97b93ed6ac87837aE+0x5): undefined reference to `git_config_iterator_free'\r\n /usr/bin/ld: /home/clement/.cache/yay/git-delta-git/src/delta/target/release/deps/libgit2-5c456929a04fdb71.rlib(git2-5c456929a04fdb71.git2.e001ce5ee71611f4-cgu.08.rcgu.o): in function `<git2::config::ConfigEntry as core::ops::drop::Drop>::drop':\r\n /home/clement/.cargo/registry/src/index.crates.io-6f17d22bba15001f/git2-0.17.2/src/config.rs:637:(.text._ZN67_$LT$git2..config..ConfigEntry$u20$as$u20$core..ops..drop..Drop$GT$4drop17ha31baffac3d896f7E+0xb): undefined reference to `git_config_entry_free'\r\n /usr/bin/ld: /home/clement/.cache/yay/git-delta-git/src/delta/target/release/deps/libgit2-5c456929a04fdb71.rlib(git2-5c456929a04fdb71.git2.e001ce5ee71611f4-cgu.10.rcgu.o): in function `git2::error::Error::last_error':\r\n /home/clement/.cargo/registry/src/index.crates.io-6f17d22bba15001f/git2-0.17.2/src/error.rs:58:(.text._ZN4git25error5Error10last_error17hffc08210b8b27171E+0x2a): undefined reference to `git_error_last'\r\n /usr/bin/ld: /home/clement/.cargo/registry/src/index.crates.io-6f17d22bba15001f/git2-0.17.2/src/error.rs:58:(.text._ZN4git25error5Error10last_error17hffc08210b8b27171E+0x130): undefined reference to `git_error_last'\r\n /usr/bin/ld: /home/clement/.cargo/registry/src/index.crates.io-6f17d22bba15001f/git2-0.17.2/src/error.rs:66:(.text._ZN4git25error5Error10last_error17hffc08210b8b27171E+0x196): undefined reference to `git_error_clear'\r\n /usr/bin/ld: /home/clement/.cache/yay/git-delta-git/src/delta/target/release/deps/libgit2-5c456929a04fdb71.rlib(git2-5c456929a04fdb71.git2.e001ce5ee71611f4-cgu.13.rcgu.o): in function `<git2::buf::Buf as core::ops::drop::Drop>::drop':\r\n /home/clement/.cargo/registry/src/index.crates.io-6f17d22bba15001f/git2-0.17.2/src/buf.rs:69:(.text._ZN56_$LT$git2..buf..Buf$u20$as$u20$core..ops..drop..Drop$GT$4drop17hc21452020d375b33E+0x2): undefined reference to `git_buf_dispose'\r\n /usr/bin/ld: /home/clement/.cache/yay/git-delta-git/src/delta/target/release/deps/libgit2-5c456929a04fdb71.rlib(git2-5c456929a04fdb71.git2.e001ce5ee71611f4-cgu.15.rcgu.o): in function `git2::remote::Remote::url_bytes':\r\n /home/clement/.cargo/registry/src/index.crates.io-6f17d22bba15001f/git2-0.17.2/src/remote.rs:146:(.text._ZN4git26remote6Remote3url17h0302733b5c0e42f5E+0xa): undefined reference to `git_remote_url'\r\n /usr/bin/ld: /home/clement/.cache/yay/git-delta-git/src/delta/target/release/deps/libgit2-5c456929a04fdb71.rlib(git2-5c456929a04fdb71.git2.e001ce5ee71611f4-cgu.15.rcgu.o): in function `<git2::remote::Remote as core::ops::drop::Drop>::drop':\r\n /home/clement/.cargo/registry/src/index.crates.io-6f17d22bba15001f/git2-0.17.2/src/remote.rs:445:(.text._ZN62_$LT$git2..remote..Remote$u20$as$u20$core..ops..drop..Drop$GT$4drop17h4122e77c3d6ff90aE+0x5): undefined reference to `git_remote_free'\r\n /usr/bin/ld: /home/clement/.cache/yay/git-delta-git/src/delta/target/release/deps/libsyntect-eab86f2473421451.rlib(syntect-eab86f2473421451.syntect.f641a764216d1ef6-cgu.06.rcgu.o): in function `onig::Regex::search_with_param':\r\n /home/clement/.cargo/registry/src/index.crates.io-6f17d22bba15001f/onig-6.4.0/src/lib.rs:707:(.text._ZN4onig5Regex17search_with_param17h51018bce7cf2fbd3E+0x3c): undefined reference to `OnigEncodingUTF8'\r\n /usr/bin/ld: /home/clement/.cargo/registry/src/index.crates.io-6f17d22bba15001f/onig-6.4.0/src/lib.rs:710:(.text._ZN4onig5Regex17search_with_param17h51018bce7cf2fbd3E+0x49): undefined reference to `OnigEncodingUTF8'\r\n /usr/bin/ld: /home/clement/.cargo/registry/src/index.crates.io-6f17d22bba15001f/onig-6.4.0/src/lib.rs:723:(.text._ZN4onig5Regex17search_with_param17h51018bce7cf2fbd3E+0x1cb): undefined reference to `onig_search_with_param'\r\n /usr/bin/ld: /home/clement/.cache/yay/git-delta-git/src/delta/target/release/deps/libonig-45f5d891c751d818.rlib(onig-45f5d891c751d818.onig.36b05d929265f9b6-cgu.3.rcgu.o): in function `onig::Error::new':\r\n /home/clement/.cargo/registry/src/index.crates.io-6f17d22bba15001f/onig-6.4.0/src/lib.rs:166:(.text._ZN4onig5Error3new17h3f567a3a67144f30E+0x40): undefined reference to `onig_error_code_to_str'\r\n /usr/bin/ld: /home/clement/.cache/yay/git-delta-git/src/delta/target/release/deps/libonig-45f5d891c751d818.rlib(onig-45f5d891c751d818.onig.36b05d929265f9b6-cgu.3.rcgu.o): in function `onig::Regex::with_options_and_encoding':\r\n /home/clement/.cargo/registry/src/index.crates.io-6f17d22bba15001f/onig-6.4.0/src/lib.rs:347:(.text._ZN4onig5Regex25with_options_and_encoding17hb47373bcb270f3a5E+0x97): undefined reference to `OnigEncodingUTF8'\r\n /usr/bin/ld: /home/clement/.cargo/registry/src/index.crates.io-6f17d22bba15001f/onig-6.4.0/src/lib.rs:347:(.text._ZN4onig5Regex25with_options_and_encoding17hb47373bcb270f3a5E+0xad): undefined reference to `onig_new'\r\n /usr/bin/ld: /home/clement/.cache/yay/git-delta-git/src/delta/target/release/deps/libonig-45f5d891c751d818.rlib(onig-45f5d891c751d818.onig.36b05d929265f9b6-cgu.3.rcgu.o): in function `onig::Error::new':\r\n /home/clement/.cargo/registry/src/index.crates.io-6f17d22bba15001f/onig-6.4.0/src/lib.rs:166:(.text._ZN4onig5Regex25with_options_and_encoding17hb47373bcb270f3a5E+0x125): undefined reference to `onig_error_code_to_str'\r\n /usr/bin/ld: /home/clement/.cache/yay/git-delta-git/src/delta/target/release/deps/libonig-45f5d891c751d818.rlib(onig-45f5d891c751d818.onig.36b05d929265f9b6-cgu.3.rcgu.o): in function `onig::Regex::encoding':\r\n /home/clement/.cargo/registry/src/index.crates.io-6f17d22bba15001f/onig-6.4.0/src/lib.rs:824:(.text._ZN4onig5Regex8encoding17hb8a8845a051b0bd4E+0x5): undefined reference to `onig_get_encoding'\r\n /usr/bin/ld: /home/clement/.cache/yay/git-delta-git/src/delta/target/release/deps/libonig-45f5d891c751d818.rlib(onig-45f5d891c751d818.onig.36b05d929265f9b6-cgu.3.rcgu.o): in function `<onig::Regex as core::ops::drop::Drop>::drop':\r\n /home/clement/.cargo/registry/src/index.crates.io-6f17d22bba15001f/onig-6.4.0/src/lib.rs:841:(.text._ZN53_$LT$onig..Regex$u20$as$u20$core..ops..drop..Drop$GT$4drop17h6b0c38e08c6508caE+0x5): undefined reference to `onig_free'\r\n collect2: error: ld returned 1 exit status\r\n\r\n = note: some `extern` functions couldn't be found; some native libraries may need to be installed or have their path specified\r\n = note: use the `-l` flag to specify native libraries to link\r\n = note: use the `cargo:rustc-link-lib` directive to specify the native libraries to link with Cargo (see https://doc.rust-lang.org/cargo/reference/build-scripts.html#cargorustc-link-libkindname)\r\n\r\nerror: could not compile `git-delta` (bin \"delta\") due to 1 previous error\r\n==> ERROR: A failure occurred in build().\r\n Aborting...\r\n -> error making: git-delta-git-exit status 4\r\n -> Failed to install the following packages. Manual intervention is required:\r\ngit-delta-git - exit status 4\r\n```\r\n\r\nI'm not much knowledgeable of the matter, but I'm guessing issue would come from `onig` crate, coming from there:\r\n```\r\nonig v6.4.0\r\n└── syntect v5.1.0\r\n ├── bat v0.23.0\r\n │ └── git-delta v0.16.5 (/home/clement/.cache/yay/git-delta-git/src/delta)\r\n └── git-delta v0.16.5 (/home/clement/.cache/yay/git-delta-git/src/delta)\r\n```","comments":[{"id":"IC_kwDOC4j8g856V3g2","author":{"login":"Bennett-Petzold"},"authorAssociation":"NONE","body":"I've also had this issue. I believe the issue is the that the library built (onig, using onig-sys, using rust-bindgen) doesn't emit lto-valid code. It needs to be built with LLVM LTO format (since that's the rustc LTO output) by setting the C compiler to clang and manually specifying some linker configuration. It builds properly on my system when I do that.\r\n\r\nSo use `RUSTFLAGS=\"-C linker-plugin-lto -C linker=clang -C link-arg=-fuse-ld=lld\" CC=clang cargo ...`. For the Arch Linux PKGBUILD, put this ahead of the build and test cargo invocations.\r\n\r\nHere's a source for the rustflags combo: https://github.com/rust-lang/rust-bindgen/discussions/2405","createdAt":"2024-04-12T21:26:21Z","includesCreatedEdit":true,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/1651#issuecomment-2052552758","viewerDidAuthor":false},{"id":"IC_kwDOC4j8g86PiXE0","author":{"login":"Porkepix"},"authorAssociation":"NONE","body":"> I've also had this issue. I believe the issue is the that the library built (onig, using onig-sys, using rust-bindgen) doesn't emit lto-valid code. It needs to be built with LLVM LTO format (since that's the rustc LTO output) by setting the C compiler to clang and manually specifying some linker configuration. It builds properly on my system when I do that.\r\n> \r\n> So use `RUSTFLAGS=\"-C linker-plugin-lto -C linker=clang -C link-arg=-fuse-ld=lld\" CC=clang cargo ...`. For the Arch Linux PKGBUILD, put this ahead of the build and test cargo invocations.\r\n> \r\n> Here's a source for the rustflags combo: [rust-lang/rust-bindgen#2405](https://github.com/rust-lang/rust-bindgen/discussions/2405)\r\n\r\nI completely missed your answer.\r\nWhen trying to add those flags, it fails very early this way:\r\n\r\n```\r\nerror: linking with `clang` failed: exit status: 1\r\n |\r\n = note: LC_ALL=\"C\" PATH=\"/usr/lib64/rustlib/x86_64-unknown-linux-gnu/bin:/usr/lib64/rustlib/x86_64-unknown-linux-gnu/bin:/usr/lib64/rustlib/x86_64-unknown-linux-gnu/bin:/usr/local/bin:/usr/bin:/usr/local/sbin:/var/lib/flatpak/exports/bin:/usr/bin/site_perl:/usr/bin/vendor_perl:/usr/bin/core_perl\" VSLANG=\"1033\" \"clang\" \"-m64\" \"/tmp/rustcvdD3Kt/symbols.o\" \"/home/clement/.cache/paru/clone/git-delta-git/src/delta/target/release/build/proc-macro2-353085366260a5a9/build_script_build-353085366260a5a9.build_script_build.20739e304462bbaa-cgu.0.rcgu.o\" \"/home/clement/.cache/paru/clone/git-delta-git/src/delta/target/release/build/proc-macro2-353085366260a5a9/build_script_build-353085366260a5a9.59yy69sqm7ub6lw0krlky02rx.rcgu.o\" \"-Wl,--as-needed\" \"-L\" \"/home/clement/.cache/paru/clone/git-delta-git/src/delta/target/release/deps\" \"-L\" \"/usr/lib64/rustlib/x86_64-unknown-linux-gnu/lib\" \"-Wl,-Bstatic\" \"/usr/lib64/rustlib/x86_64-unknown-linux-gnu/lib/libstd-975ad26df43f3092.rlib\" \"/usr/lib64/rustlib/x86_64-unknown-linux-gnu/lib/libpanic_unwind-854d359d815154a1.rlib\" \"/usr/lib64/rustlib/x86_64-unknown-linux-gnu/lib/libobject-1adba7de6291c957.rlib\" \"/usr/lib64/rustlib/x86_64-unknown-linux-gnu/lib/libmemchr-2f003cc5096f2a41.rlib\" \"/usr/lib64/rustlib/x86_64-unknown-linux-gnu/lib/libaddr2line-1940fdd05db36b65.rlib\" \"/usr/lib64/rustlib/x86_64-unknown-linux-gnu/lib/libgimli-6affaed698e37946.rlib\" \"/usr/lib64/rustlib/x86_64-unknown-linux-gnu/lib/librustc_demangle-59090bd5092c735e.rlib\" \"/usr/lib64/rustlib/x86_64-unknown-linux-gnu/lib/libstd_detect-95e6adcbe5e3e3b6.rlib\" \"/usr/lib64/rustlib/x86_64-unknown-linux-gnu/lib/libhashbrown-0b7c2ec24db7ead0.rlib\" \"/usr/lib64/rustlib/x86_64-unknown-linux-gnu/lib/librustc_std_workspace_alloc-f07917aaf98e9537.rlib\" \"/usr/lib64/rustlib/x86_64-unknown-linux-gnu/lib/libminiz_oxide-3d4fee16d8573795.rlib\" \"/usr/lib64/rustlib/x86_64-unknown-linux-gnu/lib/libadler-31d2edee42aa9f31.rlib\" \"/usr/lib64/rustlib/x86_64-unknown-linux-gnu/lib/libunwind-09f6820ab6e8fa52.rlib\" \"/usr/lib64/rustlib/x86_64-unknown-linux-gnu/lib/libcfg_if-67b9ce86c9dd6f1e.rlib\" \"/usr/lib64/rustlib/x86_64-unknown-linux-gnu/lib/liblibc-e318bc901c18d569.rlib\" \"/usr/lib64/rustlib/x86_64-unknown-linux-gnu/lib/liballoc-fa5228cf59161233.rlib\" \"/usr/lib64/rustlib/x86_64-unknown-linux-gnu/lib/librustc_std_workspace_core-2356df8ff6149061.rlib\" \"/usr/lib64/rustlib/x86_64-unknown-linux-gnu/lib/libcore-972c7c6eb3eb878d.rlib\" \"/usr/lib64/rustlib/x86_64-unknown-linux-gnu/lib/libcompiler_builtins-288663704b9edb44.rlib\" \"-Wl,-Bdynamic\" \"-lgcc_s\" \"-lutil\" \"-lrt\" \"-lpthread\" \"-lm\" \"-ldl\" \"-lc\" \"-Wl,--eh-frame-hdr\" \"-Wl,-z,noexecstack\" \"-Wl,-plugin-opt=O0,-plugin-opt=mcpu=x86-64\" \"-L\" \"/usr/lib64/rustlib/x86_64-unknown-linux-gnu/lib\" \"-o\" \"/home/clement/.cache/paru/clone/git-delta-git/src/delta/target/release/build/proc-macro2-353085366260a5a9/build_script_build-353085366260a5a9\" \"-Wl,--gc-sections\" \"-pie\" \"-Wl,-z,relro,-z,now\" \"-Wl,--strip-debug\" \"-nodefaultlibs\" \"-fuse-ld=lld\"\r\n = note: clang: error: invalid linker name in argument '-fuse-ld=lld'\r\n\r\n\r\nerror: could not compile `proc-macro2` (build script) due to 1 previous error\r\nwarning: build failed, waiting for other jobs to finish...\r\nerror: linking with `clang` failed: exit status: 1\r\n |\r\n = note: LC_ALL=\"C\" PATH=\"/usr/lib64/rustlib/x86_64-unknown-linux-gnu/bin:/usr/lib64/rustlib/x86_64-unknown-linux-gnu/bin:/usr/lib64/rustlib/x86_64-unknown-linux-gnu/bin:/usr/local/bin:/usr/bin:/usr/local/sbin:/var/lib/flatpak/exports/bin:/usr/bin/site_perl:/usr/bin/vendor_perl:/usr/bin/core_perl\" VSLANG=\"1033\" \"clang\" \"-m64\" \"/tmp/rustcmKu0HE/symbols.o\" \"/home/clement/.cache/paru/clone/git-delta-git/src/delta/target/release/build/serde-10c90918a54ac077/build_script_build-10c90918a54ac077.build_script_build.81d712daa15f93e4-cgu.0.rcgu.o\" \"/home/clement/.cache/paru/clone/git-delta-git/src/delta/target/release/build/serde-10c90918a54ac077/build_script_build-10c90918a54ac077.6m4k9ml42to73yzex2rhffbjk.rcgu.o\" \"-Wl,--as-needed\" \"-L\" \"/home/clement/.cache/paru/clone/git-delta-git/src/delta/target/release/deps\" \"-L\" \"/usr/lib64/rustlib/x86_64-unknown-linux-gnu/lib\" \"-Wl,-Bstatic\" \"/usr/lib64/rustlib/x86_64-unknown-linux-gnu/lib/libstd-975ad26df43f3092.rlib\" \"/usr/lib64/rustlib/x86_64-unknown-linux-gnu/lib/libpanic_unwind-854d359d815154a1.rlib\" \"/usr/lib64/rustlib/x86_64-unknown-linux-gnu/lib/libobject-1adba7de6291c957.rlib\" \"/usr/lib64/rustlib/x86_64-unknown-linux-gnu/lib/libmemchr-2f003cc5096f2a41.rlib\" \"/usr/lib64/rustlib/x86_64-unknown-linux-gnu/lib/libaddr2line-1940fdd05db36b65.rlib\" \"/usr/lib64/rustlib/x86_64-unknown-linux-gnu/lib/libgimli-6affaed698e37946.rlib\" \"/usr/lib64/rustlib/x86_64-unknown-linux-gnu/lib/librustc_demangle-59090bd5092c735e.rlib\" \"/usr/lib64/rustlib/x86_64-unknown-linux-gnu/lib/libstd_detect-95e6adcbe5e3e3b6.rlib\" \"/usr/lib64/rustlib/x86_64-unknown-linux-gnu/lib/libhashbrown-0b7c2ec24db7ead0.rlib\" \"/usr/lib64/rustlib/x86_64-unknown-linux-gnu/lib/librustc_std_workspace_alloc-f07917aaf98e9537.rlib\" \"/usr/lib64/rustlib/x86_64-unknown-linux-gnu/lib/libminiz_oxide-3d4fee16d8573795.rlib\" \"/usr/lib64/rustlib/x86_64-unknown-linux-gnu/lib/libadler-31d2edee42aa9f31.rlib\" \"/usr/lib64/rustlib/x86_64-unknown-linux-gnu/lib/libunwind-09f6820ab6e8fa52.rlib\" \"/usr/lib64/rustlib/x86_64-unknown-linux-gnu/lib/libcfg_if-67b9ce86c9dd6f1e.rlib\" \"/usr/lib64/rustlib/x86_64-unknown-linux-gnu/lib/liblibc-e318bc901c18d569.rlib\" \"/usr/lib64/rustlib/x86_64-unknown-linux-gnu/lib/liballoc-fa5228cf59161233.rlib\" \"/usr/lib64/rustlib/x86_64-unknown-linux-gnu/lib/librustc_std_workspace_core-2356df8ff6149061.rlib\" \"/usr/lib64/rustlib/x86_64-unknown-linux-gnu/lib/libcore-972c7c6eb3eb878d.rlib\" \"/usr/lib64/rustlib/x86_64-unknown-linux-gnu/lib/libcompiler_builtins-288663704b9edb44.rlib\" \"-Wl,-Bdynamic\" \"-lgcc_s\" \"-lutil\" \"-lrt\" \"-lpthread\" \"-lm\" \"-ldl\" \"-lc\" \"-Wl,--eh-frame-hdr\" \"-Wl,-z,noexecstack\" \"-Wl,-plugin-opt=O0,-plugin-opt=mcpu=x86-64\" \"-L\" \"/usr/lib64/rustlib/x86_64-unknown-linux-gnu/lib\" \"-o\" \"/home/clement/.cache/paru/clone/git-delta-git/src/delta/target/release/build/serde-10c90918a54ac077/build_script_build-10c90918a54ac077\" \"-Wl,--gc-sections\" \"-pie\" \"-Wl,-z,relro,-z,now\" \"-Wl,--strip-debug\" \"-nodefaultlibs\" \"-fuse-ld=lld\"\r\n = note: clang: error: invalid linker name in argument '-fuse-ld=lld'\r\n\r\n\r\nerror: could not compile `serde` (build script) due to 1 previous error\r\nerror: linking with `clang` failed: exit status: 1\r\n |\r\n = note: LC_ALL=\"C\" PATH=\"/usr/lib64/rustlib/x86_64-unknown-linux-gnu/bin:/usr/lib64/rustlib/x86_64-unknown-linux-gnu/bin:/usr/lib64/rustlib/x86_64-unknown-linux-gnu/bin:/usr/local/bin:/usr/bin:/usr/local/sbin:/var/lib/flatpak/exports/bin:/usr/bin/site_perl:/usr/bin/vendor_perl:/usr/bin/core_perl\" VSLANG=\"1033\" \"clang\" \"-m64\" \"/tmp/rustck7RjTm/symbols.o\" \"/home/clement/.cache/paru/clone/git-delta-git/src/delta/target/release/build/libc-a25c1b35ac330fab/build_script_build-a25c1b35ac330fab.build_script_build.aa3d912dfb08114a-cgu.0.rcgu.o\" \"/home/clement/.cache/paru/clone/git-delta-git/src/delta/target/release/build/libc-a25c1b35ac330fab/build_script_build-a25c1b35ac330fab.build_script_build.aa3d912dfb08114a-cgu.1.rcgu.o\" \"/home/clement/.cache/paru/clone/git-delta-git/src/delta/target/release/build/libc-a25c1b35ac330fab/build_script_build-a25c1b35ac330fab.build_script_build.aa3d912dfb08114a-cgu.2.rcgu.o\" \"/home/clement/.cache/paru/clone/git-delta-git/src/delta/target/release/build/libc-a25c1b35ac330fab/build_script_build-a25c1b35ac330fab.build_script_build.aa3d912dfb08114a-cgu.3.rcgu.o\" \"/home/clement/.cache/paru/clone/git-delta-git/src/delta/target/release/build/libc-a25c1b35ac330fab/build_script_build-a25c1b35ac330fab.ckdk0zbfvj87egtlv8eg7ivz0.rcgu.o\" \"-Wl,--as-needed\" \"-L\" \"/home/clement/.cache/paru/clone/git-delta-git/src/delta/target/release/deps\" \"-L\" \"/usr/lib64/rustlib/x86_64-unknown-linux-gnu/lib\" \"-Wl,-Bstatic\" \"/usr/lib64/rustlib/x86_64-unknown-linux-gnu/lib/libstd-975ad26df43f3092.rlib\" \"/usr/lib64/rustlib/x86_64-unknown-linux-gnu/lib/libpanic_unwind-854d359d815154a1.rlib\" \"/usr/lib64/rustlib/x86_64-unknown-linux-gnu/lib/libobject-1adba7de6291c957.rlib\" \"/usr/lib64/rustlib/x86_64-unknown-linux-gnu/lib/libmemchr-2f003cc5096f2a41.rlib\" \"/usr/lib64/rustlib/x86_64-unknown-linux-gnu/lib/libaddr2line-1940fdd05db36b65.rlib\" \"/usr/lib64/rustlib/x86_64-unknown-linux-gnu/lib/libgimli-6affaed698e37946.rlib\" \"/usr/lib64/rustlib/x86_64-unknown-linux-gnu/lib/librustc_demangle-59090bd5092c735e.rlib\" \"/usr/lib64/rustlib/x86_64-unknown-linux-gnu/lib/libstd_detect-95e6adcbe5e3e3b6.rlib\" \"/usr/lib64/rustlib/x86_64-unknown-linux-gnu/lib/libhashbrown-0b7c2ec24db7ead0.rlib\" \"/usr/lib64/rustlib/x86_64-unknown-linux-gnu/lib/librustc_std_workspace_alloc-f07917aaf98e9537.rlib\" \"/usr/lib64/rustlib/x86_64-unknown-linux-gnu/lib/libminiz_oxide-3d4fee16d8573795.rlib\" \"/usr/lib64/rustlib/x86_64-unknown-linux-gnu/lib/libadler-31d2edee42aa9f31.rlib\" \"/usr/lib64/rustlib/x86_64-unknown-linux-gnu/lib/libunwind-09f6820ab6e8fa52.rlib\" \"/usr/lib64/rustlib/x86_64-unknown-linux-gnu/lib/libcfg_if-67b9ce86c9dd6f1e.rlib\" \"/usr/lib64/rustlib/x86_64-unknown-linux-gnu/lib/liblibc-e318bc901c18d569.rlib\" \"/usr/lib64/rustlib/x86_64-unknown-linux-gnu/lib/liballoc-fa5228cf59161233.rlib\" \"/usr/lib64/rustlib/x86_64-unknown-linux-gnu/lib/librustc_std_workspace_core-2356df8ff6149061.rlib\" \"/usr/lib64/rustlib/x86_64-unknown-linux-gnu/lib/libcore-972c7c6eb3eb878d.rlib\" \"/usr/lib64/rustlib/x86_64-unknown-linux-gnu/lib/libcompiler_builtins-288663704b9edb44.rlib\" \"-Wl,-Bdynamic\" \"-lgcc_s\" \"-lutil\" \"-lrt\" \"-lpthread\" \"-lm\" \"-ldl\" \"-lc\" \"-Wl,--eh-frame-hdr\" \"-Wl,-z,noexecstack\" \"-Wl,-plugin-opt=O0,-plugin-opt=mcpu=x86-64\" \"-L\" \"/usr/lib64/rustlib/x86_64-unknown-linux-gnu/lib\" \"-o\" \"/home/clement/.cache/paru/clone/git-delta-git/src/delta/target/release/build/libc-a25c1b35ac330fab/build_script_build-a25c1b35ac330fab\" \"-Wl,--gc-sections\" \"-pie\" \"-Wl,-z,relro,-z,now\" \"-Wl,--strip-debug\" \"-nodefaultlibs\" \"-fuse-ld=lld\"\r\n = note: clang: error: invalid linker name in argument '-fuse-ld=lld'\r\n\r\n\r\nerror: could not compile `libc` (build script) due to 1 previous error\r\nerror: linking with `clang` failed: exit status: 1\r\n |\r\n = note: LC_ALL=\"C\" PATH=\"/usr/lib64/rustlib/x86_64-unknown-linux-gnu/bin:/usr/lib64/rustlib/x86_64-unknown-linux-gnu/bin:/usr/lib64/rustlib/x86_64-unknown-linux-gnu/bin:/usr/local/bin:/usr/bin:/usr/local/sbin:/var/lib/flatpak/exports/bin:/usr/bin/site_perl:/usr/bin/vendor_perl:/usr/bin/core_perl\" VSLANG=\"1033\" \"clang\" \"-m64\" \"/tmp/rustcTb9UQ1/symbols.o\" \"/home/clement/.cache/paru/clone/git-delta-git/src/delta/target/release/build/rustix-f8f184104ab5ca79/build_script_build-f8f184104ab5ca79.build_script_build.c637cab1cc22d5ff-cgu.0.rcgu.o\" \"/home/clement/.cache/paru/clone/git-delta-git/src/delta/target/release/build/rustix-f8f184104ab5ca79/build_script_build-f8f184104ab5ca79.build_script_build.c637cab1cc22d5ff-cgu.1.rcgu.o\" \"/home/clement/.cache/paru/clone/git-delta-git/src/delta/target/release/build/rustix-f8f184104ab5ca79/build_script_build-f8f184104ab5ca79.build_script_build.c637cab1cc22d5ff-cgu.2.rcgu.o\" \"/home/clement/.cache/paru/clone/git-delta-git/src/delta/target/release/build/rustix-f8f184104ab5ca79/build_script_build-f8f184104ab5ca79.20wbd5g9rn3hs4hfpplnxanu5.rcgu.o\" \"-Wl,--as-needed\" \"-L\" \"/home/clement/.cache/paru/clone/git-delta-git/src/delta/target/release/deps\" \"-L\" \"/usr/lib64/rustlib/x86_64-unknown-linux-gnu/lib\" \"-Wl,-Bstatic\" \"/usr/lib64/rustlib/x86_64-unknown-linux-gnu/lib/libstd-975ad26df43f3092.rlib\" \"/usr/lib64/rustlib/x86_64-unknown-linux-gnu/lib/libpanic_unwind-854d359d815154a1.rlib\" \"/usr/lib64/rustlib/x86_64-unknown-linux-gnu/lib/libobject-1adba7de6291c957.rlib\" \"/usr/lib64/rustlib/x86_64-unknown-linux-gnu/lib/libmemchr-2f003cc5096f2a41.rlib\" \"/usr/lib64/rustlib/x86_64-unknown-linux-gnu/lib/libaddr2line-1940fdd05db36b65.rlib\" \"/usr/lib64/rustlib/x86_64-unknown-linux-gnu/lib/libgimli-6affaed698e37946.rlib\" \"/usr/lib64/rustlib/x86_64-unknown-linux-gnu/lib/librustc_demangle-59090bd5092c735e.rlib\" \"/usr/lib64/rustlib/x86_64-unknown-linux-gnu/lib/libstd_detect-95e6adcbe5e3e3b6.rlib\" \"/usr/lib64/rustlib/x86_64-unknown-linux-gnu/lib/libhashbrown-0b7c2ec24db7ead0.rlib\" \"/usr/lib64/rustlib/x86_64-unknown-linux-gnu/lib/librustc_std_workspace_alloc-f07917aaf98e9537.rlib\" \"/usr/lib64/rustlib/x86_64-unknown-linux-gnu/lib/libminiz_oxide-3d4fee16d8573795.rlib\" \"/usr/lib64/rustlib/x86_64-unknown-linux-gnu/lib/libadler-31d2edee42aa9f31.rlib\" \"/usr/lib64/rustlib/x86_64-unknown-linux-gnu/lib/libunwind-09f6820ab6e8fa52.rlib\" \"/usr/lib64/rustlib/x86_64-unknown-linux-gnu/lib/libcfg_if-67b9ce86c9dd6f1e.rlib\" \"/usr/lib64/rustlib/x86_64-unknown-linux-gnu/lib/liblibc-e318bc901c18d569.rlib\" \"/usr/lib64/rustlib/x86_64-unknown-linux-gnu/lib/liballoc-fa5228cf59161233.rlib\" \"/usr/lib64/rustlib/x86_64-unknown-linux-gnu/lib/librustc_std_workspace_core-2356df8ff6149061.rlib\" \"/usr/lib64/rustlib/x86_64-unknown-linux-gnu/lib/libcore-972c7c6eb3eb878d.rlib\" \"/usr/lib64/rustlib/x86_64-unknown-linux-gnu/lib/libcompiler_builtins-288663704b9edb44.rlib\" \"-Wl,-Bdynamic\" \"-lgcc_s\" \"-lutil\" \"-lrt\" \"-lpthread\" \"-lm\" \"-ldl\" \"-lc\" \"-Wl,--eh-frame-hdr\" \"-Wl,-z,noexecstack\" \"-Wl,-plugin-opt=O0,-plugin-opt=mcpu=x86-64\" \"-L\" \"/usr/lib64/rustlib/x86_64-unknown-linux-gnu/lib\" \"-o\" \"/home/clement/.cache/paru/clone/git-delta-git/src/delta/target/release/build/rustix-f8f184104ab5ca79/build_script_build-f8f184104ab5ca79\" \"-Wl,--gc-sections\" \"-pie\" \"-Wl,-z,relro,-z,now\" \"-Wl,--strip-debug\" \"-nodefaultlibs\" \"-fuse-ld=lld\"\r\n = note: clang: error: invalid linker name in argument '-fuse-ld=lld'\r\n\r\n\r\nerror: could not compile `rustix` (build script) due to 1 previous error\r\n==> ERROR: A failure occurred in build().\r\n Aborting...\r\nerror: failed to build 'git-delta-git-r.319.f89300a-1':\r\nerror: packages failed to build: git-delta-git-r.319.f89300a-1\r\n```\r\nBut I don't know why it would fail in my case, if it works for yours?\r\n\r\nOn the other hand, taken from non-AUR `-git` release, I tried adding `CFLAGS+=' -ffat-lto-objects'` (https://gitlab.archlinux.org/archlinux/packaging/packages/git-delta/-/blob/main/PKGBUILD?ref_type=heads#L38) and in that case it builds, but I can't explain why would this be needed.\r\n\r\nThere are quite some differences between the two build files and I don't find build docs around, so in case you would know if/why is https://gitlab.archlinux.org/archlinux/packaging/packages/git-delta/-/blob/main/PKGBUILD?ref_type=heads#L40 needed and the recommendations between cargo locked and frozen (see https://gitlab.archlinux.org/archlinux/packaging/packages/git-delta/-/blob/main/PKGBUILD?ref_type=heads#L43).","createdAt":"2024-10-11T21:34:53Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/1651#issuecomment-2408149300","viewerDidAuthor":false}],"number":1651,"title":"🐛 delta fails to build with enabled `lto`"},{"body":"With the following configuration in git config:\r\n\r\n```\r\n[interactive]\r\n diffFilter = delta --color-only\r\n[alias]\r\n ap = \"!git add -p\"\r\n```\r\n\r\nThe keyboard input does not work at all when `git ap` asks:\r\n\r\n```\r\n(1/1) Stage this hunk [y,n,q,a,d,e,?]?\r\n```\r\n\r\nEven `Ctrl + C` does nothing, the only way to stop is with `Ctrl + Z`.\r\n\r\nThis happens when using `git-cmd` but not when using `git-bash`.\r\n\r\nThe keyboard works normally with either of the changes below:\r\n\r\n```\r\n[interactive]\r\n diffFilter = diff-so-fancy --patch\r\n```\r\n\r\n```\r\n[interactive]\r\n diffFilter = delta --color-only | cat\r\n```\r\n\r\n```\r\n[alias]\r\n ap = add -p\r\n```\r\n\r\nThis seems like some race condition. Not sure if the problem is specific to delta, but then `diff-so-fancy` works fine.\r\n\r\nIs there something else I could try to debug this?\r\n","comments":[{"id":"IC_kwDOC4j8g853jWoc","author":{"login":"hintron"},"authorAssociation":"NONE","body":"Same here, when I start Git Bash under Windows Terminal 1.19.10573.0. I have Delta 0.16.5 (also happens with 0.17.0) and Git Bash 2.40.1.1. However, when I run `git-cmd` or `git-bash` directly, and not under Windows Terminal, I don't hit the issue. ","createdAt":"2024-03-19T04:49:59Z","includesCreatedEdit":true,"isMinimized":false,"minimizedReason":"","reactionGroups":[{"content":"THUMBS_UP","users":{"totalCount":1}}],"url":"https://github.com/dandavison/delta/issues/1650#issuecomment-2005756444","viewerDidAuthor":false},{"id":"IC_kwDOC4j8g853jcsp","author":{"login":"hintron"},"authorAssociation":"NONE","body":"When I upgraded to Git 2.44.0.1, it mostly behaves the same, except if I hold ctrl and hit enter, I can get it to re-display the prompt, and sometimes a ctrl-C goes through. Also, the line number vertical bars are replaced with `Γï«` and `Γöé` (but they show up normal as `:` and `|` when I do `git diff` standalone).\r\n\r\nBTW my .gitconfig contains\r\n\r\n```\r\n[core]\r\n pager = delta\r\n\r\n[interactive]\r\n diffFilter = delta --color-only\r\n\r\n[delta]\r\n features = mgh_decorations\r\n line-numbers = true\r\n whitespace-error-style = 22 reverse\r\n\r\n[delta \"mgh_decorations\"]\r\n commit-decoration-style = bold green box\r\n file-style = bold yellow\r\n file-decoration-style = bold yellow ul\r\n hunk-header-decoration-style = purple box\r\n```","createdAt":"2024-03-19T05:15:55Z","includesCreatedEdit":true,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/1650#issuecomment-2005781289","viewerDidAuthor":false},{"id":"IC_kwDOC4j8g854T5HW","author":{"login":"Bouska"},"authorAssociation":"NONE","body":"I have also the same issue (except `⋮` is replaced by `Ôï«` and `│` by `Ôöé`) using delta 0.17.0 (copied from MSYS2/MINGW64), Windows Terminal 1.19.10573.0 and git 2.44.0.windows.1 (Git Bash). But using the same configuration with git version 2.44.0 (from MSYS2/MINGW64) works as expected. So I guess the git exe from Git Bash doesn't like the delta exe (copied from MSYS2/MINGW64) when executed under Windows Terminal (really a weird race condition)","createdAt":"2024-03-25T17:01:51Z","includesCreatedEdit":true,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/1650#issuecomment-2018480598","viewerDidAuthor":false},{"id":"IC_kwDOC4j8g854UrNG","author":{"login":"Bouska"},"authorAssociation":"NONE","body":"After some investigation, I'm not so sure this is a bug in `delta`. Under the hood, `git` calls an equivalent to ` git diff-files --color --ignore-submodules=dirty -p -- | delta --color-only` and this command works perfectly fine.","createdAt":"2024-03-25T18:53:27Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/1650#issuecomment-2018685766","viewerDidAuthor":false},{"id":"IC_kwDOC4j8g854VHvJ","author":{"login":"imbrish"},"authorAssociation":"CONTRIBUTOR","body":"I am not sure your problem is the same as mine, it seems like some encoding issue. Have you tried running `chcp 65001` (or `chcp.com 65001`) prior to the command you have trouble with?\r\n\r\nI have this in my `.bashrc` and have not seen any such problems, also with the same git version you reference.","createdAt":"2024-03-25T19:57:51Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/1650#issuecomment-2018802633","viewerDidAuthor":false},{"id":"IC_kwDOC4j8g854ZQB1","author":{"login":"Bouska"},"authorAssociation":"NONE","body":"I still think we have the same problem, the main issue I have is that `(1/1) Stage this hunk [y,n,q,a,d,e,?]?` doesn't accept any input, `ctrl-c` doesn't work either, only `ctrl-z` works (and the next hunk is shown before I get the prompt back). The encoding issue seems to be only a side effect.","createdAt":"2024-03-26T09:08:57Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[{"content":"THUMBS_UP","users":{"totalCount":1}}],"url":"https://github.com/dandavison/delta/issues/1650#issuecomment-2019885173","viewerDidAuthor":false},{"id":"IC_kwDOC4j8g854ZRda","author":{"login":"Bouska"},"authorAssociation":"NONE","body":"@imbrish `chcp.com 65001` fixes my encoding issue 👍 but still have the main issue","createdAt":"2024-03-26T09:11:52Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/1650#issuecomment-2019891034","viewerDidAuthor":false},{"id":"IC_kwDOC4j8g854bKT8","author":{"login":"imbrish"},"authorAssociation":"CONTRIBUTOR","body":"Glad it helped 👍\r\n\r\nI think the broken keyboard input is mostly a problem with Git for Windows and how it interacts with Command Prompt or Terminal. Actually, it seems it is not the input that is broken, but the output, because I am still able to go through the `git add --patch` in blind, and the changes do get staged. This is made even more apparent when using `ctrl + enter`.\r\n\r\nI have also experienced similar issues before I started to use Delta. For example, using a shell command (with `!`) for `textconv` would break mouse scrolling in diffs paged with `less`. I am not entirely sure what happens there, but it seems to have something to do with registering of mouse and keyboard hooks.\r\n\r\nAnyway, I have also tried the following in git config:\r\n\r\n```\r\n[interactive]\r\n diffFilter = delta --color-only --paging=never\r\n```\r\n\r\nBut it does not change anything, the problem is exactly the same as originally described. Only piping through `cat` helps. I have no clue why that is.\r\n\r\n@dandavison possibly you could point us where to look? What exactly does delta do differently when its output is piped and when it is not? I would imagine `delta --color-only --paging=never` should be equivalent to `delta --color-only | cat`, but apparently it is not. May it be that git detects pipe in the `diffFilter`, and then runs it differently?","createdAt":"2024-03-26T13:07:34Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[{"content":"THUMBS_UP","users":{"totalCount":2}}],"url":"https://github.com/dandavison/delta/issues/1650#issuecomment-2020386044","viewerDidAuthor":false},{"id":"IC_kwDOC4j8g854bgZk","author":{"login":"Bouska"},"authorAssociation":"NONE","body":"Here is the Git code that interest us: [add-patch.c#L403](https://github.com/git/git/blob/c75fd8d8150afdf836b63a8e0534d9b9e3e111ba/add-patch.c#L403)\r\nSo basically what git does in our case is:\r\n- run `git diff-files --no-color --ignore-submodules=dirty -p --` and store the result in a buffer `plain`\r\n- run `git diff-files --color --ignore-submodules=dirty -p --` and store the result in a buffer `colored`\r\n- pipe the content of the buffer `colored` to the command of `interactive.diffFilter` and store the result in `colored`\r\n- parse the content of `plain` to split the diff into hunks and find the offset of each line in `colored`\r\n\r\nAs I said before, `git diff-files --color --ignore-submodules=dirty -p -- | delta --color-only` works fine, so I'm guessing its finding the equivalent hunks in the `colored` buffer that triggers the issue.","createdAt":"2024-03-26T13:46:48Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/1650#issuecomment-2020476516","viewerDidAuthor":false},{"id":"IC_kwDOC4j8g854b8Wf","author":{"login":"imbrish"},"authorAssociation":"CONTRIBUTOR","body":"Investigating at the source 😉\r\n\r\nIf the problem lies in matching the `plain` and `colored` hunks, then why would `... | cat` fix it? The output stays the same.\r\n\r\nI wonder if this works only in Command Prompt. Have you tried `diffFilter = delta --color-only | cat` in Windows Terminal?","createdAt":"2024-03-26T14:30:36Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/1650#issuecomment-2020591007","viewerDidAuthor":false},{"id":"IC_kwDOC4j8g854chLN","author":{"login":"Bouska"},"authorAssociation":"NONE","body":"I tried `diffFilter = delta --color-only | cat` yesterday and it would still freeze, but I tried today and it works (but not exactly in the same conditions) 🤷 ","createdAt":"2024-03-26T15:26:22Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/1650#issuecomment-2020741837","viewerDidAuthor":false},{"id":"IC_kwDOC4j8g856LRcc","author":{"login":"adriencarbonaro"},"authorAssociation":"NONE","body":"Hello,\r\nI also have the same issue. I think it is a git for windows or windows terminal issue, as git bash works as intended. I also tested with same version of delta on another (older windows) computer and it works. The only change is the version of windows itself (10 vs 11) and git for windows (2.30 vs 2.44)","createdAt":"2024-04-11T14:06:29Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/1650#issuecomment-2049775388","viewerDidAuthor":false},{"id":"IC_kwDOC4j8g85-5CVw","author":{"login":"stefan-muc"},"authorAssociation":"NONE","body":"I have a somehow related issue: I experience the freeze on `git add -p` with VSCode/VSCodium Git bash (MINGW64) terminal, but not in native Git CMD/Bash started through start menu / context menu in explorer.\r\nCan confirm _imbrish_ discovery that if I continue \"blind\" the changes get indeed added.\r\n\r\nVersions: VSCode/VSCodium 1.89.1 (system setup)\r\nGit: git version 2.45.1.windows.1\r\nWindows: Win 10 22H2 Build 19045.4412 (VSCode and VSCodium), Win 11 23H2 Build 22631.3593 (only VSCode tested)\r\n.gitconfig: Default example as in [Get Started](https://github.com/dandavison/delta?tab=readme-ov-file#get-started) - without `delta` there's no freeze.","createdAt":"2024-05-24T08:16:13Z","includesCreatedEdit":true,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/1650#issuecomment-2128881008","viewerDidAuthor":false}],"number":1650,"title":"🐛 Delta as `diffFilter` breaks keyboard input with `git add -p` in Git CMD"},{"body":"Hi,\r\n\r\nI've just been trying delta today. I got it all configured how I like it, copied the config to a remote system, and the colours all look different for some reason.\r\n\r\n\r\n\r\n\r\nThe screenshot shows the output of `diff -u 1 2 | delta --color-only` on an OpenBSD system (where it looks correct) and on a remote Debian system over ssh. The screenshots are inside tmux, but the output is still incorrect on Debian outside of tmux.\r\n\r\nAny idea why?\r\n\r\nMy delta config:\r\n```\r\n[core]\r\n pager = \"delta --color-only\"\r\n\r\n[delta]\r\n light = false\r\n theme = gruvbox-dark\r\n keep-plus-minus-markers = true\r\n file-style = \"magenta normal\"\r\n zero-style = \"normal normal\"\r\n plus-style = \"green #26342c\"\r\n plus-emph-style = \"green #2b4134\"\r\n minus-style = \"red #342626\"\r\n minus-emph-style = \"#d95a5a #562222\"\r\n true-color = always\r\n```","comments":[{"id":"IC_kwDOC4j8g852FR9c","author":{"login":"dandavison"},"authorAssociation":"OWNER","body":"Hm, so this is the same terminal emulator and what differs is the delta executable and the fact that delta's output is coming over SSH, is that right?\r\n\r\nI am not sure what the problem is, but my first impression is that it looks like 24bit color (\"truecolor\") is not being supported correctly in the panel on the right. Have you tried comparing the raw output by piping into `cat -A` or `bat -A` or a hexdump etc? Perhaps you can hone in on the problem by creating a file containing ANSI escaped text such that `cat`ing it to the terminal in the two contexts reproduces the difference?","createdAt":"2024-03-06T15:12:29Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/1648#issuecomment-1981095772","viewerDidAuthor":true}],"number":1648,"title":"🐛 Colours different on different systems."},{"body":"### Discussed in https://github.com/dandavison/delta/discussions/1620\r\n\r\n<div type='discussions-op-text'>\r\n\r\n<sup>Originally posted by **calestyo** February 8, 2024</sup>\r\nHey.\r\n\r\nI found no way to to disable the \"surrounding\" unmodified lines. `omit` doesn’t seem to work with `--zero-style` and there doesn’t seem to be a counterpart to `diff`’s `-U0`.\r\n\r\nIs this somehow possible?\r\n\r\nThanks,\r\nChris.</div>","comments":[{"id":"IC_kwDOC4j8g851jvzJ","author":{"login":"dandavison"},"authorAssociation":"OWNER","body":"Hi Chris, ok I'm sorry to say something that sounds silly, but isn't the answer `-U0`?? As in `git show -U0`? Or is the issue that you want this when doing `delta file_1 file_2`?","createdAt":"2024-03-01T01:49:21Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/1644#issuecomment-1972305097","viewerDidAuthor":true},{"id":"IC_kwDOC4j8g851jy0Z","author":{"login":"calestyo"},"authorAssociation":"NONE","body":"Hey Dan.\r\n\r\nOh yes, I was thinking about the `delta file_1 file_2` case.\r\n\r\nBut your answer made me realise that I could at least get the behaviour via `diff -U0 a b | delta`.<br>\r\nNevertheless, would be nicer if it would work straight from delta.","createdAt":"2024-03-01T02:02:08Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/1644#issuecomment-1972317465","viewerDidAuthor":false},{"id":"IC_kwDOC4j8g851j1AB","author":{"login":"dandavison"},"authorAssociation":"OWNER","body":"Right, my feeling has always been that it would be a mess to try to add the various diff options (actually git diff options) into delta's command-line parsing. `delta a b` is actually[1] a shorthand for `git diff --no-index a b` (a rather little-known command that allows `git diff` to be used on any arbitrary pair of files) and so my stock answer here is to say \"would you mind just using `git diff --no-index a b ... | delta` ?\" and admitting that perhaps I should never have implemented the `delta a b` shorthand! \r\n\r\n\r\n[1] of course, this may have started out true but is not quite true any longer... we implemented support for things like `delta <(echo a) <(echo b)` which is an improvement over\r\n```\r\n$ git diff --no-index <(echo a) <(echo b)\r\nerror: /dev/fd/11: unsupported file type\r\nfatal: cannot hash /dev/fd/11\r\n```","createdAt":"2024-03-01T02:10:55Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/1644#issuecomment-1972326401","viewerDidAuthor":true},{"id":"IC_kwDOC4j8g851j1c4","author":{"login":"dandavison"},"authorAssociation":"OWNER","body":"To justify \"a mess\" -- it's that delta at heart is really a tool that takes in diff / grep / blame input and outputs unparseable stuff to look at. And it has a pretty large collection of options for doing that! So one hesitates before adding options for _generating_ the diff output. ","createdAt":"2024-03-01T02:12:53Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/1644#issuecomment-1972328248","viewerDidAuthor":true},{"id":"IC_kwDOC4j8g851ruc7","author":{"login":"calestyo"},"authorAssociation":"NONE","body":"> Right, my feeling has always been that it would be a mess to try to add the various diff options (actually git diff options) into delta's command-line parsing.\r\n\r\nOne way would perhaps be to add a single option, that allows passing any options to the actually used `diff` backend, be it `git diff` (which probably then also uses `diff`) or as in my example above `diff` itself.<br>\r\nThat way you could allow people to give options, but don't have to handle each of them manually in your parsing.\r\n\r\n\r\n\r\n> `delta a b` is actually[1] a shorthand for `git diff --no-index a b`\r\n\r\nOut of curiosity: Also if `git` is not available? Or would it then use `diff`?\r\n\r\n\r\n> \"would you mind just using `git diff --no-index a b ... | delta` ?\"\r\n\r\nWell I would probably do so, if the above idea isn't an alternative for you either. ;-) It does however make life at least a tin bit more complicated in usage, as one needs (at least in scripting) to check `diff`’s exit status, which would be lost because of he pipe.<br>\r\nIf `delta` would handle things internally (and does proper error handling), that could be avoided.\r\n\r\n> and admitting that perhaps I should never have implemented the `delta a b` shorthand!\r\n\r\nI personally rather like the idea that `delta` is also standalone and not fully tied to `git`. Especially as it can also be used with `diff`/`grep`, as you said above.\r\n\r\nThanks,\r\nChris.","createdAt":"2024-03-02T06:26:07Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/1644#issuecomment-1974396731","viewerDidAuthor":false},{"id":"IC_kwDOC4j8g851toOb","author":{"login":"dandavison"},"authorAssociation":"OWNER","body":"> One way would perhaps be to add a single option, that allows passing any options to the actually used diff backend\r\n\r\nOK I think you're right, that seems to makes sense. Any interest in implementing? I have to admit I am low on spare programming time currently due to day job. (But trying to at least keep up with the nice PRs and issue suggestions that come in).\r\n\r\n> if git is not available? Or would it then use diff?\r\n\r\nActually no, not currently, but that would be an easy fix to make I think:\r\n\r\nhttps://github.com/dandavison/delta/blob/dcae5bcc2428d1fb6f5ff7b9cddd7f268d9a3735/src/subcommands/diff.rs#L26-L30\r\n\r\n\r\n","createdAt":"2024-03-02T20:06:39Z","includesCreatedEdit":true,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/1644#issuecomment-1974895515","viewerDidAuthor":true},{"id":"IC_kwDOC4j8g859A0oK","author":{"login":"dandavison"},"authorAssociation":"OWNER","body":"> One way would perhaps be to add a single option, that allows passing any options to the actually used diff backend\r\n\r\nFinally got around to implementing that at https://github.com/dandavison/delta/pull/1697","createdAt":"2024-05-07T03:14:31Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[{"content":"HEART","users":{"totalCount":1}}],"url":"https://github.com/dandavison/delta/issues/1644#issuecomment-2097367562","viewerDidAuthor":true},{"id":"IC_kwDOC4j8g859A2Pp","author":{"login":"calestyo"},"authorAssociation":"NONE","body":"Thanks :-)","createdAt":"2024-05-07T03:22:52Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/1644#issuecomment-2097374185","viewerDidAuthor":false}],"number":1644,"title":"allow to completely omit zero (\"same\") lines (like `diff -U0` would do)"},{"body":"Hi,\r\nrelated to this part of your docu:\r\n\r\nhttps://dandavison.github.io/delta/build-delta-from-source.html\r\n\r\nThe instructions not complete. I think download/clone the repo is missing.","comments":[],"number":1641,"title":"🐛 Docu: Build instructions incomplete"},{"body":"New user here -- thanks for making delta!\r\n\r\nI just spent an embarrassingly long time debugging why delta was displaying added and removed lines with my terminal's default background color instead of the configured background colors. Oddly, I only saw this problem when I ran e.g. `git show`; delta used the configured background colors when I ran e.g. `git show | delta` instead.\r\n\r\nI finally figured out that it was due to a previously-added `color \"diff\"` section in my `.gitconfig` file:\r\n\r\n```\r\n[color \"diff\"]\r\n meta = brightcyan\r\n old = brightred\r\n new = brightgreen\r\n```\r\n\r\nIt'd helpful to make the \"Get Started\" section of `README.md` mention that settings like these can override delta's behavior to save other people some time. :-)","comments":[{"id":"IC_kwDOC4j8g86TBEM6","author":{"login":"dandavison"},"authorAssociation":"OWNER","body":"Thanks, we're keeping the main Readme very light on text, but I could see this going in a troubleshooting section of the manual.","createdAt":"2024-11-10T00:56:13Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[{"content":"THUMBS_UP","users":{"totalCount":1}}],"url":"https://github.com/dandavison/delta/issues/1640#issuecomment-2466530106","viewerDidAuthor":true}],"number":1640,"title":"🚀 Consider making README.md mention that color settings in .gitconfig can override delta's colors"},{"body":"This failure occasionally occurs when running the delta testsuite:\r\n\r\n```\r\n---- env::tests::test_env_parsing_with_pager_set_to_bat stdout ----\r\nthread 'env::tests::test_env_parsing_with_pager_set_to_bat' panicked at src/env.rs:79:9:\r\nassertion `left == right` failed: Expected env.pagers.1 == Some(bat) but was Some(\"less\")\r\n left: Some(\"less\")\r\n right: Some(\"bat\")\r\nnote: run with `RUST_BACKTRACE=1` environment variable to display a backtrace\r\n```\r\n\r\nThis might be a race condition between tests (which run in parallel).","comments":[],"number":1637,"title":"🐛 Possible race condition in delta testsuite with environment variable setting"},{"body":"I am trying to make `delta` more compact in its use of vertical space. I've removed the decoration for the filename, but it still prints an empty line above and below the filename. Is there any way to remove this whitespace?\r\n\r\n\r\n","comments":[{"id":"IC_kwDOC4j8g86L2VOz","author":{"login":"Gaweringo"},"authorAssociation":"NONE","body":"I am in the same boat, I like the syntax highlighting and diff highlighting from delta, but delta uses so much space with all the divider lines.\r\nMy dream would be to have the highlighting from delta with the layout/design from difftastic. So if you got any further on this, I would like to know how far you got.","createdAt":"2024-09-12T13:24:01Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/1636#issuecomment-2346275763","viewerDidAuthor":false},{"id":"IC_kwDOC4j8g86OGppS","author":{"login":"th1000s"},"authorAssociation":"COLLABORATOR","body":"Yes, that should become configurable. Related, making the divider lines work with full-width characters #1727","createdAt":"2024-09-30T20:41:34Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/1636#issuecomment-2384108114","viewerDidAuthor":false}],"number":1636,"title":"Remove empty lines around filename 🚀 "},{"body":"If the user's git configuration customizes `color.grep.match`, delta won't recognize and highlight matches.\r\n\r\nFor instance, here's `git grep 'Get Started'` in the `delta` repository with my configuration, which sets `color.grep.match = 'bold green'`:\r\n\r\n\r\n\r\nHere's the same grep with the default `git grep` color configuration:\r\n\r\n\r\n\r\nHere's the raw text output as a hexdump (using `-c color.pager=hd`) in both cases:\r\n\r\nWith `color.grep.match = 'bold green'`:\r\n\r\n```\r\n00000000 1b 5b 33 35 6d 52 45 41 44 4d 45 2e 6d 64 1b 5b |.[35mREADME.md.[|\r\n00000010 6d 1b 5b 33 36 6d 3a 1b 5b 6d 23 23 20 1b 5b 31 |m.[36m:.[m## .[1|\r\n00000020 3b 33 32 6d 47 65 74 20 53 74 61 72 74 65 64 1b |;32mGet Started.|\r\n00000030 5b 6d 0a |[m.|\r\n00000033\r\n```\r\n\r\nWith the default `color.grep.match = 'bold red'`:\r\n\r\n```\r\n00000000 1b 5b 33 35 6d 52 45 41 44 4d 45 2e 6d 64 1b 5b |.[35mREADME.md.[|\r\n00000010 6d 1b 5b 33 36 6d 3a 1b 5b 6d 23 23 20 1b 5b 31 |m.[36m:.[m## .[1|\r\n00000020 3b 33 31 6d 47 65 74 20 53 74 61 72 74 65 64 1b |;31mGet Started.|\r\n00000030 5b 6d 0a |[m.|\r\n00000033\r\n```\r\n\r\nNote the different color code on the ANSI escape right before the match.\r\n\r\nI think the most obvious way to fix this would be to retrieve and parse git's color configuration (e.g. using something like [`anstyle-git`](https://crates.io/crates/anstyle-git)), render the result as an ANSI escape sequence, and match against that.\r\n\r\n- [x] Please include the raw text output from git, so that we can reproduce the problem.\r\n (You can use `git --no-pager` to produce the raw text output.)\r\n- [x] A screenshot of Delta's output is often helpful also.\r\n\r\nThanks for filing a Delta bug report!","comments":[],"number":1635,"title":"🐛 Delta doesn't highlight matches if `color.grep.match` changed"},{"body":"\n> safemem is unmaintained\n\n| Details | |\n| ------------------- | ---------------------------------------------- |\n| Status | unmaintained |\n| Package | `safemem` |\n| Version | `0.3.3` |\n| URL | [https://github.com/abonander/safemem](https://github.com/abonander/safemem) |\n| Date | 2023-02-14 |\n\nThe latest crates.io release was in 2019. The repository has been archived by the author.\n\nSee [advisory page](https://rustsec.org/advisories/RUSTSEC-2023-0081.html) for additional details.\n","comments":[],"number":1633,"title":"RUSTSEC-2023-0081: safemem is unmaintained"},{"body":"I have \r\n\r\n```\r\n[delta]\r\n hyperlinks = true\r\n```\r\n\r\nin my `~/.gitconfig`\r\n```\r\n[remote \"origin\"]\r\n url = https://github.com/porridgewithraisins/e2ee.js\r\n fetch = +refs/heads/*:refs/remotes/origin/*\r\n```\r\nin my `~/e2ee.js/.git/config`\r\n\r\nFiles are hyperlinked to vscode as I have set `hyperlinks-file-link-format` to the `vscode://` handler.\r\n\r\nHowever, the commit hash isn't rendering as a hyperlink.\r\n\r\n<img width=\"1438\" alt=\"image\" src=\"https://github.com/dandavison/delta/assets/72668511/53516224-c9ca-479d-8e88-0b0486bd4a2b\">\r\n\r\ncmd+clicking it doesnt work either, fwiw\r\n\r\nAlso, the hyperlinks don't render in `git blame` output either.\r\n\r\nI am using iterm, zsh here.\r\n","comments":[{"id":"IC_kwDOC4j8g86TKaUc","author":{"login":"gczajkowskiTT"},"authorAssociation":"NONE","body":"Same for me","createdAt":"2024-11-11T20:36:06Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/1628#issuecomment-2468979996","viewerDidAuthor":false},{"id":"IC_kwDOC4j8g86TKdpn","author":{"login":"dandavison"},"authorAssociation":"OWNER","body":"Hi @porridgewithraisins, @gczajkowskiTT let's look at the raw bytes that delta's emitting. Can you post the output of\r\n\r\n```\r\ngit show | delta | cat -A\r\n```\r\n\r\n(or `bat -A` if you have bat installed).","createdAt":"2024-11-11T20:46:19Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/1628#issuecomment-2468993639","viewerDidAuthor":true},{"id":"IC_kwDOC4j8g86TKqIy","author":{"login":"gczajkowskiTT"},"authorAssociation":"NONE","body":"In Linux under Kitty (which is closest to functioning)\r\n```\r\n<E2><90><8A>\r\n<E2><90><8A>\r\n<E2><90>[34m\\u{2500}\\u{2500}\\u{2500}\\u{2500}\\u{2500}\\u{2500}\\u{2500}\\u{2500}\\u{2500}\\u{2500}\\u{2500}\\u{2500}\\u{2500}\\u{2500}\\u{2500}\\u{2500}<E2><90>[0m<E2><90>[34m\\u{2510[34m[0m[34m}<E2><90>[0m<E2><90><8A>\r\n<E2><90>[31m\\u{2022}<E2><90>[0m<C2><B7><E2><90>8;;file:///proj_soc/user_dev/gczajkowski/ttdelivery/.gitignore<E2><90><E2><90>[31m.gitignore<E2><90>[0m:<E2><90>[38;2;6;122;0m1<E2><90>[0m<E2>\r\n[31m[0m[31m[0m[38;2;6;122;0m[0m<90>8;;<E2><90>:<C2><B7><E2><90>[34m\\u{2502}<E2><90>[0m<E2><90><8A>\r\n<E2><90>[34m\\u{2500}\\u{2500}\\u{2500}\\u{2500}\\u{2500}\\u{2500}\\u{2500}\\u{2500}\\u{2500}\\u{2500}\\u{2500}\\u{2500}\\u{2500}\\u{2500}\\u{2500}\\u{2500}<E2><90>[0m<E2><90>[34m\\u{2518[34m[0m[34m}<E2><90>[0m<E2><90><8A>\r\n<E2><90>[38;2;117;113;94m#<C2><B7>Linux<E2><90>[0m<E2><90><8A>\r\n```\r\n\r\n<img width=\"754\" alt=\"image\" src=\"https://github.com/user-attachments/assets/24f6b6df-2192-468c-891f-5c8911373bef\">","createdAt":"2024-11-11T21:24:31Z","includesCreatedEdit":true,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/1628#issuecomment-2469044786","viewerDidAuthor":false}],"number":1628,"title":"Commit hyperlink not working 🐛 "},{"body":"`git blame -CCC` also prints filenames but delta doesn't display them. It would be great if delta would show them, or even better only show the ones that differ from the current file.","comments":[],"number":1627,"title":"Show filename when using `git blame -CCC` 🚀 "},{"body":"# Current state:\r\n\r\nThe release page offers packages that contain the version in the filename:\r\n\r\nhttps://github.com/dandavison/delta/releases/\r\ne.g. delta-**0.16.5**-x86_64-unknown-linux-gnu.tar.gz \r\n\r\n# Wanted state:\r\n\r\nThe release page offers packages that do not contain the version in the filename.\r\ne.g. delta-x86_64-unknown-linux-gnu.tar.gz \r\n\r\nExample: project that is not including version in filenames:\r\n\r\nhttps://github.com/starship/starship/releases/latest\r\n\r\n# Why the change is sensible:\r\n\r\nThis is useful to be used in CI, because we fetch the `latest` version periodically and always obtain the latest version.\r\ne.g. https://github.com/starship/starship/releases/latest/download/starship-x86_64-unknown-linux-gnu.tar.gz\r\n","comments":[{"id":"IC_kwDOC4j8g850D7aM","author":{"login":"lukoshkin"},"authorAssociation":"NONE","body":"I think about this. That is why I found myself here :)\r\nIt would be nice to have an alias 'latest' which will point to the latest version","createdAt":"2024-02-15T19:59:22Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/1624#issuecomment-1947186828","viewerDidAuthor":false},{"id":"IC_kwDOC4j8g86LpwZU","author":{"login":"kid1412621"},"authorAssociation":"NONE","body":"want this since debian < 13 cannot find via apt.\r\nso if the script could be more simpler if the asset name without a version.\r\ncurrently using this script:\r\n```bash\r\n delta_version=$(curl -s \"https://api.github.com/repos/dandavison/delta/releases/latest\" | grep -Po '\"tag_name\": \"\\K[^\"]*')\r\n delta_deb_file=\"git-delta_${delta_version}_amd64.deb\"\r\n curl -fLO \"https://github.com/dandavison/delta/releases/latest/download/$delta_deb_file\"\r\n sudo dpkg -i $delta_deb_file && rm $delta_deb_file\r\n```","createdAt":"2024-09-11T08:22:13Z","includesCreatedEdit":true,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/1624#issuecomment-2342979156","viewerDidAuthor":false}],"number":1624,"title":"🚀 Release filename without version "},{"body":"- [X] Please include the raw text output from git, so that we can reproduce the problem.\r\n (You can use `git --no-pager` to produce the raw text output.) - I tried this but it wasn't working\r\n- [X] A screenshot of Delta's output is often helpful also.\r\n\r\nThanks for filing a Delta bug report!\r\n\r\nWe use `.gitattributes` on our project to mark certain files as autogenearted, so in Github they are not expanded when the revieiwer is looking at the code. This could be to mark output js files transpiled from ts files, or autogenerated markdown files. \r\n\r\nAn example of the file to mark the markdown files.\r\n```.gitattributes\r\n*.md -diff\r\n*.md linguist-generated\r\n```\r\n\r\nIn diff tools such as vscode I get expected diff output still, but delta just gives me info about how this is a binary file and I can't see the diff. \r\n\r\nOutput from delta:\r\n\r\n\r\n\r\nOutput with vscode diff vieiwer (this is what I expect)\r\n\r\n\r\n\r\nI understand that if I use the standard `git diff` without delta that it has the same issue, so the answer might be that this isn't possible. I just think there could be a way (potentially enabled with an option) if other tools can manage it. \r\n","comments":[{"id":"IC_kwDOC4j8g85zlSAZ","author":{"login":"imbrish"},"authorAssociation":"CONTRIBUTOR","body":"By unsetting the `diff` in `.gitattributes`, you are telling `git` that it is not possible to diff the `*.md` files. Which, if i understand correctly, is what you want on GitHub. The standard behavior is showing such files as binary. It has nothing to do with delta.\r\n\r\nIf you want to skip these diffs on GitHub, but generate them locally, I guess you could have another attributes file, not included in version control, where you tell `git` it should diff these files. I am a bit unsure about inheritance though.","createdAt":"2024-02-12T17:01:33Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/1623#issuecomment-1939152921","viewerDidAuthor":false},{"id":"IC_kwDOC4j8g85zlWx_","author":{"login":"matteematt"},"authorAssociation":"NONE","body":"I did think that is the case, does that imply then that vscode is behaving how I want due to the fact that it's probably behaving incorrectly? ","createdAt":"2024-02-12T17:11:08Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/1623#issuecomment-1939172479","viewerDidAuthor":false},{"id":"IC_kwDOC4j8g85zmnb_","author":{"login":"imbrish"},"authorAssociation":"CONTRIBUTOR","body":"I don't use vscode myself, but I would imagine it talks with git to be helpful, and not necessarily promises to follow all the rules.","createdAt":"2024-02-12T20:16:41Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/1623#issuecomment-1939502847","viewerDidAuthor":false},{"id":"IC_kwDOC4j8g859EiOY","author":{"login":"0xjac"},"authorAssociation":"NONE","body":"@imbrish I have a similar issue and a scenario which I believe to be relevant here:\r\n\r\nI have generated files which are committed to a repo. Those files are marked as binary mainly to tell git to not perform any kind of merging on those files. It also hides the diffs on Github/Gitlab which is useful as they should not be reviewed/edited when merging.\r\n\r\nHowever locally, there a few times where I do need to look at the code generation process and investigate what changed in those files. I can easily do this with `git diff` by passing the `--text` option, essentially telling git to treat those files as as text (which they actually are).\r\n\r\nI want to use delta to do a diff between two generation versions of my files in two separate dir. Ideally I'd like to do `delta dirA dirB`. Since this calls `git` it doesn't work. My current work around is to call: \r\n```\r\ngit diff --no-index --color --text -- dirA dirB | delta\r\n```\r\nwhich works but is a bit cumbersome.\r\n\r\nI believe the issue is [here](https://github.com/dandavison/delta/blob/main/src/subcommands/diff.rs#L26-L29) where `delta` calls `git` but does not allow passing any extra options to `git`. It would be great if we could do something along the lines of \r\n```\r\ndelta [OPTIONS] [MINUS_FILE] [PLUS_FILE] -- [GIT_OPTIONS]\r\n```\r\nwhich would look like `delta dirA dirB -- --text`.","createdAt":"2024-05-07T12:54:22Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[{"content":"HEART","users":{"totalCount":1}}],"url":"https://github.com/dandavison/delta/issues/1623#issuecomment-2098340760","viewerDidAuthor":false},{"id":"IC_kwDOC4j8g859INQR","author":{"login":"th1000s"},"authorAssociation":"COLLABORATOR","body":"The gitattributes are applied to the output before it is sent to `delta` or any other pager, see `git diff | less` - this is what `delta` works on, and it already mentions binary files.\r\nSetting a different file via `git -c core.attributesFile=my_gitattributes diff` seemingly can not override the `-diff` setting.\r\n\r\nHowever, in _your_ specific case, @0xjac, PR #1697 will add an option so you can call `-@=--text` ","createdAt":"2024-05-07T21:01:07Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/1623#issuecomment-2099303441","viewerDidAuthor":false},{"id":"IC_kwDOC4j8g859IOYb","author":{"login":"0xjac"},"authorAssociation":"NONE","body":"@th1000s I missed that PR. Thanks a lot, it seems perfect. I'll wait for it to be released. :rocket: ","createdAt":"2024-05-07T21:04:31Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/1623#issuecomment-2099308059","viewerDidAuthor":false},{"id":"IC_kwDOC4j8g86Ir_4V","author":{"login":"matteematt"},"authorAssociation":"NONE","body":"HI @th1000s I can see that PR is merged now. What is the release cadence for being able to use this new option?","createdAt":"2024-08-16T10:13:47Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/1623#issuecomment-2293235221","viewerDidAuthor":false},{"id":"IC_kwDOC4j8g86Is6dJ","author":{"login":"dandavison"},"authorAssociation":"OWNER","body":"Hi @matteematt, we just released 0.18.0 with the new `-@` option (`--diff-args`). See `--help` for instructions.","createdAt":"2024-08-16T13:05:04Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/1623#issuecomment-2293475145","viewerDidAuthor":true}],"number":1623,"title":"🐛 delta won't show diffs of files marked as autogenerated with `.gitattributes` even though they're text files"},{"body":"\n> Memory corruption, denial of service, and arbitrary code execution in libgit2\n\n| Details | |\n| ------------------- | ---------------------------------------------- |\n| Package | `libgit2-sys` |\n| Version | `0.15.2+1.6.4` |\n| URL | [https://github.com/rust-lang/git2-rs/pull/1017](https://github.com/rust-lang/git2-rs/pull/1017) |\n| Date | 2024-02-06 |\n| Patched versions | `>=0.16.2` |\n\nThe [libgit2](https://github.com/libgit2/libgit2/) project fixed three security issues in the 1.7.2 release. These issues are:\n\n* The `git_revparse_single` function can potentially enter an infinite loop on a well-crafted input, potentially causing a Denial of Service. This function is exposed in the `git2` crate via the [`Repository::revparse_single`](https://docs.rs/git2/latest/git2/struct.Repository.html#method.revparse_single) method.\n* The `git_index_add` function may cause heap corruption and possibly lead to arbitrary code execution. This function is exposed in the `git2` crate via the [`Index::add`](https://docs.rs/git2/latest/git2/struct.Index.html#method.add) method.\n* The smart transport negotiation may experience an out-of-bounds read when a remote server did not advertise capabilities.\n\nThe `libgit2-sys` crate bundles libgit2, or optionally links to a system libgit2 library. In either case, versions of the libgit2 library less than 1.7.2 are vulnerable. The 0.16.2 release of `libgit2-sys` bundles the fixed version of 1.7.2, and requires a system libgit2 version of at least 1.7.2.\n\nIt is recommended that all users upgrade.\n\nSee [advisory page](https://rustsec.org/advisories/RUSTSEC-2024-0013.html) for additional details.\n","comments":[],"number":1622,"title":"RUSTSEC-2024-0013: Memory corruption, denial of service, and arbitrary code execution in libgit2"},{"body":"A call for the community to come up with a logo!\r\nIf the maintainers accept for this engagement activity, that is ;) ","comments":[],"number":1619,"title":"🚀 A logo for delta?"},{"body":"I configured `hyperlinks-commit-link-format` to `https://<link to repo in Azure DevOps>/commit/{commit}`\r\nThis works well with `git log` etc. but with `git blame` it seems like there is no option to force delta to display the full commit ID, and ADO URL doesn't work with short commit ID (and probably there are other git hostings that don't support it either). It'd be great if a new placeholder can be added to use the full commit SHA-1 in the URL, e.g. something like `hyperlinks-commit-link-format = https://<link to repo>/commit/{fullcommit}`","comments":[],"number":1618,"title":"🚀 Allow asking for full hash of the commit in hyperlinks-commit-link-format"},{"body":"Is this intended? Converting UTF16 files to UTF8 to do a diff would be a little cumbersome...","comments":[{"id":"IC_kwDOC4j8g85xZBR9","author":{"login":"dandavison"},"authorAssociation":"OWNER","body":"Hi @nozwock, I believe the codebase is well set up to attempt decoding of non-utf8 encodings: https://github.com/dandavison/delta/blob/e208f4ed52759fc018ee14808717c977df57b56f/src/delta.rs#L186\r\n\r\nbut it doesn't seem to get asked for often and no-one has actually added fallback to attempting other encodings.\r\n\r\nAs you can see, it attempts to decode as utf-8 and, if that fails, uses Rust's `from_utf8_lossy` function. I can imagine the results aren't terribly helpful for utf-16.\r\n","createdAt":"2024-01-20T23:23:47Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/1614#issuecomment-1902384253","viewerDidAuthor":true},{"id":"IC_kwDOC4j8g856Oq1f","author":{"login":"nozwock"},"authorAssociation":"NONE","body":"What do you think about incorporating an encoding option into the CLI, and then decoding based on that?","createdAt":"2024-04-11T22:34:48Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/1614#issuecomment-2050665823","viewerDidAuthor":false}],"number":1614,"title":"🐛 Treats UTF-16 text files as binary files"},{"body":"I tried out what I found here: https://dandavison.github.io/delta/tips-and-tricks/shell-completion.html\r\n\r\nAnd got the error you see below.\r\nI tried it first with the homebrew install, then the downloaded version directly from github. Same issue with either version.\r\n\r\n```console\r\n$ ./delta-0.16.5-aarch64-apple-darwin/delta --generate-completion fish\r\nerror: unexpected argument '--generate-completion' found\r\n\r\n note: argument '--grep-context-line-style' exists\r\n\r\nUsage: delta <--blame-code-style <STYLE>|--blame-format <FMT>|--blame-palette <COLORS>|--blame-separator-format <FMT>|--blame-separator-style <STYLE>|--blame-timestamp-format <FMT>|--blame-timestamp-output-format <FMT>|--color-only|--config <PATH>|--commit-decoration-style <STYLE>|--commit-regex <REGEX>|--commit-style <STYLE>|--dark|--default-language <LANG>|--diff-highlight|--diff-so-fancy|--diff-stat-align-width <N>|--features <FEATURES>|--file-added-label <STRING>|--file-copied-label <STRING>|--file-decoration-style <STYLE>|--file-modified-label <STRING>|--file-removed-label <STRING>|--file-renamed-label <STRING>|--file-style <STYLE>|--file-transformation <SED_CMD>|--grep-context-line-style <STYLE>|--grep-file-style <STYLE>|--grep-header-decoration-style <STYLE>|--grep-header-file-style <STYLE>|--grep-line-number-style <STYLE>|--grep-output-type <OUTPUT_TYPE>|--grep-match-line-style <STYLE>|--grep-match-word-style <STYLE>|--grep-separator-symbol <STRING>|--hunk-header-decoration-style <STYLE>|--hunk-header-file-style <STYLE>|--hunk-header-line-number-style <STYLE>|--hunk-header-style <STYLE>|--hunk-label <STRING>|--hyperlinks|--hyperlinks-commit-link-format <FMT>|--hyperlinks-file-link-format <FMT>|--inline-hint-style <STYLE>|--inspect-raw-lines <true|false>|--keep-plus-minus-markers|--light|--line-buffer-size <N>|--line-fill-method <STRING>|--line-numbers|--line-numbers-left-format <FMT>|--line-numbers-left-style <STYLE>|--line-numbers-minus-style <STYLE>|--line-numbers-plus-style <STYLE>|--line-numbers-right-format <FMT>|--line-numbers-right-style <STYLE>|--line-numbers-zero-style <STYLE>|--list-languages|--list-syntax-themes|--map-styles <STYLES_MAP>|--max-line-distance <DIST>|--max-line-length <N>|--merge-conflict-begin-symbol <STRING>|--merge-conflict-end-symbol <STRING>|--merge-conflict-ours-diff-header-decoration-style <STYLE>|--merge-conflict-ours-diff-header-style <STYLE>|--merge-conflict-theirs-diff-header-decoration-style <STYLE>|--merge-conflict-theirs-diff-header-style <STYLE>|--minus-empty-line-marker-style <STYLE>|--minus-emph-style <STYLE>|--minus-non-emph-style <STYLE>|--minus-style <STYLE>|--navigate|--navigate-regex <REGEX>|--no-gitconfig|--pager <CMD>|--paging <auto|always|never>|--parse-ansi|--plus-emph-style <STYLE>|--plus-empty-line-marker-style <STYLE>|--plus-non-emph-style <STYLE>|--plus-style <STYLE>|--raw|--relative-paths|--right-arrow <STRING>|--show-colors|--show-config|--show-syntax-themes|--show-themes|--side-by-side|--syntax-theme <SYNTAX_THEME>|--tabs <N>|--true-color <auto|always|never>|--whitespace-error-style <STYLE>|--width <N>|--word-diff-regex <REGEX>|--wrap-left-symbol <STRING>|--wrap-max-lines <N>|--wrap-right-percent <PERCENT>|--wrap-right-prefix-symbol <STRING>|--wrap-right-symbol <STRING>|--zero-style <STYLE>|--24-bit-color <auto|always|never>|MINUS_FILE|PLUS_FILE>\r\n\r\nFor more information, try '--help'.\r\n```\r\n\r\nLet me know if you need any more info!\r\n\r\n","comments":[],"number":1610,"title":"🐛 error: unexpected argument '--generate-completion' found"},{"body":"Hey.\r\n\r\nOn a Debian unstable, with delta `0.16.5-5` and **no** `git` installed, I get this:\r\n```\r\n$ touch 1 2\r\n$ delta 1 2\r\nFailed to execute the command 'git': No such file or directory (os error 2)\r\n$ delta --no-gitconfig 1 2\r\nFailed to execute the command 'git': No such file or directory (os error 2)\r\n$\r\n```\r\n\r\nInterestingly it does work with:\r\n```\r\n$ delta <(echo a) <(echo b)\r\n…\r\n```\r\n\r\nSo this might be somehow related to #1584.\r\n\r\nCheers,\r\nChris.","comments":[],"number":1593,"title":"🐛 delta fails to run (in some cases) when `git` is not installed"},{"body":"So glad to have come across Delta. Thank you for making this helpful tool that improves accessibility of diffs!\r\n\r\nCurrently Delta only highlights whitespace errors in added/plus lines. For some diffs, fully understanding them involves knowing about whitespace errors in removed/minus lines as well, and on rare occasions it can also be useful in context lines. But as far as I can tell, Delta has no option to specifically highlight whitespace errors in any additional places other than added lines.\r\n\r\n`git diff` has the option `--ws-error-highlight` for this. Tried passing git this option when piping to Delta, but this doesn't work, looks like Delta removes this highlighting along with the expected removal of other color codes.\r\n\r\nCould Delta please have option to highlight whitespace errors in removed lines, and possibly also in context lines?\r\n\r\nThanks :slightly_smiling_face: ","comments":[{"id":"IC_kwDOC4j8g853W7us","author":{"login":"phillipwood"},"authorAssociation":"CONTRIBUTOR","body":"I agree it would be really nice for delta to support this. There is some support for trailing whitespace at the end of lines, but not for other whitespace attributes like `blank-at-eof` or `space-before-tab`. One way that would avoid having to re-implement the detection and config parsing in delta would be to parse the error highlights in the output from git, remembering their offset from the beginning of the hunk and using that information to render them when delta paints the processed lines. I'm not sure how easy that would be to implement though.","createdAt":"2024-03-17T15:00:51Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/1590#issuecomment-2002500524","viewerDidAuthor":false},{"id":"IC_kwDOC4j8g853XI0f","author":{"login":"dandavison"},"authorAssociation":"OWNER","body":"This is just a thought, I sort of think it isn't really the right way forward:\r\n\r\nThe way that delta support git's \"color-moved\" feature is that, if we see that git has emitted a color other than the standard red and green (`line_has_style_other_than`), then we just emit the line raw. In other words, delta essentially gives up and supports color-moved in a rather hacky way.\r\n\r\nSo we could take the same approach here. In fact, one might think it would work already. The reason it doesn't is that `line_has_style_other_than()` is implemented in a rather odd way, partly out of concern for efficiency I think:\r\n\r\nhttps://github.com/dandavison/delta/blob/4b80dfb04c4a6e2dc841408345a2f72d441cf161/src/style.rs#L369\r\n\r\nHere's a proof-of-concept branch that reimplements `line_has_style_other_than()`: https://github.com/dandavison/delta/compare/1590-ws-error-highlight-workaround\r\n\r\nwith the result that `git show --ws-error-highlight=all` does work on that branch:\r\n\r\n<img width=\"333\" alt=\"image\" src=\"https://github.com/dandavison/delta/assets/52205/1e2a8ba9-3b82-411e-a4ea-46c67d29289f\">\r\n\r\n\r\nThat said, ideally, delta would provide its own take on rendering both `color-moved` and `ws-error-highlight`, instead of just passing through git's raw output. On the plus side, delta does have pretty convenient (and efficient) primitives for parsing ANSI color escapes into style structs and working with those structs (e.g. see the diff in the branch linked above), so it might well be possible to do the more \"ideal\" version now.\r\n\r\nI don't have an opinion on the right way forward yet, just throwing out an idea and pointing to some code; interested to know what others think.\r\n\r\nAs an aside `GIT_DEFAULT_MINUS_STYLE` and `GIT_DEFAULT_PLUS_STYLE` (i.e. the default \"red\" and \"green\" emitted by git) are currently hard-coded; they should be taken dynamically from user git config.","createdAt":"2024-03-17T17:53:12Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/1590#issuecomment-2002554143","viewerDidAuthor":true},{"id":"IC_kwDOC4j8g8531DpD","author":{"login":"laniakea64"},"authorAssociation":"NONE","body":"Thanks dandavison for looking into this :slightly_smiling_face: \r\n\r\n> Here's a proof-of-concept branch that reimplements `line_has_style_other_than()`: https://github.com/dandavison/delta/compare/1590-ws-error-highlight-workaround\r\n> \r\n> with the result that `git show --ws-error-highlight=all` does work on that branch:\r\n\r\nJust tried this branch, but am getting a very different result. Testing it with the last two commits on that branch, with passing `--ws-error-highlight` to `git`: lines with whitespace errors are highlighted red not just on the whitespace error, but all the way to the end of the line in the terminal? :confused: \r\n\r\nIn case it's related, I don't keep Delta configuration in gitconfig, instead I run Delta using a wrapper script that invokes `git diff` or `git show` with `--color=always` option (followed by whatever else is specified on the command line), piped to Delta invoked with these options:\r\n```\r\n --keep-plus-minus-markers \\\r\n --max-line-length 9999 \\\r\n --syntax-theme \"$syn\" \\\r\n --minus-style 'red auto' \\\r\n --minus-emph-style '#ff8877 bold auto' \\\r\n --plus-style 'green auto' \\\r\n --plus-emph-style 'brightgreen bold auto' \\\r\n```\r\nwhere `$syn` is `none` unless I explicitly specify otherwise.\r\n\r\n> That said, ideally, delta would provide its own take on rendering both `color-moved` and `ws-error-highlight`, instead of just passing through git's raw output.\r\n\r\n+1. Mainly because this would avoid losing word diff highlighting, which is the reason I looked into Delta in the first place. Additionally, it would allow more control over how to style highlighted whitespace errors.","createdAt":"2024-03-20T19:07:04Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/1590#issuecomment-2010397251","viewerDidAuthor":false}],"number":1590,"title":"🚀 `ws-error-highlight`"},{"body":"Duplicate of https://github.com/dandavison/delta/issues/1441 (or derivate): perhaps fixed already? My \r\n```\r\nrg --version\r\nripgrep 14.0.3\r\n\r\nfeatures:-simd-accel,+pcre2\r\nsimd(compile):+NEON\r\nsimd(runtime):+NEON\r\n\r\nPCRE2 10.42 is available (JIT is available)\r\n``` \r\non `macOS 13.6.1 Ventura`.\r\n\r\n### Description\r\nColoured output for `rg ... --json | delta` fails when tabs are included in the grepped line\r\n\r\n### Example\r\n```\r\ntouch file\r\necho $'first line\\n\\tsecond line\\n\\tthirdline' > file\r\n```\r\n\r\n```sh\r\nrg line file\r\n```\r\nshows\r\n\r\nwhereas\r\n```sh\r\nrg line file --json | delta\r\n```\r\nshows \r\n\r\nwhere the lines with tabs present wrong highlight.","comments":[{"id":"IC_kwDOC4j8g85xMG_M","author":{"login":"freeformz"},"authorAssociation":"NONE","body":"I have this problem too...\r\nI \"solved\" this by adding `--tabs=1` (after trying a few different values) to my delta command line.","createdAt":"2024-01-18T18:27:14Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[{"content":"THUMBS_UP","users":{"totalCount":3}}],"url":"https://github.com/dandavison/delta/issues/1588#issuecomment-1898999756","viewerDidAuthor":false},{"id":"IC_kwDOC4j8g85xQE_l","author":{"login":"gennaro-tedesco"},"authorAssociation":"NONE","body":"Thank you for the suggestion, it does indeed work!","createdAt":"2024-01-19T09:19:56Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/1588#issuecomment-1900040165","viewerDidAuthor":false}],"number":1588,"title":"🐛 wrong highlight with `rg --json | delta` when tabs are involved"},{"body":"🚀 Please add support for cargo-binstall","comments":[{"id":"IC_kwDOC4j8g85vPdNf","author":{"login":"dandavison"},"authorAssociation":"OWNER","body":"Hi @owenstake, can you flesh out this proposal please? (Assume that the reader is completely unfamiliar with `cargo-binstall`.)\r\n\r\n- What problem with the current installation options are you addressing? How will it be improved with `cargo-binstall`?\r\n- What would need to be done to make it happen?\r\n- What other Rust CLI projects have taken the approach you're proposing?","createdAt":"2023-12-21T14:07:19Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/1587#issuecomment-1866322783","viewerDidAuthor":true}],"number":1587,"title":"🚀 Please add support for cargo-binstall"},{"body":"Hey.\r\n\r\nIt seems right now, that `delta` has an exit status of `0` in case no differences were found, and one of `1` either when differences were found or an error (e.g. file not found) occurred.\r\n\r\nIt would be nice if one could differ between the latter two, ideally following [POSIX' exit statuses for diff](https://pubs.opengroup.org/onlinepubs/9699919799/utilities/diff.html#tag_20_34_14), that is:\r\n> 0 No differences were found.\r\n> 1 Differences were found.\r\n> \\>1 An error occurred.\r\n\r\nThanks,\r\nChris.","comments":[{"id":"IC_kwDOC4j8g85u_bcZ","author":{"login":"dandavison"},"authorAssociation":"OWNER","body":"Hi @calestyo, I thought that it worked like that already! Can you post an example? This is MacOS in zsh.\r\n\r\n```\r\n~ delta <(echo a) <(echo a) > /dev/null; echo $?\r\n0\r\n~ delta <(echo a) <(echo b) > /dev/null; echo $?\r\n1\r\n~ delta <(echo a) __not_there__ > /dev/null; echo $?\r\ndiff: __not_there__: No such file or directory\r\n2\r\n```","createdAt":"2023-12-19T05:01:36Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/1584#issuecomment-1862121241","viewerDidAuthor":true},{"id":"IC_kwDOC4j8g85u_dsf","author":{"login":"calestyo"},"authorAssociation":"NONE","body":"Indeed. Not sure how I produced the contradicting result.... I've been calling `delta` from a shell script, and I think there might have been an `exit 1` at a wrong point, which has overridden `delta`’s `2`.\r\n\r\nSorry for the noise.\r\n\r\nbtw: Is there a way in `delta` to **disable** colour output?","createdAt":"2023-12-19T05:13:31Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/1584#issuecomment-1862130463","viewerDidAuthor":false},{"id":"IC_kwDOC4j8g85u_fA9","author":{"login":"dandavison"},"authorAssociation":"OWNER","body":"No worries.\r\n\r\n> btw: Is there a way in delta to disable colour output?\r\n\r\nYou mean, keep all the reformatting and decorations but specifically disable colour? I don't think there is a way to do that, although perhaps there are enough colour settings in delta to achieve it piecemeal!\r\n\r\nSo in a script the answer would be not to call delta if one only wants the raw git/diff input, and of course, git doesn't invoke delta at all if output is not a tty. But if you explicitly pipe to delta in a script then it will add colours and text decorations / reformatting.","createdAt":"2023-12-19T05:19:30Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/1584#issuecomment-1862135869","viewerDidAuthor":true},{"id":"IC_kwDOC4j8g85u_g5J","author":{"login":"calestyo"},"authorAssociation":"NONE","body":"> No worries.\r\n\r\nI reproduced it... wait a second...","createdAt":"2023-12-19T05:27:03Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/1584#issuecomment-1862143561","viewerDidAuthor":false},{"id":"IC_kwDOC4j8g85u_hlF","author":{"login":"calestyo"},"authorAssociation":"NONE","body":"```\r\n$ touch foo\r\n$ stat /tmp/bar\r\nstat: cannot statx '/tmp/bar': No such file or directory\r\n$ delta foo /tmp/bar ; echo $?\r\nerror: Could not access '/tmp/bar'\r\n1\r\n```\r\n\r\nIf I do however:\r\n```\r\n$ delta <(echo foo) /tmp/bar ; echo $?\r\ndiff: /tmp/bar: No such file or directory\r\n2\r\n```","createdAt":"2023-12-19T05:29:37Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/1584#issuecomment-1862146373","viewerDidAuthor":false},{"id":"IC_kwDOC4j8g85u_jc4","author":{"login":"dandavison"},"authorAssociation":"OWNER","body":"Ah-ha, I'm not at my computer but I do remember that the code handling process substitutions had to do something unfortunate. Feel free to investigate!","createdAt":"2023-12-19T05:38:31Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/1584#issuecomment-1862154040","viewerDidAuthor":true},{"id":"IC_kwDOC4j8g85u_mmT","author":{"login":"calestyo"},"authorAssociation":"NONE","body":"There are more cases:\r\n```\r\n$ delta /dev/null non-existent\r\n$ delta /dev/random non-existent\r\n$ delta /dev/uinput non-existent\r\n```\r\nall give `1`, and only `uinput` is permission-wise not accessible by the user.\r\n\r\nAlso:\r\n```\r\n$ ln -s /nonexistent dangling.symlink\r\n$ delta dangling.symlink non-existent\r\n```\r\nThough it works when comparing with an existent file (not sure, btw. whether it should even then, cause then there's still one inaccessible file - the target of the dangling symlink).","createdAt":"2023-12-19T05:54:23Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/1584#issuecomment-1862166931","viewerDidAuthor":false},{"id":"IC_kwDOC4j8g85u_mxv","author":{"login":"calestyo"},"authorAssociation":"NONE","body":"Also when doing using a directory as existent file:\r\n```\r\n$ delta /tmp non-existent\r\n```","createdAt":"2023-12-19T05:55:19Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/1584#issuecomment-1862167663","viewerDidAuthor":false},{"id":"IC_kwDOC4j8g856qVLo","author":{"login":"calestyo"},"authorAssociation":"NONE","body":"That issue may even go yet a bit further.\r\n\r\nAssume I do:\r\n```\r\nfoo=\"$(diff -u a b)\"\r\n````\r\n(and there is a difference)<br>\r\nand then:\r\n```\r\nprintf '%s\\n' \"$foo\" | delta\r\n```\r\nI get the differences shown, but exit status is `0` (and not `1`).","createdAt":"2024-04-15T22:29:13Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/1584#issuecomment-2057917160","viewerDidAuthor":false},{"id":"IC_kwDOC4j8g856sPT0","author":{"login":"dandavison"},"authorAssociation":"OWNER","body":"That's right, in `something | delta` delta behaves like cat or bat -- it's just a pager displaying stuff and exit code is 0 unless something goes wrong. On the other hand in `delta a b` delta acts as a diff program, and exit codes are as `diff`.","createdAt":"2024-04-16T07:28:10Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/1584#issuecomment-2058417396","viewerDidAuthor":true},{"id":"IC_kwDOC4j8g856yEos","author":{"login":"calestyo"},"authorAssociation":"NONE","body":"Well unless for the other cases mentioned above, where one does have `delta a b` style and it still doesn't act like `diff`. :-)","createdAt":"2024-04-16T21:24:40Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/1584#issuecomment-2059946540","viewerDidAuthor":false}],"number":1584,"title":"🚀 use diff-compatible exit statuses that differ between difference-found and error"},{"body":"Essentially, `diff-so-fancy` will highlight caps like aa -> AA within a word, but `delta` does not. However, `--diff-so-fancy` mode for `delta` doesn't do it either.\r\n```\r\ngit --no-pager diff @ @~1\r\ndiff --git a/sample.m b/sample.m\r\nindex d0b67f9..b068058 100644\r\n--- a/sample.m\r\n+++ b/sample.m\r\n@@ -1 +1 @@\r\n-AAaaAA\r\n+AAAAAA\r\n```\r\n\r\n\r\n\r\n```\r\n❱ delta --version\r\ndelta 0.16.5\r\n❱ diff-so-fancy --version\r\nDiff-so-fancy: https://github.com/so-fancy/diff-so-fancy\r\nVersion : 1.4.4\r\n```\r\n","comments":[{"id":"IC_kwDOC4j8g85uDK8_","author":{"login":"ketchupfriend"},"authorAssociation":"NONE","body":"Might be https://github.com/dandavison/delta/issues/1552","createdAt":"2023-12-08T00:42:56Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/1579#issuecomment-1846325055","viewerDidAuthor":false}],"number":1579,"title":"🐛 Highlighting of capitalisation changes does not match `diff-so-fancy` when using `delta diff-so-fancy`"},{"body":"Currently:\r\n\r\n\r\n\r\nleft is 图片的地址大小, right is 图片的地址\r\n\r\nChinese words doesn't be separated by spaces, in fact, 图片的地址大小 is:\r\n\r\n图片 picture\r\n的 's\r\n地址 address\r\n大小 size\r\n\r\nSo in semantic of sentence, left should be 大小, right should be none.","comments":[{"id":"IC_kwDOC4j8g85tNKqF","author":{"login":"dandavison"},"authorAssociation":"OWNER","body":"Thanks, this is an interesting problem. I guess the question is: what is the standard technique in a modern Rust application for performing this segmentation?","createdAt":"2023-11-29T15:45:38Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/1574#issuecomment-1832168069","viewerDidAuthor":true},{"id":"IC_kwDOC4j8g85tNRDC","author":{"login":"Freed-Wu"},"authorAssociation":"NONE","body":"In other languages, I know some libraries to segmentation:\r\n\r\n- [jieba](https://github.com/fxsjy/jieba): for python\r\n- [segmentit](https://github.com/linonetwo/segmentit): for javascript\r\n\r\nI guess rust also have similar libraries, although I haven't searched.","createdAt":"2023-11-29T16:00:05Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/1574#issuecomment-1832194242","viewerDidAuthor":false},{"id":"IC_kwDOC4j8g85-dYM2","author":{"login":"zhaihao"},"authorAssociation":"NONE","body":"> Thanks, this is an interesting problem. I guess the question is: what is the standard technique in a modern Rust application for performing this segmentation?\r\n\r\n\r\nIn fact, Chinese does not need segmentation; character-level highlighting is sufficient.\r\n","createdAt":"2024-05-21T03:04:11Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/1574#issuecomment-2121630518","viewerDidAuthor":false}],"number":1574,"title":"🚀 diff chinese words better"},{"body":"Using `delta --help`` produces auto highlighted output, which can be bothersome when piped to a pager or e.g. `bat -l help`. When sending to pipe, the escape codes should be removed.","comments":[],"number":1570,"title":"🐛 When piping --help, the output should not contain escape chars"},{"body":"I am using n and N but they seem to only navigate between hunks rather than between files. The README and the book say that they should navigate between files.\r\n\r\nI have set `[delta] navigate = true` in my Git config and confirmed its value with `git config delta.navigate` which returns `true`.","comments":[],"number":1557,"title":"Navigate keybinds only go between hunks, not files"},{"body":"When using `git diff --color-words` with a diff which itself contains a patch file being committed, delta appears to be confused by inner section markers. It seems likely that delta is only considering the text characters instead of also likely needing to consider color state to distinguish this case.\r\n\r\nTested using 0.16.5\r\n\r\ndelta:\r\n\r\n\r\nless:\r\n\r\n\r\n\r\n<details>\r\n<summary>raw text</summary>\r\n<pre>\r\ndiff --git c/CVE-2023-38545_7.78.0.patch i/CVE-2023-38545_7.78.0.patch\r\nnew file mode 100644\r\nindex 0000000..7609849\r\n--- /dev/null\r\n+++ i/CVE-2023-38545_7.78.0.patch\r\n@@ -0,0 +1,137 @@\r\nFrom e478fb5f5f2e26e2b060a51939dd2746041459ab Mon Sep 17 00:00:00 2001\r\nFrom: Jay Satiro <raysatiro@yahoo.com>\r\n...\r\n\r\ndiff --git a/lib/socks.c b/lib/socks.c\r\nindex 91c4223..222660c 100644\r\n--- a/lib/socks.c\r\n+++ b/lib/socks.c\r\n@@ -535,9 +535,9 @@ CURLproxycode Curl_SOCKS5(const char *proxy_user,\r\n\r\n /* RFC1928 chapter 5 specifies max 255 chars for domain name in packet */\r\n if(!socks5_resolve_local && hostname_len > 255) {\r\n</pre>\r\n</details>","comments":[],"number":1551,"title":"🐛 Confused when using git-diff --color-words with a patch file"},{"body":"Running this reproduction script:\r\n\r\n```sh\r\n#!/usr/bin/env bash\r\n\r\ncd \"$(mktemp -d)\"\r\n\r\nexport GIT_CONFIG_GLOBAL=/dev/null\r\nexport GIT_CONFIG_NOSYSTEM=1\r\nexport PAGER=cat\r\n\r\ngit -c init.defaultBranch=master init . >/dev/null\r\ngit config user.email \"testing@example.com\"\r\ngit config user.name \"Best Tester\"\r\n\r\necho -e \"something\\nblah\\nblah\\nlong\\nfile\" > here\r\necho -e \"different\\nlorem\\nipsum\\ndolor\\nsit\\namet\" > there\r\ngit add .\r\ngit commit -m \"initial commit\" >/dev/null\r\n\r\nmv here moved\r\ncp there copied\r\ngit add .\r\ngit commit -m \"second commit\" >/dev/null\r\n\r\necho \"==== regular diff ====\"\r\ngit --no-pager diff -C -C HEAD~ HEAD\r\necho \"======================\"\r\n\r\necho\r\n\r\necho \"==== $(delta --version | tr -d '\\n') ====\"\r\ngit -c core.pager=delta diff -C -C HEAD~ HEAD\r\necho \"======================\"\r\n```\r\n\r\nProduces the following output:\r\n\r\n```\r\n==== regular diff ====\r\ndiff --git a/there b/copied\r\nsimilarity index 100%\r\ncopy from there\r\ncopy to copied\r\ndiff --git a/here b/moved\r\nsimilarity index 100%\r\nrename from here\r\nrename to moved\r\n======================\r\n\r\n==== delta 0.16.5 ====\r\n======================\r\n```","comments":[{"id":"IC_kwDOC4j8g85n1r-L","author":{"login":"RuRo"},"authorAssociation":"NONE","body":"This looks like it might be a regression from #392","createdAt":"2023-10-01T16:10:45Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/1548#issuecomment-1742126987","viewerDidAuthor":false},{"id":"IC_kwDOC4j8g8511TwB","author":{"login":"imbrish"},"authorAssociation":"CONTRIBUTOR","body":"Hey! Piping the diff you provided produces correct output in current `main`. You may want to try the same?\r\n\r\n\r\n","createdAt":"2024-03-04T15:57:17Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/1548#issuecomment-1976908801","viewerDidAuthor":false},{"id":"IC_kwDOC4j8g8513L_2","author":{"login":"RuRo"},"authorAssociation":"NONE","body":"Okay, so this is a separate issue, but it seems that delta doesn't respect the `GIT_CONFIG_GLOBAL` and `GIT_CONFIG_NOSYSTEM` environment variables which is all kinds of wrong. So my \"minimal\" reproduction didn't work because delta was still reading my gitconfig.\r\n\r\n---\r\n\r\nAfter figuring that out, I was finally able to find the problematic option: `file-style = omit`. You could argue that this is working as intended, however this behaviour doesn't really make sense. My understanding is that the main reason for the existence of `file-style = omit` is to complement `hunk-header-style = file line-number`, but since renames and copies don't produce hunks, then it doesn't make sense to completely omit this information.\r\n\r\nSo IMHO, `file-style = omit` should only omit \"empty\" file section headers and keep the rename/copy information. Or at the very least there should be an option that does that.\r\n\r\nOr alternatively, rename/copy operations should be represented by their own pseudo-hunks when `file-style` is set to `omit`.","createdAt":"2024-03-04T20:30:11Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/1548#issuecomment-1977401334","viewerDidAuthor":false},{"id":"IC_kwDOC4j8g8513MlH","author":{"login":"dandavison"},"authorAssociation":"OWNER","body":"> it seems that delta doesn't respect the GIT_CONFIG_GLOBAL and GIT_CONFIG_NOSYSTEM environment variables\r\n\r\nWhat delta version? I thought that this was a libgit2 issue that had been solved.","createdAt":"2024-03-04T20:31:44Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/1548#issuecomment-1977403719","viewerDidAuthor":true},{"id":"IC_kwDOC4j8g8513PAH","author":{"login":"RuRo"},"authorAssociation":"NONE","body":"I patched the nixpkgs derivation of `delta` to compile from dcae5bcc2428d1fb6f5ff7b9cddd7f268d9a3735 (main at the time of writing). Though `delta --version` itself still reports the version as `0.16.5`.\r\n\r\nP.S. looking at the build logs, I can see that `libgit2-sys v0.15.2+1.6.4` was compiled/used by cargo.\r\n\r\nP.P.S. looking at the upstream libgit2 repo, it seems that the relevant PR https://github.com/libgit2/libgit2/pull/6544 was first [released in version 1.7.0](https://github.com/libgit2/libgit2/releases/tag/v1.7.0).","createdAt":"2024-03-04T20:38:38Z","includesCreatedEdit":true,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/1548#issuecomment-1977413639","viewerDidAuthor":false},{"id":"IC_kwDOC4j8g8513jcm","author":{"login":"dandavison"},"authorAssociation":"OWNER","body":"Thanks @RuRo! I update git2 in main: https://github.com/dandavison/delta/pull/1647","createdAt":"2024-03-04T21:33:24Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/1548#issuecomment-1977497382","viewerDidAuthor":true},{"id":"IC_kwDOC4j8g8516c__","author":{"login":"RuRo"},"authorAssociation":"NONE","body":"Great. Circling back to the original issue, what do you think about the current behaviour of `file-style = omit` + `hunk-header-style = file line-number` for renames/copies?","createdAt":"2024-03-05T08:58:43Z","includesCreatedEdit":true,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/1548#issuecomment-1978257407","viewerDidAuthor":false},{"id":"IC_kwDOC4j8g8518VQy","author":{"login":"imbrish"},"authorAssociation":"CONTRIBUTOR","body":"For diffs of binary files, I was thinking about keeping the line `Binary files a/foo and b/bar differ`. Similarly standalone `diff` can report `Files foo and bar are identical`. Such line is not present for renames and copies of `git diff`, but I think it may be useful to have it.\r\n\r\n@dandavison what do you think about adding such line for otherwise empty diffs? It could be hidden behind an option like `--show-status-line` that would be disabled by default, and perhaps enabled automatically along with `file-style = omit`.\r\n\r\n@RuRo would something like that work in your case?","createdAt":"2024-03-05T13:12:28Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/1548#issuecomment-1978750002","viewerDidAuthor":false},{"id":"IC_kwDOC4j8g8519Jqr","author":{"login":"RuRo"},"authorAssociation":"NONE","body":"> @RuRo would something like that work in your case?\r\n\r\nI think so. I guess, the specifics could use some bikeshedding, but I'd generally be okay with any solution that could show this information without showing the redundant (when used with `hunk-header-style = file line-number`) file \"section\" headers.","createdAt":"2024-03-05T14:58:40Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/1548#issuecomment-1978964651","viewerDidAuthor":false}],"number":1548,"title":"🐛 `rename` and `copy` operations produce empty output"},{"body":"I have delta correctly setup as my git's pager, with interactive options and do on\r\n\r\nWhen running `git am -i ...`, and in the interactive session choosing `[v]iew patch`, the current .patch diff should be displayed.\r\nBut with delta enabled, that \"wrong usage\" error shows up instead:\r\n\r\n> The main way to use delta is to configure it as the pager for git: see https://github.com/dandavison/delta#get-started. You can also use delta to diff two files: `delta file_A file_B`.\r\n\r\n\r\nI only can suppose git does a `delta ./file.patch` (like a with `--no-pager` option, the result is the same as simple `cat ./file.patch`), which indeed trigger that error message.\r\nI can see that piping the file do delta works pretty well, as it just ignores the patch header, and show the diff properly:\r\n\r\n```\r\n> cat ./file.patch\r\n\r\nfile.patch \r\nFrom ...\r\n\r\n---\r\n.file.txt | 1+\r\n1 file changed ...\r\n\r\ndiff --git a/file.txt b/file.txt\r\n...\r\n@@ -1,2 +1,3 @@\r\ntext file\r\n+ a change\r\n\r\n```\r\n\r\n```\r\n> cat ./file.patch | delta\r\n\r\nfile.patch \r\nFrom ...\r\n\r\n---\r\n.file.txt | 1+\r\n1 file changed ...\r\n\r\n\r\n━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━\r\nΔ file.txt\r\n━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━\r\n\r\n────────────────┐\r\n• file.txt:1: │\r\n────────────────┘\r\n 1 ⋮ 1 │text file\r\n ⋮ 2 │a change\r\n\r\n━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━\r\n```\r\n\r\nRunning manually without the pager (`git --no-pager am -i ...`), and if needed to see long diffs, do a delta pipe on other terminal, is a somewhat inconvenient workaround, but works for now.\r\n\r\nSo i suppose it is kinda a feature-request too, to enable delta to read a single .patch file `delta file.patch`, if it is indeed the workflow going on under the hood here.","comments":[],"number":1547,"title":"🐛 doesn't work on `git am -i`'s `[v]iew patch`"},{"body":"Edit: see https://github.com/dandavison/delta/issues/1546#issuecomment-1739844657\r\n\r\nWhen diffing Vue SFC files, delta does not properly syntax highlight - even when the diff is a syntax complete file.\r\n\r\n```\r\ndiff --git ***/***/test.vue\r\nindex e69de29bb..ef35203ac 100644\r\n--- a/***/***/test.vue\r\n+++ b/***/***/test.vue\r\n@@ -0,0 +1,15 @@\r\n+<template>\r\n+ <div class=\"className\" />\r\n+</template>\r\n+\r\n+<script setup>\r\n+import fs from 'node:fs'\r\n+\r\n+fs.readFile()\r\n+</script>\r\n+\r\n+<style>\r\n+.css {\r\n+ background: transparent;\r\n+}\r\n+</style>\r\n```\r\n- [x] A screenshot of Delta's output is often helpful also.\r\n\r\n<img width=\"957\" alt=\"image\" src=\"https://github.com/dandavison/delta/assets/410558/c286981c-793a-48e7-b1f3-c9bf64d2f4da\">\r\n\r\nbat for the same file\r\n<img width=\"958\" alt=\"image\" src=\"https://github.com/dandavison/delta/assets/410558/0e62ebeb-efc1-4cae-9e74-740a5e3a52c1\">","comments":[{"id":"IC_kwDOC4j8g85ns3b2","author":{"login":"pm0u"},"authorAssociation":"NONE","body":"Edit: take it back, it appears to syntax highlight correctly outside of the diff contents (that's probably my bad) however CSS does not seem to highlight correctly.\r\n\r\n<img width=\"956\" alt=\"image\" src=\"https://github.com/dandavison/delta/assets/410558/c3338c80-3955-45a1-94e9-1647e0f3a9da\">\r\n\r\nHighlighted in bat: \r\n<img width=\"958\" alt=\"image\" src=\"https://github.com/dandavison/delta/assets/410558/9530a3cd-8918-412c-b781-10bbf81e5612\">\r\n","createdAt":"2023-09-28T18:27:42Z","includesCreatedEdit":true,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/1546#issuecomment-1739814646","viewerDidAuthor":false},{"id":"IC_kwDOC4j8g85ns7E8","author":{"login":"pm0u"},"authorAssociation":"NONE","body":"Closing - this was because in my delta config I had overrode the foreground colors for `plus`/`plus-emph` - this needed to be `syntax` - woo!\r\n\r\nGreat tool!","createdAt":"2023-09-28T18:39:42Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/1546#issuecomment-1739829564","viewerDidAuthor":false},{"id":"IC_kwDOC4j8g85ns8M3","author":{"login":"pm0u"},"authorAssociation":"NONE","body":"Reopening as I am in fact having some issues still with Vue SFC - both in JS and CSS.. will update as I can, just tracking for now...","createdAt":"2023-09-28T18:42:37Z","includesCreatedEdit":true,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/1546#issuecomment-1739834167","viewerDidAuthor":false},{"id":"IC_kwDOC4j8g85ns-wx","author":{"login":"pm0u"},"authorAssociation":"NONE","body":"Ok I believe I've isolated this, and I think I have seen similar issues - \r\n\r\nIf the diff does not include the `<script>` tag then the JS is not correctly highlighted.\r\n\r\nWorking (contents from blank file)\r\n\r\n<img width=\"958\" alt=\"image\" src=\"https://github.com/dandavison/delta/assets/410558/54305df3-346e-4673-a91b-f46cba74f4f7\">\r\n\r\n```vue\r\n@@ -0,0 +1,15 @@\r\n+<template>\r\n+ <div class=\"className\" />\r\n+</template>\r\n+\r\n+<script setup>\r\n+import fs from 'node:fs'\r\n+\r\n+fs.readFile()\r\n+</script>\r\n+\r\n+<style>\r\n+.css {\r\n+ background: transparent;\r\n+}\r\n+</style>\r\n```\r\n\r\nNot working - added a console.log() far away from the script tag opening\r\n\r\n<img width=\"955\" alt=\"image\" src=\"https://github.com/dandavison/delta/assets/410558/85a38452-237c-4e0a-92c5-87484b3a3722\">\r\n\r\n```\r\n@@ -15,6 +15,8 @@ console.log('')\r\n console.log('')\r\n console.log('')\r\n console.log('')\r\n+console.log('')\r\n+\r\n console.log('')\r\n </script>\r\n ```\r\n \r\n Full file in bat: \r\n<img width=\"959\" alt=\"image\" src=\"https://github.com/dandavison/delta/assets/410558/72e4b11a-cf02-40af-9c39-40488c0d508c\">\r\n","createdAt":"2023-09-28T18:51:11Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/1546#issuecomment-1739844657","viewerDidAuthor":false},{"id":"IC_kwDOC4j8g85ns_YG","author":{"login":"pm0u"},"authorAssociation":"NONE","body":"related: https://github.com/dandavison/delta/issues/162\r\n\r\nUnsure if a similar workaround is available for Vue SFC","createdAt":"2023-09-28T18:53:19Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/1546#issuecomment-1739847174","viewerDidAuthor":false},{"id":"IC_kwDOC4j8g85ntEM_","author":{"login":"pm0u"},"authorAssociation":"NONE","body":"I do not believe a similar fix would work, as the issue is that the opening and closing tags are needed to understand what part of the file we are in (I think).\r\n\r\nCuriously when I force bat to only output lines that exclude the opening it still works - but perhaps it still parses the full file to infer syntax.\r\n\r\n<img width=\"957\" alt=\"image\" src=\"https://github.com/dandavison/delta/assets/410558/290493ff-1589-48ea-aee0-1ec571f085cd\">\r\n\r\n<img width=\"956\" alt=\"image\" src=\"https://github.com/dandavison/delta/assets/410558/69b6d1d0-1418-43e6-8719-2e1f2e5c39f7\">\r\n","createdAt":"2023-09-28T19:10:21Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/1546#issuecomment-1739866943","viewerDidAuthor":false},{"id":"IC_kwDOC4j8g85nywrl","author":{"login":"pm0u"},"authorAssociation":"NONE","body":"If I set the context to something huge like 200 then it highlights correctly as it manages to include the opening tag for script, style, etc. However this makes the diffs not very useful. It would be nice to have something like what bat must be doing where it parses the whole file and then displays the small section of it, although I realize this is relying on diff output","createdAt":"2023-09-29T19:04:40Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/1546#issuecomment-1741359845","viewerDidAuthor":false},{"id":"IC_kwDOC4j8g85xYYu6","author":{"login":"dandavison"},"authorAssociation":"OWNER","body":"Hi @pm0u, I think this is a dup of https://github.com/dandavison/delta/issues/117, right?\r\n\r\nThere is an easy-sounding fix that a couple of people have suggested and which someone should implement: add a `-U` option to delta, so that large context can be passed in, the syntax highlighting will probably be correct, and then delta can narrow the context down.","createdAt":"2024-01-20T18:16:28Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/1546#issuecomment-1902218170","viewerDidAuthor":true},{"id":"IC_kwDOC4j8g85xila5","author":{"login":"pm0u"},"authorAssociation":"NONE","body":"I think that would do it, yes. Although providing an arbitrary number could be challenging (or I would likely just pass a giant number like 99999) since the boundaries of different parts of the file would be hard to predict. In this case, something like a full file option could be more succint but either would work.","createdAt":"2024-01-22T21:56:16Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/1546#issuecomment-1904891577","viewerDidAuthor":false},{"id":"IC_kwDOC4j8g85xiniF","author":{"login":"dandavison"},"authorAssociation":"OWNER","body":"> something like a full file option could be more succint \r\n\r\nRight, but, this is out of delta's control. It is git that is generating the diff, and so it is git that controls how much context is supplied to delta. AFAIK git just offers\r\n\r\n```\r\n -U<n>, --unified=<n>\r\n Generate diffs with <n> lines of context instead of the usual three. Implies --patch.\r\n```\r\n\r\nso yes, passing a \"large\" integer is how we'd use it. E.g.\r\n\r\n```\r\ngit diff -U99999 | delta -U10\r\n```","createdAt":"2024-01-22T22:01:35Z","includesCreatedEdit":true,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/1546#issuecomment-1904900229","viewerDidAuthor":true},{"id":"IC_kwDOC4j8g85xi5w2","author":{"login":"pm0u"},"authorAssociation":"NONE","body":"Ah gotcha, it wasn't clear to me who was interpreting the flag in question. So then I assume the `-U` for delta then limits back down the context? I have confirmed in the past that a huge context (or one that spans the whole file) fixes the issue for me - but also made the diff quite useless as I'm sure you've found. The addition of a context for delta would fix this for me","createdAt":"2024-01-22T22:56:32Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/1546#issuecomment-1904974902","viewerDidAuthor":false}],"number":1546,"title":"🐛 Vue SFC syntax highlighting does not work if opening tag is not included in diff"},{"body":"Hi!\r\n\r\nI did a lot of Profile-Guided Optimization (PGO) benchmarks recently on different kinds of software - all currently available results are located at https://github.com/zamazan4ik/awesome-pgo . According to the tests, PGO usually helps with achieving better performance. That's why testing PGO would be a good idea for Delta. I did some benchmarks on my local machine and want to share my results.\r\n\r\n## Test environment\r\n\r\n* Apple Macbook M1 (full charge, AC connected)\r\n* macOS 13.4 Ventura\r\n* Rust: 1.72\r\n* Latest Delta from the `master` branch (commit `7375f7a165dabe430e12d531fedd84bb3a027c6b `)\r\n\r\n## Test workload\r\n\r\nAs a test scenario, I used `make benchmark` command. All runs are performed on the same hardware, operating system, and the same background workload (as much as I can guarantee ofc). The measurements were performed with `hyperfine`. The PGO optimization is done with [cargo-pgo](https://github.com/Kobzol/cargo-pgo).\r\n\r\n## Results\r\n\r\nHere are the results. Also, I posted Instrumentation results so you can estimate how `delta` slow in the Instrumentation mode.\r\n\r\nPGO optimized compared to Release builds:\r\n```\r\nhyperfine --warmup 10 --min-runs 20 'delta_pgo_optimized --no-gitconfig < /tmp/delta-benchmark-input.gitdiff > /dev/null' 'delta_release --no-gitconfig < /tmp/delta-benchmark-input.gitdiff > /dev/null'\r\nBenchmark 1: delta_pgo_optimized --no-gitconfig < /tmp/delta-benchmark-input.gitdiff > /dev/null\r\n Time (mean ± σ): 405.8 ms ± 2.1 ms [User: 396.2 ms, System: 38.4 ms]\r\n Range (min … max): 403.0 ms … 410.1 ms 20 runs\r\n\r\nBenchmark 2: delta_release --no-gitconfig < /tmp/delta-benchmark-input.gitdiff > /dev/null\r\n Time (mean ± σ): 413.0 ms ± 3.4 ms [User: 403.6 ms, System: 38.7 ms]\r\n Range (min … max): 409.7 ms … 422.6 ms 20 runs\r\n\r\nSummary\r\n delta_pgo_optimized --no-gitconfig < /tmp/delta-benchmark-input.gitdiff > /dev/null ran\r\n 1.02 ± 0.01 times faster than delta_release --no-gitconfig < /tmp/delta-benchmark-input.gitdiff > /dev/null\r\n```\r\n\r\nPGO-instrumented version:\r\n```\r\nLLVM_PROFILE_FILE=/Users/zamazan4ik/open_source/delta/target/pgo-profiles/delta_%m_%p.profraw hyperfine --warmup 10 --min-runs 20 'target/aarch64-apple-darwin/release/delta --no-gitconfig < /tmp/delta-benchmark-input.gitdiff > /dev/null'\r\nBenchmark 1: target/aarch64-apple-darwin/release/delta --no-gitconfig < /tmp/delta-benchmark-input.gitdiff > /dev/null\r\n Time (mean ± σ): 575.4 ms ± 4.7 ms [User: 562.2 ms, System: 44.1 ms]\r\n Range (min … max): 569.0 ms … 588.7 ms 20 runs\r\n```\r\n\r\nSo, PGO makes some small improvements at least in the project's benchmarks. But getting a \"free\" 1-2% performance is not a bad thing after all :)\r\n\r\n## Possible further steps\r\n\r\nI can suggest to do the following things:\r\n* Add a note to the Delta documentation (maybe somewhere in the README file) about building with PGO if you think it's worth it for the project. In this case, users and maintainers who build their own Delta binaries will be aware of PGO as an additional way to optimize the project\r\n* Try to use LLVM BOLT in addition to PGO. However, I do not expect huge improvements from BOLT in this project","comments":[],"number":1540,"title":"Profile-Guided Optimization (PGO) improvements"},{"body":"- [x]\r\n> renamed: something.ps1 > somethingelse.ps1\r\n- [x]\r\n\r\n\r\nSmall bug - renamed files are hyperlinked for both old file (wrong, the file very likely doesn't exist) and new file (correct).","comments":[],"number":1534,"title":"🐛 Renamed file is displayed as a hyperlink"},{"body":"Would be nice if `git config --global delta.icons.wrap-right-prefix-symbol \"\"` and similar settings stopped a symbol from showing. Instead, an error is thrown:\r\n> Invalid value for wrap-right-prefix-symbol, display width of \"\" must be 1 but is 0\r\n\r\nAlll of the wrapping icons bring no value to me and only take space as I have line numbers enabled and can clearly see that the line continues from that.\r\n\r\nThe closest workaround I found was setting it to space, but that takes space, still. I also tried zero-width space, but that caused this:\r\n\r\nAnd e.g. ␀ (null) character but that gets printed.\r\n\r\nI don't see any reason for that error to be thrown. Maybe some internal implementation seeing how zero width breaks it.","comments":[],"number":1533,"title":"🚀 Add a way to skip printing symbols altogether"},{"body":"Similar to #1171. It seems the blame parser also isn’t ready for lines with no commit information at the start, from the [`-b` option](https://git-scm.com/docs/git-blame#Documentation/git-blame.txt--b) / `blankBoundary` configuration option.\r\n\r\nHere’s an example from the Django repository, providing `--since` so that there’s a boundary. First, the following is correctly parsed with `delta`:\r\n\r\n```\r\n$ git --no-pager blame -L 1,1 --since yesterday django/utils/html.py\r\n^facc153af7 (sarahboyce 2023-04-06 19:40:14 +0200 1) \"\"\"HTML utilities suitable for global use.\"\"\"\r\n```\r\n\r\n…which looks like:\r\n\r\n```\r\n$ git blame -L 1,1 --since yesterday django/utils/html.py\r\n4 months ago sarahboyce ^facc153af7│ 1 │ \"\"\"HTML utilities suitable for global use.\"\"\"\r\n```\r\n\r\nSecond, adding `-b` changes Git to not output any commit information for those beyond the boundary (previously indicated by the `^`):\r\n\r\n```\r\n$ git --no-pager blame -L 1,1 --since yesterday -b django/utils/html.py\r\n (sarahboyce 2023-04-06 19:40:14 +0200 1) \"\"\"HTML utilities suitable for global use.\"\"\"\r\n```\r\n\r\n…which delta fails to highlight:\r\n\r\n```\r\n$ git blame -L 1,1 --since yesterday -b django/utils/html.py\r\n (sarahboyce 2023-04-06 19:40:14 +0200 1) \"\"\"HTML utilities suitable for global use.\"\"\"\r\n```\r\n\r\n(This is a shame because the oh-my-zsh aliases set `-b` by default: https://github.com/ohmyzsh/ohmyzsh/blob/03a0d5bbaedc732436b5c67b166cde954817cc2f/plugins/git/git.plugin.zsh#L118 . Though I just made a PR to remove that: https://github.com/ohmyzsh/ohmyzsh/pull/11864 .)\r\n\r\n- [x] Please include the raw text output from git, so that we can reproduce the problem.\r\n (You can use `git --no-pager` to produce the raw text output.)\r\n- [-] A screenshot of Delta's output is often helpful also.\r\n\r\nThanks for filing a Delta bug report!\r\n","comments":[],"number":1530,"title":"🐛 blame parser fails with `-b` / `blankBoundary`"},{"body":"If I have a set of files where the only changes are line break additions/subtractions, `delta` doesn't render the diff correctly.\r\n\r\nFor example, given these two files:\r\n\r\n```sh\r\n# file1.txt\r\nsome\r\ntext\r\n```\r\n\r\n```sh\r\n# file2.txt\r\nsome\r\n\r\ntext\r\n```\r\n\r\nWhen I run `delta file1 file2`, I get this output:\r\n\r\n\r\n\r\nIf I invert the file order and run `delta file2 file1`, I get the same output:\r\n\r\n\r\n\r\n\r\nNeither output shows any colored indications of line breaks that were added or removed.\r\n\r\nI also see this issue with `git diff` when `delta` is configured as my `diff` tool for `git`.","comments":[{"id":"IC_kwDOC4j8g85tpKd-","author":{"login":"ggrzybow"},"authorAssociation":"NONE","body":"Related: #1271, #1038.\r\n\r\n#522 is vaguely related.","createdAt":"2023-12-04T21:28:17Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/1528#issuecomment-1839507326","viewerDidAuthor":false}],"number":1528,"title":"🐛 Line break only changes aren't shown correctly "},{"body":"Is it the default or a bug?\r\n\r\n\r\n","comments":[],"number":1526,"title":"🐛 Long lines are not wrapped"},{"body":"<details>\r\n<summary>Example git graph and diffs</summary>\r\n\r\n```\r\n* Merge branch 'branch' (HEAD -> main)\r\n|\\ diff --cc file\r\n| | index 5716ca5,7601807..d90bda0\r\n| | --- a/file\r\n| | +++ b/file\r\n| | @@@ -1,1 -1,1 +1,1 @@@\r\n| | - bar\r\n| | -baz\r\n| | ++quux\r\n| |\r\n| * Update to baz\r\n| | diff --git a/file b/file\r\n| | index 257cc56..7601807 100644\r\n| | --- a/file\r\n| | +++ b/file\r\n| | @@ -1 +1 @@\r\n| | -foo\r\n| | +baz\r\n| |\r\n* | Update to bar\r\n|/ diff --git a/file b/file\r\n| index 257cc56..5716ca5 100644\r\n| --- a/file\r\n| +++ b/file\r\n| @@ -1 +1 @@\r\n| -foo\r\n| +bar\r\n|\r\n* Add file\r\n| diff --git a/file b/file\r\n| new file mode 100644\r\n| index 0000000..257cc56\r\n| --- /dev/null\r\n| +++ b/file\r\n| @@ -0,0 +1 @@\r\n| +foo\r\n```\r\n</details>\r\n\r\nDuring the conflict resolution for the merge commit, delta shows the handy split ancestor view with both changes to `file`:\r\n\r\n\r\n\r\nOnce committed, showing the commit in one-column mode retains git's own two-column `+`/`-` indicators, which works ok:\r\n\r\n\r\n\r\nBut in two-column mode, there's no indication of which ancestor each line came from, and the line numbers are misleading:\r\n\r\n","comments":[],"number":1524,"title":"🐛 Ambiguous display of resolved merge conflicts in side-by-side view"},{"body":"Hey,\r\n\r\nHyperlinks are great but I don't like the style. How I can customise them?","comments":[],"number":1523,"title":"🚀 Ability to customise style for hyperlinks"},{"body":"Is there a reason for this?\r\n\r\n\r\n","comments":[],"number":1521,"title":"🐛 delta -h contains ANSI codes"},{"body":"same text in delta and vim, let me know what more information you need to help you with this\r\n\r\n\r\n\r\n\r\n\r\n","comments":[],"number":1520,"title":"🐛 wrongly tabulated text"},{"body":"\r\n\r\n\r\n\r\nconfig:\r\n\r\n```\r\ndelta \\\r\n\t--line-numbers \\\r\n\t--line-numbers-left-style '#3a3a3a' \\\r\n\t--line-numbers-right-style '#3a3a3a' \\\r\n\t--file-modified-label \"modified:\" \\\r\n\t--diff-so-fancy \\\r\n\t--file-style '#909000' \\\r\n\t--file-decoration-style 'ol #404000' \\\r\n\t--hunk-header-decoration-style '' \\\r\n\t--hunk-header-style '' \\\r\n\t--minus-emph-style '#c6c6c6 #560000' \\\r\n\t--plus-emph-style '#c6c6c6 #004500' \\\r\n\t--right-arrow '…'\r\n```\r\n\r\n","comments":[],"number":1519,"title":"🐛 Missing line number at first line of hunk"},{"body":"I can set --file-modified-label but can't seem to find a way to color it\r\n\r\n\r\n\r\n","comments":[],"number":1518,"title":"🚀 Option to color --file-modified-label"},{"body":"Hi, thanks for the software.\r\n\r\nI'm considering moving from diff-so-fancy to delta and I have played around to get the colors I want to have\r\n\r\nI notice that an extra separation line is displayed before the hunk, is there a way to remove it?\r\n\r\n\r\n","comments":[],"number":1517,"title":"🚀Option to remove line at top of hunk"},{"body":"## Description\r\nOutput of \r\n```\r\nls | delta --paging=auto --pager=\"less --version\" | cat\r\n```\r\nis less's version output.\r\n\r\nBut the output is normal if the command is\r\n```\r\nls | delta --paging=never --pager=\"less --version\" | cat\r\n```\r\n\r\n## Expectation\r\n`--paging=auto` should not page if the output is not a TTY. This is very standard for many tools, e.g. `grep --color=auto` does not color when non-TTY, same for `fd`, git does not use pager when non-TTY. I understand the auto probably factors in input line count, but I think it should factor the output as well. Or at least describe explicitly what it does in docs. Because the current state is very misleading and the only implicit indication of what `auto` really does was https://dandavison.github.io/delta/environment-variables.html#pager-environment-variables.\r\n\r\nAnyway, thanks for making delta! Despite this small problem, it works very well and I love it!","comments":[],"number":1515,"title":"🐛 --paging=auto still pages even when piping to non-TTY"},{"body":"Is there a way for delta to ignore changes ? \r\n\r\nI'm looking on a similar behavior like diff with flag `--ignore-matching-lines`","comments":[{"id":"IC_kwDOC4j8g85j5wAd","author":{"login":"dandavison"},"authorAssociation":"OWNER","body":"Hi @jcgutier, how about\r\n\r\n```\r\ngit diff --no-index --ignore-matching-lines file_a file_b | delta\r\n```\r\n\r\nor if you're using delta with git then simply\r\n\r\n```\r\ngit diff --ignore-matching-lines | delta\r\n```\r\n","createdAt":"2023-08-12T20:13:56Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/1506#issuecomment-1676083229","viewerDidAuthor":true},{"id":"IC_kwDOC4j8g85kHP17","author":{"login":"jcgutier"},"authorAssociation":"NONE","body":"Hello @dandavison thanks for your reply. \r\n\r\nI'm using the delta CLI in standalone mode. \r\n\r\nMy main goal was to see the differences from `kubectl diff` with a pipe to delta. And because kubectl shows some metadata changes that are not relevant for me I was trying to ignore those changes.\r\n\r\nlike I would like to ignore changes for generation, for example:\r\n\r\n","createdAt":"2023-08-15T21:11:58Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/1506#issuecomment-1679621499","viewerDidAuthor":false}],"number":1506,"title":"🚀 Is there a way for delta to ignore changes ? Like --ignore-matching-lines from diff"},{"body":"## Reproduction steps\r\n```sh\r\necho foo > a.txt && echo bar > b.txt\r\ngit add . && git commit -m temp\r\nrm a.txt && chmod +x b.txt\r\ngit diff\r\n```\r\n\r\nOutput:\r\n\r\n \r\n`a.txt`'s output is being displayed after the mode change of `b.txt`\r\n\r\nRaw git output:\r\n```\r\ndiff --git a/a.txt b/a.txt\r\ndeleted file mode 100644\r\nindex 257cc56..0000000\r\n--- a/a.txt\r\n+++ /dev/null\r\n@@ -1 +0,0 @@\r\n-foo\r\ndiff --git a/b.txt b/b.txt\r\nold mode 100644\r\nnew mode 100755\r\n```\r\n\r\nDelta's config:\r\n```\r\n commit-style = raw\r\n file-style = blue\r\n hunk-header-style = syntax\r\n minus-style = normal \"#3f0001\"\r\n minus-non-emph-style = normal \"#3f0001\"\r\n minus-emph-style = normal \"#901011\"\r\n minus-empty-line-marker-style = normal \"#3f0001\"\r\n zero-style = syntax\r\n plus-style = syntax \"#002800\"\r\n plus-non-emph-style = syntax \"#002800\"\r\n plus-emph-style = syntax \"#006000\"\r\n plus-empty-line-marker-style = normal \"#002800\"\r\n grep-file-style = purple\r\n grep-line-number-style = green\r\n whitespace-error-style = reverse purple\r\n blame-palette = #000000 #222222 #444444\r\n true-color = true\r\n file-added-label = 'added:'\r\n file-modified-label = ''\r\n file-removed-label = 'removed:'\r\n file-renamed-label = 'renamed:'\r\n right-arrow = '⟶ '\r\n hyperlinks = false\r\n inspect-raw-lines = true\r\n keep-plus-minus-markers = false\r\n line-numbers = false\r\n max-line-distance = 0.6\r\n max-line-length = 512\r\n diff-stat-align-width = 48\r\n line-fill-method = ansi\r\n navigate = false\r\n navigate-regex = \r\n pager = none\r\n paging = auto\r\n side-by-side = false\r\n syntax-theme = Monokai Extended\r\n width = 163\r\n tabs = 8\r\n word-diff-regex = '\\w+'\r\n```","comments":[],"number":1504,"title":"🐛 Mode changes are being printed in between the contents of other file changes. (Delta v0.16.5)"},{"body":"Hi,\r\n\r\nUsing `--navigate`, I'd like for `n` and `N` to bring me to the next and previous files respectively. Would you accept such a feature? If it is yes, what shape should it take: a flag, a feature, something else?\r\n\r\nThat feature would only apply when `--navigate-regex` is not used, ie when the regex is the default value.\r\n\r\nHere is a minimal patch that implements the change without looking at any flag. The constant false should be replaced by a conditional from flags or such. I've not modified the value of `hunk_label` as it gets passed after that to the config (and apparently is used elsewhere).\r\n\r\n```diff\r\ndiff --git a/src/config.rs b/src/config.rs\r\nindex cab21eb..ec2d064 100644\r\n--- a/src/config.rs\r\n+++ b/src/config.rs\r\n@@ -239,7 +239,7 @@ impl From<cli::Opt> for Config {\r\n &file_added_label,\r\n &file_removed_label,\r\n &file_renamed_label,\r\n- &hunk_label,\r\n+ if false { &hunk_label } else { \"\" },\r\n ))\r\n } else {\r\n opt.navigate_regex\r\n```\r\n\r\nBy the way, thanks for the `Makefile`. First change to a Rust project and I had the nice surprise of it compiling fully with a `make` which I typed out of habit. I did not read any doc. So great first contributor experience!","comments":[],"number":1500,"title":"🚀 Option to skip hunks when `--navigate`-ing"},{"body":"Currently, 3 way merge conflicts are rendered like this in side-by-side mode:\r\n\r\n\r\n\r\nI think, that it would be really cool if we could show a 3 way merge side-by-side in 3 columns instead. Something along the lines of this:\r\n```\r\n─────────────────────────────────────────────────────────────────────────────────────────────────\r\n• somefile.md:1:\r\n─────────────────────────────────────────────────────────────────────────────────────────────────\r\n 1│ HERE BE BEFORE 1│ HERE BE BEFORE 1│ HERE BE BEFORE\r\n 2│ 2│ 2│\r\n▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼\r\n ┌──────┐ ┌──────────┐ ┌──────────┐\r\n │ HEAD │ <--- │ ancestor │ ---> │ branch/B │\r\n └──────┘ └──────────┘ └──────────┘\r\n 3│ This is some file 3│ This is some file │\r\n │ 4│ with many lines in it. │\r\n │ 5│ That's pretty cool │\r\n │ 6│ innit? │\r\n 4│ that can't be merged cleanly. │ 3│ THIS IS SOME FILE\r\n 5│ I'm forced to resolve │ 4│ WITH MANY LINES IN IT!\r\n 6│ such conflicts routinely! │ 5│ THAT'S PRETTY COOL\r\n │ │ 6│ INNIT?!?!\r\n▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲\r\n 7│ 7│ 7│\r\n 8│ HERE BE AFTER 8│ HERE BE AFTER 8│ HERE BE AFTER\r\n```\r\n\r\nP.S. while writing this feature proposal, I've noticed that the line numbers are actually wrong in the current implementation (it counts the lines twice for `ancestor ⟶ HEAD` and `ancestor ⟶ branch/B` cases). Also, an already resolved merge commit currently looks kind of broken in `side-by-side` mode.","comments":[{"id":"IC_kwDOC4j8g86HbJdM","author":{"login":"searleser97"},"authorAssociation":"NONE","body":"How do you actually get to see this view ? what git command do you run ? thanks","createdAt":"2024-08-06T19:56:43Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/1499#issuecomment-2272040780","viewerDidAuthor":false},{"id":"IC_kwDOC4j8g86HbNH9","author":{"login":"dandavison"},"authorAssociation":"OWNER","body":"Hi @searleser97, if you have a merge conflict (e.g. from a `git merge`, or `git pull`, or `git cherry-pick` or `git rebase` etc) then `git diff` will show this view if you have delta configured as in the delta README. (Or you can do `git diff | delta`).\r\n\r\nTo enable `side-by-side` mode see the delta docs.","createdAt":"2024-08-06T20:05:08Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/1499#issuecomment-2272055805","viewerDidAuthor":true}],"number":1499,"title":"🚀 3 way side-by-side merge conflict"},{"body":"I'm having a weird issue where the file decorations are not detecting the terminal width properly.\r\n\r\n* without any zsh configuration loaded (`zsh -f`) it renders fine\r\n* renders in bash fine\r\n* does not render with plugins loaded\r\n\r\nHowever, I'm not sure where to start debugging this. What terminal configuration options could cause this and where could I find them?\r\n\r\nHere's a screenshot of what I'm seeing:\r\n\r\n<img width=\"1477\" alt=\"image\" src=\"https://github.com/dandavison/delta/assets/150855/be8fb8a7-9300-46f7-80e0-a0c174475206\">\r\n\r\n`git --no-pager show`:\r\n\r\n```\r\ncommit c1f4a048806abc811f354a48a9b00d2435a06c6c (HEAD -> master)\r\nAuthor: Michael Bianco <email@email.com>\r\nDate: Thu Jul 27 13:36:35 2023 -0600\r\n\r\n helper to expand ts types\r\n\r\ndiff --git a/.node-functions b/.node-functions\r\nindex 638ef76..439eeaf 100644\r\n--- a/.node-functions\r\n+++ b/.node-functions\r\n@@ -4,6 +4,12 @@\r\n # these helpers make using it more sane\r\n ###########################\r\n\r\n+# https://github.com/microsoft/vscode/issues/94679\r\n+vscode-fix-typescript-truncation() {\r\n+ local file=\"/Applications/Visual Studio Code.app/Contents/Resources/app/extensions/node_modules/typescript/lib/tsserver.js\"\r\n+ sed -i '' 's/defaultMaximumTruncationLength = 160;/defaultMaximumTruncationLength = 800;/g' \"$file\"\r\n+}\r\n+\r\n # ts-node execution\r\n tsn() {\r\n if ! npm list tsconfig-paths &>/dev/null; then\r\n```","comments":[],"number":1492,"title":"🐛 file decorations rendering incorrect in zsh"},{"body":"I am trying ripgrep in combination with delta based on your recent post in the ripgrep thread.\r\n\r\nI get this:\r\n\r\n```\r\nthread 'main' panicked at 'byte index 63 is out of bounds of `https://en.wikipedia.org/w/api.php?action=help&modules=query\r\n\r\n`', src/handlers/grep.rs:358:38\r\nstack backtrace:\r\n```\r\n\r\nReproduce:\r\n\r\n```\r\ncat x | delta\r\n```\r\n\r\nx\r\n\r\n```\r\n{\"type\":\"match\",\"data\":{\"path\":{\"text\":\"TODO\"},\"lines\":{\"text\":\"https://en.wikipedia.org/w/api.php?action=help&modules=query\\n\\n\\n\"},\"line_number\":4,\"absolute_offset\":148,\"submatches\":[{\"match\":{\"text\":\"\\n\\n\\n\"},\"start\":60,\"end\":63}]}}\r\n```\r\n\r\nIf I encode the `&` in the URL, it works.\r\n\r\nI'm not sure if the bug is in delta or grip.\r\n\r\nThis is with delta 0.16.5.","comments":[{"id":"IC_kwDOC4j8g85iOvN0","author":{"login":"dandavison"},"authorAssociation":"OWNER","body":"Thanks @tbm! This must be a delta bug. Your reproduction example is very helpful.","createdAt":"2023-07-24T14:30:36Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/1487#issuecomment-1648030580","viewerDidAuthor":true},{"id":"IC_kwDOC4j8g85ixwoL","author":{"login":"ippsav"},"authorAssociation":"CONTRIBUTOR","body":"I've been tinkering with this issue for a couple of minutes, i ll be making a pr for this soon to handle this issue","createdAt":"2023-07-30T16:15:31Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/1487#issuecomment-1657211403","viewerDidAuthor":false},{"id":"IC_kwDOC4j8g85ixz7u","author":{"login":"ippsav"},"authorAssociation":"CONTRIBUTOR","body":"@dandavison pr ready for review ! #1496 ","createdAt":"2023-07-30T17:23:46Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/1487#issuecomment-1657224942","viewerDidAuthor":false},{"id":"IC_kwDOC4j8g85jWhRf","author":{"login":"dandavison"},"authorAssociation":"OWNER","body":"@tbm @ippsav what's an example of making `rg` product output with multiple trailing newlines like this:\r\n\r\n```\r\n{\"text\":\"https://en.wikipedia.org/w/api.php?action=help&modules=query\\n\\n\\n\"}\r\n```\r\n\r\nDoes it require using the `--multiline` flag (`-U`)?\r\n\r\nFor example with input file\r\n\r\n```\r\n1\r\n\r\n2\r\n```\r\n\r\nI can reproduce this:\r\n\r\n```\r\nrg --multiline --json '1\\n\\n' /tmp/in\r\n```\r\n\r\nand that crashes delta.\r\n\r\n@ippsav is it usage of `--multiline` that your fix is addressing? I'm really sorry I've been so slow here; I didn't find this issue easy to think about and was low on time.","createdAt":"2023-08-06T12:45:24Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/1487#issuecomment-1666847839","viewerDidAuthor":true},{"id":"IC_kwDOC4j8g85jWhy3","author":{"login":"tbm"},"authorAssociation":"NONE","body":"> Does it require using the --multiline flag (-U)?\r\n\r\nSorry, I forgot to mention it. Yes, it requires `-U`.\r\n\r\nExample:\r\n\r\n```\r\n65569:tbm@jirafa: ~/tmp/wiktionary] rg -U \"\\n\\n\" xt\r\nhread 'main' panicked at 'byte index 47 is out of bounds of `https://dumps.wikimedia.org/backup-index.html\r\n`', src/handlers/grep.rs:358:38\r\nnote: run with `RUST_BACKTRACE=1` environment variable to display a backtrace\r\nx \r\nzsh: exit 101\r\n65570:tbm@jirafa: ~/tmp/wiktionary] cat x\r\n\r\nhttps://dumps.wikimedia.org/backup-index.html\r\n\r\n```","createdAt":"2023-08-06T12:52:38Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/1487#issuecomment-1666849975","viewerDidAuthor":false},{"id":"IC_kwDOC4j8g85jWh9o","author":{"login":"dandavison"},"authorAssociation":"OWNER","body":"Thanks!\r\n\r\n> If I encode the & in the URL, it works.\r\n\r\nHm, I'm finding that your example crashes delta even with the two `?` deleted; is it possible that when you experimented with encoding the `&` you also changed something about the presence of (escaped) newline characters in the `rg` output?","createdAt":"2023-08-06T12:55:11Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/1487#issuecomment-1666850664","viewerDidAuthor":true},{"id":"IC_kwDOC4j8g85jWi6M","author":{"login":"tbm"},"authorAssociation":"NONE","body":"I think you're right. See the latest example I just posted. There the file contains a URL but not one that needs to be escaped.\r\n\r\nSo I think the title is wrong. It's related to newlines.","createdAt":"2023-08-06T13:07:42Z","includesCreatedEdit":true,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/1487#issuecomment-1666854540","viewerDidAuthor":false},{"id":"IC_kwDOC4j8g85jWjG_","author":{"login":"dandavison"},"authorAssociation":"OWNER","body":"No worries! That didn't lead to my confusion -- I'd already learned from @ippsav that it was `\\n` rather than the `?` but I was still finding the bug confusing to understand!","createdAt":"2023-08-06T13:10:37Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/1487#issuecomment-1666855359","viewerDidAuthor":true},{"id":"IC_kwDOC4j8g85j6F7J","author":{"login":"dandavison"},"authorAssociation":"OWNER","body":"For my future reference: a simple reproduction of the bug is\r\n\r\n```\r\necho bar | rg -U --json 'bar\\n'\r\n```\r\n\r\n```json\r\n{\r\n \"type\": \"match\",\r\n \"data\": {\r\n \"path\": {\r\n \"text\": \"<stdin>\"\r\n },\r\n \"lines\": {\r\n \"text\": \"bar\\n\"\r\n },\r\n \"line_number\": 1,\r\n \"absolute_offset\": 0,\r\n \"submatches\": [\r\n {\r\n \"match\": {\r\n \"text\": \"bar\\n\"\r\n },\r\n \"start\": 0,\r\n \"end\": 4\r\n }\r\n ]\r\n }\r\n}\r\n```\r\n\r\n<img width=\"619\" alt=\"image\" src=\"https://github.com/dandavison/delta/assets/52205/fd8eeebe-d2ef-4489-aa3e-daaa391728cc\">\r\n\r\n\r\nMore complex examples arguably aren't highlighted correctly by delta, e.g.\r\n\r\n```\r\necho 'bar\\nbar\\n' | rg -U --json 'bar\\n'\r\n```\r\n\r\n```json\r\n{\r\n \"type\": \"match\",\r\n \"data\": {\r\n \"path\": {\r\n \"text\": \"<stdin>\"\r\n },\r\n \"lines\": {\r\n \"text\": \"bar\\nbar\\n\"\r\n },\r\n \"line_number\": 1,\r\n \"absolute_offset\": 0,\r\n \"submatches\": [\r\n {\r\n \"match\": {\r\n \"text\": \"bar\\n\"\r\n },\r\n \"start\": 0,\r\n \"end\": 4\r\n },\r\n {\r\n \"match\": {\r\n \"text\": \"bar\\n\"\r\n },\r\n \"start\": 4,\r\n \"end\": 8\r\n }\r\n ]\r\n }\r\n}\r\n```\r\n\r\n<img width=\"699\" alt=\"image\" src=\"https://github.com/dandavison/delta/assets/52205/146f7274-eeeb-4cd2-a1f0-cc5bdd5c7494\">\r\n\r\n\r\n(These are on branch https://github.com/dandavison/delta/pull/1496)","createdAt":"2023-08-13T01:17:57Z","includesCreatedEdit":true,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/1487#issuecomment-1676173001","viewerDidAuthor":true}],"number":1487,"title":"🐛 `is out of bounds of` due to newline characters in ripgrep output"},{"body":"Hi Dan, first off thanks so much for making Delta. Switched from diff-so-fancy 2 months ago and never looked back!\r\n\r\nI make use of the hyperlink feature a lot. I think one way we can enhance it is to support pull request links in the commit log. When you merge PRs on Github, you may have noticed it'll append `(#pr-number)` at the end of the commit message. Maybe delta can hyperlink those?\r\n\r\n<img width=\"909\" alt=\"Screenshot 2023-07-20 at 11 23 03 AM\" src=\"https://github.com/dandavison/delta/assets/1967248/98828122-b9d2-4be7-8ac4-dfef1abdc5ec\">\r\n","comments":[{"id":"IC_kwDOC4j8g85iBuHN","author":{"login":"dandavison"},"authorAssociation":"OWNER","body":"Hi @PatrickF1, that seems like a great idea and very doable. If you have any interest in implementing it then don't hold back!","createdAt":"2023-07-20T21:14:28Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/1482#issuecomment-1644618189","viewerDidAuthor":true},{"id":"IC_kwDOC4j8g85keO1i","author":{"login":"PatrickF1"},"authorAssociation":"NONE","body":"Hi Dan, happy to take a stab at it. Could you link me to where the feature for hyperlinked sha's is limited?","createdAt":"2023-08-21T05:03:35Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/1482#issuecomment-1685646690","viewerDidAuthor":false},{"id":"IC_kwDOC4j8g85l8pyb","author":{"login":"dandavison"},"authorAssociation":"OWNER","body":"Hi Patrick, sorry for the slow reply, I was offline. Commit SHAs are hyperlinked here: https://github.com/dandavison/delta/blob/7375f7a165dabe430e12d531fedd84bb3a027c6b/src/handlers/commit_meta.rs#L37","createdAt":"2023-09-07T15:51:31Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/1482#issuecomment-1710398619","viewerDidAuthor":true},{"id":"IC_kwDOC4j8g85vnY-a","author":{"login":"mvdan"},"authorAssociation":"NONE","body":"The client can't really tell if `#123` is an issue or a pull request, so I think it should linkify all of them as issues, and rely on the server to redirect if the number is a pull request. This would allow supporting commit message lines like `Fixes #123` too.\r\n\r\nFor example, note how `https://github.com/dandavison/delta/issues/1573` gets redirected to `https://github.com/dandavison/delta/pull/1573`.","createdAt":"2023-12-30T20:12:07Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/1482#issuecomment-1872596890","viewerDidAuthor":false},{"id":"IC_kwDOC4j8g85vnZav","author":{"login":"PatrickF1"},"authorAssociation":"NONE","body":"Good point. I know GitHub handles redirects well.\r\n\r\nOn Sat, Dec 30, 2023 at 12:12 PM Daniel Martí ***@***.***>\r\nwrote:\r\n\r\n> The client can't really tell if #123 is an issue or a pull request, so I\r\n> think it should linkify all of them as issues, and rely on the server to\r\n> redirect if the number is a pull request. This would allow supporting\r\n> commit message lines like Fixes #123 too.\r\n>\r\n> For example, note how https://github.com/dandavison/delta/issues/1573\r\n> gets redirected to https://github.com/dandavison/delta/pull/1573.\r\n>\r\n> —\r\n> Reply to this email directly, view it on GitHub\r\n> <https://github.com/dandavison/delta/issues/1482#issuecomment-1872596890>,\r\n> or unsubscribe\r\n> <https://github.com/notifications/unsubscribe-auth/AAPAJECTGG7OCHKTDYXQ4YTYMBYSDAVCNFSM6AAAAAA2RZ664WVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQNZSGU4TMOBZGA>\r\n> .\r\n> You are receiving this because you were mentioned.Message ID:\r\n> ***@***.***>\r\n>\r\n","createdAt":"2023-12-30T20:21:49Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/1482#issuecomment-1872598703","viewerDidAuthor":false},{"id":"IC_kwDOC4j8g85vnZqR","author":{"login":"PatrickF1"},"authorAssociation":"NONE","body":"As a slight optimization, we could probably send (#number) to /pull and #number to /issues, since most of the time, pull requests are added by GitHub in the commit with parens around them.\r\n\r\nBtw, in case anyone is waiting on me to implement this, I no longer plan on doing it. Learning Rust proved to be too big of a hurdle to jump. I hope someone else will take this on, thanks!","createdAt":"2023-12-30T20:26:22Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/1482#issuecomment-1872599697","viewerDidAuthor":false}],"number":1482,"title":"🚀 Hyperlink pull request and issue numbers"},{"body":"Example diff:\r\n\r\n```diff\r\n❯ diff -u {a,b}.sql\r\n--- a.sql 2023-06-28 18:25:39.540877213 +0200\r\n+++ b.sql 2023-06-28 18:25:57.079964060 +0200\r\n@@ -3,7 +3,7 @@\r\n --\r\n\r\n -- Dumped from database version 14.8 (Debian 14.8-1.pgdg120+1)\r\n--- Dumped by pg_dump version 14.8\r\n+-- Dumped by pg_dump version 15.3\r\n\r\n SET statement_timeout = 0;\r\n SET lock_timeout = 0;\r\n@@ -17,6 +17,23 @@\r\n SET row_security = off;\r\n\r\n --\r\n+-- Name: public; Type: SCHEMA; Schema: -; Owner: postgres\r\n+--\r\n+\r\n+-- *not* creating schema, since initdb creates it\r\n+\r\n+\r\n+ALTER SCHEMA public OWNER TO postgres;\r\n+\r\n+--\r\n+-- Name: SCHEMA public; Type: ACL; Schema: -; Owner: postgres\r\n+--\r\n+\r\n+REVOKE USAGE ON SCHEMA public FROM PUBLIC;\r\n+GRANT ALL ON SCHEMA public TO PUBLIC;\r\n+\r\n+\r\n+--\r\n -- PostgreSQL database dump complete\r\n --\r\n```\r\n\r\nIf passed to delta 0.16.5, the following output is produced:\r\n\r\n\r\n\r\nAs you can see, the first hunk simply disappears in delta's output.\r\n\r\nThe example files were produced by starting an empty PostgreSQL database (e.g., using Docker), and using pg_dump 14 and pg_dump 15, respectively, to dump that database, as pg_dump watermarks output files with its version.\r\n\r\n- [x] Please include the raw text output from git, so that we can reproduce the problem.\r\n (You can use `git --no-pager` to produce the raw text output.)\r\n- [x] A screenshot of Delta's output is often helpful also.\r\n\r\nThanks for filing a Delta bug report!\r\n","comments":[{"id":"IC_kwDOC4j8g85h1iYF","author":{"login":"dandavison"},"authorAssociation":"OWNER","body":"Thanks @sybereal! This is #209, but I'll close that one since your report is much better. We should fix this.","createdAt":"2023-07-19T05:16:55Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/1462#issuecomment-1641424389","viewerDidAuthor":true}],"number":1462,"title":"🐛 Lines starting with dashes disappear from highlighted output"},{"body":"When trying to see the evaluated config values, I'm not seeing the entire configuration as defined in my `~/.gitconfig`, namely the `hunk-header-*` properties.\r\n\r\nI'm unsure if other properties are missing, but these definitely are missing.\r\n\r\n\r\n","comments":[],"number":1458,"title":"🐛 Entire config not shown with `delta --show-config`"},{"body":"Not sure how to really indicate whether this is a bug, or a feature request.\r\n\r\nI've set `file-style=omit` because I prefer to use `hunk-header-*` settings, however git submodules are completely without any metadata to indicate what is going on with the SHA changes.\r\n\r\nIdeally with the `hunk-header` it'd still show the project name (ie, `golden-hammer-services` as an example listed below in the raw output)\r\n\r\nRaw Git output:\r\n```\r\ndiff --git a/golden-hammer-services b/golden-hammer-services\r\nindex bde0d96..1eddb35 160000\r\n--- a/golden-hammer-services\r\n+++ b/golden-hammer-services\r\n@@ -1 +1 @@\r\n-Subproject commit bde0d96ce720a77dc433f5f30e579da3c319f228\r\n+Subproject commit 1eddb3554c74b9e1b92237c7bf132a44cc10b2f4-dirty\r\ndiff --git a/golden-hammer-shared b/golden-hammer-shared\r\nindex 06f838f..5e12355 160000\r\n--- a/golden-hammer-shared\r\n+++ b/golden-hammer-shared\r\n@@ -1 +1 @@\r\n-Subproject commit 06f838f71e788b237a0cbfc6e60347b1d1536b9f\r\n+Subproject commit 5e1235523ccb71c643c83294333ba349d28d56bd-dirty\r\ndiff --git a/golden-hammer-ui b/golden-hammer-ui\r\nindex 6d4d420..ce896bf 160000\r\n--- a/golden-hammer-ui\r\n+++ b/golden-hammer-ui\r\n@@ -1 +1 @@\r\n-Subproject commit 6d4d420e77a53d33674d2f2e29760dc7a93ca96c\r\n+Subproject commit ce896bf290cc14316052362b5bf05f08f052ebf2-dirty\r\n```\r\n\r\nScreenshot with `file-style=omit`:\r\n\r\n\r\nScreenshot with `file-style` as default:\r\n\r\n","comments":[{"id":"IC_kwDOC4j8g86QDOmD","author":{"login":"ulidtko"},"authorAssociation":"NONE","body":"Also hit this.\r\n\r\nSeeing the submodule's name is essential; abbreviated hashes have very little information content, visually:\r\n\r\n```\r\nf7cbf8c42959..d25c049e6177\r\n```\r\n\r\nVS\r\n\r\n```\r\n--- c/HOME/vim/bundle/vim-airline\r\n+++ i/HOME/vim/bundle/vim-airline\r\n@@ -1 +1 @@\r\n-Subproject commit f7cbf8c42959689461e6dfcc92b4e453cb4ae17c\r\n+Subproject commit d25c049e617775eb2eb26c580e5dec591c94d480\r\n```\r\n\r\nThe latter is noisy, of course; but at least gives an immediate idea about the changed submodule's path. I've got a repo with **47 submodules**, where this matters.\r\n\r\n> git submodules are completely without any metadata [...]\r\n\r\nI'd consider that each submodule has multiple pieces of metadata:\r\n * its *path* in the worktree;\r\n * its *name*, as set by `submodule.$name` section in `.gitmodules` of the superproject;\r\n * its *url* pointing to the subproject repo;\r\n * optionally, the branch/ref of subproject repo that this submodule tracks.\r\n\r\nA way to somehow output at least the name besides the hashes — IMO is essential.","createdAt":"2024-10-16T12:55:22Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/1457#issuecomment-2416765315","viewerDidAuthor":false}],"number":1457,"title":"🐛 With `file-style=omit`, git submodules are only displayed as truncated SHA changes"},{"body":"delta (v0.16.5) hangs on the following input (save as `bad-diff.diff` and run `delta < bad-diff.diff`)\r\n\r\n```diff\r\ncommit deadbeef\r\n\r\ndiff --git a/bar.svelte b/bar.svelte\r\n--- a/bar.svelte\r\n+++ b/bar.svelte\r\n@@ -90,7 +90,9 @@ async function add(a, b) {\r\n+let foo\r\n export async function go_to_bar(bar_no) {\r\n+ foo = bar_no\r\n /*\r\n\r\n```\r\n\r\nHappened when running `git log -p | delta`, and I narrowed it down to this.","comments":[{"id":"IC_kwDOC4j8g85fWCI1","author":{"login":"dandavison"},"authorAssociation":"OWNER","body":"Hi @mustafa0x, thanks! That's exciting. It appears to be the syntax highlighting library (syntect), or something about the way that delta's calling syntect. \r\n\r\nA print statement before this line https://github.com/dandavison/delta/blob/master/src/paint.rs#L669\r\n\r\nshows that delta is submitting the line below to syntect `highlight_line` and that this call hangs.\r\n\r\n```\r\n /*\r\n```","createdAt":"2023-06-20T21:51:11Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[{"content":"THUMBS_UP","users":{"totalCount":1}}],"url":"https://github.com/dandavison/delta/issues/1451#issuecomment-1599611445","viewerDidAuthor":true},{"id":"IC_kwDOC4j8g85fWCoF","author":{"login":"dandavison"},"authorAssociation":"OWNER","body":"Looks like https://github.com/trishume/syntect/issues/460.","createdAt":"2023-06-20T21:52:38Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/1451#issuecomment-1599613445","viewerDidAuthor":true},{"id":"IC_kwDOC4j8g85fbPAy","author":{"login":"dandavison"},"authorAssociation":"OWNER","body":"We may want to follow what was done here: https://github.com/rust-lang/docs.rs/pull/1944","createdAt":"2023-06-21T14:44:48Z","includesCreatedEdit":true,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/1451#issuecomment-1600974898","viewerDidAuthor":true}],"number":1451,"title":"🐛 Hangs on patch"},{"body":"With `pager = delta` in my `.gitconfig`, while running `git grep` and the results include a line with a `©` symbol in a `License.txt` file, the results start to display, but there's a panic when the line with the `©` symbol is supposed to be displayed.\r\n\r\nFor this specific example, I'm in https://github.com/dnnsoftware/Dnn.Platform, running `git grep SharpZipLib` from the `DNN Platform/Components/SharpZipLib` directory (I actually ran the command from the root directory, but narrowed it down to reduce the amount of extra results for the issue).\r\n\r\nIt renders without issue in a diff and when using `less` as the pager directly (though the `©` symbol renders as `<A9>` via `less`).\r\n\r\n<details>\r\n<summary>> git grep SharpZipLib</summary>\r\n\r\n>thread 'main' panicked at 'byte index 57 is not a char boundary; it is inside '�' (bytes 56..59) of `License.txt:1:Copyright � 2000-2018 SharpZipLib Contributors`', src\\handlers\\grep.rs:381:64\r\n>stack backtrace:\r\n> 0x7ff6d8c2d422 - git_filter_source_path\r\n> 1: 0x7ff6d8c4dd8b - git_filter_source_path\r\n> 2: 0x7ff6d8c2827a - git_filter_source_path\r\n> 3: 0x7ff6d8c2d16b - git_filter_source_path\r\n> 4: 0x7ff6d8c2ff0a - git_filter_source_path\r\n> 5: 0x7ff6d8c2fb70 - git_filter_source_path\r\n> 6: 0x7ff6d8c305e6 - git_filter_source_path\r\n> 7: 0x7ff6d8c304de - git_filter_source_path\r\n> 8: 0x7ff6d8c2e0c9 - git_filter_source_path\r\n> 9: 0x7ff6d8c301f0 - git_filter_source_path\r\n> 10: 0x7ff6d8d64a15 - onig_unicode_define_user_property\r\n> 11: 0x7ff6d8c517e2 - git_filter_source_path\r\n> 12: 0x7ff6d8d650a3 - onig_unicode_define_user_property\r\n> 13: 0x7ff6d8a348ab - <unknown>\r\n> 14: 0x7ff6d8aacbee - <unknown>\r\n> 15: 0x7ff6d8aa520e - <unknown>\r\n> 16: 0x7ff6d8a6b01b - <unknown>\r\n> 17: 0x7ff6d8ac7016 - <unknown>\r\n> 18: 0x7ff6d8ac7eec - <unknown>\r\n> 19: 0x7ff6d8c20e0e - git_filter_source_path\r\n> 20: 0x7ff6d8a6c27c - <unknown>\r\n> 21: 0x7ff6d8d55e8c - onig_unicode_define_user_property\r\n> 22: 0x7ffe8f2826ad - BaseThreadInitThunk\r\n> 23: 0x7ffe903aa9f8 - RtlUserThreadStart\r\n>License.txt:\r\n\r\n</details>\r\n\r\n<details>\r\n<summary>> git --no-pager grep SharpZipLib</summary>\r\n\r\n>License.txt:1:Copyright © 2000-2018 SharpZipLib Contributors\r\n>SharpZipLib.dnn:3: <package name=\"DotNetNuke.SharpZipLib\" type=\"Library\" version=\"1.3.3\">\r\n>SharpZipLib.dnn:4: <friendlyName>SharpZipLib</friendlyName>\r\n>SharpZipLib.dnn:14: <releaseNotes>https://github.com/icsharpcode/SharpZipLib/wiki/Release-History</releaseNotes>\r\n>SharpZipLib.dnn:20: <name>ICSharpCode.SharpZipLib.dll</name>\r\n</details>\r\n\r\nI'm running this on Windows 11.","comments":[{"id":"IC_kwDOC4j8g85fAksS","author":{"login":"dandavison"},"authorAssociation":"OWNER","body":"Thanks!","createdAt":"2023-06-16T02:15:16Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/1448#issuecomment-1593985810","viewerDidAuthor":true},{"id":"IC_kwDOC4j8g85fPHHu","author":{"login":"th1000s"},"authorAssociation":"COLLABORATOR","body":"That is an ISO-8859 \"©\" char, 0xA9 in hexadecimal.\r\n\r\nOn Linux this results in the dreaded `String mismatch encountered while superimposing style sections` error, not the String indexing error.\r\n\r\nTo reproduce:\r\n`echo SVNPLTg4NTkgQ29weXJpZ2h0IKkgU2lnbg0K | base64 -d >| c.txt && git add c.txt && git grep 8859 c.txt; git reset c.txt > /dev/null; rm c.txt` (CRLF vs Unix or no line endings makes no difference).","createdAt":"2023-06-19T21:45:24Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/1448#issuecomment-1597796846","viewerDidAuthor":false},{"id":"IC_kwDOC4j8g85fPhC_","author":{"login":"dandavison"},"authorAssociation":"OWNER","body":"> On Linux this results in the dreaded String mismatch encountered while superimposing style sections error\r\n\r\nYes, that was what I saw on MacOS also.\r\n\r\nIncidentally, if anyone reading this wants a route into understanding the code paths involved in that error, delta has some documentation of its internals that explains it (including a diagram):\r\nhttps://github.com/dandavison/delta/blob/master/ARCHITECTURE.md#handling-diff-hunk-lines\r\n\r\n<table><tr><td>\r\n<img width=\"1709\" alt=\"image\" src=\"https://github.com/dandavison/delta/assets/52205/06e868c2-c113-4946-827f-d7a78534d2ba\">\r\n</td></tr></table>\r\n","createdAt":"2023-06-20T00:18:48Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/1448#issuecomment-1597903039","viewerDidAuthor":true}],"number":1448,"title":"🐛 Panic running git grep through delta pager when txt file contains ©"},{"body":"The diff contains an ISO-8859-1 line and ansi (just as `git show` would pipe to a pager), delta (HEAD) prints:\r\n\r\n\r\n\r\nTo reproduce (embedded in base64 because of the non-utf-8 data):\r\n\r\n```\r\ncat <<EOF | base64 -d | gzip -d | delta\r\nH4sICNeDh2QAA3VuaWNvZGUuYnJva2VuAG1QQW6DMBC884Vc5piImOCAsSFNRaX20FMP6S2HygTTIMUBESMR9at9TE0IUVPVsr27\r\ns7OjsSfbINC7SuvSQFFZRPZiKo5FVnAa81yFnGYiFDGXtCg445LzyVY7T63ZV02Cl07q+qAw1HiQl5iqAfas8qPzLI1KALzvW2xU\r\nDUpBWRKIhHEsfV/A9e1yHEvB6+aNCMFi5GVRwHEmW6ovKSGf1qJciKw03g7ZNem99JzymKsOeZSHPGN+zpeZ5/1+D6jvR2E40gkh\r\nN60Rc133j2wQ6TQFoYzNQ7h94EhT24M9edVmB9UTh+pDS7OfDii6OcqjwXmGr6vUUrt32SUBymKKM9ZrUMz+6wONMm1zRLfCYmG/\r\nsDzBbgFr8/ZZhCYg3wSjGTtLVyG14yMCXI3VjZqjrk5mNbacH1NBcYUDAgAA\r\nEOF\r\n```\r\n\r\nAn older delta 0.12.1 binary which I had somewhere does not exhibit this behavior.\r\n","comments":[],"number":1446,"title":"🐛 Regression: An ansi decorated, non-unicode line makes delta print the raw input"},{"body":"I set `plus-style = \"syntax #114433\"` in my `.gitconfig` and it worked on my system. I ssh-ed into a container (running an sshd, unusual, yes) using the same config and it output a completely different color\r\n\r\nit took me a while of debugging to realize it was outputting in color space 5 (256-color, `\\33[48;5;237`) instead of color space 2 (true-color, `\\33[48;2;17;68;51`)\r\n\r\nI came to file a bug report with a pile of screenshots but found #111 which mentioned `--24-bit-color` (now `--true-color`) and `COLORTERM`. ~there's definitely something broken in my container environment since `COLORTERM` isn't set, but~ it would have saved me a bunch of time if delta had just noted my choice of true/24-bit color and refused to continue instead of picking a 256-color\r\n\r\nEDIT: turns out `COLORTERM` just isn't forwarded over ssh and my terminal's terminfo isn't in the most common distribution (ncurses) due to a... disagreement between the maintainers https://github.com/kovidgoyal/kitty/issues/879#issuecomment-419825534\r\n\r\nanother option that might be nice is to default `true-color` to always (https://github.com/cronvel/terminal-kit/issues/139#issuecomment-758279390) since almost every terminal supports it nowadays, especially the ones that `delta` is likely to run on","comments":[{"id":"IC_kwDOC4j8g86LRlY_","author":{"login":"lugen4ro"},"authorAssociation":"NONE","body":"I want to second this.\r\n\r\nWas trying out a colorscheme for delta, but I got a totally different look even though everything seemed to be set up correctly.\r\nThe reason was that delta auto-downgraded my 24-bit colors into 256-colors because [my terminal (Windows Terminal) does not set the COLORTERM environmental variable](https://github.com/microsoft/terminal/issues/11057) even though it does support true color.\r\n\r\nI found this out because `delta --show-config` showed different hex-values than what I had in my configuration.\r\n\r\nTook me a lot of time debugging this so having some error / warning would be highly appreciated.\r\n\r\nMy solution was to add `true-color = always` to my `[delta]` section in my `.gitconfig` file as described [here](https://github.com/dandavison/delta/blob/2d7015c774b7ce93bbd8b5b07e7580d066442fc4/manual/src/tips-and-tricks/24-bit-color-truecolor.md).","createdAt":"2024-09-08T11:04:14Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/1429#issuecomment-2336642623","viewerDidAuthor":false},{"id":"IC_kwDOC4j8g86OGqEI","author":{"login":"th1000s"},"authorAssociation":"COLLABORATOR","body":"I think the default can become true-color / 24bit, with an option to still auto-detect or disable this entirely. Nearly all terminal emulators support it, see [https://github.com/termstandard/colors](https://github.com/termstandard/colors?tab=readme-ov-file#truecolor-support-in-output-devices).\r\n\r\n@bash, as you have been looking at a lot of terminals recently, what do you think? The url above also mentions a way to querying a terminal, that may be a bonus feature for terminal-colorosorus.\r\n\r\n","createdAt":"2024-09-30T20:42:40Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/1429#issuecomment-2384109832","viewerDidAuthor":false},{"id":"IC_kwDOC4j8g86ORlYO","author":{"login":"bash"},"authorAssociation":"CONTRIBUTOR","body":"I haven't looked at true-color support in particular so I unfortunately don't have much to add on that front. The list of terminals in <https://github.com/termstandard/colors> looks pretty complete to me though (compared to my [color detection survey](https://github.com/bash/terminal-colorsaurus/blob/main/doc/terminal-survey.md)).\r\n\r\nProbably the most important offender in the \"not supported\" pile is macOS's default Terminal.app, so I'm not sure how great it'd be to enable true-color by default [^macos-term-env-var].\r\n\r\n<details>\r\n<summary>Here's what true-colors look like on Terminal.app</summary>\r\n\r\nTerminal.app:\r\n\r\n\r\n\r\nvs WezTerm:\r\n\r\n\r\n\r\n\r\n</details>\r\n\r\nAdding a warning if a theme uses true-color but the terminal doesn't support it might also be a start as @lugen4ro suggested—but maybe too noisy? For reference [this](https://github.com/sharkdp/bat/blob/61c9f312c9d10103b33b7d8069401304ca938f06/src/macros.rs#L2) is how bat reports warnings.\r\n\r\nRegarding detection: TIL that such a query exists—looks really interesting. I'm generally open to adding something like this to terminal-colorsaurus but there are a few notes that I'd want to consider:\r\n\r\n* How widely supported is this query? If it's not widely supported then it might not be worth the extra startup cost.\r\n* I'm a bit unhappy with this part:\r\n\r\n > Here we set the background color to RGB(1,2,3) - an unlikely default choice\r\n \r\n 1. The detection requires setting the background color—yet another caveat to add to the docs of colorsaurus *sigh* (I suppose it can be improved upon by sending a reset sequence at the end)\r\n 2. Picking an arbitrary color and hoping its not the default choice seems rather interesting (I know, I know *technically* it's quite unlikely that we hit the *exact* color)\r\n\r\n> [...] due to a... disagreement between the maintainers https://github.com/kovidgoyal/kitty/issues/879#issuecomment-419825534\r\n\r\n*sigh*—of course\r\n\r\n[^macos-term-env-var]: Terminal.app does identify itself via `TERM_PROGRAM=Apple_Terminal`—but that environment variable is not forwarded by SSH & co. by default.","createdAt":"2024-10-01T20:09:43Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/1429#issuecomment-2386974222","viewerDidAuthor":false}],"number":1429,"title":"🚀 show an error when specifying true-color in 256-color mode"},{"body":"When using `git log --oneline`, if a commit only changes a binary file, the following commit line is erased by delta, making it look like the first commit made more changes than it did:\r\n\r\n<img width=\"650\" alt=\"Xnapper-2023-04-19-18 54 19\" src=\"https://user-images.githubusercontent.com/857609/233159647-f1ac1146-19de-4b05-a7a1-f635031e5f07.png\">\r\n\r\nHere's the Git output with the second commit line, `324dd44 Initial draft`:\r\n\r\n```\r\n$ git -c core.pager=less log --oneline --patch\r\n2e15507 (HEAD -> main) Better content\r\ndiff --git writing-with-llms.docx writing-with-llms.docx\r\nindex dbbabe4..93d8be4 100644\r\nBinary files writing-with-llms.docx and writing-with-llms.docx differ\r\n324dd44 Initial draft\r\ndiff --git writing-with-llms.docx writing-with-llms.docx\r\nnew file mode 100644\r\nindex 0000000..dbbabe4\r\nBinary files /dev/null and writing-with-llms.docx differ\r\n```","comments":[{"id":"IC_kwDOC4j8g85cdH60","author":{"login":"wescande"},"authorAssociation":"CONTRIBUTOR","body":"\r\nI looked a bit into that and it appear neither `2e15507 (HEAD -> main) Better content` nor `324dd44 Initial draft` are identified as being part in the CommitMeta. (AKA [this if](https://github.com/dandavison/delta/blob/b3ee8400dd955e2ecb80b06863da306e42f31d2d/src/handlers/commit_meta.rs#L14) does not detect it)\r\n\r\nThe current default regex is `^commit ` and this is set by default in `cli.rs`\r\n\r\nI see 2 fix for that:\r\n\r\n### 1/ use a custom pretty formatter (Recommanded:)\r\n\r\nUse a custom format with the `--pretty` of git log to match the expected regex (and set an alias for that of course)\r\nSomething like:\r\n```sh\r\n$> git log --pretty=\"%C(yellow)commit %h%Creset %C(bold cyan)%d%Creset %C(green)%s%Creset\" --patch\r\n```\r\n### 2/ Change the regex used in delta\r\n\r\nThe regex to match the --oneline should be `^commit |^[0-9a-f]{7,40} `. \r\nThat mean that any line that will start with a 7 to 40 sha will now be considered as a meta header for commit...\r\nI think this is really fragile\r\n\r\nThe delta config can already do that by passing the correct argument to `--commit-regex`. Something like this: (or put it your config)\r\n```sh\r\n$> git -c core.pager=\"delta --commit-regex='^commit |^[0-9a-f]{7,40} '\" log --oneline --patch\r\n```","createdAt":"2023-05-17T10:26:22Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/1400#issuecomment-1551138484","viewerDidAuthor":false},{"id":"IC_kwDOC4j8g85cd0ZQ","author":{"login":"adamchainz"},"authorAssociation":"CONTRIBUTOR","body":"\"Use a custom pretty formatter\" is a workaround rather than a fix, so I wouldn't say it's recommended. It won't help users who run `git log --oneline` and don't see a commit. delta should never erase input.\r\n\r\nIs changing the regex really the only option? Delta already highlights the first line correctly, so it doesn't seem like there's a need to get it detected as a commit header, more just to stop the erasure of the `324dd44 Initial draft` line.","createdAt":"2023-05-17T12:40:23Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/1400#issuecomment-1551320656","viewerDidAuthor":false},{"id":"IC_kwDOC4j8g85ceG3k","author":{"login":"dandavison"},"authorAssociation":"OWNER","body":"Hi @adamchainz and @wescande. I believe what's happening here is:\r\n\r\n- delta encounters the first line `2e15507 (HEAD -> main) Better content`, doesn't recognize it as anything, so enters no particular state in its state machine, and emits it unchanged, with ANSI color sequences intact.\r\n- Then delta encounters `diff --git writing-with-llms.docx writing-with-llms.docx`. It [recognizes this](https://github.com/dandavison/delta/blob/feec45b5d724f3feb29b59e48f5335513e00a3b0/src/delta.rs#L160) as a \"diff header\" and so enters `DiffHeader` state.\r\n- Now, the problem with this is that the rules for being in `DiffHeader` state are that you skip some lines (because delta deems them to be for machines, not for human eyes, and it's a design principle of delta that its output is for human eyes). Hence\r\n- Bug! We encounter `324dd44 Initial draft`, don't recognize it, and mistakenly treat is as something that should be skipped.\r\n\r\nThis seems fixable, presumably by tightening up the logic (string patterns) in `diff_header_diff.rs`, and `should_skip_line` etc.","createdAt":"2023-05-17T13:25:57Z","includesCreatedEdit":true,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/1400#issuecomment-1551396324","viewerDidAuthor":true},{"id":"IC_kwDOC4j8g85cgA1u","author":{"login":"wescande"},"authorAssociation":"CONTRIBUTOR","body":"@dandavison This is exactly what happen.\r\n\r\nWhen not using `--oneline`, the commit start with `^commit `, that let delta match this with the `CommitMeta` state. I think we want to achieve the same here. Below is a dirty fix to do that. Let me know what you think before I clean it a bit more\r\n\r\n```diff\r\ndiff --git a/src/handlers/commit_meta.rs b/src/handlers/commit_meta.rs\r\nindex f60ba37..5424983 100644\r\n--- a/src/handlers/commit_meta.rs\r\n+++ b/src/handlers/commit_meta.rs\r\n@@ -3,11 +3,19 @@ use std::borrow::Cow;\r\n use super::draw;\r\n use crate::delta::{State, StateMachine};\r\n use crate::features;\r\n+use regex::Regex;\r\n \r\n impl<'a> StateMachine<'a> {\r\n #[inline]\r\n fn test_commit_meta_header_line(&self) -> bool {\r\n- self.config.commit_regex.is_match(&self.line)\r\n+ let oneline_regex = Regex::new(\"^[0-9a-f]{7,40} \").unwrap();\r\n+ if self.config.commit_regex.is_match(&self.line) {\r\n+ true\r\n+ } else if matches!(self.state, State::DiffHeader(_)) && oneline_regex.is_match(&self.line) {\r\n+ true\r\n+ } else {\r\n+ false\r\n+ }\r\n }\r\n \r\n pub fn handle_commit_meta_header_line(&mut self) -> std::io::Result<bool> {\r\n```\r\n\r\nBut this above snippet is not perfect as it only fix for when there is no Hunk.\r\nThe issue is reported for binary file, because in this case we are going from diffHeader to diffHeader, and it allow to skip some line. But when we have some Hunk before, the `324dd44 Initial draft` will be evaluated as `HunkZero`.\r\nThe visual result is still ok, since HunkZero line are emit unchanged, but *we know* delta is not in a good state.\r\n\r\nIt would be great to detect a hunk size by looking at the `@@ -3,3 +3,3 @@` to know when we finish a Hunk. What do you think ? (this require modifying hunk_header parser and to use it's data in hunk.rs).","createdAt":"2023-05-17T18:50:55Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/1400#issuecomment-1551895918","viewerDidAuthor":false},{"id":"IC_kwDOC4j8g85cgU2P","author":{"login":"dandavison"},"authorAssociation":"OWNER","body":"@wescande is another option to change delta so that it never skips a line unless it positively recognizes it as a line that it should skip via a `starts_with(...)` call or a regex?","createdAt":"2023-05-17T20:05:25Z","includesCreatedEdit":true,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/1400#issuecomment-1551977871","viewerDidAuthor":true},{"id":"IC_kwDOC4j8g85cgqtw","author":{"login":"adamchainz"},"authorAssociation":"CONTRIBUTOR","body":"Positively identifying lines to skip, rather than identifying lines to stop skipping, sounds like an overall more robust approach.","createdAt":"2023-05-17T20:50:32Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/1400#issuecomment-1552067440","viewerDidAuthor":false}],"number":1400,"title":"🐛 git log --oneline with binary file change erases commit from log"},{"body":"iTerm’s [inline image protocol](https://iterm2.com/documentation-images.html) is a de facto standard for displaying images in the terminal. It has been copied by at least [wezterm](https://wezfurlong.org/wezterm/imgcat.html).\r\n\r\n[This blog post](https://www.codependentcodr.com/git-image-diff-with-iterm2.html) covers setting up Git to use the protocol to show images within diffs. But after following it, I found delta erases the image escape codes:\r\n\r\n<img width=\"650\" alt=\"Xnapper-2023-04-19-17 57 24\" src=\"https://user-images.githubusercontent.com/857609/233146947-9967e280-e8b2-4bd5-a6a7-26f6266a0263.png\">\r\n\r\nThis is what the setup looks like with vanilla `less`:\r\n\r\n<img width=\"650\" alt=\"Xnapper-2023-04-19-17 56 45\" src=\"https://user-images.githubusercontent.com/857609/233146990-a73e153c-197a-494c-939a-f1b888d7f4f9.png\">\r\n\r\nI guess this is part of how delta strips formatting from incoming diffs, in order to apply its own? If so it might be possible to special case the 1337 escape code for all iTerm ANSI extensions.\r\n\r\n(I'm not that interested in this feature myself, since the image diffing seems a bit limited. But I thought delta shouldn't accidentally block this use case.)","comments":[{"id":"IC_kwDOC4j8g85aTuhF","author":{"login":"dandavison"},"authorAssociation":"OWNER","body":"Interesting. If you use `core.pager='cat -A'` or `bat -A` or `hexdump` or `hexyl` or something, can you confirm that git is definitely passing the escape codes on to the pager?","createdAt":"2023-04-19T17:37:44Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/1399#issuecomment-1515120709","viewerDidAuthor":true},{"id":"IC_kwDOC4j8g85aWY7x","author":{"login":"adamchainz"},"authorAssociation":"CONTRIBUTOR","body":"Yes it is:\r\n\r\n<img width=\"946\" alt=\"Xnapper-2023-04-20-08 06 15\" src=\"https://user-images.githubusercontent.com/857609/233287329-8c79df96-5e73-4359-9caa-c2d512ab89a2.png\">\r\n\r\n(Sorry, I meant to use `less` for the second screenshot above.)","createdAt":"2023-04-20T07:06:29Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/1399#issuecomment-1515818737","viewerDidAuthor":false}],"number":1399,"title":"🐛 Pass through data in iTerm image protocol"},{"body":"Hi, thanks for this amazing library! :) \r\n\r\nI have recently started using VS Code integrated terminal instead of iterm2. I've been using the [following configuration](https://dandavison.github.io/delta/tips-and-tricks/using-delta-with-vscode.html) to open files from `git diff`. I really enjoyed that delta created links for the line numbers and I could click those to open the file on the specific line... However, this doesn't work with the integrated terminal anymore.\r\n\r\nI think vscode overrides the terminal behaviour with its link matcher algorithm and opens the search (and populates the search field with the number I clicked).\r\n\r\n(This is what happens with the integrated terminal after I cmd+click number \"184\")\r\n<img width=\"1513\" alt=\"image\" src=\"https://user-images.githubusercontent.com/22679154/232774662-9059bb0c-e9c0-4f37-8525-1cf30c364e54.png\">\r\n\r\n(Doing the same from iterm2 works as expected and the correct file is opened and correct line is selected in the vscode)\r\n<img width=\"1918\" alt=\"image\" src=\"https://user-images.githubusercontent.com/22679154/232774995-23950f68-f787-4159-bcbc-5b067b33e8ec.png\">\r\n\r\nI don't think this is a bug in delta, but maybe someone has an answer to this - but I wasn't able to figure this out :) \r\n","comments":[{"id":"IC_kwDOC4j8g85xrgYu","author":{"login":"zaneduffield"},"authorAssociation":"NONE","body":"Reported on the vscode repo: https://github.com/microsoft/vscode/issues/176812","createdAt":"2024-01-24T02:07:56Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/1397#issuecomment-1907230254","viewerDidAuthor":false},{"id":"IC_kwDOC4j8g85xwpjp","author":{"login":"dandavison"},"authorAssociation":"OWNER","body":"Thanks for pointing this out @zaneduffield. I'm a heavy VSCode user myself nowadays, and I've actually just recently started running `git blame` and `ripgrep ... | delta` in the VSCode integrated terminal, so I certainly hope this situation improves! At minimum it seems that we want a way for VSCode to open paths in VSCode (sounds reasonable...) from terminal hyperlinks, even if we don't have arbitrary protocol support.\r\n\r\nI hadn't noticed this because I have a [personal project](https://github.com/dandavison/wormhole) that uses a HTTP server to open paths in VSCode but, I was just on the verge of getting annoyed by how inelegant it was in the case of links clicked in the VSCode terminal itself, and so I was just on the verge of getting frustrated by the issue you've linked to!","createdAt":"2024-01-24T17:15:00Z","includesCreatedEdit":true,"isMinimized":false,"minimizedReason":"","reactionGroups":[{"content":"THUMBS_UP","users":{"totalCount":1}}],"url":"https://github.com/dandavison/delta/issues/1397#issuecomment-1908578537","viewerDidAuthor":true}],"number":1397,"title":"🚀 Hyperlink integration with vscode integrated terminal"},{"body":"I compute the diff on my PATH environment variable before and after sourcing a script, and with the regular diff command I can do \r\n\r\n```\r\ndiff -u \\\r\n --label \"\\$PATH before ${scriptfile}\" <(echo \"${path_before_one_path_per_line}\") \\\r\n --label \"\\$PATH after\" <(echo \"${path_after_one_path_per_line}\") || :\r\n```\r\n\r\nI would like to do that with delta, but none of the available options seem to achieve what I want.\r\n\r\n","comments":[{"id":"IC_kwDOC4j8g85YKJ6f","author":{"login":"dandavison"},"authorAssociation":"OWNER","body":"Hi @lestephane, thanks for the suggestion. I'd support this addition. The obvious names given the terminology in delta's CLI would be\r\n```\r\n--minus-file-label\r\n--plus-file-label\r\n```\r\nDoes that sound OK? It would be a relatively straightforward change I think -- any interest in making it? Add the options to `cli.rs` and `config.rs` and then I believe the relevant function is https://github.com/dandavison/delta/blob/e20c10a31bc303ab5017bc9c95e5486c724bc847/src/handlers/diff_header.rs#L403","createdAt":"2023-03-22T07:53:12Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/1370#issuecomment-1479057055","viewerDidAuthor":true},{"id":"IC_kwDOC4j8g85d3n6Z","author":{"login":"dandavison"},"authorAssociation":"OWNER","body":"Hi @lestephane, I have two hesitations here:\r\n\r\n1. What would this look like in delta? Delta currently shows one file path only for a diff:\r\n<table>\r\n <tbody>\r\n <tr>\r\n <td><img width=\"460\" alt=\"image\" src=\"https://github.com/dandavison/delta/assets/52205/20f763a0-ef4a-4e89-9f49-f762b5fb80ff\"></td>\r\n </tr>\r\n </tbody>\r\n </table>\r\n\r\n2. In general, I don't think delta should implement all `diff` flags and options; instead users should pipe `diff` output into delta. `delta fileA fileB` is intended only as a shortcut for the common case.","createdAt":"2023-06-03T11:03:11Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/1370#issuecomment-1574862489","viewerDidAuthor":true}],"number":1370,"title":"🚀 diff style --label option for diffs between arbitrary sources"},{"body":"I sometimes write Lua comments with a leading `---` instead of `--`, and I became perplexed when I saw that using `git show` on my neovim `init.lua` was getting strangely truncated. \r\n\r\nI can see that normally delta helpfully applies syntax highlighting to the file. But something (possibly specific to lua syntax handling?) is causing `---` to prematurely truncate output.","comments":[{"id":"IC_kwDOC4j8g85X-KrC","author":{"login":"dandavison"},"authorAssociation":"OWNER","body":"Hey @unphased, yes I think this is because `---` has special significance in [unified diff format](https://www.gnu.org/software/diffutils/manual/html_node/Detailed-Unified.html) and hence in git diff format. Presumably the fix is going to involve making the parser slightly more intelligent / context-dependent. Any interest in looking at it?? ","createdAt":"2023-03-20T09:47:38Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/1368#issuecomment-1475914434","viewerDidAuthor":true},{"id":"IC_kwDOC4j8g85YB-aK","author":{"login":"unphased"},"authorAssociation":"NONE","body":"Ah, good to know that context! Yeah seems like we can make diff-specific handling not take place when the command is known to be for the kind of `git show` which wouldn't produce a diff. Do you know if it's easy to know that? If all the info we have about the call is the fact that it is `git show` it might not be enough since if you do not specify the colon syntax to specify dumping a file at a given commit then it usually actually shows the diff of the commit. I definitely have interest in looking at this and it seems an ideal type of fix to get my feet wet in this project as a rust noob. will try to carve out a slice of time.","createdAt":"2023-03-20T20:47:25Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/1368#issuecomment-1476912778","viewerDidAuthor":false},{"id":"IC_kwDOC4j8g85YCJsl","author":{"login":"dandavison"},"authorAssociation":"OWNER","body":"Great! So is this only occurring when you do `git show $commit:$path` to view file contents? That's good news if so.\r\n\r\nSome implementation notes to get you going: basically there's a struct called `StateMachine` which has a mutable attribute called `state`, and delta is basically a `while` loop in a method of `StateMachine` which is processing lines of input. Here's the body of that while loop:\r\n\r\nhttps://github.com/dandavison/delta/blob/e20c10a31bc303ab5017bc9c95e5486c724bc847/src/delta.rs#L154-L175\r\n\r\nOne of those `handle_*` functions is the one that's wrongly thinking your lua `---` are diff header syntax. But of course the logic in the `handle_*` function can be made dependent on the current value of `state`, as well as made dependent on other things, and hopefully by adding a little bit of conditional logic you can prevent the `handle_*` function from handling a line it shouldn't.","createdAt":"2023-03-20T21:28:14Z","includesCreatedEdit":true,"isMinimized":false,"minimizedReason":"","reactionGroups":[{"content":"HEART","users":{"totalCount":2}}],"url":"https://github.com/dandavison/delta/issues/1368#issuecomment-1476959013","viewerDidAuthor":true}],"number":1368,"title":"🐛 Delta has a problem truncating Git show output when encountering `---` on a line in a Lua file"},{"body":"I tried to run `git grep -C10 ULT_MAN` in the man-db git repository <https://salsa.debian.org/debian/man-db.git>, and got a panic:\r\n\r\n```\r\nthread 'main' panicked at 'String mismatch encountered while superimposing style sections: ' ' vs 'E'', /home/josh/.cargo/registry/src/github.com-1ecc6299db9ec823/git-delta-0.15.1/src/paint.rs:931:17\r\n```\r\n\r\nIf I do `git --no-pager grep --color=always -C1 ULT_MAN | delta` I can reproduce the problem. However, if I redirect the output into a file, and then cat that file through delta, that *doesn't* reproduce the problem.\r\n\r\n[delta-bug.txt](https://github.com/dandavison/delta/files/11009993/delta-bug.txt)","comments":[{"id":"IC_kwDOC4j8g85X7Sb1","author":{"login":"dandavison"},"authorAssociation":"OWNER","body":"Thanks @joshtriplett!\r\n\r\n> I tried to run git grep -C10 ULT_MAN in the man-db git repository https://salsa.debian.org/debian/man-db.git, and got a panic:\r\n\r\nI can reproduce this.","createdAt":"2023-03-19T08:58:40Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/1360#issuecomment-1475159797","viewerDidAuthor":true},{"id":"IC_kwDOC4j8g85X8jpu","author":{"login":"joshtriplett"},"authorAssociation":"CONTRIBUTOR","body":"Ran into another \"String mismatch\" panic in the same repository, with `git grep manpath`; that one seems like it might be related to having a non-UTF-8 character on a line, as delta stops right before the line with that character (in `it.po`).","createdAt":"2023-03-20T01:46:45Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[{"content":"THUMBS_UP","users":{"totalCount":1}}],"url":"https://github.com/dandavison/delta/issues/1360#issuecomment-1475492462","viewerDidAuthor":false},{"id":"IC_kwDOC4j8g85Yv1fu","author":{"login":"vphantom"},"authorAssociation":"NONE","body":"That would make sense, as I have `git diff` consistently making delta crash on our repo which has lots of ISO-8859-1 files. 😕","createdAt":"2023-03-29T16:36:18Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/1360#issuecomment-1488934894","viewerDidAuthor":false},{"id":"IC_kwDOC4j8g85Yv85H","author":{"login":"dandavison"},"authorAssociation":"OWNER","body":"Thanks, we should fix this; should be a reasonably doable fix if anyone feels like looking into it. But if not I'll try to get to it soon and then make a release.","createdAt":"2023-03-29T16:57:02Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[{"content":"THUMBS_UP","users":{"totalCount":1}}],"url":"https://github.com/dandavison/delta/issues/1360#issuecomment-1488965191","viewerDidAuthor":true},{"id":"IC_kwDOC4j8g85aO4R1","author":{"login":"th1000s"},"authorAssociation":"COLLABORATOR","body":"This seems to be related to #1172, see also trishume/syntect#450","createdAt":"2023-04-18T22:08:59Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/1360#issuecomment-1513849973","viewerDidAuthor":false}],"number":1360,"title":"🐛 String mismatch encountered while superimposing style sections: ' ' vs 'E'"},{"body":"raw git output shows that the word 'leading' has not changed, but it's shown as removed; but 'Center(' and 'child:' are new words, the first one is missed.\r\n```\r\ngit diff app/lib/src/features/alert_groups/views/pages/alert_groups_page.dart | cat -\r\ndiff --git a/app/lib/src/features/alert_groups/views/pages/alert_groups_page.dart b/app/lib/src/features/alert_groups/views/pages/alert_groups_page.dart\r\nindex 7bfd801..2b894b3 100644\r\n--- a/app/lib/src/features/alert_groups/views/pages/alert_groups_page.dart\r\n+++ b/app/lib/src/features/alert_groups/views/pages/alert_groups_page.dart\r\n@@ -47,7 +47,8 @@ class _AlertGroupsPageState extends ConsumerState<AlertGroupsPage>\r\n SliverAppBar(\r\n titleSpacing: 0,\r\n floating: true,\r\n- leading: UserAvatar(avatarUrl: userInfo.avatarFull),\r\n+ leading: Center(\r\n+ child: UserAvatar(avatarUrl: userInfo.avatarFull)),\r\n actions: const [\r\n SignOutButton(),\r\n ],\r\n```\r\n\r\n\r\n\r\n","comments":[{"id":"IC_kwDOC4j8g85X2UxZ","author":{"login":"Dieterbe"},"authorAssociation":"NONE","body":"git-delta 0.15.1 on arch linux","createdAt":"2023-03-17T13:38:07Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/1359#issuecomment-1473858649","viewerDidAuthor":false}],"number":1359,"title":"🐛 incorrect display of removed/added words"},{"body":"```\r\n$ git --version\r\ngit version 2.40.0.windows.1\r\n$ less -V\r\nless 629 (PCRE2 regular expressions)\r\nCopyright (C) 1984-2023 Mark Nudelman\r\n$ delta --version\r\ndelta 0.15.0\r\n$ echo $TERM\r\nxterm-256color\r\n$ bash --version\r\nGNU bash, version 5.2.15(1)-release (x86_64-pc-msys)\r\nCopyright (C) 2022 Free Software Foundation, Inc.\r\n```\r\n\r\nI am not able to navigate (ctrl-u/ctrl-d, arrow keys), quit (q) when piping `git` or `diff` outputs to delta.\r\n\r\n```\r\ngit diff | delta\r\ndiff file1 file2 | delta\r\n```\r\n\r\nHowever, the keys work as expected if I use `delta` directly.\r\n\r\n```\r\ndelta file1 file2\r\n```\r\n\r\nIs this because STDIN is redirected to `delta` ?\r\n\r\nif this helps - if I do `diff file1 file2 | delta | less` I can navigate backwards/forwards but of course the output is not useful.\r\n\r\nAny hints on how to debug this would be appreciated. Thanks.\r\n\r\n\r\n","comments":[],"number":1357,"title":"🐛 Pager control keys not working in Windows GitBash"},{"body":"Currently only file lines can be turned into nice hyperlinks to click-to-open them in an editor.\r\nBut then the diffs have this great feaure where you can highlight individual word/char edits.\r\nWhat if these edits, in addition to being highlighted visually, were also marked as hyperlinks in the `file:line:column` format so you could click on a char diff and end up at exactly that char in your editor!\r\n","comments":[{"id":"IC_kwDOC4j8g85XmH7I","author":{"login":"dandavison"},"authorAssociation":"OWNER","body":"Ha, great idea! It hadn't occurred to me. Any interest in having a go?","createdAt":"2023-03-15T09:03:09Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/1355#issuecomment-1469611720","viewerDidAuthor":true},{"id":"IC_kwDOC4j8g85X3ahR","author":{"login":"eugenesvk"},"authorAssociation":"NONE","body":"Sorry, don't know much of any rust to help","createdAt":"2023-03-17T17:06:48Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/1355#issuecomment-1474144337","viewerDidAuthor":false}],"number":1355,"title":"🚀 mark word/char diffs as hyperlinks"},{"body":"Currently `hyperlinks-file-link-format` supports `{path}` and `{line}` placeholders.\r\nHowever, the new file protocol (and many editors) also support columns\r\nWould be great if `hyperlinks-file-link-format` added a `{column}` placeholder as well\r\n\r\n","comments":[{"id":"IC_kwDOC4j8g85XmI9T","author":{"login":"dandavison"},"authorAssociation":"OWNER","body":"Yes I think this makes sense, not sure why it's not there already! Thanks.","createdAt":"2023-03-15T09:05:20Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[{"content":"THUMBS_UP","users":{"totalCount":1}}],"url":"https://github.com/dandavison/delta/issues/1354#issuecomment-1469615955","viewerDidAuthor":true},{"id":"IC_kwDOC4j8g85yy41U","author":{"login":"fabian-thomas"},"authorAssociation":"NONE","body":"Just want to add that `{host}` or `{hostname}` would be nice to have as well.","createdAt":"2024-02-04T22:12:25Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/1354#issuecomment-1925942612","viewerDidAuthor":false},{"id":"IC_kwDOC4j8g85yy9oB","author":{"login":"dandavison"},"authorAssociation":"OWNER","body":"> Just want to add that `{host}` or `{hostname}` would be nice to have as well.\r\n\r\n@fabian-thomas I might be misunderstanding but I'm not sure a `{hostname}` placeholder makes sense? (What would it be populated with?) For example, my personal setting is currently\r\n\r\n```gitconfig\r\n hyperlinks-file-link-format = \"http://wormhole:7117/file/{path}:{line}?land-in=editor\"\r\n```\r\n\r\nThe hostname is something I hard-code into the link format template, and `{path}` and `{line}` are populated by delta as appropriate for the current file and line in delta output where the hyperlink occurs.","createdAt":"2024-02-04T23:14:08Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/1354#issuecomment-1925962241","viewerDidAuthor":true},{"id":"IC_kwDOC4j8g85yy_wd","author":{"login":"fabian-thomas"},"authorAssociation":"NONE","body":"This typically only makes sense when you work on remote machines. I have setup my machine to open files on remotes via Emacs Tramp. The format is file://remote-hostname/path/to/file\r\nRipgrep has implemented the same, so one can probably steal some code there.","createdAt":"2024-02-04T23:23:54Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/1354#issuecomment-1925970973","viewerDidAuthor":false},{"id":"IC_kwDOC4j8g85y2rI3","author":{"login":"dandavison"},"authorAssociation":"OWNER","body":"@fabian-thomas So what you're proposing is that `{hostname}` would be populated with a system hostname, regardless of the diff input that delta is parsing, correct? This would be in contrast to `{path}` and `{line}` (and `{column}`) which are placeholders to be populated from the line of input being parsed by delta.\r\n\r\nIf that's correct, the alternative would be to hard-code that hostname in your git config `hyperlinks-file-link-format` -- could you discuss that alternative?","createdAt":"2024-02-05T12:54:10Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/1354#issuecomment-1926935095","viewerDidAuthor":true},{"id":"IC_kwDOC4j8g85y5bpP","author":{"login":"fabian-thomas"},"authorAssociation":"NONE","body":"Yes, correct. I'm not entirely sure what you mean by the contrast to line and path. Let me explain my mental model of delta, maybe that helps. I think of delta as mainly two commands:\r\ndelta file1 file2\r\ngit diff (using delta)\r\n\r\nFor these two commands it makes sense to me to put the hostname in every hyperlink since all files reside on the machine and the hostname is clear. Like that I can easily jump to the corresponding diff.\r\nConfiguring the hostname via the git config would work, but is a pain when you deploy one set of dotfiles to each machine.","createdAt":"2024-02-05T18:05:54Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/1354#issuecomment-1927658063","viewerDidAuthor":false}],"number":1354,"title":"🚀 add column placeholder in hyperlinks-file-link-format"},{"body":"\n> `encoding` is unmaintained\n\n| Details | |\n| ------------------- | ---------------------------------------------- |\n| Status | unmaintained |\n| Package | `encoding` |\n| Version | `0.2.33` |\n| URL | [https://github.com/lifthrasiir/rust-encoding/issues/127](https://github.com/lifthrasiir/rust-encoding/issues/127) |\n| Date | 2021-12-05 |\n\nLast release was on 2016-08-28. The [issue](https://github.com/lifthrasiir/rust-encoding/issues/127) inquiring as to the status of the crate has gone unanswered by the maintainer.\n\n## Possible alternatives\n\n- [encoding_rs](https://crates.io/crates/encoding_rs)\n\nSee [advisory page](https://rustsec.org/advisories/RUSTSEC-2021-0153.html) for additional details.\n","comments":[{"id":"IC_kwDOC4j8g85XWuCX","author":{"login":"nickelc"},"authorAssociation":"CONTRIBUTOR","body":"```\r\n$ cargo tree -i -p encoding\r\nencoding v0.2.33\r\n└── bat v0.22.1\r\n └── git-delta v0.15.1\r\n```","createdAt":"2023-03-13T06:15:30Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/1347#issuecomment-1465573527","viewerDidAuthor":false}],"number":1347,"title":"RUSTSEC-2021-0153: `encoding` is unmaintained"},{"body":"I'm not sure how the internals work, but I noticed one thing that is slightly grating. I use tmux and zoom in and out a lot, so I run delta which will organically decide based on terminal size whether to page or put out raw output; this is fine, but when term is small, I'll get the pager, but then once I maximize the pane, only in the case when the new size is larger than the diff buffer, the pager automatically quits. **I have to manually re-run delta to see my diff again.** All I'd want is to disable this so that the pager stays open and just shows the diff in the whole terminal, because that's always always what I want it to do. If I wanted to look at the scrollback again I'll just hit `q`. \r\n\r\nI'm not sure if `less` is responsible, but if so I am pretty sure just a tweak to its flags would do the trick. Then all I need is to know how or where in the code to configure this. If it's some code that does this behavior, could you point me to where that is?","comments":[{"id":"IC_kwDOC4j8g85WAprB","author":{"login":"unphased"},"authorAssociation":"NONE","body":"Luckily I was able to quickly find the offending flag is probably hardcoded, it is the `--quit-if-one-screen` flag to less. See some discussion on it here: https://unix.stackexchange.com/questions/107315/less-quit-if-one-screen-without-no-init\r\n\r\nI really have no interest in deeply configuring less to be smarter, and would just prefer an option added so that we can opt out of the use of `quit-if-one-screen`. Having the inconsistency of diff output showing up as regular terminal output when it is short and having it run and not show in scrollback at all if it is not short enough, is worse than just making it open less and take up the whole screen in alternate mode every single time. ","createdAt":"2023-02-24T07:53:43Z","includesCreatedEdit":true,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/1308#issuecomment-1443011265","viewerDidAuthor":false},{"id":"IC_kwDOC4j8g85WArI0","author":{"login":"unphased"},"authorAssociation":"NONE","body":"Upon further searching I think https://github.com/dandavison/delta/issues/568#issuecomment-825546421 is a semi-solution. However, I plan not to close this until I figure out what `less` needs to be told to do the existing `--quit-if-one-screen` behavior but merely not kill itself once the screen expands to fit. The whole point about me expanding the screen is so I can read it, so it leading to the content being taken away from me is aggravating. ","createdAt":"2023-02-24T07:55:44Z","includesCreatedEdit":true,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/1308#issuecomment-1443017268","viewerDidAuthor":false},{"id":"IC_kwDOC4j8g85WA2dZ","author":{"login":"unphased"},"authorAssociation":"NONE","body":"Another update. So the problematic behavior is easily tested and confirmed as being part of `less` proper, so my apologies for assuming it was delta's fault at first. \r\n\r\nThe solution really is gonna look something like:\r\n- check if output fits in one screen in rust\r\n - if so, and as long as config doesn't say to always use paging, simply do not execute `less`\r\n - if not, call `less` without the `--quit-if-one-screen` flag (a flag that I now consider harmful)","createdAt":"2023-02-24T08:10:20Z","includesCreatedEdit":true,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/1308#issuecomment-1443063641","viewerDidAuthor":false}],"number":1308,"title":"🚀 Prevent less --quit-if-one-screen from auto-quitting when resizing terminal after opening."},{"body":"As of a `brew upgrade`, delta is panicking on every run, even if I build my own with `cargo install git-delta`. After poking around a bit I discovered that Homebrew had also upgraded `bat`, which was in turn unhappy with its cached styles. Rebuilding `bat`'s cache with `bat cache --build` got delta working again.\r\n\r\nThe backtrace from the failure: \r\n\r\n```\r\n$ RUST_BACKTRACE=1 .cargo/bin/delta\r\nthread 'main' panicked at 'capacity overflow', library/alloc/src/raw_vec.rs:518:5\r\nstack backtrace:\r\n 0: rust_begin_unwind\r\n at /rustc/69f9c33d71c871fc16ac445211281c6e7a340943/library/std/src/panicking.rs:575:5\r\n 1: core::panicking::panic_fmt\r\n at /rustc/69f9c33d71c871fc16ac445211281c6e7a340943/library/core/src/panicking.rs:65:14\r\n 2: alloc::raw_vec::capacity_overflow\r\n at /rustc/69f9c33d71c871fc16ac445211281c6e7a340943/library/alloc/src/raw_vec.rs:518:5\r\n 3: alloc::raw_vec::RawVec<T,A>::reserve::do_reserve_and_handle\r\n 4: <&mut bincode::de::Deserializer<R,O> as serde::de::Deserializer>::deserialize_string\r\n 5: <&mut bincode::de::Deserializer<R,O> as serde::de::Deserializer>::deserialize_map\r\n 6: bat::assets::asset_from_contents\r\n 7: bat::assets::HighlightingAssets::from_cache\r\n 8: delta::utils::bat::assets::load_highlighting_assets\r\n 9: delta::main\r\nnote: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.\r\n```\r\n\r\n[Full backtrace is here](https://gist.github.com/wlonkly/379bef78057a732a7a8f73d18eff6bad) if you need it. \r\n\r\nI don't know how delta could handle bat having an invalid cache, but I figured I should raise it in case I'm not the only person to encounter it.","comments":[],"number":1304,"title":"🐛 outdated bat cache led to delta panic"},{"body":"Delta always prints an empty line at the beginning of output. While the empty line between files or between hunks are useful for separating things, empty line at the beginning seems useless to me.\r\n\r\n```\r\n$ cat x.diff\r\n--- a.txt 2020-06-11 19:53:19.000000000 -0700\r\n+++ b.txt 2020-06-11 19:53:27.000000000 -0700\r\n@@ -1,3 +1,3 @@\r\n line 1\r\n\r\n-line 3\r\n+line 3.1\r\n\r\n$ cat x.diff | delta --no-gitconfig\r\n\r\na.txt ⟶ b.txt\r\n──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────\r\n\r\n───┐\r\n1: │\r\n───┘\r\nline 1\r\n\r\nline 3\r\nline 3.1\r\n\r\n$ cat x.diff | delta --no-gitconfig --file-style=omit\r\n\r\n───┐\r\n1: │\r\n───┘\r\nline 1\r\n\r\nline 3\r\nline 3.1\r\n```\r\nI suggest that we remove the empty line at the beginning. I'm ok with keep using empty lines to separate different files/hunks, although I'd like that to be configurable as well (but that's for a different issue).","comments":[{"id":"IC_kwDOC4j8g85XcvXw","author":{"login":"dandavison"},"authorAssociation":"OWNER","body":"Hm, yes I hadn't noticed this! I'd have to play around to see if I personally want to get rid of it, but I can definitely see that some people will whether or not I do. I will just say again that delta's output is for humans to look out, not for machines to parse, so IMO it should be whatever looks best to us, rather than whatever's most logically justifiable.\r\n\r\nOne source of new lines is https://github.com/dandavison/delta/blob/7c2740d08ef0b8b8d0c6cb8e3fc3b05dec748825/src/handlers/diff_header.rs#L284\r\nbut there's another somewhere.","createdAt":"2023-03-14T00:11:11Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/1295#issuecomment-1467151856","viewerDidAuthor":true}],"number":1295,"title":"🚀 Remove the redundant empty line at top of output"},{"body":"When using the --date option with git blame, delta does not color the output when the value is anything other than iso8601 or iso8601-local. E.g. `git blame --date=short FILENAME` does not produce colored output, while `git blame --date=iso8601 FILENAME` does.\r\n\r\n\r\n- [X] Please include the raw text output from git, so that we can reproduce the problem.\r\n (You can use `git --no-pager` to produce the raw text output.)\r\n```\r\nca769c23 (Wenxuan Zhang 2021-03-01 1) The MIT License (MIT)\r\nca769c23 (Wenxuan Zhang 2021-03-01 2) \r\nca769c23 (Wenxuan Zhang 2021-03-01 3) Copyright © 2017-2021 Wenxuan Zhang <wenxuangm@gmail.com>\r\nca769c23 (Wenxuan Zhang 2021-03-01 4) \r\nca769c23 (Wenxuan Zhang 2021-03-01 5) Permission is hereby granted, free of charge, to any person obtaining a copy\r\nca769c23 (Wenxuan Zhang 2021-03-01 6) of this software and associated documentation files (the “Software”), to deal\r\nca769c23 (Wenxuan Zhang 2021-03-01 7) in the Software without restriction, including without limitation the rights\r\nca769c23 (Wenxuan Zhang 2021-03-01 8) to use, copy, modify, merge, publish, distribute, sublicense, and/or sell\r\nca769c23 (Wenxuan Zhang 2021-03-01 9) copies of the Software, and to permit persons to whom the Software is\r\nca769c23 (Wenxuan Zhang 2021-03-01 10) furnished to do so, subject to the following conditions:\r\nca769c23 (Wenxuan Zhang 2021-03-01 11) \r\nca769c23 (Wenxuan Zhang 2021-03-01 12) The above copyright notice and this permission notice shall be included in\r\nca769c23 (Wenxuan Zhang 2021-03-01 13) all copies or substantial portions of the Software.\r\nca769c23 (Wenxuan Zhang 2021-03-01 14) \r\nca769c23 (Wenxuan Zhang 2021-03-01 15) THE SOFTWARE IS PROVIDED “AS IS”, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR\r\nca769c23 (Wenxuan Zhang 2021-03-01 16) IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,\r\nca769c23 (Wenxuan Zhang 2021-03-01 17) FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE\r\nca769c23 (Wenxuan Zhang 2021-03-01 18) AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER\r\nca769c23 (Wenxuan Zhang 2021-03-01 19) LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,\r\nca769c23 (Wenxuan Zhang 2021-03-01 20) OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN\r\nca769c23 (Wenxuan Zhang 2021-03-01 21) THE SOFTWARE.\r\n```\r\n\r\n- [X] A screenshot of Delta's output is often helpful also.\r\n\r\nI've created an asciinema here:\r\n\r\n[](https://asciinema.org/a/550820)\r\n","comments":[{"id":"IC_kwDOC4j8g85soNA7","author":{"login":"stevielavern"},"authorAssociation":"NONE","body":"Not sure if this helps, but `delta` supports this option:\r\n\r\n```\r\n --blame-timestamp-output-format <FMT>\r\n Format string for git blame timestamp output.\r\n\r\n This string is used for formatting the timestamps in git blame output. It must follow the `strftime` format syntax specification. If it is not present, the timestamps will be formatted in a human-friendly but possibly less accurate form.\r\n\r\n See: (https://docs.rs/chrono/latest/chrono/format/strftime/index.html)\r\n```\r\n\r\nFor instance, to have absolute dates by default, put this in `.gitconfig`:\r\n\r\n```\r\n[delta]\r\n blame-timestamp-output-format = %c\r\n```","createdAt":"2023-11-22T10:15:55Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/1278#issuecomment-1822478395","viewerDidAuthor":false},{"id":"IC_kwDOC4j8g86Jv5ah","author":{"login":"dvermd"},"authorAssociation":"CONTRIBUTOR","body":"Using the `-t` option also doesn't produce colored output","createdAt":"2024-08-26T20:31:54Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/1278#issuecomment-2311034529","viewerDidAuthor":false},{"id":"IC_kwDOC4j8g86JwQGV","author":{"login":"dvermd"},"authorAssociation":"CONTRIBUTOR","body":"The timestamp on the blame line is parsed with [this regex](https://github.com/dandavison/delta/blob/main/src/handlers/blame.rs#L197) which parses the timestamp as `[0-9]{4}-[0-9]{2}-[0-9]{2}\\ [0-9]{2}:[0-9]{2}:[0-9]{2}\\ [-+][0-9]{4}`.\r\n\r\nThere are many standard formats for `--date` parameter. These and the `-t` option could be tried alternatively with one or many regex but the `--date=format:...` won't be parseable this way.","createdAt":"2024-08-26T21:25:37Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/1278#issuecomment-2311127445","viewerDidAuthor":false},{"id":"IC_kwDOC4j8g86LSU2a","author":{"login":"th1000s"},"authorAssociation":"COLLABORATOR","body":"The regex should accept more formats with #925, but supporting the various `--date` options needs more robust parsing.","createdAt":"2024-09-08T21:56:33Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/1278#issuecomment-2336837018","viewerDidAuthor":false}],"number":1278,"title":"🐛 When using --date with git blame delta, the output is not colored"},{"body":"The merge conflict display in Delta is fantastic and really helps when resolving complex conflicts in Git. I've recently started using `diff3` in my personal dotfiles repo to pull external file changes using `diff3 --merge`. When there are conflicts, this creates equivalent output to git conflicts (with the `merge.conflictStyle` option set to `diff3`), except that the labels default to the filenames of the files being compared and can be customized with the `--label` option. It seems like Delta's parsing of conflict marker labels is specific to Git's output, so it doesn't attempt to parse the more general markers possible with directly using `diff3`.\r\n\r\n\r\n\r\nWould it be possible to generalize the parsing of conflict marker labels so that this output could be shown like Git conflicts?","comments":[],"number":1276,"title":"🚀 Support conflicts from `diff3 --merge` output"},{"body":"Lines like `@@ @@` crash delta:\r\n\r\n```\r\necho \"@@ @@\\n\" | RUST_BACKTRACE=full delta\r\nthread 'main' panicked at 'index out of bounds: the len is 0 but the index is 0', src/features/line_numbers.rs:188:28\r\nstack backtrace:\r\n 0: 0x1043dc5f4 - <std::sys_common::backtrace::_print::DisplayBacktrace as core::fmt::Display>::fmt::h71d20ef014883dc3\r\n 1: 0x1043f4584 - core::fmt::write::hd114a9636e34e383\r\n 2: 0x1043c73b0 - std::io::Write::write_fmt::h05898edc92938c00\r\n 3: 0x1043cc61c - std::panicking::default_hook::{{closure}}::hbd40827d346a3df4\r\n 4: 0x1043cc2ac - std::panicking::default_hook::hf2e0d2c157a06c84\r\n 5: 0x1043cce40 - std::panicking::rust_panic_with_hook::h33fd2dae40c879df\r\n 6: 0x1043dcd50 - std::panicking::begin_panic_handler::{{closure}}::h81ef06081ce645db\r\n 7: 0x1043dc730 - std::sys_common::backtrace::__rust_end_short_backtrace::hc514eeb5ddb8eaf3\r\n 8: 0x1043cca60 - _rust_begin_unwind\r\n 9: 0x10440adc8 - core::panicking::panic_fmt::h520fb0ef56e6cee7\r\n 10: 0x10440ad38 - core::panicking::panic_bounds_check::hde40779dd2c2d133\r\n 11: 0x1041cbd9c - delta::features::line_numbers::LineNumbersData::initialize_hunk::haf94d2662d9d42ca\r\n 12: 0x10423c0fc - delta::handlers::hunk::<impl delta::delta::StateMachine>::handle_hunk_line::h2ada95a2c0f7de1d\r\n 13: 0x10423720c - delta::delta::delta::hecc571c151b5ea45\r\n 14: 0x1041d88dc - delta::main::h61fdfe5805657fec\r\n 15: 0x10424bd50 - std::sys_common::backtrace::__rust_begin_short_backtrace::h1036dd8be6111153\r\n 16: 0x1041da734 - std::rt::lang_start::{{closure}}::h918f7bf93157e659\r\n 17: 0x1043cb550 - std::rt::lang_start_internal::h3f58ab0124dae34f\r\n 18: 0x1041d9410 - _main\r\n```","comments":[{"id":"IC_kwDOC4j8g85SZgkV","author":{"login":"dandavison"},"authorAssociation":"OWNER","body":"Thanks @adamchainz. What delta version is this? It doesn't seem to reproduce on master or `0.15.1` (MacOS).","createdAt":"2023-01-13T21:35:05Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/1275#issuecomment-1382418709","viewerDidAuthor":true},{"id":"IC_kwDOC4j8g85ScCuI","author":{"login":"adamchainz"},"authorAssociation":"CONTRIBUTOR","body":"0.15.1 on macOS from homebrew `¯\\_(ツ)_/¯`","createdAt":"2023-01-15T08:01:54Z","includesCreatedEdit":true,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/1275#issuecomment-1383082888","viewerDidAuthor":false},{"id":"IC_kwDOC4j8g85UJYpD","author":{"login":"adamchainz"},"authorAssociation":"CONTRIBUTOR","body":"Just had a thought this could be config related, but it still occurred when I emptied my git config file.","createdAt":"2023-02-01T09:38:22Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/1275#issuecomment-1411746371","viewerDidAuthor":false},{"id":"IC_kwDOC4j8g85-wLqF","author":{"login":"djfpaagman"},"authorAssociation":"NONE","body":"This also happens to me at 0.17.0 (mac os 14.4.1). Any more info I can give you to reproduce or debug?\r\n\r\n```\r\n❯ echo \"@@ @@\\n\" | RUST_BACKTRACE=full delta\r\nthread 'main' panicked at src/features/line_numbers.rs:189:28:\r\nindex out of bounds: the len is 0 but the index is 0\r\nstack backtrace:\r\n 0: 0x100aa27d0 - <std::sys_common::backtrace::_print::DisplayBacktrace as core::fmt::Display>::fmt::hc44f794219052ac6\r\n 1: 0x100ad01cc - core::fmt::write::h3be8b1c9593e07b4\r\n 2: 0x100ab9e28 - std::io::Write::write_fmt::h95a1e6c5537a96b5\r\n 3: 0x100aa2628 - std::sys_common::backtrace::print::h7b809dd1f18ea674\r\n 4: 0x100abbb00 - std::panicking::default_hook::{{closure}}::he339b0dd23f9052e\r\n 5: 0x100abb880 - std::panicking::default_hook::he9ee42fa25c512f5\r\n 6: 0x100abbf24 - std::panicking::rust_panic_with_hook::hd4ada112570991e5\r\n 7: 0x100aa2db4 - std::panicking::begin_panic_handler::{{closure}}::h3f2b6a80c2b7e617\r\n 8: 0x100aa2a04 - std::sys_common::backtrace::__rust_end_short_backtrace::hc0b94e2951df3fae\r\n 9: 0x100abbcb4 - _rust_begin_unwind\r\n 10: 0x100aef454 - core::panicking::panic_fmt::h0ed3af01737be6a9\r\n 11: 0x100aef5ac - core::panicking::panic_bounds_check::hd8547d2ac1a831c3\r\n 12: 0x1008b1cac - delta::features::line_numbers::LineNumbersData::initialize_hunk::ha540dfa9eecf285c\r\n 13: 0x100868f88 - delta::handlers::hunk::<impl delta::delta::StateMachine>::handle_hunk_line::h3068406ab506a6e2\r\n 14: 0x1008626d8 - delta::delta::delta::h2c1a49e16f3eea11\r\n 15: 0x1007f9b9c - delta::main::h38c636a1694eb0dc\r\n 16: 0x1007ee14c - std::sys_common::backtrace::__rust_begin_short_backtrace::h661dafcb61988808\r\n 17: 0x10086066c - std::rt::lang_start::{{closure}}::hc3fb063017debeeb\r\n 18: 0x100abbba0 - std::panicking::try::h3128bce4d588bc41\r\n 19: 0x100aa4b58 - std::rt::lang_start_internal::h57a49fa80dd8b904\r\n 20: 0x1007fba60 - _main\r\n```","createdAt":"2024-05-23T08:44:06Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/1275#issuecomment-2126559877","viewerDidAuthor":false},{"id":"IC_kwDOC4j8g85-84-X","author":{"login":"bash"},"authorAssociation":"CONTRIBUTOR","body":"I'm able to reproduce this on 0.17.0 after realizing that in my case, `echo` doesn't interpret backslash escapes by default 😅 \r\n\r\nAlso to get this exact panic, I had to enable `--line-numbers`.\r\n\r\n``` shell\r\necho -e '@@ @@\\n' | delta --line-numbers\r\n#\t ^^ enables interpretation of backslash escapes\r\n```\r\ngives me the same panic as above\r\n```\r\nthread 'main' panicked at src/features/line_numbers.rs:189:28:\r\nindex out of bounds: the len is 0 but the index is 0\r\n[...]\r\n```\r\n\r\nhowever, \r\n```shell\r\necho -e '@@ @@\\n' | delta\r\n```\r\n\r\nalso panics:\r\n\r\n```\r\nthread 'main' panicked at src/handlers/hunk_header.rs:250:28:\r\nindex out of bounds: the len is 0 but the index is 18446744073709551615\r\nstack backtrace:\r\n 0: _rust_begin_unwind\r\n 1: core::panicking::panic_fmt\r\n 2: core::panicking::panic_bounds_check\r\n 3: delta::handlers::hunk_header::write_line_of_code_with_optional_path_and_line_number\r\n 4: delta::handlers::hunk::<impl delta::delta::StateMachine>::handle_hunk_line\r\n 5: delta::delta::delta\r\n 6: delta::run_app\r\n 7: delta::main\r\nnote: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.\r\n```\r\n\r\n<details>\r\n<summary>with <code>RUST_BACKTRACE=full</code></summary>\r\n\r\n```\r\nthread 'main' panicked at src/handlers/hunk_header.rs:250:28:\r\nindex out of bounds: the len is 0 but the index is 18446744073709551615\r\nstack backtrace:\r\n 0: 0x103ea5886 - <std::sys_common::backtrace::_print::DisplayBacktrace as core::fmt::Display>::fmt::h5a9170f5fa9c9196\r\n 1: 0x103ebf5c3 - core::fmt::write::h66c46d4071227f75\r\n 2: 0x103ea8418 - std::io::Write::write_fmt::h576278b35a26d786\r\n 3: 0x103ea5679 - std::sys_common::backtrace::print::h11b96b76f3deab56\r\n 4: 0x103ea04c5 - std::panicking::default_hook::{{closure}}::hfea0a17440cb1db1\r\n 5: 0x103ea028f - std::panicking::default_hook::h3e23540ac34400d6\r\n 6: 0x103ea0918 - std::panicking::rust_panic_with_hook::h57a36a01071288aa\r\n 7: 0x103ea5e56 - std::panicking::begin_panic_handler::{{closure}}::h7719ce189a527545\r\n 8: 0x103ea5ae9 - std::sys_common::backtrace::__rust_end_short_backtrace::h978f9bd304ed474f\r\n 9: 0x103ea0672 - _rust_begin_unwind\r\n 10: 0x103ee0d65 - core::panicking::panic_fmt::hd9616c81c532c5b3\r\n 11: 0x103ee0f16 - core::panicking::panic_bounds_check::h1db59cdb31e714d4\r\n 12: 0x103c1009d - delta::handlers::hunk_header::write_line_of_code_with_optional_path_and_line_number::hebe0d84240a3defe\r\n 13: 0x103c42fa4 - delta::handlers::hunk::<impl delta::delta::StateMachine>::handle_hunk_line::h8b8e4cc8450dba0e\r\n 14: 0x103c39d1c - delta::delta::delta::hca15eecbf525e509\r\n 15: 0x103c01460 - delta::run_app::h00517eb25dd3027b\r\n 16: 0x103bfe72d - delta::main::h5a36e82a6653c374\r\n 17: 0x103c03aa6 - std::sys_common::backtrace::__rust_begin_short_backtrace::hd049ed607ac042fe\r\n 18: 0x103be3561 - std::rt::lang_start::{{closure}}::h6837e39aa9f6b9d6\r\n 19: 0x103ea0564 - std::panicking::try::hd88751af4d445ecd\r\n 20: 0x103e9bade - std::rt::lang_start_internal::hdaaea2403d56144b\r\n 21: 0x103c0345c - _main\r\n 22: 0x7ff8165e141f - <unknown>\r\n```\r\n\r\n</details","createdAt":"2024-05-24T16:02:07Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[{"content":"THUMBS_UP","users":{"totalCount":1}}],"url":"https://github.com/dandavison/delta/issues/1275#issuecomment-2129891223","viewerDidAuthor":false}],"number":1275,"title":"🐛 index out of bounds crash with malformed patch"},{"body":"Related to #729, tabs or matches following tabs are highlighted incorrectly when piping rg output to delta:\r\n<img width=\"494\" alt=\"image\" src=\"https://user-images.githubusercontent.com/16717303/211015377-1cbad4cc-b638-4a4e-9744-6178fa14b98d.png\">\r\n\r\nA minimal example:\r\n<img width=\"260\" alt=\"image\" src=\"https://user-images.githubusercontent.com/16717303/211013891-5be7c3ef-3c54-403b-b8d4-141f4414e0f4.png\">\r\n`test` is this text file (whitespace replaced for visibility):\r\n```\r\n❯ cat test |sed 's/\\t/->/g' |sed 's/ /␣/g'\r\n->tab\r\n␣1␣space\r\n␣␣␣␣4␣space\r\n```\r\n\r\nLooks like delta treats tab as single space for highlighting purposes:\r\n<img width=\"682\" alt=\"image\" src=\"https://user-images.githubusercontent.com/16717303/211015088-0f5c8b6d-7aac-4879-98a2-c7732521af33.png\">\r\n\r\nMisc:\r\n```sh\r\n❯ delta --version\r\ndelta 0.15.1\r\n\r\n❯ git config --get-regexp 'delta.*'\r\ndelta.line-numbers true\r\ndelta.syntax-theme gruvbox-dark\r\ndelta.side-by-side true\r\n\r\n❯ rg --version\r\nripgrep 13.0.0\r\n-SIMD -AVX (compiled)\r\n\r\n❯ fish --version\r\nfish, version 3.5.1\r\n\r\n❯ kitty --version\r\nkitty 0.26.5 created by Kovid Goyal\r\n\r\n❯ uname -mprsv\r\nDarwin 22.2.0 Darwin Kernel Version 22.2.0: Fri Nov 11 02:03:51 PST 2022; root:xnu-8792.61.2~4/RELEASE_ARM64_T6000 arm64 arm\r\n```","comments":[],"number":1272,"title":"🐛 Tabs are highlighted incorrectly"},{"body":"- [X] Please include the raw text output from git, so that we can reproduce the problem.\r\n (You can use `git --no-pager` to produce the raw text output.)\r\n- [X] A screenshot of Delta's output is often helpful also.\r\n\r\nHere are two files which when diff'ed should (as far as I understand) trigger the `--plus-empty-line-marker-style` style:\r\n\r\n~~~bash\r\ncat <<EOF > test.1\r\na\r\nb\r\nEOF\r\ncat <<EOF > test.2\r\na\r\n\r\nb\r\nEOF\r\n~~~\r\n\r\n~~~bash\r\n$ diff -u test.1 test.2\r\n--- test.1 2023-01-04 13:14:12.095414000 -0500\r\n+++ test.2 2023-01-04 13:14:34.046515000 -0500\r\n@@ -1,2 +1,3 @@\r\n a\r\n+\r\n b\r\n~~~\r\n\r\nDefault delta output (**as expected**) (`diff -u test.1 test.2 |delta --no-gitconfig`): \r\n\r\n\r\nDelta output with no background for plus lines (**as expected**) (`diff -u test.1 test.2 |delta --no-gitconfig --plus-style=green`): \r\n\r\n\r\nDelta output with with no background for plus lines, and `--plus-empty-line-marker-style` set (**bug?**): (`diff -u test.1 test.2 |delta --no-gitconfig --plus-style=green --plus-empty-line-marker-style=\"yellow yellow\"`): \r\n\r\n\r\n`minus-empty-line-marker-style` does not seem to work either: `diff -u test.2 test.1 | delta --no-gitconfig --plus-style=green --minus-style=red --plus-empty-line-marker-style=\"yellow yellow\" --minus-empty-line-marker-style=\"yellow yellow\"`\r\n\r\n\r\n\r\nDelta version: latest release (0.15.1)\r\nTerminal: Windows Terminal 1.15.3467 \r\nSSH: OpenSSH_for_Windows_8.9p1\r\nRemote OS: RHEL 8,3\r\n","comments":[{"id":"IC_kwDOC4j8g85Xw5eH","author":{"login":"waldyrious"},"authorAssociation":"CONTRIBUTOR","body":"I'm facing the same issue. I might be misremembering, but I'm pretty sure this used to work in the past :thinking:","createdAt":"2023-03-16T17:45:11Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/1271#issuecomment-1472436103","viewerDidAuthor":false}],"number":1271,"title":"🐛 Can't get `--plus-empty-line-marker-style` / `--minus-empty-line-marker-style` to work "},{"body":"- [X] Please include the raw text output from git, so that we can reproduce the problem.\r\n (You can use `git --no-pager` to produce the raw text output.)\r\n\r\nN/A\r\n\r\n- [X] A screenshot of Delta's output is often helpful also.\r\n\r\nN/A\r\n\r\n---\r\n\r\nWhen testing command invocations, I often use `HOME= some-command ...` so that my specific configuration for `some-command` is not used (this is useful to test bug reports and come up with reproducible bug reports ;)\r\n\r\nThis does not work with delta:\r\n\r\n~~~bash\r\n$ ./delta-0.15.1-x86_64-unknown-linux-musl/delta --version\r\n0.15.1\r\n$ HOME= ./delta-0.15.1-x86_64-unknown-linux-musl/delta --version\r\nthread 'main' panicked at 'Could not get home directory', src/utils/bat/dirs.rs:40:49\r\nnote: run with `RUST_BACKTRACE=1` environment variable to display a backtrace\r\n~~~\r\n\r\nAdding `RUST_BACKTRACE=full` does not give helpful details for the musl binary from the GitHub releases.","comments":[{"id":"IC_kwDOC4j8g85RvBO7","author":{"login":"phil-blain"},"authorAssociation":"CONTRIBUTOR","body":"I found I can get the same result with `--no-gitconfig`, but still it would be nice if it didn't panick as above :)","createdAt":"2023-01-04T18:32:57Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/1270#issuecomment-1371280315","viewerDidAuthor":false},{"id":"IC_kwDOC4j8g85SZirt","author":{"login":"dandavison"},"authorAssociation":"OWNER","body":"Hm, I'm failing to reproduce this (MacOS). More concerningly, at first glance, I don't see how it can happen! The `new()` function always returns `Some(..)` hence `panic(...)` should never be called. https://github.com/dandavison/delta/blob/ce6448f9c3e8e61d06127c62ee775f9372bc1c34/src/utils/bat/dirs.rs#L40","createdAt":"2023-01-13T21:45:18Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/1270#issuecomment-1382427373","viewerDidAuthor":true},{"id":"IC_kwDOC4j8g85SZnvr","author":{"login":"phil-blain"},"authorAssociation":"CONTRIBUTOR","body":"Hi @dandavison :) thanks for your answer. Indeed, it does not happen on macOS for me either. \r\n\r\nIt also does not happen on Ubuntu 22 with either the `delta-0.15.1-x86_64-unknown-linux-gnu` binary or the `*-musl` one.\r\n\r\nIt does not happen either on Ubuntu 18 or 20 with the `*-musl` binary (the `*-gnu` binary does not work on these platforms, I get errors from `/lib/x86_64-linux-gnu/libc.so.6` about ``version `GLIBC_2.N' not found`` with `N=28,29,32,33,34` for Ubuntu 18 and `N=32,33,34` for Ubuntu 20). \r\n\r\nBut it _does_ happen on RHEL 8, which is the distro I use, with the `musl` binary (the `gnu` binary fails as above with `N=29,32,33,34`).","createdAt":"2023-01-13T22:09:01Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/1270#issuecomment-1382448107","viewerDidAuthor":false},{"id":"IC_kwDOC4j8g85SbUQT","author":{"login":"dandavison"},"authorAssociation":"OWNER","body":"Hm, that's exciting. Does it happen to bat also?","createdAt":"2023-01-14T19:15:05Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/1270#issuecomment-1382892563","viewerDidAuthor":true},{"id":"IC_kwDOC4j8g85SbYbT","author":{"login":"phil-blain"},"authorAssociation":"CONTRIBUTOR","body":"Yes, on the RHEL8 system I'm testing on, it also happens with the `bat-v0.22.1` musl binary:\r\n```\r\n$ HOME= ./bat-v0.22.1-x86_64-unknown-linux-musl/bat --version\r\nthread 'main' panicked at 'Could not get home directory', src/bin/bat/directories.rs:72:40\r\nnote: run with `RUST_BACKTRACE=1` environment variable to display a backtrace\r\n```\r\n\r\nbut not with the gnu binary. And (sidenote), the musl and gnu bat binaries work correctly for Ubuntu 18-22 (no error message relating to `GLIBC_2.*`).\r\n\r\nOne other \"exciting\" thing is that I am not yet able to reproduce on my WSL 2 RHEL 8 instance (WSL=Windows Subsystem for Linux). ","createdAt":"2023-01-14T20:29:36Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/1270#issuecomment-1382909651","viewerDidAuthor":false},{"id":"IC_kwDOC4j8g85SbjSs","author":{"login":"phil-blain"},"authorAssociation":"CONTRIBUTOR","body":"So I compiled myself a debug version of delta: https://github.com/phil-blain/delta/releases/tag/0.15.2 and took a look at what happens in GDB:\r\n~~~\r\nHOME= gdb -d ~/code/delta \\\r\n -ex 'handle SIG34 nostop' \\\r\n -ex 'b BatProjectDirs::new' \\\r\n -ex run \\\r\n --args delta-0.15.2-x86_64-unknown-linux-musl/delta --version\r\n~~~\r\n\r\nI _think_ (it's my first experience with Rust) that the panic happens because `map` is called on `cache_dir_op` which is `None` since HOME is unset.\r\n\r\nHere is my debugging session:\r\n~~~\r\ngdb: warning: Couldn't determine a path for the index cache directory.\r\nReading symbols from delta-0.15.2-x86_64-unknown-linux-musl/delta...\r\nwarning: Missing auto-load script at offset 0 in section .debug_gdb_scripts\r\nof file /fs/homeu2/eccc/cmd/ords/cmde/phb001/logiciels/delta-0.15.2-x86_64-unknown-linux-musl/delta.\r\nUse `info auto-load python-scripts [REGEXP]' to list them.\r\nSignal Stop Print Pass to program Description\r\nSIG34 No Yes Yes Real-time event 34\r\nBreakpoint 1 at 0x132ed0: file src/utils/bat/dirs.rs, line 26.\r\nStarting program: /fs/homeu2/eccc/cmd/ords/cmde/phb001/logiciels/delta-0.15.2-x86_64-unknown-linux-musl/delta --version\r\n[New LWP 3505583]\r\n[New LWP 3505584]\r\n\r\nThread 1 \"delta\" received signal SIG34, Real-time event 34.\r\n\r\nThread 3 \"ctrl-c\" received signal SIG34, Real-time event 34.\r\n\r\nThread 1 \"delta\" hit Breakpoint 1, delta::utils::bat::dirs::BatProjectDirs::new () at src/utils/bat/dirs.rs:26\r\nwarning: Source file is more recent than executable.\r\n26 let cache_dir_op = dirs_next::cache_dir();\r\n(gdb) n\r\n28 let cache_dir = cache_dir_op.map(|d| d.join(\"bat\"))?;\r\n(gdb) p cache_dir_op\r\n$1 = core::option::Option<std::path::PathBuf>::None\r\n(gdb) n\r\n[LWP 3505583 exited]\r\n28 let cache_dir = cache_dir_op.map(|d| d.join(\"bat\"))?;\r\n(gdb) n\r\n31 }\r\n(gdb) n\r\nthread 'main' panicked at 'Could not get home directory', src/utils/bat/dirs.rs:40:49\r\nnote: run with `RUST_BACKTRACE=1` environment variable to display a backtrace\r\n[LWP 3505584 exited]\r\n[Inferior 1 (process 3505563) exited with code 0145]\r\n(gdb) quit\r\n~~~\r\nNotice one thread exits after the line `let cache_dir = cache_dir_op.map(|d| d.join(\"bat\"))?;` is executed, but the panic is triggered when leaving the function...","createdAt":"2023-01-14T22:50:06Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/1270#issuecomment-1382954156","viewerDidAuthor":false},{"id":"IC_kwDOC4j8g85So5nx","author":{"login":"phil-blain"},"authorAssociation":"CONTRIBUTOR","body":"So on my WSL system (which does not panic), `cache_dir_op` is _not_ `None`:\r\n\r\n~~~\r\n(gdb) p cache_dir_op\r\n$2 = core::option::Option<std::path::PathBuf>::Some(std::path::PathBuf {inner: std::ffi::os_str::OsString {inner: std::sys::unix::os_str::Buf {inner: alloc::vec::Vec<u8, alloc::alloc::Global> {buf: alloc::raw_vec::RawVec<u8, alloc::alloc::Global> {ptr: core::ptr::unique::Unique<u8> {pointer: core::ptr::non_null::NonNull<u8> {pointer: 0x90dcda0 \"\\230:\\355\\b\\000\"}, _marker: core::marker::PhantomData<u8>}, cap: 28, alloc: alloc::alloc::Global}, len: 21}}}})\r\n~~~\r\n\r\nAnd I _think_ this is because on the system where I hit the panic, my home directory is a symlink. \r\n\r\n- [`dirs_next::cache_dir` is a simple wrapper around `sys::cache_dir`](https://docs.rs/dirs-next/latest/src/dirs_next/lib.rs.html#77-79)\r\n- [`sys` is `dirs_next::lin` on Linux](https://docs.rs/dirs-next/latest/src/dirs_next/lib.rs.html#31-33)\r\n- [`dirs_next::lin::cache_dir` calls `dirs_next::lin::home_dir`](https://docs.rs/dirs-next/latest/src/dirs_next/lin.rs.html#5)\r\n- [`dirs_next::lin::home_dir` calls `dirs_sys_next::home_dir`](https://docs.rs/dirs-next/latest/src/dirs_next/lin.rs.html#4)\r\n- [`dirs_sys_next::home_dir` calls `libc::getpwuid_r`](https://docs.rs/dirs-sys-next/latest/src/dirs_sys_next/lib.rs.html#28-60) if `HOME` is empty to query the system database\r\n- this calls returns `None` on the affected system. I think that'a bug; it should find my home directory in the database...","createdAt":"2023-01-18T04:03:09Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/1270#issuecomment-1386453489","viewerDidAuthor":false}],"number":1270,"title":"🐛 delta `panick`s when HOME is unset (on RHEL 8, with musl binary)"},{"body":"#237 changed delta to duplicate less’ history file before handing over. I find this surprising as it means one cannot recall searches from even previous delta invocations.\r\n\r\nFor example:\r\n\r\n1. Run `git log` through delta, search for specific commits with `/^author: adam`.\r\n2. Don't find intended commits, quit.\r\n3. Switch to the right branch.\r\n4. Run `git log` agani, type `/` then up-arrow to find past search - but it's not there.\r\n5. Have to type out `/^author: adam` accurately again.\r\n\r\nI propose the implementation changes in one of two ways:\r\n\r\n1. Edit the user's default history file in-place to add the navigate search regex (or move to bottom). I didn’t spot the reason this option wasn’t taken previously. Editing the less history file just a bit doesn’t seem as bad as duplicating it.\r\n2. Duplicate the user’s less history file to `~/.local/share/delta/lesshst` *only* if there isn’t a duplicate already. Otherwise, only edit the duplicate file, to append/move the navigate search string at/to the end.\r\n\r\nEither option would make delta lesses share history. The first would share with other lesses, which is “less” of a win imo.","comments":[{"id":"IC_kwDOC4j8g85Q11c3","author":{"login":"dandavison"},"authorAssociation":"OWNER","body":"Hi @adamchainz, thanks, although #237 was a big advance (being able to leave `navigate` activated and start using it without thinking), I've also been wanting to improve things so that my history is not lost.\r\n\r\nIs this something you might be interested in working on? I haven't thought through the design options thoroughly, but I think one fixed premise I'd like to propose is that no non-delta less usage should ever see the automatically-generated delta regexps in less history.\r\n\r\nI'm trying to remember the exact usage patterns that have bothered me. The one you describe certainly. I wonder whether I _do_ in fact want delta less to share history with other less usage, much as if one had done `git ... | delta | less`. I'll watch my own usage.\r\n\r\ncc @cben @Kr1ss-XD ","createdAt":"2022-12-17T14:34:01Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/1261#issuecomment-1356289847","viewerDidAuthor":true},{"id":"IC_kwDOC4j8g85Roc4L","author":{"login":"adamchainz"},"authorAssociation":"CONTRIBUTOR","body":"> non-delta less usage should ever see the automatically-generated delta regexps in less history.\r\n\r\nWhy stick to this? It's only one regexp. I don't think it's that troublesome to insert it into the normal less history.\r\n\r\n> Is this something you might be interested in working on?\r\n\r\nReviewing yes, but writing no, I don't have much Rust experience or time to pick it up.","createdAt":"2023-01-03T09:37:52Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/1261#issuecomment-1369558539","viewerDidAuthor":false}],"number":1261,"title":"🐛 \"navigate\" makes less history transient"},{"body":"Debian 11 stable.\r\n\r\n```\r\n$ sudo dpkg -i /home/user/software/git-delta_0.15.1_amd64.deb \r\n(Reading database ... 197575 files and directories currently installed.)\r\nPreparing to unpack .../git-delta_0.15.1_amd64.deb ...\r\nUnpacking git-delta (0.15.1) over (0.14.0) ...\r\ndpkg: dependency problems prevent configuration of git-delta:\r\n git-delta depends on libc6 (>= 2.34); however:\r\n Version of libc6:amd64 on system is 2.31-13+deb11u5.\r\n\r\ndpkg: error processing package git-delta (--install):\r\n dependency problems - leaving unconfigured\r\nErrors were encountered while processing:\r\n git-delta\r\n```\r\n\r\nCurrent latest glibc6 installed:\r\n\r\n```\r\nPackage: libc6\r\nSource: glibc\r\nVersion: 2.31-13+deb11u4\r\n```","comments":[{"id":"IC_kwDOC4j8g85PqIB4","author":{"login":"dandavison"},"authorAssociation":"OWNER","body":"@DarkPark @baryluk what's the recommended course of action here?\r\n\r\nI saw you made this diagram: https://github.com/dandavison/delta/issues/1248#issuecomment-1336260157\r\n\r\n","createdAt":"2022-12-04T15:40:35Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/1250#issuecomment-1336443000","viewerDidAuthor":true},{"id":"IC_kwDOC4j8g85PqUUk","author":{"login":"baryluk"},"authorAssociation":"CONTRIBUTOR","body":"@DarkPark Could you try musl version. My guess is it is statically linked, and maybe it will work.\r\n\r\nAs far as I know the only reasonable option is to build on older version of Ubuntu or Debian, so minimal GLIBC ABI used is lower than 2.34. glibc does not support other methods.","createdAt":"2022-12-04T19:06:42Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/1250#issuecomment-1336493348","viewerDidAuthor":false},{"id":"IC_kwDOC4j8g85Pqe5j","author":{"login":"aureq"},"authorAssociation":"NONE","body":"@baryluk Installing `git-delta-musl_0.15.1_amd64.deb` works just fine, because the generated `control` file doesn't show any dependencies on `libc6 (>= 2.34)`. I think this could be a temporary workaround.\r\n\r\n@dandavison A possible way to address this would be to build `delta` on a `debian` image instead of `ubuntu-latest` (I think) so the dynamic reference uses an older version of `glibc`. Alternatively, `musl` could just become the default package.\r\n\r\n`control` (musl)\r\n```\r\nPackage: git-delta-musl\r\nVersion: 0.15.1\r\nSection: utils\r\nPriority: optional\r\nMaintainer: Dan Davison <dandavison7@gmail.com>\r\nArchitecture: amd64\r\nDepends: \r\nConflicts: delta\r\nDescription: Syntax highlighter for git\r\n Delta provides language syntax-highlighting, within-line insertion/deletion\r\n detection, and restructured diff output for git on the command line.\r\n```\r\n\r\n`control` (libc6)\r\n```\r\nPackage: git-delta\r\nVersion: 0.15.1\r\nSection: utils\r\nPriority: optional\r\nMaintainer: Dan Davison <dandavison7@gmail.com>\r\nArchitecture: amd64\r\nDepends: libc6 (>= 2.34), libgcc-s1 (>= 4.2), zlib1g (>= 1:1.1.4)\r\nConflicts: delta-musl\r\nDescription: Syntax highlighter for git\r\n Delta provides language syntax-highlighting, within-line insertion/deletion\r\n detection, and restructured diff output for git on the command line.\r\n```","createdAt":"2022-12-04T22:42:02Z","includesCreatedEdit":true,"isMinimized":false,"minimizedReason":"","reactionGroups":[{"content":"THUMBS_UP","users":{"totalCount":3}}],"url":"https://github.com/dandavison/delta/issues/1250#issuecomment-1336536675","viewerDidAuthor":false},{"id":"IC_kwDOC4j8g85QM0Fk","author":{"login":"den-is"},"authorAssociation":"NONE","body":"Same here. Broken install in `debian:bullseye` docker image, that I use in my VScode devcontainer setup. I don't need any fancy modern OSs.\r\n```\r\n#4 122.6 The following packages have unmet dependencies:\r\n#4 122.6 git-delta : Depends: libc6 (>= 2.34) but 2.31-13+deb11u5 is installed\r\n```\r\nmusl version works\r\n","createdAt":"2022-12-11T12:05:13Z","includesCreatedEdit":true,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/1250#issuecomment-1345536356","viewerDidAuthor":false},{"id":"IC_kwDOC4j8g85QNw8I","author":{"login":"dandavison"},"authorAssociation":"OWNER","body":"> A possible way to address this would be to build delta on a debian image instead of ubuntu-latest (I think) so the dynamic reference uses an older version of glibc. Alternatively, musl could just become the default package.\r\n\r\n@MarcoIeni do you have any thoughts on the right way forwards here?","createdAt":"2022-12-12T02:41:30Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/1250#issuecomment-1345785608","viewerDidAuthor":true},{"id":"IC_kwDOC4j8g85R80I3","author":{"login":"MarcoIeni"},"authorAssociation":"CONTRIBUTOR","body":"> A possible way to address this would be to build delta on a debian image\r\n\r\nGitHub doesn't offer a Debian image :/ \r\nSee [this](https://docs.github.com/en/actions/using-github-hosted-runners/about-github-hosted-runners#supported-runners-and-hardware-resources)\r\n\r\n> Alternatively, musl could just become the default package.\r\n\r\nYes, we can remove [git-delta_0.x.y_amd64.deb](https://github.com/dandavison/delta/releases/download/0.15.1/git-delta_0.15.1_amd64.deb) from the releases and make [git-delta-musl_0.x.y_amd64.deb](https://github.com/dandavison/delta/releases/download/0.15.1/git-delta-musl_0.15.1_amd64.deb) the default (by renaming it to `git-delta_0.x.y_amd64.deb`)","createdAt":"2023-01-08T18:21:27Z","includesCreatedEdit":true,"isMinimized":false,"minimizedReason":"","reactionGroups":[{"content":"THUMBS_UP","users":{"totalCount":1}}],"url":"https://github.com/dandavison/delta/issues/1250#issuecomment-1374896695","viewerDidAuthor":false},{"id":"IC_kwDOC4j8g85UlkJm","author":{"login":"eggbean"},"authorAssociation":"NONE","body":"Wouldn't just using the ubuntu 20.04 GitHub Actions runner work? Ubuntu 20.04 uses glibc 2.31. I can't use the latest version of delta on Debian instances, so I have switched to the musl build for the time being.","createdAt":"2023-02-06T14:05:02Z","includesCreatedEdit":true,"isMinimized":false,"minimizedReason":"","reactionGroups":[{"content":"THUMBS_UP","users":{"totalCount":2}}],"url":"https://github.com/dandavison/delta/issues/1250#issuecomment-1419133542","viewerDidAuthor":false},{"id":"IC_kwDOC4j8g85VvEO7","author":{"login":"lpanebr"},"authorAssociation":"NONE","body":"I've just installed on Ubuntu 20.04.5 LTS and got the same error:\r\n\r\n```shell\r\n❯ sudo dpkg -i git-delta_0.15.1_amd64.deb\r\nSelecting previously unselected package git-delta.\r\n(Reading database ... 356946 files and directories currently installed.)\r\nPreparing to unpack git-delta_0.15.1_amd64.deb ...\r\nUnpacking git-delta (0.15.1) ...\r\ndpkg: dependency problems prevent configuration of git-delta:\r\n git-delta depends on libc6 (>= 2.34); however:\r\n Version of libc6:amd64 on system is 2.31-0ubuntu9.9.\r\n\r\ndpkg: error processing package git-delta (--install):\r\n dependency problems - leaving unconfigured\r\nErrors were encountered while processing:\r\n git-delta\r\n```\r\n\r\nIt gets installed but fails:\r\n```shell\r\n❯ delta\r\ndelta: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.33' not found (required by delta)\r\ndelta: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.32' not found (required by delta)\r\ndelta: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.34' not found (required by delta)\r\n```\r\n\r\n**I tried building it from source but got errors:**\r\n\r\n\r\n\r\n**Any idea of how to get it running?**\r\n\r\n**Perhaps a docker image version?**","createdAt":"2023-02-21T12:30:51Z","includesCreatedEdit":true,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/1250#issuecomment-1438401467","viewerDidAuthor":false},{"id":"IC_kwDOC4j8g85VvQX8","author":{"login":"lpanebr"},"authorAssociation":"NONE","body":"Followup: \r\n\r\nI could install version `0.14.0` and it works:\r\n\r\n```shell\r\n❯ sudo dpkg -i git-delta-musl_0.14.0_amd64.deb\r\nSelecting previously unselected package git-delta-musl.\r\n(Reading database ... 356946 files and directories currently installed.)\r\nPreparing to unpack git-delta-musl_0.14.0_amd64.deb ...\r\nUnpacking git-delta-musl (0.14.0) ...\r\nSetting up git-delta-musl (0.14.0) ...\r\n```","createdAt":"2023-02-21T13:03:35Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[{"content":"THUMBS_UP","users":{"totalCount":2}}],"url":"https://github.com/dandavison/delta/issues/1250#issuecomment-1438451196","viewerDidAuthor":false},{"id":"IC_kwDOC4j8g85aYHrj","author":{"login":"dandavison"},"authorAssociation":"OWNER","body":"Superficial research: there's a similar bat issue https://github.com/sharkdp/bat/issues/2106 with possibly applicable fix https://github.com/sharkdp/bat/pull/2194","createdAt":"2023-04-20T12:50:50Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/1250#issuecomment-1516272355","viewerDidAuthor":true}],"number":1250,"title":"🐛 Problem with new release installation."},{"body":"When I started drafting out this issue, I thought it was a fairly simple one, but after some further testing, I think I might've stumbled on some quite odd behavior.\r\n\r\nAssuming a comparison of differing files;\r\n\r\n1. When `--paging auto` is used (which is the default):\r\n\r\n - If the diff fits into one screen, the exit code `1` is returned.\r\n ```console\r\n $ delta minus plus --paging auto\r\n minus ⟶ plus\r\n @@ -1 +1 @@\r\n 1 ⋮ │-hello\r\n ⋮ 1 │+world\r\n $ echo $?\r\n 1\r\n ```\r\n - But if the diff doesn't fit into one screen, and a pager is used, things get a little weird with the exit code `0`.\r\n ```console\r\n $ delta minus-large plus-large --paging auto\r\n // paginated //\r\n $ echo $?\r\n 0\r\n ```\r\n\r\n2. When `--paging never` is used, regardless of output size, we get the exit code 1.\r\n\r\n ```console\r\n $ delta minus plus --paging never\r\n minus ⟶ plus\r\n @@ -1 +1 @@\r\n 1 ⋮ │-hello\r\n ⋮ 1 │+world\r\n $ echo $?\r\n 1\r\n\r\n $ delta minus-large plus-large --paging never\r\n // snipped //\r\n $ echo $?\r\n 1\r\n ```\r\n\r\n3. With `--paging always`:\r\n\r\n - If the diff fits into one screen, the exit code `1` is returned.\r\n ```console\r\n $ delta minus plus --paging always\r\n // paginated //\r\n $ echo $?\r\n 1\r\n ```\r\n - But if the diff doesn't fit into one screen, and a pager is used:\r\n ```console\r\n $ delta minus-large plus-large --paging always\r\n // paginated //\r\n $ echo $?\r\n 0\r\n ```\r\n\r\nAnd one last thing I noticed with one file, but have been unable to reproduce with other files, is this.\r\n\r\nConsider `functions.sh` from https://github.com/miraclx/dotfiles/blob/9d4e18fdd2ac40f86167768cfa748413d17eeb70/functions.sh.\r\n\r\nIn comparison to a short file\r\n\r\n```console\r\n$ LANG=C tr -dc '[:alpha:]' < /dev/urandom | fold -w 40 | head -n30 > 30linefile\r\n$ delta functions.sh 30linefile\r\n // paginated //\r\n$ echo $?\r\n1\r\n$ delta 30linefile functions.sh\r\n // paginated //\r\n$ echo $?\r\n0\r\n```\r\n\r\nI tried reproducing this behavior with other pairs of large+small files, but have been unable to. Something with the `functions.sh` file, maybe? Unsure\r\n\r\nBut this behavior is not observed in comparison with larger files\r\n\r\n```console\r\n$ LANG=C tr -dc '[:alpha:]' < /dev/urandom | fold -w 40 | head -n400 > 400linefile\r\n$ delta functions.sh 400linefile\r\n // paginated //\r\n$ echo $?\r\n0\r\n$ delta 400linefile functions.sh\r\n // paginated //\r\n$ echo $?\r\n0\r\n```\r\n\r\nSince `functions.sh` is different from both `30linefile` and `400linefile`, I'd expect the exit code to be `1`, consistently.\r\n\r\nAnd well enough, `--paging never` makes it, so the exit code is `1`.\r\n\r\nRegardless of paging, I think the exit code should consistently reflect the status of the comparison.","comments":[{"id":"IC_kwDOC4j8g85PqKB0","author":{"login":"dandavison"},"authorAssociation":"OWNER","body":"Hi @miraclx, thanks for this! I haven't investigated this all / thought it through yet.\r\n\r\nRegarding the paging, one possibility is we could say that either\r\n\r\n- you are using a pager, hence you are not scripting, hence you don't get the shell exit code semantics of diff that are useful in a script.\r\n- you are not using a pager, hence delta promises to give the exit code semantics of diff.","createdAt":"2022-12-04T16:01:25Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/1246#issuecomment-1336451188","viewerDidAuthor":true},{"id":"IC_kwDOC4j8g85PuWMC","author":{"login":"miraclx"},"authorAssociation":"NONE","body":"> you are using a pager, hence you are not scripting\r\n\r\nWell, I was, but to be fair, one could classify mine as an edge-case.\r\n\r\nI defined a user-callable function.. lets call this `syncdelta`, that would pull updated state of a system, cache that to a file, and compare it with the most recent state before the update.\r\n\r\nIn doing this, it would show the user the diff through a pager. And wait for the user to exit out of the pager.\r\n\r\nIf there were no changes, (which is the case where we observe odd behaviour with delta), it then needs to delete the file we just downloaded, to avoid duplication.\r\n\r\n---\r\n\r\nBut at least for my use case, I just had to force `--paging never` in order to get the correct exit code.\r\n\r\nAnd then apply pagination outside the process.","createdAt":"2022-12-05T15:12:42Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/1246#issuecomment-1337549570","viewerDidAuthor":false}],"number":1246,"title":"🐛 Exit code inconsistencies with pagination"},{"body":"### Discussed in https://github.com/dandavison/delta/discussions/1230\r\n\r\n<div type='discussions-op-text'>\r\n\r\n<sup>Originally posted by **tg0h** November 7, 2022</sup>\r\n<img width=\"927\" alt=\"image\" src=\"https://user-images.githubusercontent.com/7954426/200239394-f15c5669-f6c0-4d1e-8f81-90d49de22131.png\">\r\n\r\n`git blame <file>` produces coloured output. However, when I pipe this to delta, `git blame <file> | delta` delta does not provide coloured output...\r\n\r\nI am not able to reproduce this behaviour with `git diff`.\r\n\r\nAm I supposed to do something with the --blame-code-style and related --blame options?</div>","comments":[{"id":"IC_kwDOC4j8g85N0YZa","author":{"login":"dandavison"},"authorAssociation":"OWNER","body":"Hi @tg0h, delta uses the filename to infer the language. (E.g. `foo.py` => Python, `bah.rs` => Rust). But the output of `git blame` does not contain the filename.\r\n\r\nHowever, the situation might not be hopeless. Delta does have [code that finds the command that was used when piping to delta](https://github.com/dandavison/delta/blob/master/src/utils/process.rs#L11-L19). Do you have any interest in writing Rust and would you like to have a go at making it work?","createdAt":"2022-11-07T12:56:50Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/1231#issuecomment-1305577050","viewerDidAuthor":true}],"number":1231,"title":"Why is git blame output not coloured when piped to delta?"},{"body":"Now file changes like \"file added\" or \"mode +x\" is printed in filename header by same color as everything in this header.\r\nBut instinctively I'm looking for changes in color of changes, especially scrolling through big commit with lot of information in it.\r\nPossibly it is good idea to highlight such thing in same way as other changes highlighted?\r\n","comments":[],"number":1225,"title":"🚀 File changes highlight"},{"body":"Line wrapping does not work for normal or blame view for now, so I come with other idea of shortening code lines.\r\nIs it possible to find shortest sequence of leading spaces in each hunk, and (if it is longer than 1 or 2) replace it with some character like \"⇥\" or any other? \r\nFor most situation diffed parts is somewhere in the middle of code and indented, but this indentation is mostly useless from perspective of viewing changes\r\n```\r\n30:30| while (count) {\r\n31:31| ssize_t rv = kernel_write(file, p, count, pos);\r\n32:32| if (rv < 0) { \r\n33: | if (rv == -EINTR)\r\n :33| if (rv == -EINTR || rv == -EAGAIN)\r\n34:34| continue;\r\n```\r\nwill look like \r\n```\r\n30:30|⇥while (count) {\r\n31:31|⇥ ssize_t rv = kernel_write(file, p, count, pos);\r\n32:32|⇥ if (rv < 0) { \r\n33: |⇥ if (rv == -EINTR)\r\n :33|⇥ if (rv == -EINTR || rv == -EAGAIN)\r\n34:34|⇥ continue;\r\n```\r\nWhile working with narrow columns (like in side-by-side view or in preview of fzf), every character counts. And removing even two useless spaces will be useful, and especially twelve","comments":[{"id":"IC_kwDOC4j8g85NGdoW","author":{"login":"dandavison"},"authorAssociation":"OWNER","body":"Hi @Prince-Mandor, that's an interesting idea.\r\n\r\nOne initial thing that comes to mind: does it bother you that successive hunks in the same function will have inconsistent alignment? E.g. below, the last line of the second hunk is the expression returned from the function whose definition is seen in the first hunk, and it's nice that it is indented in the way you'd expect relative to the `def` line. (I'm not arguing against the idea! And of course, it would be opt-in, not default.)\r\n\r\n\r\n<table>\r\n <tbody>\r\n <tr>\r\n <td><img width=\"700\" alt=\"image\" src=\"https://user-images.githubusercontent.com/52205/198295972-e52d588c-59e4-44c4-bccc-7da46842d8d3.png\">\r\n</td>\r\n </tr>\r\n </tbody>\r\n </table>\r\n","createdAt":"2022-10-27T13:37:37Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/1224#issuecomment-1293539862","viewerDidAuthor":true},{"id":"IC_kwDOC4j8g85NG9_y","author":{"login":"Prince-Mandor"},"authorAssociation":"NONE","body":"> Hi @Prince-Mandor, that's an interesting idea.\r\n\r\nHi! And thank you for great git pager!\r\n\r\n> One initial thing that comes to mind: does it bother you that successive hunks in the same function will have inconsistent alignment? E.g. below, the last line of the second hunk is the expression returned from the function whose definition is seen in the first hunk, and it's nice that it is indented in the way you'd expect relative to the `def` line. \r\n\r\nI even think, this is misleading. Imagine same situation not on line 1 and 8, but on line 132 and 147, so numbers doesn't bring to mind real file content. Indentation looks similar, but in reality there are couple of wrongly-indented _if_s in between and we do not know really, is it same level or even same function (especially in languages with function overload, where \"same name\" doesn't mean \"same function\").\r\nFor me, proper way of thinking in such situation: 'I don't know'. It is some indentation from something not visible, just by accident on same level as previous hunk\r\n\r\n> (I'm not arguing against the idea! And of course, it would be opt-in, not default.)\r\n\r\nOf course","createdAt":"2022-10-27T15:07:43Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/1224#issuecomment-1293672434","viewerDidAuthor":false},{"id":"IC_kwDOC4j8g85NHPk2","author":{"login":"dandavison"},"authorAssociation":"OWNER","body":"> For me, proper way of thinking in such situation: 'I don't know'. It is some indentation from something not visible, just by accident on same level as previous hunk\r\n\r\nRight, I agree that this viewpoint is totally reasonable and technically correct.\r\n\r\nIs this something you'd be interested in implementing?\r\n\r\n(FWIW, personally I always use my terminal emulator in full screen mode, never split horizontally into more than two terminals, and side-by-side has wrapping, so I think I might not use it myself. But I can imagine it being useful for people with different work styles, and I have played around briefly with fzf previews involving delta so I know they are an interesting source of possibilities.)","createdAt":"2022-10-27T15:56:36Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/1224#issuecomment-1293744438","viewerDidAuthor":true}],"number":1224,"title":"🚀 Shortening of hunk indentation"},{"body":"`delta` colors some keywords, which makes I difficult to detect the changes I made.\r\n\r\nFor example: here I want to keep `\\sum`, `\\in`, `\\!` keywords while color as well.\r\n<img width=\"448\" alt=\"image\" src=\"https://user-images.githubusercontent.com/18537398/197149135-3cf2a2e5-0cbd-41a4-85fe-e6440ce0f62d.png\">\r\n\r\n\r\nIs it possible to remove all coloring (basically I want to show all text as white), except removed characters showed as red and added charecters showed as green?","comments":[],"number":1214,"title":"[help] How can I remove all coloring except added and removed characters?"},{"body":"Despite `delta --list-languages` showing the following output, it seems it does not apply highlighting to `.php` files.\r\n>PHP php, php3, php4, php5, php7, phps, phpt, phtml\r\n\r\nIt seems I **_do_** get syntax highlighting for JSON, YAML and other files, so the feature is working, but just not for PHP files. This seems to be because it is highlighting in **HTML mode**, as if the file did not begin with `<?php` (even though it does) to switch it to PHP mode, which is verifiable by adding `<Tags>` in comments and observing they become highlighted.\r\n\r\n\r\n\r\n`git -v`\r\n\r\n>git version 2.38.0.windows.1\r\n\r\n`delta -V`\r\n\r\n>delta 0.14.0\r\n","comments":[{"id":"IC_kwDOC4j8g85X7xFX","author":{"login":"nickygerritsen"},"authorAssociation":"NONE","body":"This seems to happen only when the `<?php` is not in the diff. Example:\r\n\r\n","createdAt":"2023-03-19T15:03:54Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[{"content":"THUMBS_UP","users":{"totalCount":1}}],"url":"https://github.com/dandavison/delta/issues/1207#issuecomment-1475285335","viewerDidAuthor":false},{"id":"IC_kwDOC4j8g85X7x3U","author":{"login":"Bilge"},"authorAssociation":"NONE","body":"Correct\n\nOn Sun, 19 Mar 2023, 22:04 Nicky Gerritsen, ***@***.***>\nwrote:\n\n> This seems to happen only when the <?php is not in the diff. Example:\n> [image: image]\n> <https://user-images.githubusercontent.com/550145/226185092-f5db8989-d889-4587-9ad9-cd7462f3438a.png>\n>\n> —\n> Reply to this email directly, view it on GitHub\n> <https://github.com/dandavison/delta/issues/1207#issuecomment-1475285335>,\n> or unsubscribe\n> <https://github.com/notifications/unsubscribe-auth/AADS4YUATSO5CUHDXKYIFJTW44N6JANCNFSM6AAAAAARA4NQ24>\n> .\n> You are receiving this because you authored the thread.Message ID:\n> ***@***.***>\n>\n","createdAt":"2023-03-19T15:09:44Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/1207#issuecomment-1475288532","viewerDidAuthor":false},{"id":"IC_kwDOC4j8g85mIWdR","author":{"login":"pprkut"},"authorAssociation":"NONE","body":"Duplicate of #162 ","createdAt":"2023-09-11T08:58:55Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/1207#issuecomment-1713465169","viewerDidAuthor":false}],"number":1207,"title":"🐛 PHP files are syntax highlighted as if they were HTML"},{"body":"My configuration, which I think I based on some comments here a few months ago, separates commits in `git log` with blue lines 47 characters long.\r\n\r\nBecause the commit messages on my setup and indented by 4 characters, I would like to increase the length of these blue lines by 4 characters, but I cannot see where I can do that.\r\n\r\n```\r\n[interactive]\r\n\tdiffFilter = delta --color-only --features=interactive\r\n[delta]\r\n\tfeatures = decorations\r\n\tline-numbers = true\r\n\tsyntax-theme = TwoDark\r\n\twidth = 1\r\n\tminus-style = syntax \"#450a15\"\r\n\tminus-emph-style = syntax \"#600818\"\r\n\tplus-style = syntax \"#0b4820\"\r\n\tplus-emph-style = syntax \"#175c2e\"\r\n\thunk-header-style = syntax bold\r\n\thunk-header-decoration-style = omit\r\n\tfile-style = yellow italic\r\n\tfile-decoration-style = yellow ul\r\n\tline-numbers-zero-style = \"#4b5263\"\r\n\tline-numbers-left-format = \"{nm:^4} \"\r\n\tline-numbers-right-format = \"{np:^4} \"\r\n[delta \"interactive\"]\r\n\tkeep-plus-minus-markers = false\r\n[delta \"decorations\"]\r\n\tcommit-decoration-style = blue ol\r\n\tcommit-style = raw\r\n\tfile-style = omit\r\n\thunk-header-decoration-style = blue box\r\n\thunk-header-file-style = red\r\n\thunk-header-line-number-style = \"#067a00\"\r\n\thunk-header-style = file line-number syntax\r\n```\r\n\r\nWhat do I need to change? Thanks.","comments":[],"number":1202,"title":"How do I increase the length of the blue dividing line on git log?"},{"body":"Perhaps replace `ansi_term` usage in delta with https://github.com/epage/anstyle / https://github.com/epage/anstyle/tree/main/crates/termcolor and then use\r\nhttps://github.com/epage/anstyle/tree/main/crates/git to parse git colors (which should eliminate some delta code).","comments":[],"number":1195,"title":"🚀 migrate away from unsupported ansi_term library"},{"body":"There should be a command named `delta doctor` or `delta --doctor` which checks various aspects of the user's environment and reports on anything that seems like it will cause problems with delta usage.\r\n\r\nFor example, this could check for:\r\n\r\n- `less` version (see the many issues from Windows users with broken installed version of `less`)\r\n- git environment variables that are not supported by delta (#1113)\r\n- `GIT_PAGER` env var that doesn't contain \"delta\"\r\n- `*PAGER` env var using a pager other than `less`\r\n- using tmux/screen without the required [obscure terminal config hacks](https://dandavison.github.io/delta/using-delta-with-tmux.html)\r\n- 24bit color support and box-drawing unicode characters support etc (at least, it could print out some content and link the user to an image showing what it should look like)\r\n- cannot read git config\r\n- essential delta config does not seem to be present in git config\r\n- Check for deprecated delta keys in config (see https://github.com/dandavison/delta/issues/912)\r\n- Check for unknown keys or apparently mis-spelled keys\r\n- Check whether user is using latest delta version\r\n\r\nPerhaps it should be possible to silence selected warnings via delta config.","comments":[{"id":"IC_kwDOC4j8g85LAjfy","author":{"login":"dandavison"},"authorAssociation":"OWNER","body":"- check that any local bat syntax and color theme definitions are compatible with this version of delta (see #1201)","createdAt":"2022-09-26T18:24:14Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/1184#issuecomment-1258436594","viewerDidAuthor":true}],"number":1184,"title":"🚀 Add delta doctor command"},{"body":"Currently, there's no wrap to the code. So, if the code is too long in width, it will be wrapped by terminals to the next line, which is in the same place as `--blame-format`.\r\n\r\nI hope it can wrap the codes in the right of line numbers.","comments":[{"id":"IC_kwDOC4j8g85LESeO","author":{"login":"NickLarsenNZ"},"authorAssociation":"NONE","body":"I think this relates to https://github.com/dandavison/delta/issues/299\r\n","createdAt":"2022-09-27T12:11:40Z","includesCreatedEdit":true,"isMinimized":false,"minimizedReason":"","reactionGroups":[{"content":"THUMBS_UP","users":{"totalCount":1}}],"url":"https://github.com/dandavison/delta/issues/1176#issuecomment-1259415438","viewerDidAuthor":false},{"id":"IC_kwDOC4j8g85LKy7E","author":{"login":"timsu92"},"authorAssociation":"NONE","body":"True.\r\nHowever, that targets `git diff`, which already has a working solution (althought with some bug) at least in side-by-side view.","createdAt":"2022-09-28T15:57:52Z","includesCreatedEdit":true,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/1176#issuecomment-1261121220","viewerDidAuthor":false},{"id":"IC_kwDOC4j8g85LMz94","author":{"login":"dandavison"},"authorAssociation":"OWNER","body":"What's the bug you're referring to @timsu92?","createdAt":"2022-09-29T02:03:04Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/1176#issuecomment-1261649784","viewerDidAuthor":true},{"id":"IC_kwDOC4j8g85LNMjj","author":{"login":"timsu92"},"authorAssociation":"NONE","body":"I haven't searched for exist issue yet. I'll search for that or raise a new one.","createdAt":"2022-09-29T04:52:13Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/1176#issuecomment-1261750499","viewerDidAuthor":false}],"number":1176,"title":"🚀 wrap code of `git blame` in block of code only"},{"body":"\r\n\r\nError:\r\n\r\n```\r\nthread 'main' panicked at 'String mismatch encountered while superimposing style sections: '↵' vs 'k'', /var/home/aral/.cargo/registry/src/github.com-1ecc6299db9ec823/git-delta-0.12.1/src/paint.rs:922\r\n```\r\n\r\nIs caused by the following diff:\r\n\r\n```diff\r\ndiff --git a/src/production/Server.js b/src/production/Server.js\r\nindex c43305e..501b6bd 100644\r\n--- a/src/production/Server.js\r\n+++ b/src/production/Server.js\r\n@@ -162,7 +162,12 @@ export default class Server extends EventTarget {\r\n \r\n this.server = https.createServer(this.options, handler)\r\n this.server.listen(443, () => {\r\n- console.info(`😸️ Kitten\\n\\n 💾 ${chalk.bold('Serving:')} ${process.env.basePath}\\n 🌍 ${chalk.bold('At:')} https://${this.hostname}\\n`)\r\n+ console.info(\r\n+ \"😸️ Kitten\\n\\n\" +\r\n+ `📂 ${chalk.bold('Serving:')} ${process.env.basePath}\\n` +\r\n+ `🌍 ${chalk.bold('At:')} https://${this.hostname}\\n` +\r\n+ `💾 ${chalk.bold('Database:')} ${databaseDirectory}\\n`\r\n+ )\r\n })\r\n }\r\n```\r\n\r\nFull backtrace:\r\n\r\n<details>\r\n\r\n```\r\n 0: 0x5615ea0d855d - std::backtrace_rs::backtrace::libunwind::trace::hee598835bc88d35b\r\n at /rustc/7737e0b5c4103216d6fd8cf941b7ab9bdbaace7c/library/std/src/../../backtrace/src/backtrace/libunwind.rs:93:5\r\n 1: 0x5615ea0d855d - std::backtrace_rs::backtrace::trace_unsynchronized::h9cdc730ba5cf5d72\r\n at /rustc/7737e0b5c4103216d6fd8cf941b7ab9bdbaace7c/library/std/src/../../backtrace/src/backtrace/mod.rs:66:5\r\n 2: 0x5615ea0d855d - std::sys_common::backtrace::_print_fmt::h75aeaf7ed30e43fa\r\n at /rustc/7737e0b5c4103216d6fd8cf941b7ab9bdbaace7c/library/std/src/sys_common/backtrace.rs:66:5\r\n 3: 0x5615ea0d855d - <std::sys_common::backtrace::_print::DisplayBacktrace as core::fmt::Display>::fmt::h606862f787600875\r\n at /rustc/7737e0b5c4103216d6fd8cf941b7ab9bdbaace7c/library/std/src/sys_common/backtrace.rs:45:22\r\n 4: 0x5615ea0ffa0c - core::fmt::write::he803f0f418caf762\r\n at /rustc/7737e0b5c4103216d6fd8cf941b7ab9bdbaace7c/library/core/src/fmt/mod.rs:1190:17\r\n 5: 0x5615ea0d3608 - std::io::Write::write_fmt::h70bc45872f37e7bb\r\n at /rustc/7737e0b5c4103216d6fd8cf941b7ab9bdbaace7c/library/std/src/io/mod.rs:1657:15\r\n 6: 0x5615ea0da8c7 - std::sys_common::backtrace::_print::h64d038cf8ac3e13e\r\n at /rustc/7737e0b5c4103216d6fd8cf941b7ab9bdbaace7c/library/std/src/sys_common/backtrace.rs:48:5\r\n 7: 0x5615ea0da8c7 - std::sys_common::backtrace::print::h359300b4a7fccf65\r\n at /rustc/7737e0b5c4103216d6fd8cf941b7ab9bdbaace7c/library/std/src/sys_common/backtrace.rs:35:9\r\n 8: 0x5615ea0da8c7 - std::panicking::default_hook::{{closure}}::hf51be35e2f510149\r\n at /rustc/7737e0b5c4103216d6fd8cf941b7ab9bdbaace7c/library/std/src/panicking.rs:295:22\r\n 9: 0x5615ea0da590 - std::panicking::default_hook::h03ca0f22e1d2d25e\r\n at /rustc/7737e0b5c4103216d6fd8cf941b7ab9bdbaace7c/library/std/src/panicking.rs:314:9\r\n 10: 0x5615ea0db019 - std::panicking::rust_panic_with_hook::h3b7380e99b825b63\r\n at /rustc/7737e0b5c4103216d6fd8cf941b7ab9bdbaace7c/library/std/src/panicking.rs:698:17\r\n 11: 0x5615ea0dad07 - std::panicking::begin_panic_handler::{{closure}}::h8e849d0710154ce0\r\n at /rustc/7737e0b5c4103216d6fd8cf941b7ab9bdbaace7c/library/std/src/panicking.rs:588:13\r\n 12: 0x5615ea0d8a24 - std::sys_common::backtrace::__rust_end_short_backtrace::hedcdaddbd4c46cc5\r\n at /rustc/7737e0b5c4103216d6fd8cf941b7ab9bdbaace7c/library/std/src/sys_common/backtrace.rs:138:18\r\n 13: 0x5615ea0daa19 - rust_begin_unwind\r\n at /rustc/7737e0b5c4103216d6fd8cf941b7ab9bdbaace7c/library/std/src/panicking.rs:584:5\r\n 14: 0x5615e9e2b283 - core::panicking::panic_fmt::he1bbc7336d49a357\r\n at /rustc/7737e0b5c4103216d6fd8cf941b7ab9bdbaace7c/library/core/src/panicking.rs:143:14\r\n 15: 0x5615e9ea83d6 - delta::paint::Painter::paint_line::hb3721735e8d2124e\r\n 16: 0x5615e9e979b2 - delta::features::side_by_side::paint_minus_or_plus_panel_line::he4d04b2089c3a767\r\n 17: 0x5615e9e960d7 - delta::features::side_by_side::paint_minus_and_plus_lines_side_by_side::h3b475cea9c985446\r\n 18: 0x5615e9ea996f - delta::paint::paint_minus_and_plus_lines::hb0a45641da2228c7\r\n 19: 0x5615e9ea552e - delta::paint::Painter::paint_buffered_minus_and_plus_lines::hdea4ff1781b92caf\r\n 20: 0x5615e9f109fc - delta::handlers::hunk::<impl delta::delta::StateMachine>::handle_hunk_line::he943c6f38e0b0637\r\n 21: 0x5615e9f0af9f - delta::delta::delta::hfda5e87889555fc8\r\n 22: 0x5615e9f1d6c6 - delta::main::hdecd10abd1b8adc6\r\n 23: 0x5615e9ebd2b3 - std::sys_common::backtrace::__rust_begin_short_backtrace::hbf18c596260c27ce\r\n 24: 0x5615e9ed010d - std::rt::lang_start::{{closure}}::h9b88a567912c19ee\r\n 25: 0x5615ea0d7c41 - core::ops::function::impls::<impl core::ops::function::FnOnce<A> for &F>::call_once::hb7014f43484a8b4e\r\n at /rustc/7737e0b5c4103216d6fd8cf941b7ab9bdbaace7c/library/core/src/ops/function.rs:259:13\r\n 26: 0x5615ea0d7c41 - std::panicking::try::do_call::h7bc9dc436daeb8c7\r\n at /rustc/7737e0b5c4103216d6fd8cf941b7ab9bdbaace7c/library/std/src/panicking.rs:492:40\r\n 27: 0x5615ea0d7c41 - std::panicking::try::h653d68a27ff5f175\r\n at /rustc/7737e0b5c4103216d6fd8cf941b7ab9bdbaace7c/library/std/src/panicking.rs:456:19\r\n 28: 0x5615ea0d7c41 - std::panic::catch_unwind::h9d739f9f59895e68\r\n at /rustc/7737e0b5c4103216d6fd8cf941b7ab9bdbaace7c/library/std/src/panic.rs:137:14\r\n 29: 0x5615ea0d7c41 - std::rt::lang_start_internal::{{closure}}::hf006f2bc7ce22bbe\r\n at /rustc/7737e0b5c4103216d6fd8cf941b7ab9bdbaace7c/library/std/src/rt.rs:128:48\r\n 30: 0x5615ea0d7c41 - std::panicking::try::do_call::hfb39d6df61a2e69f\r\n at /rustc/7737e0b5c4103216d6fd8cf941b7ab9bdbaace7c/library/std/src/panicking.rs:492:40\r\n 31: 0x5615ea0d7c41 - std::panicking::try::h13e2d225134958ac\r\n at /rustc/7737e0b5c4103216d6fd8cf941b7ab9bdbaace7c/library/std/src/panicking.rs:456:19\r\n 32: 0x5615ea0d7c41 - std::panic::catch_unwind::h3bd49b5a5dfb1a50\r\n at /rustc/7737e0b5c4103216d6fd8cf941b7ab9bdbaace7c/library/std/src/panic.rs:137:14\r\n 33: 0x5615ea0d7c41 - std::rt::lang_start_internal::h2ba92edce36c035e\r\n at /rustc/7737e0b5c4103216d6fd8cf941b7ab9bdbaace7c/library/std/src/rt.rs:128:20\r\n 34: 0x5615e9f1ee02 - main\r\n 35: 0x7fcce07a5550 - __libc_start_call_main\r\n 36: 0x7fcce07a5609 - __libc_start_main_impl\r\n 37: 0x5615e9e2bab5 - _start\r\n```\r\n\r\n</details>","comments":[{"id":"IC_kwDOC4j8g85ep8v8","author":{"login":"th1000s"},"authorAssociation":"COLLABORATOR","body":"I can't reproduce this anymore with the current delta version. However the bat reproducer linked above is now using the same `bat` and `syntect` version as delta and (of course) it still splits off of the variant selector.\r\n\r\nThe bat version of delta was updated to 22.1 just 3 months ago, so maybe that somehow fixed it?","createdAt":"2023-06-12T20:36:57Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/1172#issuecomment-1588055036","viewerDidAuthor":false}],"number":1172,"title":"🐛 String mismatch encountered while superimposing style sections: '↵' vs 'k''"},{"body":"delta's blame parser seems unable to handle the output format that is produced when the config option [`blame.markIgnoredLines`](https://git-scm.com/docs/git-config#Documentation/git-config.txt-blamemarkIgnoredLines) is set to true. Although I wasn't able to reproduce it, I assume the same goes for [`blame.markUnblamableLines`](https://git-scm.com/docs/git-config#Documentation/git-config.txt-blamemarkUnblamableLines).\r\n\r\nI made a reproduction repo at [sybereal/delta-blame-repro](https://github.com/sybereal/delta-blame-repro). In this repo, I set `git config blame.ignoreRevsFile .git-blame-ignore-revs`.\r\n\r\nWith `blame.markIgnoredLines = false`:\r\n\r\nRaw:\r\n```\r\n^ff4fd92 (Simon Engmann 2022-08-23 08:24:42 +0200 1) struct Foo(u32);\r\n```\r\n\r\nWith `blame.markIgnoredLines = true`:\r\n\r\nRaw:\r\n```\r\n^?ff4fd9 (Simon Engmann 2022-08-23 08:24:42 +0200 1) struct Foo(u32);\r\n```\r\n\r\n- [x] Please include the raw text output from git, so that we can reproduce the problem.\r\n (You can use `git --no-pager` to produce the raw text output.)\r\n- [x] A screenshot of Delta's output is often helpful also.\r\n\r\nThanks for filing a Delta bug report!\r\n","comments":[],"number":1171,"title":"🐛 Blame parser fails when blame.markIgnoredLines = true"},{"body":"\n> ansi_term is Unmaintained\n\n| Details | |\n| ------------------- | ---------------------------------------------- |\n| Status | unmaintained |\n| Package | `ansi_term` |\n| Version | `0.12.1` |\n| URL | [https://github.com/ogham/rust-ansi-term/issues/72](https://github.com/ogham/rust-ansi-term/issues/72) |\n| Date | 2021-08-18 |\n\nThe maintainer has adviced this crate is deprecated and will not\nreceive any maintenance.\n\nThe crate does not seem to have much dependencies and may or may not be ok to use as-is.\n\nLast release seems to have been three years ago.\n\n## Possible Alternative(s)\n\n The below list has not been vetted in any way and may or may not contain alternatives;\n\n - [anstyle](https://github.com/epage/anstyle)\n - [nu-ansi-term](https://crates.io/crates/nu-ansi-term)\n - [yansi](https://crates.io/crates/yansi)\n\nSee [advisory page](https://rustsec.org/advisories/RUSTSEC-2021-0139.html) for additional details.\n","comments":[],"number":1166,"title":"RUSTSEC-2021-0139: ansi_term is Unmaintained"},{"body":"\n> xml-rs is Unmaintained\n\n| Details | |\n| ------------------- | ---------------------------------------------- |\n| Status | unmaintained |\n| Package | `xml-rs` |\n| Version | `0.8.4` |\n| URL | [https://github.com/netvl/xml-rs/issues](https://github.com/netvl/xml-rs/issues) |\n| Date | 2022-01-26 |\n\nxml-rs is a XML parser has open issues around parsing including integer\noverflows / panics that may or may not be an issue with untrusted data.\n\nTogether with these open issues with Unmaintained status xml-rs\nmay or may not be suited to parse untrusted data.\n\n## Alternatives\n\n- [quick-xml](https://crates.io/crates/quick-xml)\n\nSee [advisory page](https://rustsec.org/advisories/RUSTSEC-2022-0048.html) for additional details.\n","comments":[],"number":1161,"title":"RUSTSEC-2022-0048: xml-rs is Unmaintained"},{"body":"In the open source area, nearly no tool which can compare binary files like the commercial comapre tool (Beyond compare)\r\nIf `delta` can support this feature, I think it will become much more useful (For embedded developers)\r\n\r\nThanks.","comments":[{"id":"IC_kwDOC4j8g85IO9RZ","author":{"login":"dandavison"},"authorAssociation":"OWNER","body":"Hi @tonyho, thanks for the suggestion. For this feature I would like delta to build upon a dedicated binary file analysis tool (delta is really a tool for visualizing diff output: it's not a tool for computing diffs, whether on binary files or text files).\r\n\r\nHave you investigated using delta on the output of something like [hexyl](https://github.com/sharkdp/hexyl)? I don't work with binary files very much, but at first glance the results seem helpful?\r\n\r\n<img width=\"658\" alt=\"image\" src=\"https://user-images.githubusercontent.com/52205/184126505-cd5375b4-94e1-4100-88a5-f8fb833a23f3.png\">\r\n","createdAt":"2022-08-11T11:47:10Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/1156#issuecomment-1211880537","viewerDidAuthor":true},{"id":"IC_kwDOC4j8g85IO9qG","author":{"login":"dandavison"},"authorAssociation":"OWNER","body":"(`delta file1 file2` uses `git diff` under the hood to compute the diff.)","createdAt":"2022-08-11T11:49:09Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/1156#issuecomment-1211882118","viewerDidAuthor":true}],"number":1156,"title":"🚀 Support to compare binary files"},{"body":"\n> `term_size` is unmaintained; use `terminal_size` instead\n\n| Details | |\n| ------------------- | ---------------------------------------------- |\n| Status | unmaintained |\n| Package | `term_size` |\n| Version | `0.3.2` |\n| URL | [https://github.com/clap-rs/term_size-rs/pull/31](https://github.com/clap-rs/term_size-rs/pull/31) |\n| Date | 2020-11-03 |\n\nThe [`term_size`](https://crates.io/crates/term_size) crate is no longer maintained. Consider using\n[`terminal_size`](https://crates.io/crates/terminal_size) instead.\n\nSee [advisory page](https://rustsec.org/advisories/RUSTSEC-2020-0163.html) for additional details.\n","comments":[],"number":1147,"title":"RUSTSEC-2020-0163: `term_size` is unmaintained; use `terminal_size` instead"},{"body":"When I use delta with git, it correctly returns with 0 status code. However with mercurial it returns 1 if there were some changes which I suppose was introduced as a resolution of https://github.com/dandavison/delta/issues/448. Mercurial uses delta as an external program via the [extdiff](https://www.mercurial-scm.org/wiki/ExtdiffExtension) extension.\r\n\r\nHere is my mercurial config for reference:\r\n```\r\n[extdiff]\r\ncmd.delta =\r\nopts.delta = --no-gitconfig --line-numbers --navigate --commit-decoration-style \"bold yellow box ul\" --file-style \"bold yellow box\" --file-decoration-style \"none\" --pager \"less -XR\"\r\n```","comments":[{"id":"IC_kwDOC4j8g86SduWI","author":{"login":"dandavison"},"authorAssociation":"OWNER","body":"Sorry this got missed. If it's still a problem can you post the command that's causing problems?","createdAt":"2024-11-05T14:03:58Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/1136#issuecomment-2457265544","viewerDidAuthor":true},{"id":"IC_kwDOC4j8g86Sd7nf","author":{"login":"greenfork"},"authorAssociation":"NONE","body":"No problem. With the options above in `~/.hgrc` you can run it like so `hg delta`. You will need to have [extdiff](https://wiki.mercurial-scm.org/ExtdiffExtension) extension installed. A repository to try something could be this one: `hg clone https://repo.mercurial-scm.org/hg`.","createdAt":"2024-11-05T14:26:09Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/1136#issuecomment-2457319903","viewerDidAuthor":false}],"number":1136,"title":"🐛 Interactive use should not return non-zero status code when changes are present"},{"body":"Syntax Highlighting For The Output From `defaults read`\r\n\r\n`[$]> defaults read com.googlecode.iterm2`\r\n\r\n```\r\n{\r\n AppleAntiAliasingThreshold = 1;\r\n \"Default Bookmark Guid\" = \"AD854671-C976-4C5D-9EA2-BD69DF273EF4\";\r\n \"NSSplitView Subview Frames NSColorPanelSplitView\" = (\r\n \"0.000000, 0.000000, 224.000000, 258.000000, NO, NO\",\r\n \"0.000000, 259.000000, 224.000000, 48.000000, NO, NO\"\r\n );\r\n \"NSToolbar Configuration com.apple.NSColorPanel\" = {\r\n \"TB Is Shown\" = 1;\r\n };\r\n \"iTerm Version\" = \"3.4.15\";\r\n}\r\n```\r\n\r\nhttps://en.wikipedia.org/wiki/Property_list\r\n\r\nI believe this has already been implemented in some other tools! They appear to be using the same file.\r\n\r\n**Textmate**\r\n\r\nhttps://github.com/textmate/property-list.tmbundle/blob/textmate-1.x/Syntaxes/Property%20List.tmLanguage\r\n\r\n**Sublime**\r\n\r\nhttps://github.com/tyrone-sudeium/st3-binaryplist/blob/master/Property_List.tmLanguage\r\n\r\nBat Issue https://github.com/sharkdp/bat/issues/2247","comments":[{"id":"IC_kwDOC4j8g85G8rpD","author":{"login":"dandavison"},"authorAssociation":"OWNER","body":"Hi @Gerst20051, thanks for opening the issue here and in bat. Delta uses the collection of language syntax definitions distributed in the bat crate, so when it's available there, we can close this issue with a bat crate version bump. (It's pretty easy to add the syntax definition to the bat collection, so if you felt like making the bat PR I imagine they'd appreciate it.)","createdAt":"2022-07-20T13:49:37Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[{"content":"THUMBS_UP","users":{"totalCount":1}}],"url":"https://github.com/dandavison/delta/issues/1132#issuecomment-1190312515","viewerDidAuthor":true}],"number":1132,"title":"Support For Property List (PList) Format"},{"body":"`1.js`\r\n\r\n```js\r\nfunction foo() {\r\n return bar();\r\n}\r\n```\r\n\r\n`2.js`\r\n\r\n```js\r\nfunction foo() {\r\n return (\r\n bar() &&\r\n baz()\r\n );\r\n}\r\n```\r\n\r\n## Expected (generated by Emacs' `diff-mode`)\r\n\r\n\r\n\r\n- \"&&\" and \"baz()\" are highlighted to show they were added\r\n- the rest is not highlighted\r\n\r\n## Actual\r\n\r\n```session\r\n$ delta --light 1.js 2.js \r\n```\r\n\r\nresults in:\r\n\r\n\r\n\r\n- \"&&\" and \"baz()\" have the same highlighting as \"bar()\"\r\n","comments":[{"id":"IC_kwDOC4j8g85Jf2kk","author":{"login":"timsu92"},"authorAssociation":"NONE","body":"Me too.\r\n\r\nResult of compare in GitHub.com:\r\n\r\nResult of delta\r\n","createdAt":"2022-08-31T15:25:33Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/1129#issuecomment-1233086756","viewerDidAuthor":false},{"id":"IC_kwDOC4j8g85JgL5U","author":{"login":"dandavison"},"authorAssociation":"OWNER","body":"Hi @DamienCassou, @timsu92. I think you can get what you want if you experiment with `plus-emph-style` and `plus-non-emph-style`. E.g.\r\n\r\n```\r\ndelta --plus-style='syntax #a0efa0' --plus-non-emph-style='syntax #d0ffd0' a.js b.js\r\n```\r\n\r\n<img width=\"733\" alt=\"image\" src=\"https://user-images.githubusercontent.com/52205/187732759-3e43635b-ed90-4f78-903e-2153790059bc.png\">\r\n","createdAt":"2022-08-31T16:41:18Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/1129#issuecomment-1233174100","viewerDidAuthor":true},{"id":"IC_kwDOC4j8g85Ji_ue","author":{"login":"timsu92"},"authorAssociation":"NONE","body":"@dandavison Sorry, but no😭\r\n\r\nI meant the content it considers to be emphasized, not the color.\r\nFrom [my comment](https://github.com/dandavison/delta/issues/1129#issuecomment-1233086756), we can see that `silent!` is considered to be removed, which is correct. However, ` :let` (with a preceding space) is considered to be added.\r\nThe first point is that it included an extra space. The second is that the space between `:let` and `b:coc_diagnostic...` should be included as well.","createdAt":"2022-09-01T08:11:26Z","includesCreatedEdit":true,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/1129#issuecomment-1233910686","viewerDidAuthor":false},{"id":"IC_kwDOC4j8g85Jjicd","author":{"login":"dandavison"},"authorAssociation":"OWNER","body":"@timsu92 in addition to screenshots, can you post the raw diff input to delta as text please, so that others can experiment with piping it to delta. It may be hard to exactly recreate particular expectations regarding highlighting of whitespace, although there are some settings you could play with such as `word-diff-regex`.","createdAt":"2022-09-01T10:04:33Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/1129#issuecomment-1234052893","viewerDidAuthor":true},{"id":"IC_kwDOC4j8g85JkoF9","author":{"login":"timsu92"},"authorAssociation":"NONE","body":"> can you post the raw diff input to delta as text please\r\n\r\n@dandavison Here they are~\r\n```diff\r\n@@ -364,8 +363,8 @@ let g:EasyMotion_use_migemo = 1 \" match multibyte Japanese character with alpha\r\n let g:EasyMotion_smartcase = 1 \" lower case will match both lower and upper; upper case will match upper only\r\n let g:EasyMotion_use_smartsign_us = 1 \" make 1 match 1 and !; ! will match ! only\r\n \" avoid annoying syntax errors while jumping\r\n-autocmd User EasyMotionPromptBegin silent! CocDisable\r\n-autocmd User EasyMotionPromptEnd silent! CocEnable\r\n+autocmd User EasyMotionPromptBegin :let b:coc_diagnostic_disable = 1\r\n+autocmd User EasyMotionPromptEnd :let b:coc_diagnostic_disable = 0\r\n```\r\nIt is part of diff on my own repo. I've checked that they are spaces rather than tabs in the previous file and the next. To be specific, we can see [this compare](https://github.com/timsu92/vimrc/compare/493e74b448919a2d8d7349fae0173dbd425fc81d..583a2b71065a009b230d8457ca6f3b5ffaf7bbbd).\r\n\r\nThanks for all contributors!","createdAt":"2022-09-01T14:11:01Z","includesCreatedEdit":true,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/1129#issuecomment-1234338173","viewerDidAuthor":false},{"id":"IC_kwDOC4j8g85JoIt0","author":{"login":"DamienCassou"},"authorAssociation":"NONE","body":"@dandavison I'm sorry but I don't understand your proposal. The screenshot you attach seems to contain the exact same problem as the one I describe in the post: your screenshot makes absolutely no difference between `bar` and `baz` even though one was there in the original text and one wasn't. Said differently, I would expect `baz` to be highlighted (as it's new) but not `bar` (as it hasn't changed).","createdAt":"2022-09-02T09:06:59Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[{"content":"HEART","users":{"totalCount":1}}],"url":"https://github.com/dandavison/delta/issues/1129#issuecomment-1235258228","viewerDidAuthor":false},{"id":"IC_kwDOC4j8g85Joo-a","author":{"login":"dandavison"},"authorAssociation":"OWNER","body":"Hi @DamienCassou, Emacs' algorithm seems to have produced quite nice results on your example. Delta's algorithm is documented here: [ARCHITECTURE.md#handling-diff-hunk-lines](https://github.com/dandavison/delta/blob/master/ARCHITECTURE.md#handling-diff-hunk-lines). So, as you can see, the first important thing to notice is that delta works by first \"pairing up\" lines to decide which ones it considers to be homologs (the \"same\" line, just changed).\r\n\r\nIn your example, delta pairs up the two lines containing the word `return`. Then, it sees two newly added lines: one containing `bar` and one containing `baz`.\r\n\r\nWhat you would like it to do, is instead consider ` return (` to be a newly inserted line, and pair up the line\r\n\r\n```\r\n return bar();\r\n```\r\nwith\r\n```\r\n bar() &&\r\n```\r\n\r\nIt doesn't do that, because it computes a distance metric between the lines, and finds `return bar()` to be more similar to `return (` than to `bar() &&`.\r\n\r\nWe can tweak your example to demonstrate delta doing something like you want (but obviously that's not a solution for you :) :\r\n\r\n1.js\r\n```\r\nfunction foo() {\r\n return bar() bar();\r\n}\r\n```\r\n\r\n2.js\r\n```\r\nfunction foo() {\r\n RETURN (\r\n bar() bar() &&\r\n baz()\r\n );\r\n}\r\n```\r\n\r\nNotice that here we've\r\n\r\n1. Made the \"return\" lines dissimilar\r\n2. Increased the proportion of matching in the `bar` line by making them longer.\r\n\r\n<img width=\"854\" alt=\"image\" src=\"https://user-images.githubusercontent.com/52205/188130168-abbd4d22-a40e-4bfc-ae4e-c08b5f5b4e75.png\">\r\n\r\nWhen experimenting, do bear in mind the `max-line-distance` option.\r\n\r\nIf you're interested in working more on the within-line diff algorithm that would be great. The possibilities definitely haven't been explored thoroughly yet, although the current algorithm (pair lines by similarity, tokenize, and run a levenshtein-like edit inference algorithm) works quite well and people haven't really demanded tweaks over the last couple of years.","createdAt":"2022-09-02T11:34:41Z","includesCreatedEdit":true,"isMinimized":false,"minimizedReason":"","reactionGroups":[{"content":"THUMBS_UP","users":{"totalCount":1}}],"url":"https://github.com/dandavison/delta/issues/1129#issuecomment-1235390362","viewerDidAuthor":true},{"id":"IC_kwDOC4j8g85JopZ8","author":{"login":"dandavison"},"authorAssociation":"OWNER","body":"@timsu92 I agree that delta could do a better job / there are bugs with the way edits are inferred/highlighted in the whitespace. If you would like to open a separate issue for that that would be great (there might already be one though). ","createdAt":"2022-09-02T11:36:59Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/1129#issuecomment-1235392124","viewerDidAuthor":true},{"id":"IC_kwDOC4j8g85Js5-3","author":{"login":"timsu92"},"authorAssociation":"NONE","body":"@dandavison OK, submitted as #1181. Hope a better delta coming soon~","createdAt":"2022-09-05T03:30:47Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/1129#issuecomment-1236508599","viewerDidAuthor":false},{"id":"IC_kwDOC4j8g85e0y8f","author":{"login":"cben"},"authorAssociation":"NONE","body":"> So, as you can see, the first important thing to notice is that delta works by first \"pairing up\" lines to decide which ones it considers to be homologs (the \"same\" line, just changed).\r\n\r\nInteresting. While sophisticated, it sounds like the idea pairing up lines is inherently limited in handling cases where lines get split up / joined? :thinking: \r\n\r\nkosaki/colordiff.py is a useful strawman because it's extremely short & understandable — and it does better here, because it's feeding _whole subhunk vs. whole subhunk_ (accumulated in self.minus_buf / self.plus_buf, complete with newlines) into token-level diffing:\r\nhttps://github.com/kosaki/colordiff.py/blob/cdd1c1181f6324621272f4ee5ba35081a21a568d/colordiff.py#L83-L99\r\n\r\n\r\n\r\n<details>\r\n\r\n<summary>(tokenization is not essential here)</summary>\r\n\r\nworking on tokens instead of characters is a simplistic tradeoff to highlight whole words instead of mid-word character changes (which tend to be confusing if unrelated words get \"paired up\"); the specific tokens it compared in this example are: \r\n`['-', ' ', 'return', ' ', 'bar', '(', ')', ';', '\\n']` \r\nvs. \r\n`['+', ' ', 'return', ' ', '(', '\\n', '+', ' ', 'bar', '(', ')', ' ', '&', '&', '\\n', '+', ' ', 'baz', '(', ')', '\\n', '+', ' ', ')', ';', '\\n']`\r\n\r\n</details>\r\n\r\nThe essential point is that treating whole subhunk as one sequence with newlines can deal with newline insertion/deletion as a minor internal diff, without throwing off matching of other text.\r\n\r\nI think meld works similarly, appears to feed whole (sub)hunks into character-level diffing:\r\n\r\n\r\n\r\n----\r\n\r\nAnother meld example dealing well with multiple line joining/splitting/indentation changes (though I had to lengthen `bar()` to `barbar()` to not get swallowed in adjacent changes):\r\n\r\n","createdAt":"2023-06-14T10:08:41Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/1129#issuecomment-1590898463","viewerDidAuthor":false}],"number":1129,"title":"🐛 Word-level diff highlighting seems limited"},{"body":"I have a case that I think is not solved with just `--hyperlinks` and `--hyperlinks-commit-link-format`. I was excited to emit hyperlinks, but `--hyperlinks-commit-link-format` doesn't really make sense to me, as one has to specify the entire path to a repo, making it useless unless it's replicated across multiple `.gitconfig` files, which is quite prohibitive.\r\n\r\nI have a URL like\r\n\r\n```\r\n» git remote get-url origin\r\ngit@github.COMPANY.com:ORG/repo.git\r\n```\r\n\r\nlooking at src/git_config/git_config_entry.rs#L23 I would expect the REGEX to be able to take any `github.*\\.com` and then it could be parsed completely for any GitHub Enterprise URL. Unless I'm missing something, there's no way to do this currently, as one can only put the `{commit}` in a custom URL.","comments":[{"id":"IC_kwDOC4j8g85GUKZF","author":{"login":"dandavison"},"authorAssociation":"OWNER","body":"Hi @kanbara, can you use repo-specific git config (file at `.git/config`)? Just for this one setting; everything else can carry on using the usual place. This is what I do for the commit hyperlinks setting.","createdAt":"2022-07-10T09:20:02Z","includesCreatedEdit":true,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/1122#issuecomment-1179690565","viewerDidAuthor":true},{"id":"IC_kwDOC4j8g85GUKiE","author":{"login":"kanbara"},"authorAssociation":"NONE","body":"I considered that as a possibility, but with 94+ repos, it would certainly take way more time than I'd like. And I'd rather not fork the project just to edit a single regex. I could of course provide a patch, unless you have some reason that checking `github.foo.com` or `foo.github.foo.com` would be a bad idea.","createdAt":"2022-07-10T09:23:13Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/1122#issuecomment-1179691140","viewerDidAuthor":false}],"number":1122,"title":"🐛 --hyperlinks can't parse GitHub Enterprise URL"},{"body":"Hi there,\r\n\r\nI'm reluctantly creating this issue as I'm sure I'm just holding it wrong, but I just can't seem to activate the `side-by-side` feature from my `.gitconfig`. It works fine from CLI (`-c core.pager=delta -c delta.side-by-side=true`) and using env args (`GIT_PAGER=delta DELTA_FEATURES=+side-by-side`) but when using a minimal `.gitconfig` with the equivalent settings, I don't see the same results.\r\n\r\n```\r\n[core]\r\n pager = delta\r\n\r\n[delta]\r\n side-by-side = true\r\n```\r\n\r\n\r\n\r\nI've created a small script while trying to figure this out; it's here: _repo deleted - see below comment for script_.\r\n\r\n```\r\n# Run test script with a clean environment; run.sh will add a few term vars back in\r\n$ env -i ./run.sh\r\nCurrent working directory:\r\n\t/home/tf/dev/repos/git_test\r\nVersion details:\r\n\tGit: git version 2.36.1\r\n\tDelta: ^[[0mdelta 0.13.0\r\n^[[0m\r\nInitial state:\r\n\t'git config -l | grep include.path':\r\n\t\r\n\tRun verification aliases from both gitconfigs:\r\n\t\tgit: 'testmain' is not a git command. See 'git --help'.\r\n\t\tgit: 'testpager' is not a git command. See 'git --help'.\r\n\t'git config -l | grep delta':\r\n\t\r\n\t'git config -l':\r\n\t\tcore.repositoryformatversion=0\r\n\t\tcore.filemode=true\r\n\t\tcore.bare=false\r\n\t\tcore.logallrefupdates=true\r\n\t'printenv':\r\n\t\tCOLORTERM=truecolor\r\n\t\tOLDPWD=/home/tf/dev/repos/git_test\r\n\t\tPWD=/home/tf/dev/repos/git_test\r\n\t\tSHLVL=0\r\n\t\tTERM=xterm-kitty\r\n\t\tTERMINAL=kitty\r\n\t\tTERMINFO=/usr/lib/kitty/terminfo\r\n\t\t_=/usr/bin/printenv\r\n\r\nRun git diff using git CLI args:\r\ndiff --git a/sample_code.txt b/sample_code.txt\r\nindex cead32e..71b430f 100644\r\n--- a/sample_code.txt\r\n+++ b/sample_code.txt\r\n@@ -3,3 +3,3 @@ B\r\n C\r\n-D\r\n+XXX\r\n E\r\n\r\nState (CLI args):\r\n\t'git config -l | grep include.path':\r\n\t\r\n\tRun verification aliases from both gitconfigs:\r\n\t\tgit: 'testmain' is not a git command. See 'git --help'.\r\n\t\tgit: 'testpager' is not a git command. See 'git --help'.\r\n\t'git config -l | grep delta':\r\n\t\r\n\t'git config -l':\r\n\t\tcore.repositoryformatversion=0\r\n\t\tcore.filemode=true\r\n\t\tcore.bare=false\r\n\t\tcore.logallrefupdates=true\r\n\t'printenv':\r\n\t\tCOLORTERM=truecolor\r\n\t\tOLDPWD=/home/tf/dev/repos/git_test\r\n\t\tPWD=/home/tf/dev/repos/git_test\r\n\t\tSHLVL=0\r\n\t\tTERM=xterm-kitty\r\n\t\tTERMINAL=kitty\r\n\t\tTERMINFO=/usr/lib/kitty/terminfo\r\n\t\t_=/usr/bin/printenv\r\n\r\nRun git diff using GIT_PAGER=delta and DELTA_FEATURES=+side-by-side:\r\ndiff --git a/sample_code.txt b/sample_code.txt\r\nindex cead32e..71b430f 100644\r\n--- a/sample_code.txt\r\n+++ b/sample_code.txt\r\n@@ -3,3 +3,3 @@ B\r\n C\r\n-D\r\n+XXX\r\n E\r\n\r\nState (env args):\r\n\t'git config -l | grep include.path':\r\n\t\r\n\tRun verification aliases from both gitconfigs:\r\n\t\tgit: 'testmain' is not a git command. See 'git --help'.\r\n\t\tgit: 'testpager' is not a git command. See 'git --help'.\r\n\t'git config -l | grep delta':\r\n\t\r\n\t'git config -l':\r\n\t\tcore.repositoryformatversion=0\r\n\t\tcore.filemode=true\r\n\t\tcore.bare=false\r\n\t\tcore.logallrefupdates=true\r\n\t'printenv':\r\n\t\tCOLORTERM=truecolor\r\n\t\tDELTA_FEATURES=+side-by-side\r\n\t\tGIT_PAGER=delta\r\n\t\tOLDPWD=/home/tf/dev/repos/git_test\r\n\t\tPWD=/home/tf/dev/repos/git_test\r\n\t\tSHLVL=0\r\n\t\tTERM=xterm-kitty\r\n\t\tTERMINAL=kitty\r\n\t\tTERMINFO=/usr/lib/kitty/terminfo\r\n\t\t_=/usr/bin/printenv\r\n\r\nRun git diff using a single gitconfig (gitconfig_pager):\r\ndiff --git a/sample_code.txt b/sample_code.txt\r\nindex cead32e..71b430f 100644\r\n--- a/sample_code.txt\r\n+++ b/sample_code.txt\r\n@@ -3,3 +3,3 @@ B\r\n C\r\n-D\r\n+XXX\r\n E\r\n\r\nState (use gitconfig_pager alone):\r\n\t'git config -l | grep include.path':\r\n\t\r\n\tRun verification aliases from both gitconfigs:\r\n\t\tgit: 'testmain' is not a git command. See 'git --help'.\r\n\t\tgitconfig_pager loaded\r\n\t'git config -l | grep delta':\r\n\t\tcore.pager=delta\r\n\t\tdelta.side-by-side=true\r\n\t'git config -l':\r\n\t\talias.testpager=!echo gitconfig_pager loaded\r\n\t\tcore.pager=delta\r\n\t\tdelta.side-by-side=true\r\n\t\tcore.repositoryformatversion=0\r\n\t\tcore.filemode=true\r\n\t\tcore.bare=false\r\n\t\tcore.logallrefupdates=true\r\n\t'printenv':\r\n\t\tCOLORTERM=truecolor\r\n\t\tGIT_CONFIG_GLOBAL=/home/tf/dev/repos/git_test/gitconfig_pager\r\n\t\tOLDPWD=/home/tf/dev/repos/git_test\r\n\t\tPWD=/home/tf/dev/repos/git_test\r\n\t\tSHLVL=0\r\n\t\tTERM=xterm-kitty\r\n\t\tTERMINAL=kitty\r\n\t\tTERMINFO=/usr/lib/kitty/terminfo\r\n\t\t_=/usr/bin/printenv\r\n\r\n```\r\n\r\nWhat have I missed? Thanks for taking a look.","comments":[{"id":"IC_kwDOC4j8g85FfIY4","author":{"login":"dandavison"},"authorAssociation":"OWNER","body":"Hi @tkf144, sorry that's causing you problems, let's get to the bottom of this! It does work for me.\r\n\r\nYou may have already done this, but what does `git config -l | grep delta` show when you think you have `side-by-side` enabled/disabled in your gitconfig?","createdAt":"2022-06-24T17:34:18Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/1113#issuecomment-1165788728","viewerDidAuthor":true},{"id":"IC_kwDOC4j8g85Fg7QZ","author":{"login":"tkf144"},"authorAssociation":"NONE","body":"Thanks Dan. Appreciate your help.\r\n\r\nMy `git config -l | grep delta` doesn't seem suspicious; it shows delta being set as the pager and side-by-side being set true - output is below.\r\n\r\nHere's the more minimal repro I'm now using. Run this in an empty dir using `env --ignore-environment ./script.sh`:\r\n\r\n```bash\r\n#!/usr/bin/env bash\r\n\r\n# Suppress warning about terminal by providing this\r\nexport TERM=xterm-kitty\r\n\r\ncd \"$(dirname \"$BASH_SOURCE\")\" || exit 1\r\n\r\ncat <<GIT_CONFIG > ./gitconfig\r\n[user]\r\n\tname = \"Test Name\"\r\n\temail = \"TestEmail@gmail.com\"\r\n\r\n[core]\r\n pager = delta\r\n\r\n[delta]\r\n side-by-side = true\r\nGIT_CONFIG\r\n\r\nexport GIT_CONFIG_GLOBAL=gitconfig \r\n\r\ngit init 1> /dev/null 2>&1\r\n\r\ncat <<TEST_FILE > ./test_file.txt\r\nA\r\nB\r\nC\r\nTEST_FILE\r\ngit add ./test_file.txt 1> /dev/null 2>&1\r\ngit commit -m \"Test commit\" 1> /dev/null 2>&1\r\n\r\nsed -i'' 's#B#X#g' ./test_file.txt\r\n\r\ngit diff -U1 ./test_file.txt\r\n\r\necho\r\necho \"'git config -l | grep delta'\"\r\ngit config -l | grep delta\r\n\r\nunset GIT_CONFIG_GLOBAL\r\nrm -rf ./.git ./test_file.txt ./gitconfig\r\n```\r\n\r\n```\r\ndiff --git a/test_file.txt b/test_file.txt\r\nindex b1e6722..9df4d5e 100644\r\n--- a/test_file.txt\r\n+++ b/test_file.txt\r\n@@ -1,3 +1,3 @@\r\n A\r\n-B\r\n+X\r\n C\r\n\r\n'git config -l | grep delta'\r\ncore.pager=delta\r\ndelta.side-by-side=true\r\n```\r\n\r\n\r\n","createdAt":"2022-06-25T11:11:54Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/1113#issuecomment-1166259225","viewerDidAuthor":false},{"id":"IC_kwDOC4j8g85Fg-cL","author":{"login":"dandavison"},"authorAssociation":"OWNER","body":"Hi @tkf144, your test script also doesn't cause delta to display in side-by-side mode for me.\r\n\r\nHowever, when I copy your gitconfig from your test script into my usual gitconfig location, then it works: delta displays in side-by-side mode.\r\n\r\ndelta uses [libgit2](https://libgit2.org/), via the [git2](https://docs.rs/git2/latest/git2/) Rust bindings, to read git config. I am worried that perhaps this doesn't recognise the `GIT_CONFIG_GLOBAL` env var. So basically I'm worried that the way the test script is creating a sandboxed git repro environment might be confusing us: my suggestion of `git config -l` of course wasn't great either as it uses native git code to read git config, not libgit2.\r\n\r\nIs it possible that there is something about the way you keep your real gitconfig on disk that, while it works for native git, does not work for libgit2 (and hence not for delta)?\r\n\r\nCan you set delta settings other than `side-by-side` in your real gitconfig? I hope not!","createdAt":"2022-06-25T12:21:51Z","includesCreatedEdit":true,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/1113#issuecomment-1166272267","viewerDidAuthor":true},{"id":"IC_kwDOC4j8g85FhCqx","author":{"login":"tkf144"},"authorAssociation":"NONE","body":"Thanks @dandavison. That makes sense; looks like someone has previously raised this in https://github.com/libgit2/libgit2/issues/6182.\r\n\r\n>Can you set delta settings other than side-by-side in your real gitconfig? I hope not!\r\n\r\nI double-checked and `line-numbers` had no effect either - delta is safe :)\r\n\r\n>Is it possible that there is something about the way you keep your real gitconfig on disk that, while it works for native git, does not work for libgit2 (and hence not for delta)?\r\n\r\nThere sure is. It relates to how I have my `gitconfig`s split up for different machines/envs and also topics, i.e. there are several 'partial' files. Exporting `GIT_CONFIG_KEY_N`+`GIT_CONFIG_VALUE_N` allows one to set Git config items (e.g. `include.path`), which is how I'm loading these due to use of variables (which `gitconfig` doesn't support, beyond `$HOME`). IIRC, `GIT_CONFIG_{KEY,VALUE}_N` are recent additions to Git, so if `GIT_CONFIG_GLOBAL` is not yet supported by libgit2, then the former is also unlikely to be.\r\n\r\nNow that I know what's going on, I'm happy to work around it. Please feel free to do as you wish with this issue. Thanks for the great software Dan!","createdAt":"2022-06-25T13:41:32Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/1113#issuecomment-1166289585","viewerDidAuthor":false},{"id":"IC_kwDOC4j8g85FhHuy","author":{"login":"dandavison"},"authorAssociation":"OWNER","body":"OK, excellent, I'm glad we've got to the bottom of that. I think the title you've given this issue stands a good chance of helping others that encounter this problem so I'll close this as I don't think we have current delta development suggestions following from it. However, that's not to say that a mention in the manual that delta uses libgit2 to read config would hurt, especially if others run into similar problems.","createdAt":"2022-06-25T15:28:13Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[{"content":"THUMBS_UP","users":{"totalCount":2}}],"url":"https://github.com/dandavison/delta/issues/1113#issuecomment-1166310322","viewerDidAuthor":true},{"id":"IC_kwDOC4j8g85JskJ3","author":{"login":"ethanmsl"},"authorAssociation":"NONE","body":"I'd like to suggest that this limitation of libgit2 be noted more clearly somewhere. \r\n(and this thread left as something other than _closed_, I think -- since it's a user-impacting issue that people might look for, even if it's an upstream issue that the delta team doesn't plan to directly address.)\r\n\r\nI spent a fair bit of time looking through repo and manual and exploring setting options to find out what the problem was.\r\nIn order to find this issue one has to establish that the cause is manually setting the `GIT_CONFIG_(GLOBAL/SYSTEM)` path variable. Only after ruling out a number of other issues that could cause the problem. (e.g. syntax issues, mis-installation issues, etc.)\r\n\r\nAnd it's something that the people who collect their dotfiles for organizational and git'ing purposes probably have an interest in.\r\n\r\nPending a C-lang PR to [fix the libgit2 issue](https://github.com/libgit2/libgit2/issues/6182#issuecomment-1217989107) a workaround is to pass the variables that would be set in toml as arguments to the pager variable itself.\r\ne.g.: \r\n ```\r\n [core]\r\n pager = delta --navigate --line-numbers --side-by-side\r\n ```\r\n\r\nSince git, ofc, respects the GIT_CONFIG_... path it can run pager correctly this way. (What differences may lurk between argument and toml set-up I couldn't say.)","createdAt":"2022-09-04T21:33:15Z","includesCreatedEdit":true,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/1113#issuecomment-1236419191","viewerDidAuthor":false},{"id":"IC_kwDOC4j8g85Jvl8n","author":{"login":"dandavison"},"authorAssociation":"OWNER","body":"Hi @ethanmsl, thanks, I agree with your suggestions. I've updated the [Configuration](https://dandavison.github.io/delta/configuration.html) section in the manual, and added a new [Environment variables](https://dandavison.github.io/delta/environment-variables.html) section.\r\n\r\nI also think that delta should have a `delta doctor` (or `delta --doctor`) command, and I've opened https://github.com/dandavison/delta/issues/1184 for that.","createdAt":"2022-09-05T15:31:19Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/1113#issuecomment-1237212967","viewerDidAuthor":true}],"number":1113,"title":"🐛 Delta settings do not use .gitconfig set in GIT_CONFIG_GLOBAL env var"},{"body":"Running `git am -i PATCH` and pressing 'v' for 'view patch' results in\r\n\r\n```\r\nThe main way to use delta is to configure it as the pager for git: see https://github.com/dandavison/delta#configuration. You can also use delta to diff two files: `delta file_A file_B`.\r\nCommit Body is:\r\n-------------------------------\r\n```\r\n\r\nwith the suggested configuration.","comments":[],"number":1109,"title":"🐛 Issue when using git am"},{"body":"```\r\n 390⋮ 392│ bool operator<(const RowIndex & rhs) const {\r\nthread 'main' panicked at 'byte index 2420 is not a char boundary; it is inside '�' (bytes 2418..2421) of `-V�&/�E�w�諙j^�Gq#���X �۱#�Fai�]���lc�A���c\"{A��4m��Ӣ����8Y����r�� ��u�(�;2��/���F�?��\r\n R\"�49�w��P� v���Ě�g3g��J\"�&��5��`[...]', library/core/src/str/mod.rs:127:5\r\nnote: run with `RUST_BACKTRACE=1` environment variable to display a backtrace\r\n...skipping...\r\n```\r\n\r\nVersion: git-delta v0.13.0: delta\r\n\r\nI paste it here so it does not get lost. I hope to be able to get more details.","comments":[],"number":1093,"title":"WIP: Unreproducible panic without BT"},{"body":"Sometimes syntax highlighting is wrong, especially when the patch text begins in the middle of a multi-line comment or string.\r\n\r\nThis could be resolved by inputting a wider context e.g.\r\n\r\n`git show HEAD -U100000000 | delta --side-by-side`\r\n\r\n... however this creates a much larger output.\r\n\r\nThis could be resolved by supporting narrowing the text displayed before/after in delta, e.g.\r\n\r\n`git show HEAD -U100000000 | delta --side-by-side -U4`\r\n\r\n... which would syntax highlight using the wider context and only show fewer lines with delta's output.\r\n\r\n","comments":[{"id":"IC_kwDOC4j8g85FhMhI","author":{"login":"dandavison"},"authorAssociation":"OWNER","body":"Hi @ideasman42, I agree, this sounds like a pretty good suggestion. Ref https://github.com/dandavison/delta/issues/117","createdAt":"2022-06-25T17:26:58Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/1091#issuecomment-1166329928","viewerDidAuthor":true},{"id":"IC_kwDOC4j8g85xAhwU","author":{"login":"dandavison"},"authorAssociation":"OWNER","body":"Sorry there's been no action here. I still think this is a very good suggestion (and one which I had not thought of).","createdAt":"2024-01-17T14:47:32Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/1091#issuecomment-1895963668","viewerDidAuthor":true}],"number":1091,"title":"🚀 Improve syntax highlighting by narrowing context"},{"body":"- [x] Please include the raw text output from git, so that we can reproduce the problem.\r\n (You can use `git --no-pager` to produce the raw text output.)\r\n- [x] A screenshot of Delta's output is often helpful also.\r\n\r\nLooks like something similar to #1011 \r\n```\r\n❮ =git --no-pager diff\r\ndiff --git a/git/.gitconfig b/git/.gitconfig\r\nindex d1d04b4..ebc8229 100644\r\n--- a/git/.gitconfig\r\n+++ b/git/.gitconfig\r\n@@ -3,7 +3,7 @@\r\n path = ~/.git_author\r\n [core]\r\n excludesfile = ~/.dotfiles/git/ignore\r\n- pager = less -FSRX\r\n+ pager = (type delta > /dev/null 2>&1 && delta | less -FSRX) || less -FSRX\r\n [color]\r\n diff = auto\r\n status = auto\r\n❯ =git diff\r\n\r\ngit/.gitconfig\r\n────────────────────────────────────────────────────────────────────────────────\r\n\r\n───┐\r\n3: │\r\n───┘\r\n│ 3 │ path = ~/.git_author │ 3 │ path = ~/.git_author\r\n│ 4 │[core] │ 4 │[core]\r\n│ 5 │ excludesfile = ~/.dotfiles/git/↴│ 5 │ excludesfile = ~/.dotfiles/git/↴\r\n│ │ …ignore│ │ …ignore\r\n│ 6 │ pager = less -FSRX │ │\r\n│ │ │ 6 │ pager = (type delta > /dev/null↵\r\n│ │ │ │ 2>&1 && delta | less -FSRX) || l↵\r\n│ │ │ │ess -FSRX \r\n│ 7 │[color] │ 7 │[color]\r\n│ 8 │ diff = auto │ 8 │ diff = auto\r\n│ 9 │ status = auto │ 9 │ status = auto\r\n❯ echo $COLUMNS\r\n223\r\n❯ tput cols\r\n223\r\n❯ =git --version\r\ngit version 2.30.2\r\n```\r\n\r\n","comments":[{"id":"IC_kwDOC4j8g85CjTff","author":{"login":"msuriar"},"authorAssociation":"NONE","body":"Actually, more useful screenshot showing full terminal width:\r\n\r\n\r\n","createdAt":"2022-05-03T20:19:15Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/1068#issuecomment-1116551135","viewerDidAuthor":false},{"id":"IC_kwDOC4j8g85Lx1QF","author":{"login":"th1000s"},"authorAssociation":"COLLABORATOR","body":"When you pipe the output to less (`delta | less -FSRX`) then delta does not write to the terminal and can not query it for the exact width, so it falls back to the default. Try to skip piping the output to `less`.\r\n\r\nIf you need to call `less` with specific arguments, set these in the `LESS` environment variable.","createdAt":"2022-10-07T09:33:34Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[{"content":"THUMBS_UP","users":{"totalCount":1}}],"url":"https://github.com/dandavison/delta/issues/1068#issuecomment-1271354373","viewerDidAuthor":false}],"number":1068,"title":"Column width incorrectly deduced on Linux terminal on ChromeOS 🐛 "},{"body":"Hello, and thank you for this awesome project!\r\n\r\nIs it possible to colour renames, or adding and deleting of files?\r\n\r\n\r\n\r\n\r\nThe above is from diff-so-fancy. It makes it easier to see what has happened to a file.\r\n\r\nOn delta I have it like so:\r\n\r\n\r\nThe text of the whole line has to be one colour, which makes it a bit difficult to read.","comments":[{"id":"IC_kwDOC4j8g85CTowx","author":{"login":"dandavison"},"authorAssociation":"OWNER","body":"Hi @mustaqimM, thanks, I agree that looks nice. It should be fairly easily doable (feel free to make a PR if you like!).","createdAt":"2022-04-28T16:58:20Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/1060#issuecomment-1112443953","viewerDidAuthor":true}],"number":1060,"title":"🚀 Colour old, new and renamed file names?"},{"body":"I think the way VS Code handles diff is very good and clear.\r\nIt would be cool if I had a similar option using delta.\r\n\r\nVS Code diff:\r\n\r\n\r\nDelta:\r\n\r\n","comments":[{"id":"IC_kwDOC4j8g85CQLPp","author":{"login":"dandavison"},"authorAssociation":"OWNER","body":"Hi @igoracmelo, thanks for this. Does `word-diff-regex=.` do it (or a similar variant)?\r\n\r\n<img width=\"415\" alt=\"image\" src=\"https://user-images.githubusercontent.com/52205/165640565-b4907d6a-12d7-4780-8c26-20f937c6add7.png\">\r\n\r\nSome brief documentation of it is in `delta --help` as usual.","createdAt":"2022-04-27T22:19:59Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[{"content":"THUMBS_UP","users":{"totalCount":2}}],"url":"https://github.com/dandavison/delta/issues/1059#issuecomment-1111536617","viewerDidAuthor":true}],"number":1059,"title":"🚀 Highlight character difference, similarly to VS Code"},{"body":"```bash\r\n$ delta --version\r\ndelta 0.12.1\r\n$ delta --list-syntax-themes\r\nLight syntax themes:\r\n GitHub\r\n Monokai Extended Light\r\n OneHalfLight\r\n Solarized (light)\r\n gruvbox-light\r\n\r\nDark syntax themes:\r\n 1337\r\n Coldark-Cold\r\n Coldark-Dark\r\n DarkNeon\r\n Dracula\r\n Monokai Extended\r\n Monokai Extended Bright\r\n Monokai Extended Origin\r\n Nord\r\n OneHalfDark\r\n Solarized (dark)\r\n Sublime Snazzy\r\n TwoDark\r\n Visual Studio Dark+\r\n ansi\r\n base16\r\n base16-256\r\n gruvbox-dark\r\n zenburn\r\n\r\nUse delta --show-syntax-themes to demo the themes.\r\n```\r\n\r\nI found git-delta on Hacker News and wanted to give it a try. The example configuration was easy enough to set up.\r\n\r\nHowever, the default colour scheme is not great. I wanted to set up OneHalfLight, which is listed as available theme. I spend quite some time trying to figure that out. Unfortunately I couldn't find an example or explanation in your documentation and I could not find anything using a search engine neither.\r\n\r\nSince `delta` advertises itself as using `bat`'s builtin themes, I think it would be fitting to explicitly demonstrate how to configure one.","comments":[{"id":"IC_kwDOC4j8g85Bzire","author":{"login":"dandavison"},"authorAssociation":"OWNER","body":"Hi @MaxG87 I think you're right that this could be more explicit in the user manual: https://dandavison.github.io/delta/configuration.html?search=syntax-theme\r\n\r\nHowever, have you consulted `delta --help`? That is the point-of-truth for delta configuration options. See:\r\n\r\n```\r\n --syntax-theme <SYNTAX_THEME>\r\n The syntax-highlighting theme to use.\r\n\r\n Use --show-syntax-themes to demo available themes. Defaults to the value of the BAT_THEME environment variable, if that contains a valid theme name. --syntax-theme=none disables all syntax highlighting.\r\n``` \r\n\r\nand there is an example further down in the `--help` output\r\n\r\n```\r\n syntax-theme = Dracula\r\n plus-style = bold syntax \"#002800\"\r\n```\r\n\r\nIn gitconfig you do not need to quote a syntax theme even if it contains spaces. (But on the shell command line you would of course need to quote a string containing spaces) ","createdAt":"2022-04-20T14:55:30Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/1050#issuecomment-1104030430","viewerDidAuthor":true},{"id":"IC_kwDOC4j8g85B0OFM","author":{"login":"MaxG87"},"authorAssociation":"NONE","body":"Sorry, I missed that. I was a bit overwhelmed by the configurability. In particular I searched for _style_ pretty long, noticed they are related to _features_, and finally noticed it should be _themes_. Then I gave up. Until your reply I wasn't even aware I should configure `--syntax-theme`.\r\n\r\nAnyhow, your reply really helped me. Thank you very much.","createdAt":"2022-04-20T17:19:30Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/1050#issuecomment-1104208204","viewerDidAuthor":false}],"number":1050,"title":"🚀 Please provide documentation how to enable a syntax theme of `bat`"},{"body":"- [x] Please include the raw text output from git, so that we can reproduce the problem. \r\n```\r\n countDone += 1;\r\n progressEl.innerHTML = ` — Load${\r\n countDone === numFiles ? \"ed\" : \"ing\"\r\n- } ${countDone}/${numFiles} (${(countDone / numFiles) * 100}%)`;\r\n+ } ${countDone}/${numFiles} (${Math.round(\r\n+ (countDone / numFiles) * 100\r\n+ )}%)`;\r\n if (numFiles === countDone) {\r\n renderTimeline(objects);\r\n // progressEl.innerHTML = \"\";\r\n- setTimeout(() => {\r\n- document\r\n- .getElementById(\"log-x\")\r\n- .classList.add(\"hidden\");\r\n- }, 2000);\r\n+ if (!didAutoHide) {\r\n+ didAutoHide = true;\r\n+ setTimeout(() => {\r\n+ // do not hide if user seems to be interacting\r\n+ const logX = document.getElementById(\"log-x\");\r\n+ if (!logX.nextElementSibling.matches(\":hover\")) {\r\n+ logX.classList.add(\"hidden\");\r\n+ }\r\n+ }, 3000);\r\n+ }\r\n }\r\n };\r\n fileReader.readAsArrayBuffer(file);\r\n```\r\n- [x] A screenshot of Delta's output is often helpful also. \r\n<img width=\"728\" alt=\"image\" src=\"https://user-images.githubusercontent.com/1542910/162908436-58dab2ef-5310-47d1-9931-ecb2fddbacb1.png\">\r\n\r\n\r\n","comments":[],"number":1043,"title":"🐛 Syntax parse issue (js template string?)"},{"body":"Hi,\r\n\r\nWhile working on #1037 I noticed this comments:\r\n```rust\r\n // TODO: Git recognizes blank lines at end of file (blank-at-eof)\r\n // as a whitespace error but delta does not yet.\r\n // https://git-scm.com/docs/git-config#Documentation/git-config.txt-corewhitespace\r\n```\r\n\r\nI have a local working version for detecting theses lines, the only remaining issue is: How should we display such line ?\r\n* Do you want to stop everything to print a error ?\r\n* Do you want to print a specific graphical char ? (I am thinking of zsh with it's reversed `%`: \r\n\r\n\r\n ","comments":[{"id":"IC_kwDOC4j8g85ccjuN","author":{"login":"wescande"},"authorAssociation":"CONTRIBUTOR","body":"Adding illustration for easier understanding of the issue. Top is delta, bottom is raw git.\r\n<img src=https://github.com/dandavison/delta/assets/20841006/602fe7b8-273c-4d12-9d6a-4448d5391f69 width=300>","createdAt":"2023-05-17T08:40:29Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/1038#issuecomment-1550990221","viewerDidAuthor":false},{"id":"IC_kwDOC4j8g85cd_lS","author":{"login":"dandavison"},"authorAssociation":"OWNER","body":"I think a specific graphical character. `bat -A` uses `␊` to show `\\n` characters. Or perhaps `⏎` is sufficient and clearer here. (There's a discussion here about making delta display whitespace characters which is relevant I think: https://github.com/dandavison/delta/issues/522)","createdAt":"2023-05-17T13:10:45Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[{"content":"THUMBS_UP","users":{"totalCount":1}}],"url":"https://github.com/dandavison/delta/issues/1038#issuecomment-1551366482","viewerDidAuthor":true}],"number":1038,"title":"🚀 Warn for blank at eof (Question)"},{"body":"`0.11.3` worked fine on RHEL8/Centos8/RockyLinux8, but now `delta-0.12.1-x86_64-unknown-linux-gnu.tar.gz` gives:\r\n\r\n```\r\ndelta: /lib64/libc.so.6: version `GLIBC_2.29' not found (required by delta)\r\n```\r\nMaybe another binary might work? I am not sure what all the extensions mean.\r\n\r\nCan you please keep on supporting GLIBC_2.28? Thanks!\r\n","comments":[{"id":"IC_kwDOC4j8g85GG1cC","author":{"login":"phil-blain"},"authorAssociation":"CONTRIBUTOR","body":"I confirm (on RHEL 8.3).","createdAt":"2022-07-06T13:03:29Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/1029#issuecomment-1176196866","viewerDidAuthor":false},{"id":"IC_kwDOC4j8g85GG2T6","author":{"login":"David-Else"},"authorAssociation":"NONE","body":"`unknown-linux-musl.tar.gz` works OK.","createdAt":"2022-07-06T13:07:02Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[{"content":"THUMBS_UP","users":{"totalCount":1}}],"url":"https://github.com/dandavison/delta/issues/1029#issuecomment-1176200442","viewerDidAuthor":false},{"id":"IC_kwDOC4j8g85GG_GC","author":{"login":"phil-blain"},"authorAssociation":"CONTRIBUTOR","body":"Thanks for the workaround ! I wouldn't have thought of trying a musl-compiled binary on a glibc system. It does work though, since the `delta` binary in the `-musl` tarball is a static executable.","createdAt":"2022-07-06T13:40:29Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/1029#issuecomment-1176236418","viewerDidAuthor":false},{"id":"IC_kwDOC4j8g85GG_nT","author":{"login":"dandavison"},"authorAssociation":"OWNER","body":"Hi all, I do not have particular expertise in this area. I believe that delta binaries are being built using procedures that are standard for Rust projects building via GitHub actions, so I don't _think_ there are delta bugs in this area. However, I am open to advice / suggestions here and it's of course possible that something can be improved in the delta build config: https://github.com/dandavison/delta/blob/master/.github/workflows/cd.yml","createdAt":"2022-07-06T13:42:29Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/1029#issuecomment-1176238547","viewerDidAuthor":true},{"id":"IC_kwDOC4j8g85GHAaz","author":{"login":"dandavison"},"authorAssociation":"OWNER","body":"One strategy for investigating that comes to mind would be, if you come across a delta binary that is problematic, one could check a Rust+GitHubActions project such as `bat` or `ripgrep` to see whether they build a binary for the same architecture/libc, and see whether the same problem occurs with their binary.","createdAt":"2022-07-06T13:45:35Z","includesCreatedEdit":true,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/1029#issuecomment-1176241843","viewerDidAuthor":true},{"id":"IC_kwDOC4j8g85GHBo7","author":{"login":"phil-blain"},"authorAssociation":"CONTRIBUTOR","body":"I googled a bit and it seems it is requiring the glibc version of the system where it's compiled. One alternative is to build in a Docker container (like the offical Rust ones).","createdAt":"2022-07-06T13:49:57Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/1029#issuecomment-1176246843","viewerDidAuthor":false},{"id":"IC_kwDOC4j8g85GHE1Y","author":{"login":"phil-blain"},"authorAssociation":"CONTRIBUTOR","body":"In fact looking at https://github.com/sharkdp/bat/pull/2194 it seems it is only a matter of setting `use-cross=true` also for `x86_64-unknown-linux-gnu` :)","createdAt":"2022-07-06T14:00:56Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/1029#issuecomment-1176259928","viewerDidAuthor":false}],"number":1029,"title":"🚀 Continue to support GLIBC_2.28 in binary release"},{"body":"delta has its zsh completion\r\n<https://github.com/dandavison/delta/blob/master/etc/completion/completion.zsh>,\r\nhowever it cannot work, because\r\n</usr/share/zsh/functions/Completion/Unix/_sccs> will override it.\r\n\r\n```\r\n❯ rg delta ~/.zcompdump\r\n296:'delta' '_sccs'\r\n❯ delta -<Tab>\r\noption\r\n-s silent\r\n-y specify delta commentary\r\n```\r\n\r\nAny method to avoid this conflict? Thanks!","comments":[{"id":"IC_kwDOC4j8g85AASUS","author":{"login":"Freed-Wu"},"authorAssociation":"NONE","body":"Oh, I found it is a bug of delta, because by default, `/usr/local/share/zsh/site-functions/_delta` is priorer than `/usr/share/zsh/functions/Completion/Unix/_sccs`\r\n\r\n```\r\n❯ print -l $fpath\r\n/home/wzy/.local/share/zinit/completions\r\n/usr/local/share/zsh/site-functions\r\n/usr/share/zsh/site-functions\r\n/usr/share/zsh/functions/Calendar\r\n/usr/share/zsh/functions/Chpwd\r\n/usr/share/zsh/functions/Completion\r\n/usr/share/zsh/functions/Completion/Base\r\n/usr/share/zsh/functions/Completion/Linux\r\n/usr/share/zsh/functions/Completion/Unix\r\n...\r\n```\r\n\r\nHowever, `/usr/local/share/zsh/site-functions/_delta` has a syntax error, which make zsh skip it: any zsh completion file should start with `#compdef delta` to tell zsh it is a completion file for delta, but `_delta` not:\r\n\r\n```\r\ncompdef _gnu_generic delta\r\n```\r\n\r\nAnd, even if we fix this bug, it is still a bad completion:\r\n\r\n```\r\n❯ delta -<Tab>\r\noption\r\n- If the input that delta is receiving already has colors, and you want delta to output those\r\n--line-numbers-left-format [Change the contents of the left column\r\n--line-numbers-left-style [Change the style applied to the left column\r\n--line-numbers-minus-style [Change the style applied to line numbers in minus lines\r\n--line-numbers-plus-style [Change the style applied to line numbers in plus lines\r\n--line-numbers-right-format [Change the contents of the right column\r\n--line-numbers-right-style [Change the style applied to the right column\r\n--line-numbers-zero-style [Change the style applied to line numbers in unchanged lines\r\n--minus-style 'red bold ul \"#ffeeee\"'\r\n------ -------- ---------- ------------ --file-style\r\n```\r\n\r\n`----` should not occur in the completion list.","createdAt":"2022-03-21T12:09:35Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/1022#issuecomment-1073816850","viewerDidAuthor":false},{"id":"IC_kwDOC4j8g85ABBJn","author":{"login":"Freed-Wu"},"authorAssociation":"NONE","body":"This is a dirty realization, because `delta --list-*` is difficult to parse because it has ansicolor which cannot be disabled, wrap lines.\r\n\r\n```\r\n❯ delta --<Tab>\r\noption\r\n--24-bit-color Deprecated: use --true-color\r\n--blame-code-style Style string for the code section of a git blame line\r\n--blame-format Format string for git blame commit metadata (default: \"{timestamp:<15} {author:<15.14} {commit:<8}\")\r\n--blame-palette Background colors used for git blame lines (space-separated string)\r\n--blame-separator-format Separator between the blame format and the code section of a git blame line (default: │{n:^4}│)\r\n--blame-separator-style Style string for the blame-separator-format\r\n...\r\n❯ delta --syntax-theme <Tab>\r\n(syntax_theme)\r\n1337 dark\r\nansi dark\r\nbase16-256 dark\r\nbase16 dark\r\nColdark-Cold dark\r\n...\r\n❯ delta --default-language <Tab>\r\n(lang)\r\nActionScript as\r\nApache_Conf envvars,_htaccess,_HTACCESS,_htgroups,_HTGROUPS,_htpasswd,_HTPASSWD,_.htaccess,_.HTACCESS,_.htgroups,_.HTGROUPS,_.htpasswd,_.HTPASSWD\r\nAppleScript applescript,_script_editor\r\nARM_Assembly s,_S\r\nASP asa\r\nAuthorized_Keys authorized_keys,_pub\r\nAWK awk\r\nBatch_File bat,_cmd\r\n...\r\n```\r\n\r\n```zsh\r\n#compdef delta\r\n\r\n__delta() {\r\n local lang='\r\n ActionScript\\:as\r\n Apache_Conf\\:envvars,_htaccess,_HTACCESS,_htgroups,_HTGROUPS,_htpasswd,_HTPASSWD,_.htaccess,_.HTACCESS,_.htgroups,_.HTGROUPS,_.htpasswd,_.HTPASSWD\r\n AppleScript\\:applescript,_script_editor\r\n ARM_Assembly\\:s,_S\r\n AsciiDoc_(Asciidoctor)\\:adoc,_ad,_asciidoc\r\n ASP\\:asa\r\n Assembly_(x86_64)\\:yasm,_nasm,_asm,_inc,_mac\r\n Authorized_Keys\\:authorized_keys,_pub\r\n AWK\\:awk\r\n Batch_File\\:bat,_cmd\r\n BibTeX\\:bib\r\n Bourne_Again_Shell_(bash)\\:sh,_bash,_zsh,_ash,_.bash_aliases,_.bash_completions,_.bash_functions,_.bash_login,_.bash_logout,_.bash_profile,_.bash_variables,_.bashrc,_.profile,_.textmate_init,_.zlogin,_.zlogout,_.zprofile,_.zshenv,_.zshrc,_PKGBUILD,_ebuild,_eclass\r\n C\\:c,_h\r\n C#\\:cs,_csx\r\n C++\\:cpp,_cc,_cp,_cxx,_c++,_C,_h,_hh,_hpp,_hxx,_h++,_inl,_ipp\r\n Cabal\\:cabal\r\n Clojure\\:clj,_cljc,_cljs,_edn\r\n CMake\\:CMakeLists.txt,_cmake\r\n CMake_C_Header\\:h.in\r\n CMake_C++_Header\\:hh.in,_hpp.in,_hxx.in,_h++.in\r\n CMakeCache\\:CMakeCache.txt\r\n CoffeeScript\\:coffee,_Cakefile,_coffee.erb,_cson\r\n Comma_Separated_Values\\:csv,_tsv\r\n CpuInfo\\:cpuinfo\r\n Crystal\\:cr\r\n CSS\\:css,_css.erb,_css.liquid\r\n D\\:d,_di\r\n Dart\\:dart\r\n Diff\\:diff,_patch\r\n Dockerfile\\:Dockerfile,_dockerfile\r\n DotENV\\:.env,_.env.dist,_.env.local,_.env.sample,_.env.example,_.env.test,_.env.test.local,_.env.testing,_.env.dev,_.env.development,_.env.development.local,_.env.prod,_.env.production,_.env.production.local,_.env.dusk.local,_.env.staging,_.env.default,_.env.defaults,_.envrc,_.flaskenv\r\n Elixir\\:ex,_exs\r\n Elm\\:elm\r\n Email\\:eml,_msg,_mbx,_mboxz\r\n Erlang\\:erl,_hrl,_Emakefile,_emakefile,_escript\r\n F#\\:fs,_fsi,_fsx\r\n Fortran_(Fixed_Form)\\:f,_F,_f77,_F77,_for,_FOR,_fpp,_FPP\r\n Fortran_(Modern)\\:f90,_F90,_f95,_F95,_f03,_F03,_f08,_F08\r\n Fortran_Namelist\\:namelist\r\n Friendly_Interactive_Shell_(fish)_fish\r\n fstab\\:fstab,_crypttab,_mtab\r\n Git_Attributes\\:attributes,_gitattributes,_.gitattributes\r\n Git_Commit\\:COMMIT_EDITMSG,_MERGE_MSG,_TAG_EDITMSG\r\n Git_Config\\:gitconfig,_.gitconfig,_.gitmodules\r\n Git_Ignore\\:exclude,_gitignore,_.gitignore\r\n Git_Link\\:.git\r\n Git_Log\\:gitlog\r\n Git_Mailmap\\:.mailmap,_mailmap\r\n Git_Rebase_Todo\\:git-rebase-todo\r\n GLSL\\:vs,_fs,_gs,_vsh,_fsh,_gsh,_vshader,_fshader,_gshader,_vert,_frag,_geom,_tesc,_tese,_comp,_glsl,_mesh,_task,_rgen,_rint,_rahit,_rchit,_rmiss,_rcall\r\n gnuplot\\:gp,_gpl,_gnuplot,_gnu,_plot,_plt\r\n Go\\:go\r\n GraphQL\\:graphql,_graphqls,_gql\r\n Graphviz_(DOT)\\:dot,_DOT,_gv\r\n Groff/troff\\:groff,_troff,_1,_2,_3,_4,_5,_6,_7,_8,_9\r\n Groovy\\:groovy,_gvy,_gradle,_Jenkinsfile\r\n group\\:group\r\n Haskell\\:hs\r\n Highlight_non-printables\\:show-nonprintable\r\n hosts\\:hosts\r\n HTML\\:html,_htm,_shtml,_xhtml\r\n HTML_(ASP)\\:asp\r\n HTML_(EEx)\\:html.eex,_html.leex\r\n HTML_(Erlang)\\:yaws\r\n HTML_(Jinja2)\\:htm.j2,_html.j2,_xhtml.j2,_xml.j2\r\n HTML_(Rails)\\:rails,_rhtml,_erb,_html.erb\r\n HTML_(Tcl)\\:adp\r\n HTML_(Twig)\\:twig,_html.twig\r\n HTTP_Request_and_Response\\:http\r\n INI\\:ini,_INI,_reg,_REG,_lng,_cfg,_CFG,_desktop,_url,_URL,_.editorconfig,_.hgrc,_hgrc\r\n Java\\:java,_bsh\r\n Java_Properties\\:properties\r\n Java_Server_Page_(JSP)\\:jsp\r\n JavaScript\\:js,_htc\r\n JavaScript_(Babel)\\:js,_mjs,_jsx,_babel,_es6,_cjs\r\n JavaScript_(Rails)\\:js.erb\r\n Jinja2\\:j2,_jinja2,_jinja\r\n JQ\\:jq\r\n JSON\\:json,_sublime-settings,_sublime-menu,_sublime-keymap,_sublime-mousemap,_sublime-theme,_sublime-build,_sublime-project,_sublime-completions,_sublime-commands,_sublime-macro,_sublime-color-scheme,_ipynb,_Pipfile.lock\r\n jsonnet\\:jsonnet,_libsonnet,_libjsonnet\r\n Julia\\:jl\r\n Known_Hosts\\:known_hosts\r\n Kotlin\\:kt,_kts\r\n LaTeX\\:tex,_ltx\r\n Lean\\:lean\r\n Less\\:less,_css.less\r\n Lisp\\:lisp,_cl,_clisp,_l,_mud,_el,_scm,_ss,_lsp,_fasl\r\n Literate_Haskell\\:lhs\r\n LiveScript\\:ls,_Slakefile,_ls.erb\r\n LLVM\\:ll\r\n log\\:log\r\n Lua\\:lua\r\n Makefile\\:make,_GNUmakefile,_makefile,_Makefile,_makefile.am,_Makefile.am,_makefile.in,_Makefile.in,_OCamlMakefile,_mak,_mk\r\n Manpage\\:man\r\n Markdown\\:md,_mdown,_markdown,_markdn\r\n MATLAB\\:matlab\r\n MediaWiki\\:mediawiki,_wikipedia,_wiki\r\n MemInfo\\:meminfo\r\n NAnt_Build_File\\:build\r\n nginx\\:conf.erb,_conf,_nginx.conf,_mime.types,_fastcgi_params,_scgi_params,_uwsgi_params\r\n Nim\\:nim,_nims,_nimble\r\n Ninja\\:ninja\r\n Nix\\:nix\r\n Objective-C\\:m,_h\r\n Objective-C++\\:mm,_M,_h\r\n OCaml\\:ml,_mli\r\n OCamllex\\:mll\r\n OCamlyacc\\:mly\r\n orgmode\\:org\r\n Pascal\\:pas,_p,_dpr\r\n passwd\\:passwd\r\n Perl\\:pl,_pc,_pm,_pmc,_pod,_t\r\n PHP\\:php,_php3,_php4,_php5,_php7,_phps,_phpt,_phtml\r\n Plain_Text\\:txt\r\n PowerShell\\:ps1,_psm1,_psd1\r\n Protocol_Buffer\\:proto,_protodevel\r\n Protocol_Buffer_(TEXT)\\:pb.txt,_proto.text,_textpb,_pbtxt,_prototxt\r\n Puppet\\:pp,_epp\r\n PureScript\\:purs\r\n Python\\:py,_py3,_pyw,_pyi,_pyx,_pyx.in,_pxd,_pxd.in,_pxi,_pxi.in,_rpy,_cpy,_SConstruct,_Sconstruct,_sconstruct,_SConscript,_gyp,_gypi,_Snakefile,_vpy,_wscript,_bazel,_bzl\r\n QML\\:qml,_qmlproject\r\n R\\:R,_r,_Rprofile\r\n Racket\\:rkt\r\n Rd_(R_Documentation)\\:rd\r\n Rego\\:rego\r\n Regular_Expression\\:re\r\n resolv\\:resolv.conf\r\n reStructuredText\\:rst,_rest\r\n Robot_Framework\\:robot,_resource\r\n Ruby\\:rb,_Appfile,_Appraisals,_Berksfile,_Brewfile,_capfile,_cgi,_Cheffile,_config.ru,_Deliverfile,_Fastfile,_fcgi,_Gemfile,_gemspec,_Guardfile,_irbrc,_jbuilder,_Podfile,_podspec,_prawn,_rabl,_rake,_Rakefile,_Rantfile,_rbx,_rjs,_ruby.rail,_Scanfile,_simplecov,_Snapfile,_thor,_Thorfile,_Vagrantfile\r\n Ruby_Haml\\:haml,_sass\r\n Ruby_on_Rails\\:rxml,_builder\r\n Ruby_Slim\\:slim,_skim\r\n Rust\\:rs\r\n Salt_State_(SLS)\\:sls\r\n Sass\\:sass\r\n Scala\\:scala,_sbt,_sc\r\n SCSS\\:scss\r\n SML\\:sml,_cm,_sig\r\n Solidity\\:sol\r\n SQL\\:sql,_ddl,_dml\r\n SQL_(Rails)\\:erbsql,_sql.erb\r\n SSH_Config\\:ssh_config\r\n SSHD_Config\\:sshd_config\r\n Strace\\:strace\r\n Stylus\\:styl,_stylus\r\n Svelte\\:svlt,_svelte\r\n Swift\\:swift\r\n syslog\\:syslog\r\n SystemVerilog\\:sv,_v,_svh,_vh\r\n Tcl\\:tcl\r\n Terraform\\:tf,_tfvars,_hcl\r\n TeX\\:sty,_cls\r\n Textile\\:textile\r\n TOML\\:toml,_tml,_Cargo.lock,_Gopkg.lock,_Pipfile,_poetry.lock\r\n TypeScript\\:ts\r\n TypeScriptReact\\:tsx\r\n varlink\\:varlink\r\n Verilog\\:v,_V\r\n VimL\\:vim,_vimrc,_gvimrc,_.vimrc,_.gvimrc,__vimrc,__gvimrc\r\n Vue_Component\\:vue\r\n Vyper\\:vy\r\n XML\\:xml,_xsd,_xslt,_tld,_dtml,_rng,_rss,_opml,_svg,_xaml\r\n YAML\\:yaml,_yml,_sublime-syntax\r\n Zig\\:zig'\r\n local syntax_theme='\r\n GitHub\\:light\r\n Monokai_Extended_Light\\:light\r\n OneHalfLight\\:light\r\n Solarized_(light)\\:light\r\n gruvbox-light\\:light\r\n 1337\\:dark\r\n Coldark-Cold\\:dark\r\n Coldark-Dark\\:dark\r\n DarkNeon\\:dark\r\n Dracula\\:dark\r\n Monokai_Extended\\:dark\r\n Monokai_Extended_Bright\\:dark\r\n Monokai_Extended_Origin\\:dark\r\n Nord\\:dark\r\n OneHalfDark\\:dark\r\n Solarized_(dark)\\:dark\r\n Sublime_Snazzy\\:dark\r\n TwoDark\\:dark\r\n Visual_Studio_Dark+\\:dark\r\n ansi\\:dark\r\n base16\\:dark\r\n base16-256\\:dark\r\n gruvbox-dark\\:dark\r\n zenburn\\:dark'\r\n\r\n _arguments -s -S \\\r\n \"(- *)\"{-V,--version}'[Print version information]' \\\r\n \"(- *)\"{-h,--help}'[Print help information]' \\\r\n --blame-code-style'[Style string for the code section of a git blame line]:(style)' \\\r\n --blame-format'[Format string for git blame commit metadata (default: \"{timestamp:<15} {author:<15.14} {commit:<8}\")]:(fmt)' \\\r\n --blame-palette'[Background colors used for git blame lines (space-separated string)]:(colors)' \\\r\n --blame-separator-format'[Separator between the blame format and the code section of a git blame line (default: │{n:^4}│)]:(fmt)' \\\r\n --blame-separator-style'[Style string for the blame-separator-format]:(style)' \\\r\n --blame-timestamp-format'[Format of `git blame` timestamp in raw git output received by delta (default: \"%Y-%m-%d %H:%M:%S %z\")]:(fmt)' \\\r\n --color-only'[Do not alter the input structurally in any way]' \\\r\n --commit-decoration-style'[Style string for the commit hash decoration (default: )]:(style)' \\\r\n --commit-regex'[Regular expression used to identify the commit line when parsing git output (default: \"^commit \")]:(regex)' \\\r\n --commit-style'[Style string for the commit hash line (default: raw)]:(style)' \\\r\n --dark'[Use default colors appropriate for a dark terminal background]' \\\r\n --default-language\"[Default language used for syntax highlighting]:(lang):(($lang))\" \\\r\n --diff-highlight'[Emulate diff-highlight]' \\\r\n --diff-so-fancy'[Emulate diff-so-fancy]' \\\r\n --diff-stat-align-width'[Width allocated for file paths in a diff stat section (default: 48)]:(n)' \\\r\n --features'[Names of delta features to activate (space-separated)]:(features)' \\\r\n --file-added-label'[Text to display before an added file path (default: added:)]:(string)' \\\r\n --file-copied-label'[Text to display before a copied file path (default: copied:)]:(string)' \\\r\n --file-decoration-style'[Style string for the file decoration (default: \"blue ul\")]:(style)' \\\r\n --file-modified-label'[Text to display before a modified file path (default: )]:(string)' \\\r\n --file-removed-label'[Text to display before a removed file path (default: removed:)]:(string)' \\\r\n --file-renamed-label'[Text to display before a renamed file path (default: renamed:)]:(string)' \\\r\n --file-style'[Style string for the file section (default: blue)]:(style)' \\\r\n --file-transformation'[Sed-style command transforming file paths for display]:(sed_cmd)' \\\r\n --grep-context-line-style'[Style string for non-matching lines of grep output]:(style)' \\\r\n --grep-file-style'[Style string for file paths in grep output]:(style)' \\\r\n --grep-line-number-style'[Style string for line numbers in grep output]:(style)' \\\r\n --grep-match-line-style'[Style string for matching lines of grep output]:(style)' \\\r\n --grep-match-word-style'[Style string for the matching substrings within a matching line of grep output]:(style)' \\\r\n --grep-separator-symbol'[Separator symbol printed after the file path and line number in grep output (default: :)]:(string)' \\\r\n --hunk-header-decoration-style'[Style string for the hunk-header decoration (default: \"blue box\")]:(style)' \\\r\n --hunk-header-file-style'[Style string for the file path part of the hunk-header (default: blue)]:(style)' \\\r\n --hunk-header-line-number-style'[Style string for the line number part of the hunk-header (default: blue)]:(style)' \\\r\n --hunk-header-style'[Style string for the hunk-header (default: \"line-number syntax\")]:(style)' \\\r\n --hunk-label'[Text to display before a hunk header (default: )]:(string)' \\\r\n --hyperlinks'[Render commit hashes, file names, and line numbers as hyperlinks]' \\\r\n --hyperlinks-commit-link-format'[Format string for commit hyperlinks (requiraes --hyperlinks)]:(fmt)' \\\r\n --hyperlinks-file-link-format'[Format string for file hyperlinks (requires --hyperlinks) (default: file://{path})]:(fmt)' \\\r\n --inline-hint-style'[Style string for short inline hint text (default: blue)]:(style)' \\\r\n --inspect-raw-lines'[Kill-switch for --color-moved support (default: true)]:(bool):(true false)' \\\r\n --keep-plus-minus-markers'[Prefix added/removed lines with a +/- character, as git does]' \\\r\n --light'[Use default colors appropriate for a light terminal background]' \\\r\n --line-buffer-size'[Size of internal line buffer (default: 32)]:(n)' \\\r\n --line-fill-method'[Line-fill method in side-by-side mode]:(string)' \\\r\n {-n,--line-numbers}'[Display line numbers next to the diff]' \\\r\n --line-numbers-left-format'[Format string for the left column of line numbers (default: {nm:^4}⋮)]:(fmt)' \\\r\n --line-numbers-left-style'[Style string for the left column of line numbers (default: auto)]:(style)' \\\r\n --line-numbers-minus-style'[Style string for line numbers in the old (minus) version of the file (default: auto)]:(style)' \\\r\n --line-numbers-plus-style'[Style string for line numbers in the new (plus) version of the file (default: auto)]:(style)' \\\r\n --line-numbers-right-format'[Format string for the right column of line numbers (default: {np:^4}│)]:(fmt)' \\\r\n --line-numbers-right-style'[Style string for the right column of line numbers (default: auto)]:(style)' \\\r\n --line-numbers-zero-style'[Style string for line numbers in unchanged (zero) lines (default: auto)]:(style)' \\\r\n --list-languages'[List supported languages and associated file extensions]' \\\r\n --list-syntax-themes'[List available syntax-highlighting color themes]' \\\r\n --map-styles'[Map styles encountered in raw input to desired output styles]:(styles_map)' \\\r\n --max-line-distance'[Maximum line pair distance parameter in within-line diff algorithm (default: 0.6)]:(dist)' \\\r\n --max-line-length'[Truncate lines longer than this (default: 512)]:(n)' \\\r\n --merge-conflict-begin-symbol'[String marking the beginning of a merge conflict region (default: ▼)]:(string)' \\\r\n --merge-conflict-end-symbol'[String marking the end of a merge conflict region (default: ▲)]:(string)' \\\r\n --merge-conflict-ours-diff-header-decoration-style'[Style string for the decoration of the header above the \"ours\" merge conflict diff (default: box)]:(style)' \\\r\n --merge-conflict-ours-diff-header-style'[Style string for the header above the \"ours\" branch merge conflict diff (default: normal)]:(style)' \\\r\n --merge-conflict-theirs-diff-header-decoration-style'[Style string for the decoration of the header above the \"theirs\" merge conflict diff (default: box)]:(style)' \\\r\n --merge-conflict-theirs-diff-header-style'[Style string for the header above the \"theirs\" branch merge conflict diff (default: normal)]:(style)' \\\r\n --minus-empty-line-marker-style'[Style string for removed empty line marker (default: \"normal auto\")]:(style)' \\\r\n --minus-emph-style'[Style string for emphasized sections of removed lines (default: \"normal auto\")]:(style)' \\\r\n --minus-non-emph-style'[Style string for non-emphasized sections of removed lines that have an emphasized section (default: minus-style)]:(style)' \\\r\n --minus-style'[Style string for removed lines (default: \"normal auto\")]:(style)' \\\r\n --navigate'[Activate diff navigation]' \\\r\n --navigate-regex'[Regular expression defining navigation stop points]:(regex)' \\\r\n --no-gitconfig'[Do not read any settings from git config]' \\\r\n --pager'[Which pager to use]:(cmd)' \\\r\n --paging'[Whether to use a pager when displaying output (default: auto)]:(auto always never)' \\\r\n --parse-ansi'[Display ANSI color escape sequences in human-readable form]' \\\r\n --plus-emph-style'[Style string for emphasized sections of added lines (default: \"syntax auto\")]:(style)' \\\r\n --plus-empty-line-marker-style'[Style string for added empty line marker (default: \"normal auto\")]:(style)' \\\r\n --plus-non-emph-style'[Style string for non-emphasized sections of added lines that have an emphasized section (default: plus-style)]:(style)' \\\r\n --plus-style'[Style string for added lines (default: \"syntax auto\")]:(style)' \\\r\n --raw'[Do not alter the input in any way]' \\\r\n --relative-paths'[Output all file paths relative to the current directory]' \\\r\n --right-arrow'[Text to display with a changed file path (default: \"⟶\")]:(string)' \\\r\n --show-colors'[Show available named colors]' \\\r\n --show-config'[Display the active values for all Delta options]' \\\r\n --show-syntax-themes'[Show example diff for available syntax-highlighting themes]' \\\r\n --show-themes'[Show example diff for available delta themes]' \\\r\n {-s,--side-by-side}'[Display diffs in side-by-side layout]' \\\r\n --syntax-theme\"[The syntax-highlighting theme to use]:(syntax_theme):(($syntax_theme))\" \\\r\n --tabs'[The number of spaces to replace tab characters with (default: 4)]:(n)' \\\r\n --true-color'[Whether to emit 24-bit (\"true color\") RGB color codes (default: auto)]:(when):(auto always never)' \\\r\n --whitespace-error-style'[Style string for whitespace errors (default: \"auto auto\")]:(style)' \\\r\n {-w,--width}'[The width of underline/overline decorations]:(n)' \\\r\n --word-diff-regex'[Regular expression defining a \"word\" in within-line diff algorithm (default: \\w+)]:(regex)' \\\r\n --wrap-left-symbol'[End-of-line wrapped content symbol (left-aligned) (default: ↵)]:(string)' \\\r\n --wrap-max-lines'[How often a line should be wrapped if it does not fit (default: 2)]:(n)' \\\r\n --wrap-right-percent'[Threshold for right-aligning wrapped content (default: 37.0)]:(percent)' \\\r\n --wrap-right-prefix-symbol'[Pre-wrapped content symbol (right-aligned) (default: …)]:(string)' \\\r\n --wrap-right-symbol'[End-of-line wrapped content symbol (right-aligned) (default: ↴)]:(string)' \\\r\n --zero-style'[Style string for unchanged lines (default: \"syntax normal\")]:(style)' \\\r\n --24-bit-color'[Deprecated: use --true-color]:(when):(auto always never)' \\\r\n '1:minus_file First file to be compared when delta is being used in diff mode:_files' \\\r\n '2:plus_file Second file to be compared when delta is being used in diff mode:_files'\r\n}\r\n\r\n__delta\r\n```","createdAt":"2022-03-21T15:02:07Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/1022#issuecomment-1074008679","viewerDidAuthor":false},{"id":"IC_kwDOC4j8g85GyEnU","author":{"login":"latipun7"},"authorAssociation":"NONE","body":"Sorry to bump. Any update to this issue? I still has this same issue now.","createdAt":"2022-07-18T14:09:48Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/1022#issuecomment-1187531220","viewerDidAuthor":false},{"id":"IC_kwDOC4j8g85G_QTn","author":{"login":"Freed-Wu"},"authorAssociation":"NONE","body":"No:(\r\n\r\nI recommend generating shell completion script from code, by some library like <https://docs.rs/clap_complete/latest/clap_complete/>","createdAt":"2022-07-21T03:08:47Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/1022#issuecomment-1190986983","viewerDidAuthor":false},{"id":"IC_kwDOC4j8g85G_sbc","author":{"login":"latipun7"},"authorAssociation":"NONE","body":"That's something unpractical for me. I don't understand rust yet (and the learning curves). 😔","createdAt":"2022-07-21T06:42:35Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/1022#issuecomment-1191102172","viewerDidAuthor":false},{"id":"IC_kwDOC4j8g85JdGDi","author":{"login":"dandavison"},"authorAssociation":"OWNER","body":"Hi all, do you have any recommendations for me here? Should I delete the zsh completion script from the delta repo so that package managers don't install it? I think I would want some help if we were to maintain shell completions (e.g. like https://github.com/sharkdp/bat/tree/master/assets/completions)","createdAt":"2022-08-31T02:04:57Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/1022#issuecomment-1232363746","viewerDidAuthor":true},{"id":"IC_kwDOC4j8g85JdHNe","author":{"login":"latipun7"},"authorAssociation":"NONE","body":"Hi @dandavison, thank you for your attention. \r\n\r\nEven if we don't delete the completion in this repo, there's no harm/difference. The completion is just won't load, it's just same as no completion file at all.\r\n\r\nI'd like to help, but sadly I didn't know how to write zsh completion either, and didn't know rust yet. But, I guess if you can look here for reference: https://github.com/Schniz/fnm/blob/master/src/commands/completions.rs\r\n\r\n`fnm` has completions command, if I run `fnm completions --shell=zsh`, it would print the correct completion in stdout.\r\nCan be redirected manually to zsh completion file path by user. For example:\r\n```sh\r\nfnm completions --shell=zsh > /usr/share/zsh/site-functions/_fnm\r\n```\r\nI think it's pretty good if it can be implemented here. Sorry for the trouble.","createdAt":"2022-08-31T02:13:18Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/1022#issuecomment-1232368478","viewerDidAuthor":false},{"id":"IC_kwDOC4j8g85jwyQm","author":{"login":"maverick1872"},"authorAssociation":"NONE","body":"Is this still actively being looked at by anyone?","createdAt":"2023-08-10T18:46:33Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/1022#issuecomment-1673733158","viewerDidAuthor":false},{"id":"IC_kwDOC4j8g85jw2Yr","author":{"login":"dandavison"},"authorAssociation":"OWNER","body":"Hi @maverick1872, not as far as I know. I'd love some help here -- is this something you might be able to help with?","createdAt":"2023-08-10T19:00:27Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/1022#issuecomment-1673750059","viewerDidAuthor":true},{"id":"IC_kwDOC4j8g85jyW4z","author":{"login":"maverick1872"},"authorAssociation":"NONE","body":"@dandavison totally new to zsh completions but it's an excuse for me to toy with it. I'll see what I can come up with. My primary focus would just be solving #1167. Then completion of options would be the next focus if I can get target file completions working.","createdAt":"2023-08-11T02:30:54Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[{"content":"HEART","users":{"totalCount":2}}],"url":"https://github.com/dandavison/delta/issues/1022#issuecomment-1674145331","viewerDidAuthor":false},{"id":"IC_kwDOC4j8g85jybW-","author":{"login":"dandavison"},"authorAssociation":"OWNER","body":"That sounds great!","createdAt":"2023-08-11T03:14:15Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/1022#issuecomment-1674163646","viewerDidAuthor":true},{"id":"IC_kwDOC4j8g85sUav_","author":{"login":"maverick1872"},"authorAssociation":"NONE","body":"Dropped a completion file that seems to be working for myself with basic option completions included over in #1167. That being said long term something along the lines of #1561 might be the more appropriate choice.","createdAt":"2023-11-18T00:43:02Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/1022#issuecomment-1817291775","viewerDidAuthor":false},{"id":"IC_kwDOC4j8g85sVUtX","author":{"login":"dandavison"},"authorAssociation":"OWNER","body":"Thanks @maverick1872, yes I agree the automatic completion generation in https://github.com/dandavison/delta/pull/1561 seems like the right path forwards. This issue will close when that merges.","createdAt":"2023-11-18T14:52:19Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[{"content":"THUMBS_UP","users":{"totalCount":1}}],"url":"https://github.com/dandavison/delta/issues/1022#issuecomment-1817529175","viewerDidAuthor":true}],"number":1022,"title":"🐛 delta zsh completion was overrided by zsh builtin completion"},{"body":"Delta likes to output clear-to-eol character sequences at the end of each line in an attempt to color the trailing characters (which my chromeos terminal apparently ignores). This can cause a bug where the final character on a line of a wide diff line is lost when the terminal has the xterm/vt100 style of line wrapping (indicated by the `xn` termcap flag).\r\n\r\nTo be more explicit, if a line being diffed is exactly long enough to fill the terminal width, the final char on the line leaves the cursor at the end of the line (pending either more characters, which wrap, or some kind of line movement). Unfortunately, a clear-to-EOL escape sequence then turns the final character on the line into a space, losing information. For example, my terminal is 128-chars wide, and the following diff loses the trailing \"8\" from each long line (I use the `--keep-plus-minus-markers` setting):\r\n\r\n[width128-diff.txt](https://github.com/dandavison/delta/files/8312076/width128-diff.txt)\r\n\r\nA proper fix would probably require delta to compute the current column position each time it is going to clear-to-eol and skip it when a termcap-xn terminal is in the nebulous state of being 1-past the column width but actually in the final column.\r\n\r\nOn a related note, I enabled `--keep-plus-minus-markers` because delta would not show me when an empty line was added or removed. I can now surmise that this is because my terminal doesn't color the empty lines via the clear-to-eol idiom, as that would apparently give them the lightest red/green background color. So, we should probably also have an option to make delta output spaces instead of a clear sequence when ending an green or a red line (I tried tabs, but while they can color the screen with fewer characters, my terminal is apparently confused by the 256-color ansi sequences, which makes the use of tabs later on the line color to inconsistent column positions). If this were fixed, I would give the non-plus/minus output mode another try.","comments":[{"id":"IC_kwDOC4j8g84_-fgx","author":{"login":"WayneD"},"authorAssociation":"CONTRIBUTOR","body":"Actually, I just noticed that it is GNU screen that is the primary failure point in most of these issues -- my terminal is much better at getting them right (it even avoids the loss of the last character on the line when a clear-to-eol occurs in that nebulous xn wrap mode). They both get tab positions wrong after complex color escape sequences, though. I guess I should also look into some screen fixes. Or maybe just switch to tmux -- it also does a much better job.","createdAt":"2022-03-20T20:53:41Z","includesCreatedEdit":true,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/1021#issuecomment-1073346609","viewerDidAuthor":false},{"id":"IC_kwDOC4j8g84_-jMn","author":{"login":"th1000s"},"authorAssociation":"COLLABORATOR","body":"For side-by-side mode there already is `--line-fill-method=spaces` (or `ansi`), but since delta does not take the terminal width into account in unified mode it can't know the number of spaces, thus the ANSI sequence. This is also nice when resizing the terminal. As for terminal multiplexers, there is also [Zellij](https://github.com/zellij-org/zellij).","createdAt":"2022-03-20T22:29:52Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/1021#issuecomment-1073361703","viewerDidAuthor":false}],"number":1021,"title":"🐛Clear to EOL, the loss of the last character, & empty-line highlighting"},{"body":"`delta` eats first character of absolute file paths, thereby making them look like relative paths.\r\n\r\n### Repro Steps\r\n\r\n1. `seq 1 >fileA`\r\n2. `seq 2 >/tmp/fileB`\r\n3. Invoke `delta` as follows:\r\n\r\n```\r\n$ delta fileA /tmp/fileB\r\n\r\nfileA ⟶ tmp/fileB\r\n─────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────\r\n\r\n───┐\r\n1: │\r\n───┘\r\n1\r\n2\r\n```\r\n\r\n### Observed Behavior\r\n\r\nObserve the following within the header:\r\n\r\n```\r\nfileA ⟶ tmp/fileB\r\n```\r\n\r\nNotice that the leading `/` is missing.\r\n\r\n### Expected Behavior\r\n\r\n```\r\nfileA ⟶ /tmp/fileB\r\n```\r\n\r\n```\r\n$ delta --version\r\ndelta 0.12.1\r\n```\r\n","comments":[{"id":"IC_kwDOC4j8g84_ubzR","author":{"login":"dandavison"},"authorAssociation":"OWNER","body":"Hi @salmankhilji, thanks again! I hadn't noticed that. And that's a bit unfortunate: `delta a b` uses `git diff` under the hood, but `git diff` produces identical output on the relative and absolute paths:\r\n\r\n```\r\n$ git -P diff --no-index /tmp/a /tmp/b\r\ndiff --git a/tmp/a b/tmp/b\r\nindex 7898192..6178079 100644\r\n--- a/tmp/a\r\n+++ b/tmp/b\r\n@@ -1 +1 @@\r\n-a\r\n+b\r\n```\r\n\r\n```\r\n$ delta <(git -P diff --no-index tmp/a tmp/b) <(git -P diff --no-index /tmp/a /tmp/b); echo $?\r\n0\r\n```\r\n\r\nI was hoping that the solution might be `git diff --no-prefix` but in fact, it seems to be git that is stripping the leading `/`:\r\n\r\n```\r\n$ git -P diff --no-prefix --no-index /tmp/a /tmp/b\r\ndiff --git tmp/a tmp/b\r\nindex 7898192..6178079 100644\r\n--- tmp/a\r\n+++ tmp/b\r\n@@ -1 +1 @@\r\n-a\r\n+b\r\n```\r\n\r\nAny ideas how we should solve this? (Maybe delta will have to \"fix\" git's output, since delta knows the original paths?)","createdAt":"2022-03-16T13:35:22Z","includesCreatedEdit":true,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/1014#issuecomment-1069137105","viewerDidAuthor":true},{"id":"IC_kwDOC4j8g84_ufP6","author":{"login":"dandavison"},"authorAssociation":"OWNER","body":"Here's a quick attempt at fixing it: https://github.com/dandavison/delta/pull/1016","createdAt":"2022-03-16T13:48:42Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/1014#issuecomment-1069151226","viewerDidAuthor":true},{"id":"IC_kwDOC4j8g84_xCxz","author":{"login":"salmankhilji"},"authorAssociation":"NONE","body":"> Any ideas how we should solve this? (Maybe delta will have to \"fix\" git's output, since delta knows the original paths?)\r\n\r\nNot knowing Rust, I can not comment on the proposed changes to address this issue. At a high-level, it appears that yes, patching git's output would be the way to do. We, however, have to be careful as not to break pipe mode where `delta` may have been invoked without filenames, reading its input from stdin.\r\n\r\nBTW, this is _not_ a must fix IMHO. If its risky to fix, you may also choose to leave it as-is. At least `delta` is being consistent with `git`, which is much more widely used .","createdAt":"2022-03-17T01:42:57Z","includesCreatedEdit":true,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/1014#issuecomment-1069821043","viewerDidAuthor":false}],"number":1014,"title":"delta eats first character of absolute file path🐛 "},{"body":"Raw output: `git --no-pager diff`:\r\n\r\n``` diff\r\n DEPENDS flatc\r\n- COMMENT \"Generating header from schema IDL\"\r\n+ COMMENT \"Generating savedata_generated.h from IDL savedata.fbs\"\r\n VERBATIM)\r\n```\r\n\r\nOutput with Delta as pager\r\n\r\n```\r\n│ 31 │ DEPENDS flatc │ 42 │ DEPENDS flatc\r\n│ 32 │ COMMENT \"Generating header fro↵ │ │\r\n│ │m schema IDL\" │ │\r\n│ │ │ 43 │ COMMENT \"Generating savedata_g↵\r\n│ │ │ │enerated.h from IDL savedata.fbs\"\r\n│ 33 │ VERBATIM) │ 44 │ VERBATIM)\r\n```\r\n\r\n\r\n\r\nBoth `$COLUMNS` and `tput cols` give the same _correct_ width. `man less` renders by filling contents to the entire width of the terminal window.\r\n\r\nRelevant snip from `.gitconfig`:\r\n\r\n```\r\n[core]\r\n\tpager = delta\r\n[interactive]\r\n\tdiffFilter = delta --color-only\r\n[delta]\r\n\tfeatures = side-by-side line-numbers decorations\r\n\twhitespace-error-style = 22 reverse\r\n\tsyntax-theme = 1337\r\n\tnavigate = true\r\n[delta \"decorations\"]\r\n\tcommit-decoration-style = brightgreen box ul\r\n\tfile-style = bold yellow ul\r\n\tfile-decoration-style = none\r\n```\r\n\r\nRelevant snip from `.profile`\r\n\r\n```\r\nexport LESS=\"$LESS --ignore-case --RAW-CONTROL-CHARS\"\r\nexport DELTA_PAGER=\"$PAGER $LESS --quit-if-one-screen\"\r\n```\r\n\r\n# Versions\r\n\r\nGit: 2.35.1 (part of MSYS2 installation)\r\nDelta: 0.12.1\r\nWindows 10\r\n\r\nSame behaviour on both mintty and ConEmu.","comments":[{"id":"IC_kwDOC4j8g85AHlel","author":{"login":"th1000s"},"authorAssociation":"COLLABORATOR","body":"This might be caused by [this terminal-size bug](https://github.com/eminence/terminal-size/issues/25) which in turn is used by `console`. The mentioned git bash shell is [MinGW-w64 / build under MSYS2](https://github.com/git-for-windows/MINGW-packages).\r\n\r\nGiven that `$COLUMNS` is correct and delta does not react to terminal resizing, a workaround should be possible. To that end, what is the output of `cargo run` inside an MSYS2 terminal after creating a project with `cargo init width_check` and setting the content of the files as follows?\r\n\r\n<details><summary>Cargo.toml</summary>\r\n\r\n```toml\r\n[package]\r\nname = \"width_check\"\r\nversion = \"0.0.1\"\r\nedition = \"2021\"\r\n\r\n[dependencies]\r\nconsole = \"0.15.0\"\r\n ```\r\n</details>\r\n\r\nand \r\n\r\n<details><summary>src/main.rs</summary>\r\n\r\n```rust\r\nuse console::Term;\r\n\r\nfn main() {\r\n let term_stdout = Term::stdout();\r\n dbg!(term_stdout.is_term());\r\n dbg!(term_stdout.size());\r\n}\r\n ```\r\n</details>","createdAt":"2022-03-22T22:55:42Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/1011#issuecomment-1075730341","viewerDidAuthor":false},{"id":"IC_kwDOC4j8g85AfTHh","author":{"login":"legends2k"},"authorAssociation":"NONE","body":"> what is the output of `cargo run`\r\n\r\n```\r\n> cargo run\r\n[src\\main.rs:5] term_stdout.is_term() = true\r\n[src\\main.rs:6] term_stdout.size() = (\r\n 24,\r\n 79,\r\n)\r\n\r\n> echo $COLUMNS\r\n186\r\n\r\n> tput cols\r\n186\r\n```\r\n\r\nSo looks like it's a bug in `console`?","createdAt":"2022-03-29T14:31:23Z","includesCreatedEdit":true,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/1011#issuecomment-1081946593","viewerDidAuthor":false},{"id":"IC_kwDOC4j8g85Arfh8","author":{"login":"th1000s"},"authorAssociation":"COLLABORATOR","body":"Yes, both `console` via `terminal-size` and `crossterm` seem to ultimately use `GetConsoleScreenBufferInfo()` on Windows which returns the fallback-value `(24, 79)` under MSYS2.\r\n\r\nCan you try #1030 which calls `stty` (this seems to be available on MSYS2 and hopefully work better). The top commit contains a lot of debug output in case this does not work - but if it does you can revert it. Even with `--release` it might be a bit slower though since it will call the `stty` binary on startup.","createdAt":"2022-03-31T21:34:09Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[{"content":"THUMBS_UP","users":{"totalCount":1}}],"url":"https://github.com/dandavison/delta/issues/1011#issuecomment-1085143164","viewerDidAuthor":false},{"id":"IC_kwDOC4j8g85OrE0l","author":{"login":"koprivajakub"},"authorAssociation":"NONE","body":"Is there any update on this, I can see @th1000s you mention the #1030 that should fix it but there is no release after this point. The tool is pretty much useless without the full width.","createdAt":"2022-11-18T12:08:38Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/1011#issuecomment-1319914789","viewerDidAuthor":false},{"id":"IC_kwDOC4j8g85Po_5F","author":{"login":"Ceron257"},"authorAssociation":"NONE","body":"One thing I observed with git for windows: This issue is present when using git bash with mintty (the default). The `width_check` example always returns the fallback-value. \r\n\r\nWhen I use git bash with windows terminal the issue is **not** present👍🏼. And the `width_check` example also shows the correct values.\r\n\r\nHopefully this helps out anyone until we got a release with the fix.\r\n\r\nSmall addendum: With the following registration entry one can open git bash in windows terminal in the current window via the context menu in the explorer, provided there is a windows terminal profile called \"Git Bash\":\r\n```\r\nWindows Registry Editor Version 5.00\r\n\r\n[HKEY_CLASSES_ROOT\\Directory\\Background\\shell\\git_shell\\command]\r\n@=\"wt -w 0 nt -p \\\"Git Bash\\\"\"\r\n```\r\n","createdAt":"2022-12-03T12:13:46Z","includesCreatedEdit":true,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/1011#issuecomment-1336147525","viewerDidAuthor":false},{"id":"IC_kwDOC4j8g85PpGUd","author":{"login":"dandavison"},"authorAssociation":"OWNER","body":"> The tool is pretty much useless without the full width.\r\n\r\n@koprivajakub I'm sorry, I had absolutely no idea that delta was in an unusable state for any user! I had been thinking that width problems could always be overridden by command line options and/or env vars. In any case, I'll make a release today.","createdAt":"2022-12-03T14:42:40Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[{"content":"THUMBS_UP","users":{"totalCount":3}}],"url":"https://github.com/dandavison/delta/issues/1011#issuecomment-1336173853","viewerDidAuthor":true}],"number":1011,"title":"Column width incorrectly deduced on Windows (MSYS2)🐛 "},{"body":"Delta is the best terminal diff viewer I ever used. Now it would be great, if I could use it as merge tool. I know that is a huge request and I completely understand when it gets declined.\r\n","comments":[{"id":"IC_kwDOC4j8g84_jaXj","author":{"login":"dandavison"},"authorAssociation":"OWNER","body":"Hi @zbindenren, thank you. I've never actually used a merge tool, so am not clear exactly what this would involve. Do feel free to add some notes or links. I assume it would involve creating an application based on delta that has much more \"interactivity\" (keybindings, UI widgets etc), whether terminal-based or desktop or web app.\r\n\r\nI know that some of the terminal git UIs such as lazygit can be used with delta: https://github.com/jesseduffield/lazygit/blob/master/docs/Custom_Pagers.md#delta\r\n\r\nIs this anything like the functionality that a merge tool provides? https://github.com/jesseduffield/lazygit#resolving-merge-conflicts","createdAt":"2022-03-14T01:31:43Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/1005#issuecomment-1066247651","viewerDidAuthor":true},{"id":"IC_kwDOC4j8g85gRjx4","author":{"login":"dbelenko"},"authorAssociation":"NONE","body":"I think the idea here is to enable a three-pane mode, where you can display 2 different diffs simultaneously when resolving merge conflicts:\r\n\r\n 1. Diff wrt the origin revision in the local repo\r\n 2. Diff wrt the origin revision in remote repo\r\n \r\nAnd allow the user to selectively merge changes from both. These diffs are what you see if there's an unsuccessful merge when you do `git pull` and local changes conflict with remote ones, except there they are all in the same file. IOW this is basically a different visualization of that file, with the ability to choose what to keep and what to discard. \r\n\r\nA good example of such a merge program would be Meld or Beyond Compare. I'm not aware of any console programs that can do this conveniently. There's vimdiff, but its user experience leaves much to be desired.\r\n\r\nSuch a change would also need to add a modicum of text editing ability, however, in order to be truly useful.","createdAt":"2023-06-30T21:34:58Z","includesCreatedEdit":true,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/1005#issuecomment-1615215736","viewerDidAuthor":false},{"id":"IC_kwDOC4j8g85gRmL5","author":{"login":"dandavison"},"authorAssociation":"OWNER","body":"There are TUI git clients -- e.g. lazygit -- which can use delta. Can any of them act as merge tools? ","createdAt":"2023-06-30T21:51:12Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/1005#issuecomment-1615225593","viewerDidAuthor":true},{"id":"IC_kwDOC4j8g85gRoR3","author":{"login":"dbelenko"},"authorAssociation":"NONE","body":"As far as I can tell none of them supports side-by-side three pane diff, which means they basically have no advantage over editing the file with merge conflicts manually. My interest in this feature is that I often work remotely nowadays, and currently I have to use Meld, running remotely on my workstation at work (our laptops are not set up for direct dev work), which requires a fast connection. I think a huge number of people out there have the same needs - ability to have X-less remote workflow over SSH.\r\n\r\nThat said, I concur with the OP - this is probably far more work than one would call reasonable for a feature request.","createdAt":"2023-06-30T22:07:12Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/1005#issuecomment-1615234167","viewerDidAuthor":false},{"id":"IC_kwDOC4j8g85q16Uo","author":{"login":"dessalines"},"authorAssociation":"NONE","body":"Is vimdiff the only decent option for a command line mergetool? I'd really like to have something like meld, but for the command line.","createdAt":"2023-11-03T14:16:34Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[{"content":"THUMBS_UP","users":{"totalCount":2}}],"url":"https://github.com/dandavison/delta/issues/1005#issuecomment-1792517416","viewerDidAuthor":false}],"number":1005,"title":"Extend as interactive mergetool🚀 "},{"body":"Hi there!\r\n\r\nSo I was messing around with the config and noticed that if I do the following: \r\n\r\n```\r\nline-numbers-right-format = \"│{nm:^4}-{np:^4}│ \"\r\nline-numbers-left-format = \" \"\r\n```\r\nThis happens:\r\n\r\n\r\nBasically, the right column starts at the center but due to there being no left column it seems to be skewed right.\r\n\r\nMight be more easy to see here:\r\n\r\n\r\nMaybe there could be a sort of \"center-only\" config that properly centers the \"right\" column and discards the left one :thinking: \r\n\r\nOr is that something I should be able to achieve on my end?","comments":[{"id":"IC_kwDOC4j8g84_-i9t","author":{"login":"th1000s"},"authorAssociation":"COLLABORATOR","body":"Delta divides the terminal into two panels and only then starts drawing. The width of these panels is currently always identical, this would have to become user configurable at [side_by_side.rs:55](/dandavison/delta/blob/dd19c974baadae1a1/src/features/side_by_side.rs#L55).","createdAt":"2022-03-20T22:23:21Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[{"content":"THUMBS_UP","users":{"totalCount":1}}],"url":"https://github.com/dandavison/delta/issues/998#issuecomment-1073360749","viewerDidAuthor":false},{"id":"IC_kwDOC4j8g85EBekt","author":{"login":"ObiWahn"},"authorAssociation":"NONE","body":"It would be nice if the max line length of both sides could be checked first. And then use that to decide on the column widths in side-by-side mode. Probably this introduces too much buffering to be feasible, but it would often beneficial to me to have the columns closer together. Especially if there are few changes, on short lines, while using high resolution. A bit `CTRL-+/-` does not kill me, but it would be nice to have an option and to decide to just take the performance hit.","createdAt":"2022-05-30T14:43:58Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/998#issuecomment-1141238061","viewerDidAuthor":false}],"number":998,"title":":rocket: Center Column"},{"body":"Hey! This relates to #515. It would be great as a minor improvement, perhaps behind a flag to do word wrapping rather than character wrapping on the side to side view.\r\nExample:\r\n\r\n\r\nI think word wrapping uses \" \" character normally, not sure how it handles different languages","comments":[{"id":"IC_kwDOC4j8g84-604S","author":{"login":"dandavison"},"authorAssociation":"OWNER","body":"Hi @ayroblu, thanks! I agree, this would be great to have. cc @th1000s -- I think you've already thought about this. Do you have a sense for how hard it's going to be?","createdAt":"2022-03-01T16:12:08Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/992#issuecomment-1055608338","viewerDidAuthor":true},{"id":"IC_kwDOC4j8g84_YyaY","author":{"login":"th1000s"},"authorAssociation":"COLLABORATOR","body":"I agree, that is still sorely missing from the wrapping logic.\r\n\r\nAnd this could do a bit more than finding the first transition towards a space (`\\w` in a regex, probably via `UnicodeSegmentation::split_word_bounds`). Plus there must be some limit on the amount of characters which will be moved to the next line.\r\n\r\nWhen the break is in a non-word region it sometimes makes sense to walk backwards beyond the previous word, and maybe beyond. A few examples and alternatives I could think of, where `|` is the end of the line and `¦` the improved wrap position:\r\n\r\n```shell\r\nfoo ¦ba|r\r\nfoo¦ ba|r\r\n\r\nsome foo:¦|:bar\r\nsome foo¦:|:bar\r\n\r\nsome foo::¦|bar\r\nsome foo:¦:|bar\r\nsome ¦foo::|bar\r\n\r\nknsh14/vim-¦g|ithub\r\nknsh14/¦vim-g|ithub\r\n\r\nbar<this<that>¦|>()\r\nbar<this<that¦>|>()\r\n\r\nbar<this<¦th|at>()\r\nbar<this¦<th|at>()\r\nbar¦<this<th|at>()\r\n\r\n\"some string\"¦)|)\r\n\r\n\"some quoted ¦text|\"\r\n\r\nsome \"ab ¦b|c\" text\r\nsome ¦\"ab b|c\" text\r\n\r\nfoo::bar::baz(¦|)\r\nfoo::bar::baz¦(|)\r\nfoo::bar:¦:baz(|)\r\n\r\nsome( foo::¦b|ar )\r\nsome( ¦foo::b|ar )\r\n\r\ntoo_long_to_be_wra¦|pped\r\ntoo_long_to_be_¦wra|pped\r\n\r\ndoThisAndThatAfterSometh¦|ing\r\ndoThisAndThatAfter¦Someth|ing\r\n\r\nfn foo() -¦|> usize {\r\nfn foo() ¦-|> usize {\r\n\r\n------<-[+¦|]->\r\n------¦<-[+|]->\r\n\r\n```\r\n\r\nHow should the remaining room on the line be filled? Just spaces can't be used, so a placeholder is required (here: `·`), or the wrap character should move to the end of the line, and if so, follow up with spaces or placeholders?\r\n\r\n```shell\r\nthis was···↴|\r\n …wrapped!|\r\n``` \r\n\r\n\r\n```shell\r\nthis was↴ |\r\n …wrapped!|\r\n``` \r\n\r\n```shell\r\nthis was↴···|\r\n …wrapped!|\r\n``` \r\n\r\nI currently prefer the first option to reduce visual noise. And someone once said \"perfect is the enemy of good \" - but still... :)\r\n\r\nCC @StaticPH @disrupted @pwm @ri-aje @zifeo @jupblb @chalkygames123 @Notgnoshi @serban","createdAt":"2022-03-09T22:56:08Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/992#issuecomment-1063462552","viewerDidAuthor":false},{"id":"IC_kwDOC4j8g84_Y0fd","author":{"login":"dandavison"},"authorAssociation":"OWNER","body":"I agree that the first option looks nice. Just to make sure I understand, the reason you say \"just spaces can't be used\" is that we want to distinguish user content from artificial injected content, right?\r\n\r\nIs another option to use `…` multiple times?\r\n\r\n```shell\r\nthis was………↴|\r\n …wrapped!|\r\n```","createdAt":"2022-03-09T23:10:16Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/992#issuecomment-1063471069","viewerDidAuthor":true},{"id":"IC_kwDOC4j8g84_Y2lU","author":{"login":"th1000s"},"authorAssociation":"COLLABORATOR","body":"Yes, visually it should be clear what delta inserted and what the content itself is. ↴ … · etc. are colored differently from the code (unless the syntax highlighting does something unlucky), but spaces can't really be colored.\r\n\r\nI first tried `…` as well, but found it visually too \"heavy\", especially if repeated. But this will be configurable.","createdAt":"2022-03-09T23:23:50Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/992#issuecomment-1063479636","viewerDidAuthor":false},{"id":"IC_kwDOC4j8g84_bVBN","author":{"login":"dandavison"},"authorAssociation":"OWNER","body":"```shell\r\nthis wasXXX↴|\r\n Ywrapped!|\r\n```\r\n\r\nIt does seem like the semantics of `X` are very close to those of `Y`, which would be an argument for them using the same symbol.\r\n\r\n","createdAt":"2022-03-10T14:34:27Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/992#issuecomment-1064128589","viewerDidAuthor":true},{"id":"IC_kwDOC4j8g84_cT0P","author":{"login":"ayroblu"},"authorAssociation":"NONE","body":"fwiw, imo, I think we should break on spaces and not just non word characters, I don't think that if a word has a symbol, I don't want to break it in two in many cases.\r\nAs an alternative, more complicated example, using what the browser defaults to: https://www.w3.org/TR/css-text-3/#soft-wrap-opportunity\r\nBut that's pretty complicated I think, and I'm not sure on specifics","createdAt":"2022-03-10T18:52:50Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/992#issuecomment-1064385807","viewerDidAuthor":false},{"id":"IC_kwDOC4j8g84_iATs","author":{"login":"dandavison"},"authorAssociation":"OWNER","body":"Possibly useful? https://docs.rs/unicode-linebreak/latest/unicode_linebreak/","createdAt":"2022-03-12T12:55:44Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/992#issuecomment-1065878764","viewerDidAuthor":true},{"id":"IC_kwDOC4j8g84_rqdJ","author":{"login":"StaticPH"},"authorAssociation":"NONE","body":"> ```shell\r\n> this was···↴|\r\n> …wrapped!|\r\n> ```\r\n> ```shell\r\n> this was↴ |\r\n> …wrapped!|\r\n> ```\r\nWhile I believe the former will likely be preferred by most users, I'd personally be just as satisfied by either of these two.\r\n\r\n> Yes, visually it should be clear what delta inserted and what the content itself is. ↴ … · etc. are colored differently from the code (unless the syntax highlighting does something unlucky), **but spaces can't really be colored.** \r\n\r\nAre whitespace characters not already being colored within differing blocks? If there's already a way to indicate the addition or removal of a segment which _happens_ to begin/end in horizontal whitespace, I would imagine that the code for such behavior could be reused or modified to highlight (or otherwise style/format, perhaps with an underline?) everything between the position at which wrapping occurs and the wrapping marker \"↴\". The same could also be applied to any characters `delta` inserts at the start of the following screen-line, either in addition to or in place of any ellipses. Alternatively, spaces on either side of a wrap point **NOT** inserted as padding by `delta` could be made distinct.\r\n\r\n> I first tried `…` as well, but found it visually too \"heavy\", especially if repeated. But this will be configurable.\r\n\r\nIndeed, I find that several adjacent ellipses characters can quickly become visually noisy.\r\n`………` (x3)\r\n`………………` (x6)\r\n\r\n> fwiw, imo, I think we should break on spaces and not just non word characters, I don't think that if a word has a symbol, I don't want to break it in two in many cases. As an alternative, more complicated example, using what the browser defaults to: https://www.w3.org/TR/css-text-3/#soft-wrap-opportunity But that's pretty complicated I think, and I'm not sure on specifics\r\n\r\nI definitely think that the ideal scenario would be to break immediately before or after visible whitespace characters. At the very least, linebreaks (along with any inserted padding) for wrapping should occur immediately adjacent to non-alphanumeric symbols when possible. I suspect that \"after\" placement is probably the better position in most scenarios.","createdAt":"2022-03-15T19:58:16Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/992#issuecomment-1068410697","viewerDidAuthor":false},{"id":"IC_kwDOC4j8g85lmBl-","author":{"login":"Destroy666x"},"authorAssociation":"NONE","body":"Yes please. A mode where regular words are not split in the middle and long words are split in the middle would be perfect.","createdAt":"2023-09-04T01:03:02Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/992#issuecomment-1704466814","viewerDidAuthor":false},{"id":"IC_kwDOC4j8g86H8IE2","author":{"login":"jasonmcewen"},"authorAssociation":"NONE","body":"Any further thoughts or update on this? It would be super useful for diff'ing latex documents, which often have long lines of natural text.","createdAt":"2024-08-10T09:47:48Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[{"content":"EYES","users":{"totalCount":1}}],"url":"https://github.com/dandavison/delta/issues/992#issuecomment-2280685878","viewerDidAuthor":false}],"number":992,"title":"Word wrap for side by side by word rather than by character"},{"body":"- [x] Please include the raw text output from git, so that we can reproduce the problem.\r\n (You can use `git --no-pager` to produce the raw text output.)\r\n- [x] A screenshot of Delta's output is often helpful also.\r\n\r\n```\r\n❯ git --no-pager diff 'HEAD~1' 'HEAD'\r\ndiff --git a/b b/b\r\nnew file mode 100644\r\nindex 0000000..e69de29\r\n```\r\n\r\n<img width=\"961\" alt=\"image\" src=\"https://user-images.githubusercontent.com/36224762/154493486-cb98ac4c-b66b-401b-bed8-d3a522622f71.png\">\r\n","comments":[{"id":"IC_kwDOC4j8g84-KnP0","author":{"login":"dandavison"},"authorAssociation":"OWNER","body":"Thanks for this @NightMachinary.","createdAt":"2022-02-17T13:50:19Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[{"content":"LAUGH","users":{"totalCount":1}}],"url":"https://github.com/dandavison/delta/issues/971#issuecomment-1042969588","viewerDidAuthor":true}],"number":971,"title":"🐛 Added empty files are not shown"},{"body":"Currently, the color of `hunk-label` respects `hunk-header-file-style`, which defaults to blue. This produces a consistent coloring when the filename is included in the hunk headers, via the special \"file\" keyword: \r\n\r\n```toml\r\n[delta]\r\n\t# ...\r\n\thunk-header-style = \"file line-number syntax\"\r\n\thunk-label = \"Foobar\"\r\n\thunk-header-line-number-style = \"red\"\r\n```\r\n\r\n\r\n\r\nBut if I don't include \"file\" in `hunk-header-style`, I would like to set the hunk label to match the color of the remainder of the hunk header (in this case, the line number). I assumed there would be a `hunk-label-style` config to do so, but that doesn't seem to be the case:\r\n\r\n```toml\r\n[delta]\r\n\t# ...\r\n\thunk-header-style = \"line-number syntax\"\r\n\thunk-label = \"Foobar\"\r\n\thunk-label-style = \"red\"\r\n\thunk-header-line-number-style = \"red\"\r\n```\r\n\r\n\r\n\r\nI can work around this by setting `hunk-header-file-style`:\r\n\r\n```toml\r\n[delta]\r\n\t# ...\r\n\thunk-header-style = \"line-number syntax\"\r\n\thunk-label = \"Foobar\"\r\n\thunk-header-line-number-style = \"red\"\r\n\thunk-header-file-style = \"red\"\r\n```\r\n\r\n\r\n\r\n...but that's awkward because I'm not using \"file\" in the hunk header at all.\r\n\r\nIdeally, there should be a dedicated `hunk-label-style` for styling the hunk prefix in the hunk headers.\r\n\r\n(By the way, why is this config called `hunk-label` instead of `hunk-header-label`? That would be more consistent with the other configurations. And if the name were that, then the associated style config would be `hunk-header-label-style`.)\r\n","comments":[],"number":968,"title":"🚀 Add support for `hunk-label-style`"},{"body":"Delta 0.11.3. File [`a.lua`](http://0x0.st/o8PC.lua), [`b.lua`](http://0x0.st/o8Zr.lua). See, first part is missing:\r\n\r\n<img width=\"334\" alt=\"1\" src=\"https://user-images.githubusercontent.com/39882583/153941281-c5d5161b-04cc-4abc-b223-969124107805.png\">\r\n\r\nUPD: `diff` is alias for `diff --color -Naurp0`.","comments":[{"id":"IC_kwDOC4j8g8499ua9","author":{"login":"dandavison"},"authorAssociation":"OWNER","body":"Thanks for the report and the test files @k4leg -- I see the same bug as you.\r\n\r\nIncidentally, using `delta a.lua b.lua` does work on your files (under the hood this uses `git diff --no-index` instead of `diff -u`). But that doesn't change the fact that this is a bug with delta's handling of `diff -u`.","createdAt":"2022-02-14T21:37:13Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/962#issuecomment-1039591101","viewerDidAuthor":true},{"id":"IC_kwDOC4j8g84_PSmp","author":{"login":"WayneD"},"authorAssociation":"CONTRIBUTOR","body":"I assume it works with the git diff command because delta is requesting color? (Since that would prefix the \"---\" line by a color escape sequence.)\r\n\r\nSo, it looks like delta needs to start to interpret the counts on the \"@@\" lines so that it can ignore a \"--- \" prefix if it is in the middle of a hunk. One possibility is to stash off the @@ line and only interpret it if you run into a \"--- \" line before seeing a \"diff \" line (at which point the code would do some quick length calculations and see if it is in the hunk or not).\r\n\r\nThis is one of my big regrets looking back at when I invented unified diffs: I should have made the filename headers \"@- file\" and \"@+ file\" so that there could no confusion possible between a header line and a change line. Oh well.","createdAt":"2022-03-07T18:03:57Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[{"content":"HEART","users":{"totalCount":1}}],"url":"https://github.com/dandavison/delta/issues/962#issuecomment-1060972969","viewerDidAuthor":false}],"number":962,"title":"Incomplete diff.🐛 "},{"body":"\r\n\r\n```\r\n <key>colorSpaceName</key>ESC[m\r\n <string>sRGB</string>ESC[m\r\n <key>comment</key>ESC[m\r\nESC[31m- <string>Generated from the ansi16 template</string>ESC[m\r\nESC[32m+ESC[m ESC[32m<string>Generated from the ansi16 template at https://github.com/chtenb/ansi16</string>ESC[m\r\n <key>name</key>ESC[m\r\nESC[31m- <string>ANSI 16 Terminal</string>ESC[m\r\nESC[32m+ESC[m ESC[32m<string>Ansi 16 Terminal</string>ESC[m\r\n <key>semanticClass</key>ESC[m\r\n <string>theme.ansi16</string>ESC[m\r\n <key>settings</key>ESC[m\r\nESC[36m@@ -38,53 +38,42 @@ESC[m\r\n </dict>ESC[m\r\n <dict>ESC[m\r\n <key>name</key>ESC[m\r\nESC[1;35m- <string>Inserted</string>ESC[m\r\nESC[31m- <key>scope</key>ESC[m\r\nESC[1;35m- <string>markup.inserted</string>ESC[m\r\nESC[1;34m- <key>settings</key>ESC[m\r\nESC[1;34m- <dict>ESC[m\r\nESC[1;34m- <key>foreground</key>ESC[m\r\nESC[1;35m- <string>#02000000</string>ESC[m\r\nESC[1;34m- </dict>ESC[m\r\nESC[1;34m- </dict>ESC[m\r\nESC[1;34m- <dict>ESC[m\r\nESC[1;34m- <key>name</key>ESC[m\r\nESC[31m- <string>Deleted</string>ESC[m\r\nESC[32m+ESC[m ESC[32m<string>URL</string>ESC[m\r\n <key>scope</key>ESC[m\r\nESC[1;35m- <string>markup.deleted</string>ESC[m\r\nESC[1;33m+ESC[m ESC[1;33m<string>*url*, *link*, *uri*</string>ESC[m\r\n <key>settings</key>ESC[m\r\n <dict>ESC[m\r\nESC[31m- <key>foreground</key>ESC[m\r\nESC[1;35m- <string>#01000000</string>ESC[m\r\nESC[1;33m+ESC[m ESC[1;33m<key>fontStyle</key>ESC[m\r\nESC[1;33m+ESC[m ESC[1;33m<string>underline</string>ESC[m\r\n </dict>ESC[m\r\n </dict>ESC[m\r\n```\r\n\r\n","comments":[],"number":954,"title":"🐛 moved colors background highlighting does not always start at the beginning of the line"},{"body":"<details>\r\n <summary>My config</summary>\r\n\r\n ```ini\r\n file-style = \"#ffffff\"\r\n file-decoration-style = \"#333333\" ul box\r\n hunk-header-decoration-style = none\r\n hyperlinks = true\r\n line-numbers = true\r\n line-numbers-minus-style = \"#993333\"\r\n line-numbers-zero-style = \"#666666\"\r\n line-numbers-plus-style = \"#336633\"\r\n line-numbers-left-format = \"{nm:>3} ⋮ \"\r\n line-numbers-left-style = \"#333333\"\r\n line-numbers-right-format = \"{np:>3} │ \"\r\n line-numbers-right-style = \"#333333\"\r\n max-line-length = 0\r\n minus-style = syntax \"#330000\"\r\n navigate = true\r\n plus-style = syntax \"#003300\"\r\n minus-emph-style = syntax \"#660000\"\r\n plus-emph-style = syntax \"#006600\"\r\n relative-paths = true\r\n syntax-theme = Dracula\r\n ```\r\n</details>\r\n\r\nI'm wondering if it's possible to have Delta render a diff similar to how GitHub does it.\r\n\r\nFor instance, this is what 37dd3391844efefbfe59acbbf3ad661b497ed9ce looks like on GitHub:\r\n\r\n\r\n\r\nAnd this is how it looks on Delta:\r\n\r\n\r\n\r\nIt's _almost_ there, except for the background color not covering line numbers at left.\r\n\r\nI tried this, but it didn't quite work:\r\n\r\n```ini\r\nline-numbers-minus-style = syntax \"#330000\"\r\nline-numbers-plus-style = syntax \"#336633\"\r\n```\r\n\r\n\r\n\r\nNotice how it paints _columns_ rather than lines. Also, the background covers line numbers but not the padding around them, which looks strange. \r\n\r\nIs this possible? I went through the `-style` options in `delta --help` but didn't find anything I'm not already using. On a final note, being able to control line number foreground/background color independently from the diff context would be the icing on the cake!\r\n\r\nThanks in advance for any help and for this awesome project!\r\n","comments":[{"id":"IC_kwDOC4j8g84_jmEs","author":{"login":"dandavison"},"authorAssociation":"OWNER","body":"Hi @daniel-liuzzi, thanks very much for this and sorry to be slow.\r\n\r\nSo let's take the line number background color issue first. I definitely sympathize with what you're aiming for here. It's slightly complicated: I think there might be a bug involved, and also some limitations of what's possible with current config. \r\n\r\nIn any case, I've made an experimental branch #1009 which makes what you want possible. The config you'd use is this:\r\n\r\n```gitconfig\r\n[delta]\r\n line-numbers-minus-style = minus-emph-style\r\n line-numbers-plus-style = plus-emph-style\r\n line-numbers-left-style = omit\r\n line-numbers-right-style = omit\r\n```\r\n\r\nwhere the special word \"none\" (not available in released delta, just in that branch) is used to indicate that you don't want the `*-left-style` and `*-right-style` to be active at all. If you're ok [building delta from the git repo](https://dandavison.github.io/delta/build-delta-from-source.html) maybe you'd like to try out that branch.\r\n\r\nThere's a section in the `--help` output that tries to explain the different options; you've probably seen it:\r\n\r\n```\r\nLINE NUMBERS\r\n------------\r\n\r\nTo display line numbers, use --line-numbers.\r\n\r\nLine numbers are displayed in two columns. Here's what it looks like by default:\r\n\r\n 1 ⋮ 1 │ unchanged line\r\n 2 ⋮ │ removed line\r\n ⋮ 2 │ added line\r\n\r\nIn that output, the line numbers for the old (minus) version of the file appear in the left column,\r\nand the line numbers for the new (plus) version of the file appear in the right column. In an\r\nunchanged (zero) line, both columns contain a line number.\r\n\r\nThe following options allow the line number display to be customized:\r\n\r\n--line-numbers-left-format: Change the contents of the left column\r\n--line-numbers-right-format: Change the contents of the right column\r\n--line-numbers-left-style: Change the style applied to the left column\r\n--line-numbers-right-style: Change the style applied to the right column\r\n--line-numbers-minus-style: Change the style applied to line numbers in minus lines\r\n--line-numbers-zero-style: Change the style applied to line numbers in unchanged lines\r\n--line-numbers-plus-style: Change the style applied to line numbers in plus lines\r\n\r\nOptions --line-numbers-left-format and --line-numbers-right-format allow you to change the contents\r\nof the line number columns. Their values are arbitrary format strings, which are allowed to contain\r\nthe placeholders {nm} for the line number associated with the old version of the file and {np} for\r\nthe line number associated with the new version of the file. The placeholders support a subset of\r\nthe string formatting syntax documented here: https://doc.rust-lang.org/std/fmt/#formatting-parameters.\r\nSpecifically, you can use the alignment and width syntax.\r\n\r\nFor example, the default value of --line-numbers-left-format is '{nm:^4}⋮'. This means that the\r\nleft column should display the minus line number (nm), center-aligned, padded with spaces to a\r\nwidth of 4 characters, followed by a unicode dividing-line character (⋮).\r\n\r\nSimilarly, the default value of --line-numbers-right-format is '{np:^4}│'. This means that the\r\nright column should display the plus line number (np), center-aligned, padded with spaces to a\r\nwidth of 4 characters, followed by a unicode dividing-line character (│).\r\n\r\nUse '<' for left-align, '^' for center-align, and '>' for right-align.\r\n```","createdAt":"2022-03-14T03:11:58Z","includesCreatedEdit":true,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/949#issuecomment-1066295596","viewerDidAuthor":true},{"id":"IC_kwDOC4j8g84_jmM7","author":{"login":"dandavison"},"authorAssociation":"OWNER","body":"<img width=\"914\" alt=\"image\" src=\"https://user-images.githubusercontent.com/52205/158098504-b0065f10-1ed0-4219-8df8-2e4f03315e48.png\">\r\n","createdAt":"2022-03-14T03:12:51Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/949#issuecomment-1066296123","viewerDidAuthor":true},{"id":"IC_kwDOC4j8g84_mGpB","author":{"login":"dandavison"},"authorAssociation":"OWNER","body":"#1009 needs more work to make it work with `side-by-side` however.","createdAt":"2022-03-14T15:31:53Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/949#issuecomment-1066953281","viewerDidAuthor":true},{"id":"IC_kwDOC4j8g84_nPIw","author":{"login":"daniel-liuzzi"},"authorAssociation":"NONE","body":"Hey @dandavison,\r\n\r\nSo I checked out your branch and tried to build it, but unfortunately I didn't succeed; I ran `cargo build --release` and got an error about half way, something about missing gcc.exe. I solved it by installing gcc.exe from [MinGW Distro](https://nuwen.net/mingw.html), tried again, and it _seemed_ like it was all gonna work, then got a MASSIVE error message right at step 236/237 and got stuck. It must be a Windows thing. Oh well... 😑 (first time in my life I attempt to compile Rust BTW)\r\n\r\n<details>\r\n <summary>Error</summary>\r\n\r\n ```\r\n > cargo build --release\r\n Compiling git-delta v0.12.1 (C:\\Users\\daniel\\code\\misc\\dandavison_delta)\r\n error: linking with `x86_64-w64-mingw32-gcc` failed: exit code: 1\r\n |\r\n = note: \"x86_64-w64-mingw32-gcc\" \"-fno-use-linker-plugin\" \"-Wl,--dynamicbase\" \"-Wl,--disable-auto-image-base\" \"-m64\" \"-Wl,--high-entropy-va\" \"C:\\\\Users\\\\daniel\\\\scoop\\\\apps\\\\rust\\\\1.59.0\\\\lib\\\\rustlib\\\\x86_64-pc-windows-gnu\\\\lib\\\\self-contained\\\\crt2.o\" \"C:\\\\Users\\\\daniel\\\\scoop\\\\apps\\\\rust\\\\1.59.0\\\\lib\\\\rustlib\\\\x86_64-pc-windows-gnu\\\\lib\\\\rsbegin.o\" \"C:\\\\Users\\\\daniel\\\\code\\\\misc\\\\dandavison_delta\\\\target\\\\release\\\\deps\\\\delta-388fd1701dff5f0c.delta.5660f17b-cgu.0.rcgu.o\" \"C:\\\\Users\\\\daniel\\\\code\\\\misc\\\\dandavison_delta\\\\target\\\\release\\\\deps\\\\delta-388fd1701dff5f0c.delta.5660f17b-cgu.1.rcgu.o\" \"C:\\\\Users\\\\daniel\\\\code\\\\misc\\\\dandavison_delta\\\\target\\\\release\\\\deps\\\\delta-388fd1701dff5f0c.delta.5660f17b-cgu.10.rcgu.o\" \"C:\\\\Users\\\\daniel\\\\code\\\\misc\\\\dandavison_delta\\\\target\\\\release\\\\deps\\\\delta-388fd1701dff5f0c.delta.5660f17b-cgu.11.rcgu.o\" \"C:\\\\Users\\\\daniel\\\\code\\\\misc\\\\dandavison_delta\\\\target\\\\release\\\\deps\\\\delta-388fd1701dff5f0c.delta.5660f17b-cgu.12.rcgu.o\" \"C:\\\\Users\\\\daniel\\\\code\\\\misc\\\\dandavison_delta\\\\target\\\\release\\\\deps\\\\delta-388fd1701dff5f0c.delta.5660f17b-cgu.13.rcgu.o\" \"C:\\\\Users\\\\daniel\\\\code\\\\misc\\\\dandavison_delta\\\\target\\\\release\\\\deps\\\\delta-388fd1701dff5f0c.delta.5660f17b-cgu.14.rcgu.o\" \"C:\\\\Users\\\\daniel\\\\code\\\\misc\\\\dandavison_delta\\\\target\\\\release\\\\deps\\\\delta-388fd1701dff5f0c.delta.5660f17b-cgu.15.rcgu.o\" \"C:\\\\Users\\\\daniel\\\\code\\\\misc\\\\dandavison_delta\\\\target\\\\release\\\\deps\\\\delta-388fd1701dff5f0c.delta.5660f17b-cgu.2.rcgu.o\" \"C:\\\\Users\\\\daniel\\\\code\\\\misc\\\\dandavison_delta\\\\target\\\\release\\\\deps\\\\delta-388fd1701dff5f0c.delta.5660f17b-cgu.3.rcgu.o\" \"C:\\\\Users\\\\daniel\\\\code\\\\misc\\\\dandavison_delta\\\\target\\\\release\\\\deps\\\\delta-388fd1701dff5f0c.delta.5660f17b-cgu.4.rcgu.o\" \"C:\\\\Users\\\\daniel\\\\code\\\\misc\\\\dandavison_delta\\\\target\\\\release\\\\deps\\\\delta-388fd1701dff5f0c.delta.5660f17b-cgu.5.rcgu.o\" \"C:\\\\Users\\\\daniel\\\\code\\\\misc\\\\dandavison_delta\\\\target\\\\release\\\\deps\\\\delta-388fd1701dff5f0c.delta.5660f17b-cgu.6.rcgu.o\" \"C:\\\\Users\\\\daniel\\\\code\\\\misc\\\\dandavison_delta\\\\target\\\\release\\\\deps\\\\delta-388fd1701dff5f0c.delta.5660f17b-cgu.7.rcgu.o\" \"C:\\\\Users\\\\daniel\\\\code\\\\misc\\\\dandavison_delta\\\\target\\\\release\\\\deps\\\\delta-388fd1701dff5f0c.delta.5660f17b-cgu.8.rcgu.o\" \"C:\\\\Users\\\\daniel\\\\code\\\\misc\\\\dandavison_delta\\\\target\\\\release\\\\deps\\\\delta-388fd1701dff5f0c.delta.5660f17b-cgu.9.rcgu.o\" \"C:\\\\Users\\\\daniel\\\\code\\\\misc\\\\dandavison_delta\\\\target\\\\release\\\\deps\\\\delta-388fd1701dff5f0c.1osbgvitmqq3gttl.rcgu.o\" \"-L\" \"C:\\\\Users\\\\daniel\\\\code\\\\misc\\\\dandavison_delta\\\\target\\\\release\\\\deps\" \"-L\" \"C:\\\\Users\\\\daniel\\\\.cargo\\\\registry\\\\src\\\\github.com-1ecc6299db9ec823\\\\winapi-x86_64-pc-windows-gnu-0.4.0\\\\lib\" \"-L\" \"C:\\\\Users\\\\daniel\\\\code\\\\misc\\\\dandavison_delta\\\\target\\\\release\\\\build\\\\sys-info-74e57edc44f92486\\\\out\" \"-L\" \"C:\\\\Users\\\\daniel\\\\code\\\\misc\\\\dandavison_delta\\\\target\\\\release\\\\build\\\\libgit2-sys-2a0d2c851744a290\\\\out\\\\build\" \"-L\" \"C:\\\\Users\\\\daniel\\\\code\\\\misc\\\\dandavison_delta\\\\target\\\\release\\\\build\\\\libz-sys-cbb8657cd4ea6d01\\\\out\\\\build\" \"-L\" \"C:\\\\Users\\\\daniel\\\\code\\\\misc\\\\dandavison_delta\\\\target\\\\release\\\\build\\\\onig_sys-00df090b057f8a20\\\\out\" \"-L\" \"C:\\\\Users\\\\daniel\\\\scoop\\\\apps\\\\rust\\\\1.59.0\\\\lib\\\\rustlib\\\\x86_64-pc-windows-gnu\\\\lib\" \"-Wl,-Bstatic\" \"C:\\\\Users\\\\daniel\\\\code\\\\misc\\\\dandavison_delta\\\\target\\\\release\\\\deps\\\\libctrlc-517eca308d80a604.rlib\" \"C:\\\\Users\\\\daniel\\\\code\\\\misc\\\\dandavison_delta\\\\target\\\\release\\\\deps\\\\libpalette-094794265bdeedb6.rlib\" \"C:\\\\Users\\\\daniel\\\\code\\\\misc\\\\dandavison_delta\\\\target\\\\release\\\\deps\\\\libphf-d8e2eb85481f9142.rlib\" \"C:\\\\Users\\\\daniel\\\\code\\\\misc\\\\dandavison_delta\\\\target\\\\release\\\\deps\\\\libphf_shared-3f51b5df4c67cca8.rlib\" \"C:\\\\Users\\\\daniel\\\\code\\\\misc\\\\dandavison_delta\\\\target\\\\release\\\\deps\\\\libsiphasher-ccb02bd83b90b962.rlib\" \"C:\\\\Users\\\\daniel\\\\code\\\\misc\\\\dandavison_delta\\\\target\\\\release\\\\deps\\\\libapprox-860630dfb6fd229d.rlib\" \"C:\\\\Users\\\\daniel\\\\code\\\\misc\\\\dandavison_delta\\\\target\\\\release\\\\deps\\\\libbox_drawing-69e3a8b04f873c5b.rlib\" \"C:\\\\Users\\\\daniel\\\\code\\\\misc\\\\dandavison_delta\\\\target\\\\release\\\\deps\\\\libpathdiff-f74557308d2c8c15.rlib\" \"C:\\\\Users\\\\daniel\\\\code\\\\misc\\\\dandavison_delta\\\\target\\\\release\\\\deps\\\\libchrono_humanize-b8a095c6a6bdf12d.rlib\" \"C:\\\\Users\\\\daniel\\\\code\\\\misc\\\\dandavison_delta\\\\target\\\\release\\\\deps\\\\libdirs_next-3a88b8c9263591f3.rlib\" \"C:\\\\Users\\\\daniel\\\\code\\\\misc\\\\dandavison_delta\\\\target\\\\release\\\\deps\\\\libdirs_sys_next-7831ab0dd784d1c7.rlib\" \"C:\\\\Users\\\\daniel\\\\code\\\\misc\\\\dandavison_delta\\\\target\\\\release\\\\deps\\\\libsysinfo-1006acbd0dd18222.rlib\" \"C:\\\\Users\\\\daniel\\\\code\\\\misc\\\\dandavison_delta\\\\target\\\\release\\\\deps\\\\libntapi-8f7bb41dd6ac2043.rlib\" \"C:\\\\Users\\\\daniel\\\\code\\\\misc\\\\dandavison_delta\\\\target\\\\release\\\\deps\\\\libsmol_str-552cb557c29aed8c.rlib\" \"C:\\\\Users\\\\daniel\\\\code\\\\misc\\\\dandavison_delta\\\\target\\\\release\\\\deps\\\\libbytelines-107e51e448bae35a.rlib\" \"C:\\\\Users\\\\daniel\\\\code\\\\misc\\\\dandavison_delta\\\\target\\\\release\\\\deps\\\\libclap-ec9b56aca310bb59.rlib\" \"C:\\\\Users\\\\daniel\\\\code\\\\misc\\\\dandavison_delta\\\\target\\\\release\\\\deps\\\\libstrsim-76df0c02aa2b7547.rlib\" \"C:\\\\Users\\\\daniel\\\\code\\\\misc\\\\dandavison_delta\\\\target\\\\release\\\\deps\\\\libtextwrap-3c050beb593d825f.rlib\" \"C:\\\\Users\\\\daniel\\\\code\\\\misc\\\\dandavison_delta\\\\target\\\\release\\\\deps\\\\libos_str_bytes-8876a4d80e48c268.rlib\" \"C:\\\\Users\\\\daniel\\\\code\\\\misc\\\\dandavison_delta\\\\target\\\\release\\\\deps\\\\libbat-7627430773e6b7c8.rlib\" \"C:\\\\Users\\\\daniel\\\\code\\\\misc\\\\dandavison_delta\\\\target\\\\release\\\\deps\\\\libansi_colours-59d43a8b118fdef2.rlib\" \"C:\\\\Users\\\\daniel\\\\code\\\\misc\\\\dandavison_delta\\\\target\\\\release\\\\deps\\\\librgb-c5f2c6e04f783afe.rlib\" \"C:\\\\Users\\\\daniel\\\\code\\\\misc\\\\dandavison_delta\\\\target\\\\release\\\\deps\\\\libbytemuck-05c3ef034c8a83de.rlib\" \"C:\\\\Users\\\\daniel\\\\code\\\\misc\\\\dandavison_delta\\\\target\\\\release\\\\deps\\\\libgrep_cli-2ed961359d28f786.rlib\" \"C:\\\\Users\\\\daniel\\\\code\\\\misc\\\\dandavison_delta\\\\target\\\\release\\\\deps\\\\libatty-58e2bc4e555dc6c5.rlib\" \"C:\\\\Users\\\\daniel\\\\code\\\\misc\\\\dandavison_delta\\\\target\\\\release\\\\deps\\\\libtermcolor-16cfc99bbb17367f.rlib\" \"C:\\\\Users\\\\daniel\\\\code\\\\misc\\\\dandavison_delta\\\\target\\\\release\\\\deps\\\\libserde_yaml-60cd78e1abba2072.rlib\" \"C:\\\\Users\\\\daniel\\\\code\\\\misc\\\\dandavison_delta\\\\target\\\\release\\\\deps\\\\libglobset-ef0c13cdcb6356b6.rlib\" \"C:\\\\Users\\\\daniel\\\\code\\\\misc\\\\dandavison_delta\\\\target\\\\release\\\\deps\\\\libbstr-68b2f5b985c8ca38.rlib\" \"C:\\\\Users\\\\daniel\\\\code\\\\misc\\\\dandavison_delta\\\\target\\\\release\\\\deps\\\\libregex_automata-4bc2851e8b3f2572.rlib\" \"C:\\\\Users\\\\daniel\\\\code\\\\misc\\\\dandavison_delta\\\\target\\\\release\\\\deps\\\\libencoding-e42a57a075cc6096.rlib\" \"C:\\\\Users\\\\daniel\\\\code\\\\misc\\\\dandavison_delta\\\\target\\\\release\\\\deps\\\\libencoding_index_tradchinese-0fd9c4dda927b513.rlib\" \"C:\\\\Users\\\\daniel\\\\code\\\\misc\\\\dandavison_delta\\\\target\\\\release\\\\deps\\\\libencoding_index_simpchinese-5197503d79502d4e.rlib\" \"C:\\\\Users\\\\daniel\\\\code\\\\misc\\\\dandavison_delta\\\\target\\\\release\\\\deps\\\\libencoding_index_japanese-52f66f388c604097.rlib\" \"C:\\\\Users\\\\daniel\\\\code\\\\misc\\\\dandavison_delta\\\\target\\\\release\\\\deps\\\\libencoding_index_korean-e1654baba5166616.rlib\" \"C:\\\\Users\\\\daniel\\\\code\\\\misc\\\\dandavison_delta\\\\target\\\\release\\\\deps\\\\libencoding_index_singlebyte-aad08253efd22fc7.rlib\" \"C:\\\\Users\\\\daniel\\\\code\\\\misc\\\\dandavison_delta\\\\target\\\\release\\\\deps\\\\libbytesize-505f185d2821fd9f.rlib\" \"C:\\\\Users\\\\daniel\\\\code\\\\misc\\\\dandavison_delta\\\\target\\\\release\\\\deps\\\\libconsole-973ddb1a0dc6cb34.rlib\" \"C:\\\\Users\\\\daniel\\\\code\\\\misc\\\\dandavison_delta\\\\target\\\\release\\\\deps\\\\libterminal_size-28d3a2a74f5bda22.rlib\" \"C:\\\\Users\\\\daniel\\\\code\\\\misc\\\\dandavison_delta\\\\target\\\\release\\\\deps\\\\libencode_unicode-bcb2712644fc7dae.rlib\" \"C:\\\\Users\\\\daniel\\\\code\\\\misc\\\\dandavison_delta\\\\target\\\\release\\\\deps\\\\libshell_words-21e10021e9ad0991.rlib\" \"C:\\\\Users\\\\daniel\\\\code\\\\misc\\\\dandavison_delta\\\\target\\\\release\\\\deps\\\\libcontent_inspector-4ed2e16c930391d1.rlib\" \"C:\\\\Users\\\\daniel\\\\code\\\\misc\\\\dandavison_delta\\\\target\\\\release\\\\deps\\\\libthiserror-13abce6e2551563d.rlib\" \"C:\\\\Users\\\\daniel\\\\code\\\\misc\\\\dandavison_delta\\\\target\\\\release\\\\deps\\\\libgit2-aee82b4cc5b4f06c.rlib\" \"C:\\\\Users\\\\daniel\\\\code\\\\misc\\\\dandavison_delta\\\\target\\\\release\\\\deps\\\\liburl-1e5ef0c4964d443a.rlib\" \"C:\\\\Users\\\\daniel\\\\code\\\\misc\\\\dandavison_delta\\\\target\\\\release\\\\deps\\\\libidna-45655b7d635c865e.rlib\" \"C:\\\\Users\\\\daniel\\\\code\\\\misc\\\\dandavison_delta\\\\target\\\\release\\\\deps\\\\libunicode_normalization-45dae84655c1ad80.rlib\" \"C:\\\\Users\\\\daniel\\\\code\\\\misc\\\\dandavison_delta\\\\target\\\\release\\\\deps\\\\libtinyvec-f73f6907d3cabecf.rlib\" \"C:\\\\Users\\\\daniel\\\\code\\\\misc\\\\dandavison_delta\\\\target\\\\release\\\\deps\\\\libtinyvec_macros-f7d977ae7420f5db.rlib\" \"C:\\\\Users\\\\daniel\\\\code\\\\misc\\\\dandavison_delta\\\\target\\\\release\\\\deps\\\\libunicode_bidi-912d8c34a85f8f11.rlib\" \"C:\\\\Users\\\\daniel\\\\code\\\\misc\\\\dandavison_delta\\\\target\\\\release\\\\deps\\\\libform_urlencoded-960fd194c6467602.rlib\" \"C:\\\\Users\\\\daniel\\\\code\\\\misc\\\\dandavison_delta\\\\target\\\\release\\\\deps\\\\libpercent_encoding-570ff499e0729138.rlib\" \"C:\\\\Users\\\\daniel\\\\code\\\\misc\\\\dandavison_delta\\\\target\\\\release\\\\deps\\\\libmatches-fcaf9b3f7df69a43.rlib\" \"C:\\\\Users\\\\daniel\\\\code\\\\misc\\\\dandavison_delta\\\\target\\\\release\\\\deps\\\\liblog-e5da14505d51f33a.rlib\" \"C:\\\\Users\\\\daniel\\\\code\\\\misc\\\\dandavison_delta\\\\target\\\\release\\\\deps\\\\libcfg_if-62507f8f070cfdcc.rlib\" \"C:\\\\Users\\\\daniel\\\\code\\\\misc\\\\dandavison_delta\\\\target\\\\release\\\\deps\\\\liblibgit2_sys-5d34ed4cf5bc70dc.rlib\" \"C:\\\\Users\\\\daniel\\\\code\\\\misc\\\\dandavison_delta\\\\target\\\\release\\\\deps\\\\liblibz_sys-ab098aa1ae51ee67.rlib\" \"C:\\\\Users\\\\daniel\\\\code\\\\misc\\\\dandavison_delta\\\\target\\\\release\\\\deps\\\\libclircle-d81692a368cf467b.rlib\" \"C:\\\\Users\\\\daniel\\\\code\\\\misc\\\\dandavison_delta\\\\target\\\\release\\\\deps\\\\libregex-20259a62a589b193.rlib\" \"C:\\\\Users\\\\daniel\\\\code\\\\misc\\\\dandavison_delta\\\\target\\\\release\\\\deps\\\\libaho_corasick-a78a821e4e68fc12.rlib\" \"C:\\\\Users\\\\daniel\\\\code\\\\misc\\\\dandavison_delta\\\\target\\\\release\\\\deps\\\\libmemchr-de59c4f20196f254.rlib\" \"C:\\\\Users\\\\daniel\\\\code\\\\misc\\\\dandavison_delta\\\\target\\\\release\\\\deps\\\\libsemver-f6cb633dde07748c.rlib\" \"C:\\\\Users\\\\daniel\\\\code\\\\misc\\\\dandavison_delta\\\\target\\\\release\\\\deps\\\\libpath_abs-6618aee26f52a023.rlib\" \"C:\\\\Users\\\\daniel\\\\code\\\\misc\\\\dandavison_delta\\\\target\\\\release\\\\deps\\\\libstd_prelude-76fa71f70a47c3ac.rlib\" \"C:\\\\Users\\\\daniel\\\\code\\\\misc\\\\dandavison_delta\\\\target\\\\release\\\\deps\\\\libsyntect-122cc945b171b85c.rlib\" \"C:\\\\Users\\\\daniel\\\\code\\\\misc\\\\dandavison_delta\\\\target\\\\release\\\\deps\\\\libonig-bc9da3bf2dfe6f50.rlib\" \"C:\\\\Users\\\\daniel\\\\code\\\\misc\\\\dandavison_delta\\\\target\\\\release\\\\deps\\\\libonig_sys-8d62e696700ff6b1.rlib\" \"C:\\\\Users\\\\daniel\\\\code\\\\misc\\\\dandavison_delta\\\\target\\\\release\\\\deps\\\\libyaml_rust-50c012d5e8727cf3.rlib\" \"C:\\\\Users\\\\daniel\\\\code\\\\misc\\\\dandavison_delta\\\\target\\\\release\\\\deps\\\\liblinked_hash_map-581b04ae18c4867b.rlib\" \"C:\\\\Users\\\\daniel\\\\code\\\\misc\\\\dandavison_delta\\\\target\\\\release\\\\deps\\\\liblazycell-a1fea52b1516f65a.rlib\" \"C:\\\\Users\\\\daniel\\\\code\\\\misc\\\\dandavison_delta\\\\target\\\\release\\\\deps\\\\libregex_syntax-14cb40bd50b2fa1e.rlib\" \"C:\\\\Users\\\\daniel\\\\code\\\\misc\\\\dandavison_delta\\\\target\\\\release\\\\deps\\\\libfnv-971f465861675fb9.rlib\" \"C:\\\\Users\\\\daniel\\\\code\\\\misc\\\\dandavison_delta\\\\target\\\\release\\\\deps\\\\libwalkdir-a9b090215d9095f6.rlib\" \"C:\\\\Users\\\\daniel\\\\code\\\\misc\\\\dandavison_delta\\\\target\\\\release\\\\deps\\\\libsame_file-1e6a1d5c6026fd8f.rlib\" \"C:\\\\Users\\\\daniel\\\\code\\\\misc\\\\dandavison_delta\\\\target\\\\release\\\\deps\\\\libwinapi_util-cf7c33ea1835ed7e.rlib\" \"C:\\\\Users\\\\daniel\\\\code\\\\misc\\\\dandavison_delta\\\\target\\\\release\\\\deps\\\\libserde_json-83d133781412ee8d.rlib\" \"C:\\\\Users\\\\daniel\\\\code\\\\misc\\\\dandavison_delta\\\\target\\\\release\\\\deps\\\\libryu-1a29be5361a27ea2.rlib\" \"C:\\\\Users\\\\daniel\\\\code\\\\misc\\\\dandavison_delta\\\\target\\\\release\\\\deps\\\\libitoa-8157616bca765a90.rlib\" \"C:\\\\Users\\\\daniel\\\\code\\\\misc\\\\dandavison_delta\\\\target\\\\release\\\\deps\\\\libplist-8c48031d67814e27.rlib\" \"C:\\\\Users\\\\daniel\\\\code\\\\misc\\\\dandavison_delta\\\\target\\\\release\\\\deps\\\\libchrono-d3aded8e76c2a316.rlib\" \"C:\\\\Users\\\\daniel\\\\code\\\\misc\\\\dandavison_delta\\\\target\\\\release\\\\deps\\\\libnum_integer-c4f66485f9318bed.rlib\" \"C:\\\\Users\\\\daniel\\\\code\\\\misc\\\\dandavison_delta\\\\target\\\\release\\\\deps\\\\libnum_traits-809cec538ab977ad.rlib\" \"C:\\\\Users\\\\daniel\\\\code\\\\misc\\\\dandavison_delta\\\\target\\\\release\\\\deps\\\\liblibc-c79fe06000a35fee.rlib\" \"C:\\\\Users\\\\daniel\\\\code\\\\misc\\\\dandavison_delta\\\\target\\\\release\\\\deps\\\\libtime-68369df8bf47cd51.rlib\" \"C:\\\\Users\\\\daniel\\\\code\\\\misc\\\\dandavison_delta\\\\target\\\\release\\\\deps\\\\libline_wrap-5ddac815b34cd38e.rlib\" \"C:\\\\Users\\\\daniel\\\\code\\\\misc\\\\dandavison_delta\\\\target\\\\release\\\\deps\\\\libsafemem-386a58ba56b88225.rlib\" \"C:\\\\Users\\\\daniel\\\\code\\\\misc\\\\dandavison_delta\\\\target\\\\release\\\\deps\\\\libxml-c0683560801854dd.rlib\" \"C:\\\\Users\\\\daniel\\\\code\\\\misc\\\\dandavison_delta\\\\target\\\\release\\\\deps\\\\libbase64-3f000030df5f928d.rlib\" \"C:\\\\Users\\\\daniel\\\\code\\\\misc\\\\dandavison_delta\\\\target\\\\release\\\\deps\\\\libindexmap-2e09f0fd0bc11929.rlib\" \"C:\\\\Users\\\\daniel\\\\code\\\\misc\\\\dandavison_delta\\\\target\\\\release\\\\deps\\\\libhashbrown-f2664b059caa3af2.rlib\" \"C:\\\\Users\\\\daniel\\\\code\\\\misc\\\\dandavison_delta\\\\target\\\\release\\\\deps\\\\libflate2-4c5d68b09745d2b3.rlib\" \"C:\\\\Users\\\\daniel\\\\code\\\\misc\\\\dandavison_delta\\\\target\\\\release\\\\deps\\\\libminiz_oxide-92f52260d86a9b9d.rlib\" \"C:\\\\Users\\\\daniel\\\\code\\\\misc\\\\dandavison_delta\\\\target\\\\release\\\\deps\\\\libadler-83c07df36380bc36.rlib\" \"C:\\\\Users\\\\daniel\\\\code\\\\misc\\\\dandavison_delta\\\\target\\\\release\\\\deps\\\\libcrc32fast-f99b9f76ca760eb1.rlib\" \"C:\\\\Users\\\\daniel\\\\code\\\\misc\\\\dandavison_delta\\\\target\\\\release\\\\deps\\\\libcfg_if-850f26a1f4649596.rlib\" \"C:\\\\Users\\\\daniel\\\\code\\\\misc\\\\dandavison_delta\\\\target\\\\release\\\\deps\\\\libbincode-b26c539aab39b8c4.rlib\" \"C:\\\\Users\\\\daniel\\\\code\\\\misc\\\\dandavison_delta\\\\target\\\\release\\\\deps\\\\libserde-16600b92ef3d1344.rlib\" \"C:\\\\Users\\\\daniel\\\\code\\\\misc\\\\dandavison_delta\\\\target\\\\release\\\\deps\\\\libbyteorder-8f093c2f5836aac0.rlib\" \"C:\\\\Users\\\\daniel\\\\code\\\\misc\\\\dandavison_delta\\\\target\\\\release\\\\deps\\\\liblazy_static-d7a1fae3ea7ae2ea.rlib\" \"C:\\\\Users\\\\daniel\\\\code\\\\misc\\\\dandavison_delta\\\\target\\\\release\\\\deps\\\\libonce_cell-8b0856ea22563d09.rlib\" \"C:\\\\Users\\\\daniel\\\\code\\\\misc\\\\dandavison_delta\\\\target\\\\release\\\\deps\\\\libunicode_width-81f0bd39df38f7bd.rlib\" \"C:\\\\Users\\\\daniel\\\\code\\\\misc\\\\dandavison_delta\\\\target\\\\release\\\\deps\\\\libunicode_segmentation-7c237a5f4ca3bc63.rlib\" \"C:\\\\Users\\\\daniel\\\\code\\\\misc\\\\dandavison_delta\\\\target\\\\release\\\\deps\\\\libitertools-2b7db696e7cea099.rlib\" \"C:\\\\Users\\\\daniel\\\\code\\\\misc\\\\dandavison_delta\\\\target\\\\release\\\\deps\\\\libeither-72b4dff91df84206.rlib\" \"C:\\\\Users\\\\daniel\\\\code\\\\misc\\\\dandavison_delta\\\\target\\\\release\\\\deps\\\\libansi_term-d96463e233957519.rlib\" \"C:\\\\Users\\\\daniel\\\\code\\\\misc\\\\dandavison_delta\\\\target\\\\release\\\\deps\\\\libwinapi-b15a5c5d1d695ce7.rlib\" \"C:\\\\Users\\\\daniel\\\\code\\\\misc\\\\dandavison_delta\\\\target\\\\release\\\\deps\\\\libvte-039861bc1f76928f.rlib\" \"C:\\\\Users\\\\daniel\\\\code\\\\misc\\\\dandavison_delta\\\\target\\\\release\\\\deps\\\\libutf8parse-4f12450876002a2b.rlib\" \"C:\\\\Users\\\\daniel\\\\code\\\\misc\\\\dandavison_delta\\\\target\\\\release\\\\deps\\\\libarrayvec-ecf60af044cc8a51.rlib\" \"C:\\\\Users\\\\daniel\\\\code\\\\misc\\\\dandavison_delta\\\\target\\\\release\\\\deps\\\\liberror_chain-05132136e258b654.rlib\" \"C:\\\\Users\\\\daniel\\\\code\\\\misc\\\\dandavison_delta\\\\target\\\\release\\\\deps\\\\libbitflags-35ed76b02d0c357c.rlib\" \"-Wl,--start-group\" \"C:\\\\Users\\\\daniel\\\\scoop\\\\apps\\\\rust\\\\1.59.0\\\\lib\\\\rustlib\\\\x86_64-pc-windows-gnu\\\\lib\\\\libstd-56555e8df3df487f.rlib\" \"C:\\\\Users\\\\daniel\\\\scoop\\\\apps\\\\rust\\\\1.59.0\\\\lib\\\\rustlib\\\\x86_64-pc-windows-gnu\\\\lib\\\\libpanic_unwind-04dfc4a5db6cb4f5.rlib\" \"C:\\\\Users\\\\daniel\\\\scoop\\\\apps\\\\rust\\\\1.59.0\\\\lib\\\\rustlib\\\\x86_64-pc-windows-gnu\\\\lib\\\\libobject-e582f52592ec7f47.rlib\" \"C:\\\\Users\\\\daniel\\\\scoop\\\\apps\\\\rust\\\\1.59.0\\\\lib\\\\rustlib\\\\x86_64-pc-windows-gnu\\\\lib\\\\libmemchr-a1a4dcc32e76e372.rlib\" \"C:\\\\Users\\\\daniel\\\\scoop\\\\apps\\\\rust\\\\1.59.0\\\\lib\\\\rustlib\\\\x86_64-pc-windows-gnu\\\\lib\\\\libaddr2line-627bcebbbc102a48.rlib\" \"C:\\\\Users\\\\daniel\\\\scoop\\\\apps\\\\rust\\\\1.59.0\\\\lib\\\\rustlib\\\\x86_64-pc-windows-gnu\\\\lib\\\\libgimli-be04d4d5349d30fd.rlib\" \"C:\\\\Users\\\\daniel\\\\scoop\\\\apps\\\\rust\\\\1.59.0\\\\lib\\\\rustlib\\\\x86_64-pc-windows-gnu\\\\lib\\\\libstd_detect-db47bdfceba1a4fb.rlib\" \"C:\\\\Users\\\\daniel\\\\scoop\\\\apps\\\\rust\\\\1.59.0\\\\lib\\\\rustlib\\\\x86_64-pc-windows-gnu\\\\lib\\\\librustc_demangle-dee726504430f253.rlib\" \"C:\\\\Users\\\\daniel\\\\scoop\\\\apps\\\\rust\\\\1.59.0\\\\lib\\\\rustlib\\\\x86_64-pc-windows-gnu\\\\lib\\\\libhashbrown-437c3d2676cc0788.rlib\" \"C:\\\\Users\\\\daniel\\\\scoop\\\\apps\\\\rust\\\\1.59.0\\\\lib\\\\rustlib\\\\x86_64-pc-windows-gnu\\\\lib\\\\librustc_std_workspace_alloc-1270bba6b8f30349.rlib\" \"C:\\\\Users\\\\daniel\\\\scoop\\\\apps\\\\rust\\\\1.59.0\\\\lib\\\\rustlib\\\\x86_64-pc-windows-gnu\\\\lib\\\\libunwind-f8f2892b852b8ad4.rlib\" \"C:\\\\Users\\\\daniel\\\\scoop\\\\apps\\\\rust\\\\1.59.0\\\\lib\\\\rustlib\\\\x86_64-pc-windows-gnu\\\\lib\\\\libcfg_if-c1b181d856fd1e1d.rlib\" \"C:\\\\Users\\\\daniel\\\\scoop\\\\apps\\\\rust\\\\1.59.0\\\\lib\\\\rustlib\\\\x86_64-pc-windows-gnu\\\\lib\\\\liblibc-f05d25f40b11c06d.rlib\" \"C:\\\\Users\\\\daniel\\\\scoop\\\\apps\\\\rust\\\\1.59.0\\\\lib\\\\rustlib\\\\x86_64-pc-windows-gnu\\\\lib\\\\liballoc-0feff3ebeb068fdc.rlib\" \"C:\\\\Users\\\\daniel\\\\scoop\\\\apps\\\\rust\\\\1.59.0\\\\lib\\\\rustlib\\\\x86_64-pc-windows-gnu\\\\lib\\\\librustc_std_workspace_core-ff80f052342e9644.rlib\" \"C:\\\\Users\\\\daniel\\\\scoop\\\\apps\\\\rust\\\\1.59.0\\\\lib\\\\rustlib\\\\x86_64-pc-windows-gnu\\\\lib\\\\libcore-c879fd37675b8e5a.rlib\" \"-Wl,--end-group\" \"C:\\\\Users\\\\daniel\\\\scoop\\\\apps\\\\rust\\\\1.59.0\\\\lib\\\\rustlib\\\\x86_64-pc-windows-gnu\\\\lib\\\\libcompiler_builtins-36a35a68f30e9765.rlib\" \"-Wl,-Bdynamic\" \"-lwinapi_ntdll\" \"-lwinhttp\" \"-lrpcrt4\" \"-lole32\" \"-lcrypt32\" \"-lwinapi_advapi32\" \"-lwinapi_cfgmgr32\" \"-lwinapi_credui\" \"-lwinapi_gdi32\" \"-lwinapi_iphlpapi\" \"-lwinapi_kernel32\" \"-lwinapi_msimg32\" \"-lwinapi_netapi32\" \"-lwinapi_ole32\" \"-lwinapi_oleaut32\" \"-lwinapi_opengl32\" \"-lwinapi_pdh\" \"-lwinapi_powrprof\" \"-lwinapi_psapi\" \"-lwinapi_secur32\" \"-lwinapi_shell32\" \"-lwinapi_shlwapi\" \"-lwinapi_synchronization\" \"-lwinapi_user32\" \"-lwinapi_winspool\" \"-lkernel32\" \"-lws2_32\" \"-lbcrypt\" \"-ladvapi32\" \"-luserenv\" \"-lkernel32\" \"-lgcc_eh\" \"-l:libpthread.a\" \"-lmsvcrt\" \"-lmingwex\" \"-lmingw32\" \"-lgcc\" \"-lmsvcrt\" \"-luser32\" \"-lkernel32\" \"-Wl,--nxcompat\" \"-nostartfiles\" \"-L\" \"C:\\\\Users\\\\daniel\\\\scoop\\\\apps\\\\rust\\\\1.59.0\\\\lib\\\\rustlib\\\\x86_64-pc-windows-gnu\\\\lib\" \"-L\" \"C:\\\\Users\\\\daniel\\\\scoop\\\\apps\\\\rust\\\\1.59.0\\\\lib\\\\rustlib\\\\x86_64-pc-windows-gnu\\\\lib\\\\self-contained\" \"-o\" \"C:\\\\Users\\\\daniel\\\\code\\\\misc\\\\dandavison_delta\\\\target\\\\release\\\\deps\\\\delta-388fd1701dff5f0c.exe\" \"-Wl,--gc-sections\" \"-no-pie\" \"-Wl,-O1\" \"-nodefaultlibs\" \"C:\\\\Users\\\\daniel\\\\scoop\\\\apps\\\\rust\\\\1.59.0\\\\lib\\\\rustlib\\\\x86_64-pc-windows-gnu\\\\lib\\\\rsend.o\"\r\n = note: C:\\Users\\daniel\\code\\misc\\dandavison_delta\\target\\release\\deps\\libonig_sys-8d62e696700ff6b1.rlib(regexec.o):regexec.c:(.text$onig_setup_builtin_monitors_by_ascii_encoded_name+0xb7): undefined reference to `__imp___acrt_iob_func'\r\n C:\\Users\\daniel\\code\\misc\\dandavison_delta\\target\\release\\deps\\liblibgit2_sys-5d34ed4cf5bc70dc.rlib(diff_print.o):diff_print.c:(.text$git_diff_print_callback__to_file_handle+0x67): undefined reference to `__imp___acrt_iob_func'\r\n C:\\Users\\daniel\\code\\misc\\dandavison_delta\\target\\release\\deps\\liblibgit2_sys-5d34ed4cf5bc70dc.rlib(signature.o):signature.c:(.text$git_signature_now+0x4f): undefined reference to `__imp__difftime64'\r\n C:\\Users\\daniel\\code\\misc\\dandavison_delta\\target\\release\\deps\\liblibgit2_sys-5d34ed4cf5bc70dc.rlib(signature.o):signature.c:(.text$git_signature_default+0xc3): undefined reference to `__imp__difftime64'\r\n C:\\Users\\daniel\\code\\misc\\dandavison_delta\\target\\release\\deps\\liblibgit2_sys-5d34ed4cf5bc70dc.rlib(xdiffi.o):xdiffi.c:(.text$xdl_bug+0xf): undefined reference to `__imp___acrt_iob_func'\r\n C:\\Users\\daniel\\code\\misc\\dandavison_delta\\target\\release\\deps\\liblibgit2_sys-5d34ed4cf5bc70dc.rlib(util.o):util.c:(.text$printf+0x2a): undefined reference to `__imp___acrt_iob_func'\r\n C:\\Users\\daniel\\code\\misc\\dandavison_delta\\target\\release\\deps\\liblibgit2_sys-5d34ed4cf5bc70dc.rlib(util.o):util.c:(.text$printf.constprop.0+0x25): undefined reference to `__imp___acrt_iob_func'\r\n C:\\Users\\daniel\\code\\misc\\dandavison_delta\\target\\release\\deps\\liblibgit2_sys-5d34ed4cf5bc70dc.rlib(util.o):util.c:(.text$printf.constprop.1+0x25): undefined reference to `__imp___acrt_iob_func'\r\n C:\\Users\\daniel\\code\\misc\\dandavison_delta\\target\\release\\deps\\liblibgit2_sys-5d34ed4cf5bc70dc.rlib(util.o):util.c:(.text$printf.constprop.2+0x25): undefined reference to `__imp___acrt_iob_func'\r\n C:\\Users\\daniel\\code\\misc\\dandavison_delta\\target\\release\\deps\\liblibgit2_sys-5d34ed4cf5bc70dc.rlib(util.o):util.c:(.text$printf.constprop.3+0x25): more undefined references to `__imp___acrt_iob_func' follow\r\n \r\n = help: some `extern` functions couldn't be found; some native libraries may need to be installed or have their path specified\r\n = note: use the `-l` flag to specify native libraries to link\r\n = note: use the `cargo:rustc-link-lib` directive to specify the native libraries to link with Cargo (see https://doc.rust-lang.org/cargo/reference/build-scripts.html#cargorustc-link-libkindname)\r\n \r\n error: could not compile `git-delta` due to previous error\r\n ```\r\n</details>\r\n\r\nIn any case, that screenshot looks **SHARP**! The diff you show is _exactly_ what I was after (you even nailed the slightly darker shades of red/green on the line number columns!) This indeed looks very promising! 🎉\r\n\r\nThank you a lot for taking the time to look into this!\r\n","createdAt":"2022-03-14T20:21:23Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/949#issuecomment-1067250224","viewerDidAuthor":false},{"id":"IC_kwDOC4j8g84_qPDH","author":{"login":"dandavison"},"authorAssociation":"OWNER","body":"Oh no! Thanks for trying! I don't have any Windows knowledge unfortunately, and I don't want to waste more of your time with this. I pushed another update yesterday that I think may make it compatible with `side-by-side` so I will try to get this change made and released. I'll keep this ticket updated as there's progress towards that.","createdAt":"2022-03-15T14:13:30Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[{"content":"HEART","users":{"totalCount":1}}],"url":"https://github.com/dandavison/delta/issues/949#issuecomment-1068036295","viewerDidAuthor":true}],"number":949,"title":"🚀 GitHub-like style"},{"body":"- [x] Please include the raw text output from git, so that we can reproduce the problem.\r\n (You can use `git --no-pager` to produce the raw text output.)\r\n- [x] A screenshot of Delta's output is often helpful also.\r\n\r\nThe output of `git format-patch` has got a version footer:\r\n\r\n```\r\n--\r\n2.35.1\r\n```\r\n\r\nAnd the `--` here is marked as deletion, which is a bit confusing.\r\n\r\n<img width=\"281\" alt=\"image\" src=\"https://user-images.githubusercontent.com/4507647/152070993-3262916c-eb7d-40da-b3e0-03630bfedaf4.png\">\r\n\r\n\r\nIt'd be nice if this can be avoided :)\r\n","comments":[{"id":"IC_kwDOC4j8g849PepN","author":{"login":"dandavison"},"authorAssociation":"OWNER","body":"Hi @Frederick888, thanks. What command are you typically issuing when you use delta to view `git format-patch` output?\r\n\r\nDo you have any thoughts about the right fix here? If we are doing line-by-line parsing then `--` is ambiguous, since it could genuinely be the removal of a line containing `-`.","createdAt":"2022-02-02T00:53:23Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/941#issuecomment-1027467853","viewerDidAuthor":true},{"id":"IC_kwDOC4j8g849QK8I","author":{"login":"Frederick888"},"authorAssociation":"NONE","body":"Turned out that this is not a footer, but an email signature. The version number is just its default value. I literally have never seen anyone customising this in all the mailing lists I'm subscribed to...\r\n\r\nI usually use `git format-patch -1` `git format-patch <since>` etc. I know this is designed for emails but these days I also copy its output to GitHub, Slack and so on. If delta only parses and renders lines by line, this is quite tricky to handle and I haven't got a good idea in my mind (especially when we don't know the size of input). But I guess users like me can `git format-patch --no-signature` instead or even `git config --global format.signature ''` if they don't care about emails.\r\n\r\nPlease feel free to close this issue. And thanks for this awesome project btw :)","createdAt":"2022-02-02T07:15:38Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/941#issuecomment-1027649288","viewerDidAuthor":false},{"id":"IC_kwDOC4j8g849RDzW","author":{"login":"Frederick888"},"authorAssociation":"NONE","body":"On a second thought, is it possible to process the diff size lines? For example,\r\n\r\n```patch\r\nFrom 3683cf5dcf10d032741cc570c9d7c6e20d819f7d Mon Sep 17 00:00:00 2001\r\nFrom: Frederick Zhang <frederick888@tsundere.moe>\r\nDate: Wed, 2 Feb 2022 23:02:34 +1100\r\nSubject: [PATCH] Test\r\n\r\nSigned-off-by: Frederick Zhang <frederick888@tsundere.moe>\r\n---\r\n README.md | 5 +++--\r\n 1 file changed, 3 insertions(+), 2 deletions(-)\r\n\r\ndiff --git a/README.md b/README.md\r\nindex 5fc8cb0..f70aa05 100644\r\n--- a/README.md\r\n+++ b/README.md\r\n@@ -1,9 +1,10 @@\r\n+new line\r\n+\r\n hello\r\n\r\n-world\r\n+world1\r\n\r\n foo\r\n\r\n bar\r\n\r\n--\r\n--\r\n2.35.1\r\n```\r\n\r\nIt'll be something like:\r\n\r\n```\r\nnum_lines_old, num_lines_new = 9, 10\r\ncounter_old, counter_new = 0, 0\r\n\r\nwhile line = input.read():\r\n switch line[0]:\r\n ' ':\r\n counter_new++\r\n counter_old++\r\n '+':\r\n counter_new++\r\n '-':\r\n counter_old++\r\n render(line)\r\n if counter_old == num_lines_old && counter_new == num_lines_new:\r\n # done reading current hunk\r\n return\r\n```\r\n\r\n`new` counter stops at the empty line after `bar`, `old` counter stops at the second last `--`. Then we know the last `--` above `2.35.1` doesn't really belong to the diff.","createdAt":"2022-02-02T12:18:25Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/941#issuecomment-1027882198","viewerDidAuthor":false},{"id":"IC_kwDOC4j8g849RSvx","author":{"login":"dandavison"},"authorAssociation":"OWNER","body":"That sounds like potentially a good idea -- it feels a bit slack that we're not making use of the diff hunk line coordinates, and there might be other edge cases that it fixes / simplifies existing code. (If you or anyone else would like to look into it, that would of course be very welcome.)\r\n","createdAt":"2022-02-02T13:30:54Z","includesCreatedEdit":true,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/941#issuecomment-1027943409","viewerDidAuthor":true},{"id":"IC_kwDOC4j8g849RT1y","author":{"login":"dandavison"},"authorAssociation":"OWNER","body":"> (If you or anyone else would like to look into it, that would of course be very welcome.)\r\n\r\nWe have [ARCHITECTURE.md](https://github.com/dandavison/delta/blob/master/ARCHITECTURE.md) as a starting point for anyone interested in working on the delta codebase.","createdAt":"2022-02-02T13:36:01Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[{"content":"THUMBS_UP","users":{"totalCount":1}}],"url":"https://github.com/dandavison/delta/issues/941#issuecomment-1027947890","viewerDidAuthor":true}],"number":941,"title":"🐛 Avoid marking `--` above Git version in format-patch output as deletion"},{"body":"(filing this as a feature request instead of a bug report because I'm not sure if this is the intended behavior or not)\r\n\r\n---\r\n\r\nCurrently, when using `delta` as a diff tool with paths that are symlinks, the literal contents of the symlink (as in, the path of the file that's being pointed to) is used in the diff instead of the contents of the file that's being pointed to.\r\n\r\nFor example:\r\n```bash\r\necho \"hello\" > foo\r\nln -s foo bar\r\ndelta -s foo bar\r\n```\r\nyields:\r\n```\r\n❯ delta foo bar -s\r\n\r\nremoved: foo\r\n─────────────────────────────────────────────────────────────────────────────────\r\n\r\n───┐\r\n0: │\r\n───┘\r\n│ 1 │hello │ │\r\n\r\nadded: bar\r\n─────────────────────────────────────────────────────────────────────────────────\r\n\r\n───┐\r\n1: │\r\n───┘\r\n│ │ │ 1 │foo\r\n\\ No newline at end of file\r\n```\r\ninstead of no output (as `diff`, for example, does).\r\n\r\nThis is because of `git diff --no-index`'s behavior with respect to symlinks. As far as I know there isn't any user-facing way to change this behavior ([1](https://public-inbox.org/git/xmqqk27m1ixf.fsf@gitster.mtv.corp.google.com/T/), [2](https://git.vger.kernel.narkive.com/q1CpMpoI/grep-doesn-t-follow-symbolic-link); there was a [patch](https://public-inbox.org/git/20161111201958.2175-1-dennis@kaarsemaker.net/) that changed the default behavior to be to follow symlinks but afaict it was never merged).\r\n\r\n---\r\n\r\nIs this intended behavior for `delta`?\r\n\r\nAdding calls to [`fs::canonicalize`](https://doc.rust-lang.org/std/fs/fn.canonicalize.html) to [these two paths](https://github.com/dandavison/delta/blob/8db8e908432539543341109f94a19dc2c6f4af7f/src/subcommands/diff.rs#L27-L28) would change `delta`'s behavior w.r.t. symlinks to match `diff` and other tools but would also mean there isn't a way to actually diff the literal contents of symlinks (`diff` has `--no-dereference` for example). I'm not sure if this matters.\r\n\r\n(Also right now `delta` just lets `git diff --no-index` error when a file that's specified doesn't exist; if we call `canonicalize` in `delta` we'd need to handle the possibility of broken symlinks. I assume just printing an error message matching that of `git diff` (i.e. `error: Could not access: ...`) for symmetry is acceptable)\r\n\r\nIf this is deemed a reasonable change, I'm very happy to make a PR with the above change and some tests.","comments":[{"id":"IC_kwDOC4j8g8481RRb","author":{"login":"dandavison"},"authorAssociation":"OWNER","body":"Hi @rrbutani, thanks for writing this up. IMO this is a bug and it would be fantastic if you could fix this. I don't think we need to support diffing the contents of the symlink itself -- my intention is that the semantics of `delta a b` are the same as `diff a b`.\r\n\r\nWhile you're at it (and maybe more interesting challenge?) is there any way to workaround the related process substitution problem (see https://github.com/dandavison/delta/issues/666 and duplicate reports linked therein):\r\n\r\n```\r\n~ delta <(echo aaa) <(echo bbb)\r\nerror: /dev/fd/11: unsupported file type\r\nfatal: cannot hash /dev/fd/11\r\n```\r\n\r\n(That's MacOS but I think there's a similar error on Linux and *BSDs)","createdAt":"2022-01-24T22:09:27Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[{"content":"THUMBS_UP","users":{"totalCount":1}}],"url":"https://github.com/dandavison/delta/issues/929#issuecomment-1020597339","viewerDidAuthor":true},{"id":"IC_kwDOC4j8g8481aZV","author":{"login":"rrbutani"},"authorAssociation":"NONE","body":"Unfortunately I don't think calling `canonicalize` fixes the process substitution case; i.e.\r\n```bash\r\ngit diff --no-index $(realpath <(echo foo)) $(realpath <(echo bar))\r\n```\r\ndoes not work.\r\n\r\n(`realpath <(echo yo)` yields a pipe which I don't think you can treat as a file anyways (?); `diff` and other tools are similarly confused by this kind of thing: `cat $(realpath <(echo yo))` for example)\r\n\r\nI do have a workaround for when there's only 1 process substitution in the args though: `git diff` will happily read from `stdin` which means we can rewrite `delta <(echo yo) /some/file` as `git diff-index - /some/file < <(echo yo)` (or the Rust `Command` equivalent of that anyways; i.e. passing the `/dev/fd/<whatever>` that `delta` gets as arg1 into `git diff-index` as stdin).\r\n\r\nUnfortunately this doesn't help the case where there are two process substitutions.\r\n\r\nSo far `git diff` seems unhappy with any kind of special file (`mkfifo` also doesn't work with it). The best I can come up with is to write one of the arguments to a temporary file if necessary but that's obviously suboptimal for a lot of reasons.\r\n\r\nI'll take a peek at the `git diff --no-index` source code next to see if I missed anything.","createdAt":"2022-01-24T23:00:42Z","includesCreatedEdit":true,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/929#issuecomment-1020634709","viewerDidAuthor":false},{"id":"IC_kwDOC4j8g8481bOx","author":{"login":"rrbutani"},"authorAssociation":"NONE","body":"@dandavison If I don't find a better way though, is ^ worth implementing/merging? Is the temp file solution worth writing (seems like the kind of thing that may be better being opt in, as a flag)?\r\n\r\nAlternatively we could choose to just not use `git diff --index` as the diff tool when we have two process substitutions. I'm not sure what utility it has over regular diff tools when we know for certain that the things being compared aren't tracked by source control.\r\n\r\nEdit: whoops, just saw #543. ~~I don't think the specific example in that issue (`diff.context`) applies to `git diff` with `--no-index` though.~~","createdAt":"2022-01-24T23:05:12Z","includesCreatedEdit":true,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/929#issuecomment-1020638129","viewerDidAuthor":false},{"id":"IC_kwDOC4j8g8481fng","author":{"login":"dandavison"},"authorAssociation":"OWNER","body":"Yes #543 made me realize that there is benefit in using `git diff` for this -- I do think it makes sense to stick with it.\r\n\r\n> The best I can think come up with is to write one of the arguments to a temporary file if necessary but that's obviously suboptimal for a lot of reasons.\r\n\r\nI know it's not pretty, but I actually think that would in practice solve the vast majority of people's pain with this. What do you think? If you're up for implementing it I think that would be great -- quite a few people have stumbled across this problem.\r\n\r\nAnd the symlink solution also of course!\r\n\r\nI know there are these two git patches but I haven't looked into how they relate yet\r\n\r\n- https://marc.info/?l=git&m=141347274420939&w=2\r\n- https://public-inbox.org/git/20161111201958.2175-1-dennis@kaarsemaker.net/","createdAt":"2022-01-24T23:29:51Z","includesCreatedEdit":true,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/929#issuecomment-1020656096","viewerDidAuthor":true},{"id":"IC_kwDOC4j8g8481gxY","author":{"login":"dandavison"},"authorAssociation":"OWNER","body":"> (seems like the kind of thing that may be better being opt in, as a flag)?\r\n\r\nAs long as the temp file only happens when the user uses shell process substitution syntax then I think we should make it default, so people get the benefit automatically without having to google the problem. I'm assuming we can avoid copying normal files in \"normal\" diff invocations.","createdAt":"2022-01-24T23:39:13Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[{"content":"THUMBS_UP","users":{"totalCount":1}}],"url":"https://github.com/dandavison/delta/issues/929#issuecomment-1020660824","viewerDidAuthor":true},{"id":"IC_kwDOC4j8g8481iHw","author":{"login":"rrbutani"},"authorAssociation":"NONE","body":"> Yes #543 made me realize that there is benefit in using `git diff` for this -- I do think it makes sense to stick with it.\r\n\r\nDo you know if there are `git diff` settings/differences in it's output that apply to untracked files? \r\n\r\nMost of `git help --config | grep ^diff` seems like it doesn't apply to the process substitution args case; it feels very tempting to try to extract the options that do apply like `diff.context` and pass them along, just in this specific case.\r\n\r\n> I know it's not pretty, but I actually think that would in practice solve the vast majority of people's pain with this. What do you think? If you're up for implementing it I think that would be great -- quite a few people have stumbled across this problem.\r\n\r\nI'm definitely happy to make this change but I'm not sure I know how to catch and handle all the edge cases (I think we'd want to use `mktemp` which handles cleanup and is cross platform; is it fine to pull in another dep? Should we bound the size of the temp file we create, somehow? It doesn't seem inconceivable to me that we could run out of disk space writing a temp file (I think wrangling lengthy streams is definitely a primary motivating use case for process substitution) and while I'm pretty sure `mktemp` would do the right thing in this case -- its cleanup is in a `Drop` impl which will still get run if we `panic` and the process starts to unwind -- I have not personally tried this).\r\n\r\nMostly though I think the expectation with process substitution is that stuff isn't being written to disk and I'm a little uneasy subverting that expectation.","createdAt":"2022-01-24T23:50:57Z","includesCreatedEdit":true,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/929#issuecomment-1020666352","viewerDidAuthor":false},{"id":"IC_kwDOC4j8g8481jHu","author":{"login":"rrbutani"},"authorAssociation":"NONE","body":"I think it's ultimately a question of which behavior is more surprising when asked to diff two process substitutions: slightly different diff output or one of the streams being written to disk, temporarily.\r\n\r\n(I feel the latter would be more surprising but my usage is also maybe a bit pathological: diffing lengthy command outputs on machines with slow disk drives where the added latency of writing to a temp file first would be noticeable, etc)\r\n\r\nRegardless, I'm happy to make a PR implementing whichever approach you think is better.","createdAt":"2022-01-24T23:59:35Z","includesCreatedEdit":true,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/929#issuecomment-1020670446","viewerDidAuthor":false},{"id":"IC_kwDOC4j8g8481odT","author":{"login":"dandavison"},"authorAssociation":"OWNER","body":"> slightly different diff output \r\n\r\nHere you're implying that we could fall back to `diff` in the two-process-substitution case, right?\r\n\r\nHm. I agree it's an option, but I think I'd prefer not to have the inconsistency of having both the `diff` and `git diff` versions implemented in delta. People who are diffing two process substitutions with lengthy output can always do `diff <(echo a) <(echo b) | delta` after all (and they probably have the sophistication to switch to that without much thinking).","createdAt":"2022-01-25T00:40:51Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[{"content":"THUMBS_UP","users":{"totalCount":1}}],"url":"https://github.com/dandavison/delta/issues/929#issuecomment-1020692307","viewerDidAuthor":true},{"id":"IC_kwDOC4j8g8481ojH","author":{"login":"dandavison"},"authorAssociation":"OWNER","body":"But your efficient one-process subst trick is cool -- happy to have that as a code path in addition to the last-resort copying.","createdAt":"2022-01-25T00:41:43Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[{"content":"THUMBS_UP","users":{"totalCount":1}}],"url":"https://github.com/dandavison/delta/issues/929#issuecomment-1020692679","viewerDidAuthor":true}],"number":929,"title":"Should `delta` follow symlinks?"},{"body":"At the moment in side-by-side view new files will show up on the right split. As there is nothing to compare it to the left split is completely blank. It would be great to have an option to show new files show up on the left split if there's nothing to compare. ","comments":[{"id":"IC_kwDOC4j8g848jE-D","author":{"login":"dandavison"},"authorAssociation":"OWNER","body":"Hi @citizenharris, thanks! I agree. In fact I wonder if that should be the default. Are you thinking we should just not show that file in side-by-side mode at all? (I think I'm in favour of that.) I expect @th1000s has thought about this.","createdAt":"2022-01-18T20:58:57Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/923#issuecomment-1015828355","viewerDidAuthor":true},{"id":"IC_kwDOC4j8g848jVmy","author":{"login":"th1000s"},"authorAssociation":"COLLABORATOR","body":"The left side is also blank when a large block is added, in my opinion the \"new\" side should not jump around depending on whether the file was there already: the code is added, so it is on the right side.","createdAt":"2022-01-18T22:37:00Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/923#issuecomment-1015896498","viewerDidAuthor":false},{"id":"IC_kwDOC4j8g848jZWb","author":{"login":"dandavison"},"authorAssociation":"OWNER","body":"I believe that diffs adding multiple (large) new files are more common than PRs adding large blocks. If that's so, then I think there's an argument for new files being handled as a special case. So while I agree that I wouldn't want them in the left panel, I do wonder about disabling side-by-side entirely for new files.\r\n\r\n(Tangential, but I sometimes wonder about displaying new files with no background coloring at all, just syntax highlighting, and something like a thick green line down the left side to make it clear what one is looking at.) ","createdAt":"2022-01-18T23:04:20Z","includesCreatedEdit":true,"isMinimized":false,"minimizedReason":"","reactionGroups":[{"content":"THUMBS_UP","users":{"totalCount":1}}],"url":"https://github.com/dandavison/delta/issues/923#issuecomment-1015911835","viewerDidAuthor":true},{"id":"IC_kwDOC4j8g848kbZL","author":{"login":"citizenharris"},"authorAssociation":"NONE","body":"Disabling side-by-side for new/deleted files would work well, in my opinion. I love using Delta, it's is a fantastic tool and I appreciate this is a minor nitpick 😅 ","createdAt":"2022-01-19T08:09:19Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[{"content":"THUMBS_UP","users":{"totalCount":3}}],"url":"https://github.com/dandavison/delta/issues/923#issuecomment-1016182347","viewerDidAuthor":false}],"number":923,"title":"🚀 Don't show blank left side in side-by-side view for added files"},{"body":"Thank you so much for `delta`.\r\n\r\nIt would be great to have a platform independent package like Flatpak available [on Flathub](https://flathub.org/home).\r\n\r\nHave a wonderful day!","comments":[],"number":904,"title":"🚀 Flatpak package"},{"body":"There is a subtle behavior exhibited by delta, which one might never run into, but which I see constantly.\r\n\r\nRather than describe it in terms of my bespoke language and highlighter, imagine a file in Git-Flavored Markdown, which contains a long block of e.g. Javascript. Edits to the Javascript within a diff will be highlighted in terms of the basic Markdown syntax, rather than the \r\nJavascript subsyntax.\r\n\r\nThe brute solution to this is to parse the diff first, syntax highlight the complete document, then reconstruct the diff from the syntax highlighted document. This is... tractable, I think. \r\n\r\nGiven how syntect works, the brute solution might be the only solution. I'd venture that it qualifies as the right thing, and it would qualify as a modest but daily improvement in my work flow.\r\n\r\nIt's also wasted on many formats, and essential for some others. I'd imagine this should be configured on a per-format basis.\r\n\r\nAlas, my Rust is far below the level at which I could submit a proof of concept. I do have some experience with parser combinators if and when it comes time to rummage through a diff.\r\n","comments":[{"id":"IC_kwDOC4j8g8479WBj","author":{"login":"dandavison"},"authorAssociation":"OWNER","body":"Hi @mnemnion, thanks for this. The problem you describe is similar to https://github.com/dandavison/delta/issues/117 isn't it? (I'm also curious what the real scenario where you're hitting this is.) \r\n\r\nMy off-the-cuff reaction is that it would be rather a large change -- looking for files on disk and reading them and syntax highlighting them and thus obtaining the correct highlighting for the hunk fragments -- in return for a somewhat rare win.\r\n\r\nAlso, IMO, delta should always be very fast, since users are just sitting there staring at a prompt waiting for output, and I worry that such a change could damage performance.\r\n\r\nSomething to bear in mind also is that delta is a unix filter in the sense that it just reads stdin (and gitconfig) and writes to stdout. So the \"original files\" might not exist. Indeed someone might be piping entirely fictional diff hunks at delta! So the full-file highlighting would always have to fall back to fragment highlighting.\r\n\r\nAm I being pessimistic or missing some tricks? I don't want to say never, but if what I described above is accurate it sounds like a really big code change and I worry about performance.\r\n","createdAt":"2022-01-05T17:40:56Z","includesCreatedEdit":true,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/886#issuecomment-1005936739","viewerDidAuthor":true},{"id":"IC_kwDOC4j8g8479Z1z","author":{"login":"dandavison"},"authorAssociation":"OWNER","body":"Vague speculation: Maybe the way to architect such a thing would be to create an entirely new project named `syntect-server` or something, whose job is to watch files on disk and syntax highlight them, and expose an API for querying the highlighting at a given byte range in the file. Then the code change in delta could be small -- replacing the direct syntect library call with an IPC call to the syntect server -- and perhaps the IPC could be fast enough over a suitable local socket.\r\n\r\nI don't know much about LSP (Language Server Protocol) but my tentative conclusion from skimming things about it is that it doesn't or doesn't yet support syntax highlighting? If it did, then perhaps what I'm imagining is delta talking to a LSP server.","createdAt":"2022-01-05T18:02:29Z","includesCreatedEdit":true,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/886#issuecomment-1005952371","viewerDidAuthor":true},{"id":"IC_kwDOC4j8g848AuLQ","author":{"login":"mnemnion"},"authorAssociation":"NONE","body":"Thank you Dan, you raise a number of good points , particularly about complexity of implementation.\r\n\r\nI'm often surprised by how fast something like pretty-printing a megabyte of Lua table actually is. I mean preparing the string, streaming it to the tty is a bottleneck depending on the terminal.\r\n\r\nQuite right about the general case but I can imagine an implementation which is optimistic and still fairly simple. The diff has a short relative path for the file, generally; can we resolve this to the file itself? Very well, we could highlight from that with the line info. If not, there's no need to chase after the perfect in pursuit of the good.\r\n\r\nThis does involve more calls to the file system, and that can be quite slow indeed. It wouldn't be a step to take casually, and it isn't necessary for many languages, although the various mentions in #117 mark the problem as prevalent.\r\n\r\nI'm interested in the intersection of LSP support and syntax highlighting for my own reasons, so if you spot any discussion on here about it, please tag me in.","createdAt":"2022-01-06T18:35:25Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/886#issuecomment-1006822096","viewerDidAuthor":false},{"id":"IC_kwDOC4j8g848A1Pp","author":{"login":"dandavison"},"authorAssociation":"OWNER","body":"Perhaps what I said was out of date -- I believe that the LSP spec does now have a section relevant to syntax highlighting: https://microsoft.github.io/language-server-protocol/specification#textDocument_semanticTokens","createdAt":"2022-01-06T19:15:43Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/886#issuecomment-1006851049","viewerDidAuthor":true},{"id":"IC_kwDOC4j8g848nupR","author":{"login":"YodaEmbedding"},"authorAssociation":"NONE","body":"One lighter alternative to a full-fledged language server is **[treesitter](https://github.com/tree-sitter/tree-sitter)**.\r\n\r\nThe main purpose of treesitter is \"incremental parsing\" -- though the \"incremental\" bit isn't necessary for delta. I don't know if it's still light enough to handle a large amount of files with arbitrary languages. But it's a bit less complex and much, much faster than using LSP, which is going to be very slow to start up, and rather difficult to package and distribute with a small tool like delta. As a bonus, treesitter should correctly highlight nested language code (e.g. python nested within markdown).\r\n\r\nFor example, neovim can be configured to use treesitter for syntax highlighting. The plugin \"nvim-telescope\" uses treesitter to give syntax highlighting previews of files.","createdAt":"2022-01-20T02:06:28Z","includesCreatedEdit":true,"isMinimized":false,"minimizedReason":"","reactionGroups":[{"content":"THUMBS_UP","users":{"totalCount":4}}],"url":"https://github.com/dandavison/delta/issues/886#issuecomment-1017047633","viewerDidAuthor":false}],"number":886,"title":"🚀 Syntax highlighting of diffs should derive from the source file"},{"body":"The .deb packages don't seem to include the bash and zsh completions:\r\n\r\n```\r\n$ dpkg -c git-delta_0.11.3_amd64.deb \r\ndrwx------ root/root 0 2021-12-16 11:00 ./\r\ndrwxr-xr-x root/root 0 2021-12-16 11:00 ./usr/\r\ndrwxr-xr-x root/root 0 2021-12-16 11:00 ./usr/bin/\r\n-rwxr-xr-x root/root 5518912 2021-12-16 11:00 ./usr/bin/delta\r\ndrwxr-xr-x root/root 0 2021-12-16 11:00 ./usr/share/\r\ndrwxr-xr-x root/root 0 2021-12-16 11:00 ./usr/share/doc/\r\ndrwxr-xr-x root/root 0 2021-12-16 11:00 ./usr/share/doc/git-delta/\r\n-rw-r--r-- root/root 69847 2021-12-16 11:00 ./usr/share/doc/git-delta/README.md\r\n-rw-r--r-- root/root 1283 2021-12-16 11:00 ./usr/share/doc/git-delta/copyright\r\n```\r\n\r\nWould it be possible to include them?","comments":[],"number":877,"title":"🚀 Include completions in .deb packages "},{"body":"Sourcegraph has a CLI tool https://github.com/sourcegraph/src-cli. It can produce JSON output (and can also be used to submit GraphQL queries directly). An output format reminiscent of `rg --json` can be produced using `jq`:\r\n\r\n```\r\nsrc search --json my-pattern | jq -c \".Results[]\"\r\n```\r\n","comments":[],"number":860,"title":"🚀 Handle sourcegraph output, similarly to ripgrep and git grep"},{"body":"I'm exploring ways to further compact vertical space. As mentioned in #731 I'm revisiting not showing file entries at all. It may end up being a fools errand, but so far it seems to mainly works reasonably well for edits. What doesn't work well is that file-level changes are of course not shown at all. So far I've identified the below information elements (there may well be more) which are completely blocked from view when using the settings `file-style = omit` and `hunk-header-style = file line-number syntax`.\r\n\r\n* file rename (even worse/misleading with rename and changes combined)\r\n* submodule changes\r\n* execute bit changes\r\n\r\nAdditionally, the following elements are inferable but not exactly clear.\r\n\r\n* file addition (diff shows only added lines starting from line 1, would prefer explicit \"added: \"\r\n* file deletion (diff shows only deleted lines starting from line 0, would prefer explicit \"removed: \"\r\n\r\nWould it be straight forward in the state machine handling to make the full file-level content text available within the `hunk-header-style` config option, similar to how the `file` attribute currently includes just the filename? I'm just experimenting, but think that a configuration which I would like would be something like the following. The main tradeoff which I'm not sure how it'll pan out is that this would make things more compact for few (1-2) changes across many files, at the risk of possibly slightly increasing space used for many changes within a single file. That is at least compared to my current configuration of showing file header and using `hunk-header = omit` as I'm doing now.\r\n\r\nI'm roughly thinking something like the following, where `file-full` is the entire text content for what would be shown in the outer file header. I can't think of any case where it would be useful to use both `file` and `file-full`, but having the option may be beneficial.\r\n\r\n`hunk-header-style = file-full line-number syntax`\r\n\r\nIn order to have this be fully effective, I think delta would also need to emit meta-hunks of its own to provide the pure-file updates such as file renames, submodule updates, execute bit, etc.","comments":[{"id":"IC_kwDOC4j8g847HcNi","author":{"login":"dandavison"},"authorAssociation":"OWNER","body":"Thanks @mrjoel, I need to think about this proposal more but just wanted to mention that I am personally a\r\n```\r\n file-style = omit\r\n hunk-header-style = file line-number syntax\r\n```\r\nuser and so I definitely agree that there are some things that need fixing as you describe.","createdAt":"2021-12-11T23:51:55Z","includesCreatedEdit":true,"isMinimized":false,"minimizedReason":"","reactionGroups":[{"content":"THUMBS_UP","users":{"totalCount":1}}],"url":"https://github.com/dandavison/delta/issues/837#issuecomment-991806306","viewerDidAuthor":true},{"id":"IC_kwDOC4j8g847VORG","author":{"login":"dandavison"},"authorAssociation":"OWNER","body":"@mrjoel How far off would we be if we simply changed `file-style = omit` to mean\r\n\r\n> Omit the file change line in the common case of a modified file, but retain it in all other cases, including e.g. new files, removed files, submodules, etc.\r\n\r\nPersonally, I think this is what I want when I use `file-style=omit`.\r\n\r\n? I've pushed a branch that is intended to make that change https://github.com/dandavison/delta/pull/855","createdAt":"2021-12-16T04:03:19Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[{"content":"THUMBS_UP","users":{"totalCount":1}}],"url":"https://github.com/dandavison/delta/issues/837#issuecomment-995419206","viewerDidAuthor":true},{"id":"IC_kwDOC4j8g847WpzR","author":{"login":"mrjoel"},"authorAssociation":"NONE","body":"I'll think a bit more, but at first blush it seems to make it plenty workable for me. Perhaps be explicit in the definition that it omits the file change line if and only if there are one or more hunk header lines which are omitted for the noted file?\r\n\r\nOn the other hand, my proposed definition update would seem to cover my first group of examples, but not the second one which have a hunk header (exactly one each), for which the add/remove option is inferable but not explicit.\r\n\r\nThe main difference I think ends up being that your definition still results in not a file and hunk line for adds and removes, which likely is plenty workable. My only consideration to think more on offhand is interaction with navigation, where two navigation search hits will/may be present for adds and removes instead of always one per change.\r\n\r\nI'll try to build and test that branch today.","createdAt":"2021-12-16T13:00:50Z","includesCreatedEdit":true,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/837#issuecomment-995794129","viewerDidAuthor":false}],"number":837,"title":"🚀 Include option to expose file-level change as hunk"},{"body":"I'm thinking that we should make more effort to position certain pairs of lines at the same level, where that makes sense -- the first hunk here would be an example. Would you agree @th1000s?\r\n\r\n<table><tr><td><img width=600px src=\"https://user-images.githubusercontent.com/52205/144958760-2e360cc5-ab65-456d-9429-120d90f48516.png\" alt=\"image\" /></td></tr></table>\r\n\r\nIn terms of the current implementation, IIRC the issue is that `a` and `b` are not recognized as \"homologs\" because they are not deemed similar, according to a distance metric which is basically edit distance divided by length of longer string. ","comments":[],"number":832,"title":"🐛 Position more pairs of lines \"opposite\" each other in side-by-side view"},{"body":"It seems that a hunk header can occur within merge conflict markers:\r\n\r\n<table>\r\n<tr>\r\n<td>Raw git output</td>\r\n<td>Delta attempting to handle this</td>\r\n</tr>\r\n<tr>\r\n<td><img width=600px src=\"https://user-images.githubusercontent.com/52205/144730606-c45f0937-cad5-47ee-85bd-7f21e2102f52.png\" alt=\"image\" />\r\n</td>\r\n<td><img width=600px src=\"https://user-images.githubusercontent.com/52205/144730577-c0d22674-fa3b-4532-844d-231604da6d80.png\" alt=\"image\" />\r\n</td>\r\n</tr>\r\n</table>\r\n\r\n\r\nSee `etc/examples/822-hunk-header-within-merge-conflict.diff` and https://github.com/dandavison/delta/blob/8c900cb4d55c6c546c9853e7cddec89ecc67fdb7/src/handlers/hunk_header.rs#L35-L40","comments":[],"number":822,"title":"🐛 Better handling of hunk header within merge conflict"},{"body":"Example of a diff I generated today that represents the type of workload I care about the most for a tool like this: \r\n\r\nRaw git diff: \r\n\r\n```diff\r\ndiff --git i/csvselectcols w/csvselectcols\r\nindex 2d0fee0..7fe30bb 100755\r\n--- i/csvselectcols\r\n+++ w/csvselectcols\r\n@@ -7,20 +7,24 @@ def sanitize(s):\r\n cols = sys.argv[1:]\r\n idxs = []\r\n \r\n+def parse_header(cols, header_row):\r\n+ names = [n for n in cols if not n.isnumeric()]\r\n+ if len(names) > 0:\r\n+ if all(name in header_row for name in names):\r\n+ # provided colnames all check out\r\n+ idxs_ = [int(i) if i.isnumeric() else header_row.index(i) for i in cols]\r\n+ else:\r\n+ print (f\"Could not find one of the given colnames {str(names)} in header: {str(header_row)}\")\r\n+ exit()\r\n+ print(f\"indices derived: {idxs_}\")\r\n+ else:\r\n+ idxs_ = [int(x) for x in cols]\r\n+ return idxs_\r\n+\r\n header = True\r\n for row in csv.reader(sys.stdin):\r\n if header:\r\n- names = [n for n in cols if not n.isnumeric()]\r\n- if len(names) > 0:\r\n- if all(name in row for name in names):\r\n- # provided colnames all check out\r\n- idxs = [int(i) if i.isnumeric() else row.index(i) for i in cols]\r\n- else:\r\n- print (f\"Could not find one of the given colnames {str(names)} in header: {str(row)}\")\r\n- exit()\r\n- print(f\"idxs: {idxs}\")\r\n- else:\r\n- idxs = [int(x) for x in cols]\r\n+ idxs = parse_header(cols, row)\r\n \r\n print(\"\\t\".join([sanitize(row[i]) for i in idxs]))\r\n header = False\r\n```\r\n\r\n<img width=\"907\" alt=\"image\" src=\"https://user-images.githubusercontent.com/1542910/144551918-82d8c808-de6c-469c-b223-f6385ecde463.png\">\r\n\r\nNote that Delta kind of \"fails\" here because it is hampered by not being able to trace content that remained the same across line boundaries. \r\n\r\nI wonder if we could maybe add an option for dedicating more compute toward word diffs that we do but across the entire hunk? This would be potentially expensive but surely it is manageable if doing it across the entire input still runs okayishly fast for me.\r\n\r\nAm I being unfair on this by throwing in an indentation change? ","comments":[{"id":"IC_kwDOC4j8g846vhoe","author":{"login":"dandavison"},"authorAssociation":"OWNER","body":"Your diff is really clear -- nice work. I'd definitely like to have discussions like this about how delta can do better and take more interesting approaches. And yes, I see no reason in principle why we couldn't investigate having delta read in an entire hunk and process all hunk lines together. Currently, as you know, delta reads all lines in a \"subhunk\" (i.e. a sequence of minus and plus lines, unbroken by any zero lines: https://github.com/dandavison/delta/blob/master/ARCHITECTURE.md#handling-diff-hunk-lines\r\n\r\nFor this particular diff, what does it look like with `diff -w` and `diff -w --color-moved`?","createdAt":"2021-12-03T13:51:36Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/820#issuecomment-985537054","viewerDidAuthor":true},{"id":"IC_kwDOC4j8g846vny_","author":{"login":"dandavison"},"authorAssociation":"OWNER","body":"Incidentally, you inspired me to also investigate more minimal diff styles in delta. I was experimenting with using underline for the unchanged parts of lines. But I haven't yet figure out a nice way in the code to remove the underline from (leading) whitespace. OTOH perhaps it's hideous :)\r\n\r\n<table><tr><td><img width=600px src=\"https://user-images.githubusercontent.com/52205/144618268-f3a1eb01-fe6c-4544-a8f6-e7f15b0d62b6.png\" alt=\"image\" /></td></tr></table>\r\n\r\n```gitconfig\r\n minus-non-emph-style = ul\r\n plus-non-emph-style = syntax ul\r\n```","createdAt":"2021-12-03T14:25:36Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[{"content":"HEART","users":{"totalCount":2}}],"url":"https://github.com/dandavison/delta/issues/820#issuecomment-985562303","viewerDidAuthor":true},{"id":"IC_kwDOC4j8g846vone","author":{"login":"dandavison"},"authorAssociation":"OWNER","body":"But your diff above really emphasizes that there are interesting avenues to explore in delta involving \"squashed diffs\" (https://github.com/dandavison/delta/issues/152) and hunk rearrangements. How's your Rust? :)","createdAt":"2021-12-03T14:30:18Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/820#issuecomment-985565662","viewerDidAuthor":true},{"id":"IC_kwDOC4j8g846xjMc","author":{"login":"unphased"},"authorAssociation":"NONE","body":"I cannot conceive of a better reason to learn Rust! It will take some time to get up to speed, but I think a confluence of forces are taking shape for me on this front. I have at least one other person on my team at work (small startup) who is interested in Rust, and I also expect I will want to build some portions of my next big personal project in it. Plus this that's 3 good reasons to really get into it this time around.\n\nI'll also point out that there is an aspect that is poor about the diff that I used in my example above. Note how both the vanilla diff and delta (which is constrained to its output structure on a line basis) have identified the unchanged region \n\n```\nheader = True\n for row in csv.reader(sys.stdin):\n if header:\n```\n\nas unchanged while *my diff actually treats this region as a removal and addition!*. Since it's being treated by my diff as a move (which it knows not how to detect, let alone indicate as a move), it is suffering from the same issue of being shown to the user in a duplicated way, even though it is unchanged! Now, code moves realistically speaking would always be shown in duplicate, but it's rather important at least to indicate them. note that git's move detection cannot activate if any changes show up in the moved code (and the zebra feature acts on line boundaries, which in my eyes is only mildly better than nothing). \n\nTherefore I think this example that I gave inadvertently demonstrates yet another class of deficiency in diffs, that for many practical diffs it would be nice to be able to do a 2nd level meta diff in it. ","createdAt":"2021-12-04T18:00:15Z","includesCreatedEdit":true,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/820#issuecomment-986067740","viewerDidAuthor":false},{"id":"IC_kwDOC4j8g846xkNE","author":{"login":"dandavison"},"authorAssociation":"OWNER","body":"> I cannot conceive of a better reason to learn Rust! It will take some time to get up to speed,\r\n\r\nIncidentally, I can really highly recommend the O'Reilly book [Programming Rust](https://www.amazon.com/_/dp/1492052590?tag=oreilly20-20) by Jim Blandy and Jason Orendorff. It's enjoyable to read, and is pitched at experienced programmers, often explicitly explaining Rust in the context of C++ (not that I know C++ well myself). The best programming language book I've ecountered.","createdAt":"2021-12-04T18:26:06Z","includesCreatedEdit":true,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/820#issuecomment-986071876","viewerDidAuthor":true},{"id":"IC_kwDOC4j8g846x5Wn","author":{"login":"unphased"},"authorAssociation":"NONE","body":"Thanks for the rec!!","createdAt":"2021-12-05T03:13:36Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[{"content":"THUMBS_UP","users":{"totalCount":1}}],"url":"https://github.com/dandavison/delta/issues/820#issuecomment-986158503","viewerDidAuthor":false}],"number":820,"title":"🐛 Lackluster in diff hunks that have both code changes and indentation changes"},{"body":"I noticed that when I set the \r\n\r\n```conf\r\n[delta \"decorations\"]\r\n commit-style = yellow bold\r\n commit-decoration-style = bold yellow box ul\r\n```\r\n\r\nsettings, the entire commit line becomes yellow. Including any indicators for HEAD, local or remote branch names.\r\n\r\nI would like these to be made visually distinct for easier reading. I noticed that it's possible to use `--pretty=format` here. \r\n\r\nI have tried using this format which I directly copied out of my short git graph log configuration: `--pretty=format:'%C(bold magenta)%h%Creset -%C(auto)%d%Creset %s %Cgreen%ci %C(yellow)(%cr) %C(bold blue)<%an>%Creset'`\r\n\r\nAnd it looks like:\r\n\r\n<img width=\"977\" alt=\"image\" src=\"https://user-images.githubusercontent.com/1542910/144266038-2ea5aa1a-9a06-43a0-8d14-17ace60f1d51.png\">\r\n\r\nThis works, but completely overrides delta's configured commit styles.\r\n\r\nI feel like in the past I had this working prior to discovering Delta, but now I wonder if I may be mistaken about that and i always just had them yellow. \r\n\r\nAnyways, since it overrides, there is no way to configure the colors precisely this way and gain the benefits of Delta's styling such as boxes. Let's say I wanted box decoration. I don't, to save space, but somebody might. \r\n\r\nIn the meantime (and in the future I reckon) I will use it like I have it now with `--pretty=format` but tweaked a bit (needs more yellow) to suit my needs. This ticket is regarding whether to do anything about the intersection between git's styling and Delta's styling. ","comments":[{"id":"IC_kwDOC4j8g846xZ4W","author":{"login":"dandavison"},"authorAssociation":"OWNER","body":"Is the following an accurate summary?\r\n\r\n- `commit-style = raw` allows git's raw colors for commit SHA, HEAD, local, and remote branch names to be displayed by delta\r\n- But, it prevents us from having delta's commit decorations\r\n\r\nThis ticket calls for the two things to be possible in conjunction.","createdAt":"2021-12-04T13:44:29Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/816#issuecomment-986029590","viewerDidAuthor":true},{"id":"IC_kwDOC4j8g846yU10","author":{"login":"unphased"},"authorAssociation":"NONE","body":"Thank you for summarizing!\n\nI am not certain that the first bullet is entirely the case. Is raw the default? I seem to recall from my testing that when I made git emit colors that these git colors overrode, even when the delta commit-style was set. ","createdAt":"2021-12-05T17:41:23Z","includesCreatedEdit":true,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/816#issuecomment-986271092","viewerDidAuthor":false},{"id":"IC_kwDOC4j8g846yZWX","author":{"login":"dandavison"},"authorAssociation":"OWNER","body":"Yep, raw is the default\r\n\r\n```\r\n~ delta --no-gitconfig --show-config | grep commit-style\r\n commit-style = raw\r\n```\r\n\r\nand I believe it works; try `git show --color=always --decorate | delta --no-gitconfig`\r\n\r\n<table><tr><td><img width=600px src=\"https://user-images.githubusercontent.com/52205/144761406-eb937ffa-b864-4993-b23a-a2b13660be27.png\" alt=\"image\" /></td></tr></table>\r\n\r\n(I found that `git show` doesn't emit the decorated refs if it's output is redirected to a pipe unless we pass `--decorate`)","createdAt":"2021-12-05T19:51:13Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/816#issuecomment-986289559","viewerDidAuthor":true},{"id":"IC_kwDOC4j8g85BkXFD","author":{"login":"sebszyller"},"authorAssociation":"NONE","body":"I've run into a similar issue. It looks like there's some discrepancy between how the colours are handled for `git show` and `git log`.\r\nI've been debugging it for a while, and it seems that there's an issue with how delta is used __from__ git, and not with the git+delta combination on its own.\r\n\r\nFormat string:\r\n`--pretty=format:\" %Cred%h%Creset -%C(yellow)%d%Creset %s %Cgreen(%cr) %C(bold blue)<%an>%Creset\"`\r\n\r\n### Case 1 (pipe `git show` to `delta`) - works as desired:\r\n`git show --color=always --decorate --pretty=format:\" %Cred%h%Creset -%C(yellow)%d%Creset %s %Cgreen(%cr) %C(bold blue)<%an>%Creset\" | delta --no-gitconfig`\r\n\r\n<img width=\"640\" alt=\"works\" src=\"https://user-images.githubusercontent.com/11989990/163564719-59b4319f-530b-44aa-8d98-085a9ffa139e.png\">\r\n\r\n### Case 2 (don't pipe `git show` manually; rely on automatic formatting) - no colour but format is fine:\r\n`git show --color=always --decorate --pretty=format:\" %Cred%h%Creset -%C(yellow)%d%Creset %s %Cgreen(%cr) %C(bold blue)<%an>%Creset\"`\r\n\r\n<img width=\"640\" alt=\"doesnt\" src=\"https://user-images.githubusercontent.com/11989990/163565064-a1bebd37-40bd-4476-bb3e-f1574accd5cd.png\">\r\n\r\n### Case 3 (don't pipe `git log -p`manually; rely on automatic formatting) - works as desired:\r\n`git log -p --pretty=format:\"%Cred%h%Creset -%C(yellow)%d%Creset %s %Cgreen(%cr) %C(bold blue)<%an>%Creset\"`\r\n\r\n<img width=\"640\" alt=\"works-p\" src=\"https://user-images.githubusercontent.com/11989990/163565191-d13ac42a-7439-47f7-9f88-1dddd3714b08.png\">\r\n\r\nTLDR; I would like `git show` to use the formatting string correctly, just like `git log` does.\r\n\r\nI'm using a very basic configuration in `.gitconfig`:\r\n```\r\n[core]\r\n pager = delta\r\n\r\n[interactive]\r\n diffFilter = delta --color-only\r\n\r\n[delta]\r\n navigate = true # use n and N to move between diff sections\r\n side-by-side = true\r\n\r\n[merge]\r\n conflictstyle = diff3\r\n\r\n[diff]\r\n colorMoved = default\r\n```\r\n","createdAt":"2022-04-15T11:26:17Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/816#issuecomment-1100050755","viewerDidAuthor":false}],"number":816,"title":"🚀 Colorization of commit header?"},{"body":"cc @th1000s Although delta tries, it's not always possible for it to identify the process (e.g. `grep`/`blame`/`git show` etc) responsible for generating its input. This is because when one does `grep pattern file.txt | delta`, the grep process may exit before delta interrogates the running system processes. (That outcome is somewhat less likely when one does `grep pattern large_codebase/**/*.rs`).\r\n\r\nI suggest adding a command line option allowing users to do things like `grep -n pattern file.txt | head -n 100 | delta --input-command 'grep -n'`.\r\n\r\nIn terms of implementation, the parent process is cached on first call via [`lazy_static`](https://github.com/dandavison/delta/blob/8ff50afccb1d065b105db83eda19341c3458f964/src/utils/process.rs#L28-L30), and so we will need to find some way of getting the user options to that call.","comments":[{"id":"IC_kwDOC4j8g846YItq","author":{"login":"bew"},"authorAssociation":"NONE","body":"> Although delta tries, it's not always possible for it to identify the process responsible for generating its input.\r\n\r\nWhy would delta need to identify that process? ","createdAt":"2021-11-25T18:07:34Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/799#issuecomment-979405674","viewerDidAuthor":false},{"id":"IC_kwDOC4j8g846YMRD","author":{"login":"dandavison"},"authorAssociation":"OWNER","body":"Delta does this for a few reasons now:\r\n\r\n- To syntax highlight output from `git grep`, `rg`, etc. https://github.com/dandavison/delta/blob/master/src/handlers/grep.rs#L378\r\n standard `$file$sep$linenum$sep$code` grep output is for humans -- it cannot be parsed unambiguously -- and so delta only risks trying to parse it if it has reason to believe that it is receiving grep output (however, `rg --json` is highlighted without process inspection)\r\n- To syntax highlight code from `git show $revision:/path/to/file.ext`. Since this \"code\" is arbitrary bytes, delta needs to look at the input command to know that it should be doing this, and what the language is. https://github.com/dandavison/delta/blob/master/src/handlers/git_show_file.rs#L12\r\n- Similarly, to determine the language for syntax highlighting `git blame` output, since the file path with extension is not present in blame output https://github.com/dandavison/delta/blob/master/src/handlers/blame.rs#L80\r\n\r\nIt does violate compositional purity of a unix pipeline! But delta is always the end of a pipeline -- delta output is for humans -- and I think the benefits of doing this win out.","createdAt":"2021-11-25T18:44:22Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[{"content":"THUMBS_UP","users":{"totalCount":2}}],"url":"https://github.com/dandavison/delta/issues/799#issuecomment-979420227","viewerDidAuthor":true},{"id":"IC_kwDOC4j8g846dXRH","author":{"login":"th1000s"},"authorAssociation":"COLLABORATOR","body":"That would mean typing a lot characters twice (or knowing your shells `Ctrl-K` / `Ctrl-Y` tricks). What about making delta a wrapper for itself, e.g. `delta --pipe grep -n pattern file.txt | head -n 100 | delta` to remove the redundancy (delta-delta notwithstanding)?\r\n\r\nThe command line could be passed via some IPC mechanism, or by looking for other delta processes and just waiting log enough if the started `grep` child process was too fast.","createdAt":"2021-11-27T18:02:30Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/799#issuecomment-980776007","viewerDidAuthor":false},{"id":"IC_kwDOC4j8g846dbTw","author":{"login":"dandavison"},"authorAssociation":"OWNER","body":"> That would mean typing a lot characters twice (or knowing your shells `Ctrl-K` / `Ctrl-Y` tricks). What about making delta a wrapper for itself\r\n\r\nI'm actually not sure that ergonomics/convenience needs to be a goal here. For that we have `git grep` and `rg --json`, and (without wishing to stray onto controversial ground) I think that between them those two options give users pretty much all the code searching functionality and speed they could want.\r\n\r\nSo here what I had in mind was more \"making it possible, if inconvenient, to do things with 100% correctness\", such as pipe `grep/ag/ack` into delta. I was thinking this feature would allow the small number of people who care about doing this to write wrapper shell scripts to overcome the lack of convenience.\r\n\r\nIt probably also came to mind because I was imagining the implementation would be quite simple, just applying the same parsing code to the CLI option before doing so to the strings obtained from sysinfo.","createdAt":"2021-11-27T19:55:01Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/799#issuecomment-980792560","viewerDidAuthor":true},{"id":"IC_kwDOC4j8g85AOsgS","author":{"login":"Saklad5"},"authorAssociation":"NONE","body":"Would it be worthwhile to ask Git itself to add a method of passing contextual information to the pager it invokes by way of environment variable?\r\n\r\nThat is, do you think it'd be a good idea if I looked into making that happen?","createdAt":"2022-03-24T12:51:05Z","includesCreatedEdit":false,"isMinimized":true,"minimizedReason":"RESOLVED","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/799#issuecomment-1077594130","viewerDidAuthor":false},{"id":"IC_kwDOC4j8g85AOvQz","author":{"login":"Saklad5"},"authorAssociation":"NONE","body":"Wait, Git already prepends this information doesn't it?","createdAt":"2022-03-24T13:04:11Z","includesCreatedEdit":false,"isMinimized":true,"minimizedReason":"RESOLVED","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/799#issuecomment-1077605427","viewerDidAuthor":false},{"id":"IC_kwDOC4j8g85APT2y","author":{"login":"dandavison"},"authorAssociation":"OWNER","body":"Hi @Saklad5,\r\n\r\nLooking at the output of `git -c core.pager=env show` (don't be tempted to pipe it to `grep`!), the env vars that git sets for the child process appear to be:\r\n\r\n```\r\nGIT_CONFIG_PARAMETERS='core.pager'='env'\r\nGIT_EXEC_PATH=/usr/local/Cellar/git/2.35.1/libexec/git-core\r\nGIT_PREFIX=\r\n```\r\n\r\ndelta already makes use of `GIT_CONFIG_PARAMETERS` (so that `-c delta.foo=bar` works) and `GIT_PREFIX` (it contains the path to where git was invoked inside the repo, which delta uses to relativize paths).\r\n\r\n> That is, do you think it'd be a good idea if I looked into making that happen?\r\n\r\nI believe that it would be helpful to delta and other git pagers if git were to set an env var containing (a suitable encoding of) the entire command line with which it was invoked. If git developers wanted to do that, l think I'd be happy about it!\r\n\r\nIncidentally, delta development has come across some other areas where perhaps there's room for improvement in git. They both relate to `git diff`. Firstly it doesn't handle shell process substitution syntax https://github.com/dandavison/delta/issues/666:\r\n\r\n```\r\n$ git diff <(echo a) <(echo b)\r\nerror: /dev/fd/11: unsupported file type\r\nfatal: cannot hash /dev/fd/11\r\n```\r\n\r\nSecondly is it a bit odd that the output of `git diff /tmp/a /tmp/b` (files outside repo) is the same as `git diff tmp/a tmp/b` (files inside repo) https://github.com/dandavison/delta/issues/1014?\r\n\r\n```\r\n$ git -P diff /tmp/a /tmp/b\r\ndiff --git a/tmp/a b/tmp/b\r\nindex 7898192..6178079 100644\r\n--- a/tmp/a\r\n+++ b/tmp/b\r\n```\r\n\r\n```\r\n$ diff <(git diff --no-index /tmp/a /tmp/b) <(git -P diff --no-index tmp/a tmp/b); echo $?\r\n0\r\n``` ","createdAt":"2022-03-24T15:27:37Z","includesCreatedEdit":true,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/799#issuecomment-1077755314","viewerDidAuthor":true},{"id":"IC_kwDOC4j8g85APhDD","author":{"login":"Saklad5"},"authorAssociation":"NONE","body":"> Incidentally, delta development has come across some other areas where perhaps there's room for improvement in git. They both relate to `git diff`. Firstly it doesn't handle shell process substitution syntax #666:\r\n> \r\n> ```\r\n> $ git diff <(echo a) <(echo b)\r\n> error: /dev/fd/11: unsupported file type\r\n> fatal: cannot hash /dev/fd/11\r\n> ```\r\n> \r\n> Secondly is it a bit odd that the output of `git diff /tmp/a /tmp/b` (files outside repo) is the same as `git diff tmp/a tmp/b` (files inside repo) #1014?\r\n> \r\n> ```\r\n> $ git -P diff /tmp/a /tmp/b\r\n> diff --git a/tmp/a b/tmp/b\r\n> index 7898192..6178079 100644\r\n> --- a/tmp/a\r\n> +++ b/tmp/b\r\n> ```\r\n> \r\n> ```\r\n> $ diff <(git diff --no-index /tmp/a /tmp/b) <(git -P diff --no-index tmp/a tmp/b); echo $?\r\n> 0\r\n> ```\r\n\r\nTo support file descriptors properly, Git would need to read through them in a single pass. I'm not sure how easy that would be.\r\n\r\nAs for passing the entire command line, that seems a bit heavy-handed and insecure: most people probably wouldn't expect a pager to get all that. I hid those comments because I actually think it already provides this functionality in a form Delta could use: you can even take over the entire command from Git and control the internals yourself as an \"external diff driver\".","createdAt":"2022-03-24T16:26:31Z","includesCreatedEdit":true,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/799#issuecomment-1077809347","viewerDidAuthor":false},{"id":"IC_kwDOC4j8g85APnrL","author":{"login":"dandavison"},"authorAssociation":"OWNER","body":"> To support file descriptors properly, Git would need to read through them in a single pass. I'm not sure how easy that would be.\r\n\r\nThere have been two patches submitted to git development lists that superficially seem to do this. One of them is here: https://marc.info/?l=git&m=141347274420939&w=2 (see links from #666)\r\n\r\n> I actually think it already provides this functionality in a form Delta could use: you can even take over the entire command from Git and control the internals yourself as an \"external diff driver\".\r\n\r\nIf you have time to expand this proposal that would be great. I've been meaning to learn more about that but have not done so yet. One thing to note is that delta handles `git diff`, `git grep`, `git blame`, `git show`, `git log` etc output. ","createdAt":"2022-03-24T16:56:24Z","includesCreatedEdit":true,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/799#issuecomment-1077836491","viewerDidAuthor":true},{"id":"IC_kwDOC4j8g85APpbD","author":{"login":"dandavison"},"authorAssociation":"OWNER","body":"> the env vars that git sets for the child process appear to be:\r\n\r\n`GIT_PID` would be quite nice to have; we have already solved the problem of finding the git process and its command line, but it would be simpler with the pid.","createdAt":"2022-03-24T17:04:21Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/799#issuecomment-1077843651","viewerDidAuthor":true},{"id":"IC_kwDOC4j8g85APpld","author":{"login":"Saklad5"},"authorAssociation":"NONE","body":"Git has two broad types of commands: \"porcelain\" (for humans) and \"plumbing\" (for machines). Porcelain commands are almost exclusively wrappers around plumbing commands, and plumbing commands allow you to do pretty much anything as you see fit.\r\n\r\nUsing [`GIT_EXTERNAL_DIFF`][1] basically overrides the normal `git diff` wrapper, passing all the input it usually gets for use as you see fit. As a bonus, the plumbing commands are specifically designed to be _extremely_ stable between Git versions, so you don't have to worry about building a house of cards if you use them.\r\n\r\n[1]: https://git-scm.com/docs/git#Documentation/git.txt-codeGITEXTERNALDIFFcode","createdAt":"2022-03-24T17:05:07Z","includesCreatedEdit":true,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/799#issuecomment-1077844317","viewerDidAuthor":false},{"id":"IC_kwDOC4j8g85APtVI","author":{"login":"dandavison"},"authorAssociation":"OWNER","body":"OK, but which application would compute the diff if not git? ","createdAt":"2022-03-24T17:21:55Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/799#issuecomment-1077859656","viewerDidAuthor":true},{"id":"IC_kwDOC4j8g85APu1n","author":{"login":"Saklad5"},"authorAssociation":"NONE","body":"> OK, but which application would compute the diff if not git?\r\n\r\nThat's the thing: `git diff` is just a wrapper for the low-level commands, and it is outright encouraged for tools like Delta to run them directly. Take a look at [this guide on your choices][1].\r\n\r\n[1]: https://git-scm.com/docs/diff-format\r\n\r\nThe basic idea here is that Delta gets configured as an external diff driver, and proceeds to run the low-level Git commands it needs to do what it wants. This also stops Git from doing unnecessary work like the usual formatting.","createdAt":"2022-03-24T17:28:48Z","includesCreatedEdit":true,"isMinimized":false,"minimizedReason":"","reactionGroups":[{"content":"THUMBS_UP","users":{"totalCount":1}}],"url":"https://github.com/dandavison/delta/issues/799#issuecomment-1077865831","viewerDidAuthor":false},{"id":"IC_kwDOC4j8g86G7idG","author":{"login":"dgudim"},"authorAssociation":"NONE","body":"Just stumbled upon the same issue. Can this behavior be tweaked somehow?","createdAt":"2024-08-01T18:55:40Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/799#issuecomment-2263754566","viewerDidAuthor":false}],"number":799,"title":"🚀 Add --input-command option to tell delta the command line responsible for input"},{"body":"I used ``--show-themes`` on a repo where the last commit was a merge commit and got an empty pager instead of any output. I think delta should either detect that or mimic ``--show-syntax-themes`` behavior by using a default diff instead.","comments":[],"number":797,"title":"🐛 Use default diff for --show-themes like --show-syntax-themes"},{"body":"I think it would be nice not to apply the underline to the leading whitespace here:\r\n\r\n<table><tr><td><img width=500px src=\"https://user-images.githubusercontent.com/52205/142883838-7a234fbd-bf03-4639-b77a-d46b55884434.png\" alt=\"image\" /></td></tr></table>","comments":[],"number":787,"title":"🐛 Don't apply underline and strike-through to leading whitespace"},{"body":"I'm trying to show CRLF line endings in my diffs (on Linux, to quickly spot if someone committed a file with CRLF instead of LF). Less has the option `-u/--underline-special` to do just that, so I could just use that as pager for delta. However, delta _always_ seems to strip the carriage return byte from diffs, see:\r\n\r\n\r\n\r\nHere is a hexdump of both diffs. You can see the CR-bytes (0x0d) are missing.\r\n\r\n\r\n\r\nEven if delta strips the ANSI color escape codes (which is turned off here with `--raw`), it should never just delete any other character from the output. Let the pager decide to show those control chars or not.","comments":[{"id":"IC_kwDOC4j8g845CcN-","author":{"login":"dandavison"},"authorAssociation":"OWNER","body":"Thanks @plgruener. Do you have time to look at https://github.com/dandavison/delta/pull/664 and help me decide what the correct course of action is? In that PR, code was added that deliberately strips trailing CR. cc @norisio in case you have time to advise also.","createdAt":"2021-11-02T00:01:15Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/754#issuecomment-956941182","viewerDidAuthor":true},{"id":"IC_kwDOC4j8g84-xo1u","author":{"login":"yoichi"},"authorAssociation":"CONTRIBUTOR","body":"https://github.com/dandavison/delta/pull/664 is not the only cause. byte_lines may also strip CR.\r\nThe correct course will be\r\n\r\n* prevent byte_lines removing CR\r\n* strip CR only if delta writes to console","createdAt":"2022-02-27T06:00:37Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[{"content":"THUMBS_UP","users":{"totalCount":1}}],"url":"https://github.com/dandavison/delta/issues/754#issuecomment-1053199726","viewerDidAuthor":false},{"id":"IC_kwDOC4j8g84-yBtN","author":{"login":"yoichi"},"authorAssociation":"CONTRIBUTOR","body":"> strip CR only if delta writes to console\r\n\r\nI've tried this by applying sample code in https://rosettacode.org/wiki/Check_output_device_is_a_terminal#Rust\r\nBut it didn't work with `git add -p`.\r\n\r\nTo find a solution, I think it would be better if I understand the cause of https://github.com/dandavison/delta/pull/664 a little more.\r\n\r\n> CR will be emitted directly into a terminal (at least when delta used through git add -p). Thus the rendered result will be blank (CR erases the line).\r\n\r\nThis (=CR erases the line) does not happen with the default pager. Why does this happen with delta?","createdAt":"2022-02-27T07:35:44Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/754#issuecomment-1053301581","viewerDidAuthor":false},{"id":"IC_kwDOC4j8g84-y938","author":{"login":"dandavison"},"authorAssociation":"OWNER","body":"> This (=CR erases the line) does not happen with the default pager. Why does this happen with delta?\n\nI think this is because:\n\nSuppose we have a line ending with CR LF.\n\nGit changes that to CR ANSI LF.\n\nWith delta, bytelines strips the LF but leaves the CR (due to ANSI escape added by git). So now the line ends with CR ANSI *but no LF*. I think this causes the line to be overwritten by the terminal emulator.\n\nWhereas with the usual pager the line ends CR ANSI LF.\n","createdAt":"2022-02-27T12:56:34Z","includesCreatedEdit":true,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/754#issuecomment-1053548028","viewerDidAuthor":true},{"id":"IC_kwDOC4j8g84-6MK_","author":{"login":"yoichi"},"authorAssociation":"CONTRIBUTOR","body":"> This (=CR erases the line) does not happen with the default pager. Why does this happen with delta?\r\n\r\nI found right_fill_background_color's output overwrites the text before CR.\r\nWithout interactive.diffFilter, there is only reset (ESC[m) after CR, the text before CR remains intact.\r\n\r\n> I've tried this by applying sample code in https://rosettacode.org/wiki/Check_output_device_is_a_terminal#Rust\r\n> But it didn't work with git add -p.\r\n\r\n`git add -p` (git-add--interactive.perl) sends diff to pipe (not directly to the terminal) then print it.\r\nSo the terminal detection did not work.\r\n`git diff` with delta send output to `less --RAW-CONTROL-CHARS`, and less replaces control characters with \"^%c\" (the caret notation), but the feature is effective only for terminal output (https://github.com/gwsw/less/blob/4f5e45b4262009c6fcd87c0efc077725271c8c57/main.c#L222). Therefore it is not usable with `git add -p`.\r\n\r\nI think one solution is to define delta's new command line option to replace control characters by caret notations (like `less --RAW-CONTROL-CHARS` on terminal) and use the option in the interactive.diffFilter value.","createdAt":"2022-03-01T13:26:07Z","includesCreatedEdit":true,"isMinimized":false,"minimizedReason":"","reactionGroups":[{"content":"THUMBS_UP","users":{"totalCount":1}}],"url":"https://github.com/dandavison/delta/issues/754#issuecomment-1055441599","viewerDidAuthor":false},{"id":"IC_kwDOC4j8g84_Dh6K","author":{"login":"yoichi"},"authorAssociation":"CONTRIBUTOR","body":"> I think one solution is to define delta's new command line option to replace control characters by caret notations (like `less --RAW-CONTROL-CHARS` on terminal) and use the option in the interactive.diffFilter value.\r\n\r\nI've made a fix in this way and created a pull request. Would you please take a look? @norisio @dandavison \r\nhttps://github.com/dandavison/delta/pull/1000","createdAt":"2022-03-03T10:16:08Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/754#issuecomment-1057889930","viewerDidAuthor":false},{"id":"IC_kwDOC4j8g84_G_no","author":{"login":"dandavison"},"authorAssociation":"OWNER","body":"Is it true that the problem is occurring because\r\n\r\n(1) git is placing an ANSI character between CR and LF: `CR ANSI LF`\r\n(2) bytelines is stripping the LF, leaving `CR ANSI`\r\n\r\n?\r\n\r\nIf so, would one solution be for delta to strip trailing CR *if* it is followed by the trailing ANSI character? Presumably that would be very rare in real input.\r\n\r\nIn any case, delta's output is for humans to look at, not for machines to read, so it's not the end of the world if we occasionally remove a byte someone wanted as long as it really is rare.","createdAt":"2022-03-04T03:45:15Z","includesCreatedEdit":true,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/754#issuecomment-1058798056","viewerDidAuthor":true},{"id":"IC_kwDOC4j8g84_IZK_","author":{"login":"norisio"},"authorAssociation":"CONTRIBUTOR","body":"> git is placing an ANSI character between CR and LF\r\n\r\nOnly when used with `-p`, according to the images in https://github.com/dandavison/delta/issues/754#issue-1039048806, which show there are no CR-ANSI-LF .","createdAt":"2022-03-04T13:31:23Z","includesCreatedEdit":true,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/754#issuecomment-1059164863","viewerDidAuthor":false},{"id":"IC_kwDOC4j8g84_Iaj-","author":{"login":"norisio"},"authorAssociation":"CONTRIBUTOR","body":"Therefore this issue is not related to the CR-ANSI-LF problem, I guess.\r\nSimply because using _bytelines_ to split the input stream. It [always erases CR before LF](https://github.com/whitfin/bytelines/blob/6eccd7fb3c86e538397e39b60599b6c704e90ce3/src/lib.rs#L126-L132).","createdAt":"2022-03-04T13:39:19Z","includesCreatedEdit":true,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/754#issuecomment-1059170558","viewerDidAuthor":false},{"id":"IC_kwDOC4j8g84_Ifz_","author":{"login":"dandavison"},"authorAssociation":"OWNER","body":"> Only when used with `-p`\r\n\r\nThanks!\r\n\r\n> Therefore this issue is not related to the CR-ANSI-LF problem\r\n\r\nRight. OK, so:\r\n\r\nI think it is correct that delta's internal code paths work with a stripped line. So maybe the solution is we update bytelines so that it does not strip the line endings, or strips them but returns them to us with the line. Then, when delta is ready to print a line, it adds back the original line ending.\r\n\r\nI do think it's worth bearing in mind that delta's output is for humans to look at, not for machines to parse: if you want machine-readable diff output then that's delta's *input*, not its output. And indeed, if you redirect git's output into a pipe or file, then delta doesn't even get invoked (git doesn't invoke `core.pager`). \r\n\r\nHOWEVER:\r\n\r\n1. It seems a reasonable goal that delta prettifies a line with ANSI colors but nevertheless retains the original line ending\r\n2. delta has `--raw`, and it is very reasonable to expect that to retain the line endings even if delta didn't by default.","createdAt":"2022-03-04T14:06:43Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[{"content":"THUMBS_UP","users":{"totalCount":3}}],"url":"https://github.com/dandavison/delta/issues/754#issuecomment-1059192063","viewerDidAuthor":true},{"id":"IC_kwDOC4j8g85thU_m","author":{"login":"Atemu"},"authorAssociation":"NONE","body":"What is the status on this?\r\n\r\n> it's worth bearing in mind that delta's output is for humans to look at, not for machines to parse\r\n\r\nThis is true but us humans also need to understand the output. If it show a line removed but the same line added again, that's extremely confusing.\r\n\r\nYou might be able to deduce it's due to line endings but then you're left wondering what changed about line endings. \r\nWere they the correct ones but aren't anymore? The other way around? No idea, all you see is the same characters.\r\n\r\nLine endings are already complex enough in git as is.","createdAt":"2023-12-03T11:40:01Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/754#issuecomment-1837453286","viewerDidAuthor":false}],"number":754,"title":"🐛 CRLF line endings are stripped from diff"},{"body":"If there are raw tabs in the output in side-by-side mode, then the second (plus) column isn't well aligned:\r\n<img width=\"768\" alt=\"Screen Shot (bad)\" src=\"https://user-images.githubusercontent.com/7074165/139111945-36bd505b-39fe-4875-ae80-c776db6b1bc4.png\">\r\nIt should instead look like this:\r\n<img width=\"765\" alt=\"Screen Shot (good)\" src=\"https://user-images.githubusercontent.com/7074165/139112111-7ae4041b-5f61-49c4-91c1-3d146c4eebcf.png\">\r\nThis is related to #729, but comes from a different part of the code ([`ansi::measure_text_width()`](https://github.com/dandavison/delta/blob/081eb60299a0f75670f8397e58ed6c05417747b4/src/ansi/mod.rs#L21-L24)).","comments":[{"id":"IC_kwDOC4j8g844-HmB","author":{"login":"th1000s"},"authorAssociation":"COLLABORATOR","body":"Note that using `--tabs` like this is documented to possibly not work. The side-by-side mode could exit with an error here, or assume that however uses it like that knows what they are doing, such as their own postprocessing.\r\n\r\n> Use --tabs=0 to pass tab characters through directly,\r\n> but note that in that case delta will calculate line widths assuming tabs occupy one character's width on\r\n> the screen: **if your terminal renders tabs as more than than one character wide** then delta's output will **look\r\n> incorrect**. ","createdAt":"2021-10-31T23:06:49Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/750#issuecomment-955808129","viewerDidAuthor":false},{"id":"IC_kwDOC4j8g844-l-k","author":{"login":"dhduvall"},"authorAssociation":"NONE","body":"Right; there's no way to guarantee that it'll do the right thing. But it can do better than it does currently, if we make this assumption about terminal tab width. I'd be curious to see what terminal emulators set the default tab width to anything other than 8 columns, but as long as the major ones do, then assuming 8 is probably fine (or it could be configurable for people who go that far away from the norm). Maybe I'm wrong about the prevalence of 8-column tabs?\r\n\r\nI think that `--tabs=0` is a convenient workaround for being unable to see changes between tabs and spaces because tabs have been replaced before the highlighting happens. At least, that's why I started experimenting with it. So if/when that gets fixed, there won't be a need to do anything nice here. But until then ... (I start a new job tomorrow, so I may be slow in making that happen).\r\n\r\nAnyway, I'll defer to you and Dan on this one.","createdAt":"2021-11-01T05:00:59Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/750#issuecomment-955932580","viewerDidAuthor":false},{"id":"IC_kwDOC4j8g845BOAk","author":{"login":"th1000s"},"authorAssociation":"COLLABORATOR","body":"I learned a new weird terminal command: `tabs`\r\n\r\nThis can change the width to e.g. 1 `tabs -1`, but can also set completely arbitrary tabstops: `tabs 2,+2,+5,+11,+12,+1,+4`. But I don't think anyone seriously uses that, I also think that most terminals do use 8. Still, lets fix general tab behavior in the other PR first.\r\n\r\n","createdAt":"2021-11-01T21:22:15Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/750#issuecomment-956620836","viewerDidAuthor":false}],"number":750,"title":"🐛 In side-by-side mode, tabs mess up alignment of plus side"},{"body":"\n> Potential segfault in `localtime_r` invocations\n\n| Details | |\n| ------------------- | ---------------------------------------------- |\n| Package | `chrono` |\n| Version | `0.4.19` |\n| URL | [https://github.com/chronotope/chrono/issues/499](https://github.com/chronotope/chrono/issues/499) |\n| Date | 2020-11-10 |\n\n### Impact\n\nUnix-like operating systems may segfault due to dereferencing a dangling pointer in specific circumstances. This requires an environment variable to be set in a different thread than the affected functions. This may occur without the user's knowledge, notably in a third-party library.\n\n### Workarounds\n\nNo workarounds are known.\n\n### References\n\n- [time-rs/time#293](https://github.com/time-rs/time/issues/293)\n\nSee [advisory page](https://rustsec.org/advisories/RUSTSEC-2020-0159.html) for additional details.\n","comments":[],"number":743,"title":"RUSTSEC-2020-0159: Potential segfault in `localtime_r` invocations"},{"body":"\n> Potential segfault in the time crate\n\n| Details | |\n| ------------------- | ---------------------------------------------- |\n| Package | `time` |\n| Version | `0.1.44` |\n| URL | [https://github.com/time-rs/time/issues/293](https://github.com/time-rs/time/issues/293) |\n| Date | 2020-11-18 |\n| Patched versions | `>=0.2.23` |\n| Unaffected versions | `=0.2.0,=0.2.1,=0.2.2,=0.2.3,=0.2.4,=0.2.5,=0.2.6` |\n\n### Impact\n\nUnix-like operating systems may segfault due to dereferencing a dangling pointer in specific circumstances. This requires an environment variable to be set in a different thread than the affected functions. This may occur without the user's knowledge, notably in a third-party library.\n\nThe affected functions from time 0.2.7 through 0.2.22 are:\n\n- `time::UtcOffset::local_offset_at`\n- `time::UtcOffset::try_local_offset_at`\n- `time::UtcOffset::current_local_offset`\n- `time::UtcOffset::try_current_local_offset`\n- `time::OffsetDateTime::now_local`\n- `time::OffsetDateTime::try_now_local`\n\nThe affected functions in time 0.1 (all versions) are:\n\n- `at`\n- `at_utc`\n\nNon-Unix targets (including Windows and wasm) are unaffected.\n\n### Patches\n\nPending a proper fix, the internal method that determines the local offset has been modified to always return `None` on the affected operating systems. This has the effect of returning an `Err` on the `try_*` methods and `UTC` on the non-`try_*` methods.\n\nUsers and library authors with time in their dependency tree should perform `cargo update`, which will pull in the updated, unaffected code.\n\nUsers of time 0.1 do not have a patch and should upgrade to an unaffected version: time 0.2.23 or greater or the 0.3. series.\n\n### Workarounds\n\nNo workarounds are known.\n\n### References\n\ntime-rs/time#293\n\nSee [advisory page](https://rustsec.org/advisories/RUSTSEC-2020-0071.html) for additional details.\n","comments":[],"number":741,"title":"RUSTSEC-2020-0071: Potential segfault in the time crate"},{"body":"Tabs characters usually function in columns, meaning that if I write `Hi\\tWorld` and `Hello\\tWorld`, both occurances of `World` should be aligned. In Delta however this alignment doesn't work and instead tabs are always printed as the exact width that they're set to.\r\n\r\nThis is what my test file looks like in my editor (and how it should look):\r\n\r\n\r\nThis is what delta produces:\r\n","comments":[{"id":"IC_kwDOC4j8g843qKTe","author":{"login":"th1000s"},"authorAssociation":"COLLABORATOR","body":"Indeed, also see [#522](https://github.com/dandavison/delta/issues/522#issuecomment-779478726).","createdAt":"2021-10-04T19:44:03Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/729#issuecomment-933799134","viewerDidAuthor":false},{"id":"IC_kwDOC4j8g8440AYG","author":{"login":"dhduvall"},"authorAssociation":"NONE","body":"I wasn't sure, in my PR, whether this behavior should be configurable. I can't really imagine that people would want the existing behavior, but sometimes my imagination is lacking. 😄","createdAt":"2021-10-27T17:36:06Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/729#issuecomment-953157126","viewerDidAuthor":false},{"id":"IC_kwDOC4j8g85fPMll","author":{"login":"th1000s"},"authorAssociation":"COLLABORATOR","body":"PR #1205 would address that, but is this use case that common?","createdAt":"2023-06-19T22:04:14Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/729#issuecomment-1597819237","viewerDidAuthor":false},{"id":"IC_kwDOC4j8g85h-sgi","author":{"login":"andy29485"},"authorAssociation":"NONE","body":"It's probably not that common, but I use tabs for alignment.\r\n\r\nFor example in shell scripts (using spaces in my example, but the part before the `\\`s would be tabs):\r\n```sh\r\ncommand \\\r\n --option-a \\\r\n --other-opt \\\r\n -x yz \\\r\n```\r\n\r\nWhy align? makes it easier to see the command since it appears as a block.\r\nWhy tabs? less work to get them to align then spaces.","createdAt":"2023-07-20T12:20:15Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/729#issuecomment-1643825186","viewerDidAuthor":false},{"id":"IC_kwDOC4j8g850Pu6e","author":{"login":"CharlemagneLasse"},"authorAssociation":"NONE","body":"Same problem here. I thought `delta` would be a really good tool to review new code. But as it turns out, it fails at even the simplest task. If I would for example perform a:\r\n\r\n```\r\ngit log -p -- include/uapi/asm-generic/errno-base.h\r\n```\r\n\r\nThe changes I would see are:\r\n\r\n```\r\n#ifndef _ASM_GENERIC_ERRNO_BASE_H\r\n#define _ASM_GENERIC_ERRNO_BASE_H\r\n\r\n#define EPERM 1 /* Operation not permitted */\r\n#define ENOENT 2 /* No such file or directory */\r\n#define ESRCH 3 /* No such process */\r\n#define EINTR 4 /* Interrupted system call */\r\n#define EIO 5 /* I/O error */\r\n#define ENXIO 6 /* No such device or address */\r\n#define E2BIG 7 /* Argument list too long */\r\n#define ENOEXEC 8 /* Exec format error */\r\n#define EBADF 9 /* Bad file number */\r\n#define ECHILD 10 /* No child processes */\r\n#define EAGAIN 11 /* Try again */\r\n#define ENOMEM 12 /* Out of memory */\r\n#define EACCES 13 /* Permission denied */\r\n#define EFAULT 14 /* Bad address */\r\n#define ENOTBLK 15 /* Block device required */\r\n#define EBUSY 16 /* Device or resource busy */\r\n#define EEXIST 17 /* File exists */\r\n#define EXDEV 18 /* Cross-device link */\r\n#define ENODEV 19 /* No such device */\r\n#define ENOTDIR 20 /* Not a directory */\r\n#define EISDIR 21 /* Is a directory */\r\n#define EINVAL 22 /* Invalid argument */\r\n#define ENFILE 23 /* File table overflow */\r\n#define EMFILE 24 /* Too many open files */\r\n#define ENOTTY 25 /* Not a typewriter */\r\n#define ETXTBSY 26 /* Text file busy */\r\n#define EFBIG 27 /* File too large */\r\n#define ENOSPC 28 /* No space left on device */\r\n#define ESPIPE 29 /* Illegal seek */\r\n#define EROFS 30 /* Read-only file system */\r\n#define EMLINK 31 /* Too many links */\r\n#define EPIPE 32 /* Broken pipe */\r\n#define EDOM 33 /* Math argument out of domain of func */\r\n#define ERANGE 34 /* Math result not representable */\r\n\r\n#endif\r\n```\r\n\r\nThen I would have replied to the author that he is drunk and first sober up before submitting code again. But when looking at the actual code, it would have been clear that the author was sober but `delta` is drunk.\r\n\r\nThe only way to use delta (in this context) is to disable most of its functionalities:\r\n\r\n```\r\n [core]\r\n- pager = delta\r\n+[pager]\r\n+ diff = delta --color-only | /usr/bin/less -x1,9\r\n+ log = delta --color-only | /usr/bin/less -x1,9\r\n+ show = delta --color-only\r\n```\r\n\r\nBut this is far from perfect","createdAt":"2024-02-17T18:47:00Z","includesCreatedEdit":true,"isMinimized":false,"minimizedReason":"","reactionGroups":[{"content":"THUMBS_DOWN","users":{"totalCount":1}}],"url":"https://github.com/dandavison/delta/issues/729#issuecomment-1950281374","viewerDidAuthor":false},{"id":"IC_kwDOC4j8g850PwuH","author":{"login":"CharlemagneLasse"},"authorAssociation":"NONE","body":"> PR https://github.com/dandavison/delta/pull/1205 would address that, but is this use case that common?\r\n\r\nEver heard of this niche code base called Linux? Or the source code of this unavowed SCM called git? Or this thing called GCC, glibc, GCC, gimp, inkscape, firefox, ...\r\n\r\nAnd even if it is only part of a test, you can find such a tab in delta src/handlers/diff_header.rs or src/subcommands/list_syntax_themes.rs. Or (not a test) in etc/completion/completion.fish","createdAt":"2024-02-17T19:24:11Z","includesCreatedEdit":true,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/729#issuecomment-1950288775","viewerDidAuthor":false},{"id":"IC_kwDOC4j8g850Px0p","author":{"login":"dandavison"},"authorAssociation":"OWNER","body":"> Ever heard of this niche code base called Linux? \r\n\r\n@CharlemagneLasse the person you are replying to is the author of https://github.com/dandavison/delta/pull/1205. If we build delta on his branch, and clone the linux kernel, we find\r\n\r\n```\r\ngit log -p -- include/uapi/asm-generic/errno-base.h\r\n```\r\n\r\n<img width=\"412\" alt=\"image\" src=\"https://github.com/dandavison/delta/assets/52205/f4477832-aaa4-4473-b702-1570127c482b\">\r\n\r\nIt seems impolitic, to say the least, to speak like that to the author of the PR which is fixing the issue that you are (rightly) saying should be fixed!\r\n\r\nWould you like to fix the (few) merge conflicts on https://github.com/dandavison/delta/pull/1205 so that we can get it merged and released?","createdAt":"2024-02-17T19:46:36Z","includesCreatedEdit":true,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/729#issuecomment-1950293289","viewerDidAuthor":true},{"id":"IC_kwDOC4j8g850T0GM","author":{"login":"Mango0x45"},"authorAssociation":"NONE","body":"> PR #1205 would address that, but is this use case that common?\r\n\r\nWell I opened this issue 3 years ago and I can confidently say that this functionality has only become even more important in that time for me","createdAt":"2024-02-18T15:01:14Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[{"content":"THUMBS_UP","users":{"totalCount":1}}],"url":"https://github.com/dandavison/delta/issues/729#issuecomment-1951351180","viewerDidAuthor":false}],"number":729,"title":"🐛 Tabs are displayed incorrectly."},{"body":"Hey there, thank you for this great program! I want to style my pager output similar to Github's, but I can't seem to find a way to style this portion below to be gray italic. I've searched through the docs and issues, but maybe I'm missing something.\r\n\r\n\r\n\r\nMy guess is that because I also passed in `raw` to `hunk-header-style` in addition to `syntax`, any styling after that is not taking effect. The relevant part of my gitconfig is below\r\n\r\n```\r\n[delta]\r\n theme = base16\r\n syntax-theme = base16\r\n file-decoration-style = \"#414868\" ul ol\r\n hunk-header-style = raw syntax \"#414868\" italic\r\n hunk-header-decoration-style = none\r\n line-numbers = true\r\n line-numbers-left-format = \"{nm:^4}⁞{np:^4}│\"\r\n line-numbers-left-style = \"#414868\"\r\n line-numbers-right-format = \" \"\r\n line-numbers-right-style = \"#414868\"\r\n line-numbers-zero-style = \"#414868\"\r\n line-numbers-plus-style = \"#164846\"\r\n line-numbers-minus-style = \"#823c41\"\r\n side-by-side = true\r\n\r\n[color \"diff\"]\r\n frag = \"#414868\" italic\r\n```\r\n","comments":[{"id":"IC_kwDOC4j8g845Ct7v","author":{"login":"dandavison"},"authorAssociation":"OWNER","body":"Thanks @ourigen! And sorry to be slow. I can reproduce this -- as you say, it looks like `hunk-header-style=raw` doesn't apply to the \"frag\" in the way one might expect and that's making it impossible/non-obvious to replicate something like github's style, with the hunk-header metadata, and the frag, styled the same.","createdAt":"2021-11-02T01:13:45Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/728#issuecomment-957013743","viewerDidAuthor":true}],"number":728,"title":"🐛 No way to style hunk-header syntax with raw option?"},{"body":"Hi,\r\n\r\nI would expect the following script to show the diff successfully : \r\n\r\n```\r\ndelta <(printf \"1\\n2\\n3\\n\") <(printf \"1\\n4\\n3\\n\")\r\n```\r\n\r\nHowever, it shows, on my terminal at least : \r\n\r\n```\r\ndev/fd/63 ⟶ dev/fd/62\r\n\r\n───┐\r\n1: │\r\n───┘\r\n│ 1 │pipe:[3447202] │ │\r\n\\ No newline at end of file\r\n│ │ │ 1 │pipe:[3447204]\r\n\\ No newline at end of file\r\n```\r\n\r\nIf I run \r\n\r\n```\r\ndiff <(printf \"1\\n2\\n3\\n\") <(printf \"1\\n4\\n3\\n\")\r\n```\r\n\r\nor \r\n\r\n```\r\nicdiff <(printf \"1\\n2\\n3\\n\") <(printf \"1\\n4\\n3\\n\")\r\n```\r\n\r\nIt works as expected.","comments":[{"id":"IC_kwDOC4j8g8400ryV","author":{"login":"edi9999"},"authorAssociation":"NONE","body":"See this https://superuser.com/questions/1059781/what-exactly-is-in-bash-and-in-zsh as an explanation of process substition","createdAt":"2021-07-25T16:29:03Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/666#issuecomment-886226069","viewerDidAuthor":false},{"id":"IC_kwDOC4j8g8400xq8","author":{"login":"Kr1ss-XD"},"authorAssociation":"CONTRIBUTOR","body":"Hi @edi9999 - Note that git itself doesn't handle diffs of process substitutions (and these are implemented via named pipes, and thus can't be part of a git repository anyways) : \r\n\r\n```sh\r\n$ git --no-pager diff <(printf \"1\\n2\\n3\\n\") <(printf \"1\\n4\\n3\\n\")\r\ndiff --git 1/dev/fd/63 2/dev/fd/62\r\nindex cad0470..0d8155b 120000\r\n--- 1/dev/fd/63\r\n+++ 2/dev/fd/62\r\n@@ -1 +1 @@\r\n-pipe:[3364850]\r\n\\ No newline at end of file\r\n+pipe:[3364852]\r\n\\ No newline at end of file\r\n```\r\n\r\nHence, I don't think it's a delta issue, right ?\r\n\r\nBut, you can still achieve your goal with\r\n\r\n```sh\r\n$ diff <(printf \"1\\n2\\n3\\n\") <(printf \"1\\n4\\n3\\n\") | delta\r\n```\r\n\r\n:wink: ","createdAt":"2021-07-25T19:58:08Z","includesCreatedEdit":true,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/666#issuecomment-886250172","viewerDidAuthor":false},{"id":"IC_kwDOC4j8g8400yzx","author":{"login":"dandavison"},"authorAssociation":"OWNER","body":"Hi @edi9999, to expand slightly on @Kr1ss-XD's answer: firstly, `delta file_A file_B` is a wrapper around `git diff --no-index` (since delta of course contains no diffing algorithm). But! As @Kr1ss-XD says, it seems that git does not support process substitution; see https://stackoverflow.com/questions/22706714/why-does-git-diff-not-work-with-process-substitution. However, there is an argument that this is a bug in git, since `git diff --no-index /wherever/file-A /somewhere/else/file_B` is AFAIK intended to perform an diff on two arbitrary files with no involvement of a git repository. And in fact, in the SO thread is a link to a 2014 patch against git that claims to fix this, but seemed never to get any response.\r\n\r\nSo, one thing we could do, perhaps, would be to enquire in the appropriate git development forum as to whether that patch is appropriate and correct, or study the problem ourselves.\r\n\r\nAnother thing we _could_ do is add an option for users to go back to what delta was doing previously, i.e. calling `diff -u` instead of `git diff`. But there were (IMO) good reasons for using `git diff` instead of `diff -u` (reasons given in https://github.com/dandavison/delta/issues/543).","createdAt":"2021-07-25T20:38:56Z","includesCreatedEdit":true,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/666#issuecomment-886254833","viewerDidAuthor":true},{"id":"IC_kwDOC4j8g84000Gq","author":{"login":"edi9999"},"authorAssociation":"NONE","body":"The patch seems so simple on the git repository that it looks like it would not really do any harm in my humble opinion.\r\n\r\nOne reason delta could overcome this would be to detect this case and create temporary files from the file descriptors in this case, and call git diff on the temporary files in that case (created in /tmp/delta_XXXXX with a random suffix and deleted after the diff is done)","createdAt":"2021-07-25T21:27:50Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/666#issuecomment-886260138","viewerDidAuthor":false},{"id":"IC_kwDOC4j8g846dGy9","author":{"login":"infokiller"},"authorAssociation":"NONE","body":"My current workaround is to use temporary files like @edi9999 mentions, something like this (the full version is in a [script used in my dotfiles](https://github.com/infokiller/config-public/blob/master/.my_scripts/util/sensible-diff)):\r\n\r\n```sh\r\n# git-diff doesn't work with process substitution [1] so we're copying the\r\n# pipe to a temporary file.\r\n# [1] https://github.com/dandavison/delta/issues/666\r\n_git_diff() {\r\n local tmpdir\r\n tmpdir=\"$(mktemp -d -t 'git_diff.XXXXXX')\"\r\n # NOTE: The path variable in trap must be expanded here because it may not\r\n # be defined when the trap is ran.\r\n # shellcheck disable=SC2064\r\n trap \"rm -rf -- '${tmpdir}' &> /dev/null || true\" EXIT ERR INT HUP TERM\r\n local f files=()\r\n for ((i = 1; i <= $#; i++)); do\r\n f=\"${!i}\"\r\n if [[ -p \"${f}\" ]]; then\r\n local tmpfile=\"${tmpdir}/arg_${i}\"\r\n cat -- \"${f}\" >| \"${tmpfile}\"\r\n files+=(\"${tmpfile}\")\r\n else\r\n files+=(\"${f}\")\r\n fi\r\n done\r\n git diff --no-index --color \"${files[@]}\"\r\n}\r\n\r\n_git_diff \"$@\" | delta\r\n```","createdAt":"2021-11-27T16:59:32Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/666#issuecomment-980708541","viewerDidAuthor":false}],"number":666,"title":"Correctly handle process substitution in bash"},{"body":"I've noticed the issue on my Raspberry Pi 2 which is resource constrained and therefore it's easier to spot performance issues. Not really sure if that's expected but a diff of single file with change on single line (12k long admittedly though) takes 23s with 100% CPU (@900MHz) and allocated more than 400MB of RAM. \r\n\r\nReproducer:\r\n```sh\r\n# populate test file with very long line key = [ 'value','value','value'.... ];\r\n$ echo -n 'key = [' >> test; for i in `seq 1500`; do echo -n \"'value',\" >> test; done; echo '];' >> test\r\n# change something on the very long line and save as test2\r\n$ sed \"s/];/'value'];/\" test > test2\r\n$ /usr/bin/time -v delta --max-line-length=0 test test2\r\n...\r\n User time (seconds): 20.48\r\n System time (seconds): 1.71\r\n Percent of CPU this job got: 95%\r\n Elapsed (wall clock) time (h:mm:ss or m:ss): 0:23.34\r\n...\r\n Maximum resident set size (kbytes): 442616\r\n...\r\n```\r\nOn a much faster Pinebook Pro:\r\n```sh\r\n$ /usr/bin/time -v delta --max-line-length=0 test test2\r\n...\r\n User time (seconds): 13.53\r\n System time (seconds): 0.81\r\n Percent of CPU this job got: 95%\r\n Elapsed (wall clock) time (h:mm:ss or m:ss): 0:15.00\r\n...\r\n Maximum resident set size (kbytes): 871824\r\n...\r\n```\r\n\r\nversion: 0.8.3","comments":[{"id":"IC_kwDOC4j8g8400SFV","author":{"login":"jpalus"},"authorAssociation":"NONE","body":"`diff-so-fancy` appears to be way more efficient, with same input on Raspberry Pi 2:\r\n```sh\r\n..\r\n User time (seconds): 0.52\r\n System time (seconds): 0.06\r\n Percent of CPU this job got: 99%\r\n Elapsed (wall clock) time (h:mm:ss or m:ss): 0:00.59\r\n...\r\n Maximum resident set size (kbytes): 7696\r\n```","createdAt":"2021-07-24T22:56:51Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/659#issuecomment-886120789","viewerDidAuthor":false},{"id":"IC_kwDOC4j8g8400d6M","author":{"login":"dandavison"},"authorAssociation":"OWNER","body":"Hi @jpalus, thanks for opening this. Syntax-highlighting long lines is slow (as documented in the warning accompanying `--max-line-length=0`), and delta accordingly truncates such lines by default. But seeing as your test file doesn't involve syntax highlighting I think you're right that the performance should be better. In your real use cases, when you want to view a 12k line without truncation, would you want syntax-highlighting?\r\n\r\n```\r\n--max-line-length <max-line-length>\r\n Truncate lines longer than this. To prevent any truncation, set to zero. Note that syntax-highlighting very\r\n long lines (e.g. minified .js) will be very slow if they are not truncated [default: 512]\r\n``` \r\n","createdAt":"2021-07-25T08:52:14Z","includesCreatedEdit":true,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/659#issuecomment-886169228","viewerDidAuthor":true},{"id":"IC_kwDOC4j8g8400rb-","author":{"login":"jpalus"},"authorAssociation":"NONE","body":"Nope no need for syntax highlighting in that case, actually I don't care about syntax highlighting in diffs all that much in general.\r\n\r\nI'm aware of note regarding performance with unlimited line length but personally I prefer to have unlimited line lengths and slower diff performance however these numbers seem excessively slow. Though I just might be unaware of complexity involved here.","createdAt":"2021-07-25T16:16:50Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/659#issuecomment-886224638","viewerDidAuthor":false},{"id":"IC_kwDOC4j8g8411bTc","author":{"login":"dandavison"},"authorAssociation":"OWNER","body":"In fact, it's not the syntax highlighter that is slow here; it's the within-line diff computation. (If you're interested in the details, this runs a dynamic programming algorithm similar to the standard Levenshtein / edit distance algorithm, which involves a square matrix of dimensions `#tokens x #tokens`. So, I think it's understandable that this is slow on very long lines.)\r\n\r\nDelta doesn't currently have a way of disabling the within-line edit inference. There would certainly be ways forwards here -- alternative diff algorithms, or perhaps adjustments to the current algorithm to handle very long lines.\r\n\r\nI've updated the help text to stop it saying that the problem is the syntax highlighter. https://github.com/dandavison/delta/pull/698 ensures that no syntax highlighting call at all will be made when none is needed (e.g. user did not request syntax or language unknown).","createdAt":"2021-08-22T01:19:54Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/659#issuecomment-903197916","viewerDidAuthor":true},{"id":"IC_kwDOC4j8g8411bdn","author":{"login":"dandavison"},"authorAssociation":"OWNER","body":"diff-so-fancy has better performance on long lines because it uses the [diff-highlight](https://github.com/git/git/tree/master/contrib/diff-highlight) perl script, which has a deliberately simplistic within-line diff algorithm:\r\n\r\n> It will find the common prefix and suffix of two lines, and consider everything in the middle to be \"different\".\r\n","createdAt":"2021-08-22T01:26:55Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/659#issuecomment-903198567","viewerDidAuthor":true},{"id":"IC_kwDOC4j8g8417lZh","author":{"login":"jpalus"},"authorAssociation":"NONE","body":"Just an idea but perhaps as intermediate solution new option could be introduced with threshold for within-line diff computation? For lines with length lower than threshold delta would use exact computation while above either no within-line diff would be calculated at all or, if possible, the simplistic solution similar to diff-highlight could be implemented?","createdAt":"2021-08-24T16:52:27Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/659#issuecomment-904812129","viewerDidAuthor":false},{"id":"IC_kwDOC4j8g846xSuk","author":{"login":"jpalus"},"authorAssociation":"NONE","body":"Some other idea for an optimization though I not really sure whether it makes any sense or whether it is doable :). It comes from an observation that a lot of line modifications change a small portion of this line, leaving it mostly the same, so what about quickly finding common prefix and common suffix between two lines and running exact algorithm only against parts with common prefix/suffix stripped? Finding common prefix/suffix should be very quick so additional time spent on this should be negligible, however it should greatly improve common case. But that's only with an assumption that it's doable :).","createdAt":"2021-12-04T09:46:13Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/659#issuecomment-986000292","viewerDidAuthor":false},{"id":"IC_kwDOC4j8g846xo5I","author":{"login":"dandavison"},"authorAssociation":"OWNER","body":"> what about quickly finding common prefix and common suffix between two lines and running exact algorithm only against parts with common prefix/suffix stripped? \r\n\r\nHi @jpalus, that's an interesting idea. I wonder however whether your earlier suggestion would be just as good and easier to implement:\r\n\r\n> For lines with length lower than threshold delta would use exact computation while above [...] the simplistic solution similar to diff-highlight could be implemented?\r\n\r\nDo you happen to have any interest in implementing it? We have an [`ARCHITECTURE.md`](https://github.com/dandavison/delta/blob/master/ARCHITECTURE.md#handling-diff-hunk-lines) doc now that gives an overview of the relevant codepaths and basically points to how/where a second diff algorithm would be added.","createdAt":"2021-12-04T20:52:35Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/659#issuecomment-986091080","viewerDidAuthor":true},{"id":"IC_kwDOC4j8g84_ikY5","author":{"login":"unphased"},"authorAssociation":"NONE","body":"@dandavison I'm still trying to navigate the new documentation site, but I can't figure out how to enable more than 512 chars for when delta is being used for git diff/git log. Appreciate the explanation for its n^2 runtime behavior. I think the default of 512 is pretty limiting especially when differences actually appear in the truncated zone.\r\n\r\nI tried `max-line-length = 2048` inside the `[delta]` section of my git config, but this did not have any effect.","createdAt":"2022-03-13T04:56:54Z","includesCreatedEdit":true,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/659#issuecomment-1066026553","viewerDidAuthor":false},{"id":"IC_kwDOC4j8g84_i-TZ","author":{"login":"dandavison"},"authorAssociation":"OWNER","body":"Hi @unphased, that's right:\r\n\r\n```gitconfig\r\n[delta]\r\n max-line-length = 2048\r\n```\r\n\r\nI just tested and that does work, so something must be wrong with your config file. You could use `delta --show-config` to sanity check that entries from your git config are being picked up.\r\n\r\n> I'm still trying to navigate the new documentation site\r\n\r\n`delta -h` and `delta --help` are guaranteed to document all options. The online manual doesn't document every option (except in that it contains a [copy of the `--help` output](https://dandavison.github.io/delta/full---help-output.html)). Have you tried the new short help available with `delta -h`?\r\n\r\n> I think the default of 512 is pretty limiting especially when differences actually appear in the truncated zone.\r\n\r\nAre these long lines you're encountering minified css/js files?","createdAt":"2022-03-13T16:08:46Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/659#issuecomment-1066132697","viewerDidAuthor":true},{"id":"IC_kwDOC4j8g84_jE3v","author":{"login":"unphased"},"authorAssociation":"NONE","body":"> > I think the default of 512 is pretty limiting especially when differences actually appear in the truncated zone.\r\n> \r\n> Are these long lines you're encountering minified css/js files?\r\n\r\nNah. Plenty of situations in which we encounter things like this. markdown like `603b807 37dd3391` from this repo or various config stuff. Often you have config formats which are annoying to, or don't support multiline entries. ","createdAt":"2022-03-13T18:43:49Z","includesCreatedEdit":true,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/659#issuecomment-1066159599","viewerDidAuthor":false},{"id":"IC_kwDOC4j8g84_jOtL","author":{"login":"unphased"},"authorAssociation":"NONE","body":"@dandavison I figured out that the max-line-length config set in my gitconfig does work but only as long as side-by-side is not enabled. Is this a bug that you can confirm?","createdAt":"2022-03-13T22:59:10Z","includesCreatedEdit":true,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/659#issuecomment-1066199883","viewerDidAuthor":false},{"id":"IC_kwDOC4j8g84_jV91","author":{"login":"dandavison"},"authorAssociation":"OWNER","body":"Actually, it's not a bug, since `side-by-side` is working as documented: in `side-by-side` mode, you use `wrap-max-lines` to control how many wrapped lines you want before truncation.\r\n\r\n```\r\n--wrap-max-lines <N>\r\n How often a line should be wrapped if it does not fit.\r\n\r\n Zero means to never wrap. Any content which does not fit after wrapping will be truncated. \r\n A value of \"unlimited\" means a line will be wrapped as many times as required.\r\n\r\n [default: 2]\r\n```\r\n\r\nInternally, the `side-by-side` code sets the max line length to a high enough value to cover the requested number of wrapped lines. The thing that is potentially confusing is that increasing `max-line-length` doesn't automatically increase `wrap-max-lines`. But I think that `max-line-length` is something we're hoping to get rid of entirely once we've made the diff algorithm more efficient on long lines. ","createdAt":"2022-03-14T00:57:54Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[{"content":"THUMBS_UP","users":{"totalCount":1}}],"url":"https://github.com/dandavison/delta/issues/659#issuecomment-1066229621","viewerDidAuthor":true},{"id":"IC_kwDOC4j8g84_jZqG","author":{"login":"unphased"},"authorAssociation":"NONE","body":"Oh, perfect! Thanks for the explanation :)","createdAt":"2022-03-14T01:26:13Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/659#issuecomment-1066244742","viewerDidAuthor":false}],"number":659,"title":"🐛 High resource usage on long lines when line truncation is disabled"},{"body":"### Preface\r\n\r\nOnce again, `delta` is an AMAZING tool that I use every day, and definitely makes my workflows (lots of diff reviews) much simpler (and better than GitHub / BitBucket / GitLab diff viewers, due to supporting all of Git's options e.g. `-W`).\r\n\r\n### Problem Description\r\n\r\nOne of the issues that arises frequently is that some of our Java and Swift programmers like having lines that are 600 characters long.\r\n\r\nSince `delta` uses one of many various pagers, usually some form of `less`, which supports line-wrapping, but this breaks lots of things (like `delta`'s line numbers). Specifying `LESS=... -S ...` allows side-scroll to view the rest of the line, but this is quite tedious.\r\n\r\nThis becomes a double-whammy when using `delta --side-by-side` as the long lines are simply truncated, especially on the left-hand side (before). Scrolling only reveals more on the right-hand (after) side.\r\n\r\n### Feature Request\r\n\r\nUltimately, it would be nice if `delta` had its own option to support wrapping lines in some kind of context-aware manner. \"Context-aware\" can simply be \"wrap lines, and prepend N+4 spaces\" where \"N\" is the number of leading spaces in the original line. There would likely need to be actual \"context aware magic\" so that the full wrapped line appears to be on the same line number with `delta -n`, but I assume this is achievable.\r\n\r\nThis would also make `--side-by-side` more useful, if applied to both sides, especially with long lines.\r\n\r\n\r\n### Pitfalls and Non-Goals\r\n\r\nThis will still fail in predictable ways when the number of leading whitespace is large, as apparently some people prefer:\r\n\r\n```c\r\nif(...) { \r\n if(...) {\r\n if(...) {\r\n if(...) {\r\n if(...) {\r\n // Ad infinitum, until eventually....\r\n main_logic();\r\n } else {\r\n return err;\r\n }\r\n } else {\r\n return err;\r\n }\r\n } else {\r\n return err;\r\n }\r\n } else {\r\n return err2;\r\n }\r\n} else {\r\n return err1;\r\n}\r\n```\r\n\r\nInstead of the (IMHO more readable)\r\n\r\n```c\r\nif(!...) { \r\n return err1;\r\n}\r\n\r\nif(!...) { \r\n return err2;\r\n}\r\n\r\n// add infinitum\r\n\r\nmain_logic();\r\n```","comments":[{"id":"IC_kwDOC4j8g8411b8I","author":{"login":"dandavison"},"authorAssociation":"OWNER","body":"Hi @zachriggle, for side-by-side there is good news: @th1000s has a branch in an advanced state that implements quite sophisticated line wrapping in side-by-side mode: https://github.com/dandavison/delta/pull/515 \r\n\r\nI wonder whether it might be possible, after that merges, to borrow the line-wrapping technology from that work and use it for the non-side-by-side case; I don't think that's been discussed yet.","createdAt":"2021-08-22T01:50:03Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/657#issuecomment-903200520","viewerDidAuthor":true},{"id":"IC_kwDOC4j8g843aOno","author":{"login":"th1000s"},"authorAssociation":"COLLABORATOR","body":"That sounds doable. Before finishing #515 maybe the `--side-by-side-wrap-symbol` and related arguments should be renamed to `--wrap-symbol`. Two specific flags, the original and `--unified-wrap-symbol`, could always be added later.","createdAt":"2021-09-28T21:02:16Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/657#issuecomment-929622504","viewerDidAuthor":false},{"id":"IC_kwDOC4j8g843asol","author":{"login":"dandavison"},"authorAssociation":"OWNER","body":"@th1000s I agree: removing the `side-by-side` prefix from some option names seems to have several advantages (e.g. brevity, generality) and as you say we can always introduce the s-b-s specific ones later. Are you thinking of removing the prefix from all the options below? \r\n\r\n```\r\n --side-by-side-wrap-max-lines <side-by-side-wrap-max-lines>\r\n Maximum number of wrapped lines to display in side-by-side mode. Any content that still does not fit will be\r\n truncated [default: 3]\r\n --side-by-side-wrap-symbol <side-by-side-wrap-symbol>\r\n Symbol indicating that a line has been wrapped in side-by-side mode [default: ↵]\r\n --side-by-side-wrap-right-percent <side-by-side-wrap-right-percent>\r\n Threshold for right-aligning wrapped content in side-by-side mode. If the length of remaining wrapped\r\n content, as a percentage of the panel width, is less than this quantity then it will be displayed right-\r\n aligned [default: 37.0]\r\n --side-by-side-wrap-right-wrap-symbol <side-by-side-wrap-right-wrap-symbol>\r\n Symbol indicating that a line has been wrapped and that the subsequent content is displayed right-aligned\r\n [default: ↴]\r\n --side-by-side-wrap-right-prefix-symbol <side-by-side-wrap-right-prefix-symbol>\r\n Symbol displayed in front of right-aligned wrapped content [default: …]\r\n```","createdAt":"2021-09-29T01:23:30Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/657#issuecomment-929745445","viewerDidAuthor":true},{"id":"IC_kwDOC4j8g843lpf8","author":{"login":"th1000s"},"authorAssociation":"COLLABORATOR","body":"Yes, and I removed the prefix in the other PR, which is now final.","createdAt":"2021-10-01T22:37:50Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/657#issuecomment-932616188","viewerDidAuthor":false}],"number":657,"title":"🚀 Context-aware line wrapping"},{"body":"My theme specifies a few things like keywords to be bold.\r\nRight now, delta seems to ignore that.","comments":[{"id":"MDEyOklzc3VlQ29tbWVudDg1Mjk5OTM1OQ==","author":{"login":"dandavison"},"authorAssociation":"OWNER","body":"Hi @M1cha, would you be able to post an example theme demonstrating the problem, or otherwise give instructions for reproduction?","createdAt":"2021-06-02T12:49:49Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/621#issuecomment-852999359","viewerDidAuthor":true},{"id":"MDEyOklzc3VlQ29tbWVudDg1MzczNTM0Ng==","author":{"login":"M1cha"},"authorAssociation":"NONE","body":"ofc, here you go\r\n[cobalt.tmTheme.tar.gz](https://github.com/dandavison/delta/files/6590608/cobalt.tmTheme.tar.gz)\r\n\r\nWith that, keywords are bold using bat, but not using delta.","createdAt":"2021-06-03T09:39:07Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/621#issuecomment-853735346","viewerDidAuthor":false},{"id":"MDEyOklzc3VlQ29tbWVudDg1NDE2ODMyNw==","author":{"login":"dandavison"},"authorAssociation":"OWNER","body":"Thanks, yes I can reproduce that, e.g. the gold-coloured `pub fn` syntax below. (Copy `cobalt.tmTheme` into `\"$(bat --config-dir)/themes\"` and run `bat cache --build`.\r\n\r\n<table><tr><td><img width=600px src=\"https://user-images.githubusercontent.com/52205/120709313-b23ff900-c48a-11eb-910c-2f40080b4922.png\" alt=\"image\" /></td></tr></table>","createdAt":"2021-06-03T20:47:57Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/621#issuecomment-854168327","viewerDidAuthor":true},{"id":"MDEyOklzc3VlQ29tbWVudDg1NTU0MDQ2MQ==","author":{"login":"dandavison"},"authorAssociation":"OWNER","body":"The output below shows that bat is emitting the ANSI `1` attribute (bold), whereas delta is not. So the next step is to determine why this is. In principle there should be no such difference since both programs are using syntect to produce the ANSI color sequences for foreground text, as determined by the syntax theme.\r\n\r\nRaw output from delta:\r\n\r\n```\r\ngit show | delta --syntax-theme cobalt | LESS= less\r\n```\r\n\r\n```\r\nESC[38;5;214mpubESC[38;5;231m ESC[38;5;214mfnESC[38;5;231m get_file_paths_from_diff_line\r\n```\r\n\r\nRaw output from bat:\r\n\r\n```\r\nbat --plain --color=always --theme=cobalt src/parse.rs | LESS= less\r\n```\r\n\r\n```\r\nESC[1;38;5;214mpubESC[0mESC[38;5;231m ESC[0mESC[1;38;5;214mfnESC[0mESC[38;5;231m ESC[0mESC[38;5;231mget_file_paths_from_diff_line\r\n```\r\n","createdAt":"2021-06-07T02:59:05Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/621#issuecomment-855540461","viewerDidAuthor":true}],"number":621,"title":"`fontStyle` from bat themes is not supported"},{"body":"Hi, thanks for delta !\r\n\r\nSome automatic code formatters (e.g. `rustfmt`) introduce large changes just for whitespace moves. I don't want to totally ignore them but I'd like them to clutter less my screen. \r\nWould it be possible to add a mode where:\r\n- lines with only whitespace changes are displayed once (only the new ones), not twice\r\n- added whitespaces are green (like currently)\r\n- removed whitespaces are maybe displayed by using another color, i.e. if there are 4 less spaces then display the first 4 characters in a yellow background\r\n\r\nI'm still not clear how to display tabs/spaces difference, but maybe this warrants another option to use differently coloured speciakl characters for that (à la vim's `:set list`).","comments":[],"number":619,"title":"🚀 Add an \"inline-whitespace-change\" option"},{"body":"It would be nice to have git hash hyperlinks when using alternative log formats (eg `git log --format=...` or `git log --oneline`).","comments":[],"number":603,"title":"🚀 Add git hash hyperlinks on custom log formats"},{"body":"Hi, thanks for this great tool! Hyperlinks are really useful, it would be nice to have them working when using `--name-only` with `git diff` and `git log`.","comments":[],"number":602,"title":"🚀 Add hyperlinks for `git (log|diff) --name-only`"},{"body":"Thank you very much for this brilliant tool!\r\n\r\nIt would be nice if the header could display number of changes (and/or additions|deletions) in a file, similar to how GitHub shows this information.\r\nI looked through the docs and couldn't find it so I guess it hasn't been implemented yet.","comments":[{"id":"MDEyOklzc3VlQ29tbWVudDgzNTgxMzM5Ng==","author":{"login":"dandavison"},"authorAssociation":"OWNER","body":"Hi @disrupted, thanks for this. Is your request satisfied by using the `--stat` argument to git diff/show/log etc? That gives output like this with delta:\r\n\r\n\r\n<table><tr><td><img width=600px src=\"https://user-images.githubusercontent.com/52205/117574885-4f3a8c80-b0ad-11eb-96b7-68223f21ba6b.png\" alt=\"image\" /></td></tr></table>","createdAt":"2021-05-09T14:00:25Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/591#issuecomment-835813396","viewerDidAuthor":true},{"id":"MDEyOklzc3VlQ29tbWVudDg1MDM0NDYyNA==","author":{"login":"disrupted"},"authorAssociation":"NONE","body":"@dandavison this definitely goes in the right direction and I didn't know about it, so thanks for pointing it out.\r\n\r\nI was thinking something more like this, where it would show the number of changes (additions/deletions) in the header for each file.\r\n\r\n<img width=\"464\" alt=\"file header on GitHub showing number of changes\" src=\"https://user-images.githubusercontent.com/4771462/119974653-3854cf00-bfb5-11eb-96d6-e6902ea102ee.png\">\r\n\r\nMost of the time I use delta with fzf (inside of [forgit](https://github.com/wfxr/forgit)) so it would be really cool to show this information. Here's a small mockup of what I mean:\r\n\r\n","createdAt":"2021-05-28T11:14:28Z","includesCreatedEdit":true,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/591#issuecomment-850344624","viewerDidAuthor":false},{"id":"IC_kwDOC4j8g8411dGo","author":{"login":"dandavison"},"authorAssociation":"OWNER","body":"Hi @disrupted, I agree that could be nice. One concern however is that delta would have to process an entire file before starting to emit any of the output for that file, in order for it to be able to compute the diff summary. At the moment delta's processing is more stream-oriented than that, and it would raise the possibility of poor performance in the case of large files.","createdAt":"2021-08-22T02:52:18Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/591#issuecomment-903205288","viewerDidAuthor":true},{"id":"IC_kwDOC4j8g8411zx2","author":{"login":"Kr1ss-XD"},"authorAssociation":"CONTRIBUTOR","body":"I like that idea, too !\r\n\r\nMaybe the `--shortstat` option comes close to what @disrupted is imagining. It can be used with `git diff -p`, `git show -p` and `git log -p`.\r\n\r\nAs with `--stat`, git would do the calculation (and git is pretty efficient in that).\r\n\r\n<details><summary>examples - click to expand</summary><p>\r\n\r\n\r\n\r\n</p></details>\r\n\r\nThere are some caveats though : \r\n\r\n1. When using with `git diff` or `git show`, you need to also apply the `-p`/`--patch` flag; otherwise _only_ the shortstat will be outputted.\r\n2. It will be a summary of changes in _all_ files affected by the according commit. (There's the `--numstat` option, but that will output all statistics as a header, followed by all the diffs, and it would probably need to be parsed and reformatted.) I'm not aware of any way to have shortstats for each individual file inline, but maybe that's also possible somehow ? After all, git is a Jack of all trades in many regards... :laughing: ","createdAt":"2021-08-22T16:54:30Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[{"content":"THUMBS_UP","users":{"totalCount":1}}],"url":"https://github.com/dandavison/delta/issues/591#issuecomment-903298166","viewerDidAuthor":false}],"number":591,"title":"🚀 Count number of changes / additions / deletions"},{"body":"Right now the line numbers take space based upon their size. For example 11 will take two spaces and 132 will take 3. This cases issues if a hunk crosses a power-of-ten boundary as the second half of the hunk will be shifted over 2 spaces, causing the code to be misaligned.\r\n\r\nThis issue can be mitigated by configs such as `line-numbers-left-format = \"{nm:>4} \"` however this has a number of problems.\r\n\r\n1. It wastes screen real estate when the line numbers are smaller.\r\n2. It still breaks above your statically chosen threshold. The higher you set this threshold the more space you waste as per 1.\r\n\r\nSolution: For each hunk the required number size could be calculated and all numbers are printed with padding to keep a fixed width.","comments":[],"number":588,"title":"🚀 Automatically determine line-number padding."},{"body":"In addition to specifically customized themes using the dark/light registration, it would be useful to also include diff-highlight and diff-so-fancy emulation for comparison and reference.","comments":[],"number":586,"title":"🚀 Include diff-highlight and diff-so-fancy emulation in show-themes"},{"body":"With the 0.7.1 update I tried the `delta --show-themes` option and ran into the same issue as noted in the original [PR](https://github.com/dandavison/delta/pull/550#issuecomment-810377835) of an opaque error message. In addition to the note to require specification to the available themes, it would be useful to include the `themes.gitconfig` within the Debian package, perhaps as `/usr/share/git-delta/themes.gitconfig`.\r\n\r\n","comments":[{"id":"MDEyOklzc3VlQ29tbWVudDgzNTg2OTk1OA==","author":{"login":"dandavison"},"authorAssociation":"OWNER","body":"Hi @mrjoel, thanks. I'm thinking that a core selection of themes should be distributed in the binary itself, to avoid depending on packaging on any system.","createdAt":"2021-05-09T19:30:07Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/584#issuecomment-835869958","viewerDidAuthor":true},{"id":"MDEyOklzc3VlQ29tbWVudDg1MDY5MTY4MA==","author":{"login":"mrjoel"},"authorAssociation":"NONE","body":"That'd be even better, thanks!","createdAt":"2021-05-28T21:45:50Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/584#issuecomment-850691680","viewerDidAuthor":false}],"number":584,"title":"🚀 Bundle core themes in binary itself"},{"body":"```\r\n[delta]\r\n features = side-by-side line-numbers decorations\r\n zero-style = syntax \"#EEEEEE\"\r\n```\r\nWhen using side-by-side with a terminal background color overriding,\r\nthe color does not apply to empty lines.\r\n\r\n\r\n","comments":[{"id":"IC_kwDOC4j8g846y4eA","author":{"login":"dandavison"},"authorAssociation":"OWNER","body":"Hi @elbaro, thanks for this and sorry I didn't respond at the time you opened it. It's an interesting point -- I think the issue, at least in part, is that delta has so far been designed for the background colors to be used for emphasis. But it is not doing well, as you say, if you try to use delta to supply the default background color everywhere (I had imagined that users would use their terminal emulator to set the default background color).","createdAt":"2021-12-06T04:04:37Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/549#issuecomment-986417024","viewerDidAuthor":true},{"id":"IC_kwDOC4j8g847HvVg","author":{"login":"elbaro"},"authorAssociation":"NONE","body":"Delta emphasizes the whole line 87 in the screenshot instead of only the text part \"assert window_size > 0\". Doesn't that mean we should color the whole line 88 because the line is emphasized?\r\n\r\nOne problem relying on terminal background is remote machines. When delta is installed on the remote server, I sometimes ssh to it via dark terminal and sometimes light terminal.\r\n","createdAt":"2021-12-12T11:57:34Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/549#issuecomment-991884640","viewerDidAuthor":false},{"id":"IC_kwDOC4j8g847H0kJ","author":{"login":"dandavison"},"authorAssociation":"OWNER","body":"Hi @elbaro, can you post\r\n\r\n1. An example diff that demonstrates the problem\r\n2. The command line you are using and the output of `delta --show-config`\r\n3. Your delta version?\r\n\r\nI tried to reproduce it with this diff:\r\n\r\n```diff\r\ndiff --git a/src/cli.rs b/src/cli.rs\r\nindex e047889..6794917 100644\r\n--- a/src/cli.rs\r\n+++ b/src/cli.rs\r\n@@ -320,7 +320,7 @@ pub struct Opt {\r\n pub color_only: bool,\r\n \r\n pub features: String,\r\n```\r\n\r\nBut that seems to work correctly:\r\n\r\n```\r\ndelta --no-gitconfig --side-by-side --zero-style='black white' < the_diff.diff\r\n```\r\n\r\n<table><tr><td><img width=600px src=\"https://user-images.githubusercontent.com/52205/145716117-80be84a7-8985-435e-9641-4829e482a8ad.png\" alt=\"image\" /></td></tr></table>\r\n\r\n\r\n","createdAt":"2021-12-12T14:15:39Z","includesCreatedEdit":true,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/549#issuecomment-991906057","viewerDidAuthor":true},{"id":"IC_kwDOC4j8g847H0s6","author":{"login":"dandavison"},"authorAssociation":"OWNER","body":"Please make sure you're using the latest version of delta -- the implementation of side-by-side was rewritten this year, and I think that this bug may have been fixed already.","createdAt":"2021-12-12T14:19:38Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/549#issuecomment-991906618","viewerDidAuthor":true},{"id":"IC_kwDOC4j8g85IO4Lo","author":{"login":"ornew"},"authorAssociation":"NONE","body":"@dandavison @elbaro Hi. I am having the same problem with the latest version.\r\n\r\n```\r\n❯ delta --version\r\ndelta 0.13.0\r\n```\r\n\r\nThis occurs under the following conditions:\r\n\r\n- use side-by-side\r\n- line-numbers-zero-style **via features**\r\n\r\nfor example:\r\n\r\n```gitconfig\r\n[delta]\r\n\tside-by-side = true\r\n\tfeatures = line-numbers-style\r\n\r\n[delta \"line-numbers-style\"]\r\n\tline-numbers = true\r\n\tline-numbers-zero-style = \"#ffffff\" # doesn't work\r\n```\r\n\r\n<img width=\"754\" alt=\"スクリーンショット 2022-08-11 20 21 24\" src=\"https://user-images.githubusercontent.com/19766770/184122494-d656235a-a7d9-4afc-b77d-a574fbc8fd9b.png\">\r\n\r\n\r\nbut this is works:\r\n\r\n```gitconfig\r\n[delta]\r\n\tside-by-side = true\r\n\tline-numbers = true\r\n\tline-numbers-zero-style = \"#ffffff\" # ok\r\n```\r\n\r\n<img width=\"756\" alt=\"スクリーンショット 2022-08-11 20 21 46\" src=\"https://user-images.githubusercontent.com/19766770/184122558-9fabc31e-a574-4de6-985b-efead502e23a.png\">\r\n","createdAt":"2022-08-11T11:24:30Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[{"content":"THUMBS_UP","users":{"totalCount":1}}],"url":"https://github.com/dandavison/delta/issues/549#issuecomment-1211859688","viewerDidAuthor":false},{"id":"IC_kwDOC4j8g85IO9fH","author":{"login":"ornew"},"authorAssociation":"NONE","body":"I found that works when `side-by-side` and `zero-style` placed in the same feature.\r\n\r\n```gitconfig\r\n[delta]\r\n\tfeatures = line-numbers-style\r\n\r\n[delta \"line-numbers-style\"]\r\n\tside-by-side = true\r\n\tline-numbers = true\r\n\tline-numbers-zero-style = \"#ffffff\"\r\n```\r\n\r\n<img width=\"754\" alt=\"スクリーンショット 2022-08-11 20 39 43\" src=\"https://user-images.githubusercontent.com/19766770/184125693-b08fef99-abf7-4929-8be8-4aabebc0a7f5.png\">\r\n","createdAt":"2022-08-11T11:48:13Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[{"content":"THUMBS_UP","users":{"totalCount":1}}],"url":"https://github.com/dandavison/delta/issues/549#issuecomment-1211881415","viewerDidAuthor":false}],"number":549,"title":"🐛 side-by-side does not apply zero-styles for empty lines"},{"body":"Hi! I'm noticing that if I have the following style settings:\r\n\r\n```\r\nminus-style = red\r\nminus-emph-style = bold underline red\r\nminus-non-emph-style = syntax\r\nplus-style = green\r\nplus-emph-style = bold underline green\r\nplus-non-emph-style = syntax\r\n```\r\n\r\nThen the `minus/plus-non-emph-style` seems to use `normal` instead of `syntax` highlighting:\r\n<img width=\"1371\" alt=\"Screen Shot 2021-03-21 at 12 41 39 AM\" src=\"https://user-images.githubusercontent.com/4534726/111897682-a5a91a00-89de-11eb-8589-32b7400e4c9b.png\">\r\n\r\nHowever, if I use:\r\n\r\n```\r\nminus-style = syntax\r\nminus-emph-style = bold underline red\r\nminus-non-emph-style = syntax\r\nplus-style = syntax\r\nplus-emph-style = bold underline green\r\nplus-non-emph-style = syntax\r\n```\r\n\r\nThen the `minus/plus-non-emph-style` will use `syntax` as expected:\r\n\r\n\r\n<img width=\"1378\" alt=\"Screen Shot 2021-03-21 at 12 42 52 AM\" src=\"https://user-images.githubusercontent.com/4534726/111897689-aa6dce00-89de-11eb-82f9-7d71a052cd09.png\">\r\n\r\n\r\nHowever, I'm trying to get it such that only the meaningful changes are red/green while everything else is syntax highlighted. I could see why this would be difficult to implement, so I wasn't sure if this was expected behavior. Couldn't find it documented anywhere.\r\n\r\nFantastic plugin btw, I really appreciate all the work done on this 🙂 \r\n\r\n\r\nIf it helps, the raw output of the screenshotted section using `git --no-pager diff`:\r\n```\r\n \" buffer navigation\r\n nnoremap <silent> <Backspace> <C-^>\r\n nnoremap <silent> <Leader>l :Buffers<CR>\r\n-nnoremap <silent> <Leader>{ :bprevious<CR>\r\n-nnoremap <silent> <Leader>} :bnext<CR>\r\n-nnoremap <silent> Q :bprevious <Bar> bdelete #<CR>\r\n+nnoremap <silent> <Leader>[ :bprevious<CR>\r\n+nnoremap <silent> <Leader>] :bnext<CR>\r\n nnoremap <silent> <Leader>; :BLines<CR>\r\n nnoremap <silent> <Leader>: :Lines<CR>\r\n+nnoremap <silent> Q :bprevious <Bar> bdelete #<CR>\r\n\r\n \" tab navigation\r\n-nnoremap <silent> <Leader>[ :tabp<CR>\r\n-nnoremap <silent> <Leader>] :tabn<CR>\r\n+nnoremap <silent> <Leader>{ :tabp<CR>\r\n+nnoremap <silent> <Leader>} :tabn<CR>\r\n```","comments":[{"id":"MDEyOklzc3VlQ29tbWVudDgwMzU1NDk0NQ==","author":{"login":"dandavison"},"authorAssociation":"OWNER","body":"Hi @jearbear, thanks very much for this. I can reproduce it and agree it seems like a bug. I'll look into a fix!","createdAt":"2021-03-21T11:01:05Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/545#issuecomment-803554945","viewerDidAuthor":true}],"number":545,"title":"🐛 `syntax` not respected for `*-non-emph-style`"},{"body":"I stumbled upon [Graphtage](https://github.com/trailofbits/graphtage) and found it a cool idea. It would be nice if `delta` could integrate it (and other projects like it - \"semantic diffs\") for specific file types. What do you think?","comments":[{"id":"IC_kwDOC4j8g847H5wj","author":{"login":"dandavison"},"authorAssociation":"OWNER","body":"Hi @boris-petrov sorry to be so slow replying to this one.\r\n\r\nCan you be explicit about what sort of integration might make sense? It doesn't look like graphtage produces diff format AFAICS. So are you thinking of any of the following?\r\n\r\n1. User can do `graphtage a.json b.json | delta` (but how is that any better than `graphtage a.json b.json`)?\r\n2. User can do `delta a.json b.json` and have graphtage-like output (ok, but that is tantamount to re-implementing graphtage in Rust; delta is really a diff *viewer* not a diff *generator*)\r\n3. Something else?\r\n","createdAt":"2021-12-12T16:23:10Z","includesCreatedEdit":true,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/535#issuecomment-991927331","viewerDidAuthor":true},{"id":"IC_kwDOC4j8g847H7qJ","author":{"login":"bew"},"authorAssociation":"NONE","body":"FYI there's a project similar to delta that does exactly this (in Rust):\r\nhttps://github.com/Wilfred/difftastic\r\n(not as pretty/configurable as delta though)\r\n\r\nMaybe there's some inspiration to take here?","createdAt":"2021-12-12T17:10:40Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[{"content":"THUMBS_UP","users":{"totalCount":5}},{"content":"HEART","users":{"totalCount":1}}],"url":"https://github.com/dandavison/delta/issues/535#issuecomment-991935113","viewerDidAuthor":false},{"id":"IC_kwDOC4j8g847H-QV","author":{"login":"dandavison"},"authorAssociation":"OWNER","body":"> FYI there's a project similar to delta that does exactly this (in Rust): https://github.com/Wilfred/difftastic\r\n\r\nRight, difftastic looks great. I'd seen it before and meant to look more closely. One form of integration there could perhaps be difftastic emitting JSON and delta displaying it.","createdAt":"2021-12-12T18:17:40Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[{"content":"THUMBS_UP","users":{"totalCount":1}},{"content":"HEART","users":{"totalCount":13}}],"url":"https://github.com/dandavison/delta/issues/535#issuecomment-991945749","viewerDidAuthor":true},{"id":"IC_kwDOC4j8g85aRHXc","author":{"login":"marcelarie"},"authorAssociation":"NONE","body":"Is the support for difftastic available? ","createdAt":"2023-04-19T09:41:25Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[{"content":"THUMBS_UP","users":{"totalCount":1}},{"content":"HEART","users":{"totalCount":1}},{"content":"EYES","users":{"totalCount":2}}],"url":"https://github.com/dandavison/delta/issues/535#issuecomment-1514436060","viewerDidAuthor":false},{"id":"IC_kwDOC4j8g85aSo0P","author":{"login":"dandavison"},"authorAssociation":"OWNER","body":"> Is the support for difftastic available?\r\n\r\nNot as far as I know. Looks like one path would be if a PR like this one is merged in difftastic: https://github.com/Wilfred/difftastic/pull/158\r\n\r\nand then someone implements rendering of that JSON in delta. Delta already renders `ripgrep --json` output, so perhaps that implementation will be helpful when working on the difftastic JSON. (I guess in an ideal world there would be a standard format for describing token-level diffs regardless of their provenance; perhaps then difftastic and `git diff --word-diff` output could be the same format??)","createdAt":"2023-04-19T14:25:47Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[{"content":"THUMBS_UP","users":{"totalCount":6}},{"content":"HEART","users":{"totalCount":1}}],"url":"https://github.com/dandavison/delta/issues/535#issuecomment-1514835215","viewerDidAuthor":true},{"id":"IC_kwDOC4j8g85aSw6a","author":{"login":"marcelarie"},"authorAssociation":"NONE","body":"Ok thanks for the info. As far as I know, JSON is not the fastest to parse, right? Maybe something more raw would be better. 🤷🏽 ","createdAt":"2023-04-19T14:44:38Z","includesCreatedEdit":true,"isMinimized":false,"minimizedReason":"","reactionGroups":[{"content":"THUMBS_UP","users":{"totalCount":1}}],"url":"https://github.com/dandavison/delta/issues/535#issuecomment-1514868378","viewerDidAuthor":false},{"id":"IC_kwDOC4j8g85aTa7G","author":{"login":"Guekka"},"authorAssociation":"NONE","body":"> As far as I know, JSON is not the fastest to parse, right? Maybe something more raw would be better. 🤷🏽\r\n\r\nI don't think that's an issue. Parsing JSON [can be very fast](https://github.com/simdjson/simdjson). And diffing is way more expensive than any parsing could be","createdAt":"2023-04-19T16:33:41Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[{"content":"THUMBS_UP","users":{"totalCount":7}},{"content":"HEART","users":{"totalCount":1}}],"url":"https://github.com/dandavison/delta/issues/535#issuecomment-1515040454","viewerDidAuthor":false},{"id":"IC_kwDOC4j8g85kShbK","author":{"login":"marcelarie"},"authorAssociation":"NONE","body":"The PR on `difftastic` to output JSON has been successfully merged: https://github.com/Wilfred/difftastic/pull/158#issuecomment-1682537893","createdAt":"2023-08-17T16:14:53Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[{"content":"THUMBS_UP","users":{"totalCount":1}},{"content":"HOORAY","users":{"totalCount":21}},{"content":"HEART","users":{"totalCount":2}}],"url":"https://github.com/dandavison/delta/issues/535#issuecomment-1682577098","viewerDidAuthor":false},{"id":"IC_kwDOC4j8g85w1tPL","author":{"login":"ding-weibing"},"authorAssociation":"NONE","body":"> > Is the support for difftastic available?\r\n> \r\n> Not as far as I know. Looks like one path would be if a PR like this one is merged in difftastic: [Wilfred/difftastic#158](https://github.com/Wilfred/difftastic/pull/158)\r\n> \r\n> and then someone implements rendering of that JSON in delta. Delta already renders `ripgrep --json` output, so perhaps that implementation will be helpful when working on the difftastic JSON. (I guess in an ideal world there would be a standard format for describing token-level diffs regardless of their provenance; perhaps then difftastic and `git diff --word-diff` output could be the same format??)\r\n\r\nHi @dandavison,\r\n\r\nBased on the recent discussion at [Delta Issue #535](https://github.com/dandavison/delta/issues/535#issuecomment-1682577098), it seems there might be an opportunity to address the support issue with difftastic. While I am not highly familiar with Rust, I am eager to contribute to this effort. If you could guide me on which parts of the code require modifications, I would be delighted to make a commit. Thank you for your assistance and insight.","createdAt":"2024-01-16T06:10:49Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[{"content":"THUMBS_UP","users":{"totalCount":1}},{"content":"HEART","users":{"totalCount":10}}],"url":"https://github.com/dandavison/delta/issues/535#issuecomment-1893127115","viewerDidAuthor":false}],"number":535,"title":"🚀 Integration with Graphtage or Difftastic"},{"body":"Hi, at first glance I couldn't find any open or closed issues on this topic. Please excuse me if I missed one.\r\n\r\nRecently, while viewing a particular diff, I noticed that every indented line was highlighted as a difference, even though the code itself was not changed, other than being indented by _spaces_ vs. _tabs_. (PKGBUILD's are interpreted by bash, so indentation doesn't matter).\r\n\r\n\r\n\r\n\r\nTherefore, I think it might be useful to have an option which allows displaying whitespace characters using one or more user-defined glyphs, and/or applying the `delta.{plus,minus}-emph-style` settings to whitespace changes.\r\n\r\nIn the case that the characters to display tabs were be defined as `'‣·'` and tab size as `4`, I would imagine something like :\r\n\r\n\r\n","comments":[{"id":"MDEyOklzc3VlQ29tbWVudDc3ODMzNzcwMA==","author":{"login":"dandavison"},"authorAssociation":"OWNER","body":"Hi @Kr1ss-XD can I just check -- passing `-w` (`--ignore-all-space`) to git diff/show/etc works with delta already. Are you suggesting the new delta functionality would be worth adding, in addition to what we have with `-w`?","createdAt":"2021-02-12T17:37:32Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/522#issuecomment-778337700","viewerDidAuthor":true},{"id":"MDEyOklzc3VlQ29tbWVudDc3ODM0MTA0Mg==","author":{"login":"Kr1ss-XD"},"authorAssociation":"CONTRIBUTOR","body":"Yes, that's correct. I would like to be able to see whitespace changes, but also to distinguish them from other differences on a glance.","createdAt":"2021-02-12T17:43:50Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/522#issuecomment-778341042","viewerDidAuthor":false},{"id":"MDEyOklzc3VlQ29tbWVudDc3ODM5MzgyMw==","author":{"login":"dandavison"},"authorAssociation":"OWNER","body":"I see. It almost feels like there could be a git option for rendering tabs as visible characters doesn't it? But there doesn't seem to be one. Just playing around with possibilities, this seems quite nice:\r\n\r\n```gitconfig\r\n[core]\r\n pager = sed 's/\\t/├──┤/g' | delta\r\n```\r\n\r\nSo is this as simple as allowing the user to supply a string to substitute tabs? Here's a quick branch implementing that, do you want to try it out? https://github.com/dandavison/delta/pull/523 E.g.\r\n\r\n```\r\ngit -c delta.tab-string='├──┤' diff\r\n```\r\n\r\n<table><tr><td><img width=800px src=\"https://user-images.githubusercontent.com/52205/107811466-30418e00-6d3c-11eb-9836-81596caac7f6.png\" alt=\"image\" /></td></tr></table>\r\n\r\n","createdAt":"2021-02-12T19:13:25Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[{"content":"THUMBS_UP","users":{"totalCount":3}}],"url":"https://github.com/dandavison/delta/issues/522#issuecomment-778393823","viewerDidAuthor":true},{"id":"MDEyOklzc3VlQ29tbWVudDc3ODQwMDg5Ng==","author":{"login":"Kr1ss-XD"},"authorAssociation":"CONTRIBUTOR","body":"Nice, I guess that's exactly what I was looking for.\r\n\r\nI'll check out that branch and build it. Thanks a lot !","createdAt":"2021-02-12T19:21:19Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/522#issuecomment-778400896","viewerDidAuthor":false},{"id":"MDEyOklzc3VlQ29tbWVudDc3ODQwNzc4Mg==","author":{"login":"Kr1ss-XD"},"authorAssociation":"CONTRIBUTOR","body":"It's working fine @dandavison :+1: ","createdAt":"2021-02-12T19:34:39Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/522#issuecomment-778407782","viewerDidAuthor":false},{"id":"MDEyOklzc3VlQ29tbWVudDc3ODQwOTkwNQ==","author":{"login":"dandavison"},"authorAssociation":"OWNER","body":"Great. One question is do we consider the breaking change of getting rid of the `tabs` option, since if we go with the new branch it's redundant since any number of spaces can be provided explicitly. I guess it can be marked as deprecated (but we are not yet at 1.0 so I suppose the point of 0.x is you're allowed to break backwards compatibility while setting down.)","createdAt":"2021-02-12T19:38:49Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/522#issuecomment-778409905","viewerDidAuthor":true},{"id":"MDEyOklzc3VlQ29tbWVudDc3ODQxNzAwOQ==","author":{"login":"Kr1ss-XD"},"authorAssociation":"CONTRIBUTOR","body":"I'd say there are - at least - two ways to handle this.\r\n\r\n1. deprecate `delta.tabs` in favor of `delta.tab-string` (and break backwards compatibility), or\r\n2. maybe keep `tabs`, and let `tab-string` accept 1, 2 or 3 characters. If one character is given, repeat it `tabs` times. If there are two chars, print the first one and repeat the 2nd character `tabs`-1 times. If `tab_strings` contains three characters, print the 1st one, print the second one `tabs`-2 times, then print the 3rd character.\r\n\r\n>I suppose the point of 0.x is you're allowed to break backwards compatibility while setting down.\r\n\r\nThat's my understanding, too. Though I'd say it's preferable to prevent breaking changes if possible.","createdAt":"2021-02-12T19:50:42Z","includesCreatedEdit":true,"isMinimized":false,"minimizedReason":"","reactionGroups":[{"content":"THUMBS_UP","users":{"totalCount":1}}],"url":"https://github.com/dandavison/delta/issues/522#issuecomment-778417009","viewerDidAuthor":false},{"id":"MDEyOklzc3VlQ29tbWVudDc3OTQ3ODcyNg==","author":{"login":"th1000s"},"authorAssociation":"COLLABORATOR","body":"Speaking of tabs, when replacing them `delta` currently uses a fixed number of spaces. However these replacements must stop at a multiple of the tab width, counted from the start of the line:\r\n\r\n 1\\tX 1 X 1‣······X\r\n 12\\tX which looks like 12 X and delta then might 12‣·····X\r\n 123\\tX this with a tab- 123 X render them like this: 123‣····X\r\n 1234\\tX width of 8 1234 X 1234‣···X\r\n 1234567\\tX 1234567 X 1234567‣X\r\n\r\nAlso maybe use a more muted color than white, e.g. gray or blue as `vim` does with `:set list`.","createdAt":"2021-02-15T22:40:12Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/522#issuecomment-779478726","viewerDidAuthor":false},{"id":"MDEyOklzc3VlQ29tbWVudDgzMjUzMjIzOQ==","author":{"login":"robinmoussu"},"authorAssociation":"NONE","body":"If possible, I think it would be great to make clearer that lines that contains only whitespace change don’t introduce other modifications.\r\n\r\n<img width=\"456\" alt=\"current\" src=\"https://user-images.githubusercontent.com/6200547/117118022-8567cb80-ad90-11eb-9c55-e7c9f9035627.png\">\r\n\r\nIn this example, it doesn’t seems like the first line is really an addition, because of the whitespace changes on the next lines. I think the easiest change would be to use the light green background for lines that are entirely new. The same logic can be used for lines that where completely removed.\r\n\r\n<img width=\"456\" alt=\"proposed\" src=\"https://user-images.githubusercontent.com/6200547/117118410-04f59a80-ad91-11eb-999d-c2eea342adc6.png\">\r\n\r\n","createdAt":"2021-05-05T09:02:24Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/522#issuecomment-832532239","viewerDidAuthor":false},{"id":"MDEyOklzc3VlQ29tbWVudDgzMzg3ODg1OQ==","author":{"login":"th1000s"},"authorAssociation":"COLLABORATOR","body":"@robinmoussu also see PR #13 which among other things discusses that single changed words are emphasized more than an entire added or removed line.","createdAt":"2021-05-06T21:26:17Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[{"content":"THUMBS_UP","users":{"totalCount":1}}],"url":"https://github.com/dandavison/delta/issues/522#issuecomment-833878859","viewerDidAuthor":false},{"id":"MDEyOklzc3VlQ29tbWVudDgzNTk5OTA0NA==","author":{"login":"dandavison"},"authorAssociation":"OWNER","body":"@robinmoussu, @th1000s putting aside temporarily the question of what the defaults should be, what I would like to be true is that delta's style configuration options can achieve any of these desired highlighting styles. (Seeing as there are so many options, it seems like it must be a bug for things like this to be non-achievable!)\r\n\r\nI believe that the example above can be achieved by making `plus-style` the same as `plus-emph-style`, right? Specifically, I usually use a light background, and `delta --show-config` shows\r\n\r\n<table><tr><td><img width=400px src=\"https://user-images.githubusercontent.com/52205/117592589-2941d600-b107-11eb-898b-aa7ec1506abc.png\" alt=\"image\" /></td></tr></table>\r\n\r\nwhich gives this diff:\r\n\r\n<table><tr><td><img width=400px src=\"https://user-images.githubusercontent.com/52205/117592394-5641b900-b106-11eb-95aa-4719b170ae94.png\" alt=\"image\" /></td></tr></table>\r\n\r\nSo now if we make `plus-style` be the same as `plus-emph-style`,\r\n\r\n<table><tr><td><img width=400px src=\"https://user-images.githubusercontent.com/52205/117592496-bfc1c780-b106-11eb-906b-8ef02b1bbd7b.png\" alt=\"image\" /></td></tr></table>\r\n\r\nit looks like this\r\n\r\n<table><tr><td><img width=400px src=\"https://user-images.githubusercontent.com/52205/117592635-51c9d000-b107-11eb-9055-4464cc060e96.png\" alt=\"image\" /></td></tr></table>\r\n\r\n\r\nI also haven't forgotten about @nkouevda's PR #13, which dates from before delta gained its `*-style` options. As I said in that PR, delta's highlighting style was largely influenced by what Github does, and they reserve the emph color for individual words, not whole lines. But I don't think I could argue that that's clearly correct! So it seems that what we should do, even if we do not change defaults at this stage, it to make a version of the new-lines-get-emph-color behavior available as an option; hopefully the example I gave above proves that that will be easy to do since the option API already supports it.","createdAt":"2021-05-10T00:57:57Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[{"content":"THUMBS_UP","users":{"totalCount":1}}],"url":"https://github.com/dandavison/delta/issues/522#issuecomment-835999044","viewerDidAuthor":true},{"id":"IC_kwDOC4j8g8440D2t","author":{"login":"dhduvall"},"authorAssociation":"NONE","body":"IMHO, the `--tabs` option is still useful, since it's how you get raw tabs in the output (if you want that), and with tab alignment (#729, #751), people using tabs for code alignment can see their diffs using the same tabstops their code uses.\r\n\r\nAlso, I would suggest using a vim-style configuration for this, where you can set the characters replacing the space and the beginning, end, and middle of a tab. What vim doesn't do (and I would like) is to configure what you use for a tab expanding to a single column, and maybe also for two columns.\r\n\r\nAlso, should all tabs and spaces be replaced with these characters, only those on lines that have changed, or only those that have actually changed? (And should this be configurable?)\r\n\r\nI have a *very* crude change on top of #752, but as you can see, it still needs some work:\r\n\r\n<img width=\"781\" alt=\"Screen Shot of visualized tabs\" src=\"https://user-images.githubusercontent.com/7074165/139119475-a4bddd45-b179-40ae-ae95-3e96cddea7b5.png\">\r\n\r\n","createdAt":"2021-10-27T17:53:03Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/522#issuecomment-953171373","viewerDidAuthor":false},{"id":"IC_kwDOC4j8g8482QPc","author":{"login":"alfredbez"},"authorAssociation":"NONE","body":"Just for reference: Git also [has an option](https://stackoverflow.com/a/58037244/2123108) to show invisible or non-printable characters via `--ws-error-highlight=all`.","createdAt":"2022-01-25T06:30:05Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/522#issuecomment-1020855260","viewerDidAuthor":false},{"id":"IC_kwDOC4j8g85YBGdX","author":{"login":"mentalisttraceur"},"authorAssociation":"NONE","body":"I would really appreciate something like [`bat --show-all`](https://github.com/sharkdp/bat/tree/d20405b975ee4e0927e39d4ba9ef89991a41d685#show-non-printable-characters), more than the other possibilities being discussed here.\r\n\r\nSince `delta` is using code from `bat` for its syntax highlighting anyway, I think we can just [pass through a boolean](https://docs.rs/bat/latest/bat/config/struct.Config.html#structfield.show_nonprintable) and have `bat` take care of the rest (edge-cases like combining and double-width characters, ambiguities like a literal `·` appearing in the actual diff'ed text, ...).\r\n\r\nI also think having a \"show all invisible characters\" option, rather than something specific to just tabs, would map a lot better to user expectations, since it's found in so many IDEs/editors/tools - many devs are familiar with it, and already have trained up their minds to visually parse those kinds of visual cues for invisible characters. For example, when I first ran into the problem of `delta` hiding a spaces-to-tab change (which I'd normally spot as a single-column misalignment in a vanilla `git diff`), my first through was to look for a \"show all/hidden/whitespace/invisible characters\" option in the help text, webpage, and then here.","createdAt":"2023-03-20T17:51:34Z","includesCreatedEdit":true,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/522#issuecomment-1476683607","viewerDidAuthor":false},{"id":"IC_kwDOC4j8g85YBPq5","author":{"login":"dandavison"},"authorAssociation":"OWNER","body":"> Since delta is using code from bat for its syntax highlighting anyway\r\n\r\nHi @mentalisttraceur, this isn't true, but I'm curious where you got that idea from, since I see it said quite a bit!","createdAt":"2023-03-20T18:16:44Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[{"content":"THUMBS_UP","users":{"totalCount":1}}],"url":"https://github.com/dandavison/delta/issues/522#issuecomment-1476721337","viewerDidAuthor":true},{"id":"IC_kwDOC4j8g85YBYK-","author":{"login":"mentalisttraceur"},"authorAssociation":"NONE","body":"@dandavison I think the strongest reason was the quote (emphasis added) \"`delta` does not use `bat` when it is running (*it does use some code from the excellent `bat` project*, but users don't need to be aware of this)\" on [your page about `delta`'s use of pager environment variables](https://dandavison.github.io/delta/environment-variables.html?highlight=bat#pager-environment-variables), compounded by other mentions of `bat` in the context of `delta` themes such as [here](https://dandavison.github.io/delta/supported-languages-and-themes.html?highlight=bat#supported-languages-and-themes) and [here](https://dandavison.github.io/delta/custom-themes.html?highlight=bat#custom-themes). (And maybe I've seen other people say it too, I can't remember.)\r\n\r\nAll together, that gave me the impression that there was significant code reuse, and my first thought would be to try to reuse it for any heavy lifting needed to syntax-highlight the text inside the diff markers.","createdAt":"2023-03-20T18:45:17Z","includesCreatedEdit":true,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/522#issuecomment-1476756158","viewerDidAuthor":false},{"id":"IC_kwDOC4j8g85YBaRb","author":{"login":"dandavison"},"authorAssociation":"OWNER","body":"Right, it's funny, I added those sentences to try to dispel the belief that delta used code from bat for syntax highlighting, but I can see it's confusing especially if people come with a prior belief that it does. Delta uses bat code for things like launching the pager process, and it uses the color themes and language definitions that bat uses. But the low-level details of syntax highlighting are implemented independently in bat and delta, both using the same underlying library (syntect).","createdAt":"2023-03-20T18:52:45Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[{"content":"THUMBS_UP","users":{"totalCount":2}}],"url":"https://github.com/dandavison/delta/issues/522#issuecomment-1476764763","viewerDidAuthor":true},{"id":"IC_kwDOC4j8g85YBd0k","author":{"login":"mentalisttraceur"},"authorAssociation":"NONE","body":"Gotcha, thanks for clarifying!\r\n\r\nIf I think of any better wording or place for more precisely/unambiguously mitigating that misunderstanding I'll let you know!\r\n\r\nIn any case, I would love a `--show-all` option, and I think `bat` is a good example of it done well.","createdAt":"2023-03-20T19:00:09Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/522#issuecomment-1476779300","viewerDidAuthor":false},{"id":"IC_kwDOC4j8g85YFAop","author":{"login":"dandavison"},"authorAssociation":"OWNER","body":"@mentalisttraceur, I agree, I use `bat -A` a lot.\r\n\r\nI haven't thought too hard about how helpful this is but FWIW here's a conversation with GPT4 about this issue.\r\n\r\n-------\r\n\r\n> Can you summarize the following git-delta issue and suggest next steps?\r\n> [paste entire text copied from browser including title]\r\n\r\nThe git-delta issue #522 discusses the need for a feature to make whitespace changes visible and distinguishable from other changes in a diff. The main problem raised is that when viewing a diff, indented lines are highlighted as differences, even though the code is not changed, but only indented with spaces or tabs. The proposed solution is to have an option to display whitespace characters using user-defined glyphs and/or applying specific delta styles to whitespace changes.\r\n\r\nThroughout the conversation, there are various suggestions and implementations shared. The initial idea is to allow the user to supply a string to substitute tabs. However, it evolves to include discussions about how to handle the deprecated delta.tabs in favor of delta.tab-string and whether to break backward compatibility.\r\n\r\nThe conversation also covers topics such as:\r\n\r\n- Tab alignment and the possibility of using a vim-style configuration for tab replacement characters.\r\n- Showing invisible or non-printable characters with Git's `--ws-error-highlight=all` option.\r\n- The possibility of adding a `--show-all` option similar to the bat tool.\r\n\r\nNext steps:\r\n\r\n1. Assess the feasibility and potential impact of the suggested implementations and decide on the most suitable approach.\r\n2. Implement the chosen solution, ensuring that it addresses the issue raised and is compatible with existing features.\r\n3. Test the implemented solution thoroughly to ensure it works as expected and does not introduce new issues.\r\n4. Update documentation and provide examples of how to use the new feature.\r\nClose the issue after successful implementation and testing.\r\n\r\n> Can you give a specific suggestion for a next step as follows:\r\n> 1. The proposed change to delta's behavior and user experience\r\n> 2. The proposed implementation\r\n\r\n1. Proposed change to delta's behavior and user experience:\r\n\r\n - Introduce a `--show-all` option that, when enabled, will display all invisible characters in the diff, such as spaces and tabs. This option will help users to quickly identify and distinguish between whitespace changes and other changes in the code. The feature should be inspired by the similar functionality in the bat tool, ensuring that it is familiar and intuitive for users.\r\n\r\n2. Proposed implementation:\r\n\r\n - Add a new command-line flag `--show-all` to the list of options accepted by delta.\r\n - In the processing stage where delta is handling the diff, check if the `--show-all` flag is enabled. If so, replace the invisible characters (e.g., spaces and tabs) with their corresponding visible glyphs (e.g., '·' for space and '‣' for tab).\r\n - Ensure that the new feature is compatible with other delta options such as `--ignore-all-space` and works seamlessly with delta's styles and themes.\r\n - Add tests to verify that the new feature works as expected and does not introduce new issues or conflicts with existing functionality.\r\n - Update the documentation and help messages to include the new `--show-all` option, providing examples of its usage and explaining its purpose.\r\n\r\n> Is the idea of the `--show-all` option to explain to the user _differences_ in whitespace between the old and new version of the file, or is it simply to show which whitespace characters are in use even when they haven't changed?\r\n\r\nApologies for any confusion in my previous response. The idea of the `--show-all` option is to display all whitespace characters in use, regardless of whether they have changed or not. This will help users visualize the actual structure of the code, including spaces and tabs, making it easier for them to understand the formatting and indentation. It does not specifically highlight the differences in whitespace between the old and new versions of the file. However, by making the whitespace characters visible, users can more easily identify and compare the changes in whitespace themselves.\r\n\r\n> How do you propose that delta should display differences in whitespace characters between the old and new version?\r\n\r\nDelta could use a combination of colors and symbols to indicate the differences in whitespace characters. For example, it could use different colors for changed spaces and tabs, and a separate color for unchanged whitespace characters.\r\n\r\nHere is an ASCII representation of how it could look:\r\n\r\n```\r\nOld version:\r\nif (condition) {\r\n····doSomething();\r\n}\r\n\r\nNew version:\r\nif (condition) {\r\n‣‣‣‣doSomething();\r\n}\r\n```\r\n\r\nIn this example:\r\n\r\n- · represents a space character from the old version\r\n- ‣ represents a tab character from the new version\r\nDelta could use a light red background color for the removed spaces (represented by ·) and a light green background color for the added tabs (represented by ‣). This would make it clear that spaces were removed and replaced with tabs.\r\n\r\nPlease note that this is a text-based representation, and the actual implementation in delta would involve colors and custom symbols to create a more visually appealing and informative display.","createdAt":"2023-03-21T11:56:34Z","includesCreatedEdit":true,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/522#issuecomment-1477708329","viewerDidAuthor":true},{"id":"IC_kwDOC4j8g85YUPRL","author":{"login":"mentalisttraceur"},"authorAssociation":"NONE","body":"Sounds like I convinced ChatGPT4 😄.\r\n\r\nI appreciate that you publicly shared that - I hadn't thought to use AI as a thinking aid like that, seems useful!\r\n\r\nI basically agree with its recommendations - obviously to be precise, we probably don't want a full tab represented by just *one* single-width character (I'm tempted to say \"that's what it meant\", in the sense that if a human said this, I'd suppose that's probably what they meant).\r\n\r\nAs for coloring, I imagine the coloring of the whitespace characters to be like syntax highlighting now: if style includes `syntax`, the special character stand-ins would have the same foreground/text colors on all lines (maybe just copy how `bat -A` colors them), and the background color would indicate removed/added/moved. (Of course if someone customizes the style to have a foreground color override the syntax coloring, that overrides.)","createdAt":"2023-03-23T18:28:46Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/522#issuecomment-1481700427","viewerDidAuthor":false},{"id":"IC_kwDOC4j8g85oobcH","author":{"login":"thecaralice"},"authorAssociation":"NONE","body":"As someone who prefers using tabs in code I'd also be happy to see an option for rendering a tab to just a sequence of spaces and rendering spaces as some kind of a middle dot or a fancy underscore or something (should I open a PR for that?)","createdAt":"2023-10-10T13:27:03Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/522#issuecomment-1755428615","viewerDidAuthor":false}],"number":522,"title":"🚀 make whitespace changes visible as such"},{"body":"Hi, I guess that what I’d like to do already exists, but I wasn’t able to find the option in the documentation.\r\n\r\nI have a file that is mostly text, except for a single `\\0` in the middle. I have another one which is text + ansi escape color code. If I run `git diff --text` with delta as the difftool, the diff is perfectly rendered. However, if I run `git difftool -x delta --text`, I got the following message:\r\n\r\n> Binary files old and new differ\r\n\r\nI also get the same message if I try to run `delta` manually from the command line. How do I force `delta` to do the diff in text mode for binary file? Something like `--text`. I did not found anything useful by searching `text` and `binary` in the help, or in the Readme.","comments":[{"id":"IC_kwDOC4j8g86Fie8t","author":{"login":"tgross35"},"authorAssociation":"NONE","body":"`diff` has the `-a`/`--text` flag which just treats all files as text, it would be great to have this option in `delta`.","createdAt":"2024-07-19T22:26:50Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/516#issuecomment-2240409389","viewerDidAuthor":false},{"id":"IC_kwDOC4j8g86Fnlha","author":{"login":"th1000s"},"authorAssociation":"COLLABORATOR","body":"As you can see, delta can show the input *if* it actually reaches it. In the other cases the difftools which pipe data into delta need the `--text` flag. For the standalone `delta file1 file` case, with #1697 you will be able to call it with `-@=--text`.","createdAt":"2024-07-21T19:17:44Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/516#issuecomment-2241747034","viewerDidAuthor":false}],"number":516,"title":"🚀 How to force diff in text mode for binary file?"},{"body":"The options in the FLAGS and OPTIONS sections are colored with escape sequences even when the output is not a terminal, and this results in some garbage on the screen.","comments":[{"id":"MDEyOklzc3VlQ29tbWVudDg0NDkzOTA2OA==","author":{"login":"tpoliaw"},"authorAssociation":"CONTRIBUTOR","body":"Not sure if it's intentional behaviour or not but you can use `less -R` to show colours in less. If you set `LESS='-R'` (in .bashrc or similar) it will show colour by default.","createdAt":"2021-05-20T10:00:39Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/514#issuecomment-844939068","viewerDidAuthor":false},{"id":"MDEyOklzc3VlQ29tbWVudDg0NTgyMzU3Nw==","author":{"login":""},"authorAssociation":"NONE","body":"Thanks, @tpoliaw !\r\nMost people don't know about this option (or _any_ `less` option), though.\r\nAlso, `less` is not the only thing one might want to pipe to. `grep` comes to mind.\r\nIf the string I want to find in the quite long help output happens to have color sequences in it, it won't show up:\r\n\r\n```bash\r\n% delta --help | grep -C4 'default: raw'\r\n%\r\n```\r\n\r\nEven `ls`, which is usually used with color enabled, has its help (pretty long, like delta's) in black and white.","createdAt":"2021-05-21T09:37:09Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[{"content":"THUMBS_UP","users":{"totalCount":1}}],"url":"https://github.com/dandavison/delta/issues/514#issuecomment-845823577","viewerDidAuthor":false},{"id":"MDEyOklzc3VlQ29tbWVudDg0NTg0MTUyMg==","author":{"login":"tpoliaw"},"authorAssociation":"CONTRIBUTOR","body":"Absolutely, I think it would be better to only output colour if stdout is a tty. It was just a workaround for now to let less work.\r\n\r\nI might have a look at a PR to change this if @dandavison hasn't already got ideas or is against it.","createdAt":"2021-05-21T10:08:21Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/514#issuecomment-845841522","viewerDidAuthor":false},{"id":"MDEyOklzc3VlQ29tbWVudDg0NTg0NzUxMQ==","author":{"login":"tpoliaw"},"authorAssociation":"CONTRIBUTOR","body":"Looking at this, structopt defaults to only use colours for a tty and it's been explicitly set to always use colour [here](https://github.com/dandavison/delta/blob/feb89ac4387524c7ab571065cec7a190d1917f16/src/cli.rs#L20). I'll hold off the PR for now as it looks like a deliberate choice.","createdAt":"2021-05-21T10:18:51Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/514#issuecomment-845847511","viewerDidAuthor":false},{"id":"MDEyOklzc3VlQ29tbWVudDg0NjAzMjg1Nw==","author":{"login":"dandavison"},"authorAssociation":"OWNER","body":"Hi @lepotic, @tpoliaw you're right, I'm guilty here! I did deliberately set the help text to always be coloured. I did that because I wanted the colours to be present when I'm viewing the help text and, because the help text is long, I wanted to pipe it to less. I.e. I didn't like the alternative of allowing it to dump all the coloured output to the screen and then scrolling upwards to find what I wanted. I do see that of the other Rust CLIs `rg`, `bat`, and `exa`, none of them do what delta is doing.\r\n\r\n@tpoliaw it's always been in the back of my mind that the ideal would be for delta to automatically pipe its help text to less (when stdout is a tty) just like delta does with its normal output (again, when stdout is a tty). However, I've never looked into whether that is achievable with structopt. If you agree that that would be a good alternative and felt like investigating, that would be fantastic. A quick skim of the structopt/clap docs led me to https://docs.rs/clap/2.33.3/clap/struct.App.html#method.write_long_help which looks superficially like it could be used to write into a writer object with paging, i.e. such as delta creates here https://github.com/dandavison/delta/blob/feb89ac4387524c7ab571065cec7a190d1917f16/src/main.rs#L85-L86 and also in the `show_themes` and `show_syntax_themes` functions in the same file. But I can also imagine that we might run into problems and feel like we're fighting against clap, by trying to get `--help` to behave differently.\r\n\r\nThere's a tangentially related issue that it would be nice if `-h` showed a brief summary of options and `--help` the full text, and it appears that this is also possible with structopt https://docs.rs/structopt/0.3.21/structopt/#help-messages This is issue https://github.com/dandavison/delta/issues/377","createdAt":"2021-05-21T15:26:04Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/514#issuecomment-846032857","viewerDidAuthor":true},{"id":"MDEyOklzc3VlQ29tbWVudDg0NjE5NTkzOQ==","author":{"login":"tpoliaw"},"authorAssociation":"CONTRIBUTOR","body":">the ideal would be for delta to automatically pipe its help text to less\r\n\r\nThat could work. It's not what I'd generally expect from a help command but I can't see it being a bad thing. While many commands don't do it, there are several that do open less. `less` itself opens its help in itself, whereas the various git subcommands delegate to man to open their man page which in turn delegates to `less`, eg `git log --help` is equivalent to `man git-log`. \r\n\r\nLooking into how man shows formatting, it overrides user settings and sets `LESS` to `'-ix8Rm'` + a whole load of prompt logic (which I had no idea less could do) + the user's original `$LESS`. Maybe something like that would be the way to go for delta to ensure that the right flags are set. Is less ubiquitous enough to assume that every *nix(ish) system has it?\r\n\r\nI'll have a look when I get a chance. I'm doing some other stuff using structopt at the minute so I imagine I'm going to be spending some quality time reading through all their docs anyway.","createdAt":"2021-05-21T19:26:25Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/514#issuecomment-846195939","viewerDidAuthor":false},{"id":"MDEyOklzc3VlQ29tbWVudDg0NjIxMjM4Nw==","author":{"login":"dandavison"},"authorAssociation":"OWNER","body":"That would be great, and thanks for thinking about it.\r\n\r\n> Is less ubiquitous enough to assume that every *nix(ish) system has it?\r\n\r\nYes, I think we can assume that every delta user has less installed. Even on Windows, I believe the common way people install git involves git bundling a less binary, and I'm OK assuming that delta usage is very closely related to git usage.","createdAt":"2021-05-21T19:48:15Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/514#issuecomment-846212387","viewerDidAuthor":true},{"id":"MDEyOklzc3VlQ29tbWVudDg3NzY4NzM4OQ==","author":{"login":"c0dev0id"},"authorAssociation":"NONE","body":"I also came here to either ask for a manpage or a help output that I can read in a pager like less.\r\nSome tools provide --help and --long-help, this would be nice here as well.","createdAt":"2021-07-10T19:00:11Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/514#issuecomment-877687389","viewerDidAuthor":false},{"id":"MDEyOklzc3VlQ29tbWVudDg3NzcwNjAxNg==","author":{"login":"dandavison"},"authorAssociation":"OWNER","body":"> I also came here to either ask for a manpage or a help output that I can read in a pager like less.\r\n\r\nHi @c0dev0id, that exists! It's `delta --help`. It includes color to make the output more readable, so when piping to less you must include the `-R` flag.\r\n\r\nI am interested in making a short help version `-h` and long help `--help`, like `ripgrep` does, and I'm interested in having delta's help page automatically. (@tpoliaw did you learn anything about how one would achieve that with structopt?)\r\n\r\n> Most people don't know about this option (or any less option), though.\r\n\r\nI think I'm going to push back slightly here. delta is a tool for programmers, so it's OK to assume a slightly higher level of sophistication. If people didn't know it before, then the `-R` flag is definitely a good one to learn.\r\n\r\nFor grep, you can use ansifilter to remove colours, but I certainly agree that's a bit convoluted. I would say personally that piping into `less -R` and using the search facilities in `less` is going to be a better experience than grepping help output.\r\n\r\nI think delta's manual (i.e. `--help`) would be much less readable without colour:\r\n\r\n<table><tr><td><img width=500px src=\"https://user-images.githubusercontent.com/52205/125176608-9c7dcc00-e1cc-11eb-85bd-5bc91fb677bc.png\" alt=\"image\" /></td></tr></table>","createdAt":"2021-07-10T21:20:46Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/514#issuecomment-877706016","viewerDidAuthor":true},{"id":"MDEyOklzc3VlQ29tbWVudDg3Nzc1ODQ1OA==","author":{"login":"c0dev0id"},"authorAssociation":"NONE","body":"I think you focused at wrong part of the sentence.\r\n> ...or a help output **that I can read in a pager like less.**\r\n\r\n\r\n\r\nEDIT: Okay... the blame is on my side... I read too short and didn't know about `less -R`. That works.","createdAt":"2021-07-11T08:01:32Z","includesCreatedEdit":true,"isMinimized":false,"minimizedReason":"","reactionGroups":[{"content":"THUMBS_UP","users":{"totalCount":2}}],"url":"https://github.com/dandavison/delta/issues/514#issuecomment-877758458","viewerDidAuthor":false},{"id":"IC_kwDOC4j8g845bbk8","author":{"login":"zachriggle"},"authorAssociation":"NONE","body":"Agree with @dandavison -- especially since 99% of the functionality of `delta` is to add color to things, it doesn't make sense to NOT print colors when being piped somewhere.\r\n\r\n@c0dev0id If I can suggest some more settings, I use the following flags\r\n\r\n```\r\nexport LESS='--quit-if-one-screen --ignore-case --LONG-PROMPT --RAW-CONTROL-CHARS --chop-long-lines --no-init --window -4 --jump-target=.5'\r\n```\r\n\r\nWhere `-R` is equivalent to `--RAW-CONTROL-CHARS`.","createdAt":"2021-11-08T19:17:31Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[{"content":"THUMBS_UP","users":{"totalCount":1}}],"url":"https://github.com/dandavison/delta/issues/514#issuecomment-963492156","viewerDidAuthor":false}],"number":514,"title":"`delta --help | less` reveals the coloring escape sequences"},{"body":"Hi, thanks for contributing to Delta, please go ahead and describe your proposal!\r\n\r\nI discovered delta maybe a month ago and it's awesome! Thank you so much for making it, have already been spreading the word about it at work :)\r\n\r\nAfter initially setting delta up for usage with git, I learned it can also be used as a `diff` replacement, e.g. `delta <minus-file> <plus-file>` and have been using that functionality as well. However, the completions for delta only appear to complete options like `--color-only`. Normally in the lack of completions the shell would allow completing filenames, but because delta does ship a completion, the result is there is no autocompletion for file/directory names for the `<minus-file>` and `<plus-file>` arguments.\r\n\r\nSo, I'd like to request that the completions be extended to also support completing file/directory names.\r\n","comments":[{"id":"MDEyOklzc3VlQ29tbWVudDc1ODI4OTA4NA==","author":{"login":"jonathanpoelen"},"authorAssociation":"NONE","body":"On my system with zsh, there is an auto-completion for `delta` that has nothing to do with (`/usr/share/zsh/functions/Completion/Unix/_sccs`). Maybe you are in a similar situation? I made my own auto-completion: [_delta](https://github.com/jonathanpoelen/dotfiles/blob/master/.zshcompletions/_delta) and with `_comps[delta]=_ delta` after `compinit` to replace the original completion.","createdAt":"2021-01-11T23:27:49Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[{"content":"HOORAY","users":{"totalCount":1}},{"content":"HEART","users":{"totalCount":2}}],"url":"https://github.com/dandavison/delta/issues/501#issuecomment-758289084","viewerDidAuthor":false},{"id":"MDEyOklzc3VlQ29tbWVudDc1ODM1OTUxMQ==","author":{"login":"dandavison"},"authorAssociation":"OWNER","body":"Hi @aneeshusa @jonathanpoelen, agreed I also like to have completions working well but I've been neglecting the file that is in the delta repo.\n\nI wanted to mention that in the next release of delta, we'll be able to use `git -c`, e.g. something like `git -c delta.side-by-side=false diff`. It has occurred to me that it might be nice to somehow extend git completion to complete delta options after `-c`?","createdAt":"2021-01-12T02:50:49Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[{"content":"THUMBS_UP","users":{"totalCount":1}}],"url":"https://github.com/dandavison/delta/issues/501#issuecomment-758359511","viewerDidAuthor":true},{"id":"MDEyOklzc3VlQ29tbWVudDc1ODgxNjgxOA==","author":{"login":"Kr1ss-XD"},"authorAssociation":"CONTRIBUTOR","body":">It has occurred to me that it might be nice to somehow extend git completion to complete delta options after -c?\r\n\r\n:rocket: Absolutely, this would be great !","createdAt":"2021-01-12T17:29:16Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/501#issuecomment-758816818","viewerDidAuthor":false}],"number":501,"title":"🚀 Update completions to include local files/directories"},{"body":"In the example below, it appears that the syntax highlighter is remaining in state \"in-string\" when it starts processing `insert into`. Presumably there is a missing syntax highlighter reset call.\r\n\r\n<table><tr><td><img width=600px src=\"https://user-images.githubusercontent.com/52205/103796247-f7174f00-5014-11eb-93f0-ed8276d1739b.png\" alt=\"image\" /></td></tr></table>\r\n","comments":[{"id":"IC_kwDOC4j8g85xNNJe","author":{"login":"sskras"},"authorAssociation":"NONE","body":"I guess that's related to my issue too. This patch:\r\n```diff\r\n--- a/groups.d/231.native_packages_etc.group\r\n+++ b/groups.d/231.native_packages_etc.group\r\n@@ -372,7 +372,7 @@ gl_cv_func_getopt_gnu=yes\"};\r\n ac_cv_c_bigendian_php=no\r\n ac_cv_write_stdout=yes\r\n have_shm_mmap_posix=yes\"};\r\n-: ${PKG_PHP_CONFIGURE_ARGS_EXTRA:=\"--with-layout=GNU --with-external-pcre --with-gmp --disable-gd --disable-phar --enable-pdo=static --enable-dom=static --enable-embed=shared --enable-all=shared --without-enchant --without-imap --disable-intl --without-ldap --without-oci8 --without-adabas --disable-pcntl --without-pdo-dblib --without-pdo-firebird --without-pdo-mysql --without-pdo-oci --without-pdo-odbc --without-pdo-pgsql --without-pdo-sqlite --without-pgsql --without-pspell --without-libedit --without-sapdb --without-snmp --without-sodium --without-password-argon2 --without-tidy --without-ffi --without-mysqli --without-unixODBC --without-dbmaker --without-solid --with-pdo-odbc=no --without-ibm-db2 --without-empress --without-empress-bcs --without-iodbc --without-esoob --without-custom-odbc --without-pear --with-bz2=${PREFIX_NATIVE} --disable-opcache-jit --disable-dl-test\"};\r\n+: ${PKG_PHP_CONFIGURE_ARGS_EXTRA:=\"--with-layout=GNU --with-external-pcre --with-gmp --disable-gd --disable-phar --enable-pdo=static --enable-dom=static --enable-embed=shared --enable-all=shared --without-enchant --without-imap --disable-intl --without-ldap --without-oci8 --without-adabas --disable-pcntl --without-pdo-dblib --without-pdo-firebird --without-pdo-mysql --without-pdo-oci --without-pdo-odbc --without-pdo-pgsql --without-pdo-sqlite --without-pgsql --without-pspell --without-libedit --without-sapdb --without-snmp --without-sodium --without-password-argon2 --without-tidy --without-ffi --without-mysqli --without-unixODBC --without-dbmaker --without-solid --with-pdo-odbc=no --without-ibm-db2 --without-empress --without-empress-bcs --without-iodbc --without-esoob --without-custom-odbc --without-pear --with-bz2=${PREFIX_NATIVE} --with-gettext=${PREFIX_NATIVE} --disable-opcache-jit --disable-dl-test\"};\r\n : ${PKG_PHP_ENV_VARS_EXTRA:=\"HOST_CC=gcc:READLINE_DIR=${PREFIX_NATIVE}/include/readline\"};\r\n : ${PKG_PHP_MAKEFLAGS_PARALLELISE:=\"-j1\"};\r\n : ${PKG_PHP_LIBTOOL:=rdlibtool};\r\n```\r\n\r\n... produces this output:\r\n\r\n\r\n\r\nDifferences are trimmed. Any ETA of the fix?\r\n\r\nEDIT: Output of the `diffr` highlighter for a comparison:\r\n\r\n\r\n","createdAt":"2024-01-18T21:57:26Z","includesCreatedEdit":true,"isMinimized":false,"minimizedReason":"","reactionGroups":[{"content":"THUMBS_UP","users":{"totalCount":1}}],"url":"https://github.com/dandavison/delta/issues/491#issuecomment-1899287134","viewerDidAuthor":false}],"number":491,"title":"🐛 Syntax-highlighting incorrect after truncation due to max-line-length"},{"body":"Some tools (especially `bat`) check source files for a shebang line and if present use this to assign the according syntax rules. I'm wondering if this would be possible for `delta`, too.\r\n\r\nCurrently, a source file seems to be considered a specific language only if its name/extension can be mapped to a known language. Therefore, generically named files (e.g. executable shell scripts without `*.sh` filename extension) are not being syntax highlighted by `delta`. Considering a shebang could be an option in addition to filenames or [`--map-syntax`](https://github.com/dandavison/delta/issues/326).\r\n\r\nMaybe it's even possible to use the algorithm/regexes which `bat` has already implemented ?","comments":[{"id":"MDEyOklzc3VlQ29tbWVudDc1MzMzNTExNg==","author":{"login":"dandavison"},"authorAssociation":"OWNER","body":"Hi @Kr1ss-XD, the core issue here is that bat has access to the entire file, whereas delta (in its current form) only has access to the section of the file that happens to be in the diff hunk. It would be possible to change delta so that it (optionally) tries to find the file on disk (or from the git repo via libgit2). I have wondered from the beginning whether we would want to do that. Of course, the file might not even exist, since delta simply accepts whatever diff is given to it on stdin, which could be entirely fictional.","createdAt":"2021-01-01T16:20:01Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/485#issuecomment-753335116","viewerDidAuthor":true},{"id":"MDEyOklzc3VlQ29tbWVudDc1MzMzODEzMA==","author":{"login":"Kr1ss-XD"},"authorAssociation":"CONTRIBUTOR","body":"Right, I'm aware that it's not as simple for `delta` as for `bat` which is given a filename as argument most of the time.\r\n\r\nSince `delta` can recognize filenames in some cases, I wondered if it could utilize these to open the file and check its contents.\r\n\r\n> Of course, the file might not even exist, since delta simply accepts whatever diff is given to it on stdin, which could be entirely fictional.\r\n\r\nI haven't considered this though.","createdAt":"2021-01-01T16:28:03Z","includesCreatedEdit":true,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/485#issuecomment-753338130","viewerDidAuthor":false},{"id":"MDEyOklzc3VlQ29tbWVudDc1MzM0MzcyMQ==","author":{"login":"dandavison"},"authorAssociation":"OWNER","body":"> Since delta can recognize filenames in some cases, I wondered if it could utilize these to open the file and check its contents.\r\n\r\nYes, I agree, this would be possible. And as you say, for things like executable shell scripts, I think it's the only way forwards.","createdAt":"2021-01-01T16:55:09Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[{"content":"THUMBS_UP","users":{"totalCount":1}}],"url":"https://github.com/dandavison/delta/issues/485#issuecomment-753343721","viewerDidAuthor":true},{"id":"MDEyOklzc3VlQ29tbWVudDg3ODY4NjYxNA==","author":{"login":"zachriggle"},"authorAssociation":"NONE","body":"This would be really nice, @dandavison.\r\n\r\n### Problem\r\n\r\nI have a lot of e.g. Python scripts without the `.py` extension, and having a colorized Python-syntax-highlighted diff for these and this would be a game-changer.\r\n\r\n`delta` should be able to auto-detect the language of files in the diff by parsing the hunk headers and running e.g. `file` on them.\r\n\r\nThis could be a step that is only run when the filename has no extension at all, so it shouldn't be computationally expensive. You can rely on `file` so there's no need to even parse the shebang line (which can get complicated).\r\n\r\n```\r\n$ file bin/my-issues\r\nbin/my-issues: Python script text executable, Unicode text, UTF-8 text\r\n\r\n$ git log -p bin/my-issues | delta -n\r\n━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┓\r\ncommit cde440bb4ea6ae2b957c6ba9fa59640c596af120 ┃\r\n━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┻━━━━━━━━━━━━━━━━━━━━━━━\r\nAuthor: Zach Riggle <REDACTED>\r\nDate: Fri Jul 2 16:36:59 2021 -0500\r\n\r\n Add --entire-problem to my-issues\r\n\r\n\r\nbin/my-issues\r\n────────────────────────────────────────────────────────────────────────\r\n<non syntax-highlighted diff>\r\n```\r\n\r\n### Solution\r\n\r\nI've created a ZSH script which automatically finds all of the interpreters known to `file`. You can find a copy of it here:\r\nhttps://gist.github.com/zachriggle/e82ba2b7f6ea55df853fab03c243876d\r\n\r\nTo save you the time of running it, here's the output on my system.\r\n\r\n```\r\nash: Neil Brown's ash script text executable, ASCII text\r\nawk: awk script text executable, ASCII text\r\nbash: Bourne-Again shell script text executable, ASCII text\r\ncsh: C shell script text executable, ASCII text\r\nksh: Korn shell script text executable, ASCII text\r\nluacore: Lua script text executable, ASCII text\r\nnode: Node.js script text executable, ASCII text\r\nperl: Perl script text executable\r\npython: Python script text executable, ASCII text\r\nruby: Ruby script text executable, ASCII text\r\nsh: POSIX shell script text executable, ASCII text\r\nstapler: Systemtap script text executable, ASCII text\r\ntclassutil: Tcl script text executable, ASCII text\r\ntclsh: Tcl/Tk script text executable, ASCII text\r\ntcsh: Tenex C shell script text executable, ASCII text\r\nzsh: Paul Falstad's zsh script text executable, ASCII text\r\n```\r\n\r\nYou should be able to add these few bits to `git-delta` and use `file` to autodetect syntax, using the above as a mapping.\r\n","createdAt":"2021-07-13T00:30:08Z","includesCreatedEdit":true,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/485#issuecomment-878686614","viewerDidAuthor":false},{"id":"MDEyOklzc3VlQ29tbWVudDg3ODcyNDM5Mw==","author":{"login":"zachriggle"},"authorAssociation":"NONE","body":"@dandavison I created a simple solution to this issue, you should be able to use `file` on files without extension, and the above mappings, to automatically determine the syntax of a given file.\r\n\r\nYou may want to strip everything after the first comma (e.g. `ASCII text` or `Unicode text`).","createdAt":"2021-07-13T02:14:08Z","includesCreatedEdit":true,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/485#issuecomment-878724393","viewerDidAuthor":false},{"id":"MDEyOklzc3VlQ29tbWVudDg3ODkxMDU2Ng==","author":{"login":"dandavison"},"authorAssociation":"OWNER","body":"Thanks @zachriggle. One thing we should check before proceeding is whether there is a rust crate that already does this and looks to be reliable. Let me know if you're aware of anything.","createdAt":"2021-07-13T09:02:45Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[{"content":"THUMBS_UP","users":{"totalCount":1}}],"url":"https://github.com/dandavison/delta/issues/485#issuecomment-878910566","viewerDidAuthor":true},{"id":"IC_kwDOC4j8g85zJhZS","author":{"login":"flxai"},"authorAssociation":"NONE","body":"@dandavison There is [syntect](https://github.com/trishume/syntect) with a relevant function [`find_syntax_by_first_line`](https://docs.rs/syntect/latest/syntect/parsing/struct.SyntaxSet.html#method.find_syntax_by_first_line). Thanks to @jplatte for pointing this out in a private conversation.","createdAt":"2024-02-07T11:48:06Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[{"content":"THUMBS_UP","users":{"totalCount":2}}],"url":"https://github.com/dandavison/delta/issues/485#issuecomment-1931875922","viewerDidAuthor":false}],"number":485,"title":"🚀 [syntax highlighting] improved language mappings via shebang"},{"body":"I think the default colors for dark terminal backgrounds could be improved. Does anyone have any thoughts about this? Do you have some dark mode colors that you're happy with and would you be willing to share your config? cc @ulwlu @kevinhwang91 @torarnv @infokiller @Kr1ss-XD @clnoll (please add any others who might have ideas here).\r\n\r\nIt might also be nice to have a sort of gallery of example configs and screenshots to give people some ideas for configuring and to show what's possible. These could be distributed in the delta repo as named features in a config file, which people could `include`, something like\r\n\r\n```gitconfig\r\n[include]\r\n path = ~/src/delta/delta/themes.gitconfig\r\n```\r\n\r\n**EDIT**: ☝️ that exists now; see https://github.com/dandavison/delta#custom-color-themes","comments":[{"id":"MDEyOklzc3VlQ29tbWVudDc1Mjg3MTk2Mw==","author":{"login":"kevinhwang91"},"authorAssociation":"NONE","body":"Thank you for your invitation.\r\n# configs:\r\n```gitconfig\r\n[delta]\r\n paging=always\r\n line-numbers = true\r\n syntax-theme = TwoDark\r\n width = 1\r\n minus-style = syntax \"#450a15\"\r\n minus-emph-style = syntax \"#600818\"\r\n plus-style = syntax \"#0b4820\"\r\n plus-emph-style = syntax \"#175c2e\"\r\n hunk-header-style = syntax bold\r\n hunk-header-decoration-style = omit\r\n file-style = yellow italic\r\n file-decoration-style = yellow ul\r\n line-numbers-zero-style = \"#4b5263\"\r\n line-numbers-left-format = \"{nm:^4} \"\r\n line-numbers-right-format = \"{np:^4} \"\r\n```\r\n# screenshots:\r\n\r\n\r\n# terminal-alacritty\r\n```yaml\r\n # Normal colors\r\n normal:\r\n black: '#202326'\r\n red: '#d41a1a'\r\n green: '#12963d'\r\n yellow: '#fbb829'\r\n blue: '#2c78bf'\r\n magenta: '#985fc5'\r\n cyan: '#259cc1'\r\n white: '#bbbbbb'\r\n\r\n # Bright colors\r\n bright:\r\n black: '#5e6c7b'\r\n red: '#f75341'\r\n green: '#58c379'\r\n yellow: '#e1d359'\r\n blue: '#429ae5'\r\n magenta: '#af85ef'\r\n cyan: '#62c1d8'\r\n white: '#d3dae3'\r\n```","createdAt":"2020-12-31T07:10:31Z","includesCreatedEdit":true,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/481#issuecomment-752871963","viewerDidAuthor":false},{"id":"MDEyOklzc3VlQ29tbWVudDc1Mjk0ODk4Nw==","author":{"login":"torarnv"},"authorAssociation":"CONTRIBUTOR","body":"Hey hey! I'm still tweaking things, but this is my current setup:\r\n\r\n<img src=\"https://user-images.githubusercontent.com/7536/103410770-1aea1900-4b6d-11eb-913a-fbac38102345.png\" width=500px>\r\n\r\n```ini\r\n[delta \"torarnv-style\"]\r\n syntax-theme = OneHalfDark\r\n line-numbers = false\r\n\r\n hunk-header-style = file line-number syntax\r\n file-style = magenta omit\r\n file-modified-label = modified:\r\n\r\n hunk-header-decoration-style = bold black omit\r\n \r\n zero-style = dim syntax\r\n\r\n minus-style = bold red\r\n minus-non-emph-style = dim red\r\n minus-emph-style = bold red 52\r\n minus-empty-line-marker-style = normal \"#3f0001\"\r\n\r\n plus-style = bold green\r\n plus-non-emph-style = dim green\r\n plus-emph-style = bold green 22\r\n plus-empty-line-marker-style = normal \"#002800\"\r\n\r\n whitespace-error-style = reverse red\r\n```\r\n\r\n\r\n[OneDark.itermcolors.zip](https://github.com/dandavison/delta/files/5757263/OneDark.itermcolors.zip)\r\n","createdAt":"2020-12-31T12:39:26Z","includesCreatedEdit":true,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/481#issuecomment-752948987","viewerDidAuthor":false},{"id":"MDEyOklzc3VlQ29tbWVudDc1Mjk1MDA5NA==","author":{"login":"torarnv"},"authorAssociation":"CONTRIBUTOR","body":"Is there a way to style the line-number part of the hunk header? If I change to `hunk-header-decoration-style = bold black ul` the line number is gray, but with `hunk-header-decoration-style = bold black omit`, it's plain white. Is there a `line-number-decoration-style = bold black` e.g.?","createdAt":"2020-12-31T12:43:58Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/481#issuecomment-752950094","viewerDidAuthor":false},{"id":"MDEyOklzc3VlQ29tbWVudDc1Mjk4ODc1MA==","author":{"login":"Kr1ss-XD"},"authorAssociation":"CONTRIBUTOR","body":"This\r\n\r\n> It might also be nice to have a sort of gallery of example configs and screenshots to give people some ideas for configuring and to show what's possible. These could be distributed in the delta repo as named features in a config file, which people could `include`, [...]\r\n\r\nsounds like a really nice idea ! :+1: \r\n\r\nI'm occansionally still fiddling around with my config as new features get implemented, and because I just like messing with settings and trying out new things. At the moment, this is what it looks like (click to expand) :\r\n\r\n<details>\r\n<summary>Details</summary>\r\n\r\n### Environment\r\n```sh\r\nLESS='Mrcqi~#4x4j2 --mouse --wheel-lines=4 +Gg'\r\nLESSCHARSET=utf-8\r\nDELTA_PAGER=less\r\n```\r\n\r\n### `/etc/gitconfig`\r\n```gitconfig\r\n[core]\r\n\tpager\t\t\t\t\t\t\t= delta --24-bit-color=always --paging=always\r\n[interactive]\r\n\tdiffFilter\t\t\t\t\t\t= delta --24-bit-color=always --color-only\r\n[pager]\r\n\tstatus\t\t\t\t\t\t\t= false\r\n\tbranch\t\t\t\t\t\t\t= LESS=FMrqi~j2 less\r\n\tlog\t\t\t\t\t\t\t\t= LESS=FMrqi~x4j2 delta --24-bit-color=always\r\n\ttag\t\t\t\t\t\t\t\t= LESS=FMrqi~j2 less\r\n[delta]\r\n\thighlight-removed\t\t\t\t= true\r\n\tword-diff-regex\t\t\t\t\t= '.'\r\n\tline-buffer-size\t\t\t\t= 64\r\n\t;features\t\t\t\t\t\t= sbs links\r\n\t;features\t\t\t\t\t\t= sbs\r\n\tfeatures\t\t\t\t\t\t= unified\r\n[delta \"unified\"]\r\n\tfeatures\t\t\t\t\t\t= style labels deco lnums\r\n\tside-by-side\t\t\t\t\t= false\r\n[delta \"sbs\"]\r\n\tfeatures\t\t\t\t\t\t= style labels deco lnums\r\n\tside-by-side\t\t\t\t\t= true\r\n[delta \"style\"]\r\n\tdark\t\t\t\t\t\t\t= true\r\n\tsyntax-theme\t\t\t\t\t= Vibrant Sunburst\r\n\tzero-style\t\t\t\t\t\t= syntax\r\n\tminus-style\t\t\t\t\t\t= syntax \"#400000\"\r\n\tminus-emph-style\t\t\t\t= syntax bold \"#780000\"\r\n\tplus-style\t\t\t\t\t\t= syntax \"#004000\"\r\n\tplus-emph-style\t\t\t\t\t= syntax bold \"#007800\"\r\n\twhitespace-error-style\t\t\t= \"#280050\" reverse\r\n[delta \"deco\"]\r\n\tcommit-style\t\t\t\t\t= 232 bold italic 130\r\n\tcommit-decoration-style\t\t\t= 232 130 box\r\n\tfile-style\t\t\t\t\t\t= 232 bold 184\r\n\tfile-decoration-style\t\t\t= \"#606018\" overline\r\n\thunk-header-style\t\t\t\t= syntax bold italic 237\r\n\thunk-header-decoration-style\t= none\r\n[delta \"lnums\"]\r\n\tline-numbers\t\t\t\t\t= true\r\n\tline-numbers-zero-style\t\t\t= \"#545474\" italic\r\n\tline-numbers-left-format\t\t= \"{nm:>1}┊\"\r\n\tline-numbers-right-format\t\t= \"{np:>1}┊\"\r\n\tline-numbers-left-style\t\t\t= red\r\n\tline-numbers-right-style\t\t= green\r\n\tline-numbers-minus-style\t\t= red italic black\r\n\tline-numbers-plus-style\t\t\t= green italic black\r\n[delta \"labels\"]\r\n\tfile-added-label\t\t\t\t= [+]\r\n\tfile-copied-label\t\t\t\t= [C]\r\n\tfile-modified-label\t\t\t\t= [M]\r\n\tfile-removed-label\t\t\t\t= [-]\r\n\tfile-renamed-label\t\t\t\t= [R]\r\n[delta \"dsf\"]\r\n\tdiff-so-fancy\t\t\t\t\t= true\r\n[delta \"links\"]\r\n\thyperlinks\t\t\t\t\t\t= true\r\n\thyperlinks-file-link-format\t\t= file-line-column://{path}:{line}\r\n```\r\n\r\n</details>\r\n\r\n<details>\r\n<summary>Example</summary>\r\n\r\nI'm using i3wm, xfce4-terminal and tmux, everything with a dark theme.\r\n\r\n\r\n\r\n</details>\r\n\r\n\r\n**OT/** _Everybody have a happy **2021**_ ! :grin:","createdAt":"2020-12-31T15:31:44Z","includesCreatedEdit":true,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/481#issuecomment-752988750","viewerDidAuthor":false},{"id":"MDEyOklzc3VlQ29tbWVudDc1Mjk5MDkzMQ==","author":{"login":"dandavison"},"authorAssociation":"OWNER","body":"> Is there a way to style the line-number part of the hunk header?\r\n\r\n@torarnv There is now! 57d3f65e2e08c3abc5147fd0a0d115f8fab1b47d\r\n\r\n```\r\n--hunk-header-file-style <hunk-header-file-style>\r\n Style (foreground, background, attributes) for the file path part of the hunk-header. See STYLES section.\r\n The file path will only be displayed if hunk-header-style contains the 'file' special attribute [default:\r\n blue]\r\n--hunk-header-line-number-style <hunk-header-line-number-style>\r\n Style (foreground, background, attributes) for the line number part of the hunk-header. See STYLES section.\r\n The line number will only be displayed if hunk-header-style contains the 'line-number' special attribute\r\n [default: blue]\r\n```\r\n\r\n```gitconfig\r\n[delta]\r\n features = \"torarnv-style\"\r\n hunk-header-line-number-style = bold black\r\n hunk-header-file-style = magenta\r\n hunk-header-decoration-style = omit\r\n file-style = omit\r\n```\r\n\r\n<table><tr><td><img width=600px src=\"https://user-images.githubusercontent.com/52205/103416425-b8851e80-4b54-11eb-86d9-7c27782ccb13.png\" alt=\"image\" /></td></tr></table>","createdAt":"2020-12-31T15:42:36Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[{"content":"HEART","users":{"totalCount":1}},{"content":"ROCKET","users":{"totalCount":3}}],"url":"https://github.com/dandavison/delta/issues/481#issuecomment-752990931","viewerDidAuthor":true},{"id":"MDEyOklzc3VlQ29tbWVudDc1MzAyNjIyMA==","author":{"login":"dandavison"},"authorAssociation":"OWNER","body":"@kevinhwang91 @torarnv @Kr1ss-XD thanks for your configs! I've added a file `themes.gitconfig` file to the repo so that people can submit \"themes\" (i.e. a delta named feature) via PRs.\r\n\r\nOK, so there's going to be one rule... the name of each submitted theme has to be the name of a wild organism. It can be a mammal, bird, plant, mollusk, whatever; the name can be in any language, or even a latin genus name etc. Feel free to open a PR adding your theme to the `themes.gitconfig` file in the root dir of the repo. I've added some documentation to that file.","createdAt":"2020-12-31T18:51:51Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[{"content":"THUMBS_UP","users":{"totalCount":1}}],"url":"https://github.com/dandavison/delta/issues/481#issuecomment-753026220","viewerDidAuthor":true},{"id":"MDEyOklzc3VlQ29tbWVudDc1NDc1Mzg3Mg==","author":{"login":"dandavison"},"authorAssociation":"OWNER","body":"I'm tempted to make\r\n\r\n```gitconfig\r\n file-style = omit\r\n hunk-header-style = file line-number syntax\r\n```\r\n\r\nthe default in delta in the future. Does anyone have opinions about that? The advantages IMO are\r\n\r\n1. It's helpful to always be able to see which file you're in.\r\n2. Tools such as iTerm2 semantic click, delta `hyperlinks`, and [iterm2-dwim](https://github.com/dandavison/iterm2-dwim) allow editors/IDEs to open the file at the correct line number by clicking on the delta output in the terminal emulator.\r\n3. It looks nice and is visually cleaner to have all the info in one line, and it saves a couple of lines of output per file.","createdAt":"2021-01-05T16:44:39Z","includesCreatedEdit":true,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/481#issuecomment-754753872","viewerDidAuthor":true},{"id":"MDEyOklzc3VlQ29tbWVudDc1NDc1NDQ4Nw==","author":{"login":"dandavison"},"authorAssociation":"OWNER","body":"E.g. a light mode default could be something like (modulo colors)\r\n<table><tr><td><img width=600px src=\"https://user-images.githubusercontent.com/52205/103673342-78a2aa80-4f4b-11eb-9569-8f47598038e8.png\" alt=\"image\" /></td></tr></table>","createdAt":"2021-01-05T16:45:49Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[{"content":"THUMBS_UP","users":{"totalCount":2}}],"url":"https://github.com/dandavison/delta/issues/481#issuecomment-754754487","viewerDidAuthor":true},{"id":"MDEyOklzc3VlQ29tbWVudDc1NDc2NzIzMw==","author":{"login":"torarnv"},"authorAssociation":"CONTRIBUTOR","body":"Sounds like a good default to me, but I'm biased 😊 \r\n","createdAt":"2021-01-05T17:05:48Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/481#issuecomment-754767233","viewerDidAuthor":false},{"id":"MDEyOklzc3VlQ29tbWVudDc1NDc2OTU1Mg==","author":{"login":"Kr1ss-XD"},"authorAssociation":"CONTRIBUTOR","body":"Looks very Githubby. (That's a plus. :smile:)","createdAt":"2021-01-05T17:09:34Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[{"content":"THUMBS_UP","users":{"totalCount":1}}],"url":"https://github.com/dandavison/delta/issues/481#issuecomment-754769552","viewerDidAuthor":false},{"id":"MDEyOklzc3VlQ29tbWVudDg3MDc4NzI0NA==","author":{"login":"camsteffen"},"authorAssociation":"NONE","body":"The line numbers are unreadable. This seems like a more sensible default.\r\n```gitconfig\r\n[delta]\r\n\tline-numbers-minus-style = \"red dim\"\r\n\tline-numbers-plus-style = \"green dim\"\r\n\tline-numbers-zero-style = \"white dim\"\r\n```","createdAt":"2021-06-29T17:35:52Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[{"content":"HEART","users":{"totalCount":1}}],"url":"https://github.com/dandavison/delta/issues/481#issuecomment-870787244","viewerDidAuthor":false},{"id":"IC_kwDOC4j8g85gp0Kc","author":{"login":"anordal"},"authorAssociation":"NONE","body":"I find the dark red and green background colors (`minus-style` and `plus-style`) quite hard to distinguish from the black background if there is any amount of overcast daylight on my screen.\r\n\r\nIt helps a lot to brighten the background colors, but that also subtracts from the contrast with the text (too much of a thematic endeavour):\r\n```\r\nplus-style = \"syntax \\\"#00AA00\\\"\"\r\nminus-style = \"syntax \\\"#AA0000\\\"\"\r\nplus-emph-style = \"syntax \\\"#00FF00\\\"\"\r\nminus-emph-style = \"syntax \\\"#FF0000\\\"\"\r\n```\r\n\r\nI don't know if this is a curse of dark themes in general, but the light github-flavored theme is thankfully clearly visible in the same conditions.","createdAt":"2023-07-05T11:32:06Z","includesCreatedEdit":true,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/481#issuecomment-1621574300","viewerDidAuthor":false},{"id":"IC_kwDOC4j8g85gqTWP","author":{"login":"dandavison"},"authorAssociation":"OWNER","body":"There have been some nice contributions to delta themes over the last couple of years that this ticket has been open for. I'd encourage people to check them out and see whether any of the dark-background color choices in those themes work well for you. You can browse https://github.com/dandavison/delta/commits/master/themes.gitconfig which has links to the PRs, which should all have screenshots in them.\r\n\r\nBut agreed, it still seems challenging to find a good combination of foreground and background colours for dark terminal backgrounds, and I'd really welcome more themes demonstrating good such combinations.","createdAt":"2023-07-05T12:55:32Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[{"content":"THUMBS_UP","users":{"totalCount":2}}],"url":"https://github.com/dandavison/delta/issues/481#issuecomment-1621702031","viewerDidAuthor":true}],"number":481,"title":"🚀 Better default colors for dark terminal backgrounds"},{"body":"cc @ulwlu @HaleTom ref #307 https://github.com/dandavison/delta/pull/340#issuecomment-744350717\r\n\r\nI feel that this should work, but it does not:\r\n\r\n```gitconfig\r\n[delta]\r\n line-numbers = true\r\n features = no-line-numbers\r\n\r\n[delta \"no-line-numbers\"]\r\n line-numbers = false\r\n```\r\n\r\nDebugging suggests that it may involve delta refusing to visit the `line-numbers` entry twice:\r\n\r\n```\r\n[src/options/set.rs:393] &features = [\r\n \"line-numbers\",\r\n \"no-line-numbers\",\r\n]\r\n```\r\n\r\nPerhaps however it should notice that the second entry was associated with a different value from the first.","comments":[],"number":446,"title":"🐛 Can't disable line-numbers in a custom feature"},{"body":"\r\n\r\n\r\n\r\n\r\nShow row diff vs delta diff, clearly something is wrong, I also stashed every thing so if you need more info from the command line to please advice.\r\n\r\nDelta --version 0.4.4\r\n","comments":[{"id":"MDEyOklzc3VlQ29tbWVudDc0MDg2NzI5MA==","author":{"login":"dandavison"},"authorAssociation":"OWNER","body":"Thanks @ahmadie, this looks like an interesting one. Could you post the raw diff that's producing this as a text comment?","createdAt":"2020-12-08T19:05:55Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/439#issuecomment-740867290","viewerDidAuthor":true},{"id":"MDEyOklzc3VlQ29tbWVudDc0MjExNTk2Mg==","author":{"login":"ahmadie"},"authorAssociation":"NONE","body":"\r\n[config.txt](https://github.com/dandavison/delta/files/5669218/config.txt)\r\n[config-after.txt](https://github.com/dandavison/delta/files/5669225/config-after.txt)\r\n\r\n//could run using hope it helps =D\r\ngit diff --no-index config.txt config-after.txt\r\n\r\n","createdAt":"2020-12-09T22:57:17Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/439#issuecomment-742115962","viewerDidAuthor":false},{"id":"MDEyOklzc3VlQ29tbWVudDc0MjQ0MDkxNQ==","author":{"login":"dandavison"},"authorAssociation":"OWNER","body":"Thanks!","createdAt":"2020-12-10T10:45:44Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/439#issuecomment-742440915","viewerDidAuthor":true},{"id":"MDEyOklzc3VlQ29tbWVudDc1MDA5MzU3MA==","author":{"login":"waldyrious"},"authorAssociation":"CONTRIBUTOR","body":"@dandavison would it make sense to merge this with #246 so all similar issues can be tracked in the same place?","createdAt":"2020-12-23T10:21:40Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/439#issuecomment-750093570","viewerDidAuthor":false},{"id":"IC_kwDOC4j8g844eZJ7","author":{"login":"ElieGouzien"},"authorAssociation":"NONE","body":"Just a remark : here [diffr](https://github.com/mookid/diffr) is doing the job perfectly:\r\n\r\n\r\nI usually prefer the algorithm used by diffr than the one of delta as it is more precise, especially when a large block have been moved and modified (sometime even too much, and it would benefit from a threshold on the portion of modified words to stop considering word by word diff and show the whole line changed).\r\n\r\nMaybe diffr could be used in delta as a library (it is also in Rust and the interface and library are well separated).","createdAt":"2021-10-20T09:30:37Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/439#issuecomment-947491451","viewerDidAuthor":false},{"id":"IC_kwDOC4j8g85e0-_U","author":{"login":"cben"},"authorAssociation":"NONE","body":"This is most likely same as the situation in https://github.com/dandavison/delta/issues/522#issuecomment-832532239, discussed in more detail on #13, and now fixable by configuring colors.\r\n\r\nWhen the change is \"large\" enough (--max-line-distance), delta stops emphasizing parts and just colors uniformly (plus-style/minus-style). \r\nAnd that style defaults same as non-emph parts, which matches GitHub etc. and has benefit of maximizing fg/bg contrast when you have to read the whole old & new code anyway :+1: \r\nThe trouble is that delta makes that decision line-by-line :-1:, allowing confusing situations like this. It'd be fine if whole subhunk had emphasis or none, but single lines combined with default colors is IMHO a bug.\r\n","createdAt":"2023-06-14T10:42:28Z","includesCreatedEdit":true,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/439#issuecomment-1590947796","viewerDidAuthor":false}],"number":439,"title":"🐛 Wrong highlighting"},{"body":"When the file does not end in a new line, `diff` emits a `\\ No newline at end of file` line. Currently delta would just treat it similar to a normal unchanged line, but that causes problems when the diff section extends all the way to file end:\r\n\r\n```diff\r\n$ diff -u minus.txt plus.txt\r\n--- minus.txt 2020-12-04 20:47:52.000000000 -0500\r\n+++ plus.txt 2020-12-04 20:48:00.000000000 -0500\r\n@@ -1,5 +1,5 @@\r\n-key_0: value_0\r\n-key_1: value_1\r\n-key_2: value_2\r\n-key_3: value_3\r\n-key_4: value_4\r\n\\ No newline at end of file\r\n+key_0: value_1\r\n+key_1: value_2\r\n+key_2: value_3\r\n+key_3: value_4\r\n+key_4: value_5\r\n\\ No newline at end of file\r\n```\r\n\r\nIn this case, the minus and plus hunks should be matched together, but since the \"no newline\" message was in between, the minus hunk is marked as deleted:\r\n\r\n```bash\r\n$ delta -s minus.txt plus.txt --max-line-distance=1\r\n\r\ncomparing: minus.txt ⟶ plus.txt\r\n\r\n│ 1 │key_0: value_0 │ │\r\n│ 2 │key_1: value_1 │ │\r\n│ 3 │key_2: value_2 │ │\r\n│ 4 │key_3: value_3 │ │\r\n│ 5 │key_4: value_4 │ │\r\n\\ No newline at end of file\r\n│ │ │ 1 │key_0: value_1\r\n│ │ │ 2 │key_1: value_2\r\n│ │ │ 3 │key_2: value_3\r\n│ │ │ 4 │key_3: value_4\r\n│ │ │ 5 │key_4: value_5\r\n\\ No newline at end of file\r\n```","comments":[{"id":"MDEyOklzc3VlQ29tbWVudDczOTEzMDc3NA==","author":{"login":"dandavison"},"authorAssociation":"OWNER","body":"Thanks for this @huzecong.","createdAt":"2020-12-05T05:44:04Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/428#issuecomment-739130774","viewerDidAuthor":true}],"number":428,"title":"🐛 \"\\ No newline at end of file\" is not correctly handled"},{"body":"Right now some clippy warnings are allowed in the code. They look something like this:\r\n\r\nhttps://github.com/dandavison/delta/blob/15d06cbf7584570ec3b5beaba99cb8898f9ec3dc/src/paint.rs#L243\r\n\r\nSo just search for the word \"clippy\" in the code and you will find them.\r\nYou should do the following:\r\n\r\n1. run cargo clippy and check that there are no warnings\r\n2. delete the allow line\r\n3. run cargo clippy and check that you have a warning now\r\n4. try to fix the warning\r\n\r\nThe only one you should not remove MAYBE it's `#[allow(clippy::tabs_in_doc_comments)]`. But I am not sure about this.","comments":[],"number":424,"title":"Fix clippy warnings"},{"body":"See #392. cc @phil-blain\r\n\r\nhttps://github.com/dandavison/delta/issues/392#issuecomment-732220975\r\n\r\n> I did not think of it on Friday, but delta would be even more excellent if the similarity index (in percent) was indicated in parenthesis on the header line, for both renamed and copied files, something like this:\r\n~~~\r\n$ GIT_PAGER=../delta/target/release/delta git diff --cached -C -C\r\n\r\ncopied: first_file ⟶ copied_file (100%)\r\n─────────────────────────────────────────────────────────────────\r\n~~~\r\n","comments":[{"id":"IC_kwDOC4j8g85L1sMq","author":{"login":"WhyNotHugo"},"authorAssociation":"NONE","body":"This currently gets swallowed for files that have been moved, making them very hard to miss from diffs.\r\n\r\nFor example, here, at a glance, it seems that there's only a single change on-screen:\r\n\r\n\r\n\r\nThe raw output does include a reference though:\r\n\r\n```\r\n> git --no-pager log -p 49352587a29cb1130d963ade600e64810d596544 | less\r\ncommit 49352587a29cb1130d963ade600e64810d596544\r\nAuthor: somini <somini@users.noreply.github.com>\r\nDate: Mon Dec 27 12:19:58 2021 +0000\r\n\r\n Move icon to the app_id location\r\n \r\n This is so that the desktop files picks it up correctly.\r\n\r\ndiff --git a/resources/meson.build b/resources/meson.build\r\nindex 3e5c97a..7c99454 100644\r\n--- a/resources/meson.build\r\n+++ b/resources/meson.build\r\n@@ -15,7 +15,7 @@ resources = gnome.compile_resources(\r\n \r\n scour = find_program('scour', required: false)\r\n \r\n-icon = 'wdisplays.svg'\r\n+icon = 'network.cycles.wdisplays.svg'\r\n icondir = get_option('datadir') / 'icons' / 'hicolor' / 'scalable' / 'apps'\r\n \r\n if scour.found()\r\ndiff --git a/resources/wdisplays.svg b/resources/network.cycles.wdisplays.svg\r\nsimilarity index 100%\r\nrename from resources/wdisplays.svg\r\nrename to resources/network.cycles.wdisplays.svg\r\n\r\ncommit a9aa7472e37a44b1aaa962d3794f68553e9f81fe\r\nMerge: 5c6568a cfc8339\r\nAuthor: Arti Zirk <arti.zirk@gmail.com>\r\nDate: Mon Mar 29 11:33:43 2021 +0300\r\n\r\n Merge remote-tracking branch 'IntinteDAO/patch-1'\r\n\r\ncommit 5c6568a5b066e86d79a55f1d5334b2096a42715c\r\nMerge: dd7e1e2 5198a9c\r\nAuthor: Arti Zirk <arti.zirk@gmail.com>\r\nDate: Mon Mar 29 11:30:31 2021 +0300\r\n\r\n Merge remote-tracking branch 'emersion/fix-global-version'\r\n\r\ncommit 5198a9c94b40ff157c284df413be5402f1b75118\r\nAuthor: Simon Ser <contact@emersion.fr>\r\nDate: Wed Jul 8 11:57:35 2020 +0200\r\n\r\n Use correct versions when binding globals\r\n \r\n Changes to protocols aren't forward-compatible. It's not possible to use\r\n```\r\n\r\nPassing `similarity index 100%` in regular text colour would stand out enough, IMHO.","createdAt":"2022-10-08T17:40:39Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/406#issuecomment-1272365866","viewerDidAuthor":false},{"id":"IC_kwDOC4j8g85L1tqs","author":{"login":"dandavison"},"authorAssociation":"OWNER","body":"I have to admit I'm not quite seeing the value -- but I'm sure it's me being dense/lazy since someone has gone to the trouble of adding the feature to git! If it's 100% then there's no diff to show, so I'm not sure what value there is in showing the 100% here: `copied: first_file ⟶ copied_file (100%)`.\r\n\r\nAnd if it's <100% then there's a diff, so that will be highly visible.\r\n\r\nWould someone mind explaining how this feature is used?\r\n","createdAt":"2022-10-08T18:15:01Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/406#issuecomment-1272371884","viewerDidAuthor":true},{"id":"IC_kwDOC4j8g85L1yXR","author":{"login":"WhyNotHugo"},"authorAssociation":"NONE","body":"The file change location in these cases, but the change does not stand out. All the orange content is (as seen in the screenshot) metadata about changes. So while skimming trying to see changes in a log, file moves don't stand out and are easy to omit.\n","createdAt":"2022-10-08T20:19:07Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/406#issuecomment-1272391121","viewerDidAuthor":false},{"id":"IC_kwDOC4j8g85X7PCq","author":{"login":"mentalisttraceur"},"authorAssociation":"NONE","body":"It's nice for false positives: delete one file, write another file, have Git show it as a rename+diff, get confused (\"why does git think this is a move?! did I do something wrong? ...\"), notice \"51% similar\" (\"on that's why. well, okay then I guess\"). ","createdAt":"2023-03-19T08:12:33Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/406#issuecomment-1475145898","viewerDidAuthor":false},{"id":"IC_kwDOC4j8g85X7PMN","author":{"login":"mentalisttraceur"},"authorAssociation":"NONE","body":"Note that git allows us to change the similarity threshold when looking at logs/diffs, so knowing the degree of similarity of existing matches can help us know what to set that parameter to if we want to adjust what it dispays as a rename, etc.","createdAt":"2023-03-19T08:15:07Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/406#issuecomment-1475146509","viewerDidAuthor":false},{"id":"IC_kwDOC4j8g85X7PrV","author":{"login":"mentalisttraceur"},"authorAssociation":"NONE","body":"Oh, big reason! We *don't* always see the diff with a rename.\r\n\r\nSometimes people use `git diff`/`git log` format options which shows the file summaries (modified, added, renamed, etc) but not the hunks.\r\n\r\nI personally have done this with `git log` several times in my life (I can't remember exactly why anymore, probably to get a birds eye view of how a code base evolved, but I do remember going out of my way to look up how to do it at least twice over the years).","createdAt":"2023-03-19T08:22:37Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/406#issuecomment-1475148501","viewerDidAuthor":false}],"number":406,"title":"🚀 Display percentage similarity for renamed and copied files"},{"body":"\r\n\r\n\r\n\r\nAs you can see in the above screenshot , there is ample space to the right , but still the output is left compressed . \r\n","comments":[{"id":"MDEyOklzc3VlQ29tbWVudDcxNzM0NzM5MA==","author":{"login":"dandavison"},"authorAssociation":"OWNER","body":"Hi @neerajbadlani, thanks. I don't think I've seen this problem before, let's try to figure out what's going wrong. I think it will be a problem with your system, not a bug in delta. Can you post the output of `tput cols` and `echo $COLUMNS`? If you change the width of your terminal window, those numbers should change accordingly (and they should be the correct width in characters!). Does that seem to be true?\r\n\r\nAlso, if possible could you compare results in a different terminal emulator? For example I'm on MacOS and I have iTerm2 and Terminal.app (also Alacritty, etc).","createdAt":"2020-10-27T16:03:21Z","includesCreatedEdit":true,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/368#issuecomment-717347390","viewerDidAuthor":true},{"id":"MDEyOklzc3VlQ29tbWVudDcxNzQ2Mjg5NA==","author":{"login":"Kr1ss-XD"},"authorAssociation":"CONTRIBUTOR","body":"Also, the screenshot does look as if you're using some kind of wrapper interface around git, maybe something like `tig` or `lazygit`, is that correct @neerajbadlani ?\r\n\r\nI'm wondering because of the rectangular border around the output and the (page- ?) numbering at the top right. Unfortunately, one can not recognize if that's the entered command at the top of the image, or some kind of header coming from a git wrapper, tmux/screen or whatever.","createdAt":"2020-10-27T18:50:11Z","includesCreatedEdit":true,"isMinimized":false,"minimizedReason":"","reactionGroups":[{"content":"THUMBS_UP","users":{"totalCount":1}}],"url":"https://github.com/dandavison/delta/issues/368#issuecomment-717462894","viewerDidAuthor":false},{"id":"MDEyOklzc3VlQ29tbWVudDcxNzc3NzE5NQ==","author":{"login":"neerajbadlani"},"authorAssociation":"NONE","body":"Hi Guys , Thanks for quick check-in . My bad , heres more info : \r\n\r\nAbove screenshot is fzf preview window running inside vim running inside tmux . \r\n\r\nMy side by side diffs works fine within tmux ( when i do git diff ).\r\nProblem is only within fzf preview window running inside vim ( fzf preview window running outside vim is OK ). \r\n\r\nBefore delta I had hooked up ydiff with fzf preview window and it works fine . \r\n\r\ntput cols and COLUMNS seem to work correctly within the preview window . \r\n\r\nHeres how i checked it : \r\n```\r\n\" NOTE : Check after bug of left compression has been solved by delta git\r\ncommand! -bang -nargs=* FuzzyBCommits\r\n \\ call fzf#vim#buffer_commits({'options': ['--preview', 'tput cols ',\r\n \\ '--preview-window=down:70%']})\r\n\r\n```\r\n\r\nJust checked on Terminal ( I use Iterm ) , same issue happens there too .","createdAt":"2020-10-28T08:25:08Z","includesCreatedEdit":true,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/368#issuecomment-717777195","viewerDidAuthor":false},{"id":"MDEyOklzc3VlQ29tbWVudDcxNzk2OTUwMg==","author":{"login":"dandavison"},"authorAssociation":"OWNER","body":"Hi @neerajbadlani, can you reproduce the problem outside vim? If so, could you post the fzf command that results in the incorrect width? I'm happy to try to find the solution here (and I like fzf also!).","createdAt":"2020-10-28T14:26:38Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/368#issuecomment-717969502","viewerDidAuthor":true},{"id":"MDEyOklzc3VlQ29tbWVudDcxNzk3MTY5OQ==","author":{"login":"dandavison"},"authorAssociation":"OWNER","body":"Oh, nm, just re-read your post and you say it works outside vim.\r\n\r\nI think that using delta's `--width` option will solve this. Can you confirm?\r\n\r\nI'm also curious to see the fzf command you're using with delta, could you post that?","createdAt":"2020-10-28T14:29:53Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[{"content":"THUMBS_UP","users":{"totalCount":2}}],"url":"https://github.com/dandavison/delta/issues/368#issuecomment-717971699","viewerDidAuthor":true},{"id":"MDEyOklzc3VlQ29tbWVudDcxODU3OTU1Nw==","author":{"login":"neerajbadlani"},"authorAssociation":"NONE","body":"Hi @dandavison , I dont think explicitly using --width would work for me , since I do quite a bit of resizing of tmux windows / vim buffers when I am coding . \r\n\r\nAlthough I tried --width option , it works , however left and right sides of side by side diff are not balanced.\r\n\r\nWay to Repro this issue ( and the way I use delta with fzf ) \r\n\r\nI have this git history alias : \r\n\r\n\r\n\r\nAs you can see , i have 2 key bindings , when i press enter , it calls git split-diff-commit ( which is another alias I have and this alias uses delta ) \r\n\r\n\r\n\r\nThanks , Please let me know if any other alternative is available or something needed from my side to fix this issue . \r\n\r\n\r\n","createdAt":"2020-10-29T10:06:42Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/368#issuecomment-718579557","viewerDidAuthor":false},{"id":"MDEyOklzc3VlQ29tbWVudDcyMTY0MTIwNQ==","author":{"login":"mrswats"},"authorAssociation":"NONE","body":"I have been experiencing something similar. I use forgit to wrap around fzf and git and when doing `git diff` with delta's side-by-side option enabled everything seems to work correctly but as soon as I run it with fzf preview, the output is all messed up as reported [here](https://github.com/wfxr/forgit/issues/121).\r\n\r\nI tried what was suggested in the other issue and `git diff | delta --side-by-side` works fine while `git diff | delta --side-by-side | less` does not. This would suggest that delta has problems running properly when it's not in a tty. ","createdAt":"2020-11-04T10:13:47Z","includesCreatedEdit":true,"isMinimized":false,"minimizedReason":"","reactionGroups":[{"content":"THUMBS_UP","users":{"totalCount":3}}],"url":"https://github.com/dandavison/delta/issues/368#issuecomment-721641205","viewerDidAuthor":false},{"id":"MDEyOklzc3VlQ29tbWVudDcyMjAzMTE1Nw==","author":{"login":"Kr1ss-XD"},"authorAssociation":"CONTRIBUTOR","body":"**NOTE** I've just noticed a paragraph in the `fzf(1)` manual, which might be relevant for this ticket : \r\n\r\n> fzf exports $FZF_PREVIEW_LINES and $FZF_PREVIEW_COLUMNS so that they represent the exact size of the preview window. (It also overrides $LINES and $COLUMNS with the same values but they can be reset by the default shell, so prefer to refer to the ones with FZF_PREVIEW_ prefix.)\r\n\r\nIt's in the \"Preview\" section.","createdAt":"2020-11-04T23:33:02Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[{"content":"THUMBS_UP","users":{"totalCount":6}}],"url":"https://github.com/dandavison/delta/issues/368#issuecomment-722031157","viewerDidAuthor":false},{"id":"MDEyOklzc3VlQ29tbWVudDc1MTQ0NTM2Ng==","author":{"login":"dandavison"},"authorAssociation":"OWNER","body":"@neerajbadlani is this solved by an approach like https://github.com/wfxr/forgit/issues/121#issuecomment-725358145? There's also discussion of using delta under fzf-preview and vim in #338 cc @kevinhwang @ulwlu.","createdAt":"2020-12-27T09:33:40Z","includesCreatedEdit":true,"isMinimized":false,"minimizedReason":"","reactionGroups":[{"content":"THUMBS_UP","users":{"totalCount":1}}],"url":"https://github.com/dandavison/delta/issues/368#issuecomment-751445366","viewerDidAuthor":true},{"id":"MDEyOklzc3VlQ29tbWVudDc1MTY2ODk5MA==","author":{"login":"neerajbadlani"},"authorAssociation":"NONE","body":"@dandavison .. Perfect it works . However just a minor nitpick . I tried \r\n\r\n\r\n\r\nputting in pager config in gitconfig . However just that in itself doesnt work . I have to add it in each of my git aliases where i use delta . \r\n\r\nBefore ( Doesnt Work with above pager config added ) : \r\n\r\n\r\nAfter ( DOES work like this ) : \r\n\r\n\r\n","createdAt":"2020-12-28T10:41:59Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[{"content":"THUMBS_UP","users":{"totalCount":3}}],"url":"https://github.com/dandavison/delta/issues/368#issuecomment-751668990","viewerDidAuthor":false},{"id":"MDEyOklzc3VlQ29tbWVudDc1MTY3MzcxMw==","author":{"login":"dandavison"},"authorAssociation":"OWNER","body":"> Perfect it works .\r\n\r\nGreat!\r\n\r\n> However just a minor nitpick \r\n\r\nDelta does not read `core.pager` -- only git reads that. So if you are piping to delta then that delta process will not use any command line arguments provided in `core.pager`.\r\n\r\nIf you do `git show --pretty=fuller $COMMIT_ID` on its own without piping to delta, do you find that git does not use delta? That sounds right, since probably in the context you're calling this git sees that its output is not going to a tty in which case git would refuse to use its pager. ","createdAt":"2020-12-28T10:59:48Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/368#issuecomment-751673713","viewerDidAuthor":true},{"id":"MDEyOklzc3VlQ29tbWVudDc1MTc2MjI3NA==","author":{"login":"neerajbadlani"},"authorAssociation":"NONE","body":"> Delta does not read `core.pager` -- only git reads that. So if you are piping to delta then that delta process will not use any command line arguments provided in `core.pager`.\r\n\r\nCan we make delta read that to pick up args ? \r\n\r\n> If you do `git show --pretty=fuller $COMMIT_ID` on its own without piping to delta, do you find that git does not use delta? That sounds right, since probably in the context you're calling this git sees that its output is not going to a tty in which case git would refuse to use its pager.\r\n\r\nYeah that is what i see . On tty , git show picks up delta and its associated configs . Not however when its called from context of vim\r\n\r\n","createdAt":"2020-12-28T15:57:33Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/368#issuecomment-751762274","viewerDidAuthor":false},{"id":"IC_kwDOC4j8g86KWRnq","author":{"login":"injust"},"authorAssociation":"CONTRIBUTOR","body":"I encountered this while setting up delta with https://github.com/PatrickF1/fzf.fish by following the instructions at https://github.com/PatrickF1/fzf.fish/blob/main/README.md#integrate-with-a-diff-highlighter.\r\n\r\nTo get the width correct, I ended up using this:\r\n```fish\r\nset fzf_diff_highlighter delta --width=\\$FZF_PREVIEW_COLUMNS\r\n```","createdAt":"2024-08-30T12:32:03Z","includesCreatedEdit":true,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/368#issuecomment-2321095146","viewerDidAuthor":false}],"number":368,"title":"Width when using delta under fzf preview"},{"body":"Delta:\r\n\r\n```\r\nrenamed: /tmp/delta-example/dir-1/diagnostics ⟶ /tmp/delta-example/dir-2/diagnostics-2\r\n─────────────────────────────────────────────────────────────────────────────────────────────────────────────────────\r\n\r\nrenamed: tmp/delta-example/dir-1/diagnostics ⟶ tmp/delta-example/dir-2/diagnostics-2\r\n─────────────────────────────────────────────────────────────────────────────────────────────────────────────────────\r\n\r\n────────────────────────────────┐\r\nfor cmd in \"${commands[@]}\"; do │\r\n────────────────────────────────┘\r\n17\r\n eval \"$cmd\"\r\n echo\r\ndone\r\n\r\necho 'Hello!'\r\n```\r\n\r\nraw:\r\n\r\n```diff\r\ndiff --git a/tmp/delta-example/dir-1/diagnostics b/tmp/delta-example/dir-2/diagnostics-2\r\nsimilarity index 96%\r\nrename from /tmp/delta-example/dir-1/diagnostics\r\nrename to /tmp/delta-example/dir-2/diagnostics-2\r\nindex 0b4d47c..7c07815 100755\r\n--- a/tmp/delta-example/dir-1/diagnostics\r\n+++ b/tmp/delta-example/dir-2/diagnostics-2\r\n@@ -17,3 +17,5 @@ for cmd in \"${commands[@]}\"; do\r\n eval \"$cmd\"\r\n echo\r\n done\r\n+\r\n+echo 'Hello!'\r\n```\r\n\r\nThis doesn’t seem like a regression of #102 or #245; the original bug is only for Git repository, while this is comparing two non-Git directories like this:\r\n\r\n```sh\r\ngit diff /tmp/delta-example/dir-1 /tmp/delta-example/dir-2\r\n```\r\n\r\nI noticed that it can only be reproduced when absolute paths are used, not\r\n\r\n```sh\r\ngit diff dir-1 dir-2\r\n```","comments":[{"id":"MDEyOklzc3VlQ29tbWVudDc0ODYzMTcxNQ==","author":{"login":"dandavison"},"authorAssociation":"OWNER","body":"Thanks @FranklinYu! Indeed, this reproduces on passing your diff to delta on stdin.","createdAt":"2020-12-20T16:48:34Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/366#issuecomment-748631715","viewerDidAuthor":true}],"number":366,"title":"🐛 Duplicated lines when Git detects rename out of Git repo"},{"body":"Is there a way to config delta to not show the 'Class/Function' section in each diff?\r\n\r\nThank you.\r\n","comments":[{"id":"MDEyOklzc3VlQ29tbWVudDcxNTQwNDg5Mg==","author":{"login":"dandavison"},"authorAssociation":"OWNER","body":"Hi @simokhwang, you can do `hunk-header-style = omit`. However, is there something you'd like to display at that location instead (like some separating characters for example)? Otherwise, won't it be hard to read the diff no clear demarcation between distinct hunks? Ref https://github.com/dandavison/delta/issues/319#issuecomment-695825152 where a similar request was made. cc @nortliteborealis are you still looking for different (more minimal) hunk-header customization? let's move minimal hunk-header discussion to this ticket.\r\n\r\nYou could also use\r\n\r\n```gitconfig\r\n hunk-header-style = raw\r\n hunk-header-decoration-style = none\r\n```\r\n\r\n<table><tr><td><img width=600px src=\"https://user-images.githubusercontent.com/52205/97021415-cef17700-1520-11eb-9541-704cb70332ce.png\" alt=\"image\" /></td></tr></table>\r\n\r\nor\r\n\r\n```gitconfig\r\n hunk-header-style = raw\r\n hunk-header-decoration-style = ul\r\n```\r\n\r\n<table><tr><td><img width=600px src=\"https://user-images.githubusercontent.com/52205/97021478-e03a8380-1520-11eb-9c27-787b1ac71f70.png\" alt=\"image\" /></td></tr></table>\r\n\r\n\r\n\r\nBy the way, the low-level documentation of individual delta options (`delta --help`) contains this:\r\n\r\n```\r\n--hunk-header-style <hunk-header-style>\r\n Style (foreground, background, attributes) for the hunk-header. See STYLES section. The style 'omit' can be\r\n used to remove the hunk header section from the output [default: syntax]\r\n```","createdAt":"2020-10-23T15:15:12Z","includesCreatedEdit":true,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/364#issuecomment-715404892","viewerDidAuthor":true},{"id":"MDEyOklzc3VlQ29tbWVudDcxNTUyMTM4Nw==","author":{"login":"simokhwang"},"authorAssociation":"NONE","body":"Thanks for your reply and creating delta. It is a great tool.\n\n Basically, i find that 'class/function' section takes up a lot of screen\nspace. So it will make me longer (compare to vanilla git diff) to scroll\nthru the differences. So i am looking for ways to make delta result more\ncompact.\n\nOn Fri, 23 Oct 2020 at 08:15, Dan Davison <notifications@github.com> wrote:\n\n> Hi @simokhwang <https://github.com/simokhwang>, you can do hunk-header-style\n> = omit. However, is there something you'd like to display at that\n> location instead (like some separating characters for example)? Otherwise,\n> won't it be hard to read the diff no clear demarcation between distinct\n> hunks? Ref #319 (comment)\n> <https://github.com/dandavison/delta/issues/319#issuecomment-695825152>\n> where a similar request was made. cc @nortliteborealis\n> <https://github.com/nortliteborealis> are you still looking for different\n> (more minimal) hunk-header customization? let's move minimal hunk-header\n> discussion to this ticket.\n>\n> You could also use\n>\n> hunk-header-style = raw\n> hunk-header-decoration-style = none\n>\n> [image: image]\n> <https://user-images.githubusercontent.com/52205/97021415-cef17700-1520-11eb-9541-704cb70332ce.png>\n>\n> or\n>\n> hunk-header-style = raw\n> hunk-header-decoration-style = ul\n>\n> [image: image]\n> <https://user-images.githubusercontent.com/52205/97021478-e03a8380-1520-11eb-9c27-787b1ac71f70.png>\n>\n> By the way, the full documentation of delta is obtained by doing delta\n> --help, which mentions this:\n>\n> --hunk-header-style <hunk-header-style>\n> Style (foreground, background, attributes) for the hunk-header. See STYLES section. The style 'omit' can be\n> used to remove the hunk header section from the output [default: syntax]\n>\n> —\n> You are receiving this because you were mentioned.\n> Reply to this email directly, view it on GitHub\n> <https://github.com/dandavison/delta/issues/364#issuecomment-715404892>,\n> or unsubscribe\n> <https://github.com/notifications/unsubscribe-auth/ARPUCGOHI5FP2ROUX6JIDOLSMGMZDANCNFSM4S4UZGBQ>\n> .\n>\n","createdAt":"2020-10-23T18:50:46Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/364#issuecomment-715521387","viewerDidAuthor":false},{"id":"MDEyOklzc3VlQ29tbWVudDcxNTUzNTMyNw==","author":{"login":"dandavison"},"authorAssociation":"OWNER","body":"@simokhwang, thanks. Here's a quick comparison of some possible customizations, including one that is equally compact with default git diff. Does this help?\r\n\r\n## Vanilla git diff (3 lines)\r\n```\r\n }\r\n@@ -381,20 +376,25 @@ fn handle_hunk_header_line(\r\n config: &Config,\r\n```\r\n\r\n## Delta default (7 lines)\r\n```\r\n}\r\n\r\n────────────────────────────┐\r\nfn handle_hunk_header_line( │\r\n────────────────────────────┘\r\n376\r\n config: &Config,\r\n```\r\n\r\n## Delta custom I (5 lines)\r\n```gitconfig\r\n[delta]\r\n line-numbers = false\r\n hunk-header-decoration-style = ul\r\n```\r\n\r\n```\r\n}\r\n\r\nfn handle_hunk_header_line( \r\n─────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────\r\n config: &Config,\r\n```\r\n\r\n## Delta custom II (3 lines)\r\n\r\n```gitconfig\r\n[delta]\r\n line-numbers = false\r\n hunk-header-style = raw\r\n hunk-header-decoration-style = none\r\n```\r\n```\r\n}\r\n@@ -381,20 +376,25 @@ fn handle_hunk_header_line(\r\n config: &Config,\r\n```\r\n","createdAt":"2020-10-23T19:21:33Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/364#issuecomment-715535327","viewerDidAuthor":true},{"id":"MDEyOklzc3VlQ29tbWVudDcxODcxNDg2OQ==","author":{"login":"SuperCuber"},"authorAssociation":"NONE","body":"For me the issue is that a lot of the time the \"class name\" is actually just the first line of the hunk and it makes no sense to draw a box around it - it's just not special. For example:\r\n\r\n\r\nIn these cases I would expect delta to just not display anything there, or maybe just have some colored underscores to seperate the hunks.\r\n\r\nFor now I'll be using `hunk-header-style = omit` since the changing line numbers and the empty line is enough separation for me.\r\n\r\n\r\n(yes I'm aware the colors are horrible, configuring them right now :P )","createdAt":"2020-10-29T12:16:14Z","includesCreatedEdit":true,"isMinimized":false,"minimizedReason":"","reactionGroups":[{"content":"THUMBS_UP","users":{"totalCount":2}}],"url":"https://github.com/dandavison/delta/issues/364#issuecomment-718714869","viewerDidAuthor":false},{"id":"MDEyOklzc3VlQ29tbWVudDcxODgyNzc0MA==","author":{"login":"dandavison"},"authorAssociation":"OWNER","body":"> a lot of the time the \"class name\" is actually just the first line of the hunk and it makes no sense to draw a box around it - it's just not special.\r\n\r\nRight, I understand. Just to be clear: it is git that identifies these hunk headers, not delta, so you will see exactly the same headers under vanilla git. So if you were to use `hunk-header-style=raw` and `hunk-header-decoration-style = none` you'd be getting pretty much the vanilla git experience.\r\n\r\n> In these cases I would expect delta to just not display anything there, or maybe just have some colored underscores to separate the hunks.\r\n\r\nThe question is, how is delta to know when git has done a \"useful job\" of pulling out a hunk header vs when git has pulled out a \"boring\" line?\r\n\r\nIncidentally, have you seen this gist and accompanying blog post? https://gist.github.com/tekin/12500956bd56784728e490d8cef9cb81 I believe it improves the hunk header selection algorithm for several languages, but I agree that for things like configuration files that we will still be dealing with meaningless \"header\" choices.\r\n\r\nI'm happy to receive more suggestions for ways delta can make these headers better. It sounds like one feature we could add would be an option to insert a simple separator of some sort instead of displaying any of the actual text from the hunk header. ","createdAt":"2020-10-29T15:25:26Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/364#issuecomment-718827740","viewerDidAuthor":true},{"id":"MDEyOklzc3VlQ29tbWVudDcxODg1MzY1NA==","author":{"login":"SuperCuber"},"authorAssociation":"NONE","body":"> it is git that identifies these hunk headers, not delta\r\n\r\nI guess the solution to that would be on the git side then, maybe you can configure the algorithm for certain file types to show an empty line and then delta could detect whether the hunk header is empty... But that sounds pretty implausible to get it working and it would require the user to edit their gitattributes and stuff...\r\n\r\nAdding an option to insert a constant separator for users who just want to sidestep the whole issue sounds like a good idea to me.","createdAt":"2020-10-29T16:04:24Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/364#issuecomment-718853654","viewerDidAuthor":false},{"id":"MDEyOklzc3VlQ29tbWVudDcxODg3MjYxNQ==","author":{"login":"dandavison"},"authorAssociation":"OWNER","body":"> Adding an option to insert a constant separator for users who just want to sidestep the whole issue sounds like a good idea to me.\r\n\r\nYes, I agree. Seeing as they are (a) not actually part of ones diff and (b) not helpful in several language contexts, giving delta an option to minimize the amount of unnecessary information our brains are processing seems like the right thing to do.\r\n\r\nSo the next question is how to specify this. I think that we want this to be expressed using `hunk-header-style` and `hunk-header-decoration-style`. It's seeming to me like this should, but does not, do it:\r\n\r\n```gitconfig\r\n[delta]\r\n hunk-header-style = omit\r\n hunk-header-decoration-style = ul\r\n```\r\n\r\nIn fact what that does is just nuke the entire thing so you don't even get the `ul`. So if we could get that to render the `ul` separator with no header (we also have `ol`, and we are free to implement other things like `ul-dashed` or whatever) and for people who really want to nuke the entire thing that would be\r\n\r\n```gitconfig\r\n[delta]\r\n hunk-header-style = omit\r\n hunk-header-decoration-style = none\r\n```\r\n\r\ncc @ryuta69 who might also have thoughts here.","createdAt":"2020-10-29T16:33:07Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[{"content":"THUMBS_UP","users":{"totalCount":1}}],"url":"https://github.com/dandavison/delta/issues/364#issuecomment-718872615","viewerDidAuthor":true},{"id":"MDEyOklzc3VlQ29tbWVudDcxODg5NzcwMQ==","author":{"login":"SuperCuber"},"authorAssociation":"NONE","body":"An additional idea is to support this on a per-filetype basis, although I imagine it would make the configuration a bit convoluted","createdAt":"2020-10-29T17:14:05Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[{"content":"THUMBS_UP","users":{"totalCount":1}}],"url":"https://github.com/dandavison/delta/issues/364#issuecomment-718897701","viewerDidAuthor":false},{"id":"MDEyOklzc3VlQ29tbWVudDcxOTE0NjE0Nw==","author":{"login":""},"authorAssociation":"NONE","body":"Hi.\r\nTo me, I'm exactly same as @SuperCuber currently.\r\n\r\n>For now I'll be using hunk-header-style = omit since the changing line numbers and the empty line is enough separation for me.\r\n\r\nBut improving this is interesting. Below makes sense.\r\n\r\n> In fact what that does is just nuke the entire thing so you don't even get the ul. So if we could get that to render the ul separator with no header (we also have ol, and we are free to implement other things like ul-dashed or whatever) and for people who really want to nuke the entire thing that would be","createdAt":"2020-10-30T03:17:43Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/364#issuecomment-719146147","viewerDidAuthor":false}],"number":364,"title":"Is there a way to config delta to not show the 'Class/Function' section?"},{"body":"Hi, many thanks for writing delta -- I've long longed for something like it and am very happy to discover it.\r\n\r\nOne question: side-by-side views are great for looking at more complicated diffs but require substantially more horizontal space, so are IMO not a good default for git diff with typical terminal widths. On the other hand it would be great to have easy access to side-by-side git diffs when doing a more thorough review with a full screen'ed terminal. Unfortunately I'm not aware to of a way to pass the `-s` flag through when using delta as git diff backend, or some other way to easily switch case-by-case.\r\n\r\nAssuming something like it does not already exist, how about a mechanism to provide context dependent side-by-side in git diff based on either a user-specified minimal column width or an easy way to pass flags through something like a `DELTA` env var (similar to `LESS`)?","comments":[{"id":"MDEyOklzc3VlQ29tbWVudDcxMzM1NjkxNw==","author":{"login":"dmaahs2017"},"authorAssociation":"NONE","body":"Or instead of using an env variable it could be specified in the gitconfig for the delta options. ex: `side-by-side = auto` or `side-by-side = n_columns` such that when the terminal reaches the specified width it switches to side-by-side mode","createdAt":"2020-10-21T07:04:36Z","includesCreatedEdit":true,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/359#issuecomment-713356917","viewerDidAuthor":false},{"id":"MDEyOklzc3VlQ29tbWVudDcxMzU4ODYyNg==","author":{"login":"aschmolck"},"authorAssociation":"NONE","body":"Yes, my thinking was something like a `side-by-side-min-columns = 120` option in gitconfig rather than an env var, I think env var makes most sense for passing through flags directly for an individual run (or git alias).\r\n\r\nIf there is interest in principle, I'd also be happy to attempt to provide a PR for this feature.","createdAt":"2020-10-21T13:47:26Z","includesCreatedEdit":true,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/359#issuecomment-713588626","viewerDidAuthor":false},{"id":"MDEyOklzc3VlQ29tbWVudDcxMzgzMzIwMA==","author":{"login":"dandavison"},"authorAssociation":"OWNER","body":"Hi @aschmolck @dmaahs2017, thanks! I agree that a `DELTA` env var (analogous to `LESS`, i.e. holding a string which behaves exactly like command-line flags) could indeed make sense. There have been some similar discussions, let's just loop in some others: @ryuta69 @Kr1ss-XD @navarroaxel @gibfahn any opinions there?\r\n\r\nIt's not at all ideal, but what I currently do is something like\r\n\r\n```\r\ngit config --global delta.side-by-side true\r\n```\r\n\r\n(as is in the README). \r\n\r\nAlso your idea of an auto-side-by-side mode sounds interesting; I hadn't thought of that. Would the ideal be to re-use the same option, rather than to introduce another one? I.e.\r\n\r\n```\r\nside-by-side = true|false|120\r\n```\r\n\r\n> If there is interest in principle, I'd also be happy to attempt to provide a PR for this feature.\r\n\r\n@aschmolck great! I'll be happy to discuss designs and review code.","createdAt":"2020-10-21T19:46:10Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[{"content":"THUMBS_UP","users":{"totalCount":1}}],"url":"https://github.com/dandavison/delta/issues/359#issuecomment-713833200","viewerDidAuthor":true},{"id":"MDEyOklzc3VlQ29tbWVudDcxMzg0NzM2Mg==","author":{"login":"dmaahs2017"},"authorAssociation":"NONE","body":"> Also your idea of an auto-side-by-side mode sounds interesting; I hadn't thought of that. Would the ideal be to re-use the same option, rather than to introduce another one? I.e.\r\n> \r\n> ```\r\n> side-by-side = true|false|120\r\n> ```\r\n@dandavison Yeah I think reusing this option would be the best UX. Where 120 could be any positive integer","createdAt":"2020-10-21T20:14:26Z","includesCreatedEdit":true,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/359#issuecomment-713847362","viewerDidAuthor":false},{"id":"MDEyOklzc3VlQ29tbWVudDcxNDI4ODQ1NQ==","author":{"login":""},"authorAssociation":"NONE","body":"I think this is a good and useful idea!\r\n\r\n> ```\r\n> side-by-side = true|false|120\r\n> ```\r\n\r\nThis is just my opinion, but wouldn't the below example be confusing?\r\n\r\n```\r\n[delta]\r\n features = side-by-side\r\n side-by-side = 120\r\n``` \r\n\r\nWould Putting `side-by-side-min-columns = 120` be more intuitive...?\r\n\r\nP.S.\r\nI currently don't come up with any other options.","createdAt":"2020-10-22T07:21:30Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/359#issuecomment-714288455","viewerDidAuthor":false},{"id":"MDEyOklzc3VlQ29tbWVudDcxNDQyMzU2OA==","author":{"login":"navarroaxel"},"authorAssociation":"CONTRIBUTOR","body":"It's a hard decision and maybe we can't revert this latter... but I like\r\n```\r\nside-by-side = true|false|120\r\n```\r\ninstead of an extra configuration variable.\r\n\r\nBut I think in the future someone will request a flag to turn off the side-by-side automatically if the compared file has a line longer than the half of the terminal, etc.","createdAt":"2020-10-22T11:18:28Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[{"content":"THUMBS_UP","users":{"totalCount":3}}],"url":"https://github.com/dandavison/delta/issues/359#issuecomment-714423568","viewerDidAuthor":false},{"id":"MDEyOklzc3VlQ29tbWVudDcxNDQzOTE2OQ==","author":{"login":"aschmolck"},"authorAssociation":"NONE","body":"@navarroaxel maybe overkill, but one option to future-proof (and self-document) it more would just be to make it more descriptive, e.g:\r\n\r\n```\r\nside-by-side = true | false | columns > 119\r\n```\r\n\r\nThat's more verbose, but presumably that's not really an issue for a gitconfig line. It's a tad more annoying to parse, but again not that much.","createdAt":"2020-10-22T11:49:29Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[{"content":"THUMBS_UP","users":{"totalCount":1}}],"url":"https://github.com/dandavison/delta/issues/359#issuecomment-714439169","viewerDidAuthor":false},{"id":"MDEyOklzc3VlQ29tbWVudDcxNDUyNTQ3NA==","author":{"login":"dandavison"},"authorAssociation":"OWNER","body":"One thing we should bear in mind is that if we switch `side-by-side` to string type then I think the previously supported `delta --side-by-side` usage will be broken, because I don't think clap (the command-line arg parsing library) supports string options with no value (I'd like to be wrong about that. It's happened a few times already that I start off with a boolean and find myself wanting to expand the functionality). I still might prefer that to introducing a new option though, since delta has quite a lot of options already, and delta really emphasizes configuration via gitconfig, not command line. But some people's shell aliases etc would be broken.","createdAt":"2020-10-22T14:16:17Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/359#issuecomment-714525474","viewerDidAuthor":true},{"id":"MDEyOklzc3VlQ29tbWVudDcxNDU0NzczNw==","author":{"login":"aschmolck"},"authorAssociation":"NONE","body":"@dandavison If you dislike introducing new flags, think just extending the meaning of the gitconfig option and keeping the commandline option a simple boolean switch is probably fine, especially since delta reads gitconfig even in \"standalone\" mode. This won't break any existing aliases and there is no super compelling reason to have an automatic toggle via commandline flag since, unlike `git diff`, toggling is just an `-s` away.\r\n\r\nThere should probably be a `--no-side-by-side` option though, to override the .gitconfig default (if it's `true` or `auto`).\r\n\r\n\r\n","createdAt":"2020-10-22T14:49:22Z","includesCreatedEdit":true,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/359#issuecomment-714547737","viewerDidAuthor":false},{"id":"MDEyOklzc3VlQ29tbWVudDcxNTk1NjQ0Nw==","author":{"login":"dandavison"},"authorAssociation":"OWNER","body":"> think just extending the meaning of the gitconfig option and keeping the commandline option a simple boolean switch is probably fine\r\n\r\nRight. If I'm understanding your suggestion correctly there's precedent for this -- it's similar to what we did to allow `line-numbers = false` to have special meaning in gitconfig. See https://github.com/dandavison/delta/issues/292#issuecomment-677976160 and https://github.com/dandavison/delta/pull/296.\r\n","createdAt":"2020-10-24T16:00:47Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/359#issuecomment-715956447","viewerDidAuthor":true},{"id":"MDEyOklzc3VlQ29tbWVudDc1MTQ0NzMzMw==","author":{"login":"dandavison"},"authorAssociation":"OWNER","body":"> Assuming something like it does not already exist, how about a mechanism to provide context dependent side-by-side in git diff based on either a user-specified minimal column width or an easy way to pass flags through something like a `DELTA` env var\r\n\r\n@aschmolck Delta now supports an env var named `DELTA_FEATURES`, which can be used to dynamically alter the set of active features (a \"feature\" in delta terminology is either a named set of delta options using the `[delta \"my-feature\"]` heading syntax in ~/gitconfig, or one of the built-in \"features\" such as `side-by-side`). So we have one way of implementing automatic `side-by-side` switching. Here's a proof-of-principle in zsh (bash would be similar, using `PROMPT_COMMAND`):\r\n\r\n```zsh\r\n__dan_preexec_function () {\r\n local columns=$(tput cols)\r\n if [ $columns -ge 140 ]; then\r\n export DELTA_FEATURES=\"side-by-side\"\r\n else\r\n export DELTA_FEATURES=\"\"\r\n fi\r\n}\r\ntypeset -ag preexec_functions;\r\npreexec_functions=( __dan_preexec_function ${preexec_functions[@]} )\r\n```\r\n\r\nThis is similar to https://github.com/wfxr/forgit/issues/121#issuecomment-725811214 and may be relevant to https://github.com/dandavison/delta/issues/368; the shell code could also depend on `FZF_PREVIEW_COLUMNS` cc @mrswats @neerajbadlani @ulwlu \r\n\r\nI do wonder whether we would also want a `DELTA_ARGS` env var to literally add command line options. `DELTA_FEATURES` allows activating arbitrary groups of options by name and so is quite powerful, but it's not great for setting a numerical value like `--width` dynamically.","createdAt":"2020-12-27T09:57:06Z","includesCreatedEdit":true,"isMinimized":false,"minimizedReason":"","reactionGroups":[{"content":"THUMBS_UP","users":{"totalCount":1}}],"url":"https://github.com/dandavison/delta/issues/359#issuecomment-751447333","viewerDidAuthor":true},{"id":"MDEyOklzc3VlQ29tbWVudDc1MTQ0Nzg2MA==","author":{"login":"dandavison"},"authorAssociation":"OWNER","body":"> I do wonder whether we would also want a `DELTA_ARGS` env var to literally add command line options. \r\n\r\nThere is `GIT_PAGER` however, which can be used to dynamically alter the delta command line when delta is invoked by git, so here's a second way of doing automatic side-by-side switching:\r\n\r\n```zsh\r\n__dan_preexec_function () {\r\n local columns=$(tput cols)\r\n if [ $columns -ge 140 ]; then\r\n export GIT_PAGER=\"delta --side-by-side\"\r\n else\r\n export GIT_PAGER=\"delta\"\r\n fi\r\n}\r\ntypeset -ag preexec_functions;\r\npreexec_functions=( __dan_preexec_function ${preexec_functions[@]} )\r\n```","createdAt":"2020-12-27T10:02:54Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[{"content":"THUMBS_UP","users":{"totalCount":2}}],"url":"https://github.com/dandavison/delta/issues/359#issuecomment-751447860","viewerDidAuthor":true},{"id":"MDEyOklzc3VlQ29tbWVudDc5OTYyODMwMg==","author":{"login":"zeorin"},"authorAssociation":"NONE","body":"Here's a Fish shell version that listens to [SIGWINCH](https://en.wikipedia.org/wiki/Signal_(IPC)#SIGWINCH):\r\n```fish\r\n# Determine whether to use side-by-side mode for delta\r\nfunction delta_sidebyside --on-signal WINCH\r\n\tif test \"$COLUMNS\" -ge 120; and ! contains side-by-side \"$DELTA_FEATURES\"\r\n\t\tset --global --export --append DELTA_FEATURES side-by-side\r\n\telse if test \"$COLUMNS\" -lt 120; and contains side-by-side \"$DELTA_FEATURES\"\r\n\t\tset --erase DELTA_FEATURES[(contains --index side-by-side \"$DELTA_FEATURES\")]\r\n\tend\r\nend\r\ndelta_sidebyside\r\n```","createdAt":"2021-03-15T18:00:55Z","includesCreatedEdit":true,"isMinimized":false,"minimizedReason":"","reactionGroups":[{"content":"THUMBS_UP","users":{"totalCount":4}}],"url":"https://github.com/dandavison/delta/issues/359#issuecomment-799628302","viewerDidAuthor":false},{"id":"IC_kwDOC4j8g85yLzab","author":{"login":"cohml"},"authorAssociation":"NONE","body":"Coming to this thread from the distant future...\n\nI see almost universal enthusiasm for this proposal in the thread, plus at least one comment volunteering to work on it. Yet three years have passed and the issue remains open, nor does any PR link to it.\n\nWas this feature ever added and we just forgot to close the issue? Or was there some principled reason it never got implemented?","createdAt":"2024-01-29T22:37:20Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/359#issuecomment-1915696795","viewerDidAuthor":false},{"id":"IC_kwDOC4j8g85yL46J","author":{"login":"dandavison"},"authorAssociation":"OWNER","body":"Hi @cohml, it's that no-one worked on it.\r\n\r\nFWIW, I recently improved my shell tooling for toggling delta settings. This is what I've settled on currently:\r\n\r\n```zsh\r\ndelta-toggle() {\r\n eval \"export DELTA_FEATURES=$(-delta-features-toggle $1 | tee /dev/stderr)\"\r\n}\r\n```\r\nwhere `-delta-features-toggle` is https://github.com/dandavison/tools/blob/main/python/-delta-features-toggle.\r\n\r\n\r\nSo\r\n\r\n```\r\ndelta-toggle # shows current features\r\ndelta-toggle s # toggles side-by-side\r\ndelta-toggle l # toggles line-numbers\r\n```","createdAt":"2024-01-29T22:56:17Z","includesCreatedEdit":true,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/359#issuecomment-1915719305","viewerDidAuthor":true}],"number":359,"title":"🚀 automatic side-by-side based on column width?"},{"body":"# feature description\r\n\r\nline numbers are easier to visualize when they are right-aligned\r\n\r\n## current output\r\n```diff\r\ndiff --git a/foo b/foo\r\nindex e0de796..a297c36 100644\r\n--- a/foo\r\n+++ b/foo\r\n@@ -8,6 +8,7 @@\r\n 8 ⋮ 8 │\r\n 9 ⋮ 9 │\r\n 10 ⋮ 10 │\r\n ⋮ 11 │added line\r\n 11 ⋮ 12 │\r\n 12 ⋮ 13 │\r\n 13 ⋮ 14 │\r\n@@ -997,4 +998,5 @@\r\n997 ⋮998 │\r\n998 ⋮999 │\r\n999 ⋮1000│\r\n ⋮1001│added line\r\n1000⋮1002│\r\n```\r\n\r\n## desired output\r\n```diff\r\ndiff --git a/foo b/foo\r\nindex e0de796..a297c36 100644\r\n--- a/foo\r\n+++ b/foo\r\n@@ -8,6 +8,7 @@\r\n 8⋮ 8│\r\n 9⋮ 9│\r\n 10⋮ 10│\r\n ⋮ 11│added line\r\n 11⋮ 12│\r\n 12⋮ 13│\r\n 13⋮ 14│\r\n@@ -997,4 +998,5 @@\r\n 997⋮ 998│\r\n 998⋮ 999│\r\n 999⋮1000│\r\n ⋮1001│added line\r\n1000⋮1002│\r\n```\r\n","comments":[{"id":"MDEyOklzc3VlQ29tbWVudDcxMzY0OTE0Ng==","author":{"login":"iuliantatarascu"},"authorAssociation":"NONE","body":"I'm sorry, I hadn't searched before I created this issue, after I did I found that `--line-numbers-left-format` and `--line-numbers-right-format` can right align numbers.\r\nTherefore I edit my request to \"change the default to be right aligned\".","createdAt":"2020-10-21T15:12:39Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/358#issuecomment-713649146","viewerDidAuthor":false},{"id":"MDEyOklzc3VlQ29tbWVudDc0NDAwOTc3OA==","author":{"login":"SuperCuber"},"authorAssociation":"NONE","body":":+1: ","createdAt":"2020-12-13T13:41:34Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/358#issuecomment-744009778","viewerDidAuthor":false},{"id":"MDEyOklzc3VlQ29tbWVudDc0NDc4NTY2OQ==","author":{"login":"dandavison"},"authorAssociation":"OWNER","body":"Thanks @iuliantatarascu, sorry to be slow here, I think you may be right that the defaults could be tweaked. I remember one thing that made me hesitate before was that I felt that the \"breathing room\" to the right of the 2- and 3-digit numbers looked nice.\r\n\r\n<table><tr><td><img width=400px src=\"https://user-images.githubusercontent.com/52205/102147393-96a45000-3e62-11eb-8702-649b416d0abb.png\" alt=\"image\" /></td></tr></table>\r\n","createdAt":"2020-12-14T23:19:16Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/358#issuecomment-744785669","viewerDidAuthor":true}],"number":358,"title":"🚀 line numbers should be right-aligned by default"},{"body":"When a file's mode is changed, `git diff` will emit lines in between the `diff --git a/path b/path` line and the `index hash1..hash2` line that shows the mode change. Unfortunately delta discards this entire header, including the mode change. Using `--color-only` or `--diff-highlight` preserves these lines, but otherwise they get removed.\r\n\r\nThis is rather annoying as the mode changes are actually important.\r\n\r\n`git diff --no-pager` output:\r\n\r\n```\r\ndiff --git a/tools/is_ci.tcl b/tools/is_ci.tcl\r\nold mode 100644\r\nnew mode 100755\r\nindex d984ab2c65..d047b92be6\r\n--- a/tools/is_ci.tcl\r\n+++ b/tools/is_ci.tcl\r\n@@ -6,10 +6,10 @@ namespace import util::*\r\n \r\n proc usage {} {\r\n return \"usage: [file tail $::argv0] \\[-q]\r\n-\t\r\n+\r\n Options:\r\n -q --quiet Suppress all output.\r\n- \r\n+\r\n Description:\r\n Checks if the script was invoked from within a CI environment. If so, prints\r\n 'yes', otherwise prints 'no'.\r\n```\r\n\r\n`delta --no-gitconfig` output (sans color):\r\n\r\n```\r\n\r\ntools/is_ci.tcl\r\n─────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────\r\n\r\n─────────────────────────┐\r\nnamespace import util::* │\r\n─────────────────────────┘\r\n6\r\n\r\nproc usage {} {\r\n return \"usage: [file tail $::argv0] \\[-q]\r\n \r\n\r\nOptions:\r\n -q --quiet Suppress all output.\r\n \r\n\r\nDescription:\r\n Checks if the script was invoked from within a CI environment. If so, prints\r\n 'yes', otherwise prints 'no'.\r\n```\r\n\r\nThis was reproduced with delta 0.4.3.","comments":[{"id":"MDEyOklzc3VlQ29tbWVudDcxMjUzODU4Mg==","author":{"login":"dandavison"},"authorAssociation":"OWNER","body":"Thanks @lilyball, I agree -- we should include mode change info by default. What do you think about displaying this as\r\n\r\n```\r\ntools/is_ci.tcl (100644 ⟶ 100755)\r\n──────────────────────────────────────────────────────────────────────────────────────────────\r\n```\r\n\r\n?","createdAt":"2020-10-20T01:55:41Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[{"content":"THUMBS_UP","users":{"totalCount":9}}],"url":"https://github.com/dandavison/delta/issues/357#issuecomment-712538582","viewerDidAuthor":true},{"id":"IC_kwDOC4j8g85C_0Ny","author":{"login":"imciner2"},"authorAssociation":"NONE","body":"@dandavison would that only be displayed if the mode changed and be hidden otherwise? If so, then that output would be perfect. I am really missing this in the diff output, because otherwise it just shows the entire file as being changed, so having this piece of information displayed is key to understanding what happened.","createdAt":"2022-05-11T17:04:41Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/357#issuecomment-1124025202","viewerDidAuthor":false}],"number":357,"title":"🐛 Delta removes old/new mode lines in diff output"},{"body":"I've recently become very interested in the fact that the library used by vim and nvim for diffing, called xdiff, doesn't support in line diffs (at the word boundary) like your tool does. Obviously your tool isn't written to be a library, but I think if it were possible to create a vim or nvim plugin to use this tool to generate the two-way diffs used in the editor, it would be some massive exposure.\n\nI don't think it even needs an API, cause vim/nvim can call an external program for diffing as far as I'm aware.\n\nDoes anyone know how doable this would be?","comments":[{"id":"MDEyOklzc3VlQ29tbWVudDY5OTUwNDE2OQ==","author":{"login":"dandavison"},"authorAssociation":"OWNER","body":"Hi @Sevensidedmarble, thanks for opening this. Have you seen my project doing this for Emacs (magit)? https://github.com/dandavison/magit-delta It might contain some parallels to what would be needed for vim/nvim.\r\n\r\nIt required very little code. What it relies on is an [existing emacs-lisp library](https://github.com/atomontage/xterm-color) that can take raw text with ANSI color escape sequences as input, parse it, excise the escape sequences and annotate the strings in the Emacs buffer with the data structures that Emacs uses to add colors to text (i.e. \"text properties\" or \"overlays\").\r\n\r\nIn fact, I use delta in magit a lot and find it beneficial, so I do believe that it would be beneficial to make the same thing possible in vim/nvim. I'm happy to help where I can, but I don't know anything about vim/nvim. From a very quick google search what we want to do is similar to what is discussed in\r\n\r\nhttps://unix.stackexchange.com/questions/7695/how-to-make-vim-display-colors-as-indicated-by-color-codes\r\nhttps://vi.stackexchange.com/questions/485/can-vim-interpret-terminal-color-escape-codes\r\nhttps://stackoverflow.com/questions/10592715/ansi-color-codes-in-vim/38357506","createdAt":"2020-09-26T14:39:57Z","includesCreatedEdit":true,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/338#issuecomment-699504169","viewerDidAuthor":true},{"id":"MDEyOklzc3VlQ29tbWVudDY5OTUwNTg4Ng==","author":{"login":"dandavison"},"authorAssociation":"OWNER","body":"Does vim/nvim have the ability to run a shell and display colored output from the shell faithfully within the vim/nvim application? If there's something like that that works well, then it suggests that the required technology exists already.","createdAt":"2020-09-26T14:53:07Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/338#issuecomment-699505886","viewerDidAuthor":true},{"id":"MDEyOklzc3VlQ29tbWVudDY5OTUyMzE0MA==","author":{"login":"Kr1ss-XD"},"authorAssociation":"CONTRIBUTOR","body":"As far as I'm aware, there's no such feature in (vanilla) Vim. There's a way to run a shell command and have its output inserted into the edited text, but the color escape codes won't be processed.\r\nFor example, if I do `:r!ls -Al --color .git/`, Vim inserts the following verbatim into the text (`:r!<command>` is the command to open a subshell and execute the command) :\r\n```\r\ninsgesamt 20\r\ndrwxrwsr-x 1 kriss build 0 9. Sep 19:51 ^[[0m^[[1;34mbranches^[[0m\r\n-rw-rw-r-- 1 kriss build 262 9. Sep 19:51 config\r\n-rw-rw-r-- 1 kriss build 73 9. Sep 19:51 description\r\n-rw-rw-r-- 1 kriss build 23 9. Sep 19:51 HEAD\r\ndrwxrwsr-x 1 kriss build 460 9. Sep 19:51 ^[[1;34mhooks^[[0m\r\n-rw-rw-r-- 1 kriss build 289 9. Sep 19:51 index\r\ndrwxrwsr-x 1 kriss build 14 9. Sep 19:51 ^[[1;34minfo^[[0m\r\ndrwxrwsr-x 1 kriss build 16 9. Sep 19:51 ^[[1;34mlogs^[[0m\r\ndrwxrwsr-x 1 kriss build 52 9. Sep 19:51 ^[[1;34mobjects^[[0m\r\n-rw-rw-r-- 1 kriss build 114 9. Sep 19:51 packed-refs\r\ndrwxrwsr-x 1 kriss build 32 9. Sep 19:51 ^[[1;34mrefs^[[0m\r\n```\r\nNote this is plain Vim. Maybe there's a plugin which can interpret the escape codes. Also, I don't know what this looks like with Neovim either.","createdAt":"2020-09-26T17:18:21Z","includesCreatedEdit":true,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/338#issuecomment-699523140","viewerDidAuthor":false},{"id":"MDEyOklzc3VlQ29tbWVudDcwMDAwOTg5MA==","author":{"login":"srcrip"},"authorAssociation":"NONE","body":"They both have the option of using terminal buffers, which obviously parses all codes correctly. My gut tells me this would probably be the way to do it, I'm just not great with vimscript, or know enough about the nvim lua api, to say exactly how.","createdAt":"2020-09-28T13:33:53Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[{"content":"THUMBS_UP","users":{"totalCount":2}}],"url":"https://github.com/dandavison/delta/issues/338#issuecomment-700009890","viewerDidAuthor":false},{"id":"MDEyOklzc3VlQ29tbWVudDczNjU0MjgyMg==","author":{"login":"kevinhwang91"},"authorAssociation":"NONE","body":"Is anyone going to do this plugin(or have done)? I wanna try it out, otherwise, I will complete it in neovim after the documents of two personal plugins are done.(Not a promise)","createdAt":"2020-12-01T13:12:43Z","includesCreatedEdit":true,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/338#issuecomment-736542822","viewerDidAuthor":false},{"id":"MDEyOklzc3VlQ29tbWVudDc0MTU4NTA1NA==","author":{"login":""},"authorAssociation":"NONE","body":"I find this issue now and wonder what @Sevensidedmarble and @kevinhwang91 wants is like this?\r\n\r\n<img width=\"1420\" alt=\"ss\" src=\"https://user-images.githubusercontent.com/41639488/101597425-09b05f80-3a3a-11eb-890f-4b99d2c12b90.png\">\r\n\r\nThis could be done by fugitive.vim.\r\n\r\nIf you would like to just print, not opening on editor, just `:bo term git diff` (in the case you set core.pager = delta)\r\n\r\n<img width=\"1422\" alt=\"ss 1\" src=\"https://user-images.githubusercontent.com/41639488/101598681-e25a9200-3a3b-11eb-9ee0-c6f2fbbfdbb9.png\">\r\n","createdAt":"2020-12-09T07:18:42Z","includesCreatedEdit":true,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/338#issuecomment-741585054","viewerDidAuthor":false},{"id":"MDEyOklzc3VlQ29tbWVudDc0MTU5NzkxNA==","author":{"login":"kevinhwang91"},"authorAssociation":"NONE","body":"> I find this issue now and wonder what @Sevensidedmarble and @kevinhwang91 wants is like this?\r\n> \r\n> <img alt=\"ss\" width=\"1420\" src=\"https://user-images.githubusercontent.com/41639488/101597425-09b05f80-3a3a-11eb-890f-4b99d2c12b90.png\">\r\n> \r\n> This could be done by fugitive.vim.\r\n> \r\n> If you would like to just print, not opening on editor, just `:bo term git diff` (in the case you set core.pager = delta)\r\n> \r\n> <img alt=\"ss 1\" width=\"1422\" src=\"https://user-images.githubusercontent.com/41639488/101598681-e25a9200-3a3b-11eb-9ee0-c6f2fbbfdbb9.png\">\r\n\r\nThanks, I knew this information before commented.\r\nThere're two reasons I wanna build a plugin library based on fugitive.vim which is easier to implement:\r\n\r\n1. I prefer a floating window for preview rather than a tab or a splited window while navigating commit, more like modern T/GUI git tools, such as lazygit, tig, gitui and so on.\r\n2. I also use [vim-flog](https://github.com/rbong/vim-flog), extra library is better than a simple script based on fugitive.vim.\r\n\r\nneovim is migrating from vimscript to lua, I'm following their steps and learning lua to refactor my private config and plugin. Not enough time to make this plugin recently.","createdAt":"2020-12-09T07:48:35Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/338#issuecomment-741597914","viewerDidAuthor":false},{"id":"MDEyOklzc3VlQ29tbWVudDc0MTYwNTA3Mg==","author":{"login":""},"authorAssociation":"NONE","body":"@kevinhwang91 \r\n> I prefer a floating window\r\n\r\nThis could be done by fzf-preview.vim. It's already integrated with fugitive and can custom preview.","createdAt":"2020-12-09T08:04:34Z","includesCreatedEdit":true,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/338#issuecomment-741605072","viewerDidAuthor":false},{"id":"MDEyOklzc3VlQ29tbWVudDc0MTYxMDQ4OQ==","author":{"login":"kevinhwang91"},"authorAssociation":"NONE","body":"`git diff` is not only to a commit, but also to a file. Run `:Git` with fugitive in vim, you will know my idea if you have an experience for using IDE for code review before committing.\r\n\r\nI only use fzf preview git commit in the current buffer.","createdAt":"2020-12-09T08:15:10Z","includesCreatedEdit":true,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/338#issuecomment-741610489","viewerDidAuthor":false},{"id":"MDEyOklzc3VlQ29tbWVudDc0MTYxMjk4OA==","author":{"login":""},"authorAssociation":"NONE","body":"@kevinhwang91 \r\nYou can do `git diff` to file as well.\r\nUse `CocCommand fzf-preview.GitStatus` with config below as I said before.\r\n\r\n```bash\r\nlet g:fzf_preview_git_status_preview_command = \"[[ $(git diff --cached -- {-1}) != \\\"\\\" ]] && git diff --cached --color=always -- {-1} | delta || \" .\r\n\\ \"[[ $(git diff -- {-1}) != \\\"\\\" ]] && git diff --color=always -- {-1} | delta || \" .\r\n\\ g:fzf_preview_command\r\n\r\n```\r\n\r\n\r\n<img width=\"1589\" alt=\"ss\" src=\"https://user-images.githubusercontent.com/41639488/101603266-a676fb00-3a42-11eb-818d-9689a7a302a5.png\">\r\n","createdAt":"2020-12-09T08:20:02Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[{"content":"HEART","users":{"totalCount":2}}],"url":"https://github.com/dandavison/delta/issues/338#issuecomment-741612988","viewerDidAuthor":false},{"id":"MDEyOklzc3VlQ29tbWVudDc0MTYxOTAxNg==","author":{"login":"kevinhwang91"},"authorAssociation":"NONE","body":"> @kevinhwang91\r\n> You can do `git diff` to file as well.\r\n> Use `CocCommand fzf-preview.GitStatus` with config below as I said before.\r\n> \r\n> ```shell\r\n> let g:fzf_preview_git_status_preview_command = \"[[ $(git diff --cached -- {-1}) != \\\"\\\" ]] && git diff --cached --color=always -- {-1} | delta || \" .\r\n> \\ \"[[ $(git diff -- {-1}) != \\\"\\\" ]] && git diff --color=always -- {-1} | delta || \" .\r\n> \\ g:fzf_preview_command\r\n> ```\r\n> \r\n> <img alt=\"ss\" width=\"1589\" src=\"https://user-images.githubusercontent.com/41639488/101603266-a676fb00-3a42-11eb-818d-9689a7a302a5.png\">\r\n\r\nPretty cool, I think I have to try for a while, but I really hate the redraw in FZF during the interaction.","createdAt":"2020-12-09T08:32:10Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/338#issuecomment-741619016","viewerDidAuthor":false},{"id":"MDEyOklzc3VlQ29tbWVudDc0MzczMjQ0Mg==","author":{"login":""},"authorAssociation":"NONE","body":"Update:\r\n\r\nSomeone who saw [my example on reddit](https://www.reddit.com/r/vim/comments/kaedj9/implemented_fzfpreviewvim_with_gitdelta_in_vim/) sent a request to fzf.vim, and now fzf also implements delta.\r\n\r\nhttps://github.com/junegunn/fzf.vim/issues/1202\r\n\r\ncc: @dandavison , @Sevensidedmarble ","createdAt":"2020-12-12T09:56:41Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[{"content":"THUMBS_UP","users":{"totalCount":4}}],"url":"https://github.com/dandavison/delta/issues/338#issuecomment-743732442","viewerDidAuthor":false},{"id":"IC_kwDOC4j8g850LUZm","author":{"login":"pbnj-dragon"},"authorAssociation":"NONE","body":"A similar question was asked on `tpope/vim-fugitive` here: https://github.com/tpope/vim-fugitive/issues/2249#issuecomment-1874566335\r\n\r\n**TL;DR**\r\n\r\n```\r\n:Git -c pager.diff=delta diff\r\n```","createdAt":"2024-02-16T18:57:27Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/338#issuecomment-1949124198","viewerDidAuthor":false}],"number":338,"title":"Using Delta as a Vim/NeoVim library"},{"body":"If a commit adds an empty file, delta doesn't show it in the output, but git does.\r\n\r\nI'm assuming this is a bug, but in case it's a feature, it's very helpful to show these empty files, as they often have marker or other useful purposes.\r\n\r\nMinimal reproduction:\r\n\r\n```shell\r\ntouch foo\r\ngit add foo\r\ngit commit -m 'Test'\r\ngit --no-pager show\r\nGIT_PAGER=delta git show\r\n```\r\n\r\nOutput:\r\n\r\n```console\r\n$ GIT_PAGER=delta git show\r\n commit 9739454fde7dbdcd69035e59c17c33e347e8891f (HEAD -> master)\r\n Author: Gibson Fahnestock <gibfahn@gmail.com>\r\n Date: Fri Sep 25 10:35:36 2020 +0100\r\n\r\n Test\r\n\r\n\r\n$ git --no-pager show\r\ncommit 9739454fde7dbdcd69035e59c17c33e347e8891f (HEAD -> master)\r\nAuthor: Gibson Fahnestock <gibfahn@gmail.com>\r\nDate: Fri Sep 25 10:35:36 2020 +0100\r\n\r\n Test\r\n\r\ndiff --git a/foo b/foo\r\nnew file mode 100644\r\nindex 0000000..e69de29\r\n```","comments":[{"id":"MDEyOklzc3VlQ29tbWVudDY5OTA3NjY2NQ==","author":{"login":"dandavison"},"authorAssociation":"OWNER","body":"Thanks @gibfahn!\r\n\r\n(This is definitely a bug, not a feature; delta doesn't want to override git in any way like that.)","createdAt":"2020-09-25T18:11:07Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[{"content":"THUMBS_UP","users":{"totalCount":3}}],"url":"https://github.com/dandavison/delta/issues/336#issuecomment-699076665","viewerDidAuthor":true},{"id":"IC_kwDOC4j8g86FerVG","author":{"login":"bash"},"authorAssociation":"CONTRIBUTOR","body":"@dandavison I believe this was fixed by #945:\r\n\r\nOutput with delta 0.17.0:\r\n\r\n","createdAt":"2024-07-19T15:00:22Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/336#issuecomment-2239411526","viewerDidAuthor":false}],"number":336,"title":"🐛 Adding an empty file doesn't show up in `git show` "},{"body":"In trying out delta I noticed that the line number style delta uses doesn't match what `bat` uses for the same theme. Here's a screenshot:\r\n\r\n\r\n\r\nThe line numbers are hard to read in delta but not in bat. It looks like the line number style can be adjusted in delta, but it would be nice if it would naturally follow the theme, as in bat.","comments":[],"number":335,"title":"Make line number colors match bat for the same theme?"},{"body":"Hi, \r\nUsing the sample configuration, I have an unreadable output under Windows Terminal 1.2.2381.0\r\nOnly the background color seems to be rendered, i.e copy/pasting shows no content?\r\n\r\nTo make things more complicated the terminal I'm spawning calls `init.bat` from [cmder](https://github.com/cmderdev/cmder), so it might as well be a terminal emulator issue... \r\n\r\nI'm using the patched version of less.exe, as recommended (although it doesn't make a difference for this particular issue)\r\n\r\n~/.gitconfig\r\n```\r\n[interactive]\r\n diffFilter = delta --color-only\r\n\r\n[delta]\r\n features = side-by-side line-numbers decorations\r\n whitespace-error-style = 22 reverse\r\n\r\n[delta \"decorations\"]\r\n commit-decoration-style = bold yellow box ul\r\n file-style = bold yellow ul\r\n file-decoration-style = none\r\n```\r\n\r\nOutputs:\r\n\r\n\r\nWithout using delta\r\n\r\n\r\n```\r\nλ delta --version\r\ndelta 0.4.3\r\nλ git --version\r\ngit version 2.28.0.windows.1\r\n```","comments":[{"id":"MDEyOklzc3VlQ29tbWVudDY5NjE3OTQ5MA==","author":{"login":"dandavison"},"authorAssociation":"OWNER","body":"Hi @RemySphere, is delta working for you outside of the `git add -p` scenario? E.g. `git diff`, `git show`, etc.\r\n\r\nIf you pipe output from git to delta directly, does that look correct? `git diff | delta`","createdAt":"2020-09-21T15:12:41Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/328#issuecomment-696179490","viewerDidAuthor":true},{"id":"MDEyOklzc3VlQ29tbWVudDY5NjE5Njc3Mw==","author":{"login":"remysalim"},"authorAssociation":"NONE","body":"Before I only had `core.pager = delta --dark` set in my `.gitconfig`, and there were no apparent issue with my day-to-day use, except the one.\r\n\r\nBut indeed, now that I am fiddling with more features there are a few glitches here and there...\r\n\r\n\r\n`side-by-side` is mostly ok, with occasional encoding errors\r\n\r\n\r\nThere is no visible difference when piping output from git to delta directly. \r\nSide note, those encoding artifacts don't seem to occur in a WSL container, but the main \"background only\" issue still does, somehow","createdAt":"2020-09-21T15:36:49Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/328#issuecomment-696196773","viewerDidAuthor":false},{"id":"MDEyOklzc3VlQ29tbWVudDcwNTAxOTgxNg==","author":{"login":"stan-guer"},"authorAssociation":"NONE","body":"I wonder if it's related to the ^M carriage returns. Or perhaps it's an unrelated issue. I'm experiencing this in Linux/urxvt editing a file created with windows (running` set ff?` in vim return `fileformat=dos`). git diff works because it does not show the ^M. `git add --patch` shows only the background on lines with ^M. Running dos2unix on the file makes `git add --patch` with delta work properly again.","createdAt":"2020-10-07T15:37:23Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/328#issuecomment-705019816","viewerDidAuthor":false},{"id":"MDEyOklzc3VlQ29tbWVudDcwNTAzNTI4Ng==","author":{"login":"remysalim"},"authorAssociation":"NONE","body":"Ahem, probably related, `git log` is also pretty messed up with my configuration\r\n\r\n\r\n","createdAt":"2020-10-07T16:02:06Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/328#issuecomment-705035286","viewerDidAuthor":false},{"id":"MDEyOklzc3VlQ29tbWVudDcwNTExNjY5Mw==","author":{"login":"dandavison"},"authorAssociation":"OWNER","body":"Thanks @voqv, @RemySphere, I am also seeing some behavior I don't expect (on MacOS):\r\n\r\n1. I create a file containing the letter `a` followed by a newline character.\r\n2. I commit the file\r\n3. I run unix2dos on the file\r\n4. Now, when I do `git diff | delta` the diff is rendered correctly, but when I do `git diff` (allowing git to invoke delta via `core.pager`), the added line (green) is empty:\r\n\r\n(Note that `cat` is aliased to `bat` on my system)\r\n\r\n<table><tr><td><img width=600px src=\"https://user-images.githubusercontent.com/52205/95372150-2baa2c00-08a9-11eb-915f-c116add7bfd8.png\" alt=\"image\" /></td></tr></table>\r\n\r\n","createdAt":"2020-10-07T18:29:07Z","includesCreatedEdit":true,"isMinimized":false,"minimizedReason":"","reactionGroups":[{"content":"CONFUSED","users":{"totalCount":1}},{"content":"EYES","users":{"totalCount":2}}],"url":"https://github.com/dandavison/delta/issues/328#issuecomment-705116693","viewerDidAuthor":true}],"number":328,"title":"🐛 diff render issue on interactive patch `git add -p` with Windows Terminal"},{"body":"As far as I understand, `delta` uses `bat` for its syntax highlighting, etc… And `bat` supports having a config file (`bat --config-file /path/to/file` or by setting `BAT_CONFIG_PATH`), I'm interested in the second case `BAT_CONFIG_PATH`.\r\n\r\nIn this file you can have some file mapping like this for example:\r\n\r\n```\r\n--map-syntax '.gitconfig.local:Git Config'\r\n--map-syntax '.zsh*:Bourne Again Shell (bash)'\r\n--map-syntax '.vimrc.local:VimL'\r\n--map-syntax 'vimrc:VimL'\r\n```\r\n\r\nBut it seems like this is not being picked up by the `bat` version used by `delta`","comments":[{"id":"MDEyOklzc3VlQ29tbWVudDY5NTExNzk5MA==","author":{"login":"dandavison"},"authorAssociation":"OWNER","body":"Hi @ahmedelgabri, thanks for this, but delta doesn't use bat for syntax highlighting. So, currently at least, delta doesn't look at the bat config file. So, perhaps this is best turned into a feature request for `map-syntax` functionality in delta? I'll have to think about whether we should go down the path of honoring the bat config `map-syntax` entries. Although in practice I know one would almost always want the same mappings in both, it may not make sense to link the two applications like that -- what do you think? There is one point of shared configuration at the moment -- delta honors the `BAT_THEME` env var.","createdAt":"2020-09-18T22:47:57Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/326#issuecomment-695117990","viewerDidAuthor":true},{"id":"MDEyOklzc3VlQ29tbWVudDY5NTExODk1Mw==","author":{"login":"ahmedelgabri"},"authorAssociation":"NONE","body":"If delta honors `BAT_THEME` already why not honor the config too. The config can actually contain the theme too. ","createdAt":"2020-09-18T22:52:22Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/326#issuecomment-695118953","viewerDidAuthor":false},{"id":"MDEyOklzc3VlQ29tbWVudDY5NTExOTU1MA==","author":{"login":"ahmedelgabri"},"authorAssociation":"NONE","body":"Unless you plan not to use bat, I don’t see why you shouldn’t pick up it’s config. Yes it will couple the projects together but bat can be used as a library already so it’s not like you are going to be tied to an external app. It can be a direct dependency of the project which you can swap later if you want. ","createdAt":"2020-09-18T22:54:55Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[{"content":"THUMBS_UP","users":{"totalCount":1}}],"url":"https://github.com/dandavison/delta/issues/326#issuecomment-695119550","viewerDidAuthor":false},{"id":"MDEyOklzc3VlQ29tbWVudDcxMTQzMzQ0NA==","author":{"login":"nickspoons"},"authorAssociation":"NONE","body":"I found this confusing too, when trying to work out how to map my `~/.vim/vimrc` syntax to `VimL`, which worked as expected for `bat ~/.vim/vimrc` but not `git diff ~/.vim/vimrc`.\r\n\r\n+1 for some form of `map-syntax` for delta. I don't understand where delta is using bat and where it is not, as a new user it _seems_ like the bat config file would have been used here. Clearly not, but if parsing the bat config file is an option, that might make things \"just work\" for a lot of users. For 2 of us, at least :smile:","createdAt":"2020-10-18T22:29:26Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/326#issuecomment-711433444","viewerDidAuthor":false},{"id":"MDEyOklzc3VlQ29tbWVudDcxODcwODQ0Mg==","author":{"login":"SuperCuber"},"authorAssociation":"NONE","body":"> I don't understand where delta is using bat and where it is not, as a new user it seems like the bat config file would have been used here\r\n\r\nI agree with this, the readme mentions over and over how delta supports everything bat does so I just assumed that it uses bat as a dependency and the config would work. In particular I'm also interested in having the equivalent of `--map-syntax 'vimrc:VimL'`","createdAt":"2020-10-29T12:03:26Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[{"content":"THUMBS_UP","users":{"totalCount":1}}],"url":"https://github.com/dandavison/delta/issues/326#issuecomment-718708442","viewerDidAuthor":false},{"id":"MDEyOklzc3VlQ29tbWVudDcyMzE1MTY2Nw==","author":{"login":"dandavison"},"authorAssociation":"OWNER","body":"Thanks for the design input here @ahmedelgabri @nickspoons @SuperCuber. On the one hand the way the documentation has mentioned bat has caused some confusion, and there is probably no need for delta to support `BAT_PAGER` for example, seeing as we have `DELTA_PAGER` and `PAGER`. But on the other hand Delta does absolutely make use of the syntax and theme assets from the bat project, so perhaps that's an area where they should be coupled at the level of configuration files?\r\n\r\ncc @MarcoIeni @Kr1ss-XD any thoughts here?\r\n\r\nref #116 \"Make use of bat as a library\"","createdAt":"2020-11-06T15:49:01Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[{"content":"THUMBS_UP","users":{"totalCount":5}}],"url":"https://github.com/dandavison/delta/issues/326#issuecomment-723151667","viewerDidAuthor":true},{"id":"MDEyOklzc3VlQ29tbWVudDcyMzIxMDE3Nw==","author":{"login":"Kr1ss-XD"},"authorAssociation":"CONTRIBUTOR","body":"On the one hand I think it would be nice if delta could parse the bat configuration file and make use of the settings in it, to have a single place where syntax- and color-schemes would be defined.\r\n\r\nNonetheless, I __do__ find it really useful that I can define _different_ settings for\r\n\r\na) standalone use of bat, and\r\nb) syntax highlighting with delta.\r\n\r\nHence my suggestion would be to either \r\n\r\n- use bat's config file, but only as a default for the `delta.<xyz>` options in `gitconfig` that we currently have, so that its options can be overridden, or\r\n- introduce an additional option like `delta.batconfig` or similar, so one can have a \"delta-specific\" bat configuration in addition to the default one for general use of bat.\r\n\r\nIf it comes to one of these two alternatives, I'd prefer the first one. It would cause less of a change compared to the current status.","createdAt":"2020-11-06T17:41:44Z","includesCreatedEdit":true,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/326#issuecomment-723210177","viewerDidAuthor":false},{"id":"MDEyOklzc3VlQ29tbWVudDcyMzI4ODgzMA==","author":{"login":"dandavison"},"authorAssociation":"OWNER","body":"I definitely agree we need to make map-syntax functionality available for delta: the situation with the vim config files sounds really annoying :/\r\n\r\nThe syntax of the bat config file is simply strings representing bat command line options. So one option would be to undertake to read that but only respect certain entries such as `--map-syntax`. However, delta and bat have similar and partially overlapping sets of command line options. Delta can't honor all the entries in the bat config file and I worry that partial honoring of the bat config file will be the source of even more confusion. @ahmedelgabri what do you think?\r\n\r\nI'm honestly not sure yet what's best here, so do keep the opinions coming! What we're talking about is configuring the usage of the binary sublime syntax and theme definitions that both delta and bat use. Other than `--map-syntax` and `BAT_THEME` (aka `--syntax-theme` in delta and `--theme` in bat) are there any other points of configuration that we should be considering in this conversation?\r\n\r\n> Nonetheless, I do find it really useful that I can define different settings\r\n\r\n@Kr1ss-XD I'm guessing you wouldn't want to map syntax differently in bat vs delta, right?","createdAt":"2020-11-06T20:37:31Z","includesCreatedEdit":true,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/326#issuecomment-723288830","viewerDidAuthor":true},{"id":"MDEyOklzc3VlQ29tbWVudDcyMzI5MDQyMA==","author":{"login":"Kr1ss-XD"},"authorAssociation":"CONTRIBUTOR","body":"> I'm guessing you wouldn't want to map syntax differently in bat vs delta, right?\r\n\r\nNo, I only find different color themes convenient. Sorry if I wasn't precise.","createdAt":"2020-11-06T20:41:46Z","includesCreatedEdit":true,"isMinimized":false,"minimizedReason":"","reactionGroups":[{"content":"THUMBS_UP","users":{"totalCount":2}}],"url":"https://github.com/dandavison/delta/issues/326#issuecomment-723290420","viewerDidAuthor":false},{"id":"MDEyOklzc3VlQ29tbWVudDcyMzMwOTg4NQ==","author":{"login":"dandavison"},"authorAssociation":"OWNER","body":"cc @ryuta69 who's also been thinking about ways to make command line configuration and on-the-fly config changes more convenient.\r\n\r\n> No, I only find different color themes convenient. Sorry if I wasn't precise.\r\n\r\nNot at all; very helpful.","createdAt":"2020-11-06T21:33:55Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/326#issuecomment-723309885","viewerDidAuthor":true},{"id":"MDEyOklzc3VlQ29tbWVudDcyMzMxNjA0Mw==","author":{"login":"ahmedelgabri"},"authorAssociation":"NONE","body":"> The syntax of the bat config file is simply strings representing bat command line options. So one option would be to undertake to read that but only respect certain entries such as `--map-syntax`. However, delta and bat have similar and partially overlapping sets of command line options. Delta can't honor all the entries in the bat config file and I worry that partial honoring of the bat config file will be the source of even more confusion. @ahmedelgabri what do you think?\r\n\r\nFor me, what I only want from delta to respect from bat is only the syntax mapping, the rest doesn't make sense to support (at least for me) I don't want to configure two places/tools to do the same thing if one of them consumes the other already. ","createdAt":"2020-11-06T21:51:36Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/326#issuecomment-723316043","viewerDidAuthor":false},{"id":"MDEyOklzc3VlQ29tbWVudDcyMzMzMzkxNg==","author":{"login":"MarcoIeni"},"authorAssociation":"CONTRIBUTOR","body":"> cc @MarcoIeni @Kr1ss-XD any thoughts here?\r\n\r\nI am not an heavy delta user, so I don't have any particular opinion about this, but I will keep this discussion in mind while trying to solve #116 ","createdAt":"2020-11-06T22:47:30Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/326#issuecomment-723333916","viewerDidAuthor":false},{"id":"MDEyOklzc3VlQ29tbWVudDc3MDcxNzU1OA==","author":{"login":"bamonroe"},"authorAssociation":"NONE","body":"I would love to see the `--map-syntax` feature in delta, but until it gets there, a way to add your syntax mapping is to compile the syntaxes.bin file using bat. I did the following assuming `bat` was already installed to give files with a `Rnw` extension Latex syntax highlighting:\r\n\r\n```\r\n# Clone bat to get the syntax files it uses\r\ngit clone --recursive https://github.com/sharkdp/bat\r\n# Make the default bat config dir\r\nmkdir -p \"$(bat --config-dir)/syntaxes\"\r\n# Copy the syntax dir for the language you want to extend\r\ncp -r bat/assets/syntaxes/01_Packages/LaTeX \"$(bat --config-dir)/syntaxes/\"\r\n# Add the extension you want to add to the list of \"file_extensions:\" at the top of the file (Rnw for me)\r\nnvim \"$(bat --config-dir)/syntaxes/LaTeX/LaTeX.sublime-syntax\"\r\n# Build the bat cache\r\nbat cache --build\r\n```\r\nNow I see \"Rnw\" under LaTeX when I run `delta --list-languages` and I get LaTeX syntax highlighting with Rnw files. If you have constantly changing file extensions, much of this could be automated with some shell scripts and clever use of `sed`. Hope this helps.\r\n","createdAt":"2021-02-01T09:36:39Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[{"content":"THUMBS_UP","users":{"totalCount":4}},{"content":"HOORAY","users":{"totalCount":2}},{"content":"EYES","users":{"totalCount":1}}],"url":"https://github.com/dandavison/delta/issues/326#issuecomment-770717558","viewerDidAuthor":false},{"id":"MDEyOklzc3VlQ29tbWVudDc3MTU4MDc2Ng==","author":{"login":"gibfahn"},"authorAssociation":"NONE","body":"I'd be fine with different options in delta vs bat, and with copying things from my bat config to my delta config.\r\n\r\nIdeally the argument names would be the same so I could just copy the `--map-syntax` lines into my git config, but it's not the end of the world.\r\n\r\nPulling some options from the bat config seems possible, but would also be confusing if only some options were respected.","createdAt":"2021-02-02T11:48:19Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[{"content":"THUMBS_UP","users":{"totalCount":1}}],"url":"https://github.com/dandavison/delta/issues/326#issuecomment-771580766","viewerDidAuthor":false},{"id":"MDEyOklzc3VlQ29tbWVudDg2OTMzNDg0MA==","author":{"login":"djmattyg007"},"authorAssociation":"NONE","body":"I agree with @gibfahn. I don't care if I have to maintain two separate sets of configuration (I already do), I just want the option to exist in delta so I can make use of it.","createdAt":"2021-06-28T04:03:27Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/326#issuecomment-869334840","viewerDidAuthor":false},{"id":"IC_kwDOC4j8g848rAMP","author":{"login":"phil-blain"},"authorAssociation":"CONTRIBUTOR","body":"I would also like some way to customize the syntax detection, based on the file extension. For example, I'd want `*.ftn90` files to be recognized as \"Fortran (Modern)\", so I would like to be able to put something to that effect in my `.gitconfig` .\r\n\r\n---\r\n\r\nAs an aside, delta would be even more amazing if it could use the [`diff` Git attribute mechanism](https://git-scm.com/docs/gitattributes#_defining_a_custom_hunk_header) to choose which language syntax to apply. Meaning, if I already have in my `.gitattributes`:\r\n\r\n```\r\n*.ftn90 diff=fortran\r\n```\r\n\r\nthen delta would recognize those files as Fortran without me having to configure delta itself. One could even think of a further fall back to GitHub's and GitLab's special attributes for syntax highlighting:\r\n\r\n- https://github.com/github/linguist/blob/master/docs/overrides.md\r\n- https://docs.gitlab.com/ee/user/project/highlighting.html","createdAt":"2022-01-20T20:35:02Z","includesCreatedEdit":true,"isMinimized":false,"minimizedReason":"","reactionGroups":[{"content":"THUMBS_UP","users":{"totalCount":2}}],"url":"https://github.com/dandavison/delta/issues/326#issuecomment-1017905935","viewerDidAuthor":false},{"id":"IC_kwDOC4j8g848rDfO","author":{"login":"dandavison"},"authorAssociation":"OWNER","body":"Those sound like good suggestions @phil-blain. In the absence of any actual work on this I just want to point out that it is possible to work around this by\r\n\r\n1. Install bat\r\n2. Copy the target syntax definition into `~/.config/bat/syntaxes/` with a new name. I.e. something like\r\n ```\r\n cp bat/assets/syntaxes/02_Extra/Fortran/grammars/FortranModern.sublime-syntax ~/.config/bat/syntaxes/Fortran90.sublime-syntax\r\n ```\r\n3. Modify the file in `~/.config/bat/syntaxes` so that it has the desired file suffix\r\n4. Run `bat cache --build`\r\n\r\n~~However. Please note that delta is not compatible with the binary assets produced by the newest version of bat. See https://github.com/dandavison/delta/issues/895. So either use an older version of bat < v0.19.0, or use my experimental delta branch: https://github.com/dandavison/delta/pull/903~~\r\n\r\nIf you have a recent bat version, then this requires delta >= 0.12.1.\r\n","createdAt":"2022-01-20T20:54:59Z","includesCreatedEdit":true,"isMinimized":false,"minimizedReason":"","reactionGroups":[{"content":"HOORAY","users":{"totalCount":3}}],"url":"https://github.com/dandavison/delta/issues/326#issuecomment-1017919438","viewerDidAuthor":true},{"id":"IC_kwDOC4j8g848rFnU","author":{"login":"phil-blain"},"authorAssociation":"CONTRIBUTOR","body":"Thanks a lot for that suggestion, that's really great!","createdAt":"2022-01-20T21:06:56Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/326#issuecomment-1017928148","viewerDidAuthor":false}],"number":326,"title":"🚀 Provide a map-syntax feature, like bat does"},{"body":"This library looks great! Is it possible to use it as a crate in another rust project? `gitui` could really benefit from such state of the art diff visualisation","comments":[{"id":"MDEyOklzc3VlQ29tbWVudDY4ODMxOTEzNw==","author":{"login":"Kr1ss-XD"},"authorAssociation":"CONTRIBUTOR","body":"Nice one ! That would be great.","createdAt":"2020-09-07T13:15:54Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/317#issuecomment-688319137","viewerDidAuthor":false},{"id":"MDEyOklzc3VlQ29tbWVudDY4ODMyMTY3Mg==","author":{"login":"dandavison"},"authorAssociation":"OWNER","body":"Hi @extrawurst, thanks! Delta isn't currently structured as a library for Cargo, but shall we sketch out what the minimal version of this could look like? The delta test suite already contains a function that takes an input diff as a string, and a delta config struct, and returns delta output as a string. So, as a quick first thought, If we exposed functions like these, is there any chance that that could suffice as a minimal first version of the library?\r\n https://github.com/dandavison/delta/blob/6912b4df9507ca43fdcacbaf4b9e07fdb6a26646/src/tests/integration_test_utils.rs#L74-L84\r\n\r\nhttps://github.com/dandavison/delta/blob/6912b4df9507ca43fdcacbaf4b9e07fdb6a26646/src/tests/integration_test_utils.rs#L51-L53\r\n\r\nWhat sort of API would you like to see there?","createdAt":"2020-09-07T13:20:03Z","includesCreatedEdit":true,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/317#issuecomment-688321672","viewerDidAuthor":true},{"id":"MDEyOklzc3VlQ29tbWVudDY4ODMzNzcxOA==","author":{"login":"extrawurst"},"authorAssociation":"NONE","body":"@dandavison ok I might need more context here. what kind of `input` would that require? and what output does it generate?","createdAt":"2020-09-07T13:47:29Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/317#issuecomment-688337718","viewerDidAuthor":false},{"id":"MDEyOklzc3VlQ29tbWVudDY4ODM3MTAzOQ==","author":{"login":"dandavison"},"authorAssociation":"OWNER","body":"`input` would be a string containing the stdout of a git diff command (`git diff`, `git show`, `git log -p`, `git stash show -p` etc) or `diff -u`. The return value would be a new string, representing the same diff as the input string, but with ANSI color escape sequences inserted to effect delta's coloring, and possibly with additional decoration elements (boxes, lines, reconfigured hunk header, side-by-side layout, line numbers). The details of exactly which colors and decoration elements would be applied to the input would be determined by the `config` struct. Basically every option mentioned in the delta README would be configurable by setting a value on the `config` struct.","createdAt":"2020-09-07T14:46:17Z","includesCreatedEdit":true,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/317#issuecomment-688371039","viewerDidAuthor":true},{"id":"MDEyOklzc3VlQ29tbWVudDY4ODM3MjQ2MA==","author":{"login":"dandavison"},"authorAssociation":"OWNER","body":"Incidentally, lazygit already uses delta, but as I understand it lazygit calls git as an external process whereas you are using libgit2. Is that right? So lazygit didn't need delta as a library; a delta process is just inserted in between git's output and lazygit's input.","createdAt":"2020-09-07T14:48:52Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/317#issuecomment-688372460","viewerDidAuthor":true},{"id":"MDEyOklzc3VlQ29tbWVudDY4ODM4MDg5Mw==","author":{"login":"dandavison"},"authorAssociation":"OWNER","body":"More precisely, I think the input might be three things:\r\n\r\n1. A string containing git's diff output\r\n2. A [`git2::Config`](https://docs.rs/git2/0.13.10/git2/struct.Config.html) struct representing the user's git config (which might have relevant delta config).\r\n3. Some additional delta command line options (optional)\r\n\r\nSo my question at this stage is: would an API something like this give you what you need?\r\n\r\n```rust\r\n/// Run delta on `git_output` (a string containing a diff in git/unified diff format), respecting\r\n/// relevant configuration in `git_config` and `command_line_options`. Return a string containing\r\n/// the diff as represented by delta: i.e. with colors and optional decorations, optionally in\r\n/// side-by-side layout, with line-numbers, etc, as specified by `git_config` and\r\n/// `command_line_options`.\r\npub fn delta(git_output: &str, git_config: &git2::Config, command_line_options: &[&str]) -> String {\r\n}\r\n```","createdAt":"2020-09-07T15:04:28Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/317#issuecomment-688380893","viewerDidAuthor":true},{"id":"MDEyOklzc3VlQ29tbWVudDY5NjE4MzcyMg==","author":{"login":"dandavison"},"authorAssociation":"OWNER","body":"@extrawurst What would a minimal API look like that would be useful for your purposes?","createdAt":"2020-09-21T15:19:17Z","includesCreatedEdit":true,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/317#issuecomment-696183722","viewerDidAuthor":true},{"id":"MDEyOklzc3VlQ29tbWVudDcxMjA5MTY2MQ==","author":{"login":"jeroen"},"authorAssociation":"NONE","body":"I would be very interested in this if you can export headers that we can call from C. A good example is gifski: https://github.com/ImageOptim/gifski/blob/main/gifski.h\r\n\r\n","createdAt":"2020-10-19T11:24:46Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/317#issuecomment-712091661","viewerDidAuthor":false},{"id":"MDEyOklzc3VlQ29tbWVudDcxNDY2MjA4Ng==","author":{"login":"extrawurst"},"authorAssociation":"NONE","body":"@dandavison i guess I would need to be able to pass a buffer `a` and buffer `b` (I would get them straight out of `git2-rs` and then return me some kind of datastructure that allows me to render the lines correctly - I guess I am flexible on this end","createdAt":"2020-10-22T17:59:49Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[{"content":"ROCKET","users":{"totalCount":1}}],"url":"https://github.com/dandavison/delta/issues/317#issuecomment-714662086","viewerDidAuthor":false},{"id":"MDEyOklzc3VlQ29tbWVudDcxOTY2NzI4NA==","author":{"login":"Cldfire"},"authorAssociation":"NONE","body":"Hi! I just came by the repo looking for exactly this--I'd love a library version that could be called from Rust code 😄\r\n\r\nMy use case would just be to take two strings of source code and diff them. If a helper could be provided to handle creating the git diff so I didn't have to, that would be even more convenient, but either way works.","createdAt":"2020-10-30T16:48:21Z","includesCreatedEdit":true,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/317#issuecomment-719667284","viewerDidAuthor":false},{"id":"MDEyOklzc3VlQ29tbWVudDcyMzQyNTUxMQ==","author":{"login":"jonashaag"},"authorAssociation":"NONE","body":"I'm also interested in this. I maintain a Git web viewer written in Python, and I'd love to level up the diff rendering game by using delta, which has one of the best diff engines I've come across.\r\n\r\nThe interface of what I'm currently using is you pass old and new text: https://github.com/jonashaag/klaus/blob/3d090ec0a7ba62982b467e0f17813ba3d6a04c68/klaus/repo.py#L299-L301\r\n\r\nAnd you get back a list of line changes + metadata (old line number, new line number, type of modification): https://github.com/jonashaag/klaus/blob/3d090ec0a7ba62982b467e0f17813ba3d6a04c68/klaus/diff.py#L55-L63\r\n\r\nThe format of the line changes is described here: https://docs.python.org/3/library/difflib.html#difflib.SequenceMatcher.get_opcodes","createdAt":"2020-11-07T09:57:15Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/317#issuecomment-723425511","viewerDidAuthor":false},{"id":"MDEyOklzc3VlQ29tbWVudDcyMzQ4MDAzMA==","author":{"login":"dandavison"},"authorAssociation":"OWNER","body":"Hi all, thanks for the interest here. It should definitely be possible to refactor delta as a Rust crate exposing a function that can be passed a diff and will return a string containing the same diff altered by delta and with ANSI escape sequences representing colors, and also exposing the ability to create the necessary delta config object to control that process. I'd like to do this, but not sure yet when I'll find time.\r\n\r\n@jeroen exporting headers that can be called from C sounds interesting and I'm sure I'd learn a lot doing that.\r\n\r\n@jonashaag your application sounds like it would involve exposing a substantially lower-level interface in delta: i.e. instead of returning a string adorned with ANSI escape sequences, you want a delta library function that returns a data structure describing the results of its within-line edit inference process. How would you interface with such a Rust function from Python? Or would you write a small Rust executable that uses delta as a library, call that as a separate process from your python code, and parse its output into the necessary python data structures?","createdAt":"2020-11-07T18:40:56Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/317#issuecomment-723480030","viewerDidAuthor":true},{"id":"MDEyOklzc3VlQ29tbWVudDcyMzQ4MDYxNw==","author":{"login":"jonashaag"},"authorAssociation":"NONE","body":"Yes, either of the interfacing is fine as long as I don’t have to parse ANSI sequences 😀. If you export a C interface that’s even easier to interface from Python (or at least it doesn’t require any additional dependencies). Even a text based interface that’s not based on ANSI sequences would be fine. ","createdAt":"2020-11-07T18:46:59Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[{"content":"THUMBS_UP","users":{"totalCount":1}}],"url":"https://github.com/dandavison/delta/issues/317#issuecomment-723480617","viewerDidAuthor":false},{"id":"IC_kwDOC4j8g849XEsr","author":{"login":"raphCode"},"authorAssociation":"NONE","body":"\r\nThere is still interest from other projects in a library feature, e.g. https://github.com/extrawurst/gitui/issues/358#issuecomment-1029273184.\r\n\r\nIs there anything we can do to help the process?\r\nIf I read correctly we need to agree on an useful API first?\r\n\r\nMy take on this would probably be datastructures wrapping each line/changed word to indicate if it was added/removed. This seems to correspond to the implementation of https://github.com/mitsuhiko/similar, which is also a rust diff library.\r\n\r\nAn alternative \"out-of-band\" signalling datastructure could be also interesting, since it plays nice with separate syntax highlighting: You have a buffer of text, and some structs to annotate a certain range of bytes/chars. These annotations could be diff-related or colors for syntax highlighting.\r\nAnnotation data for different purposes can be easily merged when printing to the screen, by iterating the annotations and text simultaneously.","createdAt":"2022-02-03T22:25:21Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/317#issuecomment-1029458731","viewerDidAuthor":false},{"id":"IC_kwDOC4j8g849gvid","author":{"login":"th1000s"},"authorAssociation":"COLLABORATOR","body":"For benchmarking I have done some experimental librarification in #902 and one way forward would be to leave the binary in this `git-delta` crate and have its version number refer to the API stability of the command line and configs.\r\n\r\nThen most code is moved into `lib-git-delta-experimental`, where the \"real\" delta binary is present in the `[[bin]]` section. This crate would primarily serve `git-delta` for now and its version would remain `0.0.xyz` while experimenting with various APIs.\r\n\r\nFor now grabbing an entire diff via `delta(lines_in, &mut writer, &config)` could be used by `gitui`. A streaming version would have to be created for larger input.","createdAt":"2022-02-07T22:20:01Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[{"content":"THUMBS_UP","users":{"totalCount":2}}],"url":"https://github.com/dandavison/delta/issues/317#issuecomment-1031993501","viewerDidAuthor":false},{"id":"IC_kwDOC4j8g849gyba","author":{"login":"dandavison"},"authorAssociation":"OWNER","body":"Thanks @th1000s -- I'd be very happy to keep up movement on here and get the librarification refactor in #902 in. Currently the use of `///` docs is very patchy and inconsistent so we might want to disable that.","createdAt":"2022-02-07T22:35:49Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[{"content":"THUMBS_UP","users":{"totalCount":2}},{"content":"EYES","users":{"totalCount":1}}],"url":"https://github.com/dandavison/delta/issues/317#issuecomment-1032005338","viewerDidAuthor":true},{"id":"IC_kwDOC4j8g85VwMfp","author":{"login":"dandavison"},"authorAssociation":"OWNER","body":"Please see https://github.com/dandavison/delta/pull/1013 and https://github.com/dandavison/delta/pull/1017 for the current state of librarification work. Please shout out if you're interested in working on this (AFAIK no-one currently is).","createdAt":"2023-02-21T15:41:11Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[{"content":"HEART","users":{"totalCount":1}}],"url":"https://github.com/dandavison/delta/issues/317#issuecomment-1438697449","viewerDidAuthor":true},{"id":"IC_kwDOC4j8g85VwQb3","author":{"login":"extrawurst"},"authorAssociation":"NONE","body":"> A streaming version would have to be created for larger input.\r\n\r\nat this point streaming way to do it is not even the scope (at least for gitui, we at this point libgit2 for diffing and it also does not support a streaming version)","createdAt":"2023-02-21T15:52:04Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/317#issuecomment-1438713591","viewerDidAuthor":false}],"number":317,"title":"🚀 Using delta as library"},{"body":"Sorry if this is repeated. I didn't find any similar issues.\r\n\r\nCurrently, when the line length exceeds its column, an arrow indicates that the line continues\r\n\r\n\r\nI wish we could wrap the line like `bat` currently does and keep the diff highlighting.\r\n\r\nBat with line wrapping\r\n\r\n","comments":[{"id":"MDEyOklzc3VlQ29tbWVudDY3ODgzMzIxMQ==","author":{"login":"makew0rld"},"authorAssociation":"NONE","body":"I have a similar issue.\r\n\r\n\r\n\r\nMy lines are not wrapped at all when not in side-by-side mode, and so they go over where the line numbers would be. It'd be nice if the terminal size could be detected and then accounted for.","createdAt":"2020-08-23T22:32:39Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[{"content":"THUMBS_UP","users":{"totalCount":3}}],"url":"https://github.com/dandavison/delta/issues/299#issuecomment-678833211","viewerDidAuthor":false},{"id":"MDEyOklzc3VlQ29tbWVudDY4MDY3MjQzMA==","author":{"login":"mnsgs"},"authorAssociation":"NONE","body":"I am seeing the same issue as referred by @augustobmoura - pretty much a standard Ubuntu 20.04 installation with the git/delta config:\r\n\r\n```\r\n[delta]\r\n line-numbers = true\r\n side-by-side = true\r\n plus-color = \"#012800\"\r\n minus-color = \"#340001\"\r\n syntax-theme = Monokai Extended\r\n\r\n```\r\ndelta is of version 0.4.1.","createdAt":"2020-08-26T05:54:03Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/299#issuecomment-680672430","viewerDidAuthor":false},{"id":"MDEyOklzc3VlQ29tbWVudDY4MTk3NTI1Mw==","author":{"login":"dandavison"},"authorAssociation":"OWNER","body":"Hi all, thanks for this. I agree implementing line wrapping like bat does would be a nice feature. I don't think I'm going to be able to work on this in the near future so I'd welcome a pull request and am also happy to discuss what the code change might involve.\r\n \r\nSome notes: There's a couple of related aspects to this:\r\n\r\n1. line wrapping respecting the line numbers panel in normal mode\r\n2. line wrapping in side-by-side mode, in the left panel and right panel \r\n\r\nIn normal mode we don't lose content today, it's just that it's not wrapped prettily in line-numbers mode. Personally I have the `-S` flag set in less, i.e. it's `less -RS`, so that content never wraps in normal mode (I personally find wrapped code very hard to read and prefer to scroll right when necessary).\r\n\r\nHowever in side-by-side mode we currently lose content, because we can't allow the left panel to flow into the right panel's area and I did not attempt to implement line wrapping in the initial implementation of side-by-side because it would have been made the code change significantly more complicated than it already was.\r\n\r\nIt's maybe worth noting that in side-by-side mode, it is possible to have the panels use up more horizontal space than your terminal window has, by setting `--width X` (where X > your terminal width) and using the `-S` flag with less, and scroll right when needed.\r\n\r\nPerhaps some of this could be helpful in the README.","createdAt":"2020-08-27T14:13:11Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[{"content":"THUMBS_UP","users":{"totalCount":7}}],"url":"https://github.com/dandavison/delta/issues/299#issuecomment-681975253","viewerDidAuthor":true},{"id":"MDEyOklzc3VlQ29tbWVudDcxNTMxMTc2Mw==","author":{"login":"kevinhwang91"},"authorAssociation":"NONE","body":"sometimes I really want an option to truncate the long line. If with `less -RS`, the wrapping line symbol looks extremely ugly.\r\n\r\n\r\n","createdAt":"2020-10-23T12:29:41Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/299#issuecomment-715311763","viewerDidAuthor":false},{"id":"MDEyOklzc3VlQ29tbWVudDcxNTUyNzQxNA==","author":{"login":"dandavison"},"authorAssociation":"OWNER","body":"@kevinhwang91 can you give a full example of a diff that you can't display in the way you want, and show the delta settings you're using? Note that we do have `max-line-length` now:\r\n\r\n```\r\n--max-line-length <max-line-length>\r\n Truncate lines longer than this. To prevent any truncation, set to zero. Note that syntax-highlighting very\r\n long lines (e.g. minified .js) will be very slow if they are not truncated [default: 512]\r\n```","createdAt":"2020-10-23T19:03:34Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[{"content":"THUMBS_UP","users":{"totalCount":2}},{"content":"HEART","users":{"totalCount":1}}],"url":"https://github.com/dandavison/delta/issues/299#issuecomment-715527414","viewerDidAuthor":true},{"id":"MDEyOklzc3VlQ29tbWVudDcxNTY5MzIzNA==","author":{"login":"kevinhwang91"},"authorAssociation":"NONE","body":"> @kevinhwang91 can you give a full example of a diff that you can't display in the way you want, and show the delta settings you're using? Note that we do have `max-line-length` now:\r\n> \r\n> ```\r\n> --max-line-length <max-line-length>\r\n> Truncate lines longer than this. To prevent any truncation, set to zero. Note that syntax-highlighting very\r\n> long lines (e.g. minified .js) will be very slow if they are not truncated [default: 512]\r\n> ```\r\n\r\nIt works, could delta adjust its value by the `COLUMNS` of the current terminal?\r\nBTW, I found that it excludes the line number. I have no idea to zoom `git diff` to my column and truncate any chars long than my column.","createdAt":"2020-10-24T04:58:44Z","includesCreatedEdit":true,"isMinimized":false,"minimizedReason":"","reactionGroups":[{"content":"THUMBS_UP","users":{"totalCount":1}}],"url":"https://github.com/dandavison/delta/issues/299#issuecomment-715693234","viewerDidAuthor":false},{"id":"MDEyOklzc3VlQ29tbWVudDcxNTkzNDIyNw==","author":{"login":"Kr1ss-XD"},"authorAssociation":"CONTRIBUTOR","body":"This doesn't seem to work in the git config files @kevinhwang91 - but I can achieve it with\r\n```sh\r\ngit -c \"core.pager=delta --max-line-length=$((COLUMNS - 10))\" <git-subcommand>\r\n```\r\n\r\nNote that I needed to subtract 10 because the columns for the line numbers seem not to be included in the max-line-length that delta calculates. Depending on your configuration for line-number formatting, this might be a value smaller or greater than 10.\r\n\r\nI agree it would be nice if delta could take the current terminal width into account. Besides `$COLUMNS`, it can also be queried by `$(tput cols)` if that helps. ","createdAt":"2020-10-24T15:24:30Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[{"content":"THUMBS_UP","users":{"totalCount":3}}],"url":"https://github.com/dandavison/delta/issues/299#issuecomment-715934227","viewerDidAuthor":false},{"id":"MDEyOklzc3VlQ29tbWVudDc2NjYwMzUwOA==","author":{"login":"kevinhwang91"},"authorAssociation":"NONE","body":"> ```shell\r\n> git -c \"core.pager=delta --max-line-length=$((COLUMNS - 10))\" <git-subcommand>\r\n> ```\r\n\r\nThanks, but I think I'm encountering an issue for delta, @dandavison , it seems that `--max-line-length` work as unexpected, here is the screenshot:\r\n\r\n","createdAt":"2021-01-25T07:17:02Z","includesCreatedEdit":true,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/299#issuecomment-766603508","viewerDidAuthor":false},{"id":"IC_kwDOC4j8g847cvHV","author":{"login":"CoelacanthusHex"},"authorAssociation":"NONE","body":"I have tried auto line-wrapping algorithm implemented in https://github.com/dandavison/delta/pull/515, it works very well.\r\nBut I don't use side-by-side mode, many other users also don't use side-by-side mode. \r\nAnd there are some modes that can't use side-by-side mode, such as `git blame`.\r\nSo we need the same auto line-wrapping algorithm as the one in side-by-side when we don't use side-by-side mode.\r\nIt maybe can reuse code, and core algorithm has been implemented.\r\nHope you can add it soon, we really require this feature to display our `git diff` and `git blame` better!\r\nThank you!\r\n\r\ncc @th1000s, you have implemented line-wrapping in side-by-side mode, Could you please also take a look at the implementation of the line-wrapping algorithm in the non-side-by-side mode? Thanks very much!","createdAt":"2021-12-19T13:05:41Z","includesCreatedEdit":true,"isMinimized":false,"minimizedReason":"","reactionGroups":[{"content":"THUMBS_UP","users":{"totalCount":4}},{"content":"EYES","users":{"totalCount":3}}],"url":"https://github.com/dandavison/delta/issues/299#issuecomment-997388757","viewerDidAuthor":false},{"id":"IC_kwDOC4j8g85JSClz","author":{"login":"msrd0"},"authorAssociation":"NONE","body":"Line wrapping by default for some languages like LaTeX would be extremely helpful. I find it quite annoying to do manual linebreaks for natural language paragraphs, where I want all lines to be of similar length (this is very different to source code of course). Line wrapping in text editors does exactly that. For now I'm using `pager = delta --wrap-max-lines 16`, but ultimately I'd like lines of any length to be wrapped with `.tex` files, but no line wrapping for _ugly_ files like `.min.js` or `.min.css`.","createdAt":"2022-08-28T14:07:13Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[{"content":"THUMBS_UP","users":{"totalCount":3}}],"url":"https://github.com/dandavison/delta/issues/299#issuecomment-1229465971","viewerDidAuthor":false}],"number":299,"title":"🚀 Optional line wrapping"},{"body":"Hi, thanks for sharing this amazing tool.\r\n\r\nI noticed that when we have a comment that was added, the contrast of grey text on the green background is extremely low which makes it hard to read. Perhaps we could increase the brightness of the text, or increase the darkness of the green background?\r\n\r\n\r\n","comments":[{"id":"MDEyOklzc3VlQ29tbWVudDY3NDk0OTM2NA==","author":{"login":"dandavison"},"authorAssociation":"OWNER","body":"Hi @OliverJAsh, thanks!\r\n\r\nI am definitely open to suggestions for how to improve the defaults, especially for dark backgrounds, for which I have always felt there is room for improvement. Have you tried experimenting with different syntax-highlighting themes (affecting foreground colours from syntax highlighting), and experimenting with the style options to adjust the background colours? The grey colour in your screenshot derives from the syntax highlighting theme, and the green background colour is `plus-style`.","createdAt":"2020-08-17T15:28:55Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/294#issuecomment-674949364","viewerDidAuthor":true},{"id":"MDEyOklzc3VlQ29tbWVudDY5NjU1NTk3Mw==","author":{"login":"jhpratt"},"authorAssociation":"NONE","body":"To me, it's not so much the addition line as it is the emphasized part of an addition line. Just about every built-in theme is (nearly) unreadable in that situation. This is with comment lines specifically (Rust if that matters).","createdAt":"2020-09-22T07:29:18Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/294#issuecomment-696555973","viewerDidAuthor":false},{"id":"MDEyOklzc3VlQ29tbWVudDY5Njc0MjY0Mg==","author":{"login":"dandavison"},"authorAssociation":"OWNER","body":"Hi @jhpratt, have you tried using `plus-emph-style` to select the color you want for emphasized parts of added lines? Similarly, @OliverJAsh, you can select the background color using `plus-style`.\r\n\r\nI'm happy to accept suggestions for different defaults!","createdAt":"2020-09-22T14:02:47Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/294#issuecomment-696742642","viewerDidAuthor":true},{"id":"MDEyOklzc3VlQ29tbWVudDY5NzAzMDg5Mg==","author":{"login":"jhpratt"},"authorAssociation":"NONE","body":"I didn't spend too long playing around with it, but I couldn't find anything that was green yet both distinguishable from the non-emphasized text and had sufficient contrast.","createdAt":"2020-09-22T23:14:57Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/294#issuecomment-697030892","viewerDidAuthor":false},{"id":"IC_kwDOC4j8g847WlsA","author":{"login":"eliezio"},"authorAssociation":"NONE","body":"I got a slightly better contrast with:\r\n\r\n```\r\nplus-style = \"syntax \\\"#184b54\\\"\"\r\nminus-style = \"syntax \\\"#642f33\\\"\"\r\n```\r\n\r\n\r\n","createdAt":"2021-12-16T12:35:45Z","includesCreatedEdit":true,"isMinimized":false,"minimizedReason":"","reactionGroups":[{"content":"HEART","users":{"totalCount":2}}],"url":"https://github.com/dandavison/delta/issues/294#issuecomment-995777280","viewerDidAuthor":false},{"id":"IC_kwDOC4j8g85CYS7_","author":{"login":"durka"},"authorAssociation":"NONE","body":"IMO the problem is the syntax color, not the backgorund color. Looking through `--show-syntax-themes`, Coldark-Dark and zenburn are somewhat better for making comments visible.","createdAt":"2022-04-29T19:48:33Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[{"content":"THUMBS_UP","users":{"totalCount":1}}],"url":"https://github.com/dandavison/delta/issues/294#issuecomment-1113665279","viewerDidAuthor":false},{"id":"IC_kwDOC4j8g851FsRy","author":{"login":"buckleyGI"},"authorAssociation":"NONE","body":"Thanks for putting me in the right direction @durka \r\n\r\nTheme Coldark-Dark works much better. If possible I would use this as the default.","createdAt":"2024-02-26T15:30:51Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/294#issuecomment-1964426354","viewerDidAuthor":false}],"number":294,"title":"Default dark theme: contrast is too low for comment in addition line"},{"body":"The logic in `git diff --function-context` will always print the preceding function on the top line, since that's \"technically\" the preceding code. This happens even if -U0 is provided, unfortunately.\r\n\r\nNote that here, other_routine is the top line, even though no changes are within other_routine.\r\n\r\n```c\r\nint other_routine() {\r\n}\r\n\r\nint main() {\r\n puts(\"Hello, world!\");\r\n return 0;\r\n}\r\n```\r\n\r\n```diff\r\n$ git diff -U0 --function-context\r\ndiff --git i/example.c w/example.c\r\nindex 346e2a7..0b40a82 100644\r\n--- i/example.c\r\n+++ w/example.c\r\n@@ -6,3 +6,4 @@ int other_routine() {\r\n int main() {\r\n puts(\"Hello, world!\");\r\n+ return 0;\r\n }\r\n\\ No newline at end of file\r\n```\r\n\r\nThis breaks scripts that rely on the top line to determine which function the changes are in, including `delta`.\r\n\r\nHere we can see that `delta` boxes the name `other_routine`, based on this information.\r\n\r\n<img width=\"372\" alt=\"Screen Shot 2020-07-20 at 5 44 02 PM\" src=\"https://user-images.githubusercontent.com/111640/87993628-9caf2400-cab0-11ea-9579-e439de83e657.png\">\r\n\r\nIt would be nice if there were a way to pass e.g. `--function-context` to delta such that it's able to recognize this situation.","comments":[{"id":"MDEyOklzc3VlQ29tbWVudDY2MzY0NTMwNQ==","author":{"login":"Amorymeltzer"},"authorAssociation":"NONE","body":"delta in general doesn't handle `-U0` well at all","createdAt":"2020-07-24T17:20:54Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/259#issuecomment-663645305","viewerDidAuthor":false},{"id":"MDEyOklzc3VlQ29tbWVudDY2NDQ0MDg1Mw==","author":{"login":"dandavison"},"authorAssociation":"OWNER","body":"Hi @zachriggle and @Amorymeltzer, thanks for opening this issue. I think that I'm failing so far to understand what delta should be doing differently (perhaps because I'm not familiar with `--function-context` or `-U0`). So would you be able to help me understand? I've made the images below, and annotated it on the left with my understanding. Hopefully this will help us get on the same page! Basically it's seeming to me that in all cases delta does what's expected -- it boxes the hunk header and displays and highlights correctly all the code that git sends in its standard output. I do not know why git sometimes selects `other_routine` as the hunk header. I know it's possible to change git's behavior by configuring the `xfuncname` regex (see e.g. [here](https://gist.github.com/ruediger/5647207)), but I don't know whether that leads to a fix for git's selection of `other_routine` here. Are you suggesting that delta should override git's choice of hunk header?\r\n\r\n> delta in general doesn't handle -U0 well at all\r\n\r\n@Amorymeltzer can you expand? :) As you can see I'm a bit lost!\r\n\r\n<table><tr><td><img width=800px src=\"https://user-images.githubusercontent.com/52205/88554800-edfd6d00-cff4-11ea-8ef7-835d7738bb37.png\" alt=\"image\" /></td></tr></table>","createdAt":"2020-07-27T14:45:50Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/259#issuecomment-664440853","viewerDidAuthor":true},{"id":"MDEyOklzc3VlQ29tbWVudDY2NDU3NjkxMA==","author":{"login":"Amorymeltzer"},"authorAssociation":"NONE","body":"@dandavison As far as `-U0` goes, have you tried it on something *other* than a test file? When I run it on something meaningful, **all** of the hunk headers are displayed one right after another with no code, then **all** of the code is displayed. Try this for the delta repo: `git diff -U0 b2257cf~..b2257cf`","createdAt":"2020-07-27T18:54:50Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/259#issuecomment-664576910","viewerDidAuthor":false},{"id":"MDEyOklzc3VlQ29tbWVudDY2NDU5MDIzOQ==","author":{"login":"dandavison"},"authorAssociation":"OWNER","body":"@Amorymeltzer wow thanks, well that's certainly a bug! I opened https://github.com/dandavison/delta/issues/263 Hopefully something easy to fix in the main diff parsing/line-emitting procedure.\r\n\r\nOK, so what about `--function-context`?","createdAt":"2020-07-27T19:22:48Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[{"content":"THUMBS_UP","users":{"totalCount":2}}],"url":"https://github.com/dandavison/delta/issues/259#issuecomment-664590239","viewerDidAuthor":true},{"id":"MDEyOklzc3VlQ29tbWVudDY2NDU5MzgzMQ==","author":{"login":"Amorymeltzer"},"authorAssociation":"NONE","body":"I'd sooner have @zachriggle comment as I'm not overly familiar with it (and my intent was not to hijack this), but from quickly playing around, it seems that delta is using the first line of context rather than the function itself. To use the shas I gave above, `git diff b2257cf~ b2257cf src/config.rs` shows hunk headers for `pub struct Config {` and `impl From<cli::Opt> for Config {` whereas `git diff b2257cf~ b2257cf src/config.rs` uses `use crate::style::Style;` and `impl Config {`","createdAt":"2020-07-27T19:30:43Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/259#issuecomment-664593831","viewerDidAuthor":false},{"id":"MDEyOklzc3VlQ29tbWVudDY2NDY2NDc4OA==","author":{"login":"zachriggle"},"authorAssociation":"NONE","body":"The only reason I used `-U0` was to show that the function name is still wrong, even if zero lines of the preceding function is printed in the diff. This still happens at all `-U` levels.","createdAt":"2020-07-27T22:13:04Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/259#issuecomment-664664788","viewerDidAuthor":false},{"id":"MDEyOklzc3VlQ29tbWVudDY2NDcyOTE1Ng==","author":{"login":"dandavison"},"authorAssociation":"OWNER","body":"> it seems that delta is using the first line of context rather than the function itself. \r\n\r\nDelta uses the part of the git/unified diff output that is marked with `@@`. Git documentation refers to this as the \"hunk header\" and \"frag\" (see [here](https://git-scm.com/docs/git-config#Documentation/git-config.txt-diffltdrivergtxfuncname) and [here](https://git-scm.com/docs/git-config#Documentation/git-config.txt-colordiffltslotgt)) and delta also uses that terminology in its CLI (`hunk-header-style`, `hunk-header-decoration-style`). I believe it's technically incorrect to refer to that as the first line of context: it's not part of the context -- it's typically determined by indentation level and may in fact occur in the code many lines prior to the start of the context.\r\n\r\n> the function name is still wrong, even if zero lines of the preceding function is printed in the diff.\r\n\r\nOK, but it was git that made this choice, not delta; delta takes git's output and correctly puts the hunk header in a box. E.g. taking the third row of the table above, the hunk header identified by git is `int other_routine() {`:\r\n\r\n\r\n\r\nDoes that sound right so far? If so, then is what we're contemplating here that what delta puts in a box is no longer necessarily the hunk header selected by git but possibly something that delta has identified as preferable?","createdAt":"2020-07-28T01:51:54Z","includesCreatedEdit":true,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/259#issuecomment-664729156","viewerDidAuthor":true},{"id":"MDEyOklzc3VlQ29tbWVudDY2NDkyMTM2Mg==","author":{"login":"Amorymeltzer"},"authorAssociation":"NONE","body":"Thanks — that seems an accurate summary. I (clearly!) don't know `--function-context` well (and this isn't my issue) but I would imagine that would be rather undesirable long-term.","createdAt":"2020-07-28T09:32:19Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/259#issuecomment-664921362","viewerDidAuthor":false},{"id":"MDEyOklzc3VlQ29tbWVudDY2NzY4OTUxOQ==","author":{"login":"dandavison"},"authorAssociation":"OWNER","body":"@zachriggle do you feel that there's something Delta could be doing better, or do you think that this is an aspect of Git's behavior that Delta should just accept and display? To recap what I was saying above:\r\n\r\n> Note that here, other_routine is the top line, even though no changes are within other_routine.\r\n\r\nI believe that what you're referring to as the \"top line\" is what I'm calling the \"hunk header\" or \"frag\" (and I'm saying that it's not part of the context). Accordingly, this\r\n\r\n> This breaks scripts that rely on the top line to determine which function the changes are in, including delta.\r\n\r\nisn't the way I think about it: I would say that the hunk header (top line) is the _definition_ of which function/class/code context the changes are in.\r\n\r\nDoes this make sense? Sorry if not; it's definitely possible that I'm missing something! In particular, I do not understand at all why Git is choosing `other_routine {` for the hunk header instead of `int main() {` (and I haven't yet gone and looked at the regexes and code that Git is using to do that, which is probably what I should do).","createdAt":"2020-08-02T15:39:57Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[{"content":"THUMBS_UP","users":{"totalCount":1}}],"url":"https://github.com/dandavison/delta/issues/259#issuecomment-667689519","viewerDidAuthor":true},{"id":"MDEyOklzc3VlQ29tbWVudDY2OTM3ODU3Mg==","author":{"login":"zachriggle"},"authorAssociation":"NONE","body":"@dandavison Right now, this is a limitation of Git's implementation. I also think that this is something that Delta could parse out the first function it finds, if given a special flag. I don't expect the default behavior of `delta` to change, but rather something extra it could do if given e.g. `--dont-trust-git-function-detection` or something.\r\n\r\nA good stop-gap measure would be to have a flag to simply disable the boxed function name, via a flag.","createdAt":"2020-08-05T18:33:21Z","includesCreatedEdit":true,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/259#issuecomment-669378572","viewerDidAuthor":false},{"id":"MDEyOklzc3VlQ29tbWVudDY3MDI3ODA4OQ==","author":{"login":"dandavison"},"authorAssociation":"OWNER","body":"@zachriggle thanks for bearing with me here.\r\n\r\n> I don't expect the default behavior of delta to change, but rather something extra it could do if given e.g. `--dont-trust-git-function-detection` or something.\r\n\r\nGreat, that makes sense and is interesting. I've had the same thought. I'll keep this open to record that feature idea.\r\n\r\n> A good stop-gap measure would be to have a flag to simply disable the boxed function name, via a flag.\r\n\r\nUnless I misunderstood, this is already available:\r\n\r\n```gitconfig\r\n[delta]\r\n hunk-header-style = omit\r\n```\r\n\r\n```\r\n--hunk-header-style <hunk-header-style>\r\n Style (foreground, background, attributes) for the hunk-header. See STYLES section. The style 'omit' can be\r\n used to remove the hunk header section from the output [default: syntax]\r\n```","createdAt":"2020-08-07T01:56:06Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/259#issuecomment-670278089","viewerDidAuthor":true}],"number":259,"title":"🚀 Improve on git's function/class detection"},{"body":"left side is github, right side is delta:\r\n\r\n\r\nHere is my config about delta:\r\n```zsh\r\nexport GIT_PAGER=\"delta -n --syntax-theme=TwoDark -w 1 \\\r\n --hunk-header-style='syntax bold' \\\r\n --hunk-header-decoration-style='black box' \\\r\n --file-style='yellow italic' \\\r\n --file-decoration-style='yellow ul' \\\r\n --minus-style='syntax #450a15' \\\r\n --minus-emph-style='syntax #600818' \\\r\n --plus-style='syntax #0b4820' \\\r\n --plus-emph-style='syntax #175c2e' \\\r\n --line-numbers-zero-style='#4b5263' \\\r\n --line-numbers-minus-style='syntax #600818' \\\r\n --line-numbers-plus-style='syntax #0b4820' \\\r\n --line-numbers-left-format='{nm:^4} ' --line-numbers-right-format='{np:^4} '\"\r\n```\r\n\r\nFrom the above image, UI of delta about line number is so weird.","comments":[{"id":"MDEyOklzc3VlQ29tbWVudDY1NzE3Mjk3NA==","author":{"login":"dandavison"},"authorAssociation":"OWNER","body":"Hi @kevinhwang91, yes you're right, the background colors aren't making much sense currently :/ Thanks for this! I'll have another think about this and modify the behavior (without changing the interface hopefully) so that the background colors form contiguous blocks in this situation.","createdAt":"2020-07-12T04:16:09Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[{"content":"THUMBS_UP","users":{"totalCount":6}}],"url":"https://github.com/dandavison/delta/issues/247#issuecomment-657172974","viewerDidAuthor":true},{"id":"IC_kwDOC4j8g85PFst6","author":{"login":"bew"},"authorAssociation":"NONE","body":"Hello, I'd be interested in this as well!\r\nHow is your thinking on how to do this?\r\n(I'd like to try to make a PR if you think it's good as a first contribution)","createdAt":"2022-11-24T23:39:39Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/247#issuecomment-1326893946","viewerDidAuthor":false},{"id":"IC_kwDOC4j8g85PJIMp","author":{"login":"dandavison"},"authorAssociation":"OWNER","body":"Hi @bew I'd be happy for someone to make this possible. I don't have time to look into it currently unfortunately. IIRC the current configuration interface doesn't quite make this possible. I would suggest:\r\n\r\n- **Step 1**: Play around with the various `line-numbers-*-style` options to convince yourself that it is/isn't possible today.\r\n\r\n- **Step 2**: Identify a way of making it possible, ideally without changing the meaning of current options, so that other user's configs are not broken. Alternatively, perhaps you identify some change to the options that _does_ change the meaning, and you present an argument that other users are likely to like the new meaning more than the old!","createdAt":"2022-11-25T18:59:26Z","includesCreatedEdit":true,"isMinimized":false,"minimizedReason":"","reactionGroups":[{"content":"THUMBS_UP","users":{"totalCount":1}}],"url":"https://github.com/dandavison/delta/issues/247#issuecomment-1327792937","viewerDidAuthor":true},{"id":"IC_kwDOC4j8g85q6eGb","author":{"login":"danwilliams"},"authorAssociation":"NONE","body":"I stumbled upon this problem today 🙂 I notice this issue is quite old - has anyone done any work on it? (@dandavison @bew) If not, I'll see if I can find some time to fix it.","createdAt":"2023-11-05T11:40:25Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/247#issuecomment-1793712539","viewerDidAuthor":false},{"id":"IC_kwDOC4j8g85q6hOB","author":{"login":"bew"},"authorAssociation":"NONE","body":"@dandavison go for it, I got caught up with other configs and never went back to it (although I was thinking about it yesterday for some reason 🤷♂️)","createdAt":"2023-11-05T12:36:44Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/247#issuecomment-1793725313","viewerDidAuthor":false},{"id":"IC_kwDOC4j8g85q6rxX","author":{"login":"dandavison"},"authorAssociation":"OWNER","body":"@danwilliams yes go for it, I haven't been able to get to it. Could be helpful to post a design proposal (i.e. any modified meanings of existing options plus any new options) before doing too much implementation. Bear in mind that it needs to all make sense with and without side-by-side mode active, and that the configuration options are already quite complex.","createdAt":"2023-11-05T15:28:31Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/247#issuecomment-1793768535","viewerDidAuthor":true},{"id":"IC_kwDOC4j8g85q6tO9","author":{"login":"danwilliams"},"authorAssociation":"NONE","body":"Okay, cool 👍 ","createdAt":"2023-11-05T15:53:12Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/247#issuecomment-1793774525","viewerDidAuthor":false},{"id":"IC_kwDOC4j8g85q6vnM","author":{"login":"danwilliams"},"authorAssociation":"NONE","body":"@dandavison @bew it turned out to be extremely simple - once I'd identified how the code worked, which only took a few minutes due to it being very well structured, the change was simple and obvious.\r\n\r\n@dandavison the tests are a little odd - they work but the feedback does not make it overly clear exactly which bit is failing. So that took longer to grok than the code fix 😄 \r\n\r\nI have added some screenshots to the PR - it seems much better now and behaves as I would expect. However, please beware that I've only tested the things I am aware of that are relevant and affected by this change. In particular I don't think any documentation updates are necessary, as I see this as a bugfix more than anything, but if you disagree then please direct me to whichever area of documentation you feel might need to have something written about this 🙂 ","createdAt":"2023-11-05T16:32:35Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/247#issuecomment-1793784268","viewerDidAuthor":false},{"id":"IC_kwDOC4j8g85rTsPp","author":{"login":"danwilliams"},"authorAssociation":"NONE","body":"@kevinhwang91 @bew I'm curious if my PR fixes the behaviour in your opinions? 🙂 ","createdAt":"2023-11-07T22:49:39Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/247#issuecomment-1800324073","viewerDidAuthor":false}],"number":247,"title":"🚀 Improve line number to make UI more like github"},{"body":"Adding a separate issue for the topic originally mentioned at #245:\r\n\r\nHere's the delta output (notice the within-line highlights of removed/added text):\r\n\r\n\r\n\r\nAnd here's what diff-so-fancy/diff-highlight shows (not the best possible result, but a better default):\r\n\r\n\r\n\r\nFinally, here's delta with `--word-diff-regex = .`, which is the most accurate highlighting:\r\n\r\n<img src=\"https://user-images.githubusercontent.com/52205/87235044-8b299600-c3a5-11ea-8786-77c6ab7ad1de.png\" width=\"300\"/>\r\n\r\nI'd expect delta to provide better highlighting by default — not necessarily the best possible result shown above; doing the same as diff-highlight would have been satisfactory.","comments":[{"id":"MDEyOklzc3VlQ29tbWVudDY1NzE0ODQ4Mg==","author":{"login":"waldyrious"},"authorAssociation":"CONTRIBUTOR","body":"Responding to @dandavison's comment in #245:\r\n\r\n> Do you think `diff-highlight` and `diff-so-fancy` in delta should default to using the original, simpler, diff highlight algorithm? On the one hand there is something appealing in being able to say that `delta --diff-highlight` aims for a pixel-for-pixel emulation, and OTOH I do find that the dynamic programming algorithm often gives more helpful results.\r\n\r\nI would prefer the diff parsing algorithm to be kept orthogonal to the display style. `diff-highlight`'s algorithm won't be better than `delta`'s all the time (or, I imagine, most of the time), so it would be a disservice to users to default to a worse (on average) algorithm only because they prefer a given visual style.","createdAt":"2020-07-11T23:44:47Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/246#issuecomment-657148482","viewerDidAuthor":false},{"id":"MDEyOklzc3VlQ29tbWVudDY1NzIzMDgwOQ==","author":{"login":"waldyrious"},"authorAssociation":"CONTRIBUTOR","body":"I just came across a similar issue, where diff-highlight's algorithm produces a better output than delta's:\r\n\r\ndelta:\r\n\r\n\r\ndiff-highlight:\r\n\r\n\r\nThere is indeed, in _semantic_ terms, no shared content between the two larger hunks, so diff-highlight is \"right\"\\* to not highlight any content in them; but to be fair, markup characters and whitespace _are_ shared between the hunks, by the very nature of HTML. Maybe delta's algorithm could try to ignore such markup characters (and maybe whitespace) when calculating the similarity between two blocks?\r\n\r\n<sub>\\* Not by its merits, but for the same reason a stopped clock is right twice a day — it just doesn't try to match differently-sized hunks.</sub>","createdAt":"2020-07-12T14:39:39Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/246#issuecomment-657230809","viewerDidAuthor":false}],"number":246,"title":"🐛 Sub-optimal diff highlighting in a simple change"},{"body":"The behaviour should be the same as `-a` for bat: https://github.com/sharkdp/bat#show-non-printable-characters","comments":[{"id":"MDEyOklzc3VlQ29tbWVudDY0NDczNzk4OQ==","author":{"login":"dandavison"},"authorAssociation":"OWNER","body":"Hi @CircleCode, thanks for this. I agree that handling non-printing characters would be a good feature.\r\n\r\nSlightly tangential but I wonder whether it would also be useful to do the `bat -A` transformation on input _prior_ to computing the diff? Here's an example of doing that on two PNG files (I had to copy the output of `bat -A` to `a.txt` first, and you can only do `delta file_1 file_2` on master, not with the released version of delta; in the released version you'd do `diff -u file_1 file_2 | delta` as usual)\r\n\r\n\r\n ","createdAt":"2020-06-16T12:42:48Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/221#issuecomment-644737989","viewerDidAuthor":true},{"id":"MDEyOklzc3VlQ29tbWVudDY0NDg5MDc4Mw==","author":{"login":"CircleCode"},"authorAssociation":"NONE","body":"I think there should be 2 different options, one doing `bat -A` before computing diff, and one after, and it would be user's choice to always use one or the other, or even, if I'm not wrong, to use gitattributes to do per file choice (see https://git-scm.com/docs/gitattributes#_defining_an_external_diff_driver)","createdAt":"2020-06-16T17:00:32Z","includesCreatedEdit":true,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/221#issuecomment-644890783","viewerDidAuthor":false}],"number":221,"title":"🚀 add an option to show non-printable characters"},{"body":"0d593c2de31b57664c43b6d075965ae4025c9228 made decoration styles compose, so that one can do e.g.\r\n\r\n- `--commit-decoration-style='ul ol'` => under-and-over-line decoration\r\n- `--commit-decoration-style='box ul'` => box-with-lower-whisker decoration\r\n\r\nHowever, `box ol` and `box ul ol` were left unimplemented: they currently just yield a `box`.","comments":[],"number":214,"title":"🐛 Support 'box ol' composed decoration"},{"body":"Hi,\r\nI've quickly looked at the project and it looks awesome. Also thanks for supporting Mercurial. :)\r\n\r\nThe project uses `String` for handling hunks, which forces the data to be UTF8, or since https://github.com/dandavison/delta/commit/9d1aafee2465b3b89de09ae72e1b8b8fbda4a981, display garbage.\r\n\r\nSome projects historically did not start with UTF8, either because they predated the standard or for other reasons, which makes it impossible for them to use VCS or VCS-related software that does not support handling arbitrary bytes without completely losing their (often decades-long) history.\r\n\r\nHave you considered it? Is it a wontfix? \r\n\r\nThanks ","comments":[{"id":"MDEyOklzc3VlQ29tbWVudDYyNzk1OTA0MA==","author":{"login":"dandavison"},"authorAssociation":"OWNER","body":"Hi @Alphare thanks for getting in touch. Absolutely, let's fix this. I hasdn't thought about this previously but based on your message I'm thinking that we need to support multiple different encodings, in different files/commits within a repo. How does the following sound? cc @fgsch\r\n\r\n- We add a new command line option `--encoding`. For example, a user could pass `--encoding=utf-8,another-encoding`. (I.e. singular name \"encoding\", but supporting a comma-separated list; I am not sure if the command line app libraries in rust support passing an argument multiple times and assembling a list of values).\r\n- Delta will try each encoding in turn, until one succeeds.\r\n- If none succeed, then delta will do a lossy decoding, using the first encoding in the supplied list, producing output that will look like `Hello �World` (or just a lot of `�`).\r\n- The default value of `--encoding` will be `utf-8`.\r\n\r\nRecently opened issues #187 and #150 led me to put in the quick fix 9d1aafee2465b3b89de09ae72e1b8b8fbda4a981 to avoid crashing in the face of invalid utf-8, but I was about to modify that in any case, so I think this work fits in. I also think we can do this without impacting performance on the common case (actually, it [might](https://github.com/whitfin/bytelines) improve it).\r\n","createdAt":"2020-05-13T12:46:31Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[{"content":"THUMBS_UP","users":{"totalCount":1}}],"url":"https://github.com/dandavison/delta/issues/188#issuecomment-627959040","viewerDidAuthor":true},{"id":"MDEyOklzc3VlQ29tbWVudDYyNzk3MDk5MA==","author":{"login":"fgsch"},"authorAssociation":"NONE","body":"I'd like to add that this is not necessarily historical. Utf-8 (or any encoding really) makes sense for text, but there are cases where you want to have arbitrary bytes. \r\n\r\nAdding something like `--encoding` makes sense to me. \r\nWould the retry be at line level or entire output?","createdAt":"2020-05-13T13:06:35Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/188#issuecomment-627970990","viewerDidAuthor":false},{"id":"MDEyOklzc3VlQ29tbWVudDYyNzk4NDAwMw==","author":{"login":"dandavison"},"authorAssociation":"OWNER","body":"The retry would be at line level (delta only reads a limited number of lines into memory at a time -- basically one diff hunk).\r\n\r\nI haven't looked into this properly yet: for entirely non-textual files, I was thinking that git (and mercurial?) would often output text like `binary files a/mybinary b/mybinary differ`, in which case there will be no issue (and there's a unit test that delta handles that output from git appropriately).","createdAt":"2020-05-13T13:25:08Z","includesCreatedEdit":true,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/188#issuecomment-627984003","viewerDidAuthor":true},{"id":"MDEyOklzc3VlQ29tbWVudDYyNzk4NDkwOQ==","author":{"login":"dandavison"},"authorAssociation":"OWNER","body":"@Alphare how does Mercurial handle this? Does it look at the first few bytes of a file to judge whether it appears to be text or not?","createdAt":"2020-05-13T13:26:43Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/188#issuecomment-627984909","viewerDidAuthor":true},{"id":"MDEyOklzc3VlQ29tbWVudDYyODAzNTg1NA==","author":{"login":"Alphare"},"authorAssociation":"NONE","body":"> @Alphare how does Mercurial handle this? Does it look at the first few bytes of a file to judge whether it appears to be text or not?\r\n\r\nThe encoding strategy is documented here and will do a better job than I can: https://www.mercurial-scm.org/wiki/EncodingStrategy\r\n\r\nIf anywhere in the code Mercurial *does* need to assess if any hunk is binary, in LFS context there is an override, otherwise it looks if it's not empty and has a null byte in it. \r\n\r\nI unfortunately don't have much time to think about how to solve the issue today, but here's my question: do we have to care about the encoding at all? This is a very candid question, as in \"is there an encoding-agnostic way of doing so\"?\r\n\r\nFor example: I've been working a lot on the Rust version of `hg status` and I've defined an `HgPath` struct to represent any tracked filename/path, and it's just arbitrary bytes until we *have* to interact with the filesystem, in which case we either get an error - because it's invalid for the FS/OS pair - or we get an `OsStr`/`Path` back.","createdAt":"2020-05-13T14:40:43Z","includesCreatedEdit":true,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/188#issuecomment-628035854","viewerDidAuthor":false},{"id":"MDEyOklzc3VlQ29tbWVudDYyODA4NzA0OQ==","author":{"login":"dandavison"},"authorAssociation":"OWNER","body":"> here's my question: do we have to care about the encoding at all? \r\n> I've been working a lot on the Rust version of hg status and I've defined an HgPath struct to represent any tracked filename/path, and it's just arbitrary bytes until we have to interact with the filesystem,\r\n\r\nI think that we will need to care about the encoding. The operations that delta needs to do on its input lines include parsing, running string alignment algorithms over them to infer within-line edits, inserting ANSI escape sequences. So although [bytelines](https://github.com/whitfin/bytelines) allows us to iterate over lines of stdin yielding each line as a pointer to the relevant raw bytes of stdin, it's going to be impossible to implement the rest of Delta without being able to to construct heap-allocated `std::string::String`s. For example, I don't think that [ansi_term](https://docs.rs/ansi_term/0.6.3/ansi_term/index.html) can be used with undecoded bytes (`&[u8]`). Rust's `String` wraps valid utf-8 bytes, therefore we must construct valid utf-8 bytes. Therefore, we must deal with the original encoding, because we need to know what it is in order to translate the incoming bytes to utf-8. ","createdAt":"2020-05-13T16:01:23Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/188#issuecomment-628087049","viewerDidAuthor":true},{"id":"MDEyOklzc3VlQ29tbWVudDYyODExMDY0OA==","author":{"login":"Alphare"},"authorAssociation":"NONE","body":"> For example, I don't think that [ansi_term](https://docs.rs/ansi_term/0.6.3/ansi_term/index.html) can be used with undecoded bytes (`&[u8]`). \r\n\r\nIt looks like it does support bytes: https://github.com/ogham/rust-ansi-term#byte-strings. \r\n\r\nI don't see how the tasks you've listed could not be done on arbitrary bytes, but maybe I don't understand the specific need for `String` vs `Vec<u8>` aside from the obviously better ergonomics. ","createdAt":"2020-05-13T16:43:13Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/188#issuecomment-628110648","viewerDidAuthor":false},{"id":"MDEyOklzc3VlQ29tbWVudDYyODEyOTAwMQ==","author":{"login":"dandavison"},"authorAssociation":"OWNER","body":"> It looks like it does support bytes:\r\n\r\nAh, thanks!\r\n\r\nWell, OK but [_apart_ from](https://www.youtube.com/watch?v=Y7tvauOJMHo) ansi_term :) ... what about syntect? It looks to me like syntect requires the input to be `&str`: https://github.com/trishume/syntect/blob/master/src/highlighting/highlighter.rs#L65 \r\n\r\nI'm new to Rust with this project, and not expert. Honestly, I think that I'd been thinking that, given the prominence of `std::string::String` in Rust documentation/code, it would be nuts to try to write the entire application eschewing it.","createdAt":"2020-05-13T17:15:44Z","includesCreatedEdit":true,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/188#issuecomment-628129001","viewerDidAuthor":true},{"id":"MDEyOklzc3VlQ29tbWVudDYzMDUwMDI4NQ==","author":{"login":"dandavison"},"authorAssociation":"OWNER","body":"@Alphare I've made some of the necessary changes to do this in #191 which provides lossy utf-8 decoding. \r\n\r\n> Some projects historically did not start with UTF8, either because they predated the standard or for other reasons,\r\n\r\nDo you happen to have some examples of repos to hand which contain a mix of non-utf-8 encodings which I can test the fix for this issue against?","createdAt":"2020-05-19T00:13:30Z","includesCreatedEdit":true,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/188#issuecomment-630500285","viewerDidAuthor":true},{"id":"MDEyOklzc3VlQ29tbWVudDYzNjAxNTE5Ng==","author":{"login":"dandavison"},"authorAssociation":"OWNER","body":"@Alphare would you be able to point me to some example repos that have problematic encodings for me to test against?","createdAt":"2020-05-29T14:48:54Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/188#issuecomment-636015196","viewerDidAuthor":true},{"id":"MDEyOklzc3VlQ29tbWVudDYzNzQyMTIzNg==","author":{"login":"Alphare"},"authorAssociation":"NONE","body":"@dandavison sorry for the delay, I should have answered you when I first got the message.\r\n\r\nI do not personally have any repos that are anything other than UTF8, but I'll ask around.\r\nIn the meantime, it's very easy to create a repo that would need both encodings in a diff output:\r\n\r\n```shell\r\n$ hg init test-repo\r\n$ cd test-repo\r\n$ echo -n \"Raphaël Gomès\" > foo # assuming UTF8 default\r\n$ hg ci -Am \"UTF8\"\r\n$ iconv -f UTF-8 -t WINDOWS-1252 foo > foo2\r\n$ mv foo2 foo\r\n$ hg ci -Am \"CP1252\"\r\n```\r\n\r\nRunning `HGPLAIN= hg export` here will show the correct bytes in each \"half\" of the diff if your terminal encoding is set to UTF8 or CP1252, no bytes are lost by Mercurial. Even without changing encodings in a commit, simply using another encoding like JIS would be unusable if not for the diff algorithm being encoding-agnostic.\r\n\r\nI hope that helps, thanks for pinging me. :)","createdAt":"2020-06-02T09:37:23Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/188#issuecomment-637421236","viewerDidAuthor":false},{"id":"MDEyOklzc3VlQ29tbWVudDYzNzQyMzcwMQ==","author":{"login":"Alphare"},"authorAssociation":"NONE","body":"Early revisions of the [nginx repo](http://hg.nginx.org/nginx/) have non-UTF8 encodings. `hg up 2000` shows `docs/xml/nginx/changes.xml` using ISO-8859.","createdAt":"2020-06-02T09:42:21Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/188#issuecomment-637423701","viewerDidAuthor":false},{"id":"MDEyOklzc3VlQ29tbWVudDYzNzUyNjkzMQ==","author":{"login":"dandavison"},"authorAssociation":"OWNER","body":"@Alphare that's very useful, thanks a lot.","createdAt":"2020-06-02T13:01:38Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[{"content":"THUMBS_UP","users":{"totalCount":1}}],"url":"https://github.com/dandavison/delta/issues/188#issuecomment-637526931","viewerDidAuthor":true},{"id":"IC_kwDOC4j8g86Pcq3Z","author":{"login":"htharoldht"},"authorAssociation":"NONE","body":"Hello, is there any new progress?\r\nI have a repository and cannot modify the file encoding. Some files are in gb2312 and some are in utf8. When I use git-delta to diff, the garbled characters are displayed. Although it works, it is really not beautiful.\r\nI tried `diffFilter = delta --color-only | iconv -f GB2312 -t UTF-8//TRANSLIT` or `diffFilter = iconv -f GB2312 -t UTF-8//TRANSLIT | delta --color-only`, but it didn't work","createdAt":"2024-10-11T06:43:04Z","includesCreatedEdit":true,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/188#issuecomment-2406657497","viewerDidAuthor":false}],"number":188,"title":"Add support for arbitrary encoding 🚀"},{"body":"I have a working draft ([branch](https://github.com/da-x/delta/tree/plain-coloring)) for plain-mode extensions which adds coloring for further aspects of the diff. Hopefully I did not butcher the parsing code too much. Hoping to open a discussion about this to see that I'm taking the right direction.\r\n\r\n\r\n\r\nThis makes it look more like my old [fancydiff](https://github.com/da-x/fancydiff), which I want to retire. I added 4 options:\r\n\r\n```\r\n --commit-meta-header-background <commit-meta-header-bg>\r\n Optional background color for the first line of the commit header\r\n --commit-meta-other-background <commit-meta-other-bg>\r\n Optional background color for the other lines of the commit header. Otherwise, `commit-meta-header-bg` is\r\n --file-background <file-bg>\r\n Optional background color for the file section of git output\r\n --hunk-background <hunk-bg>\r\n Optional background color for the hunk-marker section of git output\r\n```","comments":[{"id":"MDEyOklzc3VlQ29tbWVudDYyMjM1NDk2Ng==","author":{"login":"0xC0FFEE"},"authorAssociation":"NONE","body":"Hi @da-x, I really like the idea of coloring the commit messages! However I'm not totally sure, whether this is really `delta`'s job?\r\n\r\n`git`'s support for pretty formats[1] is quite rich. It is even possible to print arbitrary ANSI escape sequences via `%x`.\r\n\r\nHere is a first quick attempt to match your example (I guess extending the background color to the end of the line should also somehow work):\r\n`git log --format=format:\"%C(white #880088)commit %H%n%C(white #440044)Author: %an <%ae>%n%C(white #440044)Date: %ad%n%n%s%n%n%b%n\" -p`\r\n\r\n\r\n\r\nIMHO it will be quite hard (aka. impossible) for `delta` to parse arbitrarily complex git pretty formats. So IMO `delta` should just print the existing lines unmodified (a first step in this direction has been done in #163).\r\n\r\n`git` lacks support for custom formatting for hunks. So at least technically I do not see a problem when `delta` tries to apply custom formatting to hunks, as the hunk format is fixed.\r\n\r\n[1] https://git-scm.com/docs/pretty-formats","createdAt":"2020-05-01T11:37:57Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/168#issuecomment-622354966","viewerDidAuthor":false},{"id":"MDEyOklzc3VlQ29tbWVudDYyMjM2Mzg2Mg==","author":{"login":"da-x"},"authorAssociation":"CONTRIBUTOR","body":"@0xC0FFEE, yeah I agree that if Git was a bit more featureful we wouldn't need to parse and recolor its output. Your suggestion looks cool, but I still prefer the indented commit body message (no alternative to `%b` I guess), and whole line background color, so I'll continue to use `delta` for now. It's easier than contributing features to Git mainline.\r\n\r\nBTW, in my draft changes I modified the parsing a slight bit - detecting where the commit header ends upon detecting a blank line. As it stands `delta` is not trying to do much parsing to the commit message (unlike in `fancydiff` where I've also highlighted `Signed-off-by`). Also, this led me to think that that in my draft changes, the original ANSI should not be stripped if commit message recoloring is not enabled, so that it can be future compatible to the possibility of newer Git client version with more coloring capabilities.","createdAt":"2020-05-01T12:13:48Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/168#issuecomment-622363862","viewerDidAuthor":false},{"id":"MDEyOklzc3VlQ29tbWVudDYyMjQwMjQ0MA==","author":{"login":"dandavison"},"authorAssociation":"OWNER","body":"@da-x great, I'm happy to have some other collaborators on the code! Modulo the current discussion, I have one initial question about the code changes: is there some refactoring of the state machine parser that you see that could be done first, to make the introduction of the new features as clean as possible?\r\n\r\n@da-x @0xC0FFEE Do you think there's a good (and not too complex) solution where we can have both? Delta's purpose is to give people a lot of possibilities in designing their own git output styling, and I think it's OK to implement some things that overlap with what advanced users can achieve with git formatting operations. Defaults is another question of course.\r\n\r\nSo doing both would be something like\r\n\r\n- If Delta cannot parse something, then it should emit the raw line, which might include ANSI escapes.\r\n\r\n- But if it can parse it then Delta may have an option allowing that element to be styled, even if that styling is something that could have been achieved with native git functionality.\r\n\r\nIf I'm understanding correctly, the concern is how we handle the conflict between people who are using git's native formatting and want Delta to pass on their input unchanged, vs people who are using default git formatting and will be happy for Delta to apply its own colors (stripping any ANSI sequences from the input in the process). But is that not basically resolved by the assumption\r\n\r\n> If you want ANSI sequences to be passed through unchanged for `<element>` then you will not use `--<element>-fg-color` or `--<element>-bg-color` \r\n\r\n?\r\n\r\n> I still prefer the indented commit body message (no alternative to %b I guess), and whole line background color, so I'll continue to use delta for now. \r\n\r\nWell I hope so, you'd lose a lot of features otherwise! To make the discussion completely clear for all readers though, I believe @0xC0FFEE was suggesting that you use delta, but that the coloring is achieved by (a) a git log format, and (b) delta being good about passing on ANSI sequences unchanged wherever possible.","createdAt":"2020-05-01T14:07:20Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/168#issuecomment-622402440","viewerDidAuthor":true},{"id":"MDEyOklzc3VlQ29tbWVudDYyMjQyMTIxNA==","author":{"login":"da-x"},"authorAssociation":"CONTRIBUTOR","body":"@dandavison while editing the code I had to copy some logic pertaining to the whole-line background handing in diff hunks. Apart from that, I saw no need for any per-line state machine change besides commit meta-data header end detection. As of today, I started to use `delta` :).\r\n\r\nI agree that we should let Git's color styling to pass through as long as the user did not specify otherwise. However my draft is not supporting it, as it strips colors in `draw::write_colored` by default... Also to complicate things, as a side effect it strips colors from Git log's ref decoration\r\n\r\n\r\n\r\n\r\nOnly Git knows what is the type of the ref (e.g. tag or branch), and it is colored accordingly, so we must preserve these colors. Depending on what the user specified, we may need to do a composite of delta's `commit-color` around Git's own provided decorated ref colors (controlled via `color.decorate.<slot>`), meaning we need to parse Git's output instead of just stripping, and carefully combine the colors onto the commit line from both programs.","createdAt":"2020-05-01T14:56:43Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/168#issuecomment-622421214","viewerDidAuthor":false},{"id":"MDEyOklzc3VlQ29tbWVudDYyMjU0MDI5NA==","author":{"login":"0xC0FFEE"},"authorAssociation":"NONE","body":"> @da-x @0xC0FFEE Do you think there's a good (and not too complex) solution where we can have both?\r\n\r\nI think the easiest and least complicated solution would be to let the user specify the desired functionality (e.g. via a command line switch). So basically `delta` would have two distinct modes:\r\n\r\n1. Work with the standard `git` log format\r\n2. Just pass everything through\r\n\r\nMaybe (and just maybe) this decision could be made automatically based on the parsed text. However parsing things, were the input can be arbitrary text, might be (too) complicated.\r\n\r\n> If I'm understanding correctly, the concern is how we handle the conflict [...]\r\n\r\nI think supporting both use cases is desirable. However as we do not have any context, except for the text-based diff itself, it will be quite hard to support both use cases automatically IMHO. That is why I thought maybe we can get away with only implementing one of the use cases in `delta` and do the rest via `git` pretty format. \r\n\r\n@da-x\r\n> Your suggestion looks cool, but I still prefer the indented commit body message (no alternative to %b I guess), and whole line background color, so I'll continue to use delta for now.\r\n\r\nIndentation can be achieved via the `%w` modifier:\r\n\r\n```\r\ngit log --format=format:\"%C(white #880088)commit %H%n%C(white #440044)Author: %an <%ae>%n%C(white #440044)Date: %ad%n%n%w(,4,4)%s%n%n%w(,4,4)%b%n\" -p\r\n```\r\n\r\nAnd as I've written before, arbitrary ANSI escape sequences can be printed via `%x`. So coloring the whole line might be possible with standard git after all (haven't had a look at this yet).","createdAt":"2020-05-01T19:57:16Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/168#issuecomment-622540294","viewerDidAuthor":false},{"id":"MDEyOklzc3VlQ29tbWVudDYzNTczMTg5MQ==","author":{"login":"dandavison"},"authorAssociation":"OWNER","body":"@da-x I haven't forgotten about the additions in your branch. I'd like to incorporate them to make more elements stylable. I did however completely change the master branch as you may have noticed. I hope you'll approve of the more consistent style CLI and internal data structures, but sorry to make your changes need recasting! I'll be happy to help out; one task is decide on what new styles we want to add I think. And I also need to circle back and think about the issue we discussed in this ticket of when delta does native color pass-through.","createdAt":"2020-05-29T03:11:56Z","includesCreatedEdit":true,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/168#issuecomment-635731891","viewerDidAuthor":true},{"id":"MDEyOklzc3VlQ29tbWVudDYzNTg4OTA3OQ==","author":{"login":"da-x"},"authorAssociation":"CONTRIBUTOR","body":"Thanks for working on this. The changes look cool. We'd still need to see whether `--color-only` should mean overriding colors set by Git, like my branch does (I tried to use `--color-only` with `--file-style` in `master` and it still does not apply the colors).","createdAt":"2020-05-29T10:03:46Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/168#issuecomment-635889079","viewerDidAuthor":false},{"id":"MDEyOklzc3VlQ29tbWVudDYzNjUzOTg0OA==","author":{"login":"dandavison"},"authorAssociation":"OWNER","body":"@da-x: the `master` branch is getting closer to supporting what you want here. Would you be interested in adding the remaining missing pieces from your branch to master? (Basically: background-color right-fill and new option `--commit-meta-style`)\r\n\r\n@da-x, @0xC0FFEE: all stylable elements now support `--foo-style=raw` meaning to pass on the input from git unchanged, with original ANSI colors. (That can be combined with a decoration.)\r\n\r\nIf `raw` is not in effect, then we strip out git's colors.\r\n\r\nHere's an attempt at recreating the screenshot in this ticket using the new features in delta `master`:\r\n\r\n```\r\ngit -c color.diff.meta='white #333333' \\\r\n -c core.pager=\"delta --commit-style 'bold white \"#880088\"'\r\n --hunk-header-style '\"#aaaaaa\" blue'\r\n --hunk-header-decoration-style none\r\n --file-style raw\r\n --file-decoration-style none\" \\\r\n show 5b2620981\r\n```\r\n\r\n<table><tr><td><img width=700px src=\"https://user-images.githubusercontent.com/52205/83363717-8535a380-a369-11ea-971f-92a14cc0523e.png\" alt=\"image\" /></td></tr></table>\r\n\r\nThe main things we're missing are:\r\n\r\n1. Background colors in commit/file/hunk-header don't fill right currently (we don't have your function `paint_whole_line`)\r\n2. Need to add a new stylable element for non-hash commit lines (`Author:`, `Date:`, `Merge:`). I suggest the name `--commit-meta-style` (`--commit-style` currently refers to the first line with the hash).\r\n\r\nComments:\r\n\r\n- Other stylable elements in delta have a `--foo-decoration-style` but it's not clear that `--commit-meta-decoration-style` would make sense?\r\n- I think I'm on board with right-filling background colors by default. It might be nice for users to be able to control that -- perhaps there could be a special style attribute with a name like `nofill`? -- but honestly the main thing is just that we don't release any command line options that we subsequently want to retract or change the meaning of.\r\n\r\n\r\n@da-x: sorry if I haven't understood yet what you were saying about `--color-only`. Hopefully this makes it clearer what my current thinking is and we can continue the discussion.\r\n","createdAt":"2020-05-31T22:29:06Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/168#issuecomment-636539848","viewerDidAuthor":true},{"id":"MDEyOklzc3VlQ29tbWVudDYzNzk3MTgzNA==","author":{"login":"da-x"},"authorAssociation":"CONTRIBUTOR","body":"Yes, I meant that with `--color-only`, it's really a shortcut to passing `raw` on all elements, so that non-ANSI output of Git before delta matches the non-ANSI output of delta. I'll try to rebase my branch `master` to see how we narrowed the difference. For reference, this is how I currently run my branch:\r\n\r\n```\r\nexec delta \\\r\n --color-only \\\r\n --24-bit-color always \\\r\n --highlight-removed \\\r\n --file-color '#cccccc' \\\r\n --file-background '#222222' \\\r\n --commit-color '#ffffff' \\\r\n --commit-meta-header-background '#880088' \\\r\n --commit-meta-other-background '#440044' \\\r\n --hunk-color '#999999' \\\r\n --hunk-background '#000088' \\\r\n \"$@\"\r\n```","createdAt":"2020-06-03T05:56:16Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/168#issuecomment-637971834","viewerDidAuthor":false}],"number":168,"title":"🚀Extended plain mode coloring options"},{"body":"Does delta support `diff --word-diff`?","comments":[{"id":"MDEyOklzc3VlQ29tbWVudDYyNDAwNzA2NQ==","author":{"login":"AvnerCohen"},"authorAssociation":"NONE","body":"In a quick check - no. Would be awesome to add though.","createdAt":"2020-05-05T11:47:51Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/152#issuecomment-624007065","viewerDidAuthor":false},{"id":"MDEyOklzc3VlQ29tbWVudDYyNDA1MDg5MQ==","author":{"login":"dandavison"},"authorAssociation":"OWNER","body":"Hi @ryanberckmans (and @AvnerCohen), thanks for this! Could you expand on exactly what you'd like to see here?\r\n\r\nIn a sense Delta does provide something like `--word-diff`, in that it infers and highlights within-line edits (using a Levenshtein-type DP algorithm). However, I'm not saying that there wouldn't be benefit in working with git's native output, and also extending and improving the algorithms implemented by Delta (see #140).","createdAt":"2020-05-05T13:20:31Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/152#issuecomment-624050891","viewerDidAuthor":true},{"id":"MDEyOklzc3VlQ29tbWVudDYyNDA1MzEzNQ==","author":{"login":"dandavison"},"authorAssociation":"OWNER","body":"Are you thinking of replacing git's default (and ugly) `{+` and `[-` markers with background colors? (Presumably in this mode, Delta's native within-line edit inference would be disabled).\r\n\r\n```\r\n_SUPPORTED_PYTHONS = [-['3.7',-]{+['3.8', '3.7',+} '3.6', '3.5', '3.4',[-'3.3',-] '2.7']\r\n```","createdAt":"2020-05-05T13:24:52Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[{"content":"THUMBS_UP","users":{"totalCount":2}}],"url":"https://github.com/dandavison/delta/issues/152#issuecomment-624053135","viewerDidAuthor":true},{"id":"MDEyOklzc3VlQ29tbWVudDYyNDE0NTQ1MQ==","author":{"login":"AvnerCohen"},"authorAssociation":"NONE","body":"How about something like:\r\n\r\n_SUPPORTED_PYTHONS = [~['3.7',]~{**['3.8', '3.7',**} '3.6', '3.5', '3.4',[-'3.3',-] '2.7']\r\n\r\nWith relevant color scheme applied as well ?\r\n\r\nWhat would be nice is if the color is applied not across all lin, but just on the +- parts.\r\n","createdAt":"2020-05-05T16:04:32Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[{"content":"THUMBS_UP","users":{"totalCount":1}}],"url":"https://github.com/dandavison/delta/issues/152#issuecomment-624145451","viewerDidAuthor":false},{"id":"MDEyOklzc3VlQ29tbWVudDYyNDIxNDAzMg==","author":{"login":"dandavison"},"authorAssociation":"OWNER","body":"@AvnerCohen could you comment on how you see the role of delta's default within-line edit highlighting versus `--word-diff`? For example, when would you use one versus the other? Do you have examples of cases where Delta's within-line edit inference is not doing a good job? (Delta's within-line edits (like GitHub, GitLab) are displayed on two different lines, unlike `--word-diff` which combines the added and removed on a single line.) Note that you may want to play with `--max-line-distance` to adjust Delta's within-line edit inference algorithm.\r\n\r\nAgain, I'm not suggesting we shouldn't support Git's `--word-diff` output, I just want to understand how people view those two different, but somewhat similar, possibilities.","createdAt":"2020-05-05T18:00:38Z","includesCreatedEdit":true,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/152#issuecomment-624214032","viewerDidAuthor":true},{"id":"MDEyOklzc3VlQ29tbWVudDYyNDIyODE0Ng==","author":{"login":"AvnerCohen"},"authorAssociation":"NONE","body":"@dandavison Thanks for the time and effort.\r\nFirst, I have checked back and seems like I got a bit confused, I actually meant \"--color-words\" and not \"word-diff\". \r\nThat being said, I have done couple of tests, and while I remember specific cases where `color-words` was pretty helpful, I couldn't really find a specific case where this would be better than the correct default you suggest, with the specific part of the word highlighted, for me, it feels like it's just a matter of getting used to it.\r\n","createdAt":"2020-05-05T18:27:09Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/152#issuecomment-624228146","viewerDidAuthor":false},{"id":"MDEyOklzc3VlQ29tbWVudDYyNDc3MTg1OQ==","author":{"login":"ryanberckmans"},"authorAssociation":"NONE","body":"@dandavison to answer your question on what I'd like to see here-\r\n\r\nSimply put, right now delta doesn't seem to support `--word-diff`. The output has no or incorrect highlighting.\r\n\r\nHere's an example\r\n\r\n\r\nIn this screenshot, I'd expect the removals and additions to be styled according to the configured delta theme. Right now they are unstyled.\r\n\r\nThanks!","createdAt":"2020-05-06T17:05:05Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/152#issuecomment-624771859","viewerDidAuthor":false},{"id":"MDEyOklzc3VlQ29tbWVudDYyNDc4OTAxOA==","author":{"login":"dandavison"},"authorAssociation":"OWNER","body":"Thanks @ryanberckmans. I agree that that would make much more sense and that, whatever features delta offers, people will still send it `--word-diff` output and it would be good for it to display it nicely. \r\n\r\nOut of interest, do you have any comments on when you use `--word-diff` versus relying on delta's within-line edit highlighting (below)?\r\n\r\n```\r\ngit diff | delta --max-line-distance=0.6\r\n```\r\n\r\n<table><tr><td><img width=300px src=\"https://user-images.githubusercontent.com/52205/81209493-9bd12080-8f9e-11ea-818f-ac0c9099f810.png\" alt=\"image\" /></td></tr></table>\r\n","createdAt":"2020-05-06T17:37:36Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/152#issuecomment-624789018","viewerDidAuthor":true},{"id":"MDEyOklzc3VlQ29tbWVudDYyNDkwNDgyNw==","author":{"login":"ryanberckmans"},"authorAssociation":"NONE","body":"@dandavison delta's within-line edit highlighting displays on two lines, whereas `--word-diff` shows \"just the words that changed\" on a single diff line. For example,\r\n\r\n\r\n^ delta, uses two lines\r\n\r\n\r\n^ `--word-diff`, uses one line","createdAt":"2020-05-06T21:38:23Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[{"content":"THUMBS_UP","users":{"totalCount":2}}],"url":"https://github.com/dandavison/delta/issues/152#issuecomment-624904827","viewerDidAuthor":false},{"id":"MDEyOklzc3VlQ29tbWVudDYyNTU1MjE4MQ==","author":{"login":"lilyball"},"authorAssociation":"NONE","body":"At the very least I'd love to see `--color-words` and `--word-diff` not confuse delta quite so much.","createdAt":"2020-05-07T23:45:54Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[{"content":"THUMBS_UP","users":{"totalCount":2}}],"url":"https://github.com/dandavison/delta/issues/152#issuecomment-625552181","viewerDidAuthor":false},{"id":"MDEyOklzc3VlQ29tbWVudDg1OTYxNTc0NA==","author":{"login":"pilif-pilif"},"authorAssociation":"NONE","body":"@dandavison I would like to have this feature and help coding it. Could you give me some guidelines where to start? ","createdAt":"2021-06-11T14:19:52Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[{"content":"THUMBS_UP","users":{"totalCount":1}}],"url":"https://github.com/dandavison/delta/issues/152#issuecomment-859615744","viewerDidAuthor":false},{"id":"MDEyOklzc3VlQ29tbWVudDg1OTcyMzE4Ng==","author":{"login":"dandavison"},"authorAssociation":"OWNER","body":"Hi @pilif-pilif, thanks for the offer! Let's start thinking about this then.\r\n\r\nI think that we need to start off with some design thinking before getting to code changes. Basically, what exactly are we aiming for? One question is:\r\n\r\n- Do we give users the option for the lines with `--word-diff` markers in them to be syntax highlighted by delta? Or do we forget about syntax highlighting and just aim to style the output appropriately?\r\n\r\nSyntax highlighting might be quite hard: I think we would have to parse the input to reconstruct the original minus/plus lines of valid syntax in the target language, send those to the syntax highlighter, and then recombine them.\r\n\r\nHonestly, after writing the notes below, I am starting to wonder about a different approach here: maybe we should just emit the `diff --word-diff` output in `raw` mode, so that the colors that git applies come through unchanged?\r\n\r\nWhat are your initial thoughts about how you want this to behave when you are finished with it?\r\n\r\n--------------------------------------------\r\n\r\nHere are some more notes. I'm just writing down my initial thoughts, so I am probably overlooking possibilities.\r\n\r\nHere is some raw output from `git --word-diff`, not using delta:\r\n\r\n<table><tr><td><img width=400px src=\"https://user-images.githubusercontent.com/52205/121722380-61945580-cab3-11eb-8362-a2bf3f9c11e2.png\" alt=\"image\" /></td></tr></table>\r\n\r\nWe see that\r\n\r\n1. Git has added some special markup to the code: ` [-removed-]` and `{+added+}`\r\n2. Git is also emitting ANSI color escape sequences causing these to be displayed as red and green\r\n\r\nNow, here is the same output, but using delta:\r\n\r\n<table><tr><td><img width=400px src=\"https://user-images.githubusercontent.com/52205/121723050-0dd63c00-cab4-11eb-8b94-15fbfb9fa6d9.png\" alt=\"image\" /></td></tr></table>\r\n\r\nWe see that\r\n\r\n1. Delta has removed the red and green from git\r\n2. Delta has syntax-highlighted the code as Rust\r\n\r\nThe `[-` and `{+` markers mean that this is _not_ valid Rust syntax, and so the syntax-highlighting could have gone wrong. But in fact, in this case, it doesn't look too bad. In contrast, here's an example where the syntax-highlighting isn't quite what we'd want:\r\n\r\n<table><tr><td><img width=600px src=\"https://user-images.githubusercontent.com/52205/121721391-35c4a000-cab2-11eb-8e59-a37bc2f34110.png\" alt=\"image\" /></td></tr></table>\r\n","createdAt":"2021-06-11T17:10:01Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/152#issuecomment-859723186","viewerDidAuthor":true},{"id":"MDEyOklzc3VlQ29tbWVudDg2MjE4MDM2Mw==","author":{"login":"pilif-pilif"},"authorAssociation":"NONE","body":"Hi @dandavison, \r\n\r\nsorry for the delay. \r\n\r\nI think that `raw` for only the `[-` and `{+` part is the only real usable solution since it is a squashed diff. As a user I would still want syntax highlighting for the rest so i can better understand/see the Code where the change is happening. \r\n\r\nWhen I use a squashed diff I want to see fast what changed where and in what environment/segment. So `what `would be raw green, `where `- raw red and `environment `delta syntax highlighting. \r\n\r\nso maybe delta can:\r\n1. stop removing the red/green ASCI color when there are `[-` and `{+` markers\r\n2. syntax highlighting treats `[-` and `{+` markers as not valid syntax per default and changes nothing on the provided ASCI color\r\n\r\nwhat do you think? \r\n\r\n\r\n","createdAt":"2021-06-16T08:53:46Z","includesCreatedEdit":true,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/152#issuecomment-862180363","viewerDidAuthor":false},{"id":"MDEyOklzc3VlQ29tbWVudDg2NjUwNTk2Ng==","author":{"login":"dandavison"},"authorAssociation":"OWNER","body":"Hi @pilif-pilif, Two questions\r\n\r\n1. Do you feel that you want syntax highlighting on the line containing `[-` and `{+` itself, or would it be sufficient to have syntax -highlighting on surrounding lines but the line containing the word diff markers in `raw` mode?\r\n\r\n2. Are you envisaging activating the new behavior via a new delta option, or are you hoping that delta will automatically detect the `--word-diff` markers? I'm not sure the latter is possible as (a) it may be valid syntax in some language, and (b) we'd have to parse the code to avoid being triggered by that pattern in strings/comments etc., (c) I don't think we have a nice way to interrogate the parent git process for whether `--word-diff` is in effect (do we?)\r\n\r\n> syntax highlighting treats [- and {+ markers as not valid syntax per default and changes nothing on the provided ASCI color\r\n\r\nThe behavior here will depend on the sublime syntax definition for the language in question so I think all we can say is that the syntax highlighting behavior is undefined/unpredictable: it may change it, and as the example above showed a comment can confuse it.\r\n\r\nSo I'm not sure that I have a better suggestion than adding a new option to delta that causes it to emit the affected lines in raw mode throughout the entire line. Perhaps that new option is not specifically related to `word-diff` but instead an optional regex that delta will test against each line and emit the line as raw if it matches (just thinking aloud, that might be a bad idea :) ).","createdAt":"2021-06-23T04:08:10Z","includesCreatedEdit":true,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/152#issuecomment-866505966","viewerDidAuthor":true},{"id":"MDEyOklzc3VlQ29tbWVudDg2ODUwMjU5Mw==","author":{"login":"pilif-pilif"},"authorAssociation":"NONE","body":"Hi @dandavison,\r\n\r\n1, I think it would be sufficient to have s.-highlighting on the surrounding lines only. That way the `raw` line would be easy to spot.\r\n\r\n2. a new delta option would be ok \r\n\r\nI want to check my logic - please correct me if I am wrong: (I know the \"..\" part is very abstract formulated)\r\n1. git generates ASCII \"colors\"\r\n\r\n2. delta gets \"text\" with ASCII \"colors\"\r\n\r\n3. delta removes the ASCII part - with the new option delta would skip this step. \r\n or\r\n3a. delta removes the ASCII part but before that saves the `raw lines` internally as per the new option \r\n\r\n4. delta sends only the \"text part\" to the syntax highlighter \r\n or\r\n4a. delta sends normally the \"text\" to the syntax highlighter (nothing changes)\r\n\r\n5. syntax highlighter \"puts new ASCII\" but leaves the ASCII from git per line\r\n or\r\n5.a. if 3a then delta restores saved lines - that way syntax highlighting will not break. \r\n\r\n6. Less displays everything. \r\n\r\ncan delta influence directly the syntax highlighter prosses? \r\n","createdAt":"2021-06-25T13:32:15Z","includesCreatedEdit":true,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/152#issuecomment-868502593","viewerDidAuthor":false},{"id":"MDEyOklzc3VlQ29tbWVudDg2ODU2NjU1Ng==","author":{"login":"dandavison"},"authorAssociation":"OWNER","body":"> I want to check my logic - please correct me if I am wrong:\r\n\r\nYes, that's basically accurate. As you say, delta saves a copy of the input line with ANSI color codes stripped and also saves the raw line with ANSI codes intact.\r\n\r\nThen, in the [main state machine parser loop](https://github.com/dandavison/delta/blob/a4f5a4fa686a8db72afbb4f07ae906effbf0fe8e/src/delta.rs#L150) delta calls `handle_hunk_line` when its handling a \"minus\" (removed) or \"plus\" (added) or \"zero\" (unchanged) line.\r\n\r\nI think that you are going to want to write a new version of `handle_hunk_line` specially for this `git-word-diff` feature. Here's the current `handle_hunk_line`: https://github.com/dandavison/delta/blob/a4f5a4fa686a8db72afbb4f07ae906effbf0fe8e/src/delta.rs#L458-L525\r\n\r\nAs you can see it's basically a match statement handling the 3 cases: minus, zero, and plus. These are recognized by a `'-'`, `' '` , and `'+'` character at the start of the line respectively. But with `--word-diff`, that's no longer true: instead of these 3 types of lines, you have two types of lines:\r\n1. Squashed-changed lines. This is a new sort of line that delta doesn't previously know about. They are recognized by having substrings like `[- ... -]` and/or `{+ ... +}` . We want to emit these raw (look at `handle_hunk_line` -- it shows how to emit a line as raw).\r\n2. \"Zero\" (unchanged) lines. But with `git-word-diff` these don't start with a leading `' '` character; they are recognized simply by not being squashed-changed lines. These you want to syntax-highlight (so look at `handle_hunk_line` for that)\r\n\r\nHere's the code location downstream where we see delta not syntax-highlighting line that should be emitted \"raw\" (the fact that is should be emitted \"raw\" is represented by the enum instance containing a non-empty value. In fact the data contained by the enum is the raw line characters.)\r\n\r\nhttps://github.com/dandavison/delta/blob/a4f5a4fa686a8db72afbb4f07ae906effbf0fe8e/src/paint.rs#L456\r\n\r\nSo hopefully that helps a bit. I'm going to add some more thoughts in a separate comment.","createdAt":"2021-06-25T15:07:41Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[{"content":"THUMBS_UP","users":{"totalCount":1}}],"url":"https://github.com/dandavison/delta/issues/152#issuecomment-868566556","viewerDidAuthor":true},{"id":"MDEyOklzc3VlQ29tbWVudDg2ODU3MzQ3Mg==","author":{"login":"dandavison"},"authorAssociation":"OWNER","body":"I think that we should carry on thinking about how we can make this feature as good as possible. Maybe this question helps: what would your absolutely ideal way be for delta to display `--word-diff` output, ignoring any implementation challenges?\r\n\r\nHere are some more higher-level notes:\r\n\r\nDelta already has two ways of displaying diffs: traditional, and side-by-side.\r\n\r\nBut git has a third style: what you are calling \"squashed\" (which seems like a good name). These are produced by `git --word-diff`.\r\n\r\nThe aim of your work could be said to be two different things (which one do you think of it as?):\r\n\r\n1. To handle `git diff --word-diff`\r\n2. To add the \"squashed diff\" style to delta.\r\n\r\nIf the aim is (2), there is a totally different approach we could take: we could forget about `git diff --word-diff` entirely, adding an entry like this to the README:\r\n> delta does not support `git --word-diff` output. If you want this style of diff, use delta's `squashed` option (or whatever it would be called).\r\n\r\nThen you would add to delta the ability to squash the minus and plus lines into a single squashed line. That way the lines would already be syntax highlighted, you wouldn't have to worry about parsing/recognizing any weird git output containing `[-` etc, and you could focus on how to style the removed and added parts of the squashed line.\r\n\r\nIn contrast, what we're talking about above is (1): i.e. having git do the squashing and delta learning how to parse and style that style of output.\r\n\r\nIf we are doing (1) then one thing that worries me is how will you handle someone using `git diff --word-diff=color`? There the git output does not contain the `[-` and `{+` markers; instead removed and added material is indicated by color alone. Here's an example of that:\r\n\r\n<table><tr><td><img width=800px src=\"https://user-images.githubusercontent.com/52205/123444583-f6787200-d5ce-11eb-9852-20ebabb510c0.png\" alt=\"image\" /></td></tr></table>\r\n\r\nand for comparison here's normal `git diff --word-diff`:\r\n\r\n<table><tr><td><img width=800px src=\"https://user-images.githubusercontent.com/52205/123444842-3f302b00-d5cf-11eb-8481-f9be6069a30f.png\" alt=\"image\" /></td></tr></table>\r\n\r\nPerhaps we ignore the `[-` and `{+` markers and do the whole thing by recognizing the red and green colors in the raw git output? (And strip the `[-` and `{+` markers if they are present). And perhaps you could actually syntax highlight everything: red and green tells you what is removed and what is added, so you could reconstruct the original code, and send it to the syntax highlighter, and then reassemble it into a single squashed line, with the desired (background color) styling.\r\n\r\nI think this gets back to my question above: in an ideal world, if we could just ask for any implementation of this and get it with no work, what would we ask for?","createdAt":"2021-06-25T15:15:19Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/152#issuecomment-868573472","viewerDidAuthor":true},{"id":"MDEyOklzc3VlQ29tbWVudDg2ODc0MDQyNQ==","author":{"login":"dandavison"},"authorAssociation":"OWNER","body":"cc @th1000s just in case you have any thoughts: the topic here is git's `--word-diff` output format, which merges sections of added and removed content together on a single line.\r\n\r\nIt seems to me that there are two related objectives:\r\n\r\n(a) Handle `git diff --word-diff` output from git\r\n(b) Design how delta should visually present added and removed content together in a single \"squashed diff\" line\r\n\r\nSo far we have been talking as if the new feature would do (a) and (b) so that a user who enters `git diff --word-diff` or `git diff --word-diff` will get the single-line squashed output from delta, and this would be the only way to get single-line squashed diff output from delta.\r\n\r\nBut another way of approaching this would be to\r\n1. Implement parsing of `git diff --word-diff` output to delta's standard internal data structures (\"minus\" and \"plus\" lines, and \"zero\" lines)\r\n2. Implement conversion of delta's standard internal data structures to a single-line squashed-diff output, somewhat like what git produces with `--word-diff`.\r\n\r\nThis way a delta user would be able to select single-line squashed diff output whether or not they had passed `--word-diff` to git.\r\n","createdAt":"2021-06-25T18:02:30Z","includesCreatedEdit":true,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/152#issuecomment-868740425","viewerDidAuthor":true},{"id":"MDEyOklzc3VlQ29tbWVudDg4MDIzNTI0Ng==","author":{"login":"th1000s"},"authorAssociation":"COLLABORATOR","body":"On a), handling the input: Detecting unified diff vs. word diff format is probably not that difficult, when a hunk contains no `+/-` characters in column zero it (only probably) is word diff output. Or (platform dependent?) look at the arguments of the parent process. Then, parsing `[-removed-]{+added+}` unambiguously can't be guaranteed either, which would leave grabbing the ANSI. That would mean users have to be instructed to use `--word-diff=color` or `--color-words` (or even `=porcelain`). But the colors are not always red/green, e.g. `git -c color.diff.old=yellow -c color.diff.new=cyan diff --color-words`.\r\n\r\nAnd b), unless I misunderstand the issue, should just be the standard red/green background.\r\n\r\n2.) Sounds much better, only the `--word-diff-regex` setting from git would be lost. However, then configuring `delta` as the pager for git would always use the word diff view. There should probably be a quick way to switch that on or off.","createdAt":"2021-07-14T21:54:19Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/152#issuecomment-880235246","viewerDidAuthor":false},{"id":"IC_kwDOC4j8g846ZoP6","author":{"login":"unphased"},"authorAssociation":"NONE","body":"Thanks for linking me here @dandavison and apologies for my delay. As is often the case various things take priority over tinkering with tools but every time I get back to tools I am reminded that it's the foundation for my success.\r\n\r\nI'm grateful for the ground that has already been covered on these topics here, and I would like to contribute from a few directions: \r\n\r\n## My personal experience with an independent diff input format\r\n\r\nI fell down the rabbit hole of enhanced line diffs on the command line ever since I caught a glimpse of intra line highlighting via things like `diff-highlight` (a perl script that comes with git? I've had it in my scripts repo in `$PATH` forever), and github. In mid 2013 I began maintaining a python script that used diff_match_patch as a dependency to obtain character-wise diffs and quickly converted that (because it was slow) to a particular C++ STL implementation of diff-match-patch (\"`dmp`\") which this py script would exec. As such, I never went deep with `git --word-diff`. I think that git diff may well provide many of the same capabilities, I think there is even regex tokenization configuration available. git word diff can be used outside of git using `--no-index`. It is merely happenstance that I didn't choose to use it and reinvented this wheel myself. \r\n\r\nYou may see in the above linked discussions #776 #785 where I have posted screenshots, my tool is fundamentally pretty similar to git `word-diff`. All my python script `sift` does is massage the raw protocol output from C++ `dmp` into suitably-placed ANSI background/reverse codes.\r\n\r\nOne of the many deficiencies that I wanted to address with stuff like diff-highlight (and which I perceived on cursory evaluation of other options, and I might add this applies to github as well is that the results are sort of suboptimal in the sense that no effort is put toward bringing out a lot of the details in intra-line changes. For example please compare the quality of highlighted regions between\r\n\r\n<img width=\"797\" alt=\"image\" src=\"https://user-images.githubusercontent.com/1542910/143542631-34cec73a-0292-46fc-ac66-14627f874328.png\">\r\n\r\n(assume the usual where + line is green and - line is red)\r\n\r\nand\r\n\r\n<img width=\"656\" alt=\"image\" src=\"https://user-images.githubusercontent.com/1542910/143542696-97788014-e91b-4c2b-b395-2cbf2975f190.png\">\r\n\r\nAs you might imagine I have become rather reliant on these maximally concise diffs where there are several main optimal properties:\r\n- no unchanged context content is ever duplicated, so context uses up the least amount of space possible\r\n- to my knowledge this can produce intelligible output highlighting under many stressful scenarios, when alternative less intensive diff algorithms cannot succeed. Examples include:\r\n - text dumps of SQL tables for double-checking transactions, \r\n - automatic code formatting applied to code: confirming no functional code changes. You would think that something like `diff-highlight` can take care of this when only changing whitespace, but as already shown when more than one change exists on a given line, it comes up short, and as a general rule, line based tools including Github often completely come apart at the seams even when only whitespace changes are introduced, in particular when newlines get introduced or removed,\r\n - something I did the other day which was the comparison between a Jenkins consoleText output and a `tmux capture-pane -eJ` export, which inserts a large number of trailing spaces in each line and many small insignificant changes\r\n\r\nSo far I've never had a need for changing the behavior of this from doing a kind of brute force character-wise diff. I have not had a chance to more deeply explore `git --word-diff`, i would want to adjust its output somewhat and wrap it still if I were to use it, for example added or removed newlines don't show well in the `color` configuration.\r\n\r\nNow computing a character-wise diff does increase computational load compared to regular diff implementations and I use it for almost, but not all, git diff viewing scenarios: I keep aliases around to use lesser, much faster diffs, and use them often when engaging in deep archaeology sessions because the runtime of `dmp` appears in practice to be a bit worse than n*log(n) complexity (an area to investigate another time).\r\n\r\nAll of this to say, I have a unique perspective on this issue of \"squashed-diff\" output, I come bearing a third possible input to Delta, and am strongly in support of having flexibility of input for Delta so that I may apply it to my own needs. I want to be able to use all diff tools at my disposal in git, and I've described (unfortunately not very concisely) the delightful extent of the benefits inside and outside of git that can be had from dedicating a little more compute to diff calculation.\r\n\r\nI feel that Delta has independently gone down the same path in this regard, to great effect and with a much more efficient implementation. When I consider choosing between using Delta or `sift` with `git diff`, there is usually no contest because Delta is a more pleasant experience *in most cases*, whether unified or side by side (quite the accomplishment I'd say). It is a great deal faster. But in many examples when only small syntactical changes are present, a large amount of actual output is produced, making quickly scanning and understanding the change more difficult than it has to be! A small amount of this is down to differences in comparison token boundary definitions, which I think are configurable and can be optimized further to reduce the amount of raw change characters highlighted (note, brute char-wise diff does go overboard finding useless matching patterns and causing garbled output, so it is not always better), a larger part of the extra content is due to duplication found in the minus- and plus- context lines. They're clearly helpful when changes become more complex, but they are also visually distracting when changes are simple.\r\n\r\nSo, the point I want to make (and finally coming back to the topic at hand): \r\n\r\n## word-diff is often more concise and readable\r\n\r\nIt's clear to me now that I have been driving Delta for a few weeks that its only weaknesses compared to my beloved `sift` is verbosity. In the vast majority of cases, a change involves small portions of a few lines. The problem with Delta/github is that it will always use up two lines of context to show a change, no matter how small. Since I'm very used to it, I would be one of these squashed-diff users, so my two cents would be in support of enabling all the possibilities (threw in a `--color-moved` related bullet but i think we should ignore that for this discussion as it is out of scope, but mentioning in case it is relevant in implementation):\r\n\r\n- to be capable of identifying and interpreting different types of input diffs:\r\n - vanilla ansi colored unified diff (already works, also works as raw stdin without ansi colors e.g. `diff -u ... | delta`)\r\n - word-diff in whatever flavors is most suitable for parsing, perhaps porcelain. Then I can edit `sift` to emit porcelain word-diff format and run e.g. `sift | delta` for my non-git shenanigans for example as a way to perhaps input a diff suggestion (this feature might be ill-formed, sorry)\r\n - color-moved when enabled as default or zebra (they are the same) as I expect parsing dimmed-zebra may be nontrivial\r\n - raw pair of input files (i'm not familiar with how it computes diff internally but i know it works) \r\n- to internally rebuild minus- and plus-lines in hunks and syntax-highlight each version of each hunk\r\n- to have configurable output modes\r\n - unified\r\n - side-by-side\r\n - squashed\r\n\r\n## On syntax highlighting of concise/squashed diff output\r\n\r\nI am not sure if there was a consensus regarding whether/how to highlight the squashed diff lines. \r\n\r\nI think the minus and plus sections themselves never have ambiguity in their syntax. They should just be highlighted per their computed values based on the minus- and plus- reconstructed hunks.\r\n\r\nIt is the context lines that have ambiguity. This is, after all, why I believe we need to consider even in the squashed-diff mode we're proposing, that we may still want to have a configurable mode where if the syntax in the unchanged context would be different that we should show the minus- and plus- unchanged context content. A simple example of this is if some lines become commented. They turn from code syntax to comment syntax. I know what I would like to do to view these scenarios is I would like to see both versions of diff, squashed to make it easier to see all of the chars changed only (i'd do it today with `sift`!), and I'd like to also see it expanded so I can confirm the green sides all have commented syntax (today Delta crushes this task). So I argue this should be an option. \r\n\r\n## Misc. (somewhat off topic but might help someone who has gone off the deep end like me)\r\n\r\nI've found it difficult ever since I discovered Delta recently, to toggle between 3 ways to view git diff, \r\n\r\n1. delta\r\n2. sift (its output getting sent to delta works fine it turns out -- delta knows not how to interpret it so it spits it back out verbatim, but I get whatever delta's been configured for for the header styles/decoration)\r\n3. vanilla (`git --no-pager diff --color=always | less` as a way to disable delta as pager) as a backup which always runs fast, which I will probably never use going forward now that I have delta\r\n\r\nThe issue I was running into was that if I configure an external diff (`diff.external`), `--color-moved` never gets applied. This makes a little bit of sense, but I think it is a bug, because I believe when `--no-ext-diff` is specified it should behave as though no external diff is configured, but it doesn't do that, it seems to disable `--color-moved`. \r\n\r\nIn conjunction with this, since this issue means that I cannot use a `diff.external` because I do want to benefit from `--color-moved`, I had a great deal of difficulty enabling `sift` inside `git log -p` which I do use a great deal. \r\n\r\nI just did some testing and was able to find the workaround!\r\nIt is possible to use `GIT_EXTERNAL_DIFF=sift git log -p --ext-diff` to enable an ext diff for `log -p`. I think I have all the puzzle pieces for this again now. This makes me feel much better being able to have all the choices for the most capable tools at hand. But most ideal would be if one tool can be the best in all scenarios, that is the dream, one diff to rule them all!\r\n","createdAt":"2021-11-26T08:55:02Z","includesCreatedEdit":true,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/152#issuecomment-979796986","viewerDidAuthor":false},{"id":"IC_kwDOC4j8g846xZmh","author":{"login":"dandavison"},"authorAssociation":"OWNER","body":"The current release (0.10.3) refuses to handle `--word-diff` or `--color-words` at all, instead allowing the raw git output through. I think this is at least a step in the right direction since what delta was doing previously to that input was entirely invalid.","createdAt":"2021-12-04T13:36:28Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/152#issuecomment-986028449","viewerDidAuthor":true},{"id":"IC_kwDOC4j8g85V68cN","author":{"login":"vigo"},"authorAssociation":"NONE","body":"```\r\n$ git diff --word-diff\r\nfatal: invalid regular expression: [a-zA-Z_][a-zA-Z0-9_]*|[-+0-9.eE]+i?|0[xX]?[0-9a-fA-F]+i?|[-+*/<>%&^|=!:]=|--|\\+\\+|<<=?|>>=?|&\\^=?|&&|\\|\\||<-|\\.{3}|[^[:space:]]|[�-�][�-�]+\r\n```\r\n","createdAt":"2023-02-23T10:24:33Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/152#issuecomment-1441515277","viewerDidAuthor":false},{"id":"IC_kwDOC4j8g86TADXH","author":{"login":"dandavison"},"authorAssociation":"OWNER","body":"> ```\r\n> $ git diff --word-diff\r\n> fatal: invalid regular expression: [a-zA-Z_][a-zA-Z0-9_]*|[-+0-9.eE]+i?|0[xX]?[0-9a-fA-F]+i?|[-+*/<>%&^|=!:]=|--|\\+\\+|<<=?|>>=?|&\\^=?|&&|\\|\\||<-|\\.{3}|[^[:space:]]|[�-�][�-�]+\r\n> ```\r\n\r\nI'm not aware of a bug like this. @vigo if this is something that you can repro it would be great if you could post the input to delta that causes this error.","createdAt":"2024-11-09T15:49:48Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/152#issuecomment-2466264519","viewerDidAuthor":true},{"id":"IC_kwDOC4j8g86TCI-Y","author":{"login":"vigo"},"authorAssociation":"NONE","body":"@dandavison ooh man, i don't remember right now :) it's been months :) i'll send if this occurs again.","createdAt":"2024-11-10T17:07:48Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[{"content":"THUMBS_UP","users":{"totalCount":1}}],"url":"https://github.com/dandavison/delta/issues/152#issuecomment-2466811800","viewerDidAuthor":false}],"number":152,"title":"🚀 Highlighting of --word-diff output, and custom \"squashed\" diff output"},{"body":"Hi I believe I came across an issue, but I'm not sure. I've configured `delta` this way in my `.gitconfig`\r\n\r\n```\r\n[core]\r\n pager = delta --width=variable\r\n```\r\n\r\nI have this alias as well \r\n\r\n```\r\n[alias]\r\n slog = log --graph --pretty=format:'%C(red)%h%Creset %C(green)%ad%Creset %C(magenta)%G?%Creset %s %C(auto)%d%Creset %C(bold blue)%ae%Creset' --abbrev-commit --date=format:'%Y-%m-%d %H:%M' --color=always\r\n```\r\n\r\nI narrowed the issue to the `--graph` option, when it's used, delta somehow back out\r\n\r\n```bash\r\ngit log --graph --patch\r\n```","comments":[{"id":"MDEyOklzc3VlQ29tbWVudDYyMDU5MjgxNw==","author":{"login":"bric3"},"authorAssociation":"NONE","body":"<details><summary> <code>git log -1 --graph --patch</code> ✅ </summary>\r\n\r\n```\r\n* commit 8baa3f796113965b5225944413a74359e5409e5d (HEAD -> master, origin/master, origin/HEAD)\r\n| Author: Scott McLeod <halcyonblue@gmail.com>\r\n| Date: 2020-04-21 00:32:06 -0400\r\n|\r\n| Fold retrieve-sapmachine into retrieval code, use globbing for cache\r\n|\r\n| diff --git a/bin/functions b/bin/functions\r\n| index 9e01fe7..c5d5bf8 100755\r\n| --- a/bin/functions\r\n| +++ b/bin/functions\r\n| @@ -1,9 +1,12 @@\r\n| #!/usr/bin/env bash\r\n| -set -e\r\n| -set -Euo pipefail\r\n|\r\n| PLUGIN_HOME=\"$(dirname \"$(dirname \"${0}\")\")\"\r\n| CACHE_DIR=\"${TMPDIR:-/tmp}/asdf-java.cache\"\r\n| +CURL_OPTS=('-f' '-s')\r\n| +\r\n| +shopt -s nullglob\r\n| +CACHE_FILES=(\"${CACHE_DIR}\"/*)\r\n| +shopt -u nullglob\r\n|\r\n| if [ ! -d \"${CACHE_DIR}\" ]\r\n| then\r\n| @@ -12,16 +15,16 @@ fi\r\n|\r\n| KERNEL_NAME=\"$(uname -s)\"\r\n| case \"${KERNEL_NAME}\" in\r\n| - Darwin) BASE64_OPTS=\"-D\"\r\n| + Darwin) BASE64_OPTS=('-D')\r\n| OS=\"mac\"\r\n| SHA256SUM=\"gsha256sum\"\r\n| - STAT_OPTS=\"-f %c\"\r\n| + STAT_OPTS=('-f' '%c')\r\n| TEMP_DIR=$(/usr/bin/mktemp -dt asdf-java)\r\n| ;;\r\n| - Linux) BASE64_OPTS=\"-d\"\r\n| + Linux) BASE64_OPTS=('-d')\r\n| OS=\"linux\"\r\n| SHA256SUM=\"sha256sum\"\r\n| - STAT_OPTS=\"-c %Z\"\r\n| + STAT_OPTS=('-c' '%Z')\r\n| TEMP_DIR=$(mktemp -dp /tmp asdf-java.XXXXXXXX)\r\n| ;;\r\n| *) echo \"Unknown operating system: ${KERNEL_NAME}\"\r\n:\r\n```\r\n\r\n</details>\r\n\r\n<details><summary> <code>git log -1 --patch</code> 🔴 </summary>\r\n\r\n```\r\ncommit 8baa3f796113965b5225944413a74359e5409e5d (HEAD -> master, origin/master, origin/HEAD)\r\nAuthor: Scott McLeod <halcyonblue@gmail.com>\r\nDate: 2020-04-21 00:32:06 -0400\r\n\r\n Fold retrieve-sapmachine into retrieval code, use globbing for cache\r\n\r\n\r\nbin/functions\r\n────────────────────────────────────────────\r\n\r\n1\r\n #!/usr/bin/env bash\r\n set -e\r\n set -Euo pipefail\r\n\r\n PLUGIN_HOME=\"$(dirname \"$(dirname \"${0}\")\")\"\r\n CACHE_DIR=\"${TMPDIR:-/tmp}/asdf-java.cache\"\r\n CURL_OPTS=('-f' '-s')\r\n\r\n shopt -s nullglob\r\n CACHE_FILES=(\"${CACHE_DIR}\"/*)\r\n shopt -u nullglob\r\n\r\n if [ ! -d \"${CACHE_DIR}\" ]\r\n then\r\n────┐\r\n fi │\r\n────┘\r\n15\r\n\r\n KERNEL_NAME=\"$(uname -s)\"\r\n case \"${KERNEL_NAME}\" in\r\n Darwin) BASE64_OPTS=\"-D\"\r\n Darwin) BASE64_OPTS=('-D')\r\n OS=\"mac\"\r\n SHA256SUM=\"gsha256sum\"\r\n STAT_OPTS=\"-f %c\"\r\n STAT_OPTS=('-f' '%c')\r\n TEMP_DIR=$(/usr/bin/mktemp -dt asdf-java)\r\n ;;\r\n Linux) BASE64_OPTS=\"-d\"\r\n Linux) BASE64_OPTS=('-d')\r\n OS=\"linux\"\r\n SHA256SUM=\"sha256sum\"\r\n STAT_OPTS=\"-c %Z\"\r\n STAT_OPTS=('-c' '%Z')\r\n TEMP_DIR=$(mktemp -dp /tmp asdf-java.XXXXXXXX)\r\n ;;\r\n *) echo \"Unknown operating system: ${KERNEL_NAME}\"\r\n```\r\n</details>","createdAt":"2020-04-28T13:03:35Z","includesCreatedEdit":true,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/141#issuecomment-620592817","viewerDidAuthor":false},{"id":"MDEyOklzc3VlQ29tbWVudDYyMDYwMjc4OQ==","author":{"login":"dandavison"},"authorAssociation":"OWNER","body":"Hi @bric3, thanks for this! I agree it's not working and I agree it would make sense for it to work in principle.\r\n\r\nRegarding implementation, the parser currently does not have any concept of \"being in `log --graph` mode\" and does not handle the possibility that each line starts with an arbitrary number of `| | | ...` markers corresponding to an arbitrary number of branch lineages.\r\n\r\nIncidentally, do you find it helpful to use `log --patch` in conjunction with `log --graph` or would you say that they people would normally use them separately? ","createdAt":"2020-04-28T13:20:45Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/141#issuecomment-620602789","viewerDidAuthor":true},{"id":"MDEyOklzc3VlQ29tbWVudDYyMTA4MDE4MQ==","author":{"login":"bric3"},"authorAssociation":"NONE","body":"> Incidentally, do you find it helpful to use `log --patch` in conjunction with `log --graph` or would you say that they people would normally use them separately?\r\n\r\nActually I usually don't do that as I'm using the git alias which happens to use the `--graph`, and sometimes I want to see the patch of a commit by adding the `-p` option. I guess it's a limitation of the `pager` way of doing things. I wonder of git could have a some way to render the diff.\r\n\r\nBut if this has to be implemnted I think using the star `*` before a commit to distinguish between graph mode or normal mode may be a clue to achieve that. I know the diff-highlight script does something like that https://github.com/git/git/commit/4551fbba141e0b2e4d16830f76f784e9c960bdf8. Although I recognize it's ultimately a tad complex.\r\n\r\n","createdAt":"2020-04-29T09:05:49Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[{"content":"THUMBS_UP","users":{"totalCount":1}}],"url":"https://github.com/dandavison/delta/issues/141#issuecomment-621080181","viewerDidAuthor":false},{"id":"IC_kwDOC4j8g85EVpOi","author":{"login":"bew"},"authorAssociation":"NONE","body":"> Incidentally, do you find it helpful to use `log --patch` in conjunction with `log --graph` or would you say that they people would normally use them separately?\r\n\r\nI'm using both at the same time, mainly because I have a git alias that reformats the commits info, body, and also enables graph.\r\nAnd when I want to see the patch diff of each commits I just add `-p` to that alias.\r\n\r\nI tested with delta 0.13.0, it's not yet working.\r\n\r\nHow difficult is the rest of the work needed to have this feature?","createdAt":"2022-06-04T04:10:13Z","includesCreatedEdit":true,"isMinimized":false,"minimizedReason":"","reactionGroups":[{"content":"THUMBS_UP","users":{"totalCount":1}}],"url":"https://github.com/dandavison/delta/issues/141#issuecomment-1146524578","viewerDidAuthor":false},{"id":"IC_kwDOC4j8g86TCH5k","author":{"login":"sebastiancarlos"},"authorAssociation":"NONE","body":"I also wanted this to be able to add `--patch` to my git log aliases. So instead I ended up making new aliases for the `--patch` use cases:\r\n\r\n```ini\r\n[alias]\r\n # log (short and long)\r\n l = log --graph --pretty=format:'%C(auto)%h %C(bold)%cs%C(auto) %C(blue)%an:%C(auto)%d %s' --color=always\r\n la = l --all\r\n ll = log --graph --pretty=fuller --abbrev-commit --color=always\r\n lla = ll --all\r\n\r\n # versions of log aliases with \"--patch\"\r\n # - they duplicate the \"l\" and \"ll\" aliases wtihout \"--graph\" since\r\n # it's not compatible with git-delta\r\n lp = log --pretty=format:'%C(auto)%h %C(bold)%cs%C(auto) %C(blue)%an:%C(auto)%d %s' --color=always --patch\r\n lap = lp --all\r\n llp = log --pretty=fuller --abbrev-commit --color=always --patch\r\n llap = llp --all\r\n```","createdAt":"2024-11-10T16:55:23Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/141#issuecomment-2466807396","viewerDidAuthor":false},{"id":"IC_kwDOC4j8g86TDKYC","author":{"login":"huyz"},"authorAssociation":"NONE","body":"Until `delta` supports `--graph`, I just fall back to `difftastic`:\r\n\r\n```ini\r\n\tlg-dt = \"!DFT_IGNORE_COMMENTS= git -c diff.external=difft log --graph --date=local --decorate --patch --ext-diff\"\r\n\tshow-dt = \"!DFT_IGNORE_COMMENTS= git -c diff.external=difft show --patch --ext-diff\"\r\n```","createdAt":"2024-11-11T01:53:46Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[{"content":"EYES","users":{"totalCount":1}}],"url":"https://github.com/dandavison/delta/issues/141#issuecomment-2467079682","viewerDidAuthor":false}],"number":141,"title":"git log --graph not supported ?"},{"body":"Delta version: delta 0.1.1\r\nI'm using mate-terminal (1.20.2) on Debian Buster.\r\nThe 24-bit color test seems to work, but the diff highlighting does not appear,\r\nWhat do I wrong? Is it some extra config needed? I attach a screenshot about my terminal.\r\n> echo $TERM\r\n> xterm\r\n> echo $COLORTERM\r\n> truecolor\r\n\r\n","comments":[{"id":"MDEyOklzc3VlQ29tbWVudDYyMDYzNzcyNg==","author":{"login":"0xC0FFEE"},"authorAssociation":"NONE","body":"FWICT this only seems to happen for some inter-line changes. However I haven't figured out the pattern yet.\r\n\r\nConsidering this line as the base:\r\n\r\n```\r\ndid_emsg = FALSE;\r\n```\r\n\r\nchanging it to:\r\n```\r\ndid_emsg == FALSE;\r\n```\r\n\r\nCorrectly highlights the diff:\r\n\r\n\r\n\r\nHowever changing the line to:\r\n```\r\ndid_emsg = TRUE;\r\n```\r\nFails:\r\n\r\n\r\n\r\nRelated: #119 ","createdAt":"2020-04-28T14:20:05Z","includesCreatedEdit":true,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/140#issuecomment-620637726","viewerDidAuthor":false},{"id":"MDEyOklzc3VlQ29tbWVudDYyMDY2NjI2Mg==","author":{"login":"dandavison"},"authorAssociation":"OWNER","body":"Hi @jakabk @0xC0FFEE thanks for this feedback. @0xC0FFEE as you've noted this is the same issue as #119. So, your example starts to be highlighted with `--max-line-distance` set to a larger value (screenshot below).\r\n\r\nBasically, this needs to be improved. The issue here is that in both examples (@jakabk's and @0xC0FFEE's) the changed section is a fairly large proportion of the line length, and delta is being (too) conservative and refusing to treat them as homologous lines. But that doesn't make much sense seeing as there is one removed line and one added line. It starts to make a bit more sense when there are, say, 1 removed line and 2 added lines, because then delta needs to make a decision about which of the 2 added lines is the replacement.\r\n\r\nIf you have any thoughts about how we should go about improving this then please let me know! My initial thought is that the algorithm should perhaps be different in the two cases: (1) same number of red and green lines vs (2) different numbers of red and green lines. GitHub/GitLab do not output the within-line highlights at all in case (2), and delta is trying to go one better here, and I think needs to do some work to stop making a mess of the common case.\r\n\r\n<table><tr><td><img width=500px src=\"https://user-images.githubusercontent.com/52205/80503049-5a59c900-893f-11ea-8d23-dfd8460f0cce.png\" alt=\"image\" /></td></tr></table>\r\n","createdAt":"2020-04-28T15:08:14Z","includesCreatedEdit":true,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/140#issuecomment-620666262","viewerDidAuthor":true},{"id":"MDEyOklzc3VlQ29tbWVudDYyMDc0MTgzNA==","author":{"login":"0xC0FFEE"},"authorAssociation":"NONE","body":"Hi @dandavison, the approach to differentiate the two cases (1) and (2) seems to make sense to me. From my experience diff-so-fancy does a good job with (1). As I've never had tooling for (2), I currently have no educated thoughts on this, except that it sounds fun and I've seen diffs today, where it really helped :+1:.\r\n\r\nMy initial take was, that a generic distance is not enough and instead (or in addition) something like the longest common sub string could be utilized. IMHO most of the time we want to highlight within-line changes when they happen to be contiguous and this is what I would explore. However I'd have a look at diff-so-fancy (and possibly other tools as well e.g. vim, gitlab, ...) before solving this from scratch. This sounds like a really common problem to me and maybe even writing this in library form might be beneficial.","createdAt":"2020-04-28T17:16:50Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[{"content":"THUMBS_UP","users":{"totalCount":1}}],"url":"https://github.com/dandavison/delta/issues/140#issuecomment-620741834","viewerDidAuthor":false},{"id":"MDEyOklzc3VlQ29tbWVudDYyMTE5MzQ2NA==","author":{"login":"jakabk"},"authorAssociation":"NONE","body":"Hi, @dandavison I'm joining to @0xC0FFEE I'd like to support the idea handling the two cases separated as well.\r\n\r\nIn the first case (one + and one -) I'd like to see the change highlighted. The recommended switch: --max-line-distance, makes much more usable the diff highlighting but it's not perfect.\r\n> delta --max-line-distance 0.8\r\n\r\n\r\nIn the second case, I find @0xC0FFEE idea good: using the longest common substring to choose the appropriate lines and showing the diff between the two chosen lines.","createdAt":"2020-04-29T13:10:02Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[{"content":"THUMBS_UP","users":{"totalCount":1}}],"url":"https://github.com/dandavison/delta/issues/140#issuecomment-621193464","viewerDidAuthor":false},{"id":"MDEyOklzc3VlQ29tbWVudDYyMTg3MTQ4MQ==","author":{"login":"dandavison"},"authorAssociation":"OWNER","body":"Thanks @0xC0FFEE @jakabk @igordovgaluk. I definitely want to get an improved v2 within-line edit inference algorithm out. It would be really helpful if you could carry on submitting more examples that you encounter of bad (or good) within-line highlighting (as plain text, just as comments in this issue is fine, or as a PR against the `tests/examples` directory). I wonder whether it ultimately will be helpful to have a large-ish collection of such examples on which we can score alternative algorithms; possibly even explore the parameter space programatically. I've added scripts with your examples so far to the `tests/examples/` dir in the repo.\r\n\r\nHere's a counter-example:\r\n\r\n```diff\r\ndiff --git a/file b/file\r\nindex 1dc5384..fa4f6e9 100644\r\n--- a/file\r\n+++ b/file\r\n@@ -1,3 +1,3 @@\r\n-aaaa a aaa\r\n-bbbb b bbb\r\n-cccc c ccc\r\n+bbbb ! bbb\r\n+dddd d ddd\r\n+cccc ! ccc\r\n```\r\n\r\nCurrent delta does this one correctly (and this is what I was going for with the original algorithm):\r\n\r\n<table><tr><td><img width=280px src=\"https://user-images.githubusercontent.com/52205/80717173-8a7fa400-8ac6-11ea-8209-9ccfb02c3128.png\" alt=\"image\" /></td></tr></table>\r\n\r\nDo you see value in that sort of behavior? I don't think any of diff-so-fancy, GitLab, GitHub etc get that one right.\r\n\r\nIf we switch to \"naive line matching\" when there are equal numbers of plus and minus lines (i.e. always assume that the i-th green evolved from the i-th red line), then we of course will \"fail\" on this example:\r\n\r\n<table><tr><td><img width=250px src=\"https://user-images.githubusercontent.com/52205/80717846-5eb0ee00-8ac7-11ea-861d-4610b5e94bb2.png\" alt=\"image\" /></td></tr></table>\r\n\r\nI'm not saying that it's essential to do this example correctly: it's obviously important to do the common cases well, and I think the equal-line-numbers that you're highlighting are common cases.\r\n\r\n\r\nSo, this needs more thought but off the top of my head here are some considerations:\r\n\r\n- Whether to match lines \"naively\" when there are equal numbers of red and green lines\r\n- If so, I think we still need some sort of threshold to avoid \"forcing\" noisy/spurious edits on two completely different lines.\r\n- If not, then what algorithm is used for deciding which lines are homologous? The original (current) algorithm uses a needleman-wunsch / levenshtein edit distance, and demands that that exceeds a certain threshold in order for two lines to be considered homologs. It's greedy, to avoid a quadratic-time search over all matching pairs (i.e., basically, assumes the lines are not out of order).\r\n- Is it possible to have the best of both worlds where we succeed on things like the \"counter-example\" above and also get the simple examples of same-number-of-red-and-green right?\r\n- Can we put together a collection of examples and score alternative algorithms?\r\n- What should the defaults be if delta ends up supporting alternative algorithms?\r\n","createdAt":"2020-04-30T14:00:42Z","includesCreatedEdit":true,"isMinimized":false,"minimizedReason":"","reactionGroups":[{"content":"THUMBS_UP","users":{"totalCount":1}}],"url":"https://github.com/dandavison/delta/issues/140#issuecomment-621871481","viewerDidAuthor":true},{"id":"MDEyOklzc3VlQ29tbWVudDYyMjM1ODQzOA==","author":{"login":"0xC0FFEE"},"authorAssociation":"NONE","body":"> Do you see value in that sort of behavior? I don't think any of diff-so-fancy, GitLab, GitHub etc get that one right.\r\n\r\nI definitely think that this is can be valuable (even if it is still somewhat hard for me to comprehend and understand what changed). Also I guess you are right, as I've not seen cases like this handled before in other tools :+1:.\r\n\r\nI think gathering (real world) examples were `delta` produces unexpected outputs will help in the future.","createdAt":"2020-05-01T11:52:02Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/140#issuecomment-622358438","viewerDidAuthor":false},{"id":"MDEyOklzc3VlQ29tbWVudDYyMjM3NjQyOQ==","author":{"login":"dandavison"},"authorAssociation":"OWNER","body":"Great. Just in case it's not already clear, handling the unequal-number-of-lines case in general is something that delta does that AFAIK other tools do not. It's that which is currently causing us to encounter suboptimal examples in the same-number-of-lines case (but I'm sure we can improve this). Here's an example of Delta's unequal-number-of-lines handling:\r\n\r\n**Github:**\r\n\r\n<table><tr><td><img width=500px src=\"https://user-images.githubusercontent.com/52205/80806436-b19eaa00-8b88-11ea-8f00-cf5a335ed9e5.png\" alt=\"image\" /></td></tr></table>\r\n\r\n**Delta:**\r\n\r\n<table><tr><td><img width=500px src=\"https://user-images.githubusercontent.com/52205/80806462-c0855c80-8b88-11ea-9157-1ec1e978c5ea.png\" alt=\"image\" /></td></tr></table>\r\n","createdAt":"2020-05-01T12:54:43Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/140#issuecomment-622376429","viewerDidAuthor":true},{"id":"MDEyOklzc3VlQ29tbWVudDYyMjQzMTY1Mg==","author":{"login":"dandavison"},"authorAssociation":"OWNER","body":"Here's something to play with if you can build from source: I've pushed 5162437b6463d36dafb72e90b6b38b09e66cb955 to master. This allows you to activate an experimental feature by setting an environment variable:\r\n\r\n```\r\nexport DELTA_EXPERIMENTAL_MAX_LINE_DISTANCE_FOR_NAIVELY_PAIRED_LINES=0.8\r\n```\r\n\r\nHere's what that does:\r\n\r\n1. If a hunk contains the same number of added and removed lines, then those will be assumed to match \"naively\", i.e. the i-th removed line is homologous to the i-th added line.\r\n\r\n2. If the distance between the two lines is less than 0.8, then apply emphasis colors to the inferred edit operations transforming the old line into the new line.\r\n\r\n\"distance\" is a number between 0 (identical lines) and 1 (totally different lines). It is basically defined as\r\n\r\n```\r\n number of characters involved in inferred edits\r\ndistance = -------------------------------------------------\r\n number of characters in the line\r\n```\r\n\r\nSee [edits.rs](https://github.com/dandavison/delta/blob/5162437b6463d36dafb72e90b6b38b09e66cb955/src/edits.rs#L159-L217) for exact calculation.\r\n\r\nSo, for example, if the env var has a value > 0.32 then we get\r\n\r\n<table><tr><td><img width=300px src=\"https://user-images.githubusercontent.com/52205/80816598-cb96b780-8b9d-11ea-9178-bb22575c4e14.png\" alt=\"image\" /></td></tr></table>\r\n\r\nIn practice I'm thinking that values somewhere above 0.6 will be appropriate but it would be great to hear what you find works with this version of the algorithm.","createdAt":"2020-05-01T15:22:44Z","includesCreatedEdit":true,"isMinimized":false,"minimizedReason":"","reactionGroups":[{"content":"HOORAY","users":{"totalCount":2}}],"url":"https://github.com/dandavison/delta/issues/140#issuecomment-622431652","viewerDidAuthor":true},{"id":"MDEyOklzc3VlQ29tbWVudDYyMjU0NDIzMA==","author":{"login":"0xC0FFEE"},"authorAssociation":"NONE","body":"Thanks for providing a usable version of your idea so promptly. I'll test-drive this next week and report interesting results back. Kudos!","createdAt":"2020-05-01T20:06:54Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/140#issuecomment-622544230","viewerDidAuthor":false},{"id":"MDEyOklzc3VlQ29tbWVudDYyMjU2Mjk2MQ==","author":{"login":"dandavison"},"authorAssociation":"OWNER","body":"Just to be clear, I put this up simply because it was very easy to do from what we have already; there could well be merit in more involved changes.","createdAt":"2020-05-01T20:50:40Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/140#issuecomment-622562961","viewerDidAuthor":true},{"id":"MDEyOklzc3VlQ29tbWVudDYyNjE4ODY1Ng==","author":{"login":"dandavison"},"authorAssociation":"OWNER","body":"If anyone tries out `DELTA_EXPERIMENTAL_MAX_LINE_DISTANCE_FOR_NAIVELY_PAIRED_LINES` then it would be really helpful to hear about your findings! I think that setting it to a large value (closer to 1.0) solves many of the \"I was expecting this to be highlighted but it isn't\" issues. However, we need to have some control on it to prevent it inferring \"edits\" between totally unrelated lines.\r\n\r\nThis aspect of delta development (improving the within-line highlight algorithms and options) is one that could benefit a lot from having multiple people's thoughts (since we use different languages, work in code bases with different styles, etc).","createdAt":"2020-05-09T14:59:21Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[{"content":"HEART","users":{"totalCount":1}}],"url":"https://github.com/dandavison/delta/issues/140#issuecomment-626188656","viewerDidAuthor":true},{"id":"IC_kwDOC4j8g85PPUlG","author":{"login":"phillipwood"},"authorAssociation":"CONTRIBUTOR","body":"> > delta --max-line-distance 0.8\r\n> > \r\n\r\nWith PR #1244 this is now highlighted correctly without having to tweak `max-line-distance`\r\n\r\n","createdAt":"2022-11-28T16:45:54Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/140#issuecomment-1329416518","viewerDidAuthor":false},{"id":"IC_kwDOC4j8g85PUezz","author":{"login":"phillipwood"},"authorAssociation":"CONTRIBUTOR","body":"> So, this needs more thought but off the top of my head here are some considerations:\r\n> \r\n> * Whether to match lines \"naively\" when there are equal numbers of red and green lines\r\n> \r\n> * If so, I think we still need some sort of threshold to avoid \"forcing\" noisy/spurious edits on two completely different lines.\r\n> \r\n> * If not, then what algorithm is used for deciding which lines are homologous? The original (current) algorithm uses a needleman-wunsch / levenshtein edit distance, and demands that that exceeds a certain threshold in order for two lines to be considered homologs. It's greedy, to avoid a quadratic-time search over all matching pairs (i.e., basically, assumes the lines are not out of order).\r\n\r\nI wonder if it would be practical to use the patience diff algorithm to pair up lines based on unique tokens within them and then use the current LCS calculation to highlight them once they're paired. That would avoid a quadratic search to pair the lines up while hopefully avoiding the suboptimal matches from the greedy matching that delta currently uses.\r\n","createdAt":"2022-11-29T14:51:31Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[{"content":"HEART","users":{"totalCount":1}}],"url":"https://github.com/dandavison/delta/issues/140#issuecomment-1330769139","viewerDidAuthor":false}],"number":140,"title":"Within-line edit highlighting is unpredictable"},{"body":"If delta receives a hunk that looks something like the example below, then it will syntax highlight the code as a string. (This is a python example, but the problem exists in any language with multiline string literals I think):\r\n\r\n```\r\n ...and this is the end of my docstring.\r\n \"\"\"\r\n x = some_function(\"some_string\") # This line should be syntax-highlighted as code.\r\n```\r\n\r\n<table><tr><td>\r\n<img width=600px src=\"https://user-images.githubusercontent.com/52205/77352512-afd60100-6d15-11ea-8e15-39d4bd878822.png\" alt=\"image\" />\r\n</td></tr></table>\r\n\r\n\r\nThat seems like an inevitable ambiguity. However, are there perhaps some heuristics that could be introduced to allow delta to guess which side of the `\"\"\"` is code and which side string literal?","comments":[{"id":"MDEyOklzc3VlQ29tbWVudDY4NzI4MTYxMw==","author":{"login":"dandavison"},"authorAssociation":"OWNER","body":"From @kofls in #316 \r\n\r\n> I think a simple solution would be to get the syntax style per file and use that for each diff section\r\n\r\nDo you mean that delta should try to locate the entire file on disk, and use that to determine exactly what is going on in a diff that shows just a fragment of the file? That's a good point, delta could try to do that. It won't always work of course, because the diff might just be piped to delta and the files mentioned in the diff might not even exist, but delta does already use libgit2 to see if it is in a git repo. As you say, it could be an option.","createdAt":"2020-09-04T17:23:51Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/117#issuecomment-687281613","viewerDidAuthor":true},{"id":"MDEyOklzc3VlQ29tbWVudDY4NzQxMTE5Mg==","author":{"login":"kofls"},"authorAssociation":"NONE","body":"Yup, that was what I meant. I hadn't considered that the diff source might not be files. ","createdAt":"2020-09-04T21:55:26Z","includesCreatedEdit":true,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/117#issuecomment-687411192","viewerDidAuthor":false},{"id":"MDEyOklzc3VlQ29tbWVudDgxMzMzNTQ1Ng==","author":{"login":"YodaEmbedding"},"authorAssociation":"NONE","body":"**Quick n' dirty:** I think that syntax highlighting both portions (even if incorrect) is less disastrous than not highlighting the code at all. Perhaps a quick and simple workaround would be to ignore `\"\"\"` when highlighting, so that everything gets highlighted?\r\n\r\n**Robust and accurate:** `delta` knows the file location, line numbers, and the line number of function definition. So read the file, skip to the function definition, then highlight from there until the end of the function. Now extract the relevant lines from the diff and display those. There are probably some edge cases to handle but that seems to be a good way to do this properly.","createdAt":"2021-04-05T10:52:11Z","includesCreatedEdit":true,"isMinimized":false,"minimizedReason":"","reactionGroups":[{"content":"THUMBS_UP","users":{"totalCount":6}}],"url":"https://github.com/dandavison/delta/issues/117#issuecomment-813335456","viewerDidAuthor":false},{"id":"MDEyOklzc3VlQ29tbWVudDgzMjU1MTYyOA==","author":{"login":"Alphare"},"authorAssociation":"NONE","body":"> Robust and accurate: delta knows the file location, line numbers, and the line number of function definition\r\n\r\nFYI this would only work with Git which is content-addressable, and not (as simply) with Mercurial. I'm not even sure that *every operation* in Git can be recovered by looking up a file given the information available in a diff, but I don't know enough about Git.","createdAt":"2021-05-05T09:35:05Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/117#issuecomment-832551628","viewerDidAuthor":false},{"id":"MDEyOklzc3VlQ29tbWVudDgzNDMxMDgxNg==","author":{"login":"Alphare"},"authorAssociation":"NONE","body":"There exists the `git diff -U` and `hg diff -U` flags that give more context. `delta` could use this flag and then strip down the added context. Note that the theoretical \"right\" approach in Mercurial would be to use some kind of `extdiff` mechanism, but that's probably more work. :)","createdAt":"2021-05-07T12:00:29Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[{"content":"THUMBS_UP","users":{"totalCount":1}},{"content":"HEART","users":{"totalCount":1}}],"url":"https://github.com/dandavison/delta/issues/117#issuecomment-834310816","viewerDidAuthor":false},{"id":"IC_kwDOC4j8g85NBQbx","author":{"login":"TheKevJames"},"authorAssociation":"NONE","body":"Potentially a middle-ground between @YodaEmbedding's options:\r\n\r\nTry to highlight both sides, capture how successful we were (does `bat` expose details on what the guessed language was? This could even be a simple \"bat guessed the wrong language for this file, probably a comment!\"), only show the highlights if `error_count < n`.","createdAt":"2022-10-26T14:52:29Z","includesCreatedEdit":true,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/117#issuecomment-1292175089","viewerDidAuthor":false},{"id":"IC_kwDOC4j8g85NBWFz","author":{"login":"dandavison"},"authorAssociation":"OWNER","body":"Hi @TheKevJames, delta does not use bat for syntax highlighting ~or guessing languages~. I'm curious -- could you tell me where you got the impression that it does? You're not alone, it's a common misconception!","createdAt":"2022-10-26T15:09:33Z","includesCreatedEdit":true,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/117#issuecomment-1292198259","viewerDidAuthor":true},{"id":"IC_kwDOC4j8g85NBcxQ","author":{"login":"TheKevJames"},"authorAssociation":"NONE","body":"@dandavison oh, interesting! I took a quick glance at the README before writing my above message and came across the following lines:\r\n\r\n> Language syntax highlighting with the same syntax-highlighting themes as [bat](https://github.com/sharkdp/bat#readme)\r\n> All the syntax-highlighting color themes that are available with [bat](https://github.com/sharkdp/bat/) are available with delta:\r\n\r\nThey definitely don't state that \"bat is used for syntax highlighting\" directly, but my read from them implied it. IMO \"why mention bat if it's not relevant here?\"\r\n\r\nGuesswork start here: perhaps the library you use for syntax highlighting is just the same one as bat's, or something like that? Maybe mentioning the library could help? eg.\r\n\r\n\"All the syntax-highlighting color themes that are available with $library -- the same library used by [bat](https://github.com/sharkdp/bat/) -- are available with delta\"\r\n","createdAt":"2022-10-26T15:28:51Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/117#issuecomment-1292225616","viewerDidAuthor":false},{"id":"IC_kwDOC4j8g85NBc2w","author":{"login":"dandavison"},"authorAssociation":"OWNER","body":"Actually, re-reading what you wrote, you're just talking about guessing languages, not syntax highlighting. OK, so the way this works is:\r\n\r\n1. Delta uses some code from bat to map a file name to a language.\r\n2. Delta uses [syntect](https://github.com/trishume/syntect) to syntax highlight that language.\r\n","createdAt":"2022-10-26T15:29:08Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[],"url":"https://github.com/dandavison/delta/issues/117#issuecomment-1292225968","viewerDidAuthor":true},{"id":"IC_kwDOC4j8g85NBdg3","author":{"login":"dandavison"},"authorAssociation":"OWNER","body":"Yes, exactly, you're right -- delta and bat use the same syntax highlighting library. Thanks, I'll change the README as you suggest -- this confuses lots of people. I thought it might help to mention that they're the same themes to reassure people that they will be able to create a visually consistent experience using both programs.","createdAt":"2022-10-26T15:31:06Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[{"content":"THUMBS_UP","users":{"totalCount":2}}],"url":"https://github.com/dandavison/delta/issues/117#issuecomment-1292228663","viewerDidAuthor":true},{"id":"IC_kwDOC4j8g85NBoCx","author":{"login":"TheKevJames"},"authorAssociation":"NONE","body":"Definitely agree on mentioning the similarity to bat -- the two having the same themes was certainly relevant to me when I started looking into using delta! But yeah, mentioning/linking to syntect will certainly help folks looking for a more specific understanding of what lib does what thing.\r\n\r\nSo in that case, it looks to me like the functionality I described would best be implemented via changes to syntect code; eg. they would need to offer someway to check if a given SyntaxSet \"seems to be correct\".\r\n\r\nMy initial thought is that \"seems to be correct\" might be approximate by checking on the number of modifications: my naive assumption is that in cases where we're highlighting the code we would get many tokens highlighted with their syntax but in cases where we're highlighting the comment we would get few highlights (or perhaps \"all the same\"? Not sure if there's a highlight for \"this token doesn't make sense here\").\r\n\r\nSo in that case, an option which doesn't require syntect changes might be to modify [this chunk of delta](https://github.com/dandavison/delta/blob/b99e6c5d9c9c099d9c97f59e6e27a2f1ba53d863/src/paint.rs#L682-L686).\r\n\r\nPardon my incredible lack of rust fluency here, but in attempted psuedo-code / bad code, we might be able to do something like:\r\n```rust\r\nlet mut line_styles = Vec::new();\r\nfor (line, _) in lines.iter() {\r\n let sections = highlighter\r\n .highlight_line(line, &config.syntax_set)\r\n .unwrap();\r\n # MIN_STYLED_TOKENS might be \"at least n tokens should be highlighted\"\r\n # alternatively, it could be \"at least n% of the line is hightlighted\"\r\n let is_styled = sections\r\n .reduce(|acc, (style, _)| {\r\n if (style != NULL && style != INVALID_TOKEN) { acc += 1 }\r\n }) <= MIN_STYLED_TOKENS;\r\n line_styles.push((sections, is_styled));\r\n}\r\n\r\n# ie. \"split our vector into lines before and lines after a block comment\"\r\nlet index = line_styles.iter().position(|(line, _)| line == \"\\\"\\\"\\\"\").unwrap();\r\nlet styled_tokens_before = line_styles[..index]\r\n .filter(|(_, is_styled)| { is_styled })\r\n .count();\r\nlet styled_tokens_after = line_styles[index..]\r\n .filter(|(_, is_styled)| { is_styled })\r\n .count();\r\n\r\n# This could also be thresholded: eg. \"if they're close enough, style both\"\r\nif (styled_tokens_before > styled_tokens_after) {\r\n line_sections.push(line_styles[..index]);\r\n for (line, _) in lines[index..].iter() {\r\n line_sections.push(vec![(config.null_syntect_style, line.as_str())]);\r\n }\r\n} else {\r\n for (line, _) in lines[..index].iter() {\r\n line_sections.push(vec![(config.null_syntect_style, line.as_str())]);\r\n }\r\n line_sections.push(line_styles[index..]);\r\n}\r\n```","createdAt":"2022-10-26T16:02:29Z","includesCreatedEdit":false,"isMinimized":false,"minimizedReason":"","reactionGroups":[{"content":"THUMBS_UP","users":{"totalCount":1}}],"url":"https://github.com/dandavison/delta/issues/117#issuecomment-1292271793","viewerDidAuthor":false}],"number":117,"title":"Syntax highlighting sometimes incorrect with multiline constructs "}]
|