From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: hw Newsgroups: gmane.emacs.devel Subject: Re: User interaction from multiple threads Date: Wed, 29 Aug 2018 22:00:52 +0200 Organization: my virtual residence Message-ID: <877ek9oscr.fsf@himinbjorg.adminart.net> References: <838t59j821.fsf@gnu.org> <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> <83mut52o8g.fsf@gnu.org> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: blaine.gmane.org 1535578873 13360 195.159.176.226 (29 Aug 2018 21:41:13 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 29 Aug 2018 21:41:13 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux) 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: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Aug 29 23:41:08 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 1fv8D5-0003Nb-Su for ged-emacs-devel@m.gmane.org; Wed, 29 Aug 2018 23:41:08 +0200 Original-Received: from localhost ([::1]:45099 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fv8FC-0005kh-B3 for ged-emacs-devel@m.gmane.org; Wed, 29 Aug 2018 17:43:18 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:43173) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fv8Cl-00038B-0r for emacs-devel@gnu.org; Wed, 29 Aug 2018 17:40:48 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1fv8Cj-00071B-Sg for emacs-devel@gnu.org; Wed, 29 Aug 2018 17:40:46 -0400 Original-Received: from mo6-p01-ob.smtp.rzone.de ([2a01:238:20a:202:5301::11]:33249) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1fv8Ce-0006lM-7G; Wed, 29 Aug 2018 17:40:40 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1535578827; s=strato-dkim-0002; d=adminart.net; h=Sender:References:Message-ID:Date:In-Reply-To:Subject:Cc:To:From: X-RZG-CLASS-ID:X-RZG-AUTH:From:Subject:Sender; bh=FKn1JZuVoNyQ5B6Zai4XW8RRRIgdePJCQRg91VyfJoE=; b=DvPpjEc6qI07zaRwNjsOg0MNwbL/AE7W0TNn7a3FCmgG2JweF6SG/g4tvCUqTeMmAf Y+/5ya7MwQ6H+xNXoGlQnupSFG1D/yFBv5M3ouzJO2W3FivRaZk2EjLrGNimHcFbN9/e fR4ANFWObREmxKyszWGSwzCU55L4BrjJ/6kCp0Cql2Ufe34AHHS4gQuQICmR4UuaUCw5 hb5CVFMcX+Igu0S9+NSSG9mLgU217uiMYDmq8x5jj3ktp4In2qpQNElXhSQ0woZIXbkz +StPENUkIHLu0luQhGXlPVx37RxX5E2zvez7okH7bW6NOlEnMq6pCm8iAfiXY4i5ucdW 66tQ== X-RZG-AUTH: ":O2kGeEG7b/pS1FS4THaxjVF9w0vVgfQ9xGcjwO5WMRo5c+h5ceMqQWZ3yrBp+AVdIIwXjneEe9k=" X-RZG-CLASS-ID: mo00 Original-Received: from himinbjorg.adminart.net by smtp.strato.de (RZmta 43.21 DYNA|AUTH) with ESMTPSA id j020b1u7TLeF6KA (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (curve secp521r1 with 521 ECDH bits, eq. 15360 bits RSA)) (Client did not present a certificate); Wed, 29 Aug 2018 23:40:15 +0200 (CEST) Original-Received: from lee by himinbjorg.adminart.net with local (Exim 4.90_1) (envelope-from ) id 1fv8CE-0001SV-Dt; Wed, 29 Aug 2018 23:40:14 +0200 In-Reply-To: <83mut52o8g.fsf@gnu.org> (Eli Zaretskii's message of "Wed, 29 Aug 2018 18:20:47 +0300") X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2a01:238:20a:202:5301::11 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:229072 Archived-At: Eli Zaretskii writes: >> 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. Maybe not all users will activate it, and I probably wouldn't activate it all the time. How to make Emacs causing disturbances from the background is a technical problem; disturbing users in what they are doing is a usability problem. If Emacs was disturbing me while I'm programming, I would have no choice but to switch to a different editor. Letting aside the loss of time and the annoyance, the rate of errors goes up tremendously when I'm being disturbed, and fixing them also costs time. It is devastating for productivity. >> 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. That already works since a long time. >> 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. That would be good. > [...] >> >> 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. That's bad. Last week I had tramp block me because it couldn't create a backup file, and it was impossible to interrupt that. >> 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. Hm. I wish the description would also say how much overhead is involved in creating a thread to give us some idea about when to start a thread and when not. Knowing only the name of a function and maybe a name for the thread is not much. What if the function calls other functions which prompt the user? Is it possible to show a backtrace so the user can get some idea about what might have caused the prompt to appear? What if the name is designed maliciously? Also, the user goes like "I want to copy files" rather than "I want to call this function". I call functions when I can't remember what keystrokes to use but have an idea of how the function may be called. How is the function called that deletes files? Does that depend on whether the files are remote or local? What do I do when I can't figure out what Emacs wants to know when it shows a prompt? >> >> 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. The strategy would have been successful when the user pressed '!' and had Emacs perform all replacements so far. It doesn't matter when she does that unless she does it when it takes longer to switch buffers than it takes to do the rest of the replacements. If Emacs learns that she usually does not press '!', it could change its strategy :) But when it can prepare stuff using another thread, what does it matter when it's wrong?