Page MenuHomePhabricator

Remove default highlighting of source code as PHP?
Closed, ResolvedPublic

Description

Currently, in Remarkup, code blocks highlight as PHP by default. Although this works OK for C-family languages, it's pretty bad/distracting when a code block is used to just, e.g,., format text. Somewhat often I use code blocks to either show how to write something in Remarkup, or do something like describe a Herald rule in a structured way:

Conditions:
  If [x] is [y]
Actions:
  Do [z]

Highlighting this kind of thing as PHP makes a fairly unreadable mess of it, as a bunch of words get coloration. I think a smarter rule would probably be:

  • If the block is in an inline comment on a diff, default to the language implied by the file (for instance, inlines on a .py file get Python highlighting by default).
  • If the block is on a paste, default to the language of the paste.
  • If the block is on a revision/commit, default to the majority / plurality language of the revision/commit? Not so sure about this one. Major issue I can think of is that a "PHP" revision may be majority/plurality HTML or CSS, and the highlighters are very different. This is probably hard to figure out, too, and could theoretically change over the course of a revision. Maybe better to leave this rule out.
  • Anywhere else (no context to infer language from), don't highlight by default.

Do those rules seem reasonable?

In all case, users could still select a language explicitly with lang=..., and the language inference rules would still override this default (for example, we infer that blocks beginning with <?php are certainly PHP unless the user has said otherwise with lang=...).

Event Timeline

epriestley raised the priority of this task from to Low.
epriestley updated the task description. (Show Details)
epriestley added a project: Remarkup.
epriestley added subscribers: epriestley, btrahan, chad.
  • If the block is in an inline comment on a diff, default to the language implied by the file (for instance, inlines on a .py file get Python highlighting by default).
    • agreezy
  • If the block is on a paste, default to the language of the paste.
    • this means to use what the user selects when creating the paste? if so, also agreezy
  • If the block is on a revision/commit, default to the majority / plurality language of the revision/commit? Not so sure about this one. Major issue I can think of is that a "PHP" revision may be majority/plurality HTML or CSS, and the highlighters are very different. This is probably hard to figure out, too, and could theoretically change over the course of a revision. Maybe better to leave this rule out.
    • I think inline comments should behave the same on revisions / diffs / commits -- defaulting to the language of the filename. all other comments should have no highlight by default
  • Anywhere else (no context to infer language from), don't highlight by default.
    • agreezy

this means to use what the user selects when creating the paste? if so, also agreezy

Pretty much -- I think the exact algorithm is:

  • If they set a language, use that;
  • if they did not, try to figure it out from an extension in the paste name (for example, we guess that paste.php probably has PHP in it);
  • if that doesn't work either, we look for a few specific content patterns in the file to try to guess (for example, we guess that files with <?php in them are probably PHP, and there are a couple of other languages we can detect with high certainty).

I'm not entirely sure that no highlighting by default is always reasonable. For example, the company I work at developers mainly PHP, and pretty much all code snippets we write in comments, tasks, etc. are PHP.

Of course, writing lang=php is not a big deal, but it could seem very strange for people who've grown accustomed to the current behaviour?

Paste should get a "no highlight option" the user can select if its not there already.

I woke up thinking maybe inline comments should have no magic either? Seems the cleanest to understand, with only paste having automagicalness.

There's a "Plain Text" option in paste that stops highlighting in Paste.

If we don't do it on inlines I think it's probably not worth doing on pastes either -- I think it's pretty rare that they receive comments with code blocks, and the rule would be more consistent by removing that as a special case. I think of pastes as just an almost-free pickup if we do all the legwork for inlines.

I'm not sure if the inlines rule would be valuable or not overall. It seems reasonably unambiguous, but would be kind of complex and maybe surprising.

Maybe for v0 we just disable it everywhere and see what feedback we get? We could then purse the inlines rule, or maybe offer a global default if there's significant interest in the existing behavior (per @richardvanvelzen).

epriestley claimed this task.

This is in HEAD now. I'll keep an ear out for complaints; the behavior has mostly seemed reasonable to me so far.

I would like a configuration option, but I'm fine either way. I took me some time to get used to.