[PATCH] Make patch saving in vim a little better.

2014-10-18 Thread Franz Fellner
PATCH LGTM. Did not find any patch that couldn't be saved.
One issue: It saves the patches into $WORKDIR. It would be great if the target 
path could
be prompted (default again to ~/.notmuch/tmp?) so no random dirs get polluted.
But that isn't a regression to the previous behaviour -> no showstopper.

Franz

Ian Main wrote:
> It seems like there was some bitrot on the previous version of this
> which made it not work correctly.  This fixes the bitrot and also
> updates how it works.
> 
> - Sometimes [PATCH.*] isn't at the beginning of the message (often on
>   lists I'm on).
> - It now goes through all the messages in the thread.  for some reason
>   the toplevel messages didn't usually contain all the patches in my
>   testing.
> - Check for 'Re:' at the beginning and skip if it's there.
> - Save patches to filesystem-safe filename containing the subject
>   (unfortunately we use system()...)
> 
> Ian
> ---
>  vim/notmuch.vim | 14 ++
>  1 file changed, 10 insertions(+), 4 deletions(-)
> 
> diff --git a/vim/notmuch.vim b/vim/notmuch.vim
> index b33c6c6..d80f22f 100644
> --- a/vim/notmuch.vim
> +++ b/vim/notmuch.vim
> @@ -182,12 +182,18 @@ ruby << EOF
>   q = $curbuf.query($cur_thread)
>   t = q.search_threads.first
>   n = 0
> - t.toplevel_messages.first.replies.each do |m|
> - next if not m['subject'] =~ /^\[PATCH.*\]/
> - file = "%04d.patch" % [n += 1]
> + t.messages.each do |m|
> + next if not m['subject'] =~ /\[PATCH.*\]/
> + next if m['subject'] =~ /^Re:/
> + file = "#{m['subject']}-%04d.patch" % [n += 1]
> + # Sanitize for the filesystem
> + file.gsub!(/[^0-9A-Za-z.\-]/, '_')
> + # Remove leading underscores.
> + file.gsub!(/^_+/, '')
> + vim_puts "Saving patch to #{file}"
>   system "notmuch show --format=mbox id:#{m.message_id} > #{file}"
>   end
> - vim_puts "Saved #{n} patches"
> + vim_puts "Saved #{n} patch(es)"
>  EOF
>  endfunction
>  
> -- 
> 1.9.3
> 
> ___
> notmuch mailing list
> notmuch at notmuchmail.org
> http://notmuchmail.org/mailman/listinfo/notmuch




[PATCH] VIM: Make starting in 'insert' mode for compose optional

2014-10-18 Thread Franz Fellner
Ian Main wrote:
> I found it unusual to be started in insert mode
Me too.
Patch LGTM. Works as expected - thx!

Franz
> 
> Ian
> ---
>  vim/notmuch.vim | 13 +++--
>  1 file changed, 11 insertions(+), 2 deletions(-)
> 
> diff --git a/vim/notmuch.vim b/vim/notmuch.vim
> index 331e930..252f16b 100644
> --- a/vim/notmuch.vim
> +++ b/vim/notmuch.vim
> @@ -59,6 +59,7 @@ let s:notmuch_datetime_format_default = '%d.%m.%y %H:%M:%S'
>  let s:notmuch_reader_default = 'mutt -f %s'
>  let s:notmuch_sendmail_default = 'sendmail'
>  let s:notmuch_folders_count_threads_default = 0
> +let s:notmuch_compose_start_insert_default = 1
>  
>  function! s:new_file_buffer(type, fname)
>   exec printf('edit %s', a:fname)
> @@ -132,7 +133,9 @@ function! s:show_reply()
>   let b:compose_done = 0
>   call s:set_map(g:notmuch_compose_maps)
>   autocmd BufDelete  call s:on_compose_delete()
> - startinsert!
> + if g:notmuch_compose_start_insert
> + startinsert!
> + end
>  endfunction
>  
>  function! s:compose()
> @@ -140,7 +143,9 @@ function! s:compose()
>   let b:compose_done = 0
>   call s:set_map(g:notmuch_compose_maps)
>   autocmd BufDelete  call s:on_compose_delete()
> - startinsert!
> + if g:notmuch_compose_start_insert
> + startinsert!
> + end
>  endfunction
>  
>  function! s:show_info()
> @@ -428,6 +433,10 @@ function! s:set_defaults()
>   endif
>   endif
>  
> + if !exists('g:notmuch_compose_start_insert')
> + let g:notmuch_compose_start_insert = 
> s:notmuch_compose_start_insert_default
> + endif
> +
>   if !exists('g:notmuch_custom_search_maps') && 
> exists('g:notmuch_rb_custom_search_maps')
>   let g:notmuch_custom_search_maps = 
> g:notmuch_rb_custom_search_maps
>   endif
> -- 
> 1.9.3
> 
> ___
> notmuch mailing list
> notmuch at notmuchmail.org
> http://notmuchmail.org/mailman/listinfo/notmuch




