Thank you for your reports.

Both issues of your reports are fixed in the RC2:
https://community.notepad-plus-plus.org/topic/20534/notepad-v7-9-2-release-candidate-2

Could you confirm if the issues you reported have been fix in RC2 please?

https://notepad-plus-plus.org/download/

I can reproduce it by double-clicking on “download”. It’s a regression definitely.
Thank you for your report, I’ll try to fix it in the short term.

Isn’t that the desired behavior? I mean, if you’ve modified any of the files, you wouldn’t want the install to overwrite those mods, right?

No, it should work as described in #9134 by donho:

"The new behaviour of loading function list will be:

1. For the installer package:
   Try to load from %APPDATA%\Notepad++\functionList, if it failed, then load from %PROGRAMFILES%\Notepad++\functionList.
   In this way, users can override function list in %APPDATA%\Notepad++\functionList\ manually. Otherwise, function list won’t be empty."

If the folder %ProgramFiles%\Notepad++\functionList with xml files exists, the installation of Notepad++ 7.9.2 RC does not replace any existing xml files.

Isn’t that the desired behavior? I mean, if you’ve modified any of the files, you wouldn’t want the install to overwrite those mods, right?

If the folder %ProgramFiles%\Notepad++\functionList with xml files exists, the installation of Notepad++ 7.9.2 RC does not replace any existing xml files.

Notepad++ v7.9.2   (64-bit)
Build time : Dec 25 2020 - 20:53:05
Path : C:\Program Files\Notepad++\notepad++.exe
Admin mode : OFF
Local Conf mode : OFF
OS Name : Windows 10 Home (64-bit) 
OS Version : 1909
OS Build : 18363.1256
Current ANSI codepage : 1252
Plugins : mimeTools.dll NppConverter.dll NppExport.dll 

Best Regards.

One more point :

If we consider the wrong links of my previous post :

ttps://notepad-plus-plus.org/download

ttps://ftp.opera.com/ftp/pub/opera-developer

ttps://notepad-plus-plus.org

• With the v7.9.2 and v7.9.1 versions these links are not considered as valid ( no highlighting ), which is expected !

• With the v7.9 version and versions before, these links were considered as valid but, of course, not functional !

@alan-kilborn :

I redid the test with the v7.9.2 version and the link    https://notepad-plus-plus.org

It still does not work, whether :

• I use leading tabulation or space characters or not

• I use the Word wrap option or not

• I use the Show All Characters option or not

It just selects the word org ! Adding a final / to that link does help and make the link functional ;-))

Cheers,

guy038

P.S. :

If I add the dot . as a word character in Preferences... > Delimiter > Word character list > Add your character as part of word, a double-click on part org of https://notepad-plus-plus.org, does not work, too and, then, selects the part plus.org !

Clicking on the part download of    https://notepad-plus-plus.org/download

Clicking on the part developer of    https://ftp.opera.com/ftp/pub/opera-developer

Clicking on the part org of    https://notepad-plus-plus.org

does not forward the URL

For me, the first TWO do NOT work, but the last ONE works indeed (success when double-clicking the trailing org section). Here’s my info if it matters:

Notepad++ v7.9.2 (32-bit)
Build time : Dec 25 2020 - 21:02:37
Path : C:\blahblahblah\notepad++.exe
Admin mode : OFF
Local Conf mode : ON
OS Name : Windows 10 Enterprise (64-bit)
OS Version : 1809
OS Build : 17763.1577
Current ANSI codepage : 1252
Plugins : mimeTools.dll NppConverter.dll NppExport.dll PythonScript.dll

@deus-ex :

Incomprehensible ! I have done the same tests as before and, indeed, I confirm everything you say, namely :

• Clicking on the part download of    https://notepad-plus-plus.org/download

• Clicking on the part developer of    https://ftp.opera.com/ftp/pub/opera-developer

• Clicking on the part org of    https://notepad-plus-plus.org

