Big Array lists bug with Lua or JavaScript syntax


Atom does not correctly display a comma separated string list if it has more than 20 values. For example:

Orden_tallas = {‘XS’,‘S’,‘M’,‘L’,‘XL’,‘XXL’,‘3XL’,‘4XL’,‘34’,‘35’,‘36’,‘37’,‘38’,‘38/40’,‘39’,‘40’,‘41’,‘42’,‘42/44’,‘44’,‘46’,‘46/48’,‘48’,‘50’,‘50/52’,‘52’,‘54’,‘54/56’,‘56’,‘58/60’,‘85’,‘85B’,‘85C’,‘85D’,‘90’,‘90B’,‘90C’,‘90D’,‘95’,‘95B’,‘95C’,‘95D’,‘100’,‘100B’,‘100C’,‘100D’,‘105’,‘105B’,‘105C’,‘105D’,‘110’,‘110B’,‘110C’,‘110D’,‘115’,‘115B’,‘115C’,‘115D’,‘120’,‘120B’,‘120C’,‘120D’,‘125’,‘125B’,‘125C’,‘125D’,‘130’,‘130B’,‘130C’,‘130D’,‘135’,‘135B’,‘135C’,‘135D’}

It correctly display from ‘XS’ (first value) to ‘50’.Then it considers the rest of the text to be an string and so it colorises any text input as if it where an string.


Enable tree-sitter parsers in Settings ➔ Core to fix JS. The Lua fix will need someone to write a tree sitter grammar for Lua.

Alternatively, line breaks will fix it.


The default language highlighter has a built-in cutoff before it stops highlighting a particular line, and the fact that you’re making a list with a bunch of different values means that it hits the limit pretty quickly. The cutoff was put in place for performance reasons, since first-mate's regex engine gets extremely taxing on large files or files with very long lines. The tree-sitter work is currently bleeding edge and opt-in, but the different methods used to parse the files allow for a much smoother process that doesn’t have to be as stingy about how much data it accepts.


tree-sitter option works ok for JavaScript syntax! Now looking for a solution in Lua syntax…


The package grammar-token-limit allows you to specify the “give up” number of matches per line. I believe 300 should be reasonable, while still performant.