GNU bug report logs - #51490
Show an indicator when Emacs is busy somewhere in the Emacs window

Previous Next

To reply to this bug, email your comments to 51490 AT debbugs.gnu.org.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Stefan Kangas <stefan <at> marxist.se>
To: bug-gnu-emacs <at> gnu.org
Subject: Show an indicator when Emacs is busy somewhere in the Emacs window
Date: Fri, 29 Oct 2021 10:59:21 -0700

Severity: wishlist

(This is a follow-up to Bug#19776.)

Lars Ingebrigtsen <larsi <at> gnus.org> writes:

> Stefan Kangas <stefan <at> marxist.se> writes:
>
>> I was talking about showing something in the actual Emacs window, not
>> just changing the mouse pointer.  The mouse pointer can change also when
>> some program has just crashed, so users won't necessarily take this as a
>> sign that "everything is okay, just give us a minute and we'll be back".
>
> And there's no hourglass pointer in terminal Emacs (which apparently is
> almost as popular as GUI Emacs for some reason), so perhaps it's worth
> having a spinning thing somewhere.  In the mode line, for instance.
>
> However, if we want that, perhaps it shouldn't be tied to
> with-delayed-message, but work exactly like the hourglass -- i.e., start
> spinning whenever Emacs is busy for a while.
>
> I'm not at all sure whether there'd be any negative repercussions to
> spinning a glyph in the mode line area (for instance -- what about if
> you're running over a slow ssh connection?), but perhaps it's worth
> exploring and see how goes?

Let's continue discussing this as a new bug.

Message #8 received at 51490 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Stefan Kangas <stefan <at> marxist.se>
Cc: 51490 <at> debbugs.gnu.org
Subject: Re: bug#51490: Show an indicator when Emacs is busy somewhere in
 the Emacs window
Date: Sat, 30 Oct 2021 14:40:02 +0200

Stefan Kangas <stefan <at> marxist.se> writes:

>> I'm not at all sure whether there'd be any negative repercussions to
>> spinning a glyph in the mode line area (for instance -- what about if
>> you're running over a slow ssh connection?), but perhaps it's worth
>> exploring and see how goes?
>
> Let's continue discussing this as a new bug.

I wonder whether this could be implemented by modifying the glyphs in
the mode line directly instead of going through the entire mode line
machinery (for efficiency).  I was thinking we'd designate (say) the
first (or last) displayed position on the mode line as "the spinner"
(and restore the previous glyph there after finishing spinning, of
course).

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Message #11 received at 51490 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Stefan Kangas <stefan <at> marxist.se>
Cc: 'Eli Zaretskii' <eliz <at> gnu.org>, 51490 <at> debbugs.gnu.org
Subject: Re: bug#51490: Show an indicator when Emacs is busy somewhere in
 the Emacs window
Date: Mon, 19 Sep 2022 22:16:48 +0200

Lars Ingebrigtsen <larsi <at> gnus.org> writes:

>>> I'm not at all sure whether there'd be any negative repercussions to
>>> spinning a glyph in the mode line area (for instance -- what about if
>>> you're running over a slow ssh connection?), but perhaps it's worth
>>> exploring and see how goes?
>>
>> Let's continue discussing this as a new bug.
>
> I wonder whether this could be implemented by modifying the glyphs in
> the mode line directly instead of going through the entire mode line
> machinery (for efficiency).  I was thinking we'd designate (say) the
> first (or last) displayed position on the mode line as "the spinner"
> (and restore the previous glyph there after finishing spinning, of
> course).

Eli, does this seem like feasible approach to you?

Message #14 received at 51490 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: stefan <at> marxist.se, 51490 <at> debbugs.gnu.org
Subject: Re: bug#51490: Show an indicator when Emacs is busy somewhere in
 the Emacs window
Date: Tue, 20 Sep 2022 14:36:06 +0300

> From: Lars Ingebrigtsen <larsi <at> gnus.org>
> Cc: 51490 <at> debbugs.gnu.org, "'Eli Zaretskii'" <eliz <at> gnu.org>
> Date: Mon, 19 Sep 2022 22:16:48 +0200
> 
> Lars Ingebrigtsen <larsi <at> gnus.org> writes:
> 
> >>> I'm not at all sure whether there'd be any negative repercussions to
> >>> spinning a glyph in the mode line area (for instance -- what about if
> >>> you're running over a slow ssh connection?), but perhaps it's worth
> >>> exploring and see how goes?
> >>
> >> Let's continue discussing this as a new bug.
> >
> > I wonder whether this could be implemented by modifying the glyphs in
> > the mode line directly instead of going through the entire mode line
> > machinery (for efficiency).  I was thinking we'd designate (say) the
> > first (or last) displayed position on the mode line as "the spinner"
> > (and restore the previous glyph there after finishing spinning, of
> > course).
> 
> Eli, does this seem like feasible approach to you?

I'm not sure I understand the problem and the proposed solution.  Are
we talking about having a spinning character, like | / - \, in the
mode lines of a window on TTY frames?  If so, what are you trying to
save by "modifying the glyphs directly", and why do you think doing so
will produce some savings, as opposed to just update the mode line
normally?

Message #17 received at 51490 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: stefan <at> marxist.se, 51490 <at> debbugs.gnu.org
Subject: Re: bug#51490: Show an indicator when Emacs is busy somewhere in
 the Emacs window
Date: Wed, 21 Sep 2022 13:06:25 +0200

Eli Zaretskii <eliz <at> gnu.org> writes:

> I'm not sure I understand the problem and the proposed solution.  Are
> we talking about having a spinning character, like | / - \, in the
> mode lines of a window on TTY frames?

Yes -- but not just on TTY frames, but on GUI frames, too (for those
that want that).

> If so, what are you trying to save by "modifying the glyphs directly",
> and why do you think doing so will produce some savings, as opposed to
> just update the mode line normally?

Because this will be happening from an alarm while Lisp code is running,
and we can't run other Lisp code while that is happening.  So we have to
modify the mode line directly from the C function called by the alarm, I
think?

Message #20 received at 51490 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: stefan <at> marxist.se, 51490 <at> debbugs.gnu.org
Subject: Re: bug#51490: Show an indicator when Emacs is busy somewhere in
 the Emacs window
Date: Wed, 21 Sep 2022 14:49:35 +0300

> From: Lars Ingebrigtsen <larsi <at> gnus.org>
> Cc: stefan <at> marxist.se,  51490 <at> debbugs.gnu.org
> Date: Wed, 21 Sep 2022 13:06:25 +0200
> 
> > If so, what are you trying to save by "modifying the glyphs directly",
> > and why do you think doing so will produce some savings, as opposed to
> > just update the mode line normally?
> 
> Because this will be happening from an alarm while Lisp code is running,
> and we can't run other Lisp code while that is happening.

Mode line is drawn in C, not in Lisp.

And if the problem is that we cannot run the display code, either,
then how would it help to poke the glyph?  It won't be shown on the
glass, because redisplay cannot run.  Right?  Or what am I missing?

Message #23 received at 51490 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: stefan <at> marxist.se, 51490 <at> debbugs.gnu.org
Subject: Re: bug#51490: Show an indicator when Emacs is busy somewhere in
 the Emacs window
Date: Wed, 21 Sep 2022 14:01:13 +0200

Eli Zaretskii <eliz <at> gnu.org> writes:

> Mode line is drawn in C, not in Lisp.
>
> And if the problem is that we cannot run the display code, either,
> then how would it help to poke the glyph?  It won't be shown on the
> glass, because redisplay cannot run.  Right?  Or what am I missing?

Redisplay can run, but we can't run any Lisp code, and the normal
formatting of a mode line does (potentially) run lots of Lisp code,
doesn't it?

Message #26 received at 51490 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Kangas <stefankangas <at> gmail.com>
To: Lars Ingebrigtsen <larsi <at> gnus.org>, Eli Zaretskii <eliz <at> gnu.org>
Cc: 51490 <at> debbugs.gnu.org
Subject: Re: bug#51490: Show an indicator when Emacs is busy somewhere in the
 Emacs window
Date: Wed, 21 Sep 2022 05:34:51 -0700

Lars Ingebrigtsen <larsi <at> gnus.org> writes:

> Eli Zaretskii <eliz <at> gnu.org> writes:
>
>> Mode line is drawn in C, not in Lisp.
>>
>> And if the problem is that we cannot run the display code, either,
>> then how would it help to poke the glyph?  It won't be shown on the
>> glass, because redisplay cannot run.  Right?  Or what am I missing?
>
> Redisplay can run, but we can't run any Lisp code, and the normal
> formatting of a mode line does (potentially) run lots of Lisp code,
> doesn't it?

BTW, I think one goal here should be to optionally replace the glyph
with a sequence of images/icons (preferably SVG files).

Message #29 received at 51490 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: stefan <at> marxist.se, 51490 <at> debbugs.gnu.org
Subject: Re: bug#51490: Show an indicator when Emacs is busy somewhere in
 the Emacs window
Date: Wed, 21 Sep 2022 16:05:17 +0300

> From: Lars Ingebrigtsen <larsi <at> gnus.org>
> Cc: stefan <at> marxist.se,  51490 <at> debbugs.gnu.org
> Date: Wed, 21 Sep 2022 14:01:13 +0200
> 
> Eli Zaretskii <eliz <at> gnu.org> writes:
> 
> > Mode line is drawn in C, not in Lisp.
> >
> > And if the problem is that we cannot run the display code, either,
> > then how would it help to poke the glyph?  It won't be shown on the
> > glass, because redisplay cannot run.  Right?  Or what am I missing?
> 
> Redisplay can run, but we can't run any Lisp code, and the normal
> formatting of a mode line does (potentially) run lots of Lisp code,
> doesn't it?

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?

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.

So I think if we want some kind of feature that displays progress
indicator while Emacs is busy, we'd need to develop it.
hourglass-cursor just raises a flag and does it only once, so it can
run from an atimer.  Anything more complex will probably need another
Lisp thread, and calls to synchronization functions (sit-for,
thread-yield, etc.) from the main thread.  Or something.

Or maybe we can run some async subprocess which will display some
animation?

Message #32 received at 51490 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Stefan Kangas <stefankangas <at> gmail.com>
Cc: larsi <at> gnus.org, 51490 <at> debbugs.gnu.org
Subject: Re: bug#51490: Show an indicator when Emacs is busy somewhere in the
 Emacs window
Date: Wed, 21 Sep 2022 16:08:34 +0300

> From: Stefan Kangas <stefankangas <at> gmail.com>
> Date: Wed, 21 Sep 2022 05:34:51 -0700
> Cc: 51490 <at> debbugs.gnu.org
> 
> Lars Ingebrigtsen <larsi <at> gnus.org> writes:
> 
> > Eli Zaretskii <eliz <at> gnu.org> writes:
> >
> >> Mode line is drawn in C, not in Lisp.
> >>
> >> And if the problem is that we cannot run the display code, either,
> >> then how would it help to poke the glyph?  It won't be shown on the
> >> glass, because redisplay cannot run.  Right?  Or what am I missing?
> >
> > Redisplay can run, but we can't run any Lisp code, and the normal
> > formatting of a mode line does (potentially) run lots of Lisp code,
> > doesn't it?
> 
> BTW, I think one goal here should be to optionally replace the glyph
> with a sequence of images/icons (preferably SVG files).

These are also (special kinds of) glyphs.

Message #35 received at 51490 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: stefan <at> marxist.se, 51490 <at> debbugs.gnu.org
Subject: Re: bug#51490: Show an indicator when Emacs is busy somewhere in
 the Emacs window
Date: Wed, 21 Sep 2022 15:32:39 +0200

Eli Zaretskii <eliz <at> gnu.org> 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...

Message #38 received at 51490 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: stefan <at> marxist.se, 51490 <at> debbugs.gnu.org
Subject: Re: bug#51490: Show an indicator when Emacs is busy somewhere in
 the Emacs window
Date: Wed, 21 Sep 2022 17:01:53 +0300

> From: Lars Ingebrigtsen <larsi <at> gnus.org>
> Cc: stefan <at> marxist.se,  51490 <at> debbugs.gnu.org
> Date: Wed, 21 Sep 2022 15:32:39 +0200
> 
> Eli Zaretskii <eliz <at> gnu.org> 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...

We barely get away with that on TTY frames (that's how TTY menus are
implemented).  On GUI frames, I don't think it's feasible, not with
the code we have now.

As for not accessing any Lisp data: do you really believe our users
will let us deprive them of even the minimal customization
capabilities, like determining the face of this indicator and how it
generally looks?  I sincerely doubt that.

> > 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.

We don't write pixels to the glass, we call GUI APIs to do that.

Message #41 received at 51490 <at> debbugs.gnu.org (full text, mbox):

From: Gregory Heytings <gregory <at> heytings.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: Lars Ingebrigtsen <larsi <at> gnus.org>, stefan <at> marxist.se,
 51490 <at> debbugs.gnu.org
Subject: Re: bug#51490: Show an indicator when Emacs is busy somewhere in
 the Emacs window
Date: Wed, 21 Sep 2022 16:02:12 +0000

>
> We barely get away with that on TTY frames (that's how TTY menus are 
> implemented).  On GUI frames, I don't think it's feasible, not with the 
> code we have now.
>

On GUI frames, can't we do something similar to what we do for fringe 
bitmaps?

Message #44 received at 51490 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Gregory Heytings <gregory <at> heytings.org>
Cc: larsi <at> gnus.org, stefan <at> marxist.se, 51490 <at> debbugs.gnu.org
Subject: Re: bug#51490: Show an indicator when Emacs is busy somewhere in
 the Emacs window
Date: Wed, 21 Sep 2022 19:21:18 +0300

> Date: Wed, 21 Sep 2022 16:02:12 +0000
> From: Gregory Heytings <gregory <at> heytings.org>
> cc: Lars Ingebrigtsen <larsi <at> gnus.org>, stefan <at> marxist.se, 
>     51490 <at> debbugs.gnu.org
> 
> On GUI frames, can't we do something similar to what we do for fringe 
> bitmaps?

I'm not sure I follow.  Fringe bitmaps are drawn by redisplay, and
they do access faces, text properties, overlays,...  So how would this
solve the problem?

Message #47 received at 51490 <at> debbugs.gnu.org (full text, mbox):

From: Gregory Heytings <gregory <at> heytings.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: larsi <at> gnus.org, stefan <at> marxist.se, 51490 <at> debbugs.gnu.org
Subject: Re: bug#51490: Show an indicator when Emacs is busy somewhere in
 the Emacs window
Date: Wed, 21 Sep 2022 17:11:17 +0000

>> On GUI frames, can't we do something similar to what we do for fringe 
>> bitmaps?
>
> I'm not sure I follow.  Fringe bitmaps are drawn by redisplay, and they 
> do access faces, text properties, overlays,...  So how would this solve 
> the problem?
>

Aren't they the simplest graphical element drawn by Emacs, a simple 
black-and-white bitmap?  I don't think a "busy" indicator would have to 
access faces, text properties and overlays, it could be a simple (list of) 
black-and-white bitmaps drawn at a fixed position, e.g. on the left of the 
mode line.  The interaction with Lisp would be minimal.

Message #50 received at 51490 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Gregory Heytings <gregory <at> heytings.org>
Cc: larsi <at> gnus.org, stefan <at> marxist.se, 51490 <at> debbugs.gnu.org
Subject: Re: bug#51490: Show an indicator when Emacs is busy somewhere in
 the Emacs window
Date: Thu, 22 Sep 2022 09:28:22 +0300

> Date: Wed, 21 Sep 2022 17:11:17 +0000
> From: Gregory Heytings <gregory <at> heytings.org>
> cc: larsi <at> gnus.org, stefan <at> marxist.se, 51490 <at> debbugs.gnu.org
> 
> >> On GUI frames, can't we do something similar to what we do for fringe 
> >> bitmaps?
> >
> > I'm not sure I follow.  Fringe bitmaps are drawn by redisplay, and they 
> > do access faces, text properties, overlays,...  So how would this solve 
> > the problem?
> 
> Aren't they the simplest graphical element drawn by Emacs, a simple 
> black-and-white bitmap?

No, they aren't.  They are certainly not black-and-white: they use
faces.

> I don't think a "busy" indicator would have to access faces, text
> properties and overlays, it could be a simple (list of)
> black-and-white bitmaps drawn at a fixed position, e.g. on the left
> of the mode line.

Drawn how?  Bitmaps are images, and drawing images in the text area
means we need to invoke all the machinery of redrawing a certain
screen line, be it on the mode line or elsewhere.  That's how Emacs
draws stuff; we don't have any way of directly poking the glass with
an arbitrary bunch of pixels, at least not one that I know of.

Message #53 received at 51490 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: Gregory Heytings <gregory <at> heytings.org>, stefan <at> marxist.se,
 51490 <at> debbugs.gnu.org
Subject: Re: bug#51490: Show an indicator when Emacs is busy somewhere in
 the Emacs window
Date: Thu, 22 Sep 2022 12:54:41 +0200

Eli Zaretskii <eliz <at> gnu.org> writes:

>> Aren't they the simplest graphical element drawn by Emacs, a simple 
>> black-and-white bitmap?
>
> No, they aren't.  They are certainly not black-and-white: they use
> faces.

They use faces to get at the colours, but nothing beyond that, I think?

Message #56 received at 51490 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: gregory <at> heytings.org, stefan <at> marxist.se, 51490 <at> debbugs.gnu.org
Subject: Re: bug#51490: Show an indicator when Emacs is busy somewhere in
 the Emacs window
Date: Thu, 22 Sep 2022 15:33:42 +0300

> From: Lars Ingebrigtsen <larsi <at> gnus.org>
> Cc: Gregory Heytings <gregory <at> heytings.org>,  stefan <at> marxist.se,
>   51490 <at> debbugs.gnu.org
> Date: Thu, 22 Sep 2022 12:54:41 +0200
> 
> Eli Zaretskii <eliz <at> gnu.org> writes:
> 
> >> Aren't they the simplest graphical element drawn by Emacs, a simple 
> >> black-and-white bitmap?
> >
> > No, they aren't.  They are certainly not black-and-white: they use
> > faces.
> 
> They use faces to get at the colours, but nothing beyond that, I think?

Yes, only the colors.  But accessing the faces means you cannot do
that while the Lisp machine is doing something.

Message #59 received at 51490 <at> debbugs.gnu.org (full text, mbox):

From: Gregory Heytings <gregory <at> heytings.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: larsi <at> gnus.org, stefan <at> marxist.se, 51490 <at> debbugs.gnu.org
Subject: Re: bug#51490: Show an indicator when Emacs is busy somewhere in
 the Emacs window
Date: Thu, 22 Sep 2022 13:02:53 +0000

>> Aren't they the simplest graphical element drawn by Emacs, a simple 
>> black-and-white bitmap?
>
> No, they aren't.  They are certainly not black-and-white: they use 
> faces.
>

Sorry, I wrote a bit too fast (as usual), I did not mean literally "black" 
and "white", I meant "two colors", represented by a two-value pixel 
bitmap.

>
> Drawn how?  Bitmaps are images, and drawing images in the text area 
> means we need to invoke all the machinery of redrawing a certain screen 
> line, be it on the mode line or elsewhere.  That's how Emacs draws 
> stuff; we don't have any way of directly poking the glass with an 
> arbitrary bunch of pixels, at least not one that I know of.
>

I'm thinking aloud here, sorry if it isn't useful.  But I think we have at 
least one similar occurrence: XTflash.

Message #62 received at 51490 <at> debbugs.gnu.org (full text, mbox):

From: Gregory Heytings <gregory <at> heytings.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: Lars Ingebrigtsen <larsi <at> gnus.org>, stefan <at> marxist.se,
 51490 <at> debbugs.gnu.org
Subject: Re: bug#51490: Show an indicator when Emacs is busy somewhere in
 the Emacs window
Date: Thu, 22 Sep 2022 13:08:25 +0000

>>>> Aren't they the simplest graphical element drawn by Emacs, a simple 
>>>> black-and-white bitmap?
>>>
>>> No, they aren't.  They are certainly not black-and-white: they use 
>>> faces.
>>
>> They use faces to get at the colours, but nothing beyond that, I think?
>
> Yes, only the colors.  But accessing the faces means you cannot do that 
> while the Lisp machine is doing something.
>

But would it be really necessary to access these faces each time the 
indicator would be drawn?  We could for example cache the values of these 
two colors somewhere, or decide to do something different and use a 
specific function to set these two colors without going through the whole 
face machinery, something like (set-busy-indicator-colors FOREGROUND 
BACKGROUND).

Message #65 received at 51490 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Gregory Heytings <gregory <at> heytings.org>
Cc: larsi <at> gnus.org, stefan <at> marxist.se, 51490 <at> debbugs.gnu.org
Subject: Re: bug#51490: Show an indicator when Emacs is busy somewhere in
 the Emacs window
Date: Thu, 22 Sep 2022 16:59:48 +0300

> Date: Thu, 22 Sep 2022 13:02:53 +0000
> From: Gregory Heytings <gregory <at> heytings.org>
> cc: larsi <at> gnus.org, stefan <at> marxist.se, 51490 <at> debbugs.gnu.org
> 
> > Drawn how?  Bitmaps are images, and drawing images in the text area 
> > means we need to invoke all the machinery of redrawing a certain screen 
> > line, be it on the mode line or elsewhere.  That's how Emacs draws 
> > stuff; we don't have any way of directly poking the glass with an 
> > arbitrary bunch of pixels, at least not one that I know of.
> 
> I'm thinking aloud here, sorry if it isn't useful.  But I think we have at 
> least one similar occurrence: XTflash.

Which part of it seemed similar to what is being discussed here?

Message #68 received at 51490 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Gregory Heytings <gregory <at> heytings.org>
Cc: larsi <at> gnus.org, stefan <at> marxist.se, 51490 <at> debbugs.gnu.org
Subject: Re: bug#51490: Show an indicator when Emacs is busy somewhere in
 the Emacs window
Date: Thu, 22 Sep 2022 17:03:41 +0300

> Date: Thu, 22 Sep 2022 13:08:25 +0000
> From: Gregory Heytings <gregory <at> heytings.org>
> cc: Lars Ingebrigtsen <larsi <at> gnus.org>, stefan <at> marxist.se, 
>     51490 <at> debbugs.gnu.org
> 
> >> They use faces to get at the colours, but nothing beyond that, I think?
> >
> > Yes, only the colors.  But accessing the faces means you cannot do that 
> > while the Lisp machine is doing something.
> 
> But would it be really necessary to access these faces each time the 
> indicator would be drawn?  We could for example cache the values of these 
> two colors somewhere

Faces are already cached.  But for each cache there comes a time when
it must be flushed and/or refreshed, and during those times you cannot
safely use the cache.

> or decide to do something different and use a 
> specific function to set these two colors without going through the whole 
> face machinery, something like (set-busy-indicator-colors FOREGROUND 
> BACKGROUND).

As soon as we allow set-busy-indicator-colors or somesuch, we have a
problem with Lisp programs doing that exactly when there's time to
redraw the indicator.

Message #71 received at 51490 <at> debbugs.gnu.org (full text, mbox):

From: Gregory Heytings <gregory <at> heytings.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: larsi <at> gnus.org, stefan <at> marxist.se, 51490 <at> debbugs.gnu.org
Subject: Re: bug#51490: Show an indicator when Emacs is busy somewhere in
 the Emacs window
Date: Thu, 22 Sep 2022 15:57:04 +0000

>> I'm thinking aloud here, sorry if it isn't useful.  But I think we have 
>> at least one similar occurrence: XTflash.
>
> Which part of it seemed similar to what is being discussed here?
>

The fact that a portion of the frame is modified without a complete 
redisplay of the frame, through primitive drawing functions?  Am I missing 
something?  Would it not be possible to draw a busy indicator at a fixed 
position of the frame with XDrawRectangle for the background, followed by 
XDrawPoints for the foreground?

>> But would it be really necessary to access these faces each time the 
>> indicator would be drawn?  We could for example cache the values of 
>> these two colors somewhere
>
> Faces are already cached.  But for each cache there comes a time when it 
> must be flushed and/or refreshed, and during those times you cannot 
> safely use the cache.
>

What I had in mind is a more primitive cache mechanism: two C variables.

>> or decide to do something different and use a specific function to set 
>> these two colors without going through the whole face machinery, 
>> something like (set-busy-indicator-colors FOREGROUND BACKGROUND).
>
> As soon as we allow set-busy-indicator-colors or somesuch, we have a 
> problem with Lisp programs doing that exactly when there's time to 
> redraw the indicator.
>

We could specify that set-busy-indicator-colors is only meant to be used 
in init files, for example.

Message #74 received at 51490 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Gregory Heytings <gregory <at> heytings.org>
Cc: larsi <at> gnus.org, stefan <at> marxist.se, 51490 <at> debbugs.gnu.org
Subject: Re: bug#51490: Show an indicator when Emacs is busy somewhere in
 the Emacs window
Date: Thu, 22 Sep 2022 19:21:10 +0300

> Date: Thu, 22 Sep 2022 15:57:04 +0000
> From: Gregory Heytings <gregory <at> heytings.org>
> cc: larsi <at> gnus.org, stefan <at> marxist.se, 51490 <at> debbugs.gnu.org
> 
> >> I'm thinking aloud here, sorry if it isn't useful.  But I think we have 
> >> at least one similar occurrence: XTflash.
> >
> > Which part of it seemed similar to what is being discussed here?
> 
> The fact that a portion of the frame is modified without a complete 
> redisplay of the frame, through primitive drawing functions?  Am I missing 
> something?  Would it not be possible to draw a busy indicator at a fixed 
> position of the frame with XDrawRectangle for the background, followed by 
> XDrawPoints for the foreground?

It should be possible, yes.  I just said that we don't have such an
infrastructure yet, it needs to be written first.  When someone does
write it, they will have to deal with the issue of what kind of
drawing do we allow there; for example, a 1-pixel line is easy, but is
unlikely to be visually appealing.

And the main problem this will have to solve is this: whatever you
draw behind the back of the display engine will run the risk of being
wiped out when the next redisplay cycle kicks in.  XTflash doesn't
have that problem because it is invoked from Lisp, not from an async
signal handler.

> >> or decide to do something different and use a specific function to set 
> >> these two colors without going through the whole face machinery, 
> >> something like (set-busy-indicator-colors FOREGROUND BACKGROUND).
> >
> > As soon as we allow set-busy-indicator-colors or somesuch, we have a 
> > problem with Lisp programs doing that exactly when there's time to 
> > redraw the indicator.
> 
> We could specify that set-busy-indicator-colors is only meant to be used 
> in init files, for example.

Good luck with getting that past our users!

Message #77 received at 51490 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: Gregory Heytings <gregory <at> heytings.org>, stefan <at> marxist.se,
 51490 <at> debbugs.gnu.org
Subject: Re: bug#51490: Show an indicator when Emacs is busy somewhere in
 the Emacs window
Date: Fri, 23 Sep 2022 17:06:05 +0200

Eli Zaretskii <eliz <at> gnu.org> writes:

> It should be possible, yes.  I just said that we don't have such an
> infrastructure yet, it needs to be written first.  When someone does
> write it, they will have to deal with the issue of what kind of
> drawing do we allow there; for example, a 1-pixel line is easy, but is
> unlikely to be visually appealing.

The spinner will presumably not be done with line drawing, but consist
of a set of 8 glyphs that are defined along the lines of fringe markers.

> And the main problem this will have to solve is this: whatever you
> draw behind the back of the display engine will run the risk of being
> wiped out when the next redisplay cycle kicks in.

Yes, we'd have to have a way to tell the redisplay to lay off redrawing
in that rectangle, probably.

Message #80 received at 51490 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: gregory <at> heytings.org, stefan <at> marxist.se, 51490 <at> debbugs.gnu.org
Subject: Re: bug#51490: Show an indicator when Emacs is busy somewhere in
 the Emacs window
Date: Fri, 23 Sep 2022 18:45:12 +0300

> From: Lars Ingebrigtsen <larsi <at> gnus.org>
> Cc: Gregory Heytings <gregory <at> heytings.org>,  stefan <at> marxist.se,
>   51490 <at> debbugs.gnu.org
> Date: Fri, 23 Sep 2022 17:06:05 +0200
> 
> Eli Zaretskii <eliz <at> gnu.org> writes:
> 
> > It should be possible, yes.  I just said that we don't have such an
> > infrastructure yet, it needs to be written first.  When someone does
> > write it, they will have to deal with the issue of what kind of
> > drawing do we allow there; for example, a 1-pixel line is easy, but is
> > unlikely to be visually appealing.
> 
> The spinner will presumably not be done with line drawing, but consist
> of a set of 8 glyphs that are defined along the lines of fringe markers.

Then this gets back to how to do that behind the back of the display
code.  We'd need to invent new machinery for that.

> > And the main problem this will have to solve is this: whatever you
> > draw behind the back of the display engine will run the risk of being
> > wiped out when the next redisplay cycle kicks in.
> 
> Yes, we'd have to have a way to tell the redisplay to lay off redrawing
> in that rectangle, probably.

That's also something that doesn't exist, and will have to be added
somehow.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.