The patch rewrites `notmuch-show-message-extent' to be more
robust. The main goal is to make it work as expected if point is
invisible. Besides, there are no more point movements and
property search functions are used instead manual loops. The
comment regarding properties strangeness is removed
Human-friendly scenario:
* open a thread which has at least 2 messages in notmuch-show view
* hide the first message
* move to the first line of the second message
* press C-a (bound to `beginning-of-visual-line')
* press RET (bound to `notmuch-show-toggle-message')
Result: the first message is s
---
Either enable `notmuch-always-prompt-for-sender', or apply this
quick-fix patch, which uses `name' and `primary_email' as configured
in your .notmuch-config if aforementioned isn't enabled.
emacs/notmuch-mua.el |4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/emacs
On Sat, 02 Jul 2011 02:23:34 +0100, Andreas Amann wrote:
> > It's a known problem. As a short term fix, try the patches of
> >
> > id:"1307320169-29905-1-git-send-email-jrollins at finestructure.net"
> >
Or use `notmuch-show-view-raw-message' (bound to 'V').
> thanks a lot David. I can confi
On Fri, 1 Jul 2011 12:37:11 -0400, Austin Clements wrote:
Non-text part: multipart/alternative
> On Jul 1, 2011 10:55 AM, "Austin Clements" wrote:
> >
> > On Thu, Jun 30, 2011 at 3:38 PM, Pieter Praet wrote:
> > > Ok, even though my very first reply [1] may have created the impression
> > > that
---
test/emacs | 37
test/emacs.expected-output/notmuch-hello |3 +-
.../notmuch-hello-new-section |4 ++
.../notmuch-hello-no-saved-searches|3 +-
.../notmuch-hello-section-be
This patch makes the notmuch-hello screen fully customizable
by allowing the user to add and remove arbitrary sections. It
also provides some convenience functions for constructing sections,
e.g. showing the unread message count for each tag.
This is done by specifying a list of functions that wil
Rebased against current master and some improvements for using customize.
On Sat, Jul 2, 2011 at 07:44, David Bremner wrote:
>
> A third strategy is "git checkout master && git merge -s ours 0.6".
> Then history will look like this:
>
> ?freeze
> --.-.- master
> ? \ ? ? ? ? ? /
> ? ?---
> ? ? ? ? ? ? ? release
>
> As long as every patch on the re
by
committing/cherry-picking on release.
d
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 315 bytes
Desc: not available
URL:
<http://notmuchmail.org/pipermail/notmuch/attachments/20110702/b4deff86/attachment-0001.pgp>
On Sat, Jul 2, 2011 at 07:44, David Bremner wrote:
>
> A third strategy is "git checkout master && git merge -s ours 0.6".
> Then history will look like this:
>
> freeze
> --.-.- master
> \ /
> ---
> release
>
> As long as every patch on the re
On 1 July 2011 19:47, David Bremner wrote:
> On Fri, 01 Jul 2011 14:48:24 -0700, Keith Packard
> wrote:
>> > 2) merge master onto the release branch
>>
>> This makes doing 'bug fix' stuff on top of 0.6 a bit more challenging.
>
> Can you elaborate? Naively it seems like one ends up with the same
On Sat, 2 Jul 2011 11:59:04 -0400, servilio wrote:
> What about having Carl do the merging of features into a develop
> branch[1], then the release manager prepares a release in a release
> branch, merging back and tagging into master when release is ready? A
> similar workflow could be followed f
not what we
want.
d
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 315 bytes
Desc: not available
URL:
<http://notmuchmail.org/pipermail/notmuch/attachments/20110702/32aa0752/attachment.pgp>
On Sat, 02 Jul 2011 09:44:50 -0300, David Bremner wrote:
> This has the advantage that "git describe master" starts to count from
> 0.6 instead of 0.5. Currently e.g. "make dist" on master is making
> notmuch-0.5-317-gd15faa1.tar.gz. Unless we are going for the
> "increasingly innacurately named"
On 1 July 2011 19:47, David Bremner wrote:
> On Fri, 01 Jul 2011 14:48:24 -0700, Keith Packard wrote:
>> > 2) merge master onto the release branch
>>
>> This makes doing 'bug fix' stuff on top of 0.6 a bit more challenging.
>
> Can you elaborate? Naively it seems like one ends up with the same ki
---
Either enable `notmuch-always-prompt-for-sender', or apply this
quick-fix patch, which uses `name' and `primary_email' as configured
in your .notmuch-config if aforementioned isn't enabled.
emacs/notmuch-mua.el |4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/emacs
On Sat, 02 Jul 2011 09:44:50 -0300, David Bremner wrote:
> This has the advantage that "git describe master" starts to count from
> 0.6 instead of 0.5. Currently e.g. "make dist" on master is making
> notmuch-0.5-317-gd15faa1.tar.gz. Unless we are going for the
> "increasingly innacurately named"
On Sat, 02 Jul 2011 02:23:34 +0100, Andreas Amann wrote:
> > It's a known problem. As a short term fix, try the patches of
> >
> > id:"1307320169-29905-1-git-send-email-jroll...@finestructure.net"
> >
Or use `notmuch-show-view-raw-message' (bound to 'V').
> thanks a lot David. I can confirm
On Fri, 1 Jul 2011 12:37:11 -0400, Austin Clements wrote:
Non-text part: multipart/alternative
> On Jul 1, 2011 10:55 AM, "Austin Clements" wrote:
> >
> > On Thu, Jun 30, 2011 at 3:38 PM, Pieter Praet wrote:
> > > Ok, even though my very first reply [1] may have created the impression
> > > that
---
test/emacs | 37
test/emacs.expected-output/notmuch-hello |3 +-
.../notmuch-hello-new-section |4 ++
.../notmuch-hello-no-saved-searches|3 +-
.../notmuch-hello-section-be
This patch makes the notmuch-hello screen fully customizable
by allowing the user to add and remove arbitrary sections. It
also provides some convenience functions for constructing sections,
e.g. showing the unread message count for each tag.
This is done by specifying a list of functions that wil
Rebased against current master and some improvements for using customize.
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch
On Fri, 01 Jul 2011 18:37:27 -0300, David Bremner wrote:
>
> So now we have to decide what to do. FWIW, there are about 20 commits on
> release past d6f05fd.
>
> There are two obvious strategies going forward.
>
A third strategy is "git checkout master && git merge -s ours 0.6".
Then history
> It's a known problem. As a short term fix, try the patches of
>
> id:"1307320169-29905-1-git-send-email-jrollins at finestructure.net"
>
thanks a lot David. I can confirm that it works for me.
Andreas
25 matches
Mail list logo
