From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Drew Adams Newsgroups: gmane.emacs.help Subject: RE: Message queue for Emacs? Date: Sun, 23 Apr 2017 13:47:44 -0700 (PDT) Message-ID: <801751ec-b79a-4d11-90e0-b86b2dae6da0@default> References: <87vapv9fyf.fsf@jane> <87pog26gz7.fsf@ericabrahamsen.net> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Trace: blaine.gmane.org 1492980522 20195 195.159.176.226 (23 Apr 2017 20:48:42 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sun, 23 Apr 2017 20:48:42 +0000 (UTC) To: Eric Abrahamsen , help-gnu-emacs@gnu.org Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Sun Apr 23 22:48:32 2017 Return-path: Envelope-to: geh-help-gnu-emacs@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 1d2OQo-0004uI-HB for geh-help-gnu-emacs@m.gmane.org; Sun, 23 Apr 2017 22:48:30 +0200 Original-Received: from localhost ([::1]:40555 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1d2OQq-0006mF-QM for geh-help-gnu-emacs@m.gmane.org; Sun, 23 Apr 2017 16:48:32 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:38622) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1d2OQK-0006lw-NC for help-gnu-emacs@gnu.org; Sun, 23 Apr 2017 16:48:01 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1d2OQH-0005wY-Gt for help-gnu-emacs@gnu.org; Sun, 23 Apr 2017 16:48:00 -0400 Original-Received: from aserp1040.oracle.com ([141.146.126.69]:42955) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1d2OQH-0005wO-7a for help-gnu-emacs@gnu.org; Sun, 23 Apr 2017 16:47:57 -0400 Original-Received: from userv0021.oracle.com (userv0021.oracle.com [156.151.31.71]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id v3NKlkMc000865 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Sun, 23 Apr 2017 20:47:46 GMT Original-Received: from userv0122.oracle.com (userv0122.oracle.com [156.151.31.75]) by userv0021.oracle.com (8.14.4/8.14.4) with ESMTP id v3NKlkVM017651 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Sun, 23 Apr 2017 20:47:46 GMT Original-Received: from abhmp0008.oracle.com (abhmp0008.oracle.com [141.146.116.14]) by userv0122.oracle.com (8.14.4/8.14.4) with ESMTP id v3NKljC8031446; Sun, 23 Apr 2017 20:47:45 GMT In-Reply-To: <87pog26gz7.fsf@ericabrahamsen.net> X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.9.1 (1003210) [OL 12.0.6767.5000 (x86)] X-Source-IP: userv0021.oracle.com [156.151.31.71] X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.4.x-2.6.x [generic] [fuzzy] X-Received-From: 141.146.126.69 X-BeenThere: help-gnu-emacs@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Users list for the GNU Emacs text editor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Original-Sender: "help-gnu-emacs" Xref: news.gmane.org gmane.emacs.help:112866 Archived-At: > >> a lot of Emacs commands send a (message "...") for a user in the echo > >> area. Now imagine a command that sends more than of them (not unlikel= y > >> e.g. if there are a few hooks, each printing a message). Of course, > >> only the last one is then visible. Is there any way for the next > >> message to be printed with some delay, so that the previous one is > >> still visible, say, for a second or two? > >> > >> I know about C-h e (view-echo-area-messages), but this is not what I'm > >> after. > > > > See `sit-for' and `sleep-for'. >=20 > The disadvantage of that is that it would be blocking. Not `sit-for'. > It could be > interesting if Emacs just piled up messages and displayed them one per > second, without blocking whatever comes next. (message "A") (sit-for 1.0) (message "B") (sit-for 1.0) ... (message "Z") > If whatever comes next waits for user input in the minibuffer, > hitting any key would cancel/flush the rest of the queue. Again, `sit-for' does that, and regardless of whether input is to the minibuffer. Any user event cancels and flushes. > I can imagine all kinds of things going wrong, but it could be fun. It's unclear just what the OP is asking for (or why). If code issues calls to `message' in sequence, and if it wants to be sure the user sees messages other than just the last one, then a wait after each is appropriate, whether blocking or not. `sleep-for' blocks. `sit-for' does not, but it waits the allotted time if there is no user event.