Re: Emacs: postponing messages

[David Bremner]

Brian Sniffen  writes:

> I just found this thread from June while looking to resume a draft saved
> from another program (dovecot) and which was given the 'draft' tag by
> synchronization from Maildir flags.  Mark, thanks!
>
> I *think* all I have to do to deal with other clients accessing the
> Maildir through IMAP is to remove 'Message-ID from message-deletable
> headers, because other clients may be watching for that---though this
> only matters if the draft is resumed and postponed again, rather than
> deleted.
>
> Does that sound right?
>
>   (when draft
>(notmuch-message-unquote-some-mml))
>
> One comment here: anyone using maildir flag synchronization will have
> items with tag:draft but no quoted MML.  To help them reasonably
> *discuss* quoted MML, even when working from a mix of notmuch and other
> MUAs, can this use a distinct tag?  For example, tag:quoted-mml?

I'm not sure if Mark saw this, as it wasn't connected to the original
thread.

d
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch

Re: [PATCH] Add option `hooks.path` for setting the directory of hooks.

[Tomi Ollila]

On Tue, Aug 30 2016, Tomi Ollila  wrote:

> On Tue, Aug 30 2016, Tomi Ollila  wrote:
>
>> On Sat, Aug 27 2016, Erik Rybakken  wrote:
>>
>>> Hi,
>>>
>>> Thanks Tomi and David for the feedback!
>>>
>>> On Fri, Aug 26, 2016 at 02:32:19PM +0300, Tomi Ollila wrote:
>>>
 ... but I can think of one problem there (if my memory server correctly)
>>>
>>> Yeah, I didn't think of that. I have been thinking about how to make the
>>> generated configuration show only the options that differ from the
>>> default, and have the default options commented out, but it got a bit too
>>> involved for me.
>>>
>>> However, I think I have another solution, and I included a updated patch
>>> for this. There is only one (*) difference from the first patch:
>>>
>>> When reading the configuration file and "hooks.path" is either unset or
>>> set to an empty string, we set config->hooks_path to be the expanded
>>> path "database.path/.notmuch/hooks", but we set the value of hooks.path in
>>> config->key_file to be an empty string. That way, when calling
>>> "notmuch_config_get_hooks_path", the expanded path gets returned, but when
>>> saving the config file, either from "notmuch setup" or "notmuch config set",
>>> the value will still be an empty string, given that it wasn't changed.
>>>
>>> I believe this is the easiest fix, and if this sounds good, I will start
>>> working on the tests.
>>
>> I kinda like how this would work...
>>
>> The code looked pretty good -- when did I git am to the email content
>> I got all from the beginning of this email to the commit message --
>> so before next patches use git-format-patch and git-am... Check
>>
>> https://notmuchmail.org/contributing/ for more information...
>>
>> 2 things that came up after quick view
>>
>> 2) I wonder whether calling notmuch_config_get_hooks_path() could
>> be "lazier" ARGH no :( -- it would make notmuch_config_get_hooks_path()
>> have different code than others and ... (**)
>
> That said, perhaps 
>
> const char *
> notmuch_config_get_hooks_path (notmuch_config_t *config)
> {
>  const char * hooks_path =
>  _config_get (config, >hooks_path, "hooks", "path");
>  if (hooks_path == NULL || hooks_path[0] == '\0') {
> hooks_path = talloc_asprintf (config, "%s/.notmuch/hooks",
>   notmuch_config_get_database_path 
> (config));
> _config_set(config, >hooks_path, "hooks", "path", hooks_path);
>  }
>  return hooks_path;
> }
>
> But, it takes quite a bit of careful examination to check whether that works
> as expected, and I always think whether some accidental fragileness there
> causes that stored value to be dumped to the configuration file (now, or
> in later changes).

I forgot that this risk can be mitigated by a set of suitable tests...

>
> But, the above may be useless crap -- just I don't have more time to check
> that out now...
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch

Re: [PATCH] Add option `hooks.path` for setting the directory of hooks.

[Tomi Ollila]

On Tue, Aug 30 2016, Tomi Ollila  wrote:

> On Sat, Aug 27 2016, Erik Rybakken  wrote:
>
>> Hi,
>>
>> Thanks Tomi and David for the feedback!
>>
>> On Fri, Aug 26, 2016 at 02:32:19PM +0300, Tomi Ollila wrote:
>>
>>> ... but I can think of one problem there (if my memory server correctly)
>>
>> Yeah, I didn't think of that. I have been thinking about how to make the
>> generated configuration show only the options that differ from the
>> default, and have the default options commented out, but it got a bit too
>> involved for me.
>>
>> However, I think I have another solution, and I included a updated patch
>> for this. There is only one (*) difference from the first patch:
>>
>> When reading the configuration file and "hooks.path" is either unset or
>> set to an empty string, we set config->hooks_path to be the expanded
>> path "database.path/.notmuch/hooks", but we set the value of hooks.path in
>> config->key_file to be an empty string. That way, when calling
>> "notmuch_config_get_hooks_path", the expanded path gets returned, but when
>> saving the config file, either from "notmuch setup" or "notmuch config set",
>> the value will still be an empty string, given that it wasn't changed.
>>
>> I believe this is the easiest fix, and if this sounds good, I will start
>> working on the tests.
>
> I kinda like how this would work...
>
> The code looked pretty good -- when did I git am to the email content
> I got all from the beginning of this email to the commit message --
> so before next patches use git-format-patch and git-am... Check
>
> https://notmuchmail.org/contributing/ for more information...
>
> 2 things that came up after quick view
>
> 2) I wonder whether calling notmuch_config_get_hooks_path() could
> be "lazier" ARGH no :( -- it would make notmuch_config_get_hooks_path()
> have different code than others and ... (**)

That said, perhaps 

const char *
notmuch_config_get_hooks_path (notmuch_config_t *config)
{
 const char * hooks_path =
 _config_get (config, >hooks_path, "hooks", "path");
 if (hooks_path == NULL || hooks_path[0] == '\0') {
hooks_path = talloc_asprintf (config, "%s/.notmuch/hooks",
  notmuch_config_get_database_path 
(config));
_config_set(config, >hooks_path, "hooks", "path", hooks_path);
 }
 return hooks_path;
}

But, it takes quite a bit of careful examination to check whether that works
as expected, and I always think whether some accidental fragileness there
causes that stored value to be dumped to the configuration file (now, or
in later changes).

But, the above may be useless crap -- just I don't have more time to check
that out now...


___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch

Re: [PATCH] Add option `hooks.path` for setting the directory of hooks.

[Erik Rybakken]

On Tue, Aug 30, 2016 at 08:43:20AM +0300, Tomi Ollila wrote:
> The code looked pretty good -- when did I git am to the email content
> I got all from the beginning of this email to the commit message --
> so before next patches use git-format-patch and git-am... Check
> 
> https://notmuchmail.org/contributing/ for more information...

Sorry about that. I will start checking my email patches.

> 2 things that came up after quick view
> 
> 1) there is one indentation mismatch ;/

I'm not sure what you refer to here. Could you point me to it?

> 3) I don't see any calls to notmuch_config_set_hooks_path()

Yes, that's true. The function is not needed now, but I kept it for
completeness.

So, there are only two places in the code where there are calls to
notmuch_config_set_*. One of them are in the procedure
"notmuch_config_open" in notmuch-config.c where the config file is read.
For hooks_path the reading is done differently as explained in the last
email.

The other place is in notmuch-setup.c, but the notmuch setup does not
(for now) set hooks.path.

The command "notmuch config set" does not use notmuch_config_set for
some reason, but changes the key file directly.

- Erik
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch