Latest release hangs on startup (macOS 12.7.4) about neomutt HOT 8 OPEN

Thanks, @bmclean2 that's very helpful.
The 'Assertion failure' is expected -- the code was undergoing some major changes in that side-branch.

Please can I ask that you do some different bisection, now -- that of your config.
First, please check that the basic NeoMutt works; zero config:

neomutt -n -F /dev/null

If that works, and I really hope it does, please can you comment out half of your config and start up NeoMutt.
If that works, try the other half.
Then repeat with smaller blocks.

One or more config lines is causing NeoMutt to get into a loop.
If you can find one, I can fix it.

Thanks ❤️

from neomutt.

Can confirm that the original problem is rectified by %> .

from neomutt.

Hi, to clarify: the title says "Latest release ...". Is it only happening with 20240416? If you switch back to a previous version this does not happen?

from neomutt.

20240329 starts up normally. I compiled it with the same options as the homebrew version except truecolor—couldn't figure out how to turn that on. So yes, only with 20240416

from neomutt.

Sorry about that. Are you maybe able to bisect the issue to a specific commit? Also can you try with the latest main?

I'm also on macOS, these are my usual configure options:

./configure --notmuch --with-notmuch=/opt/homebrew/opt/notmuch --disable-doc --disable-nls --lmdb --zlib --idn2 --with-idn=/opt/homebrew/opt/libidn2 --with-iconv=/opt/homebrew/opt/libiconv --with-ncurses=/opt/homebrew/opt/ncurses

truecolor depends on the ncurses version, afaik.

from neomutt.

The bisect found 9325596 as the problematic commit. Worth mentioning that while I was bisecting, 7520d13 printed this to the screen: Assertion failed: (DTYPE(he_base->type) == DT_STRING), function cs_subset_string, file helpers.c, line 301.

Edit (flatcap) unquote commits so that GitHub links them

from neomutt.

@flatcap, I did some more playing around on 20240416. This line is the culprit:

folder-hook . "set index_format='%3C %4Z %?X?& ? %D %-20.20F %.70s (%-4.4c) %>'"

Specifically, if I change the %4Z to %4z, it works. I'm not sure if this is a bug or a feature. The docs state that %Z should work, and indeed it worked in previous versions.

from neomutt.

Great find! (but I don't think %Z is to blame)
There's a mistake at the end of your format string.
The %> (hard padding) expando is missing the pad character.
It should read %> (percent, greater-than, space).

The parser ought to catch this.
For now, I've changed the code to default to (space).

Please can you give branch [devel/padding] a try (#4277)

Thanks

from neomutt.