Often when reviewing a diff in phabricator, I'll suggest a revision for the diff author using a remarkup indented code block. Characters in the code block are sometimes misinterpreted by remarkup, so I have to insert lang=python or php or java or whatever the file is at the top of my code block.
It would save us all a couple lines in review if remarkup defaulted to lang=<whatever_code_type_the_current_file_is>.
:-)
See some earlier discussion in T6823. At that time, we opted not to give contexts where we can infer a language (pastes, inline comments) any special behavior and wait for feedback.
Hrm. Yeah, T6823 raises some difficulties of finding a good default for everyone I hadn't considered though. Maybe we could support environments with multiple and mixed languages (e.g. sql embedded in python or html/css embedded in php) by parsing language suggestions in-line? Something like:
# Coolest python/hive/bash/html code evarr. sql = '''-- lang=sql, but a thing called sql should just be colorized that way. :-P SELECT email FROM dim_thos_folks WHERE LOWER(fursonality) LIKE '%party%'; ''' # Sorry Larry, the party is too big and Oracle can't hang with all that data. if big_party: partiers = hive.run(sql) else: partiers = oracle.run(sql) # Send invites. for person in partiers: subprocess.call('''#lang=bash, ok maybe we have to specify here since it looks like an email too. cat<<EOF | sendmail || echo 'There will be no party.' from: Party Crew <crew@partytime.com> to: {person} subject: Friday <a href='index.html'>Because Friday.</a> EOF '''.format(**locals()) ) # Flask isn't really this easy. flask.page('index.html', '''<!-- lang=html, something with html elements is pretty obvious though, no? --> <HTML><BODY> <h1>PARTAY!</h1> <p>Time: Friday<br/>Place: 1 Hacker Way<br/>Why: Because Party.<!-- Also, because hack. --> </BODY></HTML> ''')
Just imagine it 1000 lines longer and way more ridiculously complex: so much nicer to review with all that syntax highlighting. Hopefully we could also make Differential comments synhl based on the detected language there? Also I agree it would be nice to have the global default thing for lang=none, auto, or something specific.
Regarding mixed-language environments (like sql appearing in a python script), most editors would simply look at the file extension and highlight the entire file in that language (in our example, python.. and the inline sql might appear in the color of a string).
It would be great if we could just start with the baseline behavior. Anything else seems like a ton of potential complexity that most editors don't even handle.