Automatic language detection?

  • Nobody/Anonymous

    Based on the text file name extension, shouldn't N++ automatically recognize and use the
    appropriate language and syntax highlighting?  It works OK at home, but not at my work place.
    I have two user defined languages: eBridge (*.map) and eBridgeReport (*.prn).  At home, when I open these files, they are recognized and the proper language and syntax highlighting settings are used. When I try it at work, it s treated as plaon text, unless I manually change the language to one of my two custom settings.  Any suggestions?  Thanks!

    • jbiwer

      jbiwer - 2007-02-28

      Yes, that is it.  Thanks, THANKS, thanks (etc.)...

    • Nobody/Anonymous

      I'm having the same problem.  I've defined my own user markup and set the extension to .txt+ but when I open .txt+ files (which are associated with N++) they default to "Normal Text".  I'm assuming the correct markup can be automatically used based on file extension but I must be missing something.

      Also, and perhaps related, is the issue that under the "New Document" settings, you can pick your default language but only one option is given for "User Defined" rather than a list of the existing user defined definitions.  Even when I set it to User Defined, it still defaults to Normal Text anyway.

      Can someone please help me out with this?  TIA!

    • Nobody/Anonymous

      I have the same problem (or lack of understanding). I have added
      Autohotkey .AHK language and when I open such a file, the language
      is not recognized. I manually go to the Language menu and select
      Autohotkey from the list. It then works perfectly, but automating
      this would be nice.

      • Nobody/Anonymous

        I fixed my problem. In userDefineLang.xml I needed to specify
        all the possible extensions I use (I added AHK to ahk):

        <UserLang name="AHK Autohotkey" ext="ahk AHK">

        I did not realize this is case-sensitive. I find it
        unnecessary on non-unix platforms. No Windows app
        cares about the file name case. It *preserves* the
        case, but does not treat them differently in any way.


Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

JavaScript is required for this form.

No, thanks