Menu
▾
▴
#310 Segfault when resizing with ^T menu open
Start joe at the normal 80x24 size. Press ^T to open the menu (it opens in 3 columns). Slowly resize the terminal to make it wider. At some point the menu entries are rearranged to 4 columns. Later, when they should be rearranged to 5 columns, joe segfaults instead.
Probably strongly related: Start joe at 105 column wide terminal, open the ^T menu, it's arranged in 4 columns. Widen the terminal to 106, the menu is rearranged in 5 columns, where the bottom line duplicates the entries of the top menu line. You can't move the cursor to the bottom line, but if you press the right arrow within the top menu line, both occurrences of the menu entires become highlighted.
It's even more visible if ^T is opened when joe is so narrow that it's arranged in 1 column. Apparently joe totally forgets to recompute the number of necessary lines for the menu when the width changes.
The prompt not being resized is also observable at ^C's "Lose changes to this file (y,n,^C)?"
In what way is the "Lose changes to this file" prompt not resized? It's one line and not very long. Shoot me an email or re-open for that problem (the fix is unrelated to that prompt).
From the looks of things, child windows weren't designed to be resized vertically. There's some window fitting going on when they get created and such. It might be an interesting experiment, however...
That said, this bug was actually fixed back in 2010, but the fix only got applied to the coroutine branch. I backported it and committed in [9cb980].
Related
Commit: [9cb980]