Copy/Move dialog and alternative CMD

[admin]

TL;DR: That looks fine!

Qué?

Actually I gonna separate EXE and ARGS template tweaks, because sooner or later this will be elevated to UI in form of two text boxes.

[TheQwerty]

TL;DR: That looks fine!

Qué?

Too Long;Didn't Read. The short version of my post.

Actually I gonna separate EXE and ARGS template tweaks, because sooner or later this will be elevated to UI in form of two text boxes.

Other than when elevated to UI, a single input using:

Code: Select all

"path_to.exe" args <Command>

would make more sense since that is how it is done in the Catalog/UDC.

Though I guess you can make the case that in those instances the single input serves multiple uses.

[TheQwerty]

Looks good.. at least once I figured out that <command> was case sensitive.

For Console using the default startup tab:

Code: Select all

CustomCLI=..\Console\Console.exe
CustomCLIArgs=-r "/k <command>"

For Console using PowerShell (must have defined a tab named "PowerShell"):

Code: Select all

CustomCLI=..\Console\Console.exe
CustomCLIArgs=-t PowerShell -r "-NoExit -Command <command>"

It seems tricky getting the right combination of arguments worked out and as a tweak having to restart XY repeatedly gets old quick. Thankfully it is a set and forget option, at least for me.


However, I'd like to see the general idea of this expanded to Aliases. Thus allowing XY's Aliases to work similarly to Firefox's bookmark keywords or Chrome's keyword searches. So for example say I had an alias that (just for kicks) greeted the user:

Code: Select all

@Greet=::Echo 'Hello, World!';

The expansion of this is to allow the user to enter an alias and some other input that the alias would use:

Code: Select all

@Greet=::Echo 'Hello, <command>!';

Now in the AB they could type:

Code: Select all

@Greet Don

And XY would do:

Code: Select all

::Echo 'Hello, Don!';

Though, unlike CustomCLI, I would suggest that it not auto-append <command> when omitted. The argument could be made either way, but for some reason I think in this instance it would be more confusing... :shrugs:

This could really take aliases to the next level, and it's not hard to imagine the powerful uses this would allow.

[admin]

Looks good.. at least once I figured out that <command> was case sensitive.

For Console using the default startup tab:

Code: Select all

CustomCLI=..\Console\Console.exe
CustomCLIArgs=-r "/k <command>"

For Console using PowerShell (must have defined a tab named "PowerShell"):

Code: Select all

CustomCLI=..\Console\Console.exe
CustomCLIArgs=-t PowerShell -r "-NoExit -Command <command>"

It seems tricky getting the right combination of arguments worked out and as a tweak having to restart XY repeatedly gets old quick. Thankfully it is a set and forget option, at least for me.


However, I'd like to see the general idea of this expanded to Aliases. Thus allowing XY's Aliases to work similarly to Firefox's bookmark keywords or Chrome's keyword searches. So for example say I had an alias that (just for kicks) greeted the user:

Code: Select all

@Greet=::Echo 'Hello, World!';

The expansion of this is to allow the user to enter an alias and some other input that the alias would use:

Code: Select all

@Greet=::Echo 'Hello, <command>!';

Now in the AB they could type:

Code: Select all

@Greet Don

And XY would do:

Code: Select all

::Echo 'Hello, Don!';

Though, unlike CustomCLI, I would suggest that it not auto-append <command> when omitted. The argument could be made either way, but for some reason I think in this instance it would be more confusing... :shrugs:

This could really take aliases to the next level, and it's not hard to imagine the powerful uses this would allow.

Will add CLI to UI soon.

Cool idea with the aliases! Probably I should add a flag to allow this sort of replacement to avoid breaking old aliases. And maybe I should allow more than one... <param1>

Code: Select all

@Greet=::Echo 'Hello, <param1>! <param2>';
@Greet Don, Hungry?
::Echo 'Hello, Don! Hungry?';

[TheQwerty]

Cool idea with the aliases! Probably I should add a flag to allow this sort of replacement to avoid breaking old aliases. And maybe I should allow more than one... <param1>

Code: Select all

@Greet=::Echo 'Hello, <param1>! <param2>';
@Greet Don, Hungry?
::Echo 'Hello, Don! Hungry?';

I'm not sure a flag is really needed, at least if you do not append on omission. What are the chances someone is already using whatever pattern you'll be replacing?

The ability to replace multiple parameters would be nice, so long as there is a variable for the non-split input as well. I was holding back so as to not scare you away from implementing this.

[admin]

Cool idea with the aliases! Probably I should add a flag to allow this sort of replacement to avoid breaking old aliases. And maybe I should allow more than one... <param1>

