unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: "Drew Adams" <drew.adams@oracle.com>
To: "'Juanma Barranquero'" <lekktu@gmail.com>
Cc: 'Lennart Borgman' <lennart.borgman@gmail.com>,
	'Stefan Monnier' <monnier@iro.umontreal.ca>,
	'Emacs developers' <emacs-devel@gnu.org>
Subject: RE: Deprecate _emacs on Windows
Date: Tue, 22 Mar 2011 17:12:00 -0700	[thread overview]
Message-ID: <0B6A6EC5FD8F46D697F914FB2F6D4304@us.oracle.com> (raw)
In-Reply-To: <AANLkTi=GYfn9=oSThGyhdJo2XzFCLcEs_Vb+Xqgd=VYv@mail.gmail.com>

> perhaps you could wait until the delayed warning issue is
> decided, and then we can change the warning so it still exists, 

Why should it still exist?

> but users can deactivate it from their .emacs... Sorry,
> I mean from their _emacs.

Why should they have to?

Why issue a _warning_ for this?  As long as a user's `_emacs' is found and used
(traditional behavior) there is nothing to warn about.  And if a user's `_emacs'
is no longer sought and found (i.e. ignored, in the future) then the warning
obviously does no good.

Since when does the mere act of deprecation call for a _warning_?  A warning is
in order only if a particular deprecation means there is some danger to warn
about.  Not the case for this deprecation.  And certainly we should not be
warning about the deprecation itself - there is no danger in that.

> > This phenomenon is a by-product of a unique civil law system gone
> > litigation-crazy.  And the influence extends beyond 
> > Amerika, unfortunately.
> 
> Well, Spain is nowhere near the States in this regard (and I proposed
> and added the warning) so I think your analysis is... silly?
> ridiculous? out of the line?

Yes, I know you did, which is why I added that this has moved well beyond
Amerika.  As I said, a couple of generations and globalization have spread it,
yes, even as far as Catalunya and the Canary Islands.  You might like to believe
you are not so influenced by American culture, but think again.

Other societies often pick up the effects (e.g., ubiquitous non-warning
warnings) even when they don't necessarily pick up the cause (e.g., fear of
lawsuits).

And even if an American corp doesn't necessarily fear a particular lawsuit
abroad, it often applies the same general policy as in the US.  McDonalds in
Paris introduced urinals for the disabled in the 90s - it started applying the
same US-inspired policy pretty much everywhere.  (Parisians sometimes thought
they were kid urinals...)

That's an example of an improvement, but the effects are not always so positive.
Overcleanliness and overprotection have helped lead to antibiotic resistance
worldwide.

An indiscriminate spread of watered-down warnings acts similarly.  When warnings
are everywhere they tend to get ignored as background noise.  Chicken Little and
the Boy Who Cried Wolf eventually got into trouble...  You can't be warning
people of nonsense all the time and then expect them to stand up and take notice
when you really have something to warn about.

---

That said, much of continental Europe itself has a long tradition of
over-warning people.  The Code Napoleon (with an explicit rule for everything,
as opposed to English law's greater reliance on precedence), coupled with a
(necessarily) unsystematic enforcement of the rules, has meant that people are
always breaking some rule or other, and typically not getting punished for it.

It's just a different system/tradition, one where "Defense d'Afficher" is
affiched everywhere.

So yes, there are no doubt multiple reasons why a European might think it
appropriate to "warn" users about such a deprecation.  I don't claim that
avoidance of lawsuits is the only culprit.  I do feel that over-warning has
gotten worse over the last few decades, and corporate America's increased
lawsuit shyness has played a role in that.

Whatever the reasons, it's too bad.  One opinion.




  reply	other threads:[~2011-03-23  0:12 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-03-12 21:54 Deprecate _emacs on Windows Juanma Barranquero
2011-03-12 22:02 ` Lennart Borgman
2011-03-12 22:48   ` Drew Adams
2011-03-12 22:53     ` Lennart Borgman
2011-03-12 23:03       ` Drew Adams
2011-03-12 23:20         ` Lennart Borgman
2011-03-13  4:01   ` Stefan Monnier
2011-03-13  4:14     ` Juanma Barranquero
2011-03-22 20:38     ` Drew Adams
2011-03-22 20:50       ` Juanma Barranquero
2011-03-23  0:12         ` Drew Adams [this message]
2011-03-23  0:26           ` Juanma Barranquero
2011-03-23  0:58             ` Drew Adams
2011-03-23  1:34               ` Juanma Barranquero
2011-03-23  1:42                 ` Juanma Barranquero
2011-03-24 23:33                   ` Stephen J. Turnbull
2011-03-24 23:39                     ` Juanma Barranquero
2011-03-23  2:42                 ` Drew Adams
2011-03-23  3:00                   ` Juanma Barranquero
2011-03-23  3:20               ` Stephen J. Turnbull
2011-03-23  3:34                 ` Juanma Barranquero
2011-03-23  5:01                   ` Óscar Fuentes
2011-03-23 12:07                     ` Juanma Barranquero
2011-03-23 12:23                       ` Fabian Ezequiel Gallina
2011-03-23 12:30                         ` Juanma Barranquero
2011-03-23 13:36                           ` Fabian Ezequiel Gallina
2011-03-23 13:42                           ` Drew Adams
2011-03-23 14:30                             ` Juanma Barranquero
2011-03-23 17:40                             ` Stefan Monnier
2011-03-23 14:09                 ` Drew Adams
2011-03-23 16:23                   ` Stephen J. Turnbull
2011-03-13 22:49 ` Chong Yidong

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

  List information: https://www.gnu.org/software/emacs/

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

  git send-email \
    --in-reply-to=0B6A6EC5FD8F46D697F914FB2F6D4304@us.oracle.com \
    --to=drew.adams@oracle.com \
    --cc=emacs-devel@gnu.org \
    --cc=lekktu@gmail.com \
    --cc=lennart.borgman@gmail.com \
    --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 public inbox

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

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).