Duplicate (conflicting) names

[dcantor]

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

 

[rconn]

> 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".)

The first one loaded.

Rex Conn
JP Software

 

[dcantor]

The first one loaded.

Rex Conn
JP Software

Thank you. Since it's deterministic, I can load the plugins in a particular order to get the version I want.

 

[Steve Fabian]

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

 

[Steve Fabian]

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

 

[rconn]

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

That's correct (and in the docs).

 

[vefatica]

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

 

[Charles Dye]

What do you mean by "modify the command line".

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

 

[rconn]

> (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

 

[vefatica]

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

 

[vefatica]

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

 

[Charles Dye]

Agreed. It might also be useful if the current version allowed this -- which it does. :-)

Really? What am I missing?

 

[rconn]

> ---Quote (Originally by rconn)---
> Agreed. It might also be useful if the current version allowed this --
> which it does. :-)
> ---End Quote---
> Really? What am I missing?

Keystroke plugins.

Rex Conn
JP Software

 

[rconn]

> ---Quote (Originally by rconn)---
> Agreed. It might also be useful if the current version allowed this --
> which it does. :-)
> ---End Quote---
> Really? What am I missing?

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

 

[dcantor]

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

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.

 

[vefatica]

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

 

[Charles Dye]

Keystroke plugins.

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.

Or, you could have your PRE_EXEC alias execute your plugin command, which could diddle the command line to your heart's content.

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.