bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#14473: 24.3; emacs locks up when eshell attempts to display a dialog


From: Stefan Kangas
Subject: bug#14473: 24.3; emacs locks up when eshell attempts to display a dialog
Date: Tue, 8 Oct 2019 16:05:54 +0200

Hi Joseph,

Joseph Mingrone <jrm@ftfl.ca> 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.

Thank you, noted.  There are indeed (a small number of) open bugs
regarding *BSD systems, so I'm hoping that someone will take you up on
that offer.  I might if I find the time.

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

Yes, after installing "dialog", I'm able to reproduce the problem on
my system using this command:

    dialog --yesno "foobar" 10 50

In my case, hitting RET brings me back to the eshell prompt.

I think the problem is that eshell just doesn't support the control
characters that ncurses is producing, meaning that it has to switch to
term-mode to get that to work.  Luckily, there are user options you
could set to make eshell do that automatically.

I created a Makefile with:

    config:
        dialog --yesno "foobar" 10 50

Using that Makefile, saying "make config" in eshell opens it in
term-mode automatically after I evaluate:

    (add-to-list 'eshell-visual-subcommands '("make" "config"))

Does setting that option solve the issues you're seeing too?

If so, I think we can just write this up as a limitation in eshell,
and recommend users to configure this variable.  Also see
eshell-visual-commands and eshell-visual-options for more.

One final thing, is running "make config" common on FreeBSD?  I guess
it's part of the "ports" system that pretty much everyone uses,
including people on OpenBSD?  If so, perhaps it would be worth
changing the default of eshell-visual-subcommands from nil to
something like:

    (when (equal system-type 'berkeley-unix) '(("make" "config")))

Best regards,
Stefan Kangas





reply via email to

[Prev in Thread] Current Thread [Next in Thread]