If two (or more) plugin packages contain the same module (say, for example, a variable function @FOO), which will be in effect--the first one loaded, or the last one? (And I hope the answer is not "it depends".) (It would help if the folks who maintain plugins would coordinate with each other to avoid duplications.)
Thank you. Since it's deterministic, I can load the plugins in a particular order to get the version I want.
| ---Quote (Originally by rconn)--- || The first one loaded. || ---End Quote--- | Thank you. Since it's deterministic, I can load the plugins in a | particular order to get the version I want. Keep the one you don't want to be first out of the PLUGINS subdirectory, allowing the one you do want (as well as all other nonconflicting plugins) to be loaded automatically, and load that one manually. However, IIRC (I do not have time at the moment to search through all plugins) the only conflict is between some item in Federico Romano's FEDUTILS and one of Charles Dye's. If the version you desire is not the one from FEDUTILS, you can use the selective disable feature which Federico included in FEDUTILS, which would make loading order irrelevant. -- Steve
| ---Quote--- || If two (or more) plugin packages contain the same module (say, for || example, a variable function @FOO), which will be in effect--the || first one loaded, or the last one? (And I hope the answer is not || "it depends".) | ---End Quote--- | The first one loaded. Rex, I seem to remember a discussion on that topic when you introduced plug-ins. IIRC you stated that it is possible for a plug-in to "hook" a feature (command, or internal variable, or variable function). When called it may evaluate command or function parameters as well as perform or system status, and determine that the conditions are not right for it to return a result, and just pass it back to TCC for further processing, potentially including other plug-ins. I could reconcile it with the above statement by interpreting the one above to mean that the first to load gets first crack, but if it decides not to return a result, the second to load would get its chance. Likewise, if no plug-in decides to process the item, TCC's built-in features will get their chance. Please verify my recollection (or tell me I am wrong). -- Steve
On Sat, 27 Mar 2010 11:19:22 -0400, rconn <> wrote: |---Quote--- |> Rex, I seem to remember a discussion on that topic when you introduced |> plug-ins. IIRC you stated that it is possible for a plug-in to "hook" a |> feature (command, or internal variable, or variable function). When |> called it may evaluate command or function parameters as well as perform |> or system status, and determine that the conditions are not right for it |> to return a result, and just pass it back to TCC for further processing, |> potentially including other plug-ins. |---End Quote--- |That's correct (and in the docs). Yes. The docs say "There is a special return value (0xFEDCBA98) that tells the parser to assume that the plugin decided not to handle the variable/function/command. The parser then continues looking for a matching internal, then external. Note that you can use this return value to have your plugin modify the command line and then pass it on to an existing internal variable/function/command!" What do you mean by "modify the command line". -- - Vince
Just that -- you can change the contents of the command line before the internal command (or another plugin, I suppose) sees it. Some earlier versions of my ISO8601 actually did this, intercepting the TOUCH command and looking for new-format date arguments; if found, the plugin would massage them into something that the internal TOUCH could recognize and pass the command line on. (I've since removed this feature; too much code for little or no real benefit, especially now that the internal TOUCH can handle formats 5 and 6.) (It might be useful if some future version allowed plugins to see/modify the command line for *all* internal commands. It would enable plugin extensions to non-variable/function features such as date ranges....)
Agreed. It might also be useful if the current version allowed this -- which it does. :-) Rex Conn JP Software
On Sat, 27 Mar 2010 14:26:57 -0400, Charles Dye <> wrote: |---Quote (Originally by vefatica)--- |What do you mean by "modify the command line". |---End Quote--- |Just that -- you can change the contents of the command line before the internal command (or another plugin, I suppose) sees it. | |Some earlier versions of my ISO8601 actually did this, intercepting the TOUCH command and looking for new-format date arguments; if found, the plugin would massage them into something that the internal TOUCH could recognize and pass the command line on. (I've since removed this feature; too much code for little or no real benefit, especially now that the internal TOUCH can handle formats 5 and 6.) | |(It might be useful if some future version allowed plugins to see/modify the command line for *all* internal commands. It would enable plugin extensions to non-variable/function features such as date ranges....) I still don't get it. For a command, the tail of the command line may have been modified already (variable expansion). For a variable function, it certainly is not seeing a command line; rather, it sees its own args (only). And an internal variable sees nothing. The comment in the help specifically mentions all three: "Note that you can use this return value to have your plugin modify the command line and then pass it on to an existing internal variable/function/command!". Is it the case for a command or variable function that returns 0xFEDCBA98, a plugin or built-in command/function with the same name will be called with (exactly) the same argument string (pszArgs)? -- - Vince
On Sat, 27 Mar 2010 15:48:03 -0400, rconn <> wrote: |---Quote--- |> (It might be useful if some future version allowed plugins to |> see/modify the command line for *all* internal commands. It would |> enable plugin extensions to non-variable/function features such as date |> ranges....) |---End Quote--- |Agreed. It might also be useful if the current version allowed this -- |which it does. :-) Let's see ... the plugin author could duplicate every command name ... nah! He could process "Enter" with a keystroke handler and see an unparsed command line ... nah! What did you have in mind? -- - Vince
Or, you could have your PRE_EXEC alias execute your plugin command, which could diddle the command line to your heart's content. Rex Conn JP Software
Actually, the conflict is between the new ISO8601 plugin and RB_UTILS. I want the @ISDATE function of ISO8601. Because the plugins in the directory are loaded in alphabetical order, it just happens to work out correctly for me.
On Sat, 27 Mar 2010 20:10:09 -0400, dcantor <> wrote: |Actually, the conflict is between the new ISO8601 plugin and RB_UTILS. |I want the @ISDATE function of ISO8601. | |Because the plugins in the directory are loaded in alphabetical order, it just happens to work out correctly for me. I suppose you could rename plugin DLLs to get them to load in a specific order. TCC uses their internal names and I'd suppose most plugins (mine I imagine) don't depend of what their filename is. -- - Vince
I did think of that, but aside from the general clumsiness of looking at a raw command line and having to cope with pipes and redirections, command separators, escapes etc., it wouldn't work at all with batch files. That's better, although I think a means for plugins to hook in directly instead of having to define an alias would be neater. (Would PRE_EXEC work with lines read from a batch file?) No, I don't actually have a burning need for this. Massaging date ranges is not something that I really want to implement, just a trivial example.
