NppExec v0.8.6 has been released!

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.

PeterJones

@Vitalii-Dovgan ,

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.

Alan Kilborn

@PeterJones said in NppExec v0.8.6 has been released!:

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”

Vitalii Dovgan

Makes sense, thank you! Such obvious things did not come to my mind, but I’m learning :)
I’ve created an issue regarding the RichEdit. Anyone interested please feel free to comment right there:
https://github.com/d0vgan/nppexec/issues/79

Vitalii Dovgan

One more idea that requires help of someone familiar with HTML.
It would be great to add a search index (ability to search for a given word) to the online NppExec Manual.
I’ve created the corresponding issue on github, please feel free to comment right there:
https://github.com/d0vgan/nppexec/issues/80