From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Alan Mackenzie Newsgroups: gmane.emacs.devel Subject: Re: Strange use of (run-with-timer 0 nil #'foo args) in do-after-load-evaluation Date: Sat, 26 Oct 2019 14:18:19 +0000 Message-ID: <20191026141819.GD17424@ACM> References: <20191026101407.GA17424@ACM> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="238945"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: Mutt/1.10.1 (2018-07-13) Cc: emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Oct 26 16:18:35 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 1iOMtm-00100q-Tz for ged-emacs-devel@m.gmane.org; Sat, 26 Oct 2019 16:18:35 +0200 Original-Received: from localhost ([::1]:40286 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iOMtl-0004EY-AJ for ged-emacs-devel@m.gmane.org; Sat, 26 Oct 2019 10:18:33 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:47817) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iOMtd-0004Dt-Eu for emacs-devel@gnu.org; Sat, 26 Oct 2019 10:18:26 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1iOMtc-0001ZI-Bj for emacs-devel@gnu.org; Sat, 26 Oct 2019 10:18:25 -0400 Original-Received: from colin.muc.de ([193.149.48.1]:18772 helo=mail.muc.de) by eggs.gnu.org with smtp (Exim 4.71) (envelope-from ) id 1iOMtb-0001YC-DI for emacs-devel@gnu.org; Sat, 26 Oct 2019 10:18:24 -0400 Original-Received: (qmail 12241 invoked by uid 3782); 26 Oct 2019 14:18:21 -0000 Original-Received: from acm.muc.de (p2E5D5144.dip0.t-ipconnect.de [46.93.81.68]) by colin.muc.de (tmda-ofmipd) with ESMTP; Sat, 26 Oct 2019 16:18:19 +0200 Original-Received: (qmail 21200 invoked by uid 1000); 26 Oct 2019 14:18:19 -0000 Content-Disposition: inline In-Reply-To: X-Delivery-Agent: TMDA/1.1.12 (Macallan) X-Primary-Address: acm@muc.de X-detected-operating-system: by eggs.gnu.org: FreeBSD 9.x [fuzzy] X-Received-From: 193.149.48.1 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:241461 Archived-At: Hello, Stefan. On Sat, Oct 26, 2019 at 08:41:27 -0400, Stefan Monnier wrote: > > (run-with-timer 0 nil > > (lambda (msg) > > (message "%s" msg)) > > msg) > > run-with-timer is being used to run message once, immediately. > > Why not just call message? > Good question. It's been that way since > commit 5766c380eec20a19844253cbb511922b6c70fc0b > Author: Stefan Monnier > Date: Sat Sep 12 03:35:40 2009 +0000 > * lread.c (Fload): Don't output a message after loading an obsolete > package any more (done in Lisp now). > * subr.el (do-after-load-evaluation): Warn the user after loading an > obsolete package. > but I can't see any trace of an explanation nor can I find it in my memory. > > What is going on, here? Is the run-with-timer mechanism being used > > deliberately to make the "deprecated" message prevail over other > > messages? > That's my best guess, yes. I think I can see what's happening, now. The (run-with-timer 0 nil ...) mechanism doesn't trigger its function until Emacs is waiting for input. This will be in the minibuffer routines, just after the y-or-n-p has displayed its prompt string and tries to read a character. So the (run-with-timer ...) message will overwrite any prompt string. I have counted 11 occurrences of run-with-timer or run-at-time with a zero delay in them. So, the (run-with-timer ...) seems indeed to be being used to raise the "priority" of its message. Maybe a simple message call should be used here instead. > > The current situation seems unsatisfactory; the prompt from > > hack-local-variables is more important than the deprecation message, > > and shouldn't be obscured by it. > It's a kind of general problem with messages, indeed. Yes. > Stefan -- Alan Mackenzie (Nuremberg, Germany).