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 09:22:43 -0700	[thread overview]
Message-ID: <3457CB74869B424BB0DB5A41C034AED7@us.oracle.com> (raw)
In-Reply-To: <jwv62wnkup9.fsf-monnier+emacs@gnu.org>

> > So does nil mean the code is performing an essential task?  Or does
> > non-nil mean that?
> 
> Let's see, you're asking whether "non-essential = nil" means 
> "performing an essential task" or "performing a non-essential
> task"?

Actually, I asked whether `non-essential'=nil or  `non-essential'=t means
performing a non-essential task (whatever that in turn might mean).

I asked about the variable value: what it's for, what it means.  Do you know?

The variable's only use is in Tramp.  Why isn't it named with the prefix
`tramp-'?  Is there something more general going on?

> Hmm... now that's a difficult question which I wouldn't
> expect any Lisp coder to be able to answer.

How cute.  But if you cannot tell by reading the code and you cannot tell by
reading the doc, then where are we?

The doc apparently does try to answer that "difficult question", but it is not
clear.  Hence this doc-bug report.

(Imagine a nuclear submarine with a big red flashing button labeled "UNIMPORTANT
*", where the footnote `*' says "UNimportant ONLY if ______ - otherwise,
IMPORTANT - push now!", where the _____ part is illegible...)

The doc says something about the value determining whether or not users will be
disturbed.  It is unclear which value disturbs them, how it disturbs them, why
or when it does so.

> > I cannot understand this.  What does it really mean?
> 
> If you can't understand it, then just ignore it.

Do you understand it?  If so, then please clean up the doc string.  That
shouldn't be hard.  If you do not, then let's find someone who does.

> > If this variable is this important and global (no `tramp-' 
> > prefix) then it should be documented in the Elisp manual.
>  
> Emacs lived happily for more than 20 years without it, so I 
> really have no clue whatsoever what makes you think "it's
> this important".

By that reasoning, we should simply remove the variable altogether.  It wasn't
needed during the last 20 years so it must not be needed now. (!?)

You admit that the doc for this is incomprehensible and misleading.  But you say
that doesn't matter because this variable wasn't necessary for the previous 20
years.  Huh?

Still, I would like to know what this is about.  Especially since it apparently
matters for code that involves file-name completion.  Is there something special
about Ido and Icomplete that this should single them out for its treatment
(whatever that treatment might be)?  Or does it apply generally to file-name
completion code?






  reply	other threads:[~2010-10-28 16:22 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 [this message]
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
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=3457CB74869B424BB0DB5A41C034AED7@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.