Re: auto list choices

[Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx>]

On Mar 10, 12:45am, joe M wrote:
}
} gmail is adding application/octet-stream. I will send both the .zsh
} file and a .txt file.

Amusingly, ".zsh.txt" sets off my anti-virus because it appears to be
one file type masquerading as another.

Gmail is a bit of a conundrum for this list, because we'd actually prefer
that code/patches/etc. be pasted in-line rather than attached, but then
you get into line-wrapping/reformatting issues.

Here's a thought (I haven't tried it yet) -- try adding a definition for
the ".zsh" extension in your ~/.mime.types file or the equivalent and
restart your web browser.  Maybe the browser will pick that up and send
that file type to gmail when the attachment is uploaded.

} On a slightly different note, I do not feel comfortable using the ((
} .. )) construct as it does not show up properly in the xtrace/verbose
} log. This is how it shows up.
} 
} +limit-completion:21> (( compstate[list_lines] > 60         ||
} compstate[list_lines]+BUFFERLINES+2 > LINES ))

This is somewhat related to the thread I started a few days ago about
expansions not showing up when xtracing array subscripts.  What both
of those have in common is that it would sometimes be nice to trace
the details of parameter expansion and math evaluation.

The trouble is that doing so would produce a LOT of output, often not
ordered in a way that a reader could easily follow.  Hard to find the
right balance.

Anyway you can use the (( )) expression but also expand the parameters
explicitly rather than implicitly:

    (( $compstate[list_lines] > 60 ||
       $compstate[list_lines]+$BUFFERLINES+2 > $LINES )) 

which traces like

    zsh:4> ((  10 > 60 ||
         10+24+2 > 24  ))

You do need to be a bit more careful that the expansions won't result in
empty strings and thereby cause a syntax error.  (It'd be nice if the
trace did something a little more sensible with the embedded newline.)

} I could not figure out why the below lines do not work. They return a blank.
} 
}    echo "4: $(expr ${compstate[list_lines]})"
}    echo "5: $(expr $compstate[list_lines])"
}    echo "6: $(expr $compstate[list_lines] + $BUFFERLINES)"
}    echo "7: $(expr $compstate[list_lines] + $BUFFERLINES + 2)"
} 
} They are in lines 42 .. 45 of the attached script.

Hmm, I have no idea either -- it works for me.

----- no idea why these below lines do not work
: limit-completion:14:cursh cmdsubst; expr 78
: limit-completion:14:cursh; echo '4: 78'
4: 78
: limit-completion:15:cursh cmdsubst; expr 78
: limit-completion:15:cursh; echo '5: 78'
5: 78
: limit-completion:16:cursh cmdsubst; expr 78 + 1
: limit-completion:16:cursh; echo '6: 79'
6: 79
: limit-completion:17:cursh cmdsubst; expr 78 + 1 + 2
: limit-completion:17:cursh; echo '7: 81'
7: 81
: limit-completion:18:cursh; echo '----- no idea why the above lines do not
work
'
----- no idea why the above lines do not work

Comparing that to your output, you're missing the "cmdsubst" lines for
expr; you should have two lines of trace for source lines 14-17 the
same way you do for source lines 12 and 23.  I suspect some kind of a
race condition between the parent shell and the $(expr ...) subshell
both writing to the same descriptors, though I'm not sure why it would
only crop up in that specific spot.

Replace the $(expr ...) with $(( ... )) and see if that "fixes" it.