NppExec - latest development version



  • Hello everyone!
    Latest development version of NppExec contains several interesting changes requested by users. These changes, in their turn, led to some other changes - and I believe that it is a good time to share the result with you to get your opinions and comments on the result.
    Here is the list of changes included in this build:

    • 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++.
      https://github.com/d0vgan/nppexec/issues/39
    • 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 starts or ends with ’ or ` character,
      you need to enquote this text in a different pair of quotes. For example: `'t was brilling…`, “Press `Esc`”, etc.

    • changed: now NppExec’s Console and the Toolbar button explicitly mention “NppExec” in their names
      https://github.com/d0vgan/nppexec/issues/40

    The latest build is available here:
    https://sourceforge.net/projects/npp-plugins/files/NppExec/NppExec Plugin (dev)/
    The archive NppExec20210620_dll_PA.zip is the one you need.

    Please feel free to share your thoughts on these changes and report any problems with this build.



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

    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



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



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



  • 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


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


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



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



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



  • 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
    


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



  • 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)/



  • @Vitaliy-Dovgan

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



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



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



  • @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’).



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


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



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



  • Here is an alternative approach:

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

Log in to reply