Request to add notmuch

[kvaneesh]

Can we add a new layer for notmuch ?

[swaroopch]

@kvaneesh There is already a gnus layer - https://github.com/syl20bnr/spacemacs/tree/master/contrib/!email/gnus - please feel free to contribute a layer for notmuch - https://github.com/syl20bnr/spacemacs/blob/master/doc/DOCUMENTATION.md#configuration-layers

[kvaneesh]

I am not sure how a gnus layer would help. I currently have a private layer which does minimal stuff. But I don't enough to remap (SPC) which is used by notmuch layer.

NOTE: I solved that by using different keybinding instead of SPC in notmuch.

[cpaulik]

I've been playing with notmuch a little bit in the last weeks and have started a private layer for it. But there is a lot of stuff that is not working.

There are also issues with the starting page of notmuch and evil-movement keys.

[StreakyCobra]

@cpaulik Does your notmuch layer improved? 😄

[cpaulik]

No. I'm using mu4e now.

[StreakyCobra]

@cpaulik Ok thanks.

@kvaneesh can mu4e solve your needs? (PR in progress: #2514)

[kvaneesh]

I won't be switching to mu4e, and I am also not in a position to contribute the notmuch layer. So if you are looking at closing this issue, because nobody is going to look at this soon, please feel free to do so.

-aneesh

[StreakyCobra]

No no, your request is valid, I was just trying to see if there was some news on this side ☺️

[a13ph]

There's some work on it done by @lehoff

It will be linked or backlinked here when it's published :D

[lehoff]

I have raised #5239 re the collision I have with key bindings.

If someone finds my notmuch layer of any use, then I could clean it up.
But I think some work has to go into how to provide sensible key bindings for the layer. I would need some help on that.

[wwentland]

@lehoff It would definitely be appreciated!

[lehoff]

Hi,

I have put something together, but it might be too specific for my usage to
generally shareable...

https://github.com/lehoff/dotfiles/tree/master/my-notmuch

E.g., I have my sendmail info in there, I use msmtp to queue my mail and I
use offlineimap to fetch my mail. And I have nottoomuch-addresses hooked
into my post-sync hook outside emacs.

If someone has a good recommendation on how to separate those things out
then I could turn the generic things into a layer.
I don't fully grok the layers, so advice on how this could be done would be
nice. If I move the generic parts into a public notmuch layer, how should I
then do my personal configuration?

And I am open to changing some of the keymappings. I am using T to trash a
mail thread (only in the search window) or an individual mail. Would be
nice if it could would more like a and A - i.e., when viewing a mail "a"
archives the current message and "A" archives the entire thread. Maybe I
should just use "d" and "D" to get the same behaviour as archiving.

Thoughts are most welcome.

With some guidance we can have a layer for notmuch out very soon.

Cheers,
Torben

On 31 May 2016 at 22:33, Wolodja Wentland notifications@github.com wrote:

@lehoff https://github.com/lehoff It would definitely be appreciated!

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#2163 (comment),
or mute the thread
https://github.com/notifications/unsubscribe/AALyChlAnlTPBXekfvURDts0_lM1RE25ks5qHJsUgaJpZM4FQWN7
.

http://www.linkedin.com/in/torbenhoffmann
@lehoff

[butterthebuddha]

Any progress on this?

[jb55]

I wish!

[FrancescElies]

I'm also quite interested on this one, I am putting some stuff together most of the code coming from @lehoff
Is there any place where things could be discussed? I would like to open a pull request with what I've done so far, and discuss the changes over there.

What I did so far lives in this commit FrancescElies@f307d81e

Would someone be interested in helping out?

[jb55]

Would someone be interested in helping out?

Yes! I have some time this week to test this.

[jb55]

I have limited connectivity (I'm in the middle of the woods somewhere) so I can't do an extensive review via GitHub's interface. So I'll do that here. I have a few comments: ## Message archiving `spacemacs/notmuch-message-archive`: I noticed when archiving from the search view it was using a custom archiving routine (+archive -inbox -unread). This shouldn't be necessary since `notmuch-search-archive-thread` does the same thing and can be customized by changing `notmuch-archive-tags`. This also makes `spacemacs/archive-by-removing-inbox-tag` redundant as well. ## zz bindings Another thing that I think we should do is make the zz,zt,zb,etc evil bindings work in notmuch-show. I use these a lot when reading email and having to `f d z t` is a bit annoying. Right now z is bound to tree view search so we could rebind that. ## custom hooks ```elisp ;; from https://github.com/fgeller/emacs.d/blob/master/email.org (add-hook 'notmuch-show-hook 'spacemacs/notmuch-show-prefer-html-over-text) ``` Should the notmuch layer be opinionated about how email is shown? There is already a bunch of customizable options in notmuch-show for this. ## message-sendmail-f-is-evil ```elisp (setq message-sendmail-f-is-evil 't) ``` The notmuch layer probably shouldn't be opinionated about how email is sent... ## fixed previous buffer issue ```elisp ;; fixes: killing a notmuch buffer does not show the previous buffer (push "\\*notmuch.+\\*" spacemacs-useful-buffers-regexp) ``` OMG this was such a pain! Thanks! I have some of my working patches at `github/jb55/spacemacs/notmuch-layer`, mostly with respect to the message archiving issue for now. Let me know what you think. Other than that it seems to be working great! I've just started testing this so I'll add more comments if I have any more.

[mpe]

William Casarin <notifications@github.com> writes:

## fixed previous buffer issue ```elisp ;; fixes: killing a notmuch buffer does not show the previous buffer (push "\\*notmuch.+\\*" spacemacs-useful-buffers-regexp) ``` OMG this was such a pain! Thanks!

I also have: (push "\\*unsent mail.*\\*" spacemacs-useful-buffers-regexp) Though I suspect that buffer naming doesn't come from notmuch, so maybe it's not the notmuch layers business to push that regexp. It is useful though. cheers

[FrancescElies]

@jb55, I agree with your points, I added two more commits on top of yours addressing your suggestions.
One to removing stuff and the other one addressing the zz bindings.

@mpe do you also have a branch with your configurations and stuff you would like to share?
If I understand correctly I believe usent name comes from gnus

[jb55]

@jb55, I agree with your points, I added a commit two more commits on top of yours addressing your suggestions. One to removing stuff and the other one addressing the `zz bindings`.

After thinking about it some more I'm a bit reluctant about the zz bindings. My "real" goal was to have normal-mode-like feel when reading email. Such as jumping around paragraphs with { and }, etc. I'm not sure if there's a way to retain normal-mode bindings somehow. I'm not that familiar with evilified states so I'm not even sure if this is possible. For now I think we shouldn't re-add normal mode mappings to the notmuch-show evilified state as that seems a bit ad-hoc...

[FrancescElies]

After thinking about it some more I'm a bit reluctant about the zz bindings. My "real" goal was to have normal-mode-like feel when reading email. Such as jumping around paragraphs with { and }, etc. I'm not sure if there's a way to retain normal-mode bindings somehow. I'm not that familiar with evilified states so I'm not even sure if this is possible. For now I think we shouldn't re-add normal mode mappings to the notmuch-show evilified state as that seems a bit ad-hoc...

@jb55 I am also not sure how to address that, the zz feels like a workaround to me too. By the way, I rebased my branch on top of yours.

[FrancescElies]

FWIW, I've actually been trying to do basically just that a bit more generally: i.e., in evilified state, fall back to motion-state keybindings before global keybindings. The second half of this comment might be useful: #9451 (comment)

@braham-snyder Interesting, thanks for sharing! If I understand correctly this changes are in your fork only, right?

[FrancescElies]

@jb55 I picked @braham-snyder's commit braham-snyder@24e91f8, I will give it a shot during this week.

[jb55]

#9927

[syl20bnr]

The layer has been merged in develop branch.

[jb55]

this can be closed

[d12frosted]

It will be closed with next release :)

P. S. Missclick

[jb55]

oh right

[github-actions]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Please let us know if this issue is still valid!