Copy/Move dialog and alternative CMD

[Stefan]

I think, if an defined placeholder is not used while executing an alias
then the placeholder should be dropped instead used as output.

Code: Select all

        Resolved alias:
          ::echo 'Hello, Don! It's !';      

I don't agree for 2 reasons:
1) The placeholder might be not meant to be placeholder but part of the hard input. Not likely but possible.
2) It would be more work for me to remove unknown placeholders. Needs to scan the string for "<@[number]>".

OK, i was just wondering if one would define an alias like

Code: Select all

myAlias=::run <@1> <@2> <@3> <@4> <@5> <@6>
CMD:     myTool.exe  <curitem> /para /para2
Result:   myTool.exe  C:\Temp\file.ext /para /para2  <@5> <@6>

I can imaging that those "<" ">" signs could lead to unwanted results? (don't want to test this right now)

My suggestion would be like in DOS batch: %1 %2 %3 %4 %5 %6
where the un-used paras are just dropped instead of showing %5 %6 in the output.


- - -

While playing around i have found an problem by using an dot with my "@send" alias (have tried several kind of quoting)

Try this, else the dot in "Dr. Don" is seen by copytext as concatenator:

Code: Select all

send=::copytext "File <curname> send at <date> to " . '<@1>';

Yes of course
Give me a few hours and i had see it my own

Code: Select all

send=::copytext "File " . quote("<curname>") . " send at <date> to " .  '<@1>';

[admin]

OK, i was just wondering if one would define an alias like

Code: Select all

myAlias=::run <@1> <@2> <@3> <@4> <@5> <@6>
CMD:     myTool.exe  <curitem> /para /para2
Result:   myTool.exe  C:\Temp\file.ext /para /para2  <@5> <@6>

I can imaging that those "<" ">" signs could lead to unwanted results? (don't want to test this right now)

Yes, may be. Or even probably. Not 100% sure yet.

[TheQwerty]

OK, i was just wondering if one would define an alias like

Code: Select all

myAlias=::run <@1> <@2> <@3> <@4> <@5> <@6>
CMD:     myTool.exe  <curitem> /para /para2
Result:   myTool.exe  C:\Temp\file.ext /para /para2  <@5> <@6>

I can imaging that those "<" ">" signs could lead to unwanted results? (don't want to test this right now)

Yes, may be. Or even probably. Not 100% sure yet.

In this case anyhow, <@0> would be the answer, as then you wouldn't need to put all those placeholders in your script.

It's not pretty but you can test if it's been set using:

Code: Select all

"<@1>" Like ('<'.'@1>')

As I said earlier I'm not opposed to XY stripping unused <@#> out, and really Don, I think you could make this easier by capping it to 9 placeholders - it's nice that it supports at least 1000 but it's a bit overkill. If the user needs more maybe they should consider splitting the input themselves.

[admin]

As I said earlier I'm not opposed to XY stripping unused <@#> out, and really Don, I think you could make this easier by capping it to 9 placeholders - it's nice that it supports at least 1000 but it's a bit overkill. If the user needs more maybe they should consider splitting the input themselves.

Good, done.

[TheQwerty]

Okay Don, these parametrized aliases are incredibly awesome!

However , I have one more, and hopefully last, request:

Code: Select all

<@#[OmittedValue]>

Thus, instead of XY removing unused placeholders this would replace them with the specified OmittedValue.

A small example that just maps the scripting command SelFilter to an alias @s. If I do not want the same defaults as SelFilter's omitted defaults then I need to test the placeholders and may end up with something like:

Code: Select all

@s=::SelFilter("<@1>","<@2>"?"<@2>":"f","<@3>"?"<@3>":"Name","<@4>"?"<@4>":"0");

but with this proposal that could be reduced to:

Code: Select all

@s=::SelFilter("<@1>","<@2 f>", "<@3 Name>", "<@4 0>");

which I think we can all agree is a huge improvement in legibility.

[admin]

Okay Don, these parametrized aliases are incredibly awesome!

However , I have one more, and hopefully last, request:

Code: Select all

<@#[OmittedValue]>

Thus, instead of XY removing unused placeholders this would replace them with the specified OmittedValue.

A small example that just maps the scripting command SelFilter to an alias @s. If I do not want the same defaults as SelFilter's omitted defaults then I need to test the placeholders and may end up with something like:

Code: Select all

@s=::SelFilter("<@1>","<@2>"?"<@2>":"f","<@3>"?"<@3>":"Name","<@4>"?"<@4>":"0");

but with this proposal that could be reduced to:

Code: Select all

@s=::SelFilter("<@1>","<@2 f>", "<@3 Name>", "<@4 0>");

which I think we can all agree is a huge improvement in legibility.

Yup, makes sense. But the parsing then becomes difficult if not a can of worms. Needs a little thinking...

Imagine you do evil things like this:

Code: Select all

@s=::SelFilter("<@1 <@2>>","<@2 <@1>>");

[TheQwerty]

Yup, makes sense. But the parsing then becomes difficult if not a can of worms. Needs a little thinking...

Imagine you do evil things like this:

Code: Select all

@s=::SelFilter("<@1 <@2>>","<@2 <@1>>");

Fair enough, I wasn't considering the ability to nest variables. I was more meaning for this to be a way to improve/simplify what is likely to be a common scenario not an end-all solution, so prohibiting nested variables would be okay by me. After all, the user can always do these more advanced replacements with scripting, it just won't be as pretty/easy.

Don't you handle a lot of the complications already with <get...>?

Code: Select all

::echo("<get Tree <curpath><crlf>>");

From you example given <@1>='One', and <@2> is omitted, you replace <@1...> and get (focusing on strings):

Code: Select all

"One","<@2 One>"

and then replace <@2...> and arrive at:

Code: Select all

"One","One"

The more complicated case to me is sanitizing user input as in this case which is not handled clearly currently:

Code: Select all

@test=::Echo("<@0><@1><@2>");

"@test" => ""
"@test A" => "AA"
"@test A,B" => "A,BAB"
"@test A,<@0>" => "A,<@0>A<@0>"
"@test A,<@1>" => "A,AA<@1>"

Don't we actually want the last one to result in "A,<@1>A<@1>"?

If it were me I'd probably be attempting to tackle this entire parsing nightmare with a shunting yard and RPN evaluator implementation, but I wouldn't be surprised at all to discover there's a much better way.

[admin]

I think I sorted it out. Check out next beta...

[TheQwerty]

k I sorted it out. Check out next beta...

Looks good to me; this just got awesome!

[admin]

k I sorted it out. Check out next beta...

Looks good to me; this just got awesome!

Great!

Since you more or less invented this feature and I don't have the time to use it (yet!): Is anybody apart from TheQwerty enjoying this probably completely awesome feature? It looks like a vast time and error saver for typists...