Uploaded image for project: 'Jenkins'
  1. Jenkins
  2. JENKINS-64584

Wrong language for syntax highlighting

    XMLWordPrintable

    Details

    • Similar Issues:

      Description

      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).

        Attachments

          Activity

          Hide
          drulli 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.

          Show
          drulli 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.
          Hide
          sunblack 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.

          Show
          sunblack 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.
          Hide
          drulli 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.

          Show
          drulli 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.

            People

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

              Dates

              Created:
              Updated: