New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
vfolder-from-query seems broken #7
Comments
@257 Hmm... I'm sorry, I don't see a problem. I've just tested mutt-1.5.24, mutt-tip (latest dev) and neomutt-20160320.
Pressing 'm' (start mail), then 'hor' lists some animals containing 'hor'. Back in the index, pressing 'Q' (start query), 'hor' lists some animals containing 'hor'. What else can you tell me about your problem? |
hmm, Query: interface is used for both 'query external program for addr' |
I can confirm it does not work, need more investigation. |
The code assumes that sidebar has clue about all folders, but this is not true because notmuch folders may be generated on-the-fly. In this case sidebar should be out of game... |
@karelzak what do you think of changing the prompt to qaddr (or whatever) so user can see it's querying for addr or perfoming vfolder-from-query? |
All you need is:
|
The code assumes that sidebar has clue about all folders, but in notmuch support may generate virtual folders on the fly from notmuch queries. Addresses: neomutt/neomutt#7 Signed-off-by: Karel Zak <kzak@redhat.com>
@flatcap see karelzak/mutt-kz@8c824f5 .. not sure how to force github to accept pull requests from another repository if the repository is not directly based on fork. I use "git remote" for neo stuff and it works as expected, unfortunately github is not smart enough for this work flow :-( |
The code assumes that sidebar has clue about all folders, but in notmuch support may generate virtual folders on the fly from notmuch queries. Addresses: #7 Signed-off-by: Karel Zak <kzak@redhat.com>
@karelzak Thanks. @257 Please can you try the new version: Thanks, Rich. |
works here, thanks.
|
The code assumes that sidebar has clue about all folders, but in notmuch support may generate virtual folders on the fly from notmuch queries. Addresses: #7 Signed-off-by: Karel Zak <kzak@redhat.com>
Neomutt would segfault if the mail that should be inserted into the header cache doesn't exist / failed to parse. I was previously observing the following crash: > $ bt > #0 memcpy (__len=0xa8, __src=0x0, __dest=0x7ffdcc8a8890) at /nix/store/hycbi8v31600cimx211ilj8p922nharl-glibc-2.30-dev/include/bits/string_fortified.h:34 > neomutt#1 dump (uidvalidity=0x0, off=0x7ffdcc8a8884, e=0x0, hc=0xc18330) at hcache/hcache.c:164 > neomutt#2 mutt_hcache_store (hc=hc@entry=0xc18330, key=0xc7d820 "/some/path/that/doesn't exist", > keylen=0x65, e=e@entry=0x0, uidvalidity=uidvalidity@entry=0x0) at hcache/hcache.c:592 > neomutt#3 0x000000000049d677 in append_message (h=h@entry=0xc18330, m=m@entry=0xc10580, q=q@entry=0xc3f460, msg=msg@entry=0xc0e4b0, dedup=dedup@entry=0x0) > at notmuch/mutt_notmuch.c:971 > neomutt#4 0x000000000049dd3c in read_mesgs_query (dedup=0x0, q=0xc3f460, m=0xc10580) at notmuch/mutt_notmuch.c:1125 > neomutt#5 nm_mbox_open (m=0xc10580) at notmuch/mutt_notmuch.c:2171 > neomutt#6 0x000000000044ee5e in mx_mbox_open (m=0xc10580, flags=<optimized out>) at mx.c:369 > neomutt#7 0x000000000043e574 in main (argc=0x1, argv=<optimized out>, envp=<optimized out>) at main.c:1152 > neomutt#8 0x00007f53c2303d8b in __libc_start_main () from /nix/store/9rabxvqbv0vgjmydiv59wkz768b5fmbc-glibc-2.30/lib/libc.so.6 > neomutt#9 0x000000000040bf6a in _start () at ../sysdeps/x86_64/start.S:120
Check if the mail was parsed before storing it in hcache. Neomutt would segfault if the mail that should be inserted into the header cache doesn't exist / failed to parse. I was previously observing the following crash: > $ bt > #0 memcpy (__len=0xa8, __src=0x0, __dest=0x7ffdcc8a8890) at /nix/store/hycbi8v31600cimx211ilj8p922nharl-glibc-2.30-dev/include/bits/string_fortified.h:34 > neomutt#1 dump (uidvalidity=0x0, off=0x7ffdcc8a8884, e=0x0, hc=0xc18330) at hcache/hcache.c:164 > neomutt#2 mutt_hcache_store (hc=hc@entry=0xc18330, key=0xc7d820 "/some/path/that/doesn't exist", > keylen=0x65, e=e@entry=0x0, uidvalidity=uidvalidity@entry=0x0) at hcache/hcache.c:592 > neomutt#3 0x000000000049d677 in append_message (h=h@entry=0xc18330, m=m@entry=0xc10580, q=q@entry=0xc3f460, msg=msg@entry=0xc0e4b0, dedup=dedup@entry=0x0) > at notmuch/mutt_notmuch.c:971 > neomutt#4 0x000000000049dd3c in read_mesgs_query (dedup=0x0, q=0xc3f460, m=0xc10580) at notmuch/mutt_notmuch.c:1125 > neomutt#5 nm_mbox_open (m=0xc10580) at notmuch/mutt_notmuch.c:2171 > neomutt#6 0x000000000044ee5e in mx_mbox_open (m=0xc10580, flags=<optimized out>) at mx.c:369 > neomutt#7 0x000000000043e574 in main (argc=0x1, argv=<optimized out>, envp=<optimized out>) at main.c:1152 > neomutt#8 0x00007f53c2303d8b in __libc_start_main () from /nix/store/9rabxvqbv0vgjmydiv59wkz768b5fmbc-glibc-2.30/lib/libc.so.6 > neomutt#9 0x000000000040bf6a in _start () at ../sysdeps/x86_64/start.S:120
Check if the mail was parsed before storing it in hcache. Neomutt would segfault if the mail that should be inserted into the header cache doesn't exist / failed to parse. I was previously observing the following crash: > $ bt > #0 memcpy (__len=0xa8, __src=0x0, __dest=0x7ffdcc8a8890) at /nix/store/hycbi8v31600cimx211ilj8p922nharl-glibc-2.30-dev/include/bits/string_fortified.h:34 > #1 dump (uidvalidity=0x0, off=0x7ffdcc8a8884, e=0x0, hc=0xc18330) at hcache/hcache.c:164 > #2 mutt_hcache_store (hc=hc@entry=0xc18330, key=0xc7d820 "/some/path/that/doesn't exist", > keylen=0x65, e=e@entry=0x0, uidvalidity=uidvalidity@entry=0x0) at hcache/hcache.c:592 > #3 0x000000000049d677 in append_message (h=h@entry=0xc18330, m=m@entry=0xc10580, q=q@entry=0xc3f460, msg=msg@entry=0xc0e4b0, dedup=dedup@entry=0x0) > at notmuch/mutt_notmuch.c:971 > #4 0x000000000049dd3c in read_mesgs_query (dedup=0x0, q=0xc3f460, m=0xc10580) at notmuch/mutt_notmuch.c:1125 > #5 nm_mbox_open (m=0xc10580) at notmuch/mutt_notmuch.c:2171 > #6 0x000000000044ee5e in mx_mbox_open (m=0xc10580, flags=<optimized out>) at mx.c:369 > #7 0x000000000043e574 in main (argc=0x1, argv=<optimized out>, envp=<optimized out>) at main.c:1152 > #8 0x00007f53c2303d8b in __libc_start_main () from /nix/store/9rabxvqbv0vgjmydiv59wkz768b5fmbc-glibc-2.30/lib/libc.so.6 > #9 0x000000000040bf6a in _start () at ../sysdeps/x86_64/start.S:120
The colours #000000 to neomutt#7 correspond to the numbers 0 to 7. Even when calling the *_extended_* functions of ncurses those colours correspond to the eight default terminal colours and not to some dark blacks. Interestingly, colour numbers 8 to 15 (the default bright colours of the terminal), do not show this behaviour. As a workaround we round these eight RGB colours up to neomutt#8 (the darkest black we can achieve) and hope nobody notices.
The colours #000000 to neomutt#7 correspond to the numbers 0 to 7. Even when calling the *_extended_* functions of ncurses those colours correspond to the eight default terminal colours and not to some dark blacks. Interestingly, colour numbers 8 to 15 (the default bright colours of the terminal), do not show this behaviour. As a workaround we round these eight RGB colours up to neomutt#8 (the darkest black we can achieve) and hope nobody notices.
The colours #000000 to neomutt#7 correspond to the numbers 0 to 7. Even when calling the *_extended_* functions of ncurses those colours correspond to the eight default terminal colours and not to some dark blacks. Interestingly, colour numbers 8 to 15 (the default bright colours of the terminal), do not show this behaviour. As a workaround we round these eight RGB colours up to neomutt#8 (the darkest black we can achieve) and hope nobody notices.
The colours #000000 to neomutt#7 correspond to the numbers 0 to 7. Even when calling the *_extended_* functions of ncurses those colours correspond to the eight default terminal colours and not to some dark blacks. Interestingly, colour numbers 8 to 15 (the default bright colours of the terminal), do not show this behaviour. As a workaround we round these eight RGB colours up to neomutt#8 (the darkest black we can achieve) and hope nobody notices.
The colours #000000 to neomutt#7 correspond to the numbers 0 to 7. Even when calling the *_extended_* functions of ncurses those colours correspond to the eight default terminal colours and not to some dark blacks. Interestingly, colour numbers 8 to 15 (the default bright colours of the terminal), do not show this behaviour. As a workaround we round these eight RGB colours up to neomutt#8 (the darkest black we can achieve) and hope nobody notices.
The colours #000000 to neomutt#7 correspond to the numbers 0 to 7. Even when calling the *_extended_* functions of ncurses those colours correspond to the eight default terminal colours and not to some dark blacks. Interestingly, colour numbers 8 to 15 (the default bright colours of the terminal), do not show this behaviour. As a workaround we round these eight RGB colours up to neomutt#8 (the darkest black we can achieve) and hope nobody notices.
The colours #000000 to neomutt#7 correspond to the numbers 0 to 7. Even when calling the *_extended_* functions of ncurses those colours correspond to the eight default terminal colours and not to some dark blacks. Interestingly, colour numbers 8 to 15 (the default bright colours of the terminal), do not show this behaviour. As a workaround we round these eight RGB colours up to neomutt#8 (the darkest black we can achieve) and hope nobody notices.
The colours #000000 to neomutt#7 correspond to the numbers 0 to 7. Even when calling the *_extended_* functions of ncurses those colours correspond to the eight default terminal colours and not to some dark blacks. Interestingly, colour numbers 8 to 15 (the default bright colours of the terminal), do not show this behaviour. As a workaround we round these eight RGB colours up to neomutt#8 (the darkest black we can achieve) and hope nobody notices.
The colours #000000 to neomutt#7 correspond to the numbers 0 to 7. Even when calling the *_extended_* functions of ncurses those colours correspond to the eight default terminal colours and not to some dark blacks. Interestingly, colour numbers 8 to 15 (the default bright colours of the terminal), do not show this behaviour. As a workaround we round these eight RGB colours up to neomutt#8 (the darkest black we can achieve) and hope nobody notices.
The colours #000000 to neomutt#7 correspond to the numbers 0 to 7. Even when calling the *_extended_* functions of ncurses those colours correspond to the eight default terminal colours and not to some dark blacks. Interestingly, colour numbers 8 to 15 (the default bright colours of the terminal), do not show this behaviour. As a workaround we round these eight RGB colours up to neomutt#8 (the darkest black we can achieve) and hope nobody notices.
The colours #000000 to neomutt#7 correspond to the numbers 0 to 7. Even when calling the *_extended_* functions of ncurses those colours correspond to the eight default terminal colours and not to some dark blacks. Interestingly, colour numbers 8 to 15 (the default bright colours of the terminal), do not show this behaviour. As a workaround we round these eight RGB colours up to neomutt#8 (the darkest black we can achieve) and hope nobody notices.
The colours #000000 to neomutt#7 correspond to the numbers 0 to 7. Even when calling the *_extended_* functions of ncurses those colours correspond to the eight default terminal colours and not to some dark blacks. Interestingly, colour numbers 8 to 15 (the default bright colours of the terminal), do not show this behaviour. As a workaround we round these eight RGB colours up to neomutt#8 (the darkest black we can achieve) and hope nobody notices.
* Allow 24bit colors * Refactor parse_color_name() * Add color_directcolor config variable * Colors: Allow #RRGGBB colours syntax * Colors: If convert xterm colors ("color123") to RGB * Colors: Workaround for colors #000000 to #7 * Colors: Test on startup whether 24bit colors are supported * auto.def: Test if ncurses is new enough for 24bit colours * Colour docs: Note that `default` is transparent * docs: Document #RRGGBB color syntax and $color_directcolor * Add MoreArgsF() which is MoreArgs() but understands flags * Color: Allow '#' without quoting in #RRGGBB color syntax
i get 0 results for any Query invoked in command mode. notmuch works though since i get my vfolders as before (before == with mutt-kz).
The text was updated successfully, but these errors were encountered: