Re: [PATCH 0/9] argument parsing fixes and improvements

On Sat, 30 Sep 2017, Jani Nikula wrote: > Looking at the defaults from another angle, if we don't want the ability > to set --foo=default explicitly, I still think passing ints as booleans > to the argument parser and checking if a boolean is neither true nor > false is the wrong

[PATCH] cli: use designated initializers for opt desc

Several changes at once, just to not have to change the same lines several times over: - Use designated initializers to initialize opt desc arrays. - Only initialize the needed fields. - Remove arg_id (short options) as unused. - Replace opt_type and output_var with several type safe output

Re: [PATCH 0/6] Sort by from and subject

Hi On Sat, 30 Sep 2017, Jani Nikula wrote: > On Sat, 30 Sep 2017, William Casarin wrote: >> Jani Nikula writes: >> >>> I think there are two considerations here: >>> >>> First, is this something we want to have? Is this generally useful? >> >>

Re: [PATCH 0/6] Sort by from and subject

On Sat, 30 Sep 2017, William Casarin wrote: > Jani Nikula writes: > >> I think there are two considerations here: >> >> First, is this something we want to have? Is this generally useful? > > Sorting by from and subject are in most mail clients (mutt, gnus,

Re: [PATCH 0/6] Sort by from and subject

Hey Jani, Jani Nikula writes: > I think there are two considerations here: > > First, is this something we want to have? Is this generally useful? Sorting by from and subject are in most mail clients (mutt, gnus, outlook...) > There's still the issue of From: and Subject:

Re: [PATCH 0/6] Sort by from and subject

On Mon, 25 Sep 2017, William Casarin wrote: > This patch series replaces my original set[1]. I've been using this > extensivly for about 3 weeks now and I'm pretty happy with it. I've > added the ability to change sort-order on the fly with the O key > binding. I think there are

Re: [PATCH 0/9] argument parsing fixes and improvements

On Mon, 25 Sep 2017, David Bremner wrote: > Daniel Kahn Gillmor writes: >> So from an implementation point of view, it's definitely cleaner/simpler >> to have an internally "explicitly unset" state for the CLI flags. > > I'm trying to separate-out/defer

Re: notmuch-emacs: Fcc to top-level directory given by database.path

On Sat, 23 Sep 2017, David Bremner wrote: > Do you happen to know if it calls with an empty string as the folder > name? It would be consistent with searching for that to insert at the > top level. notmuch insert --folder= or --folder="" does not work: String argument for

Re: Guess 'From:' when doing notmuch reply

> One option would be for you to customize the output of notmuch-reply in > Emacs. I think the package message-templ (unfortunately only in > marmalade, debian, and my git repo) provides tools that could help with > that. If you want to investigate it's at: > >

Re: notmuch.el: "wash" date in message display

On Thu, 21 Sep 2017, Tomi Ollila wrote: > On Wed, Sep 20 2017, Matt Armstrong wrote: > >> I miss some of the Gnus "wash" functions available for message display. >> There was one that either reformatted the Date: header into my time >> zone, or displayed the Date in terms of

Re: notmuch-emacs: Fcc to top-level directory given by database.path

On Sun, 24 Sep 2017, David Bremner wrote: > Arun Isaac writes: > >>> In any case I've noted your feature request/bug-report. It doesn't sound >>> terribly difficult to change, but it will need someone motivated to >>> think about all of the related