all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: "Drew Adams" <drew.adams@oracle.com>
To: "'Stefan Monnier'" <monnier@iro.umontreal.ca>
Cc: 7291@debbugs.gnu.org
Subject: bug#7291: 24.0.50; `non-essential' is incomprehensible
Date: Thu, 28 Oct 2010 14:58:34 -0700	[thread overview]
Message-ID: <D07ECE8A4198434681B524AECADC9E82@us.oracle.com> (raw)
In-Reply-To: <jwvr5fagkg2.fsf-monnier+emacs@gnu.org>

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

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.

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.  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 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" you mean the currently running Ido or Icomplete
code that binds the variable, and not the Tramp task of interrupting and reading
the password.

But either interpretation is possible; the result is confusion.

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

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.

The doc string is understandable by some and misunderstandable by others.  It is
not clear.

> > You seem to be defending the doc as it is only because you wrote it.
> > It doesn't matter that a user points out that it can be confusing?
> 
> No, I don't actually defend it.  It sucks because I'm bad at it, and
> I know it.  Your bug-report just rubbed me the wrong way: I 
> know I'm bad at it, no need to rub my face in it.  ... you should be
> able to provide more constructive criticism, and
> not only after the Nth email exchange.

No one rubbed your face in it.  Please don't be so defensive - it's not about
you.  If you feel I offended you then I am sorry for that.  I did not at first
know it was you who wrote this doc, and I really don't care who wrote it.  I
criticized the doc, not its writer.  If I had had to guess, I would have guessed
that Michael A. had written the doc string (only because he works on the Tramp
code).

My only intention was to help so that this doc string gets clarified a bit.
That should not be a big deal.  You immediately resisted, however, claiming in
effect that it was already clear and only an idiot would misunderstand it.

As to constructive criticism, my original report suggested that we say
explicitly which value (nil or non-nil) means that the code is performing a
non-essential task.  You resisted that suggestion, for some reason (not given).
By my third reply I gave an example in case my meaning wasn't clear: "Non-nil
means the currently executing code is performing a non-essential task".

Likewise, I pointed out from the beginning the possible confusion over what
"non-essential" means and which task was non-essential, and the need to clarify
this.

> >> Yes, they perform operations which are non-essential, i.e. 
> >> during which we don't want to pester the user.
> >
> > Do you see how backward that sounds?
> 
> No I don't.

Here, you refer to the Ido and Icomplete code as performing the operations that
we don't want to interrupt.  ("They" refers to the Ido etc. code, _not_ to the
potentially interrupting Tramp code - see the passage you replied to.)

So which is it?  Is it the Tramp password-reading task that is "so UNimportant
that the user should NOT be interrupted for it" (i.e. to perform it).  Or is it
the Ido and Icomplete code that "performs operations which are non-essential,
i.e. during which we don't want to pester the user"?

Once you decide that, you can tell the story clearly and easily.  What it really
comes down to, besides a choice of words, is that both sections of code
determine, together, where and whether a task should be skipped, the one by
binding the var to non-nil, the other by checking its value and skipping some
task if non-nil.

I suggest something like the following, if you feel it agrees with the behavior.

"Non-nil can prevent some tasks from interrupting the user.
 Code that might perform a non-essential task can test this
 variable and dispense with performing the task if the value
 is non-nil.

 E.g., Icomplete code binds this to non-nil while gathering a
 collection of file names.  While it is non-nil, Tramp
 will not read a password to check for any of files that might
 be remote."

HTH.






  reply	other threads:[~2010-10-28 21:58 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-10-27 22:30 bug#7291: 24.0.50; `non-essential' is incomprehensible Drew Adams
2010-10-28  0:52 ` Stefan Monnier
2010-10-28 16:22   ` Drew Adams
2010-10-28 17:14     ` Stefan Monnier
2010-10-28 18:43       ` Michael Albinus
2010-10-28 18:51       ` Drew Adams
2010-10-28 20:12         ` Stefan Monnier
2010-10-28 21:58           ` Drew Adams [this message]
2010-10-29 16:20             ` Stefan Monnier
2010-10-29 16:47               ` Drew Adams
2010-10-29 17:36                 ` Stefan Monnier
2010-10-29  8:36           ` Andreas Schwab
2010-10-29 16:03             ` Stefan Monnier
2010-10-29 16:21               ` Andreas Schwab
2010-10-29 18:29               ` Eli Zaretskii
2010-10-29 23:00                 ` Andy Moreton
2010-10-30  6:52                   ` Eli Zaretskii
2010-10-30 16:16                     ` Drew Adams
2010-10-30 17:53                       ` Michael Albinus
2010-10-30 20:05                         ` Drew Adams
2010-10-29 18:56           ` Alan Mackenzie
2010-10-28 17:33 ` James Cloos
2010-10-28 18:53   ` Drew Adams
2011-07-14 14:35   ` Lars Magne Ingebrigtsen
2010-10-31  2:34 ` MON KEY

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=D07ECE8A4198434681B524AECADC9E82@us.oracle.com \
    --to=drew.adams@oracle.com \
    --cc=7291@debbugs.gnu.org \
    --cc=monnier@iro.umontreal.ca \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.