From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Debouncing slow mode line constructs (was: Emacs design and architecture. How about copy-on-write?) Date: Fri, 22 Sep 2023 16:04:02 +0300 Message-ID: <831qeq741p.fsf@gnu.org> References: <837comcam8.fsf@gnu.org> <6946e6f0-c6ef-186c-35d4-c09935c05a07@gutov.dev> <83y1h1axtq.fsf@gnu.org> <87sf79rq5o.fsf@yahoo.com> <83fs38c2yv.fsf@gnu.org> <83o7hw9ee1.fsf@gnu.org> <87il84q845.fsf@yahoo.com> <83il849bx6.fsf@gnu.org> <87a5tfri8c.fsf@yahoo.com> <878r8z27cs.fsf@localhost> <44e98df7-f683-ac07-e644-40757f1d26f9@gutov.dev> <87msxfzts6.fsf@localhost> <7b0c07f5-88c8-4f2c-6ac6-a6112c884f32@gutov.dev> <87il83zsg1.fsf@localhost> <87fs37zrjx.fsf@localhost> <400f8781-6bd9-53a0-0ace-26c327890fd9@gutov.dev> <87msxey105.fsf@localhost> <83lecy777w.fsf@gnu.org> <87ttrmwetx.fsf@localhost> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="32561"; mail-complaints-to="usenet@ciao.gmane.io" Cc: dmitry@gutov.dev, luangruo@yahoo.com, acm@muc.de, incal@dataswamp.org, emacs-devel@gnu.org To: Ihor Radchenko Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Fri Sep 22 15:05:02 2023 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1qjfqA-0008Ej-5k for ged-emacs-devel@m.gmane-mx.org; Fri, 22 Sep 2023 15:05:02 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qjfpI-0007Ay-3c; Fri, 22 Sep 2023 09:04:09 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qjfpF-00077R-9m for emacs-devel@gnu.org; Fri, 22 Sep 2023 09:04:05 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qjfpC-0001gC-AR; Fri, 22 Sep 2023 09:04:03 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=4kgnXmMU7lfbi2QofehKyvaM7lqrDwNWWkw5D7/RtbA=; b=Os2CuVwayskk wELNxcZwUMcQKk08f7sWDmEp0eFdM5zs2Xg7AruD6+cPR2QcsWiWl/cugKvC7CiptOfUk0BHjHBXh Kx9zjb6Sm7Juy2Z30xsjPi0iG1lTG6tpJZpR042SxOFi9zxIKl5Sxyb8CwDLNs8jKHnVZSL7NbZDv 2+MQJ1FIku+EIHinE7zdM8Fay2fKhnxUWSLwhNBvXEn6T3gDG8QQcd3KQJhAJkwZIlTO7oTtjDjIL sikpRVC5Dk18TANKCw8eB0b0+X07AK5Vtm1XMd7rkw66C2IGNUo4ZO77/4aRpZWm7F6EKoKa8aGci jFD4205usc83pQu6ooyWPQ==; In-Reply-To: <87ttrmwetx.fsf@localhost> (message from Ihor Radchenko on Fri, 22 Sep 2023 12:50:39 +0000) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 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-mx.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.devel:310961 Archived-At: > From: Ihor Radchenko > Cc: dmitry@gutov.dev, luangruo@yahoo.com, acm@muc.de, incal@dataswamp.org, > emacs-devel@gnu.org > Date: Fri, 22 Sep 2023 12:50:39 +0000 > > Eli Zaretskii writes: > > >> > Though if we just do this silently, it can hide performance problems, > >> > both discouraging the mode-line authors from fixing them, and creating > >> > odd behaviors (from the user's POV) when something which should change, > >> > doesn't. > >> > >> A warning may be displayed when this "debouncing" is activated. > > > > You cannot easily display any warnings from redisplay. > > Can't the code inside :eval display warnings? No, because displaying a warning requires redisplay, and we don't support recursive redisplays. > In any case, it is not a big problem to arrange the warning to be > displayed after redisplay finishes. I don't see a reason to do that with this particular kind of problems. We currently don't display anything by default even if Lisp called by redisplay signals an error, we just log that in *Messages*. Why should these :eval problems we treated differently?