NppExec - latest development version

artie-finkelstein

As a random user, I’m not sure I can support reverting to the direct reference to the manifest constant names as defined in the files in …\Notepad++\plugins\NppExec\NppExec.

Don’t get me wrong, I see it as a nice coding shortcut, but I think that it would overpower the variable namespace. While many of the files of constants use a unique prefix, e.g., IDM_, NPPM_ or SCI_, there are other constants, such as FILE_NAME or CURRENT_WORD that could easily be used in a script as an unqualified (no added attributes, e.g., ‘local’) variable and it is not clear to me which one would be evaluated.

The NppExec language may define this behavior, and guarantee which variable or constant reference would be evaluated, but I don’t recall any clarification in the HelpAll file or the User Guide. I assume the ‘~’ assignment operator is a signal that fparser will be used to evaluate the expression, and it is also responsible for interpreting the files of constants (see section 3.8.4 of the NppExec User Guide).

Vitaliy Dovgan

Comparisons (under IF) do not use calculations for performance reasons.
We could, however, introduce new operators explicitly for calculations during comparisons. For example, it might be:

if NPPMSG ~~ WM_USER + 1000 // calc. if eq
if $(x) + 1 !~ $(y) + 2 // calc. if not eq

What do you think?
And yes, it does not include alternate forms of operator <, >= and so on because they might look a bit ugly in combination with ~ . So there could be better proposals for the syntax.

dinkumoil

@Vitaliy-Dovgan

So there could be better proposals for the syntax.

Operator >= could be >~ and <= could be <~ but what about the operators > and <? Changing them to ~> and ~< is confusing because of their similarity to >~ and <~.

Maybe you could introduce the ability to use abbreviated forms of the according english words:

==  ->  equ
!=  ->  neq
<   ->  lss
<=  ->  leq
>=  ->  geq
>   ->  gtr

For using calculations with IF ... THEN or IF ... GOTO statements these abbreviations could be prefixed with a ~ character.

But if this whole thing will cause severe performance issues I would vote against changing anything. The workaround I mentioned above is not that bad.

Vitaliy Dovgan

Or we may alter the IF keyword itself, e.g.:

if~ NPPMSG == WM_USER + 1000
if~ NPPMSG >= WM_USER + 1000
else if~ NPPMSG < WM_USER + 1000

In terms of the execution logic, if~ NPPMSG >= WM_USER + 1000 is equal to:

set local result ~ NPPMSG >= WM_USER + 1000
if result == 1

dinkumoil

@Vitaliy-Dovgan

Using if~ seems to require the least amount of effort and is understandable. I would like it to see it resolved that way.

Vitaliy Dovgan

NppExec20210724_dll:

added: if~ <condition> - first calculates, then checks the condition

Get it here:
https://sourceforge.net/projects/npp-plugins/files/NppExec/NppExec Plugin (dev)/

dinkumoil

@Vitaliy-Dovgan

Great, thank you! Will test as soon as I have some spare time.

artie-finkelstein

@Vitaliy-Dovgan

It works as advertised.
Thank you.

I tried pushing the limits:
I copied the Npp resource.h file into ...\Notepad++\plugins\NppExec\NppExec to see if other manifest constants could be read. It worked once in a mini script I wrote to test reading & basic math operations, but only once. Reading constants in the traditional four .h files in that same folder always worked. The log file showed that the resource.h file was being opened and scanned even when the same script was tried again.
Question: Should this ‘expansion of function’ work?

[change of focus area, still on NppExec though]
Question #2:
Is it possible to assign a command line style argument to a NppExec script placed on the Menu Items area of the NppExec Advanced Options dialog? This would be similar to adding arguments or flags to a UserDefinedCommand in the shortcuts.xml file. Right now I create individual wrapper functions in startup.npes (f/k/a npes_saved.txt). This copying & tweaking works fine; I want to coalesce the cookie cutter code and reduce the chance of forgetting to update one in the future.

example:

afRun :: afRun
afRunAlt :: afRunA
afRunNpp :: afRunN

would look something like:

afRun :: afRun
afRunAlt :: afRun  A
afRunNpp :: afRun  N

where all three ‘exported’ functions would call the same core code and optionally pass in a flag.

Vitaliy Dovgan

Placing any number of .h files under the “NppExec\NppExec” is expected to add all the definitions from these files to the FParser. For example, if I put Notepad++'es “resource.h” into that folder and my NppExec’s startup script does not contain any calculations, here is an extract of what I see after the following commands in NppExec’s Console:

npe_debug 1
set local x ~ IDI_VIEW_UD_DLG_ICON_DM

Here is the extract of a possible output:

CheckUserMacroVars()
{
   [in]  "local x ~ IDI_VIEW_UD_DLG_ICON_DM"
   ; SET command found
   initFParserConsts()
   {
      C:\Progs\npp8\plugins\NppExec\NppExec\BaseDef.h
      (
         20 definitions added.
      )
      C:\Progs\npp8\plugins\NppExec\NppExec\menuCmdID.h
      (
         475 definitions added.
      )
      C:\Progs\npp8\plugins\NppExec\NppExec\Notepad_plus_msgs.h
      (
         264 definitions added.
      )
      C:\Progs\npp8\plugins\NppExec\NppExec\resource.h
      (
         error at line 22: "TEXT("Notepad++ v8.1")"
          - Syntax error: Unknown identifier at pos 0
         error at line 26: "TEXT("8.1\0")"
          - Syntax error: Unknown identifier at pos 0
         error at line 27: "8, 1, 0, 0"
          - Syntax error: Operator expected at pos 1
         429 definitions added.
      )
      C:\Progs\npp8\plugins\NppExec\NppExec\Scintilla.h
      (
         error at line 1299: "Sci_CharacterRange"
          - Syntax error: Unknown identifier at pos 0
         error at line 1300: "Sci_TextRange"
          - Syntax error: Unknown identifier at pos 0
         error at line 1301: "Sci_TextToFind"
          - Syntax error: Unknown identifier at pos 0
         error at line 1302: "Sci_RangeToFormat"
          - Syntax error: Unknown identifier at pos 0
         error at line 1303: "Sci_NotifyHeader"
          - Syntax error: Unknown identifier at pos 0
         1142 definitions added.
      )
   }
   ; fparser calc result: 261
   ; OK: local $(X) = 261
   [out] "local x = 261"
}

The initFParserConsts() is called only once by demand - when a very first calculation is performed by current instance of NppExec. If Notepad++ is not restarted, initFParserConsts() will not be called again by the same instance of NppExec.

As for the second question, it looks like it will require to modify the Advanced Options dialog by adding a new input field “Script arguments” right under the “Associated script” field. Also it will require an updated syntax of the “[UserMenu]” items - for example “menu item name :: script name :: script arguments”.
In the same time, I believe your scripts “afRunAlt” and “afRunNpp” already look similar to the following:

::afRunAlt
npp_exec afRun A

::afRunNpp
npp_exec afRun N

that achieve the very same goal and avoids copy-pasting. So I’m not sure if the Advanced Options dialog really needs an additional element of the “Script arguments” field.

artie-finkelstein

@Vitaliy-Dovgan
Thank you for the prompt reply.

It is possible to parse other .h files. Cool. I will spend additional time looking at other *.h files in (or symlinked into) NppExec\NppExec. I may have overlooked something in my late night coding fatigue.

As for the additional arguments on the Advanced Options dialog: I was not asking for a change, only a verification that it was not possible at the present. BTW: Your ‘already look similar to the following’ code block display is a shortened version of how I have the code in startup.npes (npes_saved.txt):

::afRunA
//  a/k/a:  afRun Alternate      <Alt> <Ctrl+/>        [N++: left scroll]    "Notepad++"
//  open with Notepad++.bat -multiInst -nosession    (ignores system association)
npp_console ?                           // keep console state
if      "$(ARGV[1])" == ""
    set local tmpShell = A              // default to Alternate
else 
    set local tmpShell = $(ARGV[1])
endif
NPP_EXEC  "$(SYS.NPE_SCRIPTS)\nppRun.npes"  $(tmpShell)
//

afRunN is similar, but replaces the ‘A’ with an ‘N’
afRun is also similar, but replaces the ‘A’ with a ‘U’
I won’t go into the gory details of the rest of the NppExec and system code, but in the end I can ‘left mouse wheel’ click on a line of text in a file and open the target with the system associated program.

I was looking at streamlining startup.npes a bit by using the Advanced Options area to provide the unique portion of each call (the letter ‘A’ or ‘N’).

artie-finkelstein

@Vitaliy-Dovgan
The parsing of other files of manifest constant works great! I messed up my testing the other day.

In my further testing today, I was pleased to find that the names parsed by fparser for ‘~’ commands are independent of user created names.

set pi = 3
set e = 2
set local locDiff ~ pi - e
echo locDiff=$(locDiff)
echo pi=$(pi)
echo e=$(e)

displays

locDiff=0.423311
pi=3
e=2

dinkumoil

@Vitaliy-Dovgan

I found a bug in the latest version of NppExec from NppExec20210724_dll_PA.zip

In one of my scripts there is the line

if "$(CLIPBOARD_TEXT)" != "" goto :SHOW_RESULT

If the clipboard contains text which contains a " sign (for example This is a "testing" text), I get an error message:

; executing: IF "This is a "testing" text
" != "" goto :SHOW_RESULT
- Syntax error in the if-condition.
To prevent unpredictable behavior, the script is stopped.

Previous versions of NppExec were able to process this line without any error.

Vitaliy Dovgan

What about

if `$(CLIPBOARD_TEXT)` != `` goto :SHOW_RESULT

?
In fact, the previous version of NppExec has other problems parsing the IF arguments, so that part of code was rewritten to be more strict in terms of syntax. So now extra " within another pair of "" leads to syntax error.