Code: Select all

@Greet=::Echo 'Hello, <param1>! <param2>';
@Greet Don, Hungry?
::Echo 'Hello, Don! Hungry?';

I'm not sure a flag is really needed, at least if you do not append on omission. What are the chances someone is already using whatever pattern you'll be replacing?

The ability to replace multiple parameters would be nice, so long as there is a variable for the non-split input as well. I was holding back so as to not scare you away from implementing this.

Currently alias names can contain any character apart from "=", so that also includes " " (space). So @Greet Don could also be an alias name. I'm still looking for a solution (w/out breaking old user code)...

[TheQwerty]

Currently alias names can contain any character apart from "=", so that also includes " " (space). So @Greet Don could also be an alias name. I'm still looking for a solution (w/out breaking old user code)...

Well that was dumb! Why'd we let you do that?

I wonder how much would break if you just removed space from the acceptable alias name characters. There can't be that many fools err.. people that used it right?

Well then I'm not sure what's most important to you (having O(1) for the alias lookup vs. complicating syntax vs pleasing those fools), so I'm not sure what to recommend. I'm thinking of a few solutions but I wouldn't be pleased by the fact that none of them are elegant.

[admin]

Currently alias names can contain any character apart from "=", so that also includes " " (space). So @Greet Don could also be an alias name. I'm still looking for a solution (w/out breaking old user code)...

Well that was dumb! Why'd we let you do that?

I wonder how much would break if you just removed space from the acceptable alias name characters. There can't be that many fools err.. people that used it right?

Well then I'm not sure what's most important to you (having O(1) for the alias lookup vs. complicating syntax vs pleasing those fools), so I'm not sure what to recommend. I'm thinking of a few solutions but I wouldn't be pleased by the fact that none of them are elegant.

I think I go this way:
1) remove space from the acceptable alias name characters
2) on upgrading replace any spaces in alias names with underscores; pop a message about this
3) if 2) generates doublettes (now that would be clearly 2nd level fools) attach increment suffix until name is unique

The alias-avec-args idea is just too good to give up now...

[TheQwerty]

*ahem*

The ability to replace multiple parameters would be nice, so long as there is a variable for the non-split input as well. I was holding back so as to not scare you away from implementing this.

<@0> would be fine.

Also you may want to clean up the BETA post as you switch between using <@a#> and <@#> repeatedly.

Aside from those it looks good, now I just have to find the time to play with it. Thank you, Don!

[Stefan]

- If you define an <@#> but didn't pass an argument, then the placeholders are shown/used in output as it.

Code: Select all

      Example 3:
        Define alias:
          @Greet=::echo "Hello, <@1>! It's <@2>!";
        Use alias:
          @Greet Don
        Resolved alias:
          ::echo 'Hello, Don! It's <@2>!';      

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 !';      

[TheQwerty]

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

The only problem with this is how can you then tell the difference between an omitted placeholder and one that is empty? However, I don't foresee the need for that, so I agree with Stefan.

---

A little fun one for everyone. Paste this in the address bar (if you don't already have an alias "@@"):

Code: Select all

@@=::$a=("<@1>" UnLike ('<'.'@1>')) ? "<@1>" : Input('Create New Alias',"Enter an alias name (without @) for:<crlf><curpath>",RegexReplace("<curfolder>",'[ =]','_'),'s');goto("@$a=<curpath>");

Now you have a shortcut to create an alias for the current path.
"@@" will prompt you for the alias name (defaulting to the current directory)
and
"@@ Harold" will create the alias "@Harold".

[Stefan]

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

Some examples for user didn't know what alias can be good for:

Code: Select all

Alias:	 @=::#633;
CMD:		@@
Result:	opens List Management > Aliases


Alias:	 T=::copytext <@1> <date>;
CMD:		@T File downloaded at
Result:	new clip board content: "File downloaded at 14.04.2011 13:59:10"


Alias:	 send=::copytext File "<curname>" send at <date> to <@1>;
CMD:		@send Mr. Don
Result:	new clip board content: File "lizenz.txt" send at 14.04.2011 14:01:05 to MrDon"


Alias:	 N=::run notepad "<curitem>";
CMD:		@N
Result:	opens notepad with current selected file

Alias:	 U=::goto "%personal%";
Alias:	 u=::goto "%UserProfile%";
Result:	opens folder in current pane

[admin]

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

[admin]

*ahem*

The ability to replace multiple parameters would be nice, so long as there is a variable for the non-split input as well. I was holding back so as to not scare you away from implementing this.

<@0> would be fine.

Ah! I was already wondering what this sentence meant. OK, makes sense.

[admin]

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