Double click links no longer work

Claudia Frank

thank you very much, that is exactly the kind of information which was needed.
I can reproduce it as well and I guess I understand why it happens.
When changing the lexer (by using a different language from menu) the text gets styled newly
and therefore the underline gets removed. When adding a char npp does seem to call the link style again to create it.
Not sure if this can be easily solved but I know what to look for and will open an
issue at github once I find which part needs to be modified.

Cheers
Claudia

mkupper

Is the double-click to follow a link stuff done by npp itself, Scintilla, or the language parsers?

If I have a .htm file where the links are not working and rename it to .txt then npp recognizes and color codes it as HTML and links don’t work. Thus it seems like a glitch related to the HTML language.

I was running v7.3.3 32-bit
Disabled all plugins - no joy.
v7.2 - Works
v7.2.1 - Works
v7.2.2 - Works
v7.3 - Does not work
v7.3.1 - Does not work
v7.3.2 - Does not work
v7.3.3 - Does not work

By “does not work” I mean that links don’t work in .htm files. They work fine in .bat .css, .txt, etc. It looks like they broke starting with v7.3

By links I mean:

file://c:/some/path/to/a/file/or/folder
np://c:/some/path/to/a/file/or/folder np is my own protocol. It runs npp to open the file. I mainly use it in links to .bat and .htm files as I want double click to open the file for editing in npp and not to run the batch script or to open the file in a browser.
http://www.domain-name.com/…
outlook://… Another of my own protocols. It launches Microsoft Outlook in a folder or message.

Normally I can double click a link to view or launch the file.

guy038

Hi, Jean Heck, mkupper and Claudia,

Please, read my post to Don :

https://notepad-plus-plus.org/community/topic/13415/v7-3-3-fix-cia-hacking-notepad-issue/14

Cheers,

guy038

Claudia Frank

@mkupper

Is the double-click to follow a link stuff done by npp itself, Scintilla, or the language parsers?

Not by the parser but by npp and scintilla.
Scintilla does the underlying coloring etc… (basically how it looks like) but
npp needs to trigger it.

Guy already confirmed your findings so do I.

Cheers
Claudia

chcg

Maybe introduced with https://github.com/notepad-plus-plus/notepad-plus-plus/commit/911fd9a7bdade5953302159bfaa066114197e6a1.

The part of the code setting the style for links deals with scintilla deprecated code:

SCI_SETSTYLEBITS(int bits) Deprecated
SCI_GETSTYLEBITS → int Deprecated
SCI_GETSTYLEBITSNEEDED → int Deprecated
INDIC0_MASK, INDIC1_MASK, INDIC2_MASK, INDICS_MASK Deprecated
Scintilla no longer supports style byte indicators. The last version to support style byte indicators was 3.4.2. Any use of these symbols should be removed and replaced with standard indicators. SCI_GETSTYLEBITS and SCI_GETSTYLEBITSNEEDED always return 8, indicating that 8 bits are used for styling and there are 256 styles.

In a lexer specific way and especially html with js is special. See Notepad_plus::addHotSpot() and there

if (type == L_HTML || type == L_PHP || type == L_ASP || type == L_JSP)
	mask = INDIC2_MASK;

I already failed on removing this. Hopefully the issue is not related to that part.

dail

@chcg

Since that was my commit I figured I should check it out.

I used the v7.3.3 and reverted that single commit and it still has the bug, so looks like I’m off the hook :) I’ll do a git bisect and try to track down the commit that introduced it.

dail

Hmmm maybe I spoke to soon…

dail

I’ve opened https://github.com/notepad-plus-plus/notepad-plus-plus/pull/3019 which solves the issue with clicking links in certain file types.

chcg

@dail
thanks for checking it. The thing with the stylebit usage for URL links works, but as the documentation on it is not existing it is hard to deal with it and to understand. Especially as it doesn’t follow the normal scintilla way from my point of view and the embedded stuff in HMTL which is handled different most other lexers.

mkupper

Thank you @dail I think you would have been safe leaving the style variable typed as auto and to change line 924
< if (not notifyView->execute(SCI_STYLEGETHOTSPOT, style))
> if (not notifyView->execute(SCI_STYLEGETHOTSPOT, static_cast<uint8_t>(style)))

It appears there’s a Scintilla bug in that it’s storing the style index bytes as int8_t rather than uint8_t. When a document has more than 127 styles then SCI_GETSTYLEAT, which returns an int, sign-extends the style byte index 128 to 255 into negative values when converting the int8_t into an int. That bug should not have mattered for most of the old npp code except line 924 where Scintilla expected you to pass a style index value from 0 to 255 to SCI_STYLEGETHOTSPOT. When you passed a negative value to SCI_STYLEGETHOTSPOT it returned false.