Stefan Kangas writes: > Joseph Mingrone writes: >> It's still a problem (26.3 and 2019-09-15 master-branch build) in that the dialog is not displayed, but the Emacs process no longer consumes 100% CPU. > Thanks for reporting back. >> Here is a simple recipe to reproduce the problem. It assumes the FreeBSD ports tree is installed in the default location, which is /usr/ports. > Can you think of any way to reproduce this if you are not using > FreeBSD? Is there some particular command run by "make config" that > makes eshell freeze for example? It seems to me that very few Emacs > developers are using FreeBSD, and I personally don't have access to > any FreeBSD systems for debugging. I would guess any GNU/Linux command that also presents these curses dialogs would have problems. If you or any Emacs developer wants a FreeBSD shell account, I can provide one. https://invisible-island.net/dialog/dialog-figures.html To be clear, it seems like less of a freeze now and more like an inability to display the dialog and the point becomes lost requiring users to kill eshell. So, it is much less severe of a problem than in the past. >> Instead of the dialog displaying, eshell becomes unusable (blank screen and no keys will return the prompt). Trying to exit by hitting TAB/Enter reports >> Completion function pcomplete-completions-at-point uses a deprecated calling convention >> Warning: pcomplete-completions-at-point failed to return valid completion data! >> You can switch buffers and kill the eshell process now though. > What happens if you run M-x toggle-debug-on-error before trying to > reproduce? Do you then get a backtrace? There is no backtrace. Regards, Joseph