- Mentioned In
- D19748: Skip copied code detection for changes that are too large for it to be useful
rP0363febeb2c6: Disable default syntax highlighting for large files in DocumentEngine
D19306: Disable default syntax highlighting for large files in DocumentEngine
T12948: Remove the `bin/files purge` workflow
D14273: Skip pygmentize for large source and too long lines
- Mentioned Here
- T8227: Why not just add an option/setting/preference?
T13105: Plans: Rich presentation and diff rendering pipelines for various file types
T7776: Loading delta between two diffs in Differential can result in diffs for large files failing to load
D12132: Don't highlight very large files by default
And, if your desired value is larger, would making it easier to activate highlighting be a reasonable alternative approach? Currently you can highlight with:
View Options → Highlight As...
...but this is a minimum of three clicks. We could do this instead:
Syntax highlighting is disabled for this enormous file. Highlight File
Or, more broadly, is your codebase littered with >256KB source files which routinely need human review, or is this just cumbersome for the handful you have?
(I'm also assuming you want to increase the limit rather than lower it, although I could imagine that also being the case..)
Sorry, I'll make sure to describe problems in the future!
Previously, differential would syntax highlight all files. Now, syntax highlighting a large file is a 5-click process. (Selecting "use default" doesn't seem to work, so we actually have to select a language -- that's why I'm getting 5 clicks and not 3.)
I searched across our main repos, and we have 10 files that are edited and reviewed by humans and are >256KB. Our largest is 537KB. So, not terribly common, but for some of these files there are teams that edit the files daily, and this issue is causing a lot of frustration on these teams.
In an ideal world, would the regularly edited human-facing 537KB file still be a single 537KB file (rather than, e.g., a collection of smaller files, or a code-generated file, or some other kind of resource)?
That is, is this exacerbating an existing architectural/code-quality problem where some projects have 20K-line "Spaghetti.java" files, or are these files basically pretty reasonable and my assumption that 256KB is well above the upper size bound for a reasonable source file just not holding up well in the real world?
I don't currently plan to pursue this. We haven't seen interest from other installs and I think the upstream behavior is reasonably good most of the time and not a huge issue even when we get it wrong (you can still review the file without doing anything, and can get highlighting with a few clicks -- plus, the file and page render much faster).
You can change DifferentialChangesetParser::HIGHLIGHT_BYTE_LIMIT locally to adjust this behavior:
See T8227 for some discussion of why options which will see very little use face a high barrier to adoption in the upstream.
See also T13105 for some modern context.