NppExec - latest development version

astewart77

@Vitaliy-Dovgan said in NppExec - latest development version:

added: new menu item “Change Execute Script Font…”
https://github.com/d0vgan/nppexec/issues/37

This new menu item is listed in the shortcut mapper and bumps all the nppexec scripts added to the macro submenu down (up in number). Shortcuts assigned to these scripts are apparently positional (by number, not name?) in the mapper list and are “off by one”. A quick fix is moving a macro without a shortcut from the top to the bottom of the nppexec list, but disconcerting at first.

Alan

Vitaliy Dovgan

@astewart77

It is related to how Notepad++‘s Shorcut Mapper assigns shortcut keys to plugins’ commands.
When you open the file “shortcuts.xml”, you may see entries similar to the following:

<PluginCommand moduleName="NppExec.dll" internalID="19" Ctrl="yes" Alt="yes" Shift="no" Key="112" />

What it demonstrates is the fact that the Shorcut Mapper assigns shortcut keys using the menu item IDs of plugin’s menu.
The new menu item “Change Execute Script Font…” in NppExec indeed causes all the menu IDs after it to be increased by 1. And the Shorcut Mapper is not aware of this.
So you may open the file “shortcuts.xml” and manually increase the value of internalID for each NppExec’s item to fix this.

artie-finkelstein

Other than my experiencing a minor hiccup with the Shortcut mapper reassigning the keycodes for my NppExec scripts (and nicely explained by @Vitaliy-Dovgan in his response to @astewart77) all the new features are working nicely for me.

I would like to pass on a hard won insight into the nesting of quotes: The inner quotes will be preserved if there are outer quotes at each critical processing step. They are not magically remembered because they were nested the first time they were referenced.

set local msg1 = "the '$(INPUT)' option is not available from the interactive menu,"
        set local msg2 = "use the NppExec console version instead"
        set local msg ~ strfromhex $(msg1) 0A 00 $(msg2) 
        messagebox "$(msg)" : "Warning" : : 7000

In the above example, the inner single quotes around $(INPUT) will disappear if the outer double quotes around $(msg) are not used. An additional thank you to @Vitaliy-Dovgan for the correction in my thinking.

FWIW: There is a slightly newer version of the plugin posted in the dev folder at sourceforge; @Vitaliy-Dovgan fixed an issue with the ‘strfromhex’ command.

Vitaliy Dovgan

Hello everyone!
I’ve collected everything to be included into the next release of NppExec - and now it’s time to share it with the community! Please let me know if there are any problems/suggestions with this version before it is officially released.
Please download this version here:
https://sourceforge.net/projects/npp-plugins/files/NppExec/NppExec Plugin (dev)/
The archive NppExec20210719_dll is the one you want.
Here is the full changelog for this version:

added: now NppExec supports the “Dark Mode” of Notepad++ v8
(Thanks to Peter Jones for the updated icons!)
NppExec is still compatible with previous versions of Notepad++.

changed: now NppExec supports quoted strings in the form of “abc”, ‘abc’
and `abc`.
This allows to pass quote characters within a quoted string: `“`, '”',
‘“abc” `def`’ and so on.
Now, if you want to pass a text that includes ’ or ` character, you need
to enquote this text in a different pair of quotes. For example:
`'t was brillig…`, “Can’t stop”, “Press `Esc`”, etc.
changed: now NppExec’s Console and the Toolbar button explicitly mention
“NppExec” in their names

added: new menu item “Change Execute Script Font…”
added: now MESSAGEBOX and INPUTBOX can accept 4th parameter ‘time_ms’

changed: now the InputBox can be closed by pressing Esc. When it happens,
the value of $(INPUT) will be empty.

added: now con_colour, con_filter, env_set, npe_console, npe_noemptyvars,
npe_sendmsgbuflen and npp_console support a new keyword “local”.
This new keyword means: the changes are applied locally to the current
NppExec’s script and are reverted back when the current script ends.
Thus, the “local” keyword does not make sense in a single command executed
directly in NppExec’s Console because the previous state is restored right
after the execution of this single “local” command, so you will not see any
effect of it.
added: set <var> ~ strescape <s>, set <var> ~ strunescape <s>
added: file names “npes_temp.txt” and “npes_saved.txt” can be customized
(see “NppExec_TechInfo.txt” for details)

fixed: indirect variable reference in e.g. “echo #$(i) = $(#$(i))”

new advanced option “CustomMsgReady” (see “NppExec_TechInfo.txt”)
NppExec Manual updated

dinkumoil

@Vitaliy-Dovgan said in NppExec - latest development version:

Please let me know if there are any problems/suggestions with this version before it is officially released.

A feature I strongly miss is expansion of constant values read from the files BaseDef.h, menuCmdID.h, Notepad_plus_msgs.h and Scintilla.h (part of every NppExec installation) when used in if ... then or if ... goto expressions to be able to write for example

if $(MyVar) == MAIN_VIEW then ...

Currently I have to use the workaround

set local $(MainView) ~ MAIN_VIEW

if $(MyVar) == $(MainView) then ...

artie-finkelstein

@dinkumoil

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