Whitespace-separated arguments

[daniel-shimon]

Hi @anki-code! First of all, really nice work with this repo!

You've clearly put a lot of time and effort into this and I think it really raises the level of the discussion 😄

In the XEP2 proposal, you wrote about whitespace splitting:

Probably we can replace it to something like @($().words). I suggest to think about dropping @$() on final stages. Feel free to create an issue for talking.

So I created an issue to talk about it :)

You write about line-separated arguments in the use cases table:

Use case	Subproc current / proposed	Python current / proposed
Get multiple arguments. ✅ Becomes shorter.	du @($(ls).rstrip().split('\n')) du $(ls)	files = $(ls).rstrip().split('\n') files = $(ls)

Could you add a row about whitespace-separated outputs as well? For example:

groups
# daniel adm dialout cdrom floppy sudo audio dip video plugdev netdev docker

pkg-config --libs libuv
# -luv -lrt -lpthread -lnsl -ldl

(pkg-config's output is used for compilation and has to be passed with each value as a different argument to the compiler).

How do you think these should be handled? We should decide it in this XEP IMO for completeness.

I currently think @$() should stay as-is, currently it's just handy syntactical sugar and can remain so after the XEP.

[anki-code]

Hi @daniel-shimon! Thank you for the feedback! If you like the XEP-2 please star the repo and like the comment in the general discussion.

I currently think @$() should stay as-is, currently it's just handy syntactical sugar and can remain so after the XEP.

I agree. I changed the text of the answer to be more clear:

"Probably we can replace it to something like @($().words). If you really want to drop the @$() operator let's think about it on final stages of this proposal discussing. Feel free to create an issue for talking."

I wrote about dropping @$ not because I suggest it. Anthony wrote before that the reducing of syntax is better than creating new and I added this line keeping his statement in mind. If we really want to reduce operators we can do it completely and drop @$() too :)

Could you add a row about whitespace-separated outputs as well?

I thought that I mentioned it as "Custom output splitting." i.e. this lines is similar:

groups = $(groups).split(' ')
echo @($(groups).split(' '))
echo @$(groups)

If you want to make the calls shorter we can add @$() to python mode or create $().words property as well.

[daniel-shimon]

I thought that I mentioned it as "Custom output splitting." i.e. this lines is similar:

It's not really the same. Whitespace splitting is a pretty common case and is different than just splitting by space since it collapses adjacent whitespace chars.

If we really want to reduce operators we can do it completely and drop @$() too :)

That's what I'm asking about... Doesn't gcc main.c @($(pkg-config --libs libuv).split()) seem like overkill? That's why I think gcc main.c @$(pkg-config --libs libuv) should stay

[anki-code]

That's why I think gcc main.c @$(pkg-config --libs libuv) should stay

I agree. Because @$() operator is not changed in subproc mode in XEP-2 it has no mention in text of changes.

[daniel-shimon]

Cool! So could you remove the idea of removing @$() and add a line about why we want to keep the operator? Maybe in the changes section

It's a part of the subcommand operators so it's relevant to the XEP IMO

[anki-code]

Changed to:

From scopatz: What do we do with the @$() operator? ...

**Answer**: Do nothing because it's a syntax sugar for getting words from output. 
We suggest to keep short calls using this operator unchanged.

Or feel free to suggest more idiomatic sentences.

Maybe in the changes section It's a part of the subcommand operators so it's relevant to the XEP IMO

I prefer the changes section of XEP is to changes. This mention about that @$() has no changes could be very good for your comparison tables in "Re-thinking" issue.