Regexes should have priority over strings, ids, numbers and operators because it will define custom rules to the parser.

At the moment, it has one of the lowest parser priorities. https://github.com/github-aux/linguist-unknown/blob/chrome/src/scripts/ling-highlighter.js#L298

The highlighter is sometimes generating the folowing code

<span style="color:#969896;">/* comment */</span>
<span style="color:#FF8272;">  ==== </span>
<span style="color:#FF00FF;">if</span>
<span style="color:#FF8272;"> </span>
<span style="color:#FF99FF;">huhdufd</span>
<span style="color:#FF8272;"> </span>
<span style="color:#FF00FF;">let</span>
<span style="color:#FF8272;"> </span>
<span style="color:#FF99FF;">fdjijfdf</span>
<span style="color:#FF8272;"> == !!!!! </span>
<span style="color:#72EEBB;">while</span>
<span style="color:#FF8272;"> </span>
<span style="color:#72EEBB;">for</span>
<span style="color:#FF8272;"> </span>
<span style="color:#FF00FF;">let</span>
<span style="color:#FF8272;"> </span>
<span style="color:#72EEBB;">for</span>
<span style="color:#FF8272;"> </span>
<span style="color:#72EEBB;">for</span>
<span style="color:#FF8272;"> </span>
<span style="color:#72EEBB;">for</span>
<span style="color:#FF8272;"> </span>
<span style="color:#FF99FF;">rfrereer</span>
<span style="color:#FF8272;"> ===</span>

If you check it again, you'll find many times the following code <span style="color:#FF8272;"> </span>. This behavior is a bug as empty spaces should be inserted into the nearest span (left or right)

Method getLiteralString is not able to parse incomplete strings,
such as: "this is a non-closed string

Travis error: https://travis-ci.org/github-aux/linguist-unknown/jobs/241995488

We today only have support for multiline comments and would be good that we added that to the rules, so languages with multiline tokens may be supported.

see image below:

We will need to reimplement the function getNumber inside the Highlighter. There's a bug going on https://github.com/github-aux/linguist-unknown/blob/development/src/scripts/ling-highlighter.js#L150

The tests are failing when we try to parse a number at the index 6 for the input ******1_1_1_BLAH111******. It should return 1, but it is returning 1_1.

It also seems that the isNumber function is not recognizing numbers started with + or -, such as -9 or +1. Update: the parser will not recognize these kind of numbers in order to reduce its ambiguity. The user then will need to create their own rules for that

Travis error: https://travis-ci.org/github-aux/linguist-unknown/jobs/241995488

• Search where to advertise
• Make a proper plan such as creating a Github page or writing an article about it. See the best days to post on Social Media as well.
• Take one day to post in all searched social media websites. Make sure to not post in different hours, once we want to get as many stars as possible to enter on Github trending.

DownloadHelper

• YAML should be downloaded and parsed properly.

Utilities

• Method tryMatchUrlExtension should callback a function with a single Language object.
• Check if method getPossibleFilepath is returning an appropriate url.
• Check if method refresh is drawing properly (if possible)

Token

• Check if tokens are being created properly // it will be checked on the lexer

Highlighter

• Check functions: openSpan, closeSpan and getSpan
• Check function isId
• Check function isNumber
• Check function isLiteralString
• Check function startsWith
• Check function matchRegex
• Check function getId
• Check function getNumber
• Check function getLiteralString
• Check function getMultilineComment
• Check if function lexer is producing the tokens according to the Language object. // Check the 'Token' item once it is done
• Check if function paint is producing the right span colors, according to the Token list
• Check function draw, if possible

Bootstrap

• Test the chrome variables, if possible

.linguist.yml

• Create tests with many languages testing all properties of the Language object, if possible

Obs.:

I am not sure if it will be possible to reproduce all tests, thus I am mentioning if possible in the bullet points, meaning that we will check the viability to do so. If not possible, we will just check the bullet point normally (it won't be implemented)

Check the folders' names and final tree structure before release v1.0

Airbnb Javascript Guidelines

• Read and understand guidelines
• Implement guidelines for popup.js(Chrome)
• Implement guidelines for ling-bootstrap.js(Chrome)
• Implement guidelines for ling-loader.js
• Implement guidelines for ling-highlighter.js

Chrome

• Generate .min.js files on chrome branch
• Create tag v1.0-chrome on chrome branch
• Upload chrome extension for tag v1.0-chrome

Firefox

• Generate .min.js files on firefox branch
• Create tag v1.0-firefox on firefox branch
• Upload firefox add-on for tag v1.0-firefox

The try-catch on https://github.com/github-aux/linguist-unknown/blob/chrome/src/scripts/ling-loader.js#L13 is always printing a console error when the status of a XMLHttpRequest is 404

According to here, here and here says that "Unfortunately, our browser vendors don't allow us to suppress network errors in 2016.". It seems to be still the same in 2017. However, there is a workaround such as having a proxy between the script and the server.
For now, though, I will leave it here for a future discussion. Should that be considered a known bug or an expected behavior?

• Create Firefox branch
• Study and implement Firefox add-on
• Create Chrome's equivalent manifest.json
• Implement popup.js
• Implement ling-bootstrap.js
• Run tests

I believe we should do some refactoring for the .linguist.yml file.

We can keep the keyword grammar and organize it more or less like:

We could also implement something like operator overload with a keyword pattern, for exemple:

pattern:
  id: regex
  number: regex