From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: [External] : Re: Would you say this information window is well designed? Date: Sun, 28 Feb 2021 19:32:59 +0200 Message-ID: <83sg5gm71w.fsf@gnu.org> References: <83eeh6vmg2.fsf@gnu.org> <835z2ivknw.fsf@gnu.org> <83sg5mu1hn.fsf@gnu.org> <83r1l6tzbo.fsf@gnu.org> <8f6be1e9-09ab-09ae-69cd-eef092d4dc8b@yandex.ru> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="2719"; mail-complaints-to="usenet@ciao.gmane.io" Cc: laszlomail@protonmail.com, larsi@gnus.org, stefankangas@gmail.com, drew.adams@oracle.com, emacs-devel@gnu.org To: Dmitry Gutov Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sun Feb 28 18:34:37 2021 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1lGPxl-0000bv-8y for ged-emacs-devel@m.gmane-mx.org; Sun, 28 Feb 2021 18:34:37 +0100 Original-Received: from localhost ([::1]:47520 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lGPxk-0002CZ-9W for ged-emacs-devel@m.gmane-mx.org; Sun, 28 Feb 2021 12:34:36 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:36202) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lGPwL-0001UL-JI for emacs-devel@gnu.org; Sun, 28 Feb 2021 12:33:16 -0500 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:52485) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lGPwK-00013K-TJ; Sun, 28 Feb 2021 12:33:08 -0500 Original-Received: from 84.94.185.95.cable.012.net.il ([84.94.185.95]:3655 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1lGPwI-0004rT-Uo; Sun, 28 Feb 2021 12:33:07 -0500 In-Reply-To: <8f6be1e9-09ab-09ae-69cd-eef092d4dc8b@yandex.ru> (message from Dmitry Gutov on Sat, 27 Feb 2021 23:44:18 +0200) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:265751 Archived-At: > Cc: drew.adams@oracle.com, stefankangas@gmail.com, larsi@gnus.org, > emacs-devel@gnu.org > From: Dmitry Gutov > Date: Sat, 27 Feb 2021 23:44:18 +0200 > > > thread-yield runs in the context of the thread that yields. You make > > it sound like there's some entity other than the involved threads > > which runs thread-yield, but that's not what happens. > > It was also my impression that the threading facility in Emacs is > incomplete. Nothing in Emacs is ever complete. > For one thing, error handling is very low-level (saving only the last > error looks like a straight translation from C). Patches welcome. The original version didn't provide even that rudimentary error handling. > Another: there is no 'thread-resume' which some came to expect from > other languages. IMO, thread-resume makes no sense when only one thread can run at a time. We could instead add an optional argument to thread-yield, with the effect that the calling thread would yield to the thread specified by the argument. > But it seems we can substitute with condition-wait (in the worker > thread) + condition-notify (in an idle timer which it would create > before waiting). That should help suspend-resume the worker thread on a > regular basis, all the while giving the main thread the time to do its > thing. I encourage you (and everyone else) to try to come up with a real-life application that uses this paradigm, and see if it works well. The original design didn't intend for this to become the main paradigm, but that doesn't mean it cannot work well. > Either way, I don't think this can solve the original issue. Having a > link appear only some time after a Help buffer is shown is not a great > experience either: blinking elements are a visual nuisance. So if we > could pre-index the manual for symbols, that would be preferable. I tend to agree.