Page MenuHomePhabricator

Make HIGHLIGHT_BYTE_LIMIT configurable
Closed, WontfixPublic

Description

We would like a way to configure the HIGHLIGHT_BYTE_LIMIT setting added in D12132.

Event Timeline

jhurwitz raised the priority of this task from to Needs Triage.
jhurwitz updated the task description. (Show Details)
jhurwitz added a project: Differential.
jhurwitz added a subscriber: jhurwitz.

If it was configurable, what value would you set it to?

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 OptionsHighlight 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!

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.

jhurwitz added a project: Restricted Project.Jun 3 2015, 9:27 PM
eadler added a project: Restricted Project.Aug 5 2016, 5:24 PM
epriestley claimed this task.

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:

https://secure.phabricator.com/source/phabricator/browse/master/src/applications/differential/parser/DifferentialChangesetParser.php;af87f414e8339f1a6cc9a163ce01507aa6ca16dc$5

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.