-
Notifications
You must be signed in to change notification settings - Fork 3.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Update GitHub style #2798
Update GitHub style #2798
Conversation
Awesome! Please show a code comparison as well, say a medium snippet of Javascript, etc. |
@joshgoebel see the JS code below |
What is the orange coloring of GitHub for |
2896c75
to
8e34eae
Compare
Ah, I think that's dating back to before we had classes... since a function can of course be a class/constructor type function even before classes existed as a thing.
Well, it's a JS built-in of course (https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Object), but if you mean that perhaps GitHub isn't treating it differently because of that you may be right. Ok, now that we have more context I'm pretty confident that @allejo @egor-rogov Any thoughts here? Perhaps move all ecmascript TYPES into So the question is... is that what we have @Hirse Your'e welcome to weigh in also of course. :) |
With the current logic, for the GitHub style it might be best to stick to purple for all Would that be a reasonable solution while the bigger changes to JS grammar/logic are being worked out? |
Playing: // js
interface User {
name: string;
id: number;
}
bob.User.Smithy.conquest()
class UserAccount {
name: string;
id: number;
constructor(name: string, id: number) {
this.name = name;
this.id = id;
}
}
const user: User = new UserAccount("Murphy", 1); // ts
interface User {
name: string;
id: number;
}
class UserAccount {
name: string;
id: number;
constructor(name: string, id: number) {
this.name = name;
this.id = id;
}
}
const user: User = new UserAccount("Murphy", 1); let Bug = 53
as, // for exports
in,
of,
if,
for,
while,
finally,
var,
new,
function,
do,
return,
void,
else,
break,
catch,
instanceof,
with,
throw,
case,
default,
try,
switch,
continue,
typeof,
delete,
let,
yield,
const,
class,
// JS handles these with a special rule
// get,
// set,
debugger,
async,
await,
static,
import,
from,
export,
extends
];
const LITERALS = [
true,
false,
null,
undefined,
NaN,
Infinity
];
const TYPES = [
Intl,
DataView,
Number,
Math,
Date,
String,
RegExp,
Object,
Function,
Boolean,
Error,
Symbol,
Set,
Map,
WeakSet,
WeakMap,
Proxy,
Reflect,
JSON,
Promise,
Float64Array,
Int16Array,
Int32Array,
Int8Array,
Uint16Array,
Uint32Array,
Float32Array,
Array,
Uint8Array,
Uint8ClampedArray,
ArrayBuffer
];
const ERROR_TYPES = [
EvalError,
InternalError,
RangeError,
ReferenceError,
SyntaxError,
TypeError,
URIError
];
const BUILT_IN_GLOBALS = [
setInterval,
setTimeout,
clearInterval,
clearTimeout,
require,
exports,
eval,
isFinite,
isNaN,
parseFloat,
parseInt,
decodeURI,
decodeURIComponent,
encodeURI,
encodeURIComponent,
escape,
unescape
];
const BUILT_IN_VARIABLES = [
arguments,
this,
super,
console,
window,
document,
localStorage,
module,
global // Node.js
]; |
Agreed 👍
If I'm understanding this and RTD correctly, |
I think I'm going to change that definition in the docs, we already regularly use it more broadly. For example in some languages we do:
This is honestly how I think of them in my head and personally I'm not sure I mean technically these could be I think I'd be pretty happy to add a |
I like this idea the least. There is a distinction between function and class titles that we should try to preserve... so The only question is what to do about built-in and built-in vs type. |
I think I'm "ok" with leaving built-in as orange for now and revisiting this at a later date... |
Did we lose |
Sorry just now taking a CLOSE look at this. :-) Before I was mostly just looking at the pictures. .hljs-comment and .hljs-meta should not be the same. I'd think the meta should probably be the pretty light blue color (which would match the DOCTYPE snap to a tee). |
+1
As you've mentioned to me before, highlight.js' goal is to get users most of the way there when it comes to syntax highlighting. I think being able to differentiate between built-in and user-defined types goes against that goal and is introducing an unnecessary level of maintenance (maintaining a list of built-ins per language).
I like this idea, seems like the least specific approach and will benefit users for the majority of the cases. |
I'm always forgetting about auto-detect though, that's what maintaining the built-in lists does for ya... but still for languages where it's easy to detect proper class names by case I think I'd be a fan of an additional rule so we can color them all. And at that point the highlighting distinction (color) may not matter, but internally we'd still know what is what is what for relevance. I do think overtime that makes it harder to maintain the built-in class lists (since now no one can see when they are deficient), but that's perhaps a problem for another day. |
Using built-in lists internally for relevance definitely makes sense. I don't think there's much use for it as a CSS class though, so I'd opt out of including that distinction as a class; one less thing to worry about people potentially relying on. |
@Hirse I see some questions we've asked here you've never responded to... can we bring this back to life or should I just close it for now? |
Hey @joshgoebel, sorry I completely forgot about this PR. I'm going to have a look to read the conversation (again) and address the questions. |
I'm thinking this was incorrectly flagged "good first issue" LOL. 😐 |
I think the latest snaps look fine. I think perhaps we should rename this "GitHubish" though LOL. |
It's the same color as default. |
And is this technically a breaking change? 🤔 |
It might be since it's a rather substantial change. |
Yeah, we'll merge it after 10.7. |
Are we considering this good to go now then? |
Yes, I would think so. |
👍 for continuous improvements. There's no way we'd be able to get perfection (even if postponed) here without a lot of effort. GitHub.com This PR GitHub.com C# This PR This inaccuracy is partly because of the C# grammar (i.e. the
Enough of a breaking change to warrant a merge for 10.7. |
Since it looks so different I figure it doesn't hurt to just save it for 11. I want to push 10.7 soon, so it won't wait too long to get merged. |
Resolves #1616
As mentioned in the issue above, the GitHub-theme has not been updated since 2015 and is quite out of date.
The GitHub Gist theme has been updated and (since GitHub and Gist now share the same) looks closer to GitHub's current design, but not entirely.
The screenshots below show the old and new GitHub theme. There are some minor differences as GitHub uses more granularity for some cases (splitting number and unit in CSS) and different classifications across languages for tokens than HLJS.
Old GitHub theme
New GitHub theme
GitHub (for comparison)
Changes
Checklist
Added markup testsN/A, theme only changeCHANGES.md
AUTHORS.txt
, under Contributors