Skip to content
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

Closed
257 opened this issue Mar 21, 2016 · 9 comments
Closed

vfolder-from-query seems broken #7

257 opened this issue Mar 21, 2016 · 9 comments
Assignees
Labels

Comments

@257
Copy link

257 commented Mar 21, 2016

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).

@flatcap flatcap added the bug label Mar 21, 2016
@flatcap flatcap self-assigned this Mar 21, 2016
@flatcap
Copy link
Member

flatcap commented Mar 21, 2016

@257 Hmm... I'm sorry, I don't see a problem.
Plus, I don't think I've changed any code that might have affected the Query function.

I've just tested mutt-1.5.24, mutt-tip (latest dev) and neomutt-20160320.
I created a small address file 'animals.txt', then

set query_command="grep '%s' ~/animals.txt"

Pressing 'm' (start mail), then 'hor' lists some animals containing 'hor'.
As expected.

Back in the index, pressing 'Q' (start query), 'hor' lists some animals containing 'hor'.
As expected.

What else can you tell me about your problem?

@257
Copy link
Author

257 commented Mar 21, 2016

hmm, Query: interface is used for both 'query external program for addr'
and vfolder-from-query. vfolder-from-query is what i was referring to.
'Q' (query external...) works fine here.

@257 257 changed the title 'Query:' is broken vfolder-from-query seems broken Mar 21, 2016
@karelzak
Copy link
Contributor

I can confirm it does not work, need more investigation.

@karelzak
Copy link
Contributor

 static int main_change_folder(MUTTMENU *menu, int op, char *buf, size_t bufsz,
                          int *oldcount, int *index_hint)
 {
   mutt_expand_path (buf, bufsz);
-  set_curbuffy(buf);
+#ifdef USE_SIDEBAR
+  if (sb_set_open_buffy (buf) == NULL)
+    return -1;
+#endif

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...

@257
Copy link
Author

257 commented Mar 21, 2016

@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?

@karelzak
Copy link
Contributor

All you need is:

diff --git a/curs_main.c b/curs_main.c
index 6fcdcd6..c2ff15c 100644
--- a/curs_main.c
+++ b/curs_main.c
@@ -598,8 +598,7 @@ static int main_change_folder(MUTTMENU *menu, int op, char *buf, size_t bufsz,
 {
   mutt_expand_path (buf, bufsz);
 #ifdef USE_SIDEBAR
-  if (sb_set_open_buffy (buf) == NULL)
-    return -1;
+  sb_set_open_buffy (buf);
 #endif
   if (mx_get_magic (buf) <= 0)
   {

karelzak added a commit to karelzak/mutt-kz that referenced this issue Mar 21, 2016
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>
@karelzak
Copy link
Contributor

@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 :-(

flatcap pushed a commit that referenced this issue Mar 21, 2016
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>
@flatcap
Copy link
Member

flatcap commented Mar 21, 2016

@karelzak Thanks.
I've pushed the change up to NeoMutt.

@257 Please can you try the new version:
git or source zip

Thanks, Rich.

@257
Copy link
Author

257 commented Mar 22, 2016 via email

@flatcap flatcap closed this as completed Mar 22, 2016
flatcap pushed a commit that referenced this issue Apr 4, 2016
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>
@guyzmo guyzmo added type:bug Bug and removed status:new-bug labels Jan 22, 2017
andir added a commit to andir/neomutt that referenced this issue Mar 18, 2020
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
flatcap pushed a commit to andir/neomutt that referenced this issue Mar 18, 2020
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
flatcap pushed a commit that referenced this issue Mar 18, 2020
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
rayfordshire added a commit to rayfordshire/neomutt that referenced this issue Feb 23, 2023
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.
flatcap pushed a commit to rayfordshire/neomutt that referenced this issue Feb 27, 2023
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.
rayfordshire added a commit to rayfordshire/neomutt that referenced this issue Mar 4, 2023
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.
rayfordshire added a commit to rayfordshire/neomutt that referenced this issue Mar 4, 2023
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.
flatcap pushed a commit to rayfordshire/neomutt that referenced this issue Mar 11, 2023
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.
flatcap pushed a commit to rayfordshire/neomutt that referenced this issue Mar 13, 2023
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.
flatcap pushed a commit to rayfordshire/neomutt that referenced this issue Mar 22, 2023
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.
flatcap pushed a commit to rayfordshire/neomutt that referenced this issue Mar 23, 2023
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.
flatcap pushed a commit to rayfordshire/neomutt that referenced this issue Apr 8, 2023
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.
flatcap pushed a commit to rayfordshire/neomutt that referenced this issue Apr 14, 2023
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.
flatcap pushed a commit to rayfordshire/neomutt that referenced this issue Apr 14, 2023
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.
flatcap pushed a commit to rayfordshire/neomutt that referenced this issue Apr 26, 2023
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.
flatcap added a commit that referenced this issue Apr 26, 2023
 * 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
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

4 participants