From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: User interaction from multiple threads Date: Wed, 29 Aug 2018 18:20:47 +0300 Message-ID: <83mut52o8g.fsf@gnu.org> References: <838t59j821.fsf@gnu.org> <83a7phdl7r.fsf@gnu.org> <61492e7f622303d02405bedbe65fabae@webmail.orcon.net.nz> <83pnybdaer.fsf@gnu.org> <837ekicw7i.fsf@gnu.org> <877ekiierh.fsf@himinbjorg.adminart.net> <834lflb2fj.fsf@gnu.org> <83h8jk9l41.fsf@gnu.org> <8336v2994c.fsf@gnu.org> <83bm9q6x7v.fsf@gnu.org> <874lfi863s.fsf@himinbjorg.adminart.net> <83va7x5guc.fsf@gnu.org> <871sakl97g.fsf@himinbjorg.adminart.net> <8336uz6e8e.fsf@gnu.org> <877ekbego9.fsf@himinbjorg.adminart.net> <83mut73vau.fsf@gnu.org> <87lg8qqh9n.fsf@himinbjorg.adminart.net> NNTP-Posting-Host: blaine.gmane.org X-Trace: blaine.gmane.org 1535555946 11789 195.159.176.226 (29 Aug 2018 15:19:06 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 29 Aug 2018 15:19:06 +0000 (UTC) Cc: psainty@orcon.net.nz, gazally@runbox.com, rms@gnu.org, emacs-devel-bounces+psainty=orcon.net.nz@gnu.org, emacs-devel@gnu.org To: hw Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Aug 29 17:19:01 2018 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1fv2FJ-0002wH-Nl for ged-emacs-devel@m.gmane.org; Wed, 29 Aug 2018 17:19:01 +0200 Original-Received: from localhost ([::1]:43553 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fv2HQ-0004vJ-2d for ged-emacs-devel@m.gmane.org; Wed, 29 Aug 2018 11:21:12 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:54383) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fv2HI-0004uG-Nc for emacs-devel@gnu.org; Wed, 29 Aug 2018 11:21:05 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1fv2HE-00011f-NY for emacs-devel@gnu.org; Wed, 29 Aug 2018 11:21:04 -0400 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:49623) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fv2HE-00011b-JT; Wed, 29 Aug 2018 11:21:00 -0400 Original-Received: from [176.228.60.248] (port=2337 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1fv2H6-0007Ag-Dk; Wed, 29 Aug 2018 11:20:52 -0400 In-reply-to: <87lg8qqh9n.fsf@himinbjorg.adminart.net> (message from hw on Wed, 29 Aug 2018 00:05:08 +0200) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 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.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:229054 Archived-At: > From: hw > Cc: psainty@orcon.net.nz, gazally@runbox.com, rms@gnu.org, emacs-devel-bounces+psainty=orcon.net.nz@gnu.org, emacs-devel@gnu.org > Date: Wed, 29 Aug 2018 00:05:08 +0200 > > Imagine serializing requests and presenting them to users with the right > amount of sequentiality and historical context was already solved. What > is Emacs supposed to do with requests after I start using it for > programming and tell it that I am in do-not-disturb-mode? > > That mode means that I do not want to be disturbed by any prompt which > is not directly related to what I'm currently doing, i. e. it's ok for > Emacs to ask me for a file name right away when I press C-x C-f. It is > definitely not ok to prompt me "FOO (y or n)" because Emacs is still > copying or deleting files and wants to know something. I'd look into > the progress of that some time later, or the next day maybe. Such a mode could be a useful feature, but we cannot assume all the users will want to activate it. We are looking for a way to allow them to "be disturbed" by the background threads, but in a way that will still allow to do something useful in the foreground. > It is also not ok for gnus to change the size of the mini-buffer or to > ask me for a password when it automatically checks for new mail every > now and then. Letting Gnus running in the background ask me for a password is actually something we'd like to support. > Since there is no such thing as "a foreground", Emacs has no idea what > I'm doing and no way to decide which requests it may allow to reach me > and which ones not. The Lisp program with which you are interacting could help Emacs have some idea about these things. > While the user is not in do-not-disturb-mode, it doesn't matter which > prompt is forwarded first. I don't think the order matters. I think the fundamental problems are when it is okay to prompt the user, and how to indicate to threads it's okay. > >> Aren't the threads already managed in some way? > > > > No, not really. There's a single global lock and a race to grab it > > when it becomes released by whatever thread was holding it. > > How is being decided for how long the most a thread can stall the > others? It can stall them indefinitely. As long as the thread runs some Lisp and doesn't call any of the "yielding" APIs, no other thread can run. > What information is available when a thread is created? See 'make-thread' for the gory details, but in a nutshell, just the function which the thread will run and the optional name. > >> Emacs could even assume the possible answers to a prompt and perform the > >> actions resulting from the answers in some cases so that when the user > >> makes a decision, the result is already available and the one not needed > >> can be discarded :) > > > > I don't think this is possible in practice. We usually ask the user > > questions for which only the user knows the answers. > > While (query-replace) is waiting for the user to answer its prompt, > Emacs could anticipate the possibility that the user is going to perform > all the possible replacements (after verifying only a few) and create a > version of the buffer in which all replacements have been performed. Now > when the user actually does what Emacs anticipated, it switches the > buffers so the user doesn't need to wait for the replacements to be > performed (assuming that would be faster than doing the replacements, > for the sake of this example). I think this strategy will fail most of the time: if the user wants to confirm all the replacements, she will press '!' early on. If they keep pressing 'y' or SPC, my guess is that they want to skip some of the matches.