If I have unsaved documents open and try to shut down Windows, it takes too long to do it, or simply crashes with ntoskrnl blue screen. When I get back to Windows, backup files of those unsaved documents are corrupted beyond repair.

I’ve just lost one-year work in other program happened to be running when the crash took place, supposedly because of this behavior.

I’m using Notepad++ 7.7.1 64-bit on Windows 8.1.

Sorry if this kind of bug already asked before (but after searching for a while I didn’t think there was anything similar). Sorry for my English.

Function list for perl (.pl and .pm files) does not work in 7.7.1 release

It works for me. Maybe start a new topic (*) in the Help Wanted, providing example code (++) (embedded, so we can easily copy/paste) and a screenshot showing it not working – along with an explanation of what in the screenshot isn’t working. With some back and forth, we may be able to help you get it working…

*: I suggest in a new topic, because I think there will be quite a few rounds back and forth between us, and don’t want to clutter this thread with a more-involved debug/help session

++: if you need help with Markdown in this forum, so that your example text and screenshots render correctly, please see @Scott-Sumner’s post in the “how to markdown code on this forum” topic, and my updates near the end, which will show how to embed example text, and how to embed pictures.

sn’t the very next Notepad++ release going to bump Scintilla

I don’t follow the commit progress in the NPP code repo, so I wouldn’t know. But if it does, that’s quite promising, especially if they keep on updating Scintilla with most NPP releases.

Isn’t the very next Notepad++ release going to bump Scintilla to 4.20 from 4.15 (take my numbers with a grain of salt as they are off the top of my head without any checking)? [So, maybe no reason to be Scintilla-pessimistic just because the recent-to-mid history of Notepad++ had it going a long time without this type of upgrade] ;)

f I submit this lexer to the Scintilla project, would Npp add it as an internal language fairly soon?

Unfortunately, not unless your definition of “fairly soon” is “within the next 2-5 years”, which was the approximate gap before the most-recent major Scintilla upgrade. Now that it’s back in modern scintilla, it should be easier to upgrade Scintilla more regularly (assuming they do mostly bug fixes, and not major feature-suite changes), but it’s not guaranteed that the development team will stay on top of that.

There’s still no good reason to not submit your lexer to Scintilla, once you get it compatible with modern Scintilla.

Awesome! Not that you have to do extra work, but that you’re still maintaining your plugins.

Hi, Michael. Yes, you have found the current gedcomlexer plugin - 32-bit only.

The last maintenance was in January 2017, so it will be a bit painful to get back up to speed with the code. Back then, I had made a ticket to remind me to release an x64 version. At that time the Npp Plugin Manager was in a state of flux, so it never got done, but I’ll include that now.

I’ve noticed that Npp occasionally adds languages from the Scintilla project, from SciLexer.dll. If I submit this lexer to the Scintilla project, would Npp add it as an internal language fairly soon?

Since I am the maintainer of the plugin, it looks like I have some work to do

Awesome! Not that you have to do extra work, but that you’re still maintaining your plugins. I see it available in the old Plugin Manager, but not the new Plugin Admin and I only see a 32-bit version. Is this it?:

https://sourceforge.net/projects/gedcomlexer/files/GedcomLexer-0.3.3-r100/

While you’re making improvements / updates, If you can:

• make it 64-bit compatible and provide a VS Studio solution for both 32-bit (which you already have as Release|x86) and add 64-bit (Release|x64)
• package it for Plugin Admin

You should probably contact the maintainer of gedcomlexer.dll and see if they think their DLL needs upgrading to work with Notepad++ v7.7 / Scintilla v4.14 and beyond.

Thanks Peter for your explanation. Unfortunately, it is the response I expected. Since I am the maintainer of the plugin, it looks like I have some work to do :)

gedcomlexer plugin

I do not know the details of that plugin. However, there was a change in the underlying scintilla (which is what the lexers interact with) between v7.6.6 and v7.7: scintilla was updated from v3.56 to v4.14; this changed how some plugins and lexers interact with scintilla, though I hadn’t heard of any that just slowed down signficantly. It may be that the gedcomlexer.dll will need to be updated to be more fully-compatible with scintilla v4.14. You should probably contact the maintainer of gedcomlexer.dll and see if they think their DLL needs upgrading to work with Notepad++ v7.7 / Scintilla v4.14 and beyond.