does not forward the URL :-((

In all these cases the double-click just acts as a selection of the greatest range of characters between non-word characters, which would be identical to clicking on the same locations in the text below, where no link occur because of the missing leading letter h :

ttps://notepad-plus-plus.org/download

ttps://ftp.opera.com/ftp/pub/opera-developer

ttps://notepad-plus-plus.org

Now, as soon as you add a / at the end of the links, everything works as expected, again !

Cheers,

guy038

P.S. :

As I still use N++ v7.8.5, while writing my previous post, I should have wrongly switched on this version for some tests !

Thank you for joining the discussion. I’m on Windows 10 Pro 64-bit, running NPP 64-bit, Firefox 64-bit v85 beta release stream.

I just checked the setting you mentioned, it doesn’t make any difference for me if set to on or off, the described behavior remains the same. I also tried NPP without any plugin and no individual theme, but that doesn’t change the situation either.

I just noticed that for URLs composed like the example below, clicking the part after the last dash won’t do anything, clicking anything before the last dash, including the last dash, opens the URL in your browser.

Example:
https://ftp.opera.com/ftp/pub/opera-developer

Similar issue with dots (example below). Clicking the part after the last dot won’t work, everything before including the dot works.

Example:
https://notepad-plus-plus.org

I have two separate installations of NPP that I can easily switch between, v7.9,1 and 7.9.2 RC. With NPP v7.9.1, the issues described are not present, all URLs are fully working as intended.

@deus-ex, I cannot reproduce your issue. I’ve just tried and the link :

https://notepad-plus-plus.org/download

works, clicking at any location ( before or after the word download ) , both, with the two options :

• Preferences... > Cloud & Link > Clickable Link Settings > Enable fullbox mode enabled

• Preferences... > Cloud & Link > Clickable Link Settings > Enable fullbox mode disabled

I have a Firefox browser ( version Firefox ESR 52.9.0, not updated cause XP ! )

Notepad++ v7.9.2   (32-bit)
Build time : Dec 25 2020 - 21:02:37
Path : D:\@@\792\notepad++.exe
Admin mode : OFF
Local Conf mode : ON
OS Name : Microsoft Windows XP (32-bit) 
OS Build : 2600.0
Current ANSI codepage : 1252
Plugins : mimeTools.dll NppConverter.dll NppExport.dll 

Best Regards,

guy038

@donho said in Notepad++ 7.9.2 RC:

I will do a RC2 later (or I will just do a release with this fix if there’s no other critical issue found).

The URL parser is partially broken. It does not forward an URL to your internet browser when clicking the part of an URL after the last slash.

Example:

https://notepad-plus-plus.org/download

When clicking on any part of the word ‘download’ of this URL, NP++ v7.9.2 RC doesn’t forward it to the browser. But clicking on any part before the word ‘download’, including the last slash, works as intended.

Adding a slash to the end of the URL (example below) makes NP++ v7.9.2 RC forward the URL again when clicking on ‘download’.

https://notepad-plus-plus.org/download/

The previous release of NP++ v7.9.1 does not have this issue.

Pleased to know that this new formulation of Normal text should not have any influence in scripting ! I just had this fear as the strings are different in XML configuration files !

Cheers,

guy038

notepad.getCurrentLang() returns Npp.LANGTYPE.TXT (that is, no ‘string’ is involved).

Well, I did more looking and I did find an “involved” string, and it can be seen by executing this Pythonscript command at the console:

notepad.getLanguageName(notepad.getLangType())

In 7.9.1 and 7.92RC the same string results (shown below for 7.92RC); not sure where exactly this all originates, but I think that it shows @guy038 's fears were groundless?

I unzipped a 7.9.2 portable package but cannot reproduce the result shown in the video: https://www.youtube.com/watch?v=9IgsUYkh7mY&feature=youtu.be&ab_channel=7GOLEM7

Ok, it’s good!

Trifle:
You can think of something?

What do you mean ?

Auto-indent - slightly increase size of box. ))
And maybe add a clarifying description, about new line?

I did not find bugs, so I am writing about ergonomics. Sry!

in the previous releases, normal text was encoded as lang=“Normal Text”, in the XML configuration files. Now, of course, it’s encoded as lang=“None (Normal Text)”. So, I suppose that Python, Lua or NppExec scripts which attempt to verify if the language of current file is a simple text file will have to get the new spelling for normal text !

