notmuch vim patches

notmuch vim patches

[Ian Main]

For those who are interested, I've created a fork of the official(?)
github repo that contains all the patches I've worked on so far.
For those using notmuch-vim this would be a much easier way to try
out the new code.

https://github.com/imain/notmuch-vim

I think it could be useful to get feedback here on what people think.

I'm starting to realize that I could default to using 'enter' to both
open URI's and view attachments.  Any other ideas welcome.

    Ian

Re: notmuch vim patches

[Franz Fellner]

 
> I'm starting to realize that I could default to using 'enter' to both
> open URI's and view attachments.  Any other ideas welcome.

- make some of the functions public so users can bind them to keys they
  want
- introduce show_[prev,next]_unread_msg, probably factor out
  "show_scroll_to_msg()" and implement prev/next msg with that?
- use proper buffers instead of Scratch buffers, so BufExplorer also
  shows notmuch-vim buffers
- folding of messages; add option to fold read messages by default.

I think I can implement the second point (if you not already did
that).
I also looked into folding, but my knowledge of all the possiblities is
not that good (manual folding markers look ugly, don't know if/how 'syntax'
will work; and IMHO the user's shortcuts for folding should still work).

Franz

Re: notmuch vim patches

[Ian Main]

Franz Fellner wrote:
> 
>  
> > I'm starting to realize that I could default to using 'enter' to both
> > open URI's and view attachments.  Any other ideas welcome.
> 
> - make some of the functions public so users can bind them to keys they
>   want

Not sure I understand this one.  You want to be able to access the notmuch
functions outside of notmuch buffers?

> - introduce show_[prev,next]_unread_msg, probably factor out
>   "show_scroll_to_msg()" and implement prev/next msg with that?

I have not done this yet but that would be a great addition.  Especially
to jump through unread messages in a thread.

> - use proper buffers instead of Scratch buffers, so BufExplorer also
>   shows notmuch-vim buffers
> - folding of messages; add option to fold read messages by default.
> 
> I think I can implement the second point (if you not already did
> that).
> I also looked into folding, but my knowledge of all the possiblities is
> not that good (manual folding markers look ugly, don't know if/how 'syntax'
> will work; and IMHO the user's shortcuts for folding should still work).

Yeah I'm not sure how we would do that.  I do remember the old email client
for vim had some form of folding in the syntax file I think.  That seem right?

The other feature I'd like is to be able to view the full headers of an email.

    Ian

Re: notmuch vim patches

[Ian Main]

Franz Fellner wrote:
> 
>  
> > I'm starting to realize that I could default to using 'enter' to both
> > open URI's and view attachments.  Any other ideas welcome.
> 
> - make some of the functions public so users can bind them to keys they
>   want
> - introduce show_[prev,next]_unread_msg, probably factor out
>   "show_scroll_to_msg()" and implement prev/next msg with that?

You know I was just reading a thread and hit 'a' to archive a message
within the thread and for some reason it hung for a few seconds.. but it
made me think we should be able to press 'a' (or whatever archive key)
and have it archive and move to next unread.  That seems to me to be a
good behavior with a natural flow.

    Ian

> - use proper buffers instead of Scratch buffers, so BufExplorer also
>   shows notmuch-vim buffers
> - folding of messages; add option to fold read messages by default.
> 
> I think I can implement the second point (if you not already did
> that).
> I also looked into folding, but my knowledge of all the possiblities is
> not that good (manual folding markers look ugly, don't know if/how 'syntax'
> will work; and IMHO the user's shortcuts for folding should still work).
> 
> Franz
> _______________________________________________
> notmuch mailing list
> notmuch@notmuchmail.org
> http://notmuchmail.org/mailman/listinfo/notmuch

Re: notmuch vim patches

[Franz Fellner]

On Thu, 16 Oct 2014 15:30:11 -0700, Ian Main <imain@redhat.com> wrote:
> Franz Fellner wrote:
> > 
> >  
> > > I'm starting to realize that I could default to using 'enter' to both
> > > open URI's and view attachments.  Any other ideas welcome.
> > 
> > - make some of the functions public so users can bind them to keys they
> >   want
> > - introduce show_[prev,next]_unread_msg, probably factor out
> >   "show_scroll_to_msg()" and implement prev/next msg with that?
> 
> You know I was just reading a thread and hit 'a' to archive a message
> within the thread and for some reason it hung for a few seconds.. but it
> made me think we should be able to press 'a' (or whatever archive key)
> and have it archive and move to next unread.  That seems to me to be a
> good behavior with a natural flow.

Yes, sounds good.
Today I thought of a more generic approach:
pass a query that a message should match.
:notmuch-show-next-message tag:unread		# go to the next unread
message in thread
:notmuch-show-next-message from:"Ian Main" 	# got to the next
message in thread sent by "Ian Main"
...
The user then can map keys to custom commands.

Good or too generic?

Furthermore I thought of rearranging the sources:
- Put files in Vundle/*-compatible dirs, would simplify development.
  (Currently I have several files symlinked from notmuch-src into .vim)
- Put the "heavy" ruby code into its own file. Today I got an error I
  could not deal with because line numbers did not match. Also I read
  about the possibility that the ruby interpreter might optimize only
  seperate files. This could lead to better performance.

Franz

Re: notmuch vim patches

[Ian Main]

Franz Fellner wrote:
> On Thu, 16 Oct 2014 15:30:11 -0700, Ian Main <imain@redhat.com> wrote:
> > Franz Fellner wrote:
> > > 
> > >  
> > > > I'm starting to realize that I could default to using 'enter' to both
> > > > open URI's and view attachments.  Any other ideas welcome.
> > > 
> > > - make some of the functions public so users can bind them to keys they
> > >   want
> > > - introduce show_[prev,next]_unread_msg, probably factor out
> > >   "show_scroll_to_msg()" and implement prev/next msg with that?
> > 
> > You know I was just reading a thread and hit 'a' to archive a message
> > within the thread and for some reason it hung for a few seconds.. but it
> > made me think we should be able to press 'a' (or whatever archive key)
> > and have it archive and move to next unread.  That seems to me to be a
> > good behavior with a natural flow.
> 
> Yes, sounds good.
> Today I thought of a more generic approach:
> pass a query that a message should match.
> :notmuch-show-next-message tag:unread		# go to the next unread
> message in thread

next unread message in thread, and if there are no more in thread, the next
unread message in the next thread?

> :notmuch-show-next-message from:"Ian Main" 	# got to the next
> message in thread sent by "Ian Main"
> ...
> The user then can map keys to custom commands.
> 
> Good or too generic?

I'm not sure how easy it would be to invoke that.. if you think you'd use
it I'd say it's fine but I don't think I would.

> 
> Furthermore I thought of rearranging the sources:
> - Put files in Vundle/*-compatible dirs, would simplify development.
>   (Currently I have several files symlinked from notmuch-src into .vim)
> - Put the "heavy" ruby code into its own file. Today I got an error I
>   could not deal with because line numbers did not match. Also I read
>   about the possibility that the ruby interpreter might optimize only
>   seperate files. This could lead to better performance.
> 

Yes, that's a good idea too.  I notice that the github version has a
different layout. I think it is vundle compatible?  I know it makes moving
patches from the official repo to the github one challenging.

    Ian