Syntax highlighting for GEDCOM files depends upon the gedcomlexer plugin. The same version of the plugin was used for these tests with Npp 7.6.6, 7.7 and 7.7.1.

Is this an issue for Notepad++ or the plugin?

My configuration follows …
Notepad++ v7.7.1 (32-bit)
Build time : Jun 16 2019 - 21:14:50
Path : C:\Program Files (x86)\Notepad++\notepad++.exe
Admin mode : OFF
Local Conf mode : OFF
OS : Windows 10 (64-bit)
Plugins : gedcomlexer.dll mimeTools.dll NppConverter.dll NppExport.dll

I cannot re-install the plugins because the plugin manager is gone too.

Plugin Manager is gone because it is not compatible with v7.6 or newer. Use the Plugins Admin, the new official built-in method of installing plugins, below the line in the Plugins menu, near the bottom.

My plugins are located in the Notepad++\plugins folder, not in separate directories.

Then they won’t work in Notepad++ v7.7.1. You either need to create the separate subfolders yourself and move the DLLs into those folders, or you need to use the Plugins Admin to install the plugins again.

I’ll try reinstalling and let you know if that works.

Installing Notepad++ again won’t move your plugins for you. See my second sentence in my previous paragraph.

Such as?

Notepad ++ files erro " null null null "

I’m sorry for your loss.

This is much less common with recent versions. Are you using Notepad++ v7.7.1 (the newest version)? If so, then the bug needs to be reported and investigated here. If not, see the “advice” section, below

debugging issue

If you are using v7.7.1, please confirm this by going to the ? menu, selecting Debug Info and Copy debug info into clipboard and paste it here.

otherwise, it’s not a problem with v7.7.1, and you should follow the advice below and possibly open a new thread in Help Wanted section if you think your circumstances are different than mentioned below and in linked files

advice

Advice for recovering files has been given lots of times in this forum, including https://notepad-plus-plus.org/community/topic/17302/notepad-shows-null-null-after-crash/3. Search for “null crash” using the forum search to find others. The usual locations for backups are %appdata%\notepad++\backup, which will only be populated if you had enabled **Settings > Preferences > Backup > ** ☐ Enable session snapshot and periodic backup and if the crash occurred when the data had not been saved to disk. If you enabled ☐ Simple or ☐ Verbose in Settings > Preferences > Backup >, it will be either as .bak in the file’s current directory, or .\nppBackup\___.bak, or in whatever directory you defined as the custom backup directory. If you did not have backup-on-save enabled already, or if you didn’t have periodic-backup enabled on an unsaved file, nothing you can do now will fix that. There are file recovery utilities that exist, which can be found in other threads by searching.

Once I get time, I will try to create a PR to make command line flag is case insensitive. Hope that may come in next release, if @donho likes.

I’ve deployed many Notepad++ versions using the “/s” (lower case) switch without issues. I understand that the switch is supposed to be “/S” (upper case) and that this is by design, but up until version 7.7.1, it has always worked using the lower case switch, so I still feel that something has changed in this version. Anyway, I’m happy to use the upper case switch from now on.

@SinghRajenM That did the trick. Thanks!

@MichielOverweel , Thank you! Glad to know that it helped you. Just for your reference, actually it is not a trick, but nsis installer design behavior.

From Nsis developer reference doc
There are several methods to make an installer or an uninstaller silent:

1. SilentInstall and SilentUninstall
2. SetSilent
3. Passing /S on the command line (case sensitive)

However, (from developer perspective) there are ways to make /S flag case insensitive (e.g. parse command line parameters and take care of /S or /s). Even in most of commercial s/w (at least which I developed or worked upon), command line flag is case insensitive.

Once I get time, I will try to create a PR to make command line flag is case insensitive. Hope that may come in next release, if @donho likes.