@donho said:

Since I don’t script (or very rarely) in Notepad++, I didn’t consider on this side. What’s your suggestion then?

At least in Pythonscript, I don’t think there is any implication anyway:

notepad.getCurrentLang() returns Npp.LANGTYPE.TXT (that is, no ‘string’ is involved).

Perhaps the text that was changed is involved in some other way, but I don’t know it.

Since I don’t script (or very rarely) in Notepad++, I didn’t consider on this side. What’s your suggestion then?

I DO script, a lot. I suggest doing nothing.
A change was made for the betterment of the Notepad++ core software – Nice.
Scripts that depend upon previous behavior will simply have to change to rely on the new behavior.
Not everything needs to be “backward compatible”.

The link, concerning point 5., does not work because of a # character inside it. The correct link is :

Fixed. Thank you for your heads up.

Indeed, I suppose that it must not be as simple as IF lang = “None (Normal Text)”, written in a pseudo-language way !

Since I don’t script (or very rarely) in Notepad++, I didn’t consider on this side. What’s your suggestion then?

In the Shortcut Mapper…, I suppose that we should change the names 91 - Character Panel and 92 - Clipboard History as Toggle Character Panel and Toggle Clipboard History , to be consistent with the other Toggle entries !

Done in https://github.com/notepad-plus-plus/notepad-plus-plus/commit/413762c393879cf28b29d4973852f392be214a09

I will do a RC2 later (or I will just do a release with this fix if there’s no other critical issue found).

It’s just because the default behaviour is “fill find field”, and this option was added for people who don’t wanna fill this field.

Understood. But it is still awkward (because it makes one have to think too hard about it). But we accept it. :-)
Maybe it is only an English speaker’s perspective?
Anyway, I’d say in the future for new checkbox options, it is best if they aren’t defined in the negative sense.

It is awkward the way it is, with seemingly no reason for it to be that way.

It’s just because the default behaviour is “fill find field”, and this option was added for people who don’t wanna fill this field.

@Artur-Harison

On first launch, after searching, the field results is collapsed.

I unzipped a 7.9.2 portable package but cannot reproduce the result shown in the video: https://www.youtube.com/watch?v=9IgsUYkh7mY&feature=youtu.be&ab_channel=7GOLEM7

Trifle:
You can think of something?

What do you mean ?

One more thing :

• In the Shortcut Mapper…, I suppose that we should change the names 91 - Character Panel and 92 - Clipboard History as Toggle Character Panel and Toggle Clipboard History , to be consistent with the other Toggle entries !

Cheers,

guy038

Many thanks for this new release with, again, a lot of changes. It’s really a very nice Christmas gift !

Of course, this list is quite subjective but many points seem important : 1, 2, 8, 9, 11, 14, 15, 25, 26, 28, 30, 32, 33, 34, 36 and, probably, 19 and 20 for people using RTL text writing !

Two remarks :

• The link, concerning point 5., does not work because of a # character inside it. The correct link is :

https://github.com/notepad-plus-plus/notepad-plus-plus/issues/8983

• Regarding point 9., in the previous releases, normal text was encoded as lang="Normal Text", in the XML configuration files. Now, of course, it’s encoded as lang="None (Normal Text)". So, I suppose that Python, Lua or NppExec scripts which attempt to verify if the language of current file is a simple text file will have to get the new spelling for normal text !

Indeed, I suppose that it must not be as simple as IF lang = "None (Normal Text)", written in a pseudo-language way !

Best Regards,

guy038

It’s just a preference:
1 - Don’t fill find field in Find dialog with selected word option make it inverted.
Fill find field in Find dialog with selected text and flagged by default.

I agree with this.
It is awkward the way it is, with seemingly no reason for it to be that way.
BUT…it isn’t a new thing with 7.9.2, it is old.

On first launch, after searching, the field results is collapsed.

If I’m understanding correctly what the problem is, it doesn’t happen for me, which makes me think I truly don’t understand. Can you say a bit more about this problem and how to reproduce it?

2 - On first launch, after searching, the field results is collapsed.

Trifle:
You can think of something?

ps
Thanks for RC. )))