From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Lars Ingebrigtsen Newsgroups: gmane.emacs.bugs Subject: bug#51490: Show an indicator when Emacs is busy somewhere in the Emacs window Date: Wed, 21 Sep 2022 15:32:39 +0200 Message-ID: <87bkr8am4o.fsf@gnus.org> References: <83ee8a2pm7.fsf@gnu.org> <87fssq2orj.fsf@gnus.org> <87pmru18xg.fsf@gnus.org> <87lf2i18pv.fsf@gnus.org> <87h7d618j7.fsf@gnus.org> <87bl3e2m1y.fsf@gnus.org> <87pmrtz1y7.fsf@gnus.org> <83pmrt1bsa.fsf@gnu.org> <87y26hxm8a.fsf@gnus.org> <87k0hvviiu.fsf@gnus.org> <87a6iqr8il.fsf@gnus.org> <87r107nmq7.fsf@gnus.org> <83y1uewa55.fsf@gnu.org> <87fsgl7zri.fsf@gnus.org> <83illhueuo.fsf@gnu.org> <87wn9x543a.fsf@gnus.org> <83bkr8vpwy.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="24474"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux) Cc: stefan@marxist.se, 51490@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Wed Sep 21 15:34:55 2022 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from [209.51.188.17] (helo=lists.gnu.org) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1oazsN-00068I-4X for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 21 Sep 2022 15:34:55 +0200 Original-Received: from localhost ([::1]:60238 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oazsL-0001xY-MQ for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 21 Sep 2022 09:34:53 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:60160) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oazqZ-00005U-D4 for bug-gnu-emacs@gnu.org; Wed, 21 Sep 2022 09:33:03 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:33916) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1oazqZ-0006Si-5U for bug-gnu-emacs@gnu.org; Wed, 21 Sep 2022 09:33:03 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1oazqY-0007qa-Jj for bug-gnu-emacs@gnu.org; Wed, 21 Sep 2022 09:33:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Lars Ingebrigtsen Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 21 Sep 2022 13:33:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 51490 X-GNU-PR-Package: emacs Original-Received: via spool by 51490-submit@debbugs.gnu.org id=B51490.166376717230148 (code B ref 51490); Wed, 21 Sep 2022 13:33:02 +0000 Original-Received: (at 51490) by debbugs.gnu.org; 21 Sep 2022 13:32:52 +0000 Original-Received: from localhost ([127.0.0.1]:32994 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oazqO-0007qC-Ae for submit@debbugs.gnu.org; Wed, 21 Sep 2022 09:32:52 -0400 Original-Received: from quimby.gnus.org ([95.216.78.240]:39694) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oazqM-0007pz-Q0 for 51490@debbugs.gnu.org; Wed, 21 Sep 2022 09:32:51 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnus.org; s=20200322; h=Content-Type:MIME-Version:Message-ID:Date:References: In-Reply-To:Subject:Cc:To:From:Sender:Reply-To:Content-Transfer-Encoding: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=lbK+KUBVVOuoHw3kZBXQ2tOuhWIxs8n569eEBZJfCGg=; b=ci1bhaPXi2W2siNtPPxyep77BO q1N5LIaYJDWeNP17mOPZPDSI2aTuZZboJXA0YIRNfmtzUmY3sBCsDoZehOMGw/qHTKqQPE/n0Cx8x P3BgFur9fP5o9/lyRzELVOJvOmOBHkvcE0uEcekIy8MoEF4oMJVoDhMLY/ZKimI6jT44=; Original-Received: from [84.212.220.105] (helo=joga) by quimby.gnus.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1oazqD-0005oP-Ec; Wed, 21 Sep 2022 15:32:43 +0200 In-Reply-To: <83bkr8vpwy.fsf@gnu.org> (Eli Zaretskii's message of "Wed, 21 Sep 2022 16:05:17 +0300") Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwAgMAAAAqbBEUAAAABGdBTUEAALGPC/xhBQAAACBj SFJNAAB6JgAAgIQAAPoAAACA6AAAdTAAAOpgAAA6mAAAF3CculE8AAAACVBMVEU2Mjqfi3P///9G gfLxAAAAAWJLR0QCZgt8ZAAAAAd0SU1FB+YJFQ0dLk18ZWMAAAFCSURBVCjPJZJRqkQhDENbuP13 QPdT4frfC83+t/ISHzgzHG1jGsciZ+OkYZvZauzi+sU/HC7sJkRkx3kxJwGGfn7JPZUVItYeEDjg p3/9qOeFf+xnAaH5U/jwPqzrBOZH9SidIM7itxMegEXs8tds1iKi2xYBBK62kXZYcY9sJY32BRht L0dRC5/s0HNLYwuC20nI0j3BZoGm+64SUN5pcSFq3xBEGtI+M84xh8YfpUnXtYXxcASL6ZUJpVMM ZxkSeYtn0IE9pQxsro32Z1wI3lsRW8Q5CDNcTm1fm7HUtGThUEiR8jU+KCWWeSC0mSqjZ8wyd9m9 YeR9DfWtvSvSweGY7UKHSoqfj9Fa+MFryWeXTkpTykziVChUxp42o72m7uF1edp6SATptmE97fBF bEznn0PSTCcHT76SA3nfyDn+ABZobG62Q/ncAAAAJXRFWHRkYXRlOmNyZWF0ZQAyMDIyLTA5LTIx VDEzOjI5OjQ2KzAwOjAw5f0XigAAACV0RVh0ZGF0ZTptb2RpZnkAMjAyMi0wOS0yMVQxMzoyOTo0 NiswMDowMJSgrzYAAAAASUVORK5CYII= X-Now-Playing: Suicide Romeo's _Pictures_: "Suicide Romeo" X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.io gmane.emacs.bugs:243340 Archived-At: Eli Zaretskii writes: > That's true, but if Lisp cannot run, neither can redisplay. They both > access the internal Emacs state: buffers, variables, etc. Even to > replace a single glyph, you'd need to access faces, right? I'm not sure that we have to? That's why I wondered whether we could somehow get away with just altering the glyph matrix... > Also, poking a single glyph on a GUI frame is unsafe, because no one > can be sure the new glyph will have the same metrics as the old one. I was thinking way more primitive than that -- just altering the pixelish data on some level. I.e., I wouldn't want to display the characters | \ etc, but instead some pre-calculated pixel data. But like I said, I'm not sure whether even that is feasible...