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!
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
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!
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
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.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
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.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
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!
Yes, that is it. Thanks, THANKS, thanks (etc.)...
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!
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.
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.