Heyho,
Klemens Nanni wrote:
> >>> arg.h is really ugly code and way to complex for tools like slock that
> >>> have such minimal synopsis.
> >>
> >> it's a bit of "macro magic", but not really that complex if you think about
> >> it. Also, the usage within the code is dead simple and straightforwa
On Sat, Oct 29, 2016 at 10:49:03PM +0200, Klemens Nanni wrote:
arg.h is really ugly code and way to complex for tools like slock that
have such minimal synopsis.
it's a bit of "macro magic", but not really that complex if you think
about it. Also, the usage within the code is dead simple and
st
On Sat, Oct 29, 2016 at 08:39:07PM +0200, Laslo Hunhold wrote:
On Fri, 28 Oct 2016 22:56:14 +0200
Klemens Nanni wrote:
Hey Klemens,
arg.h is really ugly code and way to complex for tools like slock that
have such minimal synopsis.
it's a bit of "macro magic", but not really that complex if
On Fri, 28 Oct 2016 22:56:14 +0200
Klemens Nanni wrote:
Hey Klemens,
> arg.h is really ugly code and way to complex for tools like slock that
> have such minimal synopsis.
it's a bit of "macro magic", but not really that complex if you think
about it. Also, the usage within the code is dead sim
On 2016-10-28 23:56, Klemens Nanni wrote:
arg.h is really ugly code and way to complex for tools like slock that
have such minimal synopsis.
it's not ugly, you just can't wrap your head around it, it's just a unix
port of the plan 9 option parser[0]
[0]: http://9p.io/sources/plan9/sys/include/
arg.h is really ugly code and way to complex for tools like slock that
have such minimal synopsis.
Regardless of that, usage() does not have to be a function of it's own
if it's called just once.
This (hopefully) is the final commit implementing proper command-line
pargsing adhering to the POSIX