Vitaliy Dovgan

Here is an alternative approach:

set local len ~ strlen $(CLIPBOARD_TEXT)
if $(len) != 0 goto :SHOW_RESULT

dinkumoil

@Vitaliy-Dovgan

Another workaround:

if "" != "$(CLIPBOARD_TEXT)" goto :SHOW_RESULT

Vitalii Dovgan

Guys, there is a release candidate for an upcoming new version of NppExec.
You can find the latest binaries here:
https://sourceforge.net/projects/npp-plugins/files/NppExec/NppExec Plugin (dev)/

I know that everyone is waiting for ads in NppExec’s Console, but I have to disappoint you: no ads in NppExec, even though human kind seems to be obsessed by ads (as ads appear every-freaking-where).
Also I have to disappoint you regarding multi-line pasting into NppExec’s Console: I am still not sure how exactly to implement this. Instead, there is a new feature that can be used instead of multi-line pasting (though I understand it can not completely replace a native ability of multi-line pasting).

So, here are the most interesting new features:

Added a built-in highlight filter that catches most of compiler error messages. This filter is disabled by default to avoid an impact on performance. It is recommanded to enable this filter locally, right before running a compiler or an interpreter: “npe_console local – x+”.
Added new menu items “Execute Selected Text”, “Execute Clipboard Text”. So now you can select a text in Notepad++ and “Execute Selected Text” will execute it as NppExec’s script or send it to the running child process as an input. Also, a new command “npp_exectext” added.

Here is the list of all the changes:

added: built-in highlight filter that catches most of compiler error
messages, thanks to David Maisonave.
This filter is disabled by default to avoid an impact on performance.
It is recommanded to enable this filter locally, right before running
a compiler or an interpreter: “npe_console local – x+”.
See also: “NppExec_TechInfo.txt”, the ‘CompilerErrors’ setting.
added: now WarningAnalyzer caches the previously matched lines.
It allows the built-in highlight filter (see above) to react to a
double-click in the Console even when this filter is disabled at the
moment of double-clicking. Explanation: let’s consider a situation when
the built-in highlight filter had been disabled globally but was locally
enabled via “npe_console local – x+” right before running a compiler. So
the messages produced by compiler are analyzed by the built-in highlight
filter and the filter is automatically disabled after the compiler exits.
Now, as WarningAnalyzer has cached the matched lines from the compiler’s
output, it is possible to double-click these lines in NppExec’s Console
to get the cached match result.
added: the last executed script is now saved to “npes_last.txt”.
added: new menu items “Execute Selected Text”, “Execute Clipboard Text”.
NPE_CONSOLE c<N> and s<N> to change the text processing for the
Execute Clipboard Text and Execute Selected Text.
added: new command “proc_input”.
added: new command “npp_exectext”.
added: new variables $(SELECTED_TEXT), $(IS_PROCESS).

changed: the menu item “Disable command aliases” has been removed. Use
the “npe_console q+/q-” instead.
changed: now killing a running child process also kills any processes
that were started from the running child process.
changed: now “help” command works in NppExec’s scripts.

fixed: now “set local” (without an argument) prints only local vars.

NppExec Manual updated

Michael Vincent

@vitalii-dovgan said in NppExec - latest development version:

Guys, there is a release candidate for an upcoming new version of NppExec.
You can find the latest binaries here:

Just installed it. FYI, I’ve been using your AppVeyor build for a bit now before this.

I did notice a caveat in installing - a new menu item or two in the NppExec menu caused a shift in all of my Macro menu items shortcuts that are NppExec scripts so I had to go manually remap all the shortcuts. This is a known issue with Notepad++ menu ID numbers - nothing you can “fix”, just something for others to be aware of.

Great job on continued development of the NppExec plugin - one of my MUST HAVE plugins I use in every Notepad++ editing session!

Cheers.

Michael Vincent

@vitalii-dovgan said in NppExec - latest development version:

Guys, there is a release candidate for an upcoming new version of NppExec.

Found what seems to be a regression.

I have a global set:

SET CMD=cmd.exe /d /c

And I use it in scripts - for example:

$(CMD) start $(NPP_DIRECTORY)\change.log

and this launches Notepad.exe (my default .log editor apparently) with change.log.

In the new version, nothing happens. It seems the $(CMD) variable isn’t launching an external CMD.exe process? Weird, because other things like:

$(CMD) dir /b /ad $(NPP_DIRECTORY)

do work.

Cheers.

Vitalii Dovgan

Please try the latest version NppExec20220203_dll here:
https://sourceforge.net/projects/npp-plugins/files/NppExec/NppExec Plugin (dev)/

Changelog:

NPE_CONSOLE j+/j- to kill process tree on/off.
npp_files updated to Notepad++ 8.2.2.
tiny internal improvements

Michael Vincent

@vitalii-dovgan

Thanks! And thanks for the help on your Github issues page - my scripts are updated and this latest 3-Feb version is working fine for me so far!

Cheers.