Notepad++ 8.4.2 not recognizing file extension to define language
-
@pallieguy said in Notepad++ 8.4.2 not recognizing file extension to define language:
any saved sessions keep the language I’ve identified.
Indeed, that is the way it works. The session files track the Language selected for each file – so that way if you’ve manually selected a language for a file, it will keep it from run-to-run as long as you don’t close the file in Notepad++. And if you had saved a separate session file (File > Save Session…) then that UDL information was saved in that file, so any time you load that session file, it will keep that UDL information with the file. Other
*.php
files, and any file like thephp.misnamed
which starts with<?php
will determine the type as PHP when you do the File > Open on them; but if you have a PHP file in a session and had saved that session with something other than PHP selected, it will remember that. Resave your session now thatdemo.php
is identified as a PHP, and your problem will not come back to haunt you. -
Hello
I recently had a similar “issue” with other type of source files and only if I open the file from file explorer and not from File->Open.
For example .py, .md, .txt, .json, etc. files (with extension).
When they are opened from File->Open or File->Recent the language is detected and is correctly visible on the left side of status bar.
When they are opened from file explorer in all cases the language is not detected and in status bar is see the followingI have a couple of UDLs but all mentioned file types-extensions should not be affected.
Notepad++ v8.4.2 (64-bit)
Build time : May 29 2022 - 16:47:30
Path : C:\Users~~\Apps\Notepad++\notepad++.exe
Command Line :
Admin mode : OFF
Local Conf mode : ON
Cloud Config : C:\Users~~\Apps\Notepad++\cloudDir
OS Name : Windows 10 Pro (64-bit)
OS Version : 21H2
OS Build : 19044.1766
Current ANSI codepage : 1252
Plugins :
ComparePlugin (2.0.2)
DSpellCheck (1.4.24)
EnhanceAnyLexer ()
Explorer (1.9.5)
GitSCM (1.4.7.1)
MarkdownViewerPlusPlus (0.8.2)
mimeTools (2.8)
NppConverter (4.4)
NppExport (0.4)
NPPJSONViewer (1.40)
NppXmlTreeviewPlugin (2)
PoorMansTSqlFormatterNppPlugin (1.6.13.31508)
SurroundSelection (1.4.1) -
Given that your status bar shows path or file/machine information in the “file type” section like @Pallieguy showed, I now think you have found something… however, I am not able to replicate it with my installation of Notepad++.
If I use the Windows Explorer and use the double-click action (on file types like
.txt
and.md
, which have their default action set to Notepad++), it loads them up and immediately recognizes the type; and if I use my right-click Edit with Notepad++ action on any file type (those listed, or.py
or.json
, to finish replicating your examples), it also correctly recognizes the type: it does not pick a non-existent UDL and show part of the file path in the status bar.Notepad++ v8.4.2 (64-bit) Build time : May 29 2022 - 16:47:30 Path : C:\usr\local\apps\notepad++\notepad++.exe Command Line : "C:\Users\xxxxx\Downloads\TempData\23148.txt" Admin mode : OFF Local Conf mode : OFF Cloud Config : OFF OS Name : Windows 10 Enterprise (64-bit) OS Version : 20H2 OS Build : 19042.1586 Current ANSI codepage : 1252 Plugins : AutoSave (1.6.1) ComparePlugin (2.0.2) DSpellCheck (1.4.24) EnhanceAnyLexer () ExtSettings (1.2.1) MarkdownViewerPlusPlus (0.8.2) mimeTools (2.8) NppConsole (1.2.4.1) NppConverter (4.4) NppEditorConfig (0.4) NppExec (0.8) NppExport (0.4) NppFTP (0.30.12) NppLspClient () NppUISpy (1.0.4) PreviewHTML (1.3.2) PythonScript (2) QuickText (0.2.4.1) TagLEET (1.3.10.1) _CustomizeToolbar (5.3)
I wonder if there’s some difference in the way our file associations are defined which are causing the difference between your installation’s behavior and mine… Weird. If you can provide more information (how you made your associations, or digging into the registry to show us exactly what those associations look like), it might provide enough hints to make a replicable situation: if we can replicate it and define the exact sequence of events necessary, then we can probably file a bug report about it; but without a way to replicate it, I am not sure that a bug report will get much activity after the first attempt to replicate it fails.
-
@peterjones
I booted up my computer today and I’m now getting the behavior described by @Giannis-Raptis. If I go File > Open it detects the language, if I right click in explorer and select Edit with Notepad++ it detects the language, if I select the file from the recent files section under the File menu it detects the language. The only way it doesn’t is if I double click the file in Windows Explorer.I’ve tried my hardest to avoid dealing with the windows registry. If you can let me know what details you need I’ll gladly get you what I can.
-
Here’s a way to do it where you cannot accidentally write anything: using the command-line REG QUERY which just grabs information from the registry without editing it. (For these instructions, I am assuming that even double-clicking a
*.txt
file is giving this wrong behavior. If not, replace the.txt
below with an extension that double-clicks into Notepad++ but doesn’t identify correctly, like maybe.php
, since that’s what started it all.)Open a command prompt
REG QUERY HKCR\.txt /VE
This will output something like:
HKEY_CLASSES_ROOT\.txt (Default) REG_SZ txtfile
Whatever the text is to the right of
REG_SZ
, use that in the next query:REG QUERY HKCR\txtfile
Share those results with us (use the
</>
button on the forum toolbar to wrap your text in a black box like I did)For example, mine is:
C:\usr\local\share>REG QUERY HKCR\.txt /VE HKEY_CLASSES_ROOT\.txt (Default) REG_SZ txtfile C:\usr\local\share>REG QUERY HKCR\txtfile HKEY_CLASSES_ROOT\txtfile (Default) REG_SZ Text Document EditFlags REG_DWORD 0x210000 FriendlyTypeName REG_EXPAND_SZ @%SystemRoot%\system32\notepad.exe,-469 HKEY_CLASSES_ROOT\txtfile\DefaultIcon HKEY_CLASSES_ROOT\txtfile\shell
Those will give the “old fashioned” file associations, which Windows used prior to Win10 (and still work in Win10 and Win11, though they are moving away from them)
But since @giannis-raptis is on Win10, it might be useful to examine the newer “Open With” storage locations
REG QUERY HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\FileExts\.txt /S REG QUERY HKCR\Applications\notepad++.exe /S
Give us the output to both of those as well
For the record, mine are:
C:\usr\local\share>REG QUERY HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\FileExts\.txt /S HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\FileExts\.txt\OpenWithList a REG_SZ notepad.exe b REG_SZ cabd c REG_SZ EXCEL.EXE d REG_SZ notepad++.exe MRUList REG_SZ dce e REG_SZ chrome.exe HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\FileExts\.txt\OpenWithProgids txtfile REG_NONE HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\FileExts\.txt\UserChoice ProgId REG_SZ Applications\notepad++.exe Hash REG_SZ cK5ueCMWhb4= C:\usr\local\share>REG QUERY HKCR\Applications\notepad++.exe /S HKEY_CLASSES_ROOT\Applications\notepad++.exe FriendlyAppName REG_SZ Notepad++ (Default) REG_SZ Notepad++ Text Document HKEY_CLASSES_ROOT\Applications\notepad++.exe\DefaultIcon (Default) REG_SZ "c:\usr\local\apps\notepad++\notepad++.exe",-100 HKEY_CLASSES_ROOT\Applications\notepad++.exe\shell HKEY_CLASSES_ROOT\Applications\notepad++.exe\shell\open Icon REG_SZ c:\usr\local\apps\notepad++\notepad++.exe,-101 HKEY_CLASSES_ROOT\Applications\notepad++.exe\shell\open\command (Default) REG_SZ "C:\usr\local\apps\notepad++\notepad++.exe" "%1"
And finally, grab
REG QUERY HKCU\Software\Microsoft\Windows\CurrentVersion\ApplicationAssociationToasts
But that’s too big. So paste it into Notepad++, and then run the following replacement on it:
- FIND WHAT:
(?-s)^((?!Toasts|Notepad\+\+\.exe|\.txt).)*(\R|\Z)
- REPLACE WITH: (empty)
- hit Replace All
Then copy/paste the filtered results from Notepad++ into a black
</>
box in your your reply as well. - FIND WHAT:
-
@peterjones
I tried a .txt to see if the language problem persisted and like after the .css yesterday, the language is back to being detected properly for all my files. If it happens again tomorrow I will run these commands and post them while it’s still wonky.First set of commands:
C:\Users\Palli>REG QUERY HKCR\.php /VE HKEY_CLASSES_ROOT\.php (Default) REG_SZ php_auto_file C:\Users\Palli>REG QUERY HKCR\php_auto_file HKEY_CLASSES_ROOT\php_auto_file\shell
Second two:
C:\Users\Palli>REG QUERY HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\FileExts\.php /S HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\FileExts\.php\OpenWithList a REG_SZ firefox.exe b REG_SZ cab c REG_SZ {1AC14E77-02E7-4E5D-B744-2EB1AE5198B7}\OpenWith.exe d REG_SZ dabc MRUList REG_SZ eabcd e REG_SZ notepad++.exe HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\FileExts\.php\OpenWithProgids php_auto_file REG_NONE HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\FileExts\.php\UserChoice Hash REG_SZ 8c5Dq+bAc2A= ProgId REG_SZ Applications\notepad++.exe C:\Users\Palli>REG QUERY HKCR\Applications\notepad++.exe /S HKEY_CLASSES_ROOT\Applications\notepad++.exe\shell HKEY_CLASSES_ROOT\Applications\notepad++.exe\shell\open HKEY_CLASSES_ROOT\Applications\notepad++.exe\shell\open\command (Default) REG_SZ "D:\Notepad++\notepad++.exe" "%1"
Filtered last command:
HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\ApplicationAssociationToasts txtfile_.txt REG_DWORD 0x0 textfile_.txt REG_DWORD 0x0 Applications\notepad++.exe_.sfv REG_DWORD 0x0 Applications\notepad++.exe_.srt REG_DWORD 0x0 Applications\notepad++.exe_.ssa REG_DWORD 0x0 soffice.StarWriterDocument.6_.txt REG_DWORD 0x0 soffice.StarCalcDocument.6_.txt REG_DWORD 0x0 Applications\notepad++.exe_.txt REG_DWORD 0x0 Applications\notepad++.exe_.php REG_DWORD 0x0 Applications\NOTEPAD.EXE_.txt REG_DWORD 0x0 Applications\notepad++.exe_.gcode REG_DWORD 0x0 Applications\notepad++.exe_.pl REG_DWORD 0x0 Applications\notepad++.exe_.css REG_DWORD 0x0 Applications\notepad++.exe_.js REG_DWORD 0x0 Applications\notepad++.exe_.orig REG_DWORD 0x0 Applications\notepad++.exe_.ini REG_DWORD 0x0 Applications\notepad++.exe_.log REG_DWORD 0x0 Applications\notepad++.exe_.fasta REG_DWORD 0x0 Applications\notepad++.exe_.htaccess REG_DWORD 0x0 Applications\notepad++.exe_.cpp REG_DWORD 0x0 Applications\notepad++.exe_.h REG_DWORD 0x0 Applications\notepad++.exe_.cfg REG_DWORD 0x0 Applications\notepad++.exe_.pem REG_DWORD 0x0 Applications\notepad++.exe_.html REG_DWORD 0x0 Applications\notepad++.exe_.json REG_DWORD 0x0 Applications\notepad++.exe_.lock REG_DWORD 0x0 Applications\notepad++.exe_.gitignore REG_DWORD 0x0 AppX4ztfk9wxr86nxmzzq47px0nh0e58b8fw_.txt REG_DWORD 0x0 Applications\notepad++.exe_.test REG_DWORD 0x0 Applications\notepad++.exe_.old REG_DWORD 0x0 Applications\notepad++.exe_.new REG_DWORD 0x0 Applications\notepad++.exe_.xml REG_DWORD 0x0 Applications\notepad++.exe_.bar REG_DWORD 0x0 Applications\notepad++.exe_.htpasswd REG_DWORD 0x0 Applications\notepad++.exe_.env REG_DWORD 0x0
-
I wonder if one of your plugins is causing Notepad++ to have intermittent difficulty in identifying the file type. Weird. If it goes back to happening, share your ?-menu’s Debug Info like @Giannis-Raptis did.
Also, if it happens again, try closing Notepad++ and renaming your
c:\program files\notepad++\plugins
directory (which is one of the steps in this FAQ, which though it claims to be about crashing, is also a general-purpose see-if-plugin-is-causing-problem instruction set; because your problem is only with double-click, you cannot easily use option #1, but option #2 will still work for you) -
This post is deleted! -
@peterjones
I haven’t installed any plugins that I’m aware of, but I’ll try that after posting if it happens again tomorrow.Debug info:
Notepad++ v8.4.2 (64-bit) Build time : May 29 2022 - 16:47:30 Path : C:\Program Files\Notepad++\notepad++.exe Command Line : "D:\Dropbox (xxxx)\xxxx\Coding\xxxx\web\content\submissions\permissionForm\index.php" Admin mode : OFF Local Conf mode : OFF Cloud Config : OFF OS Name : Windows 10 Pro (64-bit) OS Version : 21H2 OS Build : 19044.1766 Current ANSI codepage : 1252 Plugins : mimeTools (2.8) NppConverter (4.4) NppExport (0.4)
-
@pallieguy said in Notepad++ 8.4.2 not recognizing file extension to define language:
I haven’t installed any plugins that I’m aware of
Your Debug Info agrees: you only have the default plugins, which aren’t the culprit.
Well, let us know if the problem comes back.
-
@peterjones
Day three and the same problem. Only difference is I didn’t shut down the computer last night.First commands:
C:\Users\Palli>REG QUERY HKCR\.php /VE HKEY_CLASSES_ROOT\.php (Default) REG_SZ php_auto_file C:\Users\Palli>REG QUERY HKCR\php_auto_file HKEY_CLASSES_ROOT\php_auto_file\shell
Second Set:
C:\Users\Palli>REG QUERY HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\FileExts\.php /S HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\FileExts\.php\OpenWithList a REG_SZ firefox.exe b REG_SZ cab c REG_SZ {1AC14E77-02E7-4E5D-B744-2EB1AE5198B7}\OpenWith.exe d REG_SZ dabc MRUList REG_SZ eabcd e REG_SZ notepad++.exe HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\FileExts\.php\OpenWithProgids php_auto_file REG_NONE HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\FileExts\.php\UserChoice Hash REG_SZ 8c5Dq+bAc2A= ProgId REG_SZ Applications\notepad++.exe C:\Users\Palli>REG QUERY HKCR\Applications\notepad++.exe /S HKEY_CLASSES_ROOT\Applications\notepad++.exe\shell HKEY_CLASSES_ROOT\Applications\notepad++.exe\shell\open HKEY_CLASSES_ROOT\Applications\notepad++.exe\shell\open\command (Default) REG_SZ "D:\Notepad++\notepad++.exe" "%1"
Filtered last command:
HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\ApplicationAssociationToasts txtfile_.txt REG_DWORD 0x0 textfile_.txt REG_DWORD 0x0 Applications\notepad++.exe_.sfv REG_DWORD 0x0 Applications\notepad++.exe_.srt REG_DWORD 0x0 Applications\notepad++.exe_.ssa REG_DWORD 0x0 soffice.StarWriterDocument.6_.txt REG_DWORD 0x0 soffice.StarCalcDocument.6_.txt REG_DWORD 0x0 Applications\notepad++.exe_.txt REG_DWORD 0x0 Applications\notepad++.exe_.php REG_DWORD 0x0 Applications\NOTEPAD.EXE_.txt REG_DWORD 0x0 Applications\notepad++.exe_.gcode REG_DWORD 0x0 Applications\notepad++.exe_.pl REG_DWORD 0x0 Applications\notepad++.exe_.css REG_DWORD 0x0 Applications\notepad++.exe_.js REG_DWORD 0x0 Applications\notepad++.exe_.orig REG_DWORD 0x0 Applications\notepad++.exe_.ini REG_DWORD 0x0 Applications\notepad++.exe_.log REG_DWORD 0x0 Applications\notepad++.exe_.fasta REG_DWORD 0x0 Applications\notepad++.exe_.htaccess REG_DWORD 0x0 Applications\notepad++.exe_.cpp REG_DWORD 0x0 Applications\notepad++.exe_.h REG_DWORD 0x0 Applications\notepad++.exe_.cfg REG_DWORD 0x0 Applications\notepad++.exe_.pem REG_DWORD 0x0 Applications\notepad++.exe_.html REG_DWORD 0x0 Applications\notepad++.exe_.json REG_DWORD 0x0 Applications\notepad++.exe_.lock REG_DWORD 0x0 Applications\notepad++.exe_.gitignore REG_DWORD 0x0 AppX4ztfk9wxr86nxmzzq47px0nh0e58b8fw_.txt REG_DWORD 0x0 Applications\notepad++.exe_.test REG_DWORD 0x0 Applications\notepad++.exe_.old REG_DWORD 0x0 Applications\notepad++.exe_.new REG_DWORD 0x0 Applications\notepad++.exe_.xml REG_DWORD 0x0 Applications\notepad++.exe_.bar REG_DWORD 0x0 Applications\notepad++.exe_.htpasswd REG_DWORD 0x0 Applications\notepad++.exe_.env REG_DWORD 0x0
Possible solution
I find out that if N++ is closed and I open the file through Windows Explorer, then language is detected and everything works, even if I open new files. If I open N++ from my taskbar shortcut (Set by right clicking an open N++ and selecting Pin to taskbar) then double click on the file in Windows Explorer is the only time it seems to not be working. Opening N++ by opening the file in my taskbar also shows a second N++ icon in that taskbar:
Unpinning the old shortcut (originally pinned so long ago I don’t recall which N++ version it was) and pinning the new one Fixed the problem entirely. It may be that enough time has passed for the problem to resolve itself like when I tried the txt and css files, so I’ll have another update tomorrow, but it appears the issue had to do with the shortcut made for an older version of N++.
-
I missed the edit window to correct this, sorry.
Before my taskbar screenshot I meant to say:
Opening N++ by opening a file in Windows Explorer also shows a a second N++ icon in my taskbar: -
@pallieguy said in Notepad++ 8.4.2 not recognizing file extension to define language:
Unpinning the old shortcut (originally pinned so long ago I don’t recall which N++ version it was) and pinning the new one Fixed the problem entirely.
Yeah. I wonder if you still have a residual notepad++ installation somewhere else other than your newly-pinned shortcut.
Actually, your data actually already shows that. Earlier, you were running from
C:\Program Files\Notepad++\notepad++.exe
, as your Debug Info showed. Your REG QUERY output showedHKEY_CLASSES_ROOT\Applications\notepad++.exe\shell\open\command (Default) REG_SZ "D:\Notepad++\notepad++.exe" "%1"
(though I didn’t see it yesterday, because I didn’t scroll far enough in your black box)
So when you double-click when no notepad++ was running, it ran your
D:
-drive copy of Notepad++. If you used your old shortcut, it was apparently running yourC:
-drive copy … and then, because you presumably don’t have multi-instance enabled, when you double clicked, it tried to run theD:
-drive copy, but saw theC:
-drive copy running and opened the file with that instead.Since I believe you pinned the copy that was associated, I believe your pin should now point to the
D:
-drive copy. If so, I would recommend removing theC:
-drive copy, to avoid future confusion. But check your pin to make sure: right click on the pin, then right click on thenotepad++
near the bottom, then select “properties”: the Target field will show which one is now pinned. -
@peterjones
I do indeed have a C: and a D: install, I wonder when I did that?Glad this is resolved, thanks fro all your help!
-
@pallieguy said in Notepad++ 8.4.2 not recognizing file extension to define language:
I wonder when I did that?
Probably at one of the updates: there was a while when the installer would not notice an old installation if it wasn’t in
c:\program files\notepad++
, so even if you had installed toD:\notepad++\
, the updater/installer would put the newer copy inc:\program files\notepad++
instead. IIRC, that has been fixed (I spent a couple minutes searching through the issues list, but wasn’t using a narrow enough set of search terms, so couldn’t find it buried in all the other results), so the next time you run the installer/updater for whatever version you end up keeping, it should hopefully default to the existing location.