Re: Is there any possible way to automatically escape characters when executing an alias in zsh?

[Steve Dondley <s@dondley.com>]

> If you're never using these commands in any sort of pipeline or other
> structured shell input, why are you using a general-purpose shell for
> this at all?  Why not write a taskwarrior front-end that does nothing
> but read literal lines without interpretation and pass them along?

This is how taskwarrior works out of the box, through the shell. Others 
have written front ends for TW: https://github.com/vit-project/vit

But I'm 99% happy using TW through the command line especially since it 
allows me to write my own functions to speed up entering tasks with 
command arguments I use regularly. It wouldn't be a good idea to throw 
out the baby with the bath water and write my own front end or move to 
some front end that I may or may not be able to hack to behave as I wish 
to address this minor annoyance.

> I think you'll find it's the shell that's removing (interpreting) the
> quotes, not taskwarrior.

Ok, yeah, didn't think about that.

> But you aren't interacting with "an application" in the sense that you
> mean it.  You're interacting with the shell, which has explicit syntax
> rules so that you can precisely describe what you intend to have it
> do.

I don't agree with this statement. If I launch a command with the shell 
and pass it some argument to open up a full-blown GUI for with a 
particular color theme, that doesn't mean I'm interacting with the 
shell. The shell is just a useful go-between and then it gets out of my 
way. Similarly, the shell is just a useful go-between for manipulating 
the TW database. I (usually) want it to get out of the way and leave me 
alone when I do that. I only want the shell to reveal itself at the 
appropriate times (like writing aliases and functions). But the more it 
can get out of the way when I'm trying to achieve my goal of 
manipulating the TW database, the better. For me to have to worry about 
making the shell happy when entering tasks is a nuisance I'd prefer not 
to deal with.

> You're in effect arguing that this input should not be on a shell
> command line and instead should always be consumed separately, so that
> the shell doesn't have to interpret it first.

No, I'm saying that I personally would like to get the best of both 
worlds, if possible. And why wouldn't I?

And what could possibly be the harm in having the shell do some typing 
for me without me having to think about it? Isn't that what computers 
are for, to automate things for us?

> If the only thing that ever follows "tasn" is something that's
> supposed to be a human-readable sentence interpreted exactly as typed,
> you can skip the whole business of messing about with checking for
> quotes etc., but the fact that you're worried about autocompletion
> suggests that is not the case.

Correct, I can type in pro<tab> and it will autocomplete to "project:" 
for me. It can also autocomplete project names as and perform other 
minor completions (none of which will ever contain special characters 
that need to be escaped).

> I'm going to assume that the trailing backquote there is a typo.
> Here's a modification of PWS's widget, that really does take
> everything after the word "tasn" (or any other word beginning with
> "ta" or "tm") as raw human-readable text:
> 
> taskwarrior-literal() {
>   setopt localoptions extendedglob
>   local -a match
>   # Assumes human never types tab or backslash
>   # and everything after the first word is literal
>   if [[ -z ${BUFFER/(#s)(#b)((ta|tm)[a-z](#c1,) )(*)/} &&
>         $match[3] != *\\* ]]
>   then BUFFER="$match[1] ${(@q)${=match[3]}}"
>   fi
> }
> zle -N taskwarrior-literal
> autoload add-zle-hook-widget
> add-zle-hook-widget line-finish taskwarrior-literal

Yeah, so I don't think this would work because I need <tab> for 
autocompletion. Or am I not understanding this?