mutt-kz

mutt-kz@lists.fedoraproject.org

138 discussions

Re: [mutt-kz] release based on mutt-1.5.24 (#118)
by Karel Zak 23 Mar '16

23 Mar '16

On Thu, Jan 07, 2016 at 07:18:16AM -0800, Thomas Klausner wrote: > Please merge the changes and make a release based on that version Thank you! I'll very probably merge stuff from neomutt/mutt-kz (from Richard Russon). The result should be mutt-kz synced with the current mutt upstream. It seems that after years mutt upstream is again active, so it's probably good idea to regularly rebase our changes to keep things up to date. (It means that "git pull --force" or so will be necessary to fetch mutt-kz.) The next step (I hope end of this week or begin of the next week) will be release mutt-kz tarball. And sorry for my delays, I'm busy with util-linux and with work on RHEL... Karel -- Karel Zak <kzak(a)redhat.com> http://karelzak.blogspot.com

3 5

marking message as unread
by Jan Hutař 14 Mar '16

14 Mar '16

Hello, I'm trying to mark message as unread after I opened it. I have this in .muttrc: virtual-mailboxes \ 'INBOX' 'notmuch://?query=tag:inbox and NOT tag:archive' \ [...] macro index U "<modify-labels>+unread\n" but it just do not work on majority of messages. When I run mutt with, say, "-d 2", it says: [2016-03-14 21:28:13] nm: find message (bug-1249655-203706-qqlNkcbOWR(a)bugzilla.redhat.com) [2016-03-14 21:28:13] nm: tags modify: '+unread' [2016-03-14 21:28:13] nm: add tag: 'unread' [2016-03-14 21:28:13] nm: tags update requested (bug-1249655-203706-qqlNkcbOWR(a)bugzilla.redhat.com) [2016-03-14 21:28:13] nm: tags unchanged [2016-03-14 21:28:13] nm: db close and message is still shown as read, but tags seems to be set correctly: $ notmuch dump id:bug-1249655-203706-qqlNkcbOWR@bugzilla.redhat.com +inbox +unread -- id:bug-1249655-203706-qqlNkcbOWR@bugzilla.redhat.com I'm most probably missing something obvious. Looks like that "unread" tag is not used by Mutt to determine if message was already red. Could somebody please point me in right direction? Thank you in advance, Jan -- Jan Hutar Systems Management QA jhutar(a)redhat.com Red Hat, Inc.

1 0

#118 and beyond...
by Richard Russon 14 Mar '16

14 Mar '16

In issue #118 Thomas Klausner asks if someone could update notmuch to mutt-1.5.24. Done. That, and much much more... mutt-kz consists of quite a few elements: Major features: sidebar notmuch Minor features: conditional dates index-color nested-if progress bar quasi-delete status-color tls-sni Misc: bug-fixes for Mutt However, the current version of mutt-kz is missing: Some important mutt code commits Most of the translation commits Many bugfixes in the minor features My wonderful new version of the sidebar patch I've brought mutt-kz up-to-date. The branch names in [] refer to my work repository on github. The diagram, below, may help you understand the relationships between the branches (red: mutt; green: sidebar; cyan: notmuch). https://github.com/neomutt/flatcap https://flatcap.org/mutt/flatcap.png I started with the latest version of mutt-kz [kz/master] which contains 394 commits since the Last Common Ancestor with mutt [mutt/lca]. Rebase onto: [mutt/1.5.24] -> [kz/rebase1] (160 commits) [combine/minor/20160307] -> [kz/rebase2] (148 commits) [combine/sidebar/20160307] -> [kz/rebase3] (129 commits) Any mutt-kz bug-fixes that weren't notuch-related have been moved to either [feature/bugfix] or the relevant feature branch. The minor features have been merged into [combine/minor/20160307] The icons represent the order in which the features were merged. This brings mutt-kz now up-to-date, but still needs a little tidying. Refactor: [kz/refactor1] (116 commits) Tidy remaining rebase artifacts I've tweaked the history a little here (in very minor ways). e.g. folded pairs like: Introduce typo Fix typo Move notmuch build changes to beginning [kz/refactor2] [kz/release2] (110 + 2 commits) Factor out kz-build-related commit The kz-version number isn't a part of the notmuch code. gitignore changes folded kz-versioning changes folded [kz/release2] (yellow on diagram) represents the kz-versioning. These are changes you want for mutt-kz, but don't want to be merged into Mutt upstream. [kz/refactor3] [kz/release3] (110 + 2 commits) Trailing whitespace Rework all the commits to prevent the introduction of trailing whitespace. Tidy commit messages Most commits in the repo were prefixed with "notmuch:". Now the notmuch code is isolated in its own branch, the prefix isn't needed. Fold commit messages Fit to git standards The code REMAINS THE SAME, but the 'churn' is reduced This should making rebasing simpler. I've been very careful not to make any functional changes and the authorship of commits is maintained. What next? Adoption -- I would like you to adopt one of these branches. Ideally [kz/refactor3] Once you've picked a repo, I will start submitting changes to: Tidy the Sidebar code that Notmuch introduces Fix mutt-kz's remaining Sidebar issues Rename <sidebar-toggle> to <sidebar-toggle-virtual> Sidebar currently has <sidebar-toggle-visible> Integrate [combine/extra/20160307] Number of useful small features Integrate other downstream/distro bugfixes Hope this all makes sense. -- Rich Russon (FlatCap) <rich(a)flatcap.org>

3 2

[PATCH 1/2] mutt, notmuch: Update 'unread' tag for all files mapped to msg
by Don Zickus 15 Dec '15

15 Dec '15

I ran into an issue where I would read an email in my inbox that was sent to me and cc'd a mailing list and it would not remove the 'unread' tag after syncing the mailbox. Apparently, when nm_synci'ing the message, the local inbox copy would be recognized as seen but the duplicate copy in the mailing list folder would still be in the 'new' directory, so the 'unread' flag would not be cleared. The way the 'duplicate' messags where handled in 'rename_filename', it appears after the add/remove the local copy of 'msg' was not updated with the new paths. I fixed this by destorying the message and then re-reading it from the notmuch database. However, the tags were still off. I had to further call 'update_header_flags' to re-read the tags from the database (using the updated paths) to clear the 'unread' tag. Both of these changes seem to work as expected now. Signed-off-by: Don Zickus <dzickus(a)redhat.com> -- I am not too familar with this code, so my changes may not be correct. I do know they seem to work after a couple of days of testing. --- mutt_notmuch.c | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/mutt_notmuch.c b/mutt_notmuch.c index 1a39249..3a25cc1 100644 --- a/mutt_notmuch.c +++ b/mutt_notmuch.c @@ -1474,6 +1474,9 @@ static int rename_filename(struct nm_ctxdata *data, notmuch_database_add_message(db, newpath, NULL); } } + notmuch_message_destroy(msg); + msg = NULL; + notmuch_database_find_message_by_filename(db, new, &msg); st = NOTMUCH_STATUS_SUCCESS; break; default: @@ -1484,6 +1487,7 @@ static int rename_filename(struct nm_ctxdata *data, if (st == NOTMUCH_STATUS_SUCCESS && h && msg) { notmuch_message_maildir_flags_to_tags(msg); + update_header_tags(h, msg); update_tags(msg, nm_header_get_tags(h)); } -- 1.8.4

2 4

virtual folder sidebar provides deceiving new email count
by Don Zickus 04 Dec '15

04 Dec '15

Hi, I stumbled upon mutt-kz, notmuch and afew a couple of months ago and have been fairly happy with how they all work together. One of the quirks I haven't figure out yet, is my sidebar virtual folder new email count. I have a virtual folder Inbox that contains all notmuch query 'to:dzickus@redhat.com'. Going into that folder works great. However, when I leave that folder to go to another virtual folder, it says I have some new messages in my Inbox folder. When I go back into my 'Inbox' folder there is no new messages waiting. Digging through the notmuch database I am _guessing_ the problem is duplicate messages from a mailing list sent to me or cc'd to me. Further guessing is that I am clearing the new flag (by reading the email) in one of the copies but not the other? Querying notmuch produces the same 'unread' count as the virtual folder, so I don't believe mutt-kz is reading anything wrong. So my guess was duplicate files, though I haven't figured out the right notmuch-fu to conclude that properly. Thoughts? Tips? (using mutt-kz::5147a6c1921) Thanks again for the tool! Cheers, Don

1 0

Do you _only_ use virtual folders?
by Xu Wang 19 Nov '15

19 Nov '15

Currently I have it set up so I press a shortcut that takes me to a virtual folder for my inbox. I'm not sure why I don't just by default only use virtual folders. I think the reasoning is I was concerned that if I deleted a message I wasn't sure whether I would delete it from my inbox or a different location that was made available because of finding the thread. I don't know if this is to be a legitimate concern or not. Is there a reason not to only use virtual folders? Do you use virtual folders by default or do you only switch when you e.g. want to open a thread? Kind regards, Xu

3 3

trash patch on mutt-kz
by Xu Wang 05 Sep '15

05 Sep '15

Hi, I (think I) would like to use the trash patch. Does mutt-kz already have it built in? I tried to do set trash = '+[Gmail].Trash' but that doesn't seem to work. Has anyone a suggestion? Kind regards, Xu

1 0

notmuch as query_command
by Víctor M. Jáquez L. 22 Jul '15

22 Jul '15

Hi, A friend of mine has written a small app for looking address using notmuch's database: https://github.com/aperezdc/notmuch-addrlookup-c But just recently he added support for mutt query_command: set query_command = "notmuch-addrlookup --mutt %s" et voilà vmjl

3 3

Virtual folders always empty
by Glenn Golden 17 Jul '15

17 Jul '15

Hello muttkzoids, First, +1 for a great forking idea, nice combo of two excellent tools. Having a bit of trouble getting virtual folders to work though. Attempting to do <sidebar-open> always results in an empty folder, regardless of the search term. With -d3, seeing stuff like this in the debug log (apparent error noted with "==>") [ ... ] [2015-07-15 03:32:09] Reading notmuch://?query=smc... [2015-07-15 03:32:09] nm: initialize context data 0x954ce68 [2015-07-15 03:32:09] nm: reading messages...[current count=0] [2015-07-15 03:32:09] nm: db filename '/home/XXX/Mail' [2015-07-15 03:32:09] nm: db open '/home/XXX/Mail' [READ] (timeout 5) [2015-07-15 03:32:09] nm: query 'smc' [2015-07-15 03:32:09] nm: query successfully initialized [2015-07-15 03:32:09] nm: appending message, i=0, id=[...], path=[...] [2015-07-15 03:32:09] nm: allocate mx memory [2015-07-15 03:32:09] nm: initialize header data: [hdr=0x95856c0, data=0x9585328] (notmuch-sha1-[...]) [2015-07-15 03:32:09] nm: path update requested path=/home/XXX/[...], (notmuch-sha1-[ ... ]) [2015-07-15 03:32:09] nm: freeing header 0x9585328 ==> [2015-07-15 03:32:09] nm: failed to append header! [2015-07-15 03:32:09] nm: appending message, i=0, id=XXXXX, path=[...] [2015-07-15 03:32:09] parse_parameters: `charset="iso-8859-1"' [2015-07-15 03:32:09] parse_parameter: `charset' = `iso-8859-1' [2015-07-15 03:32:09] nm: initialize header data: [hdr=0x9585708, data=0x95855a8] ([ ... ] ) [2015-07-15 03:32:09] nm: path update requested path=[...] [2015-07-15 03:32:09] nm: freeing header 0x95855a8 ==> [2015-07-15 03:32:09] nm: failed to append header! [ ... ] When notmuch is executed from the commandline with the same query term, it seems to behave normally. Version info: mutt-kz 1.5.23.1 obtained via Arch AUR, configured with --enable-debug, and notmuch 0.20.1. Muttrc doesn't seem to be implicated, but for completeness, tried it with the minimal muttrc given here http://notmuchmail.org/mutttips/ and see the same problem. Any ideas on how to track this down further?

2 3

synced with upstream
by Karel Zak 17 Jul '15

17 Jul '15

Hi all, I have merged all the latest (and some missing old) patches from mutt upstream to mutt-kz. It works for my use-cases, but it would be nice to re-test GPG and keys stuff as there has been some conflicts and currently it's the most actively developed part of the mutt (thanks to Kevin). Karel -- Karel Zak <kzak(a)redhat.com> http://karelzak.blogspot.com

2 1

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

mutt-kz