NppExec v0.8.6 has been released!

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

Vitalii Dovgan

For me it’s hard to keep away from offtopic sometimes because NppExec’s nature is all related to effectiveness and development.
For example, one guy asked about the behavior of ipython under NppExec. At that point, I did not even know what ipython is. So, from your perspective, that question could be treated as ipython-specific and, thus, offtopic. However, I invested my time into looking into that problem since ipython was running under NppExec, making it NppExec-related in that sense.
Another example: NppExec is distributed with a few .h (C-header) files because NppExec goes as far as loads these .h files during runtime to read the numeric constants from the files. Correspondingly, NppExec supports two-pass parsing of C #define statements as well as C enum statements. From your perspective, C #define and enum statements are C-specific and thus can be treated as offtopic - however, it is directly related to NppExec’s code that probably makes them non-offtopic.
Next example: Joseph-Samuel, Lycan Thrope and rdipardo significantly helped with making NppExec’s Manual available online. In terms of NppExec, this is a historical achievement because, from now on, any user of NppExec can access and can be pointed to the online Manual at any time. And this benifit is incommensurably more important than the question of offtopic in the forum. Let me highlight: NppExec Manual would have never been online without Joseph-Samuel’s, Lycan Thrope’s and rdipardo’s help!
You had mentioned that HTML-related things are offtopic here, but you have omitted two truly significant points:

People who read and write here, in this topic, do care about NppExec, so their motivation with helping with some technology-specific solution is much higher than in any other solely technology-specific forum. In terms of HTML, I did not even know what to ask about, and only due to Lycan Thrope, because he knows how NppExec’s Manual chm file looks like, I discovered such things as frames in HTML. Then, Joseph-Samuel helped with hosting the HTML Manual on Git (without him, I did not even know that it is possible). Finally, rdipardo helped with the final form of the online/offline Manual. By marking all of this as “offtopic”, you are actually saying: NppExec Manual is not important for Notepad++ Community, we’d prefer to not have the online/offline version in favour of not having technology-specific duscussion in our forum.
While NppExec’s users are free to ask questions about NppExec as a tool and as a technology, I can’t feel free to ask about tools and technologies that are used by NppExec itself. Execuse me, but it looks assymetrical and unfair to me. Again, exactly here, in the forum named “Notepad++ & Plugin Development”, where we have people who care about NppExec and who use different technologies and different tools, there are much higher chances to get an answer. And if people do not have such answer, they just do not reply. For example, in terms of RichEdit, some developer who is interested in Notepad++ and NppExec, might reply e.g.: “RichEdit is an ancient thing, let’s better use another component that has a similar API but is implemented much better. Morover, as I have experience with it and was already thinking about using it NppExec, let’s do it together”. Such an answer would not be possible in any other forum otside of Notepad++'s one.