Hello all!
First congratulations for the nice software! I hardly wait for a
notmuch native (i.e. libnotmuch) and curses client (like `ner`) to
become more stable, and thus I'll be able to ditch GMail. :) But until
then a small glitch...
While upgrading from notmuch 0.4 to 0.5, I've re
On Tue, 16 Nov 2010 15:33:30 +0200, "Ciprian Dorin, Craciun"
wrote:
> But in my particular case `~/.notmuch-config` is symlinked to an
> applications configuration directory which is versioned. Thus I've
> expected than when notmuch updates the config, it opens it for
> read-write, but with t
On 11/16/2010 08:38 AM, Jameson Rollins wrote:
> On Tue, 16 Nov 2010 15:33:30 +0200, "Ciprian Dorin, Craciun"
> wrote:
>> So my question is: is this behaviour (of deleting the file and
>> creating a new one) deliberate? If not, could it be fixed (I could
>> provide a patch) to just update the
'Lo. I've been toying with switching to notmuch for a while, but the
speed of search has been holding me back. Perhaps I should upgrade
the archaic machine I'm trying to run notmuch on, but I figured
optimizing search would be a good way for me to cut my teeth on
notmuch's code. I've implemented
On Tue, 16 Nov 2010 11:18:43 -0500, Austin Clements wrote:
> [1] Except for 2 emacs tests that depend on author order. What order
> are matched authors *supposed* to be in?
In IRC cworth confirmed that he considered the current behaviour a bug,
which is to say that the authors should be sorted b
Message mode uses a different name for composition buffers in newer
versions of emacs. Allow for this when causing the composition window
to overlay the viewing window.
---
I don't understand why Aneesh chose to use `add-hook' and `purecopy'.
emacs/notmuch-mua.el |2 +-
1 files changed, 1 in
Quoth David Edmondson on Nov 16 at 4:58 pm:
> On Tue, 16 Nov 2010 11:18:43 -0500, Austin Clements wrote:
> > [1] Except for 2 emacs tests that depend on author order. What order
> > are matched authors *supposed* to be in?
>
> In IRC cworth confirmed that he considered the current behaviour a b
On Tue, 16 Nov 2010 11:18:43 -0500, Austin Clements wrote:
> 'Lo. I've been toying with switching to notmuch for a while, but the
> speed of search has been holding me back. Perhaps I should upgrade
> the archaic machine I'm trying to run notmuch on, but I figured
> optimizing search would be a
On Tue, 16 Nov 2010 15:33:30 +0200, "Ciprian Dorin, Craciun"
wrote:
> First congratulations for the nice software!
Thanks so much! Welcome to notmuch.
> So my question is: is this behaviour (of deleting the file and
> creating a new one) deliberate? If not, could it be fixed (I could
>
On Mon, 15 Nov 2010 14:21:53 +, David Edmondson wrote:
> ---
> emacs/notmuch-show.el | 12 +++-
> 1 files changed, 7 insertions(+), 5 deletions(-)
Thanks. This is pushed now, with slightly more of a commit message---if
nothing else a little bit more of a commit message would give m
On Sun, 14 Nov 2010 22:52:20 +0100, Michal Sojka wrote:
> I'm sending the fixes to the test suite as responses to this mail.
Excellent fixes, Michal. Thanks so much!
I've pushed these out now, with one tiny followup to remove the
hard-coded:
test_expect_equal '' ''
which looked really
On Sun, 14 Nov 2010 17:09:01 -0500, Jameson Rollins
wrote:
> While these are not currently bound to any keys, I have found them to
> be very useful for constructing custom key bindings outside of what
> notmuch provides by default.
These look fairly handy.
But, since I know our current keybindi
On Sat, 13 Nov 2010 02:55:50 -0500, Daniel Kahn Gillmor
wrote:
> i've been trying to wrap my head around how to get notmuch to support
> verifying cryptographically-signed mail. i'm afraid my current
> understanding of the problem space is that it is neither pretty nor
> clean. Sorry for the le
On Fri, 12 Nov 2010 12:50:02 +, David Edmondson wrote:
> Declare `notmuch-wash-tidy-citations-max', which is the largest region
> that `notmuch-wash-tidy-citations' will attempt to improve.
Hi David,
Could you add a test case for whatever bug is being fixed here?
I'm a little concerned abou
On 11/16/2010 02:47 PM, Carl Worth wrote:
> The current linearization of parts is a bug that should be fixed. And I
> think several aspects of your proposal are effectively workarounds for
> this bug. So I'd rather we fix the json output to emit the tree
> structure first, and then see what parts o
On Tue, 16 Nov 2010 11:47:13 -0800, Carl Worth wrote:
> The only other piece I think I'd like to see is actually making the
> content of the signature pieces available in the json output. Then, a
> client could do its own verification.
>
> Then if we had that would we not want to add the --verify
On 11/16/2010 03:10 PM, Jameson Rollins wrote:
> I would almost say that --verify should be the
> default, with a --no-verify option. It will make things much easier for
> all the UIs if notmuch handles the verification and just outputs the
> result.
For clients that do not know how to interpret/
On Tue, Nov 16, 2010 at 21:09, Carl Worth wrote:
> On Tue, 16 Nov 2010 15:33:30 +0200, "Ciprian Dorin, Craciun"
> wrote:
>> So my question is: is this behaviour (of deleting the file and
>> creating a new one) deliberate? If not, could it be fixed (I could
>> provide a patch) to just update
On 11/16/2010 03:26 PM, Ciprian Dorin, Craciun wrote:
> So in the light of the above quoted "glitches", my question is:
> due to the small chance of a power loss happening right when we write
> such a small file, doesn't the inconvenience weight more than the
> (fairly remote probable) file los
On Tue, 16 Nov 2010 11:35:31 -0800, Carl Worth wrote:
> These look fairly handy.
>
> But, since I know our current keybindings are less-than-perfect, I would
> prefer to see patches that also fix them, (rather than just adding
> functionality that new users can't get at without manual customizati
On 11/16/2010 03:37 PM, Daniel Kahn Gillmor wrote:
> On 11/16/2010 03:26 PM, Ciprian Dorin, Craciun wrote:
>> So in the light of the above quoted "glitches", my question is:
>> due to the small chance of a power loss happening right when we write
>> such a small file, doesn't the inconvenience
On Tue, 16 Nov 2010 15:22:49 -0500, Daniel Kahn Gillmor
wrote:
> For clients that do not know how to interpret/display the verification
> results, i don't want the backend to incur the cost of verification that
> will be thrown away.
Aren't clients going to have to interpret/display the output r
On 11/16/2010 03:44 PM, Jameson Rollins wrote:
> Aren't clients going to have to interpret/display the output regardless
> of it's been verified or not? It seems to me that understanding how to
> display the verified output is really not that much more difficult than
> understanding how to display
On Tue, Nov 16, 2010 at 22:37, Daniel Kahn Gillmor
wrote:
> On 11/16/2010 03:26 PM, Ciprian Dorin, Craciun wrote:
>> P.S.: I say "pseudo" atomic because only the rename is atomic,
>> thus in order to override file `a` for the target file `b` which
>> exists, we must execute two **non-atomic**
On Tue, Nov 16, 2010 at 22:42, Daniel Kahn Gillmor
wrote:
> On 11/16/2010 03:37 PM, Daniel Kahn Gillmor wrote:
>> On 11/16/2010 03:26 PM, Ciprian Dorin, Craciun wrote:
>>> So in the light of the above quoted "glitches", my question is:
>>> due to the small chance of a power loss happening righ
On Sat, 27 Feb 2010 20:34:45 -0500, James Vasile
wrote:
> Emacs22 lacks apply-partially and mouse-event-p, so define them if emacs
> version is less than 23. With this change, I was able to begin using
> notmuch in emacs22.
Hi James.
Thanks very much for the patch. I've pushed this now, (and a
Carl Worth writes:
> But perhaps getting access to that single, entire file will be easier
> than getting access to these two little functions.
Assuming the current emacs-23 version will work:
wget -O json.el \
'http://repo.or.cz/w/emacs.git/blob_plain/emacs-23:/lisp/json.el'
--
Rob Bro
Hello all!
First congratulations for the nice software! I hardly wait for a
notmuch native (i.e. libnotmuch) and curses client (like `ner`) to
become more stable, and thus I'll be able to ditch GMail. :) But until
then a small glitch...
While upgrading from notmuch 0.4 to 0.5, I've re
ly not
deliberate, and is definitely undesirable. A patch would be welcome.
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/20101116/af48bf11/attachment.pgp>
---
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 900 bytes
Desc: OpenPGP digital signature
URL:
<http://notmuchmail.org/pipermail/notmuch/attachments/20101116/552d79a3/attachment.pgp>
'Lo. I've been toying with switching to notmuch for a while, but the
speed of search has been holding me back. Perhaps I should upgrade
the archaic machine I'm trying to run notmuch on, but I figured
optimizing search would be a good way for me to cut my teeth on
notmuch's code. I've implemented
On Tue, 16 Nov 2010 11:18:43 -0500, Austin Clements wrote:
> [1] Except for 2 emacs tests that depend on author order. What order
> are matched authors *supposed* to be in?
In IRC cworth confirmed that he considered the current behaviour a bug,
which is to say that the authors should be sorted b
Message mode uses a different name for composition buffers in newer
versions of emacs. Allow for this when causing the composition window
to overlay the viewing window.
---
I don't understand why Aneesh chose to use `add-hook' and `purecopy'.
emacs/notmuch-mua.el |2 +-
1 files changed, 1 in
Quoth David Edmondson on Nov 16 at 4:58 pm:
> On Tue, 16 Nov 2010 11:18:43 -0500, Austin Clements
> wrote:
> > [1] Except for 2 emacs tests that depend on author order. What order
> > are matched authors *supposed* to be in?
>
> In IRC cworth confirmed that he considered the current behaviour
se for fixing that.
-Carl
--
carl.d.worth at intel.com
-- 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/20101116/ca9be4a2/attachment.pgp>
his
to replace the target of any symlinks.
-Carl
--
carl.d.worth at intel.com
-- 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/no
muchmail.org/pipermail/notmuch/attachments/20101116/d2162bd5/attachment.pgp>
ize: 189 bytes
Desc: not available
URL:
<http://notmuchmail.org/pipermail/notmuch/attachments/20101116/d6fc03c7/attachment.pgp>
ailable
URL:
<http://notmuchmail.org/pipermail/notmuch/attachments/20101116/9bc490da/attachment.pgp>
--- 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/20101116/4ec53210/attachment.pgp>
ugh that we would feel fine just not offering the knob
at all.
Thanks,
-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/attach
attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 900 bytes
Desc: OpenPGP digital signature
URL:
<http://notmuchmail.org/pipermail/notmuch/attachments/20101116/d1c26e9a/attachment.pgp>
s scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: not available
URL:
<http://notmuchmail.org/pipermail/notmuch/attachments/20101116/9ca183d9/attachment.pgp>
next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 900 bytes
Desc: OpenPGP digital signature
URL:
<http://notmuchmail.org/pipermail/notmuch/attachments/20101116/202d31c2/attachment.pgp>
On Tue, Nov 16, 2010 at 21:09, Carl Worth wrote:
> On Tue, 16 Nov 2010 15:33:30 +0200, "Ciprian Dorin, Craciun" at gmail.com> wrote:
>> ? ? So my question is: is this behaviour (of deleting the file and
>> creating a new one) deliberate? If not, could it be fixed (I could
>> provide a patch) to j
ies. This is what the atomicity of the operation is expected
to guarantee.
--dkg
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 900 bytes
Desc: OpenPGP digital signature
URL:
<http://notmuchmail.org/pipermail/notmuch/attachments/20101116/fd4bca1c/attachment.pgp>
On Tue, 16 Nov 2010 11:35:31 -0800, Carl Worth wrote:
> These look fairly handy.
>
> But, since I know our current keybindings are less-than-perfect, I would
> prefer to see patches that also fix them, (rather than just adding
> functionality that new users can't get at without manual customizati
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 900 bytes
Desc: OpenPGP digital signature
URL:
<http://notmuchmail.org/pipermail/notmuch/attachments/20101116/652de272/attachment.pgp>
ent was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: not available
URL:
<http://notmuchmail.org/pipermail/notmuch/attachments/20101116/9566d0d4/attachment.pgp>
think that
translates into --verify being on by default in
/usr/bin/notmuch.
--dkg
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 900 bytes
Desc: OpenPGP digital signature
URL:
<http://notmuchmail.o
wo little functions.
-Carl
--
carl.d.worth at intel.com
-- 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/20101116/18c401b3/attachment.pgp>
Carl Worth writes:
> But perhaps getting access to that single, entire file will be easier
> than getting access to these two little functions.
Assuming the current emacs-23 version will work:
wget -O json.el \
'http://repo.or.cz/w/emacs.git/blob_plain/emacs-23:/lisp/json.el'
--
Rob Bro
52 matches
Mail list logo
