"Loading"

"Loading"

[Lars Magne Ingebrigtsen]

shr downloads images asynchronously, but there isn't anything to say
"we're still downloading".  I think there should be.

shr just inserts a "*" character as a placeholder now.  Perhaps it would
make sense to insert an animated image instead displaying a "loading"
symbol?  Or we could go old style with a spinning - \ | / - thing.

This is obviously not for Emacs 24.1, but here's my question:

The main problem is actually knowing when to stop animating.  Currently
url-queue just kills off processes in a variety of situations, but it
should probably call the callback anyway, with an error condition
instead.  However, Emacs 24 is in a feature freeze, and I don't think
rearranging the kill-off/callback thing can be considered a bug fix.

Or can it?  `url-retrieve' calls the callback on most (all?) situations,
and `url-queue' is supposed to be like `url-retrieve', but on the
timeout/kill-off/callback issue it isn't.

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

Re: "Loading"

[Stefan Monnier]

> Or can it?  `url-retrieve' calls the callback on most (all?) situations,
> and `url-queue' is supposed to be like `url-retrieve', but on the
> timeout/kill-off/callback issue it isn't.

url-retrieve has suffered from similar problems, but they've been fixed
over time.  So, if that can be changed easily, please make such changes,
so the callback is always called,


        Stefan

Re: "Loading"

[Lars Magne Ingebrigtsen]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> url-retrieve has suffered from similar problems, but they've been fixed
> over time.  So, if that can be changed easily, please make such changes,
> so the callback is always called,

Ok; will do.  

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

Re: "Loading"

[Michael Albinus]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

Hi Lars,

> shr downloads images asynchronously, but there isn't anything to say
> "we're still downloading".  I think there should be.
>
> shr just inserts a "*" character as a placeholder now.  Perhaps it would
> make sense to insert an animated image instead displaying a "loading"
> symbol?  Or we could go old style with a spinning - \ | / - thing.

These days, I have started to implement asynchronous inserting/writing
of buffers, which are bound to a remote file. There I have also the
problem to indicate the user, that the operation hasn't been finished yet.

The progress-reporter, spinning in the echo area, is not an option,
because the minibuffer shall be usable. Therefore I'm thinking about to
reactivate the old proposal of a progress-reporter extension, spinning \
| / in the modeline (more precisely: in `mode-line-remote').

I believe it would be a good thing, if running asynchronous operations
are made visible consistently in Emacs. Maybe we could agree on the same
function?

Best regards, Michael.

Re: "Loading"

[Stefan Monnier]

> The progress-reporter, spinning in the echo area, is not an option,
> because the minibuffer shall be usable. Therefore I'm thinking about to
> reactivate the old proposal of a progress-reporter extension, spinning \
> | / in the modeline (more precisely: in `mode-line-remote').

Why mode-line-remote rather than mode-line-process?


        Stefan

Re: "Loading"

[Michael Albinus]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> Why mode-line-remote rather than mode-line-process?

I'm saving a file. mode-line-remote ("@") tells me about the status of
this file, "being remote". Saving the file has nothing to do with any
running process, from the user's pov. So I believe it is the natural
place to indicate.

But it isn't hammered in stone for me, I'm open to other proposals.

>         Stefan

Best regards, Michael.

Re: "Loading"

[Stefan Monnier]

>> Why mode-line-remote rather than mode-line-process?
> I'm saving a file. mode-line-remote ("@") tells me about the status of
> this file, "being remote". Saving the file has nothing to do with any
> running process, from the user's pov. So I believe it is the natural
> place to indicate.

To me mode-line-process is the natural place (within the mode-line) to
put things that say "not quite done yet".


        Stefan

Re: "Loading"

[Michael Albinus]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> To me mode-line-process is the natural place (within the mode-line) to
> put things that say "not quite done yet".

No problem for me. I'll start with this. Could we document this meaning
of mode-line-process in the docstring? Currently, it just says

| Mode-line control for displaying info on process status.
| Normally nil in most modes, since there is no process to display.

I'll come later with a proposal about progress-reporter extension for 24.2.

(Honestly, I'm making slow progress, 'cause there are several serious
problems in asynchronous file operations I haven't solved yet)

>         Stefan

Best regards, Michael.

Re: "Loading"

[Lars Magne Ingebrigtsen]

Michael Albinus <michael.albinus@gmx.de> writes:

> The progress-reporter, spinning in the echo area, is not an option,
> because the minibuffer shall be usable. Therefore I'm thinking about to
> reactivate the old proposal of a progress-reporter extension, spinning \
> | / in the modeline (more precisely: in `mode-line-remote').

I think spinning something in the mode line to indicate that we're
waiting for network traffic is a very good idea.

> I believe it would be a good thing, if running asynchronous operations
> are made visible consistently in Emacs. Maybe we could agree on the same
> function?

In messages with images, there's usually more than one.  Some may be
downloading, some may have failed and some may not be downloading at
all.  I was thinking that it would make sense to "spin" the particular
images that are in the process of downloading to give the user an
obvious feedback on what's happening with each particular image.

However, I'm not absolutely sure that's necessary.  The three categories
could be distinguished otherwise.  If the downloading fails, perhaps a
"broken image" image could be shown instead, and for the images that
aren't going to be downloaded, perhaps some other icon could be shown.
Spinning in the buffer itself may be unnecessarily distracting.

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

Re: "Loading"

[Tassilo Horn]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

>> I believe it would be a good thing, if running asynchronous
>> operations are made visible consistently in Emacs. Maybe we could
>> agree on the same function?
>
> In messages with images, there's usually more than one.  Some may be
> downloading, some may have failed and some may not be downloading at
> all.  I was thinking that it would make sense to "spin" the particular
> images that are in the process of downloading to give the user an
> obvious feedback on what's happening with each particular image.
>
> However, I'm not absolutely sure that's necessary.  The three
> categories could be distinguished otherwise.  If the downloading
> fails, perhaps a "broken image" image could be shown instead, and for
> the images that aren't going to be downloaded, perhaps some other icon
> could be shown.

Maybe some spinner plus number of active/aborted/skipped processes,
e.g., [\ (2/1/0)]?

> Spinning in the buffer itself may be unnecessarily distracting.

And it would be likely to break something.  Remember when you introduced
the seconds-counting Date header in gnus article mode and sometimes
copying a region would copy from Date header to mark instead of from
mark to point?

Bye,
Tassilo

Re: "Loading"

[Lars Magne Ingebrigtsen]

Tassilo Horn <tassilo@member.fsf.org> writes:

> Maybe some spinner plus number of active/aborted/skipped processes,
> e.g., [\ (2/1/0)]?

I think a simple spinner (that doesn't move stuff around in the mode
line) is to be preferred.  We just want to communicate to the user that
"we're waiting for something", not to flash lots of details at the
user.  If we want the latter, we can use the echo area...

>> Spinning in the buffer itself may be unnecessarily distracting.
>
> And it would be likely to break something.  Remember when you introduced
> the seconds-counting Date header in gnus article mode and sometimes
> copying a region would copy from Date header to mark instead of from
> mark to point?

Yes, that was a pain.  But I think I got all the bugs worked out after a
few months.

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

Re: "Loading"

[Michael Albinus]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> I think a simple spinner (that doesn't move stuff around in the mode
> line) is to be preferred.  We just want to communicate to the user that
> "we're waiting for something", not to flash lots of details at the
> user.  If we want the latter, we can use the echo area...

I would prefer the help area of the spinning char. As usual in the modeline.

As said already, the minibuffer/echo area shall be usable during the
async operation. At least in my use case :-)

Best regards, Michael.

Re: "Loading"

[Dave Abrahams]

on Wed Mar 14 2012, Michael Albinus <michael.albinus-AT-gmx.de> wrote:

> Lars Magne Ingebrigtsen <larsi@gnus.org> writes:
>
>> I think a simple spinner (that doesn't move stuff around in the mode
>> line) is to be preferred.  We just want to communicate to the user that
>> "we're waiting for something", not to flash lots of details at the
>> user.  If we want the latter, we can use the echo area...
>
> I would prefer the help area of the spinning char. As usual in the modeline.
>
> As said already, the minibuffer/echo area shall be usable during the
> async operation. At least in my use case :-)

Is there any reason a few characters couldn't be used for this in the
left part of the minibuffer/echo area, without making that area
completely unusable?

-- 
Dave Abrahams
BoostPro Computing
http://www.boostpro.com

Re: "Loading"

[Michael Albinus]

Dave Abrahams <dave@boostpro.com> writes:

> Is there any reason a few characters couldn't be used for this in the
> left part of the minibuffer/echo area, without making that area
> completely unusable?

Harder to implement. You would need to add a minor mode for the
minibuffer, which shows this fixed string. And for the echo area, you
would also need to touch `message' and friends.

Best regards, Michael.

Re: "Loading"

[Dave Abrahams]

on Thu Mar 15 2012, Michael Albinus <michael.albinus-AT-gmx.de> wrote:

> Dave Abrahams <dave@boostpro.com> writes:
>
>> Is there any reason a few characters couldn't be used for this in the
>> left part of the minibuffer/echo area, without making that area
>> completely unusable?
>
> Harder to implement. You would need to add a minor mode for the
> minibuffer, which shows this fixed string. And for the echo area, you
> would also need to touch `message' and friends.

What about just splitting the minibuffer window horizontally?

-- 
Dave Abrahams
BoostPro Computing
http://www.boostpro.com

Re: "Loading"

[Michael Albinus]

Dave Abrahams <dave@boostpro.com> writes:

>>> Is there any reason a few characters couldn't be used for this in the
>>> left part of the minibuffer/echo area, without making that area
>>> completely unusable?
>>
>> Harder to implement. You would need to add a minor mode for the
>> minibuffer, which shows this fixed string. And for the echo area, you
>> would also need to touch `message' and friends.
>
> What about just splitting the minibuffer window horizontally?

Anything goes, of course. But I fear we would break the minibuffer
(which is a special buffer, with special handling). And there is still
the echo area problem.

The modeline is designed to provide indications to the user. I believe,
it is the natural place for showing unfinished network activities.

If it cannot be a spinning char due to the permanent refresh, than it
might be some coloured text, as running processes show already.

Best regards, Michael.

Re: "Loading"

[Dave Abrahams]

on Thu Mar 15 2012, Michael Albinus <michael.albinus-AT-gmx.de> wrote:

> Dave Abrahams <dave@boostpro.com> writes:
>
>>>> Is there any reason a few characters couldn't be used for this in the
>>>> left part of the minibuffer/echo area, without making that area
>>>> completely unusable?
>>>
>>> Harder to implement. You would need to add a minor mode for the
>>> minibuffer, which shows this fixed string. And for the echo area, you
>>> would also need to touch `message' and friends.
>>
>> What about just splitting the minibuffer window horizontally?
>
> Anything goes, of course. But I fear we would break the minibuffer
> (which is a special buffer, with special handling). And there is still
> the echo area problem.

I didn't realize that was a separate problem.  Could you explain further?


> The modeline is designed to provide indications to the user. I believe,
> it is the natural place for showing unfinished network activities.
>
> If it cannot be a spinning char due to the permanent refresh, than it
> might be some coloured text, as running processes show already.

Yeah... but of course I'm looking at three modelines in my frame right
now.  The problem of having no central place to display global state is
well known around here, though.  Maybe just use the modeline of the
leftmost window immediately above the minibuffer?

-- 
Dave Abrahams
BoostPro Computing
http://www.boostpro.com

Re: "Loading"

[Tassilo Horn]

Dave Abrahams <dave@boostpro.com> writes:

>> The modeline is designed to provide indications to the user. I
>> believe, it is the natural place for showing unfinished network
>> activities.
>>
>> If it cannot be a spinning char due to the permanent refresh, than it
>> might be some coloured text, as running processes show already.
>
> Yeah... but of course I'm looking at three modelines in my frame right
> now.  The problem of having no central place to display global state
> is well known around here, though.  Maybe just use the modeline of the
> leftmost window immediately above the minibuffer?

Why is that a "global state"?  I mean, the running process is associated
with a buffer (e.g., a tramp buffer visiting a remote file, or a gnus
article buffer that has spawned several download processes), so I'd
expect the process activity indicator in the mode line of exactly that
buffer, no?

Bye,
Tassilo

Re: "Loading"

[Michael Albinus]

Tassilo Horn <tassilo@member.fsf.org> writes:

> Why is that a "global state"?  I mean, the running process is associated
> with a buffer (e.g., a tramp buffer visiting a remote file, or a gnus
> article buffer that has spawned several download processes), so I'd
> expect the process activity indicator in the mode line of exactly that
> buffer, no?

It could become "global" if we would speak about asynchronous file
operations in general, like asynchronous `copy-file'. But that I do not
implement (yet), I've started with `write-region' and
`insert-file-contents'. And here we have an associated buffer, and could
use its modeline.

Same for doing asynchronous operations on a gnus article buffer.

> Bye,
> Tassilo

Best regards, Michael.

Re: "Loading"

[Dave Abrahams]

on Thu Mar 15 2012, Tassilo Horn <tassilo-AT-member.fsf.org> wrote:

> Dave Abrahams <dave@boostpro.com> writes:
>
>>> The modeline is designed to provide indications to the user. I
>>> believe, it is the natural place for showing unfinished network
>>> activities.
>>>
>>> If it cannot be a spinning char due to the permanent refresh, than it
>>> might be some coloured text, as running processes show already.
>>
>> Yeah... but of course I'm looking at three modelines in my frame right
>> now.  The problem of having no central place to display global state
>> is well known around here, though.  Maybe just use the modeline of the
>> leftmost window immediately above the minibuffer?
>
> Why is that a "global state"?  I mean, the running process is associated
> with a buffer (e.g., a tramp buffer visiting a remote file, or a gnus
> article buffer that has spawned several download processes), so I'd
> expect the process activity indicator in the mode line of exactly that
> buffer, no?

In this case, maybe.  In the general case, there are processes with
no visible buffer or any obvious association.

-- 
Dave Abrahams
BoostPro Computing
http://www.boostpro.com

Re: "Loading"

[Lars Magne Ingebrigtsen]

Dave Abrahams <dave@boostpro.com> writes:

> In this case, maybe.  In the general case, there are processes with
> no visible buffer or any obvious association.

There may be use cases for a global notification thing, but it's not
immediately clear what this would be.  If the mode line spins for a
particular buffer, then it's clear that something (hopefully obvious) is
going to happen in the buffer in question.  If we have a global spinner,
all that would convey to the user is that Emacs is doing something...
somewhere...  for some reason...  Which might be neat, but not really
useful.

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

Re: "Loading"

[Lars Magne Ingebrigtsen]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> If we have a global spinner, all that would convey to the user is that
> Emacs is doing something...  somewhere...  for some reason...

On the other hand, if the interface allowed mouse-over over the spinner
to display a text saying what it was doing, then that might be nice.
Even for a per-buffer spinner.

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

Re: "Loading"

[Ted Zlatanov]

On Thu, 15 Mar 2012 17:12:10 +0100 Lars Magne Ingebrigtsen <larsi@gnus.org> wrote: 

LMI> Lars Magne Ingebrigtsen <larsi@gnus.org> writes:
>> If we have a global spinner, all that would convey to the user is that
>> Emacs is doing something...  somewhere...  for some reason...

LMI> On the other hand, if the interface allowed mouse-over over the spinner
LMI> to display a text saying what it was doing, then that might be nice.
LMI> Even for a per-buffer spinner.

A spinner is just one instance of a progress reporter (indeterminate) so
we should aim to implement a general progress reporter.

I am in favor of both a per-buffer reporter in the modeline, and a
global progress indicator.  Both should use the "Harvey balls" Unicode
characters, if they are available, rather than the typical \|/-
characters, and it could even use SVG if that's available.  On mouseover
this special progress report indicator it would display the messages
currently littering the echo area.

It should all be passed in parameters to `make-progress-reporter' with
the defaults left the way they are now.

We discussed this a while ago and Michael had a proposal with working
code that used the current modeline IIRC.  The global progress indicator
could live in the menu bar or in the currently active modeline.  I feel
that providing a flexible interface we can use and experiment on is more
important than getting every possible case right from the start, so
please think of flexible approaches rather than exactly how it should be
done to please everyone.

Ted

Re: "Loading"

[Michael Albinus]

Dave Abrahams <dave@boostpro.com> writes:

>> Anything goes, of course. But I fear we would break the minibuffer
>> (which is a special buffer, with special handling). And there is still
>> the echo area problem.
>
> I didn't realize that was a separate problem.  Could you explain further?

(info "(elisp)The Echo Area")

> Yeah... but of course I'm looking at three modelines in my frame right
> now.  The problem of having no central place to display global state is
> well known around here, though.  Maybe just use the modeline of the
> leftmost window immediately above the minibuffer?

We are speaking about asynchronous saving of a buffer. The
progress-reporter shall only touch the modeline which belongs to that
buffer.

Best regards, Michael.

Re: "Loading"

[Eli Zaretskii]

> From: Michael Albinus <michael.albinus@gmx.de>
> Date: Wed, 14 Mar 2012 10:02:45 +0100
> 
> The progress-reporter, spinning in the echo area, is not an option,
> because the minibuffer shall be usable.

Agreed.

> Therefore I'm thinking about to reactivate the old proposal of a
> progress-reporter extension, spinning \ | / in the modeline (more
> precisely: in `mode-line-remote').

Beware: I think redisplaying the mode line triggers redisplay of the
entire frame.  If I'm right (and I'm not 100% sure I am), then a
spinning indicator in the mode line would be a nuisance, because it
will cause an annoying flickering on display.

Re: "Loading"

[Michael Albinus]

Eli Zaretskii <eliz@gnu.org> writes:

> Beware: I think redisplaying the mode line triggers redisplay of the
> entire frame.  If I'm right (and I'm not 100% sure I am), then a
> spinning indicator in the mode line would be a nuisance, because it
> will cause an annoying flickering on display.

Thank for the heads-up. I will reanimate my slowest computer, and run
checks.

Best regards, Michael.