NppExec v0.8.6 has been released!

Vitalii Dovgan

As a proof of concept, I’ve added index.html to NppExec Manual’s files to mimic the .chm user experience while accessing the Manual via web browser:
https://htmlpreview.github.io/?https://github.com/d0vgan/nppexec/blob/develop/NppExec/doc/NppExec/NppExec_Manual/index.html

It would be interesting to add the ability to search the HTML content, similarly to how it is possible within a .chm file. I assume it will require additional styles (.css) and scripts (.js) applied to the index.html and this is something beyond of my knowledge.
If somebody knows how to do that, please let me know.

Lycan Thrope

@Vitalii-Dovgan ,
The easiest way for you to emulate a chm, is with the use of a frame layout, where your index.html is the host, and it’s screen is broken into frames. For instance, one frame on the left with the “contents” and one on the right for the display of the actual content.

I’m not sure what current html standards use, but at least with version 4.0 (which most browsers should be backward compatible with) you can still write html code that allows for this by just changing the header to reflect that version of html.

Here’s some sample code showing a page, with 3 framed areas and if you copy this into a new file in NPP and name it index.html you can view it in a browser. Firefox is my choice:

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Frameset//EN" "http://www.w3.org/TR/html4/frameset.dtd">
<html>
  <head>
    <meta http-equiv="content-type" content="text/html; charset=utf-8">
    <meta name="description" content="">
    <meta name="keywords" content="">
  <title>NPP Frame Reconstruction</title>
  </head> 
<frameset rows="20%,*">
    <frame classname="ridge" name="indexheader" src="https://htmlpreview.github.io/?https://raw.githubusercontent.com/d0vgan/nppexec/develop/NppExec/doc/NppExec/NppExec_Manual/0.%20Title%20Page.html" marginwidth="0" marginheight="0" scrolling="no" frameborder="5" noresize="noresize" bordercolor="#48800C" >
        <frameset cols="15%,*">
        <frame name="indexmenu" src="" marginwidth="0" marginheight="0" scrolling="auto" frameborder="5" noresize="noresize" bordercolor="#48800C" >
        <frame name="indexviewport" src="" marginwidth="0" marginheight="0" scrolling="auto" frameborder="5" noresize="noresize" bordercolor="#48800C" >
    </frameset>
</frameset>
</html>

Vitalii Dovgan

Thank you for the hints!

This thing works locally:
https://github.com/d0vgan/nppexec/blob/develop/NppExec/doc/NppExec/NppExec_Manual/index-2.html

But not remotely:
https://htmlpreview.github.io/?https://github.com/d0vgan/nppexec/blob/develop/NppExec/doc/NppExec/NppExec_Manual/index-2.html

I’m so far from this HTML stuff that even this simple “index-2.html” took me noticeable time to make it work locally.
Now I see it does not work remotely :( Moreover, <frame> is stated as “deprecated”, whereas <iframe> does not seem to support automatic resizing when you have two of them and want to move the divider between them. Or I just don’t understand it (that is most likely) :)

rdipardo

This thing works locally:
https://github.com/d0vgan/nppexec/blob/develop/NppExec/doc/NppExec/NppExec_Manual/index-2.html

But not remotely:
https://htmlpreview.github.io/?https://github.com/d0vgan/nppexec/blob/develop/NppExec/doc/NppExec/NppExec_Manual/index-2.html

The <frameset> is strongly discouraged by contemporary web standards, so it’s no wonder the hosting server won’t load it (although the frame borders are still clearly visible).

As you’ve noticed, the file:/// protocol works fine, as it’s not handled as securely as a remote host — even though a page at a file:/// address will still execute whatever scripts may be embedded in it.

Joseph Samuel

@Vitalii-Dovgan
I think you have an option to use github pages with frames as suggested by @Lycan-Thrope
Like this https://bjsam.github.io/nppexec/
https://github.com/BJSam/nppexec/tree/gh-pages
instead of having a new branch(like I did) move all the docs to a docs folder at root and configure github pages to point docs folder.

Lycan Thrope

@Joseph-Samuel ,
Thanks. I don’t have a lot of experience with the main purpose of github, myself, let alone all the little tricks it involves.

My suggestion of using the html standard of the frameset of 4.0 or 4.01 was to at least allow for someone to setup a local usage, like downloading the documentation to the hard drive and being able to view it in a browser.

Thanks for giving him a better usable solution with his current intent.

Vitalii Dovgan

Wow, kudos to Joseph, now NppExec’s Manual is available online!!!
https://d0vgan.github.io/nppexec/

Vitalii Dovgan

Just wondering: is it possible to alter the “index.html” (in the root) to make it work both from the web and locally? As far as I understand, locally <base href="/nppexec/"> confuses a browser, so maybe there could be some conditional instruction?

Lycan Thrope

@Vitalii-Dovgan ,
Not sure what you mean? Just saving the file via browser, saves it to the person’s chosen directory with all the html links so it can be navigated. What are you trying to do differently?

Vitalii Dovgan

@Lycan-Thrope
I mean if I get these files from github to my local machine:
https://github.com/d0vgan/nppexec/tree/develop/docs
and open the “index.html” in the root of the “docs” folder on my local machine, the content is not shown because of the <base href="/nppexec/">. Hence the question whether it is possible to make the <base> tag conditional, depending on whether the path to “index.html” is local or not.

rdipardo

@Vitalii-Dovgan said in NppExec v0.8.6 has been released!:

Hence the question whether it is possible to make the <base> tag conditional, depending on whether the path to “index.html” is local or not.

Dynamic HTML is pretty hard without the benefits of a server-side language like PHP. You could more easily just fake the <base> path on local machines.

First, make a nppexec/ subtree in the docs/ root, and create empty files for the pages you need, e.g.

docs/
├── fparser.html
├── index.html
├── nppexec
│   └── NppExec_Manual
│       ├── 0. Title Page.html
│       └── toc.html
├── ...
├── NppExec_Manual
|   └── . . .
├── ...
├── ...
├── ...
└── style.css

Now the dummy pages can simply redirect to the real pages using location.replace:

<!-- docs/nppexec/NppExec_Manual/toc.html -->
<!DOCTYPE html>
<body>
  <!-- fallback for when JS is disabled by the user agent -->
  <noscript>
    <h1>301 - Moved permanently</h1>
    <p>
      This page has moved to <a href="../../../NppExec_Manual/toc.html">../../../NppExec_Manual/toc.html</a>.
    </p>
  </noscript>
  <script>
    window.onload = function() {
      location.replace("../../../NppExec_Manual/toc.html");
    }
  </script>
</body>
</html>

<!-- docs/nppexec/NppExec_Manual/0. Title Page.html -->
<!DOCTYPE html>
<body>
  <!-- blah... -->
  <script>
    window.onload = function() {
      location.replace("../../../NppExec_Manual/0. Title Page.html");
    }
  </script>
</body>
</html>

rdipardo

I should’ve mentioned that the above will only work on a local server. When that’s the case, the forward slash in the /nppexec base path resolves to the server’s root (presumably docs/). It does not matter where on the file system the docs/ directory happens to be saved.

But if you’re just browsing the docs over the file:// protocol, the forward slash resolves to the file system’s root, and since docs/ will never be saved directly under C:\ or similar, the /nppexec path won’t be found either.

Fortunately there’s a client-side solution for this, too; and it’s even simpler.

Just create a second index page, for example index-1.html, identical to index.html except leaving out the <base> path. This will be for locally browsing the file tree.

Now your main index just needs a few lines of JavaScript to know when to serve index-1.html instead, e.g.

  window.onload = function() {
    if (location.protocol == 'file:') {
      location.replace(location.href.replace(/\/index\.(php|x?html?)$/, '/index-1.html'));
    }
  }

rdipardo

Just a few more things.

If we don’t want to prejudice local servers, we should check the hostname, too, and take into account that index file paths are usually omitted when requesting a server address.

Binding a callback to window.onload is also not ideal when it gives the server time to log 404 codes, and the user may see flickering error messages in the window.

A full patch would look like this, excluding a new index-1.html page. The <script> element is now a child of <head>, to respect HTML document standards.

diff --git a/docs/index.html b/docs/index.html
index 97dbc11..28ebe28 100644
--- a/docs/index.html
+++ b/docs/index.html
@@ -7,24 +7,21 @@
 <title>NppExec Manual: Index</title>
 <meta http-equiv="Permissions-Policy" content="interest-cohort=()"> <!--Remove warning in browser: feature not enabled: 'interest-cohort'-->
 <base href="/nppexec/">
-</HEAD>
-<script>
-  // var protocol = location.protocol;
-  // var hostname = location.hostname;
-  // var pathname = location.pathname;
-  // var protocol = location.protocol
-  // var port     = window.location.port
-  // var baseHref = new URL('http://github.com'); 
-  // baseHref.host = hostname
-  // baseHref.port = port.length>0 ? port : null
-  // baseHref.pathname = pathname
-  // baseHref.protocol = protocol
-  // console.log(baseHref.href);
-  // var head = document.getElementsByTagName('head')[0];
-  // var base = document.createElement('base');
-  // base.href = baseHref.href;
-  // head.appendChild(base);
+<script type="text/javascript">
+    var protocol = location.protocol;
+    var hostname = location.hostname;
+    var pathname = location.pathname;
+    var href     = location.href;
+    var newPath  = 'index-1.html';
+    var redir    = href.replace(/\/index\.(php|x?html?)$/, '/'+newPath);
+    if (protocol == 'file:') {
+        location.replace(redir);
+    } else if (Array('localhost', '127.0.0.1').indexOf(hostname) > -1) {
+        redir = (pathname == '/') ? href + newPath : redir;
+        location.replace(redir);
+    }
 </script>
+</HEAD>
 <FRAMESET cols="30%, 70%">
   <FRAME name="toc" src="./NppExec_Manual/toc.html">
   <FRAME name="content" src="./NppExec_Manual/0. Title Page.html">

Vitalii Dovgan

@rdipardo
Thank you! I’ve integrated this - seems to work like a charm!
Now I probably understand the feelings of people who are looking at Python’s or NppExec’s scripts with understanding of the general idea behind them but anyway perceiving the entire script like a form of a magic spell :)

PeterJones

@Vitalii-Dovgan and all,

It seems like this is mostly wrapped up, but if there’s anything more on the HTML/presentation of the NppExec manual, it would be a better fit in the NppExec repo’s issue section than here.

Of course, discussion on the plugin itself is quite encouraged here. :-)

Vitalii Dovgan

Recently I had made some optimizations around variables handling in NppExec (in the develop branch). So I decided to create a scenario that would help to compare the performance between 0.8.6 and pre-0.8.7. Hence the following simple NppExec’s script was born:

npe_console local -- m-
set local N = 20
set local i = 0

:1
set local i ~ $(i) + 1
if $(i) >= 8400 goto 3
if~ $(i) % 100 != 0 goto 1
set local k ~ ord a
set local kk = 0
:2
set local c ~ chr $(k)
set local v ~ strupper $(c)
set local $($(c)_) = $($(c)_)$(v)
set local k ~ $(k) + 1
set local kk ~ $(kk) + 1
if $(kk) < $(N) goto 2
goto 1

:3
set local k ~ ord a
set local kk = 0
:4
set local c ~ chr $(k)
echo $($(c)_)
set local k ~ $(k) + 1
set local kk ~ $(kk) + 1
if $(kk) < $(N) goto 4

This script intentionally does not use nested IF-THEN-ELSE because, as I discovered during these tests, all the versions of NppExec prior to pre-0.8.7 (in development) had problems with nested IF-THEN-ELSE. I wonder how it happened that no one had reported that before.
Anyway, here is the script that works in both NppExec 0.8.6 and pre-0.8.7 and here are the average execution times of this script on my i5-6600 CPU @ 3.30GHz :

0.8.6 - 2.00 seconds
0.8.7 - 0.65 seconds

Not bad, I should say.
Now, if you want the very same script to take extra long time of around 2 minutes and 30 seconds (just compare it to 0.65 seconds!), just replace npe_console local -- m- in the beginning of the script with npe_console local -- m+. This clearly shows that the implementation of CNppExecConsole::PrintMessage which is basically:

SendMessage(hRichEdit, EM_EXGETSEL, 0, (LPARAM) &cr);
SendMessage(hRichEdit, WM_SETREDRAW, FALSE, 0);
SendMessage(hRichEdit, EM_EXSETSEL, 0, (LPARAM) &CHARRANGE{-1, -1});
SendMessage(hRichEdit, EM_SETCHARFORMAT, (WPARAM) dwOptions, (LPARAM) &cf);
SendMessage(hRichEdit, EM_REPLACESEL, FALSE, (LPARAM) cszText);
SendMessage(hRichEdit, EM_EXSETSEL, 0, (LPARAM) &cr);
SendMessage(hRichEdit, EM_SCROLLCARET, 0, 0);
SendMessage(hRichEdit, WM_SETREDRAW, TRUE, 0);
if (InvalidateRect(hRichEdit, NULL, TRUE))
    UpdateWindow(hRichEdit);

is slow as hell.
As you can see, all of these are actually messages to a RichEdit window.
I tried to remove SendMessage(hRichEdit, WM_SETREDRAW, FALSE, 0);, together with SendMessage(hRichEdit, WM_SETREDRAW, TRUE, 0);, InvalidateRect(hRichEdit, NULL, TRUE) and UpdateWindow(hRichEdit) - and got 3 minutes and 40 seconds - i.e. 1 minute was added to the previous extra long result!
Oh my, is there a way to append text to RichEdit more effectively, without waiting forever?

PeterJones

@Vitalii-Dovgan said in NppExec v0.8.6 has been released!:

As you can see, all of these are actually messages to a RichEdit window.

It sounds like you’ve got a generic win32 API programming question, then, rather than something specific to Notepad++, and there are other forums on the internet that will have a higher concentration of RichEdit experts than here, where we focus on the specifics to the Plugin/Notepad++ interface.

Alan Kilborn

Hmm, told TWICE now to avoid off-topic conversations…

Vitalii Dovgan

Guys, I respect your will to avoid off-topic.
Let’s, however, analyze the content of my last message:

First I’m presenting an interesting NppExec’s script. Not off-topic.
Second, I’m describing some technical details of NppExec’s implementation. Not off-topic.
then I mention the details of implementation of CNppExecConsole::PrintMessage to illustrate that exactly the implementation of this method adds extra execution time.
Until this point, there’s nothing about “a generic win32 API programming question”, as you mentioned.
Finally, summing up with the slow implementation of CNppExecConsole::PrintMessage, I’m asking “is there a way to append text to RichEdit more effectively”. This question was not the goal of the entire text above.

PeterJones

@Vitalii-Dovgan said in NppExec v0.8.6 has been released!:

Until this point, there’s nothing about “a generic win32 API programming question”, as you mentioned

And your post, until that point, was on topic. But that point (including the RichEdit question asked) and any followup, is not. That is why I only quoted that single portion in commenting about off-topic, because that was the portion that was going off-topic. (And no, I didn’t do it out of shear meanness or something; when I, as a moderator, get valid private complaints about discussions straying off-topic, I have to address them somehow.)