bug#7291: 24.0.50; `non-essential' is incomprehensible

[Stefan Monnier]

>> That's because you have it backwards:
>> It means that the task being performed is so UNimportant that
>> the user should NOT be interrupted for it.
> And there's the potential confusion.  Which task is the "currently executing
> code" whose task gets characterized as essential or non-essential?

Elisp is single-threaded, so there is never more than one task at any
given time.  So I don't understand the question.

> It is quite possible to read the doc and think that the "currently
> executing code" refers to the code that binds this var to non-nil in
> order to prevent it's own interruption.

No, the docstring of a variable always describes the meaning of that
variable, i.e. "what does it mean for the variable to be set to
a particular value".  So the code that sets the non-essential variable
states that "the code is non-essential" and the code that reads it
checks whether it (itself) is non-essential.

> Now you are suggesting that the "task being performed" is the task
> that would be _doing_ the interrupting, not the task that would be
> interrupted.

Again, Elisp is single-threaded, so the current code can't interrupt
some other.

> That comes across because you say "interrupted _for_ it"
> (for the task being performed).  That one word makes all the
> difference - the difference between interrupted "by" some task and
> interrupted "for" (i.e. to perform) some task.

The docstring says:

   Whether the currently executing code is performing an essential task.
   This variable should be non-nil only when running code which should not
   disturb the user.  ...

do you also see such a potential confusion there?

> The doc as written allows an interpretation of the "currently
> performing task" as the task that would (not) be interrupted.  It is
> very easy to think that by "the currently performing task"

As you can see the doc has no such "the currently performing task".

>> > One could easily suppose that a non-essential task is one that it is
>> > NOT IMPORTANT enough to protect against interruption.
>> Yes, I thought it was so easy to suppose that, that the docstring
>> was understandable.
> And yet you just said above that "the task being performed is so UNimportant
> that the user should NOT be interrupted for it".

Yes, sorry I didn't read your sentence carefully until the end.

> In one case we're talking about the nonimportance of the task that might be
> interrupted (so no need to prevent interruption).  In the other case we're
> talking about the nonimportance of the interrupting task.

But the only place where the docstring refers to the word "task" it very
clearly refers to "what the currently executing code is doing".  And it
never uses the word "interrupt" but instead uses "disturb".

> "Non-nil can prevent some tasks from interrupting the user.

Some of your confusion comes from the word "interrupt", so I'd rather
stick to "disturb".

>  Code that might perform a non-essential task can test this
>  variable and dispense with performing the task if the value
>  is non-nil.

No, this is backwards: e.g. Tramp doesn't know that what it does is
non-essential, which is why it needs to look up non-essential to figure
that out.  The only reason it does such a look up is not because it
suspects this is non-essential, but because it is about to do something
that may disturb the user, so it first wants to make sure it is really
necessary to do it.


        Stefan