[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: |
Joseph Mingrone |
Subject: |
bug#14473: 24.3; emacs locks up when eshell attempts to display a dialog |
Date: |
Mon, 14 Oct 2019 14:53:35 -0300 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (berkeley-unix) |
Stefan Kangas <stefan@marxist.se> writes:
> 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
Hi Stefan,
RET or TAB RET does not return to the eshell prompt here.
Switching to term mode by adding ("make" "config") `to
eshell-visual-subcommands' does now work, so I think this bug can be
closed. I had this commented out in my config, so assume I tried
it at one point and it didn't work. I should have checked this again
when you contacted me though.
Running `make config` was more common in the past, but many FreeBSD
users now install pre-built packages or build their own packages with
tools on top of the ports tree. I am less familiar with OpenBSD, but am
relatively confident that most OpenBSD users install pre-built packages.
Another complication is that many users would run this as `sudo make
config` or `doas make config` on OpenBSD.
Thank you,
Joseph
signature.asc
Description: PGP signature