We would like a way to configure the HIGHLIGHT_BYTE_LIMIT setting added in D12132.
Description
Related Objects
- 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
Event Timeline
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..)
@jhurwitz - please don't forget https://secure.phabricator.com/book/phabcontrib/article/feature_requests/#describe-problems in light of your new powers. :D
Sorry, I'll make sure to describe problems in the future!
Problem:
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?
(Our largest human-facing source file is PhabricatorApplicationTransactionEditor.php and weighs in at a paltry 78KB.)
Ideally these large files would be collections of smaller files, and we have made progress towards this, but I suspect it will be a while before all such cases are completely fixed.
That being said, this isn't the first time large files have caused us pain on Phabricator. Cf T7776.
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.