[PATCH] VIM: Improve search list

2014-10-18 Thread Franz Fellner
LGTM

Franz

Ian Main wrote:
> Make the width of the search name column expand/contract with the
> length of the longest search name string.
> 
> Fix syntax highlighting to make the above work right.
> 
> Add the ability to use a blank search pattern to create a spacer
> to break up searches into groups.
> ---
>  vim/notmuch.txt|  4 
>  vim/notmuch.vim| 16 ++--
>  vim/syntax/notmuch-folders.vim |  2 +-
>  3 files changed, 19 insertions(+), 3 deletions(-)
> 
> diff --git a/vim/notmuch.txt b/vim/notmuch.txt
> index 4374102..3a73912 100644
> --- a/vim/notmuch.txt
> +++ b/vim/notmuch.txt
> @@ -94,11 +94,15 @@ You can add the following configurations to your 
> `.vimrc`, or
>   *g:notmuch_folders*
>  
>  The first thing you might want to do is set your custom searches.
> +
> +Adding an empty set of strings results in a blank line which allows you
> +to break up searches into groups.
>  >
>   let g:notmuch_folders = [
>   \ [ 'new', 'tag:inbox and tag:unread' ],
>   \ [ 'inbox', 'tag:inbox' ],
>   \ [ 'unread', 'tag:unread' ],
> + \ [ '', '' ],
>   \ [ 'to-do', 'tag:to-do' ],
>   \ [ 'to-me', 'to:john.doe and tag:new' ],
>   \ ]
> diff --git a/vim/notmuch.vim b/vim/notmuch.vim
> index 331e930..61a7260 100644
> --- a/vim/notmuch.vim
> +++ b/vim/notmuch.vim
> @@ -374,7 +374,9 @@ function! s:folders_show_search()
>  ruby << EOF
>   n = $curbuf.line_number
>   s = $searches[n - 1]
> - VIM::command("call s:search('#{s}')")
> + if s.length > 0
> + VIM::command("call s:search('#{s}')")
> + end
>  EOF
>  endfunction
>  
> @@ -633,11 +635,21 @@ ruby << EOF
>   folders = VIM::evaluate('g:notmuch_folders')
>   count_threads = 
> VIM::evaluate('g:notmuch_folders_count_threads') == 1
>   $searches.clear
> + longest_name = 0
> + folders.each do |name, search|
> + if name.length > longest_name
> + longest_name = name.length
> + end
> + end
>   folders.each do |name, search|
>   q = $curbuf.query(search)
>   $searches << search
>   count = count_threads ? q.search_threads.count 
> : q.search_messages.count
> - b << "%9d %-20s (%s)" % [count, name, search]
> + if name == ''
> + b << ""
> + else
> + b << "%9d %-#{longest_name + 1}s (%s)" 
> % [count, name, search]
> + end
>   end
>   end
>   end
> diff --git a/vim/syntax/notmuch-folders.vim b/vim/syntax/notmuch-folders.vim
> index 9477f86..03209c1 100644
> --- a/vim/syntax/notmuch-folders.vim
> +++ b/vim/syntax/notmuch-folders.vim
> @@ -1,7 +1,7 @@
>  " notmuch folders mode syntax file
>  
>  syntax region nmFoldersCount start='^' end='\%10v'
> -syntax region nmFoldersName  start='\%11v' end='\%31v'
> +syntax region nmFoldersName  start='\%11v' end='  ('me=e-1
>  syntax match  nmFoldersSearch/([^()]\+)$/
>  
>  highlight link nmFoldersCount Statement
> -- 
> 1.9.3
> 
> ___
> notmuch mailing list
> notmuch at notmuchmail.org
> http://notmuchmail.org/mailman/listinfo/notmuch




[PATCH] VIM: Improve moving between messages in a thread

2014-10-18 Thread Franz Fellner
Ian Main wrote:
> Franz Fellner wrote:
> > Patch works fine for me. It also would be nice to have a "move to next
> > unread message" function.
> > Most beautiful would be a treeview of the thread structure. Currently
> > threads are rendered as plain list, so you can't immediately see and
> > jump to the quoted mail. Bower IMHO uses the best approach here. I tried
> > emacs treeview but did not really like it (partly because I failed badly
> > to implement a solution that shows treeview by default). Indent the
> > whole large Message view IMHO also is not a good (at least to me)
> > solution.
> 
> Yeah I agree.  This is a start anyway.  As I use the vim client more my
> plan is to just keep fixing things that get in my way.

Great :)

Just a LGTM to get this pushed.

Franz


[PATCH] VIM: Make an option to save sent mail locally

2014-10-18 Thread Franz Fellner
Ian Main wrote:
> Franz Fellner wrote:
> > Why not simply use Notmuch::Database.add_message? Would save a
> > system-call.
> > One could easily copy the sent mail into nm_db_path/sent/cur, add it to the 
> > db, tag it.
> > Though I don't know enough about maildir handling, but probably rubys
> > Mail module could help here.
> 
> So you are saying I'd have to copy the message to the database and then call
> Notmuch::Database.add_message()?  If so I think I'd rather stick with the
> system call..
Yes, that was my intention. I usually prefer using a stable API rather then 
realying on CLI.
But that's just preference ;)

All in all it works. So LGTM.

> 
> > Another issue is configuration. Hardcoding "Sent" probably won't fit
> > everyones needs. And (if I understand DOCS correctly) db.add_message
> > doesn't even force you to keep sent mail folder inside db_path; correct
> > me if I'm wrong :) notmuch --insert will put it into folder relative to
> > db_path.
> 
> Yeah, I can add it so the folder can be changed.  I figured this was just the
> start of things.  Really we should be able to fcc it to our upstream provider
> sent mailbox too.
That MIGHT get hard.
All accounts I use store the mails I send to their smtp-server locally, I could 
sync them again through IMAP.
GMail for example does that. Pushing those mails upstream again is useless.
But there might be setups where it is neccessary to manually store mails inside 
a sent folder that get's afterwards synced with the IMAP server.

So if you want that to work in any case we might need to introduce settings for 
user accounts...

Franz


Tabulation in multiline headers

2014-10-18 Thread Jani Nikula
On Sat, 18 Oct 2014, Sergei Shilovsky  wrote:
>> Hi, Sergei.  I'm not clear on where exactly you are seeing a problem
>> with this tab in the subject line.  Is it showing up somewhere you think
>> it shouldn't?
>
> It is shown in e.g. `notmuch show` as well as
> 'notmuch_message_get_header(m, "subject")`
>
>> I'm not sure libnotmuch should be doing any scrubbing of the message
>> contents.  The emacs UI does seem to replace the tab with a space,
>> though.  Maybe other MUAs should be doing the same?
>
> My point is that this tabulation character does not relate to the
> contents of the header (this might be arguable though) and libnotmuch
> should return the contents, not its representation on file system.

This is folding and unfolding of long header fields in action, described
in [1]. In short, folding happens by inserting CRLF before any WSP, and
unfolding happens by removing any CRLF immediately followed by WSP. The
WSP is preserved unchanged through folding and unfolding. The TAB is not
part of the multiple line representation, it's part of the unfolded
content.

If my memory serves me right, many problems lead back to an
interpretation of [2] that you could insert extra WSP while folding. Due
to this interpretation, many agents replace the WSP following a CRLF
with a single space while unfolding. And presumably because of this,
buggy folding in a Python email package that replaces WSP by a TAB while
folding went unnoticed. This problem, in turn, has been literally spread
wide by Mailman 2 through its use of said email package. In practice it
follows that a perfectly good message will have folding WSP replaced by
TAB when it gets transmitted through Mailman 2. Again, this is all from
memory, [citation needed] etc.

Notmuch is not free of a history of its own when it comes to header
unfolding. For historical reasons, we used two header parsers until
recently. One from gmime, and one of our own. After all of the above, it
shouldn't surprise the reader that the parsers treated folding WSP
differently! Our own parser replaced folding WSP with a single space,
while gmime respects the RFC. Starting from 0.18 we only use gmime to
parse headers, which means we're at least consistent, but, by the GIGO
principle, we may see more folding TABs.

I do not think we should workaround header folding problems in the lib,
and I'm not sure about the cli either. We should consider replacing TABs
with spaces in notmuch-emacs though (I personally use a
notmuch-show-markup-headers-hook that does that).

HTH,
Jani.


[1] https://tools.ietf.org/html/rfc5322#section-2.2.3
[2] https://tools.ietf.org/html/rfc822#section-3.1


[PATCH] test: add simple tests for post-insert hook

2014-10-18 Thread David Bremner
Most of the existing tests for pre/post-new hook don't seem to apply.
---
 test/T400-hooks.sh | 18 ++
 1 file changed, 18 insertions(+)

diff --git a/test/T400-hooks.sh b/test/T400-hooks.sh
index 77e8569..e741211 100755
--- a/test/T400-hooks.sh
+++ b/test/T400-hooks.sh
@@ -30,6 +30,8 @@ rm_hooks () {

 # add a message to generate mail dir and database
 add_message
+# create maildir structure for notmuch-insert
+mkdir -p "$MAIL_DIR"/{cur,new,tmp}

 test_begin_subtest "pre-new is run"
 rm_hooks
@@ -45,6 +47,16 @@ create_echo_hook "post-new" expected output
 notmuch new > /dev/null
 test_expect_equal_file expected output

+test_begin_subtest "post-insert hook is run"
+rm_hooks
+generate_message
+create_echo_hook "post-insert" expected output
+echo $gen_msg_filename
+cat output
+notmuch insert < "$gen_msg_filename"
+echo $?
+test_expect_equal_file expected output
+
 test_begin_subtest "pre-new is run before post-new"
 rm_hooks
 generate_message
@@ -82,6 +94,12 @@ test_expect_equal_file expected output
 # depends on the previous subtest leaving broken hook behind
 test_expect_code 1 "post-new non-zero exit status (notmuch status)" "notmuch 
new"

+rm_hooks
+generate_message
+create_failing_hook "post-insert"
+test_expect_success "post-insert hook does not affect insert status" \
+"notmuch insert < \"$gen_msg_filename\" > /dev/null"
+
 # test_begin_subtest "hook without executable permissions"
 rm_hooks
 mkdir -p ${HOOK_DIR}
-- 
2.1.1



[Patch v2.5 1/4] test/insert: add known broken tests for indexing failures

2014-10-18 Thread David Bremner
David Bremner  writes:

> Jani Nikula  writes:
>
>> On Sat, 04 Oct 2014, David Bremner  wrote:
>>> These tests are written with the assumption that we want all indexing
>>> failures to be considered as failures by notmuch insert.
>>
>> Just realized this needs a missing prereq test for gdb.
>>
>> BR,
>> Jani.
>
> oops. missed this until after I pushed. I'll look into it ASAP.

I took the liberty of pushing a one-line build fix.  I'm not 100%
certain, but I think the usage of "test_require_external_prereq" in 
T380-atomicity.sh could be simplified in a similary way.

d


[Patch v2.5 1/4] test/insert: add known broken tests for indexing failures

2014-10-18 Thread David Bremner
Jani Nikula  writes:

> On Sat, 04 Oct 2014, David Bremner  wrote:
>> These tests are written with the assumption that we want all indexing
>> failures to be considered as failures by notmuch insert.
>
> Just realized this needs a missing prereq test for gdb.
>
> BR,
> Jani.

oops. missed this until after I pushed. I'll look into it ASAP.

d


Tabulation in multiline headers

2014-10-18 Thread Sergei Shilovsky
> Hi, Sergei.  I'm not clear on where exactly you are seeing a problem
> with this tab in the subject line.  Is it showing up somewhere you think
> it shouldn't?

It is shown in e.g. `notmuch show` as well as
'notmuch_message_get_header(m, "subject")`

> I'm not sure libnotmuch should be doing any scrubbing of the message
> contents.  The emacs UI does seem to replace the tab with a space,
> though.  Maybe other MUAs should be doing the same?

My point is that this tabulation character does not relate to the
contents of the header (this might be arguable though) and libnotmuch
should return the contents, not its representation on file system.

-- 
? ?,
?? ?
Sergei Shilovsky


Tabulation in multiline headers

2014-10-18 Thread Sergei Shilovsky
Lets consider this message:

id:87r5aucoeg.fsf at servo.finestructure.net

Its subject spreads over 2 lines and the 2nd line is indented with
 in the file:

Subject: running the crypto branch [was: Re: Hiding HTML mime-parts and/or
scrubbing (gmail's) HTML-based citation]

The issue is that notmuch_message_get_header() returns this whole line
with the Tab
character (though I guess it should not):

running the crypto branch [was: Re: Hiding HTML mime-parts
and/orscrubbing (gmail's) HTML-based citation]

This file could be imported from gmane though with mb2md. My test long
subject message (sent via gmail) didn't got any tabulation.

 No idea where this tabulation could came from, but would that be
correct to replace  with space in libnotmuch itself?

-- 
? ?,
?? ?
Sergei Shilovsky


Re: [Patch v2.5 1/4] test/insert: add known broken tests for indexing failures

2014-10-18 Thread David Bremner
Jani Nikula j...@nikula.org writes:

 On Sat, 04 Oct 2014, David Bremner da...@tethera.net wrote:
 These tests are written with the assumption that we want all indexing
 failures to be considered as failures by notmuch insert.

 Just realized this needs a missing prereq test for gdb.

 BR,
 Jani.

oops. missed this until after I pushed. I'll look into it ASAP.

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


Re: [Patch v2.5 1/4] test/insert: add known broken tests for indexing failures

2014-10-18 Thread David Bremner
David Bremner da...@tethera.net writes:

 Jani Nikula j...@nikula.org writes:

 On Sat, 04 Oct 2014, David Bremner da...@tethera.net wrote:
 These tests are written with the assumption that we want all indexing
 failures to be considered as failures by notmuch insert.

 Just realized this needs a missing prereq test for gdb.

 BR,
 Jani.

 oops. missed this until after I pushed. I'll look into it ASAP.

I took the liberty of pushing a one-line build fix.  I'm not 100%
certain, but I think the usage of test_require_external_prereq in 
T380-atomicity.sh could be simplified in a similary way.

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


[PATCH] test: add simple tests for post-insert hook

2014-10-18 Thread David Bremner
Most of the existing tests for pre/post-new hook don't seem to apply.
---
 test/T400-hooks.sh | 18 ++
 1 file changed, 18 insertions(+)

diff --git a/test/T400-hooks.sh b/test/T400-hooks.sh
index 77e8569..e741211 100755
--- a/test/T400-hooks.sh
+++ b/test/T400-hooks.sh
@@ -30,6 +30,8 @@ rm_hooks () {
 
 # add a message to generate mail dir and database
 add_message
+# create maildir structure for notmuch-insert
+mkdir -p $MAIL_DIR/{cur,new,tmp}
 
 test_begin_subtest pre-new is run
 rm_hooks
@@ -45,6 +47,16 @@ create_echo_hook post-new expected output
 notmuch new  /dev/null
 test_expect_equal_file expected output
 
+test_begin_subtest post-insert hook is run
+rm_hooks
+generate_message
+create_echo_hook post-insert expected output
+echo $gen_msg_filename
+cat output
+notmuch insert  $gen_msg_filename
+echo $?
+test_expect_equal_file expected output
+
 test_begin_subtest pre-new is run before post-new
 rm_hooks
 generate_message
@@ -82,6 +94,12 @@ test_expect_equal_file expected output
 # depends on the previous subtest leaving broken hook behind
 test_expect_code 1 post-new non-zero exit status (notmuch status) notmuch 
new
 
+rm_hooks
+generate_message
+create_failing_hook post-insert
+test_expect_success post-insert hook does not affect insert status \
+notmuch insert  \$gen_msg_filename\  /dev/null
+
 # test_begin_subtest hook without executable permissions
 rm_hooks
 mkdir -p ${HOOK_DIR}
-- 
2.1.1

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


Re: Tabulation in multiline headers

2014-10-18 Thread Jani Nikula
On Sat, 18 Oct 2014, Sergei Shilovsky sshilov...@gmail.com wrote:
 Hi, Sergei.  I'm not clear on where exactly you are seeing a problem
 with this tab in the subject line.  Is it showing up somewhere you think
 it shouldn't?

 It is shown in e.g. `notmuch show` as well as
 'notmuch_message_get_header(m, subject)`

 I'm not sure libnotmuch should be doing any scrubbing of the message
 contents.  The emacs UI does seem to replace the tab with a space,
 though.  Maybe other MUAs should be doing the same?

 My point is that this tabulation character does not relate to the
 contents of the header (this might be arguable though) and libnotmuch
 should return the contents, not its representation on file system.

This is folding and unfolding of long header fields in action, described
in [1]. In short, folding happens by inserting CRLF before any WSP, and
unfolding happens by removing any CRLF immediately followed by WSP. The
WSP is preserved unchanged through folding and unfolding. The TAB is not
part of the multiple line representation, it's part of the unfolded
content.

If my memory serves me right, many problems lead back to an
interpretation of [2] that you could insert extra WSP while folding. Due
to this interpretation, many agents replace the WSP following a CRLF
with a single space while unfolding. And presumably because of this,
buggy folding in a Python email package that replaces WSP by a TAB while
folding went unnoticed. This problem, in turn, has been literally spread
wide by Mailman 2 through its use of said email package. In practice it
follows that a perfectly good message will have folding WSP replaced by
TAB when it gets transmitted through Mailman 2. Again, this is all from
memory, [citation needed] etc.

Notmuch is not free of a history of its own when it comes to header
unfolding. For historical reasons, we used two header parsers until
recently. One from gmime, and one of our own. After all of the above, it
shouldn't surprise the reader that the parsers treated folding WSP
differently! Our own parser replaced folding WSP with a single space,
while gmime respects the RFC. Starting from 0.18 we only use gmime to
parse headers, which means we're at least consistent, but, by the GIGO
principle, we may see more folding TABs.

I do not think we should workaround header folding problems in the lib,
and I'm not sure about the cli either. We should consider replacing TABs
with spaces in notmuch-emacs though (I personally use a
notmuch-show-markup-headers-hook that does that).

HTH,
Jani.


[1] https://tools.ietf.org/html/rfc5322#section-2.2.3
[2] https://tools.ietf.org/html/rfc822#section-3.1
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch


Re: [PATCH] VIM: Make an option to save sent mail locally

2014-10-18 Thread Franz Fellner
Ian Main wrote:
 Franz Fellner wrote:
  Why not simply use Notmuch::Database.add_message? Would save a
  system-call.
  One could easily copy the sent mail into nm_db_path/sent/cur, add it to the 
  db, tag it.
  Though I don't know enough about maildir handling, but probably rubys
  Mail module could help here.
 
 So you are saying I'd have to copy the message to the database and then call
 Notmuch::Database.add_message()?  If so I think I'd rather stick with the
 system call..
Yes, that was my intention. I usually prefer using a stable API rather then 
realying on CLI.
But that's just preference ;)

All in all it works. So LGTM.

 
  Another issue is configuration. Hardcoding Sent probably won't fit
  everyones needs. And (if I understand DOCS correctly) db.add_message
  doesn't even force you to keep sent mail folder inside db_path; correct
  me if I'm wrong :) notmuch --insert will put it into folder relative to
  db_path.
 
 Yeah, I can add it so the folder can be changed.  I figured this was just the
 start of things.  Really we should be able to fcc it to our upstream provider
 sent mailbox too.
That MIGHT get hard.
All accounts I use store the mails I send to their smtp-server locally, I could 
sync them again through IMAP.
GMail for example does that. Pushing those mails upstream again is useless.
But there might be setups where it is neccessary to manually store mails inside 
a sent folder that get's afterwards synced with the IMAP server.

So if you want that to work in any case we might need to introduce settings for 
user accounts...

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


Re: [PATCH] VIM: Improve moving between messages in a thread

2014-10-18 Thread Franz Fellner
Ian Main wrote:
 Franz Fellner wrote:
  Patch works fine for me. It also would be nice to have a move to next
  unread message function.
  Most beautiful would be a treeview of the thread structure. Currently
  threads are rendered as plain list, so you can't immediately see and
  jump to the quoted mail. Bower IMHO uses the best approach here. I tried
  emacs treeview but did not really like it (partly because I failed badly
  to implement a solution that shows treeview by default). Indent the
  whole large Message view IMHO also is not a good (at least to me)
  solution.
 
 Yeah I agree.  This is a start anyway.  As I use the vim client more my
 plan is to just keep fixing things that get in my way.

Great :)

Just a LGTM to get this pushed.

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


RE: [PATCH] VIM: Improve search list

2014-10-18 Thread Franz Fellner
LGTM

Franz

Ian Main wrote:
 Make the width of the search name column expand/contract with the
 length of the longest search name string.
 
 Fix syntax highlighting to make the above work right.
 
 Add the ability to use a blank search pattern to create a spacer
 to break up searches into groups.
 ---
  vim/notmuch.txt|  4 
  vim/notmuch.vim| 16 ++--
  vim/syntax/notmuch-folders.vim |  2 +-
  3 files changed, 19 insertions(+), 3 deletions(-)
 
 diff --git a/vim/notmuch.txt b/vim/notmuch.txt
 index 4374102..3a73912 100644
 --- a/vim/notmuch.txt
 +++ b/vim/notmuch.txt
 @@ -94,11 +94,15 @@ You can add the following configurations to your 
 `.vimrc`, or
   *g:notmuch_folders*
  
  The first thing you might want to do is set your custom searches.
 +
 +Adding an empty set of strings results in a blank line which allows you
 +to break up searches into groups.
  
   let g:notmuch_folders = [
   \ [ 'new', 'tag:inbox and tag:unread' ],
   \ [ 'inbox', 'tag:inbox' ],
   \ [ 'unread', 'tag:unread' ],
 + \ [ '', '' ],
   \ [ 'to-do', 'tag:to-do' ],
   \ [ 'to-me', 'to:john.doe and tag:new' ],
   \ ]
 diff --git a/vim/notmuch.vim b/vim/notmuch.vim
 index 331e930..61a7260 100644
 --- a/vim/notmuch.vim
 +++ b/vim/notmuch.vim
 @@ -374,7 +374,9 @@ function! s:folders_show_search()
  ruby  EOF
   n = $curbuf.line_number
   s = $searches[n - 1]
 - VIM::command(call s:search('#{s}'))
 + if s.length  0
 + VIM::command(call s:search('#{s}'))
 + end
  EOF
  endfunction
  
 @@ -633,11 +635,21 @@ ruby  EOF
   folders = VIM::evaluate('g:notmuch_folders')
   count_threads = 
 VIM::evaluate('g:notmuch_folders_count_threads') == 1
   $searches.clear
 + longest_name = 0
 + folders.each do |name, search|
 + if name.length  longest_name
 + longest_name = name.length
 + end
 + end
   folders.each do |name, search|
   q = $curbuf.query(search)
   $searches  search
   count = count_threads ? q.search_threads.count 
 : q.search_messages.count
 - b  %9d %-20s (%s) % [count, name, search]
 + if name == ''
 + b  
 + else
 + b  %9d %-#{longest_name + 1}s (%s) 
 % [count, name, search]
 + end
   end
   end
   end
 diff --git a/vim/syntax/notmuch-folders.vim b/vim/syntax/notmuch-folders.vim
 index 9477f86..03209c1 100644
 --- a/vim/syntax/notmuch-folders.vim
 +++ b/vim/syntax/notmuch-folders.vim
 @@ -1,7 +1,7 @@
   notmuch folders mode syntax file
  
  syntax region nmFoldersCount start='^' end='\%10v'
 -syntax region nmFoldersName  start='\%11v' end='\%31v'
 +syntax region nmFoldersName  start='\%11v' end='  ('me=e-1
  syntax match  nmFoldersSearch/([^()]\+)$/
  
  highlight link nmFoldersCount Statement
 -- 
 1.9.3
 
 ___
 notmuch mailing list
 notmuch@notmuchmail.org
 http://notmuchmail.org/mailman/listinfo/notmuch


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


RE: [PATCH] VIM: Make starting in 'insert' mode for compose optional

2014-10-18 Thread Franz Fellner
Ian Main wrote:
 I found it unusual to be started in insert mode
Me too.
Patch LGTM. Works as expected - thx!

Franz
 
 Ian
 ---
  vim/notmuch.vim | 13 +++--
  1 file changed, 11 insertions(+), 2 deletions(-)
 
 diff --git a/vim/notmuch.vim b/vim/notmuch.vim
 index 331e930..252f16b 100644
 --- a/vim/notmuch.vim
 +++ b/vim/notmuch.vim
 @@ -59,6 +59,7 @@ let s:notmuch_datetime_format_default = '%d.%m.%y %H:%M:%S'
  let s:notmuch_reader_default = 'mutt -f %s'
  let s:notmuch_sendmail_default = 'sendmail'
  let s:notmuch_folders_count_threads_default = 0
 +let s:notmuch_compose_start_insert_default = 1
  
  function! s:new_file_buffer(type, fname)
   exec printf('edit %s', a:fname)
 @@ -132,7 +133,9 @@ function! s:show_reply()
   let b:compose_done = 0
   call s:set_map(g:notmuch_compose_maps)
   autocmd BufDelete buffer call s:on_compose_delete()
 - startinsert!
 + if g:notmuch_compose_start_insert
 + startinsert!
 + end
  endfunction
  
  function! s:compose()
 @@ -140,7 +143,9 @@ function! s:compose()
   let b:compose_done = 0
   call s:set_map(g:notmuch_compose_maps)
   autocmd BufDelete buffer call s:on_compose_delete()
 - startinsert!
 + if g:notmuch_compose_start_insert
 + startinsert!
 + end
  endfunction
  
  function! s:show_info()
 @@ -428,6 +433,10 @@ function! s:set_defaults()
   endif
   endif
  
 + if !exists('g:notmuch_compose_start_insert')
 + let g:notmuch_compose_start_insert = 
 s:notmuch_compose_start_insert_default
 + endif
 +
   if !exists('g:notmuch_custom_search_maps')  
 exists('g:notmuch_rb_custom_search_maps')
   let g:notmuch_custom_search_maps = 
 g:notmuch_rb_custom_search_maps
   endif
 -- 
 1.9.3
 
 ___
 notmuch mailing list
 notmuch@notmuchmail.org
 http://notmuchmail.org/mailman/listinfo/notmuch


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


RE: [PATCH] Make patch saving in vim a little better.

2014-10-18 Thread Franz Fellner
PATCH LGTM. Did not find any patch that couldn't be saved.
One issue: It saves the patches into $WORKDIR. It would be great if the target 
path could
be prompted (default again to ~/.notmuch/tmp?) so no random dirs get polluted.
But that isn't a regression to the previous behaviour - no showstopper.

Franz

Ian Main wrote:
 It seems like there was some bitrot on the previous version of this
 which made it not work correctly.  This fixes the bitrot and also
 updates how it works.
 
 - Sometimes [PATCH.*] isn't at the beginning of the message (often on
   lists I'm on).
 - It now goes through all the messages in the thread.  for some reason
   the toplevel messages didn't usually contain all the patches in my
   testing.
 - Check for 'Re:' at the beginning and skip if it's there.
 - Save patches to filesystem-safe filename containing the subject
   (unfortunately we use system()...)
 
 Ian
 ---
  vim/notmuch.vim | 14 ++
  1 file changed, 10 insertions(+), 4 deletions(-)
 
 diff --git a/vim/notmuch.vim b/vim/notmuch.vim
 index b33c6c6..d80f22f 100644
 --- a/vim/notmuch.vim
 +++ b/vim/notmuch.vim
 @@ -182,12 +182,18 @@ ruby  EOF
   q = $curbuf.query($cur_thread)
   t = q.search_threads.first
   n = 0
 - t.toplevel_messages.first.replies.each do |m|
 - next if not m['subject'] =~ /^\[PATCH.*\]/
 - file = %04d.patch % [n += 1]
 + t.messages.each do |m|
 + next if not m['subject'] =~ /\[PATCH.*\]/
 + next if m['subject'] =~ /^Re:/
 + file = #{m['subject']}-%04d.patch % [n += 1]
 + # Sanitize for the filesystem
 + file.gsub!(/[^0-9A-Za-z.\-]/, '_')
 + # Remove leading underscores.
 + file.gsub!(/^_+/, '')
 + vim_puts Saving patch to #{file}
   system notmuch show --format=mbox id:#{m.message_id}  #{file}
   end
 - vim_puts Saved #{n} patches
 + vim_puts Saved #{n} patch(es)
  EOF
  endfunction
  
 -- 
 1.9.3
 
 ___
 notmuch mailing list
 notmuch@notmuchmail.org
 http://notmuchmail.org/mailman/listinfo/notmuch


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