With the added support of translation files the current implementation of language detection isn't anymore enough, as a file extension could be used for different usage. So SourcePrinter::selectLanguageClass always decide that file extension *.ts means typescript, but it could be now also markup (as it as qt translation file). This leads to interesting coloring of the file - and tons of useless html tags

       

      There are different possibilities to fix this:

      • The IssueParser within AnalysisModel could store the language and the WNG plugin matches it to the available prism languages (e.g. xml => markup). So the language decision could be overwritten by the parser
      • Add option in Jenkins settings to adjust the file extension mapping. This could be useful as the mapping is already incomplete (e.g. glsl is supported by Prism, but not by the plugin)
      • Add this options not globally, but per project.
      • Add language auto detection
         

      First option would be a fix without the need the user has to do sth. Second & third has the benefit that further languages could be added. 

      As we have a lot of different jobs for the same project second option would be best for us, but in case Jenkins is used for different projects (e.g. a Qt C++ project and a Typescript project) third option may be better. An combination would also be an option (e.g. create globally different named file mapping and within the call to recordIssue you reference one of the named mapping).

          [JENKINS-64584] Wrong language for syntax highlighting

          Ulli Hafner added a comment -

          Adding language auto detection would also be a way to go, see https://github.com/PrismJS/prism/issues/1313. This should be feasible in a Java class as well, I'm not sure if there are libraries available that can do this.

          Ulli Hafner added a comment - Adding language auto detection would also be a way to go, see https://github.com/PrismJS/prism/issues/1313 . This should be feasible in a Java class as well, I'm not sure if there are libraries available that can do this.

          sunblack added a comment -

          Auto detection would be even more nice, but not sure if is a good idea due to performance reasons (when doing it during the analysis phase it could be really expensive when you are doing it for hundreds of files and doing it when needed for rendering, it could could maybe slow down the loading time of the page).

          I didn't found an still supported project for Java, but [for Python|https://guesslang.readthedocs.io.|https://guesslang.readthedocs.io]./] As you can see they are saying they have "only" 90% accuracy. Compared to the knowledge which language each parser supports, it is low (e.g. we know that CppCheck only supports Cpp/C-Like, TSLint only TypeScript).

           

          So maybe it would make currently most sense to use this knowledge:

          • In case the parser supports only a language, set a value to it
          • In case the parser supports doesn't know the languages, set the language to auto-detection => current file extension detection until there is a better way.

           

          In general I believe it is enough to set the language at the Parser and not per Issue. For transition auto-detection should be default.

          sunblack added a comment - Auto detection would be even more nice, but not sure if is a good idea due to performance reasons (when doing it during the analysis phase it could be really expensive when you are doing it for hundreds of files and doing it when needed for rendering, it could could maybe slow down the loading time of the page). I didn't found an still supported project for Java, but [for Python| https://guesslang.readthedocs.io .|https://guesslang.readthedocs.io]./] As you can see they are saying they have "only" 90% accuracy. Compared to the knowledge which language each parser supports, it is low (e.g. we know that CppCheck only supports Cpp/C-Like, TSLint only TypeScript).   So maybe it would make currently most sense to use this knowledge: In case the parser supports only a language, set a value to it In case the parser supports doesn't know the languages, set the language to auto-detection => current file extension detection until there is a better way.   In general I believe it is enough to set the language at the Parser and not per Issue. For transition auto-detection should be default.

          Ulli Hafner added a comment -

          We also need to select carefully the languages to include. Not all languages are already part of the prism.js dependency.

          Ulli Hafner added a comment - We also need to select carefully the languages to include. Not all languages are already part of the prism.js dependency.

          Ulli Hafner added a comment -

          There is now a new JS library: https://github.com/teknologi-umum/flourite

          If someone wants to try...

          Ulli Hafner added a comment - There is now a new JS library: https://github.com/teknologi-umum/flourite If someone wants to try...

            Unassigned Unassigned
            sunblack sunblack
            Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

              Created:
              Updated: