Oh my goodness. I just tried
http://github.com/dme/notmuch/raw/dme-play/emacs/notmuch-address.el
together with the latest version of my "addrlookup" tool (which does the
same as jkr's notmuch_addresses.py) and it just works, even in current
cworth/master.
Address completion for to: and cc: headers
On Tue, 20 Apr 2010 23:33:11 +0200, "Sebastian Spaeth"
wrote:
> Oh my goodness. I just tried
> http://github.com/dme/notmuch/raw/dme-play/emacs/notmuch-address.el
> together with the latest version of my "addrlookup" tool (which does the
> same as jkr's notmuch_addresses.py) and it just works, ev
On Tue, 20 Apr 2010 23:33:11 +0200, "Sebastian Spaeth" wrote:
> Oh my goodness. I just tried
> http://github.com/dme/notmuch/raw/dme-play/emacs/notmuch-address.el
> together with the latest version of my "addrlookup" tool (which does the
> same as jkr's notmuch_addresses.py) and it just works, eve
Oh my goodness. I just tried
http://github.com/dme/notmuch/raw/dme-play/emacs/notmuch-address.el
together with the latest version of my "addrlookup" tool (which does the
same as jkr's notmuch_addresses.py) and it just works, even in current
cworth/master.
Address completion for to: and cc: headers
On Tue, 20 Apr 2010, David Edmondson wrote:
> On Tue, 20 Apr 2010 12:14:56 +0200, Michal Sojka
> wrote:
> > > I'm puzzled why you chose to pass a filename as the argument to 'cat'
> > > rather than a message id (id:foo at bar.com)?
> >
> > The reason is that I want be able to distinguish betwe
On Tue, 20 Apr 2010 13:13:36 +0200, Michal Sojka wrote:
> On Tue, 20 Apr 2010, David Edmondson wrote:
> > On Tue, 20 Apr 2010 12:14:56 +0200, Michal Sojka
> > wrote:
> > > > I'm puzzled why you chose to pass a filename as the argument to 'cat'
> > > > rather than a message id (id:foo at bar.co
On 20.4.2010 09:21, David Edmondson wrote:
> On Tue, 20 Apr 2010 09:16:32 +0200, Michal Sojka
wrote:
>> This command dumps a raw message identified by a filename to the
>> standard output. It allows MUAs to access the messages for piping,
>> attachment manipulation, etc. in the same way as i
On Tue, 20 Apr 2010 12:14:56 +0200, Michal Sojka wrote:
> > I'm puzzled why you chose to pass a filename as the argument to 'cat'
> > rather than a message id (id:foo at bar.com)?
>
> The reason is that I want be able to distinguish between several
> messages with the same id.
It strikes me th
> I'm puzzled why you chose to pass a filename as the argument to 'cat'
> rather than a message id (id:foo at bar.com)?
I agree, especially as some people want to introduce abstract mailstores
which might not even have the concept of a file name :).
Passing a message-id seems more useful.
Sebast
On 2010-04-20, micah anderson wrote:
> It would be great if this became a key to make this easier. In mutt,
> that key is 'b', which prompts you who you should send the message
> to. That key is already bound to showing the body in notmuch, but I'm
> sure there are other options.
I'm pretty sure,
- "Carl Worth" a ?crit :
> Once we fix that, I think we can go back to having tag operations
> only
> affect matched messages in the search view, and I agree that this
> will
> be extremely convenient.
>
What about using prefixes to each command, the way Gnus does it*? For instance,
'd' s
not available
URL:
<http://notmuchmail.org/pipermail/notmuch/attachments/20100420/96bfc301/attachment-0001.pgp>
On Tue, 20 Apr 2010 06:27:02 +0100, David Edmondson wrote:
> The second chunk was intended to cover a similar case (len == 0), but
> becomes unnecessary after the first chunk. At least, that's what I
> convinced myself after the conversation with Anthony Towns
> (id:h2y87b3a4191004060117v5421db8ej
ot some
confusion about "body visible" vs. "message visible" that I want to fix
before pushing).
-Carl
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL:
<http://notmuchmail.org/pipermail/notmuch/attachments/20100420/479ca685/attachment.pgp>
The following commands now access the messages via the cat subcommand:
view/save attachments, view raw message and pipe message to command.
With this patch, it is straightforward to use notmuch emacs interface
with a remote database accessed over SSH. To do this, it is sufficient
to redefine notmu
This command dumps a raw message identified by a filename to the
standard output. It allows MUAs to access the messages for piping,
attachment manipulation, etc. in the same way as it is done in
notmuch-show-mode (through notmuch show subcommand). This will simplify
the MUAs when they need to opera
looked into
that?
jamie.
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: not available
URL:
<http://notmuchmail.org/pipermail/notmuch/attachments/20100420/bcb92133/attachment.pgp>
> There's already a check in json_quote_chararray for len==0, so it
> might be sensible to say:
>
> return (json_quote_chararray (ctx, str, str != NULL ? strlen (str) : 0));
>
> OTOH, the code in json_quote_array to deal with that does the same
> thing (returns a literal string containing two
array.
I've pushed this out now, (separated into two pieces).
-Carl
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL:
<http://notmuchmail.org/pipermail/notmuch/attachments/20100420/8b505c7f/attachment.pgp>
On Tue, 20 Apr 2010 09:16:32 +0200, Michal Sojka wrote:
> This command dumps a raw message identified by a filename to the
> standard output. It allows MUAs to access the messages for piping,
> attachment manipulation, etc. in the same way as it is done in
> notmuch-show-mode (through notmuch show
On Tue, 20 Apr 2010 12:14:56 +0200, Michal Sojka wrote:
> The reason is that I want be able to distinguish between several
> messages with the same id. Consider a message sent to a list. One copy
> is stored in your sent folder and one in another folder. You may want to
> investigate the Receiv
On Mon, 19 Apr 2010 11:07:40 -0700, Carl Worth wrote:
> > commit 8586a86b9dd4ed2406a2fbda6c08bdc6a598cfd8
> > debian: git should ignore packaging intermediate files
>
> I committed an alternate version of this, (with a new debian/.gitignore
> file). I used more wildcarding too. And I couldn'
On Tue, 20 Apr 2010 10:07:21 +0200, "Sebastian Spaeth"
wrote:
> On 2010-04-20, micah anderson wrote:
> I'm pretty sure, we can get a nice keybinding that invokes message mode's
> "message-resend" function or something similar. The only disadvantag is
> that it asks for the mail address in the min
On Tue, 20 Apr 2010 13:13:36 +0200, Michal Sojka wrote:
> On Tue, 20 Apr 2010, David Edmondson wrote:
> > On Tue, 20 Apr 2010 12:14:56 +0200, Michal Sojka
> > wrote:
> > > > I'm puzzled why you chose to pass a filename as the argument to 'cat'
> > > > rather than a message id (id:f...@bar.com)
On Tue, 20 Apr 2010, David Edmondson wrote:
> On Tue, 20 Apr 2010 12:14:56 +0200, Michal Sojka wrote:
> > > I'm puzzled why you chose to pass a filename as the argument to 'cat'
> > > rather than a message id (id:f...@bar.com)?
> >
> > The reason is that I want be able to distinguish between se
On Tue, 20 Apr 2010 12:14:56 +0200, Michal Sojka wrote:
> > I'm puzzled why you chose to pass a filename as the argument to 'cat'
> > rather than a message id (id:f...@bar.com)?
>
> The reason is that I want be able to distinguish between several
> messages with the same id.
It strikes me that
On 20.4.2010 09:21, David Edmondson wrote:
> On Tue, 20 Apr 2010 09:16:32 +0200, Michal Sojka
wrote:
>> This command dumps a raw message identified by a filename to the
>> standard output. It allows MUAs to access the messages for piping,
>> attachment manipulation, etc. in the same way as it i
> I'm puzzled why you chose to pass a filename as the argument to 'cat'
> rather than a message id (id:f...@bar.com)?
I agree, especially as some people want to introduce abstract mailstores
which might not even have the concept of a file name :).
Passing a message-id seems more useful.
Sebastia
On 2010-04-20, micah anderson wrote:
> It would be great if this became a key to make this easier. In mutt,
> that key is 'b', which prompts you who you should send the message
> to. That key is already bound to showing the body in notmuch, but I'm
> sure there are other options.
I'm pretty sure,
- "Carl Worth" a écrit :
> Once we fix that, I think we can go back to having tag operations
> only
> affect matched messages in the search view, and I agree that this
> will
> be extremely convenient.
>
What about using prefixes to each command, the way Gnus does it*? For instance,
'd' s
Hi,
GNU Emacs interface comes with 2 functions I am not sure I am
using correctly.
What's the difference between searching and filtering exactly (s
and f) ? It seems to me that they deserve the same purpose.
Regards,
Xavier
On Tue, 20 Apr 2010 09:16:32 +0200, Michal Sojka wrote:
> This command dumps a raw message identified by a filename to the
> standard output. It allows MUAs to access the messages for piping,
> attachment manipulation, etc. in the same way as it is done in
> notmuch-show-mode (through notmuch show
This command dumps a raw message identified by a filename to the
standard output. It allows MUAs to access the messages for piping,
attachment manipulation, etc. in the same way as it is done in
notmuch-show-mode (through notmuch show subcommand). This will simplify
the MUAs when they need to opera
The following commands now access the messages via the cat subcommand:
view/save attachments, view raw message and pipe message to command.
With this patch, it is straightforward to use notmuch emacs interface
with a remote database accessed over SSH. To do this, it is sufficient
to redefine notmu
34 matches
Mail list logo
