How is this for a compromise? When an on-topic conversation here starts to edge into things that aren’t Notepad+±specific,

There’s also the option of taking any discussion you want into a dedicated “chat” right on this site.

So one could say, “if anyone has some ideas for me about ____, please private chat me and we’ll talk further, without potentially bothering any others”

I’m trying to walk the fine line of a moderator, of trying to encourage healthy discussion pertinent to Notepad++ (and here, the development and usage of plugins) while not letting things get off into generic programming questions. Unfortunately, that’s not always easy to do, and it can make people on one or both sides of the viewpoint on a certain discussion unhappy, no matter what I do. Maybe I am being too strict – I’m doing my best, but I’m not perfect.

How is this for a compromise? When an on-topic conversation here starts to edge into things that aren’t Notepad++-specific, you could say, “It looks like we’re straying away from the Notepad++ aspects of my plugin. If you have any ideas on how to improve the SendMessage with the RichText elements, could you please come to my issue#XXXXX which I created to delve deeper into this?” That way, interested readers in this Community would know that you’re having difficulty, and if they think of something, they’ll have an on-topic location for where to give you more details.

1. 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.
2. 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.

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

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

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.

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?

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

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">

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'));
    }
  }

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>

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.

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.

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

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>