From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Marcin Borkowski Newsgroups: gmane.emacs.devel Subject: Re: How about making `sleep-for' interactive? Date: Thu, 27 Jun 2019 09:55:06 +0200 Message-ID: <87k1d7wjhh.fsf@mbork.pl> References: <87v9wrwsde.fsf@mbork.pl> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="269181"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: mu4e 1.1.0; emacs 27.0.50 Cc: Emacs developers To: =?utf-8?Q?S=C3=B8ren_Pilg=C3=A5rd?= Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Jun 27 09:57:54 2019 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([209.51.188.17]) by blaine.gmane.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1hgPHz-0017oh-Da for ged-emacs-devel@m.gmane.org; Thu, 27 Jun 2019 09:57:51 +0200 Original-Received: from localhost ([::1]:47442 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1hgPHy-0004Fd-GE for ged-emacs-devel@m.gmane.org; Thu, 27 Jun 2019 03:57:50 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:38552) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1hgPHk-00042C-T0 for emacs-devel@gnu.org; Thu, 27 Jun 2019 03:57:38 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hgPHi-0003mA-Ss for emacs-devel@gnu.org; Thu, 27 Jun 2019 03:57:36 -0400 Original-Received: from mail.mojserwer.eu ([195.110.48.8]:50458) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hgPHg-0003dP-TK for emacs-devel@gnu.org; Thu, 27 Jun 2019 03:57:34 -0400 Original-Received: from localhost (localhost [127.0.0.1]) by mail.mojserwer.eu (Postfix) with ESMTP id C0807E6734; Thu, 27 Jun 2019 09:57:24 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at mail.mojserwer.eu Original-Received: from mail.mojserwer.eu ([127.0.0.1]) by localhost (mail.mojserwer.eu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HL1wRS5Te8s9; Thu, 27 Jun 2019 09:57:16 +0200 (CEST) Original-Received: from localhost (188.147.99.36.nat.umts.dynamic.t-mobile.pl [188.147.99.36]) by mail.mojserwer.eu (Postfix) with ESMTPSA id B3014E64F4; Thu, 27 Jun 2019 09:57:15 +0200 (CEST) In-reply-to: X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 195.110.48.8 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.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:238186 Archived-At: On 2019-06-27, at 09:46, S=C3=B8ren Pilg=C3=A5rd wro= te: > On Thu, Jun 27, 2019 at 6:47 AM Marcin Borkowski wrote: >> >> Hi all, >> >> I noticed today that `sleep-for' is not an (interactive) command. IMHO >> it should be - at least I can see a need for it. Here is my use case. >> I recorded a keyboard macro which edits the text in some way. The macro >> begins with isearching for something (which may be outside the part of >> the buffer currently seen) and then changing. Having e.g. a 1-second >> delay between moving to that part and actually changing it would help >> spot mistakes. >> >> Since `sleep-for' is a builtin, I can't prepare a patch (I don't speak >> C very well), but if I get a hint I can try (just to learn something >> new). >> >> WDYT? >> > > I can't really see the use. > You could always just do ```M-: (sleep-foor xxx)``` in the macro. > Being time sensitive and waiting for abortion is a bit too dangerous > in my taste, either I am sure and do it everywhere or I want to accept > / decline in cases like that. > > What I usually do in cases like that is to make a macro that moves to > the next occurrence, then does the changes and then moves to just the > beginning of the next occurrence again. > That way I can just call the macro repeatedly and it will move forward > to the next place where a change will happen each time. > If I decide not to apply the macro I will skip forward, either > searching manually for the next occurrence or sometimes just moving > the point forward so the macro will edit the next occurrence instead. Good points. In addition to that, I discovered that screen is not updated during macro execution, so my solution would have to involve updating the display. Let's forget about this idea. Thanks, --=20 Marcin Borkowski http://mbork.pl