From: Ruthard Baudach <ruthard.baudach@web.de>
To: Gaute Hope <eg@gaute.vetsj.com>
Cc: supmua <supmua@googlegroups.com>
Subject: Re: [sup] [PATCH] added command line argument to sup invocation: "sup email-address" invokes sup in command line
Date: Fri, 14 Nov 2014 22:48:46 +0100 [thread overview]
Message-ID: <1416000203-sup-9655@ruthard-lappi> (raw)
In-Reply-To: <1415959463-astroid-0-4xu4dq0h0g-7223@strange>
[-- Attachment #1: Type: text/plain, Size: 2202 bytes --]
>== Auszüge aus der Nachricht von Gaute Hope vom 2014-11-14 11:13:
> got a few comments below [btw: it is better to send a completely new
> patch with your changes squashed together than to send incremental
> changes to the first patch].
I still have to master this "stupid content tracker". Hope to figure it
out.
> > Sup is a curses-based email client.
> >
> > Usage:
> > - sup [options]
> > + sup [options] [to-address]
> > +
> > +Arguments:
> > + to-address: Compose message to this recipient upon startup
> > + --compose overrides an address passed as argument
>
> ^^ i think it would be better to fail if --compose is specified in addition to
> an unnamed argument, what happens if i want to specify many addresses?
> what do you think?
I had trouble to figure out how --compose works. As far as I found out
by now it accepts exact ONE argument, which might be a string containing
a list of well formatted email addresses. No checks are done,
sup --compose "This is all a terrible nonsense"
will happily compose an email with a "To: This is all a terrible
nonsense" header.
Thus I think I could just add the arguments to compose and ARGV.join(' '),
check this combined address list with RMail::Address.parse, inform the
user if the mails are not well formed, and pass the list happily to the
existing code
This way the option --compose and any command arguments would work
seamlessly together.
What do you think?
> >
> > +## Trollop does no command argument parsing, only option parsing.
> > +# After Trollop parsing, ARGV contains only the +rest+ of the command line,
> > +# thus the arguments to our program
> > +## compose message if we have an email address as first command line argument
>
> add '.'
sorry, yes
> , why different levels of '#' ?
a habit I took from lisp and bash, somehow feels like structuring
comments and code
> try to stay at approx 80
> char width.
I do like Python, my vim is set to tw=80 for all of my work.
Well, usually.
Yours, Ruthard
--
Please encrypt and sign emails.
My PGP-Id: AC5AC6C2
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 473 bytes --]
next prev parent reply other threads:[~2014-11-16 11:12 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-11-08 18:37 Ruthard Baudach
2014-11-14 10:13 ` [sup] " Gaute Hope
2014-11-14 21:48 ` Ruthard Baudach [this message]
2014-11-16 11:17 ` Gaute Hope
2014-11-15 9:57 ` Ruthard Baudach
2014-11-16 11:25 ` Gaute Hope
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1416000203-sup-9655@ruthard-lappi \
--to=ruthard.baudach@web.de \
--cc=eg@gaute.vetsj.com \
--cc=supmua@googlegroups.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox