Double click links no longer work

  • Bonjour à tous, je viens d’installer la V7.3.2, les liens en double clic ne fonctionnent plus!
    Constatez-vous le même comportement de Npp +

    Hello everyone, I just installed the V7.3.2, the double click links no longer work!
    Do you see the same behavior of Npp +

  • @Jean-Heck

    No, it is working for me - do you see that the link gets highlighted
    if you click on it? Is it initially underscored?
    Which link did you try?


  • I’ve been running into the same issue except that it’s intermittent. Background data:

    • 32-bit npp
    • I saw it with v7.3.2 and am now running v7.3.3 and still see the issue
    • It tends to affect .htm extension files. I edit both .htm and .txt a lot.
    • The links seem to always work from .txt files
    • The links are getting underlined and highlighted when I hover on them. Double clicking seems to do nothing.

    As a test I did

    • Ctrl-N to create a new/blank tab.
    • Enter on a line by itself.
    • I see that it’s underline and mouse hover makes the text blue.
    • Double clicking on the link works.
    • Change the language to HTML
    • The text is no longer underlined and hovering does nothing.
    • I move the cursor to the end of the line and hit enter. The text gets underlined and hover changes it to blue.
    • Double clicking on it does nothing.
    • Change the language back to Normal Text
    • The text is no longer underlined and hovering does nothing.
    • I move the cursor to the end of the line and hit enter. The text gets underlined and hover changes it to blue.
    • Double clicking on it works
    • Links also work for the CSS, Batch, and XML languages though with all of them the link is not underlined until I make a change on the line such as adding a space, newline, etc. If I switch back to HTML the links don’t work.
    • I tried disabling and re-enabling Settings / Preferences / MISC. / Clickable Link Setting. No joy.
    • I tried running npp in administrative mode. No joy. (I thought about trying this as just after I upgraded to 3.7.7 the installer launched npp in administrative mode and a link in an HTML file worked. Sadly, it was just one of the few random times it works.)

    I looked for a menu option to navigate to the selected text but did not see one and so don’t know of a way to test other than double-clicking. While the issue was consistent and reproducible when I was testing at random times links in HTML files work for me.

  • @mkupper

    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.


  • 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.
    • 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.

  • Hi, Jean Heck, mkupper and Claudia,

    Please, read my post to Don :



  • @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.


  • Maybe introduced with

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

    SCI_SETSTYLEBITS(int bits) Deprecated
    SCI_GETSTYLEBITS → int 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.

  • @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.

  • Hmmm maybe I spoke to soon…

  • I’ve opened which solves the issue with clicking links in certain file types.

  • @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.

  • 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.

Log in to reply