Deprecate _emacs on Windows

Deprecate _emacs on Windows

[Juanma Barranquero]

As part of the discussion of bug#8220, I'd like to propose to add

  (warn "`_emacs' init file is deprecated, please use `.emacs'")

at the appropriate place in `command-line', as a first past to
eventually make _emacs obsolete and remove its support (on Windows, of
course, not MS-DOS).

Opinions?

    Juanma



(The patch also changes  cond + if/elsif/else into a simple cond,
which seems clearer).


=== modified file 'lisp/startup.el'
--- lisp/startup.el	2011-01-25 04:08:28 +0000
+++ lisp/startup.el	2011-03-12 21:39:52 +0000
@@ -1008,17 +1008,18 @@
 			   (cond
 			    ((eq system-type 'ms-dos)
 			     (concat "~" init-file-user "/_emacs"))
-			    ((eq system-type 'windows-nt)
+			     ((not (eq system-type 'windows-nt))
+			      (concat "~" init-file-user "/.emacs"))
+			     ;; Else deal with the Windows situation
+			     ((directory-files "~" nil "^\\.emacs\\(\\.elc?\\)?$")
 			     ;; Prefer .emacs on Windows.
-			     (if (directory-files "~" nil "^\\.emacs\\(\\.elc?\\)?$")
-				 "~/.emacs"
-			       ;; Also support _emacs for compatibility.
-			       (if (directory-files "~" nil "^_emacs\\(\\.elc?\\)?$")
-				   "~/_emacs"
-				 ;; But default to .emacs if _emacs does not exist.
-				 "~/.emacs")))
-			    (t
-			     (concat "~" init-file-user "/.emacs")))))
+			      "~/.emacs")
+			     ((directory-files "~" nil "^_emacs\\(\\.elc?\\)?$")
+			      ;; Also support _emacs for compatibility, but warn about it.
+			      (warn "`_emacs' init file is deprecated, please use `.emacs'")
+			      "~/_emacs")
+			     (t ;; But default to .emacs if _emacs does not exist.
+			      "~/.emacs"))))
 		      ;; This tells `load' to store the file name found
 		      ;; into user-init-file.
 		      (setq user-init-file t)

Re: Deprecate _emacs on Windows

[Lennart Borgman]

On Sat, Mar 12, 2011 at 10:54 PM, Juanma Barranquero <lekktu@gmail.com> wrote:
> As part of the discussion of bug#8220, I'd like to propose to add
>
>  (warn "`_emacs' init file is deprecated, please use `.emacs'")
>
> at the appropriate place in `command-line', as a first past to
> eventually make _emacs obsolete and remove its support (on Windows, of
> course, not MS-DOS).
>
> Opinions?

A good simplification.

RE: Deprecate _emacs on Windows

[Drew Adams]

> > Opinions?
> 
> A good simplification.

Another opinion: a bad idea.  (See bug #8220 thread.)

I'd propose instead that all platforms treat `_emacs' as a legitimate default
init-file name (in addition to `.emacs').

No doubt a minority of one, but that's my opinion anyway.

Re: Deprecate _emacs on Windows

[Lennart Borgman]

On Sat, Mar 12, 2011 at 11:48 PM, Drew Adams <drew.adams@oracle.com> wrote:
>> > Opinions?
>>
>> A good simplification.
>
> Another opinion: a bad idea.  (See bug #8220 thread.)
>
> I'd propose instead that all platforms treat `_emacs' as a legitimate default
> init-file name (in addition to `.emacs').
>
> No doubt a minority of one, but that's my opinion anyway.

Why?

RE: Deprecate _emacs on Windows

[Drew Adams]

> Why?

See the referenced thread if you're really interested, Lennart.  I'm sure I'm a
small minority on this, and I've already expressed myself about it.

Re: Deprecate _emacs on Windows

[Lennart Borgman]

On Sun, Mar 13, 2011 at 12:03 AM, Drew Adams <drew.adams@oracle.com> wrote:
>> Why?
>
> See the referenced thread if you're really interested, Lennart.  I'm sure I'm a
> small minority on this, and I've already expressed myself about it.

Sorry, I did not notice that discussion. And yes, I still think it is
a good idea to get rid of _emacs.

Re: Deprecate _emacs on Windows

[Stefan Monnier]

>> As part of the discussion of bug#8220, I'd like to propose to add
>> 
>>  (warn "`_emacs' init file is deprecated, please use `.emacs'")
>> 
>> at the appropriate place in `command-line', as a first past to
>> eventually make _emacs obsolete and remove its support (on Windows, of
>> course, not MS-DOS).
>> 
>> Opinions?

> A good simplification.

The patch doesn't show it to be a simplification, but I think it's
a good idea.


        Stefan

Re: Deprecate _emacs on Windows

[Juanma Barranquero]

On Sun, Mar 13, 2011 at 05:01, Stefan Monnier <monnier@iro.umontreal.ca> wrote:

> The patch doesn't show it to be a simplification

It's one line and a bit of reordering, because I find much clearer this

			   (cond
			     ((eq system-type 'ms-dos)
			      (concat "~" init-file-user "/_emacs"))
			     ((not (eq system-type 'windows-nt))
			      (concat "~" init-file-user "/.emacs"))
			     ;; Else deal with the Windows situation
			     ((directory-files "~" nil "^\\.emacs\\(\\.elc?\\)?$")
			      ;; Prefer .emacs on Windows.
			      "~/.emacs")
			     ((directory-files "~" nil "^_emacs\\(\\.elc?\\)?$")
			      ;; Also support _emacs for compatibility, but warn about it.
			      (warn "`_emacs' init file is deprecated, please use `.emacs'")
			      "~/_emacs")
			     (t ;; But default to .emacs if _emacs does not exist.
			      "~/.emacs"))))

rather than

			   (cond
                             ((eq system-type 'ms-dos)
                              (concat "~" init-file-user "/_emacs"))
                             ((eq system-type 'windows-nt)
                              ;; Prefer .emacs on Windows.
                              (if (directory-files "~" nil
"^\\.emacs\\(\\.elc?\\)?$")
                                  "~/.emacs"
                                ;; Also support _emacs for
compatibility, but warn about it
                                (if (directory-files "~" nil
"^_emacs\\(\\.elc?\\)?$")
                                    (progn
                                      (warn "`_emacs' init file is
deprecated, please use `.emacs'")
                                      "~/_emacs")
                                  ;; But default to .emacs if _emacs
does not exist.
                                  "~/.emacs")))
                             (t
                              (concat "~" init-file-user "/.emacs")))))

with the nested if / else if / else thingy, but I can install this
change instead if people dislikes the other.

> but I think it's a good idea.

That's great to hear.

    Juanma

Re: Deprecate _emacs on Windows

[Chong Yidong]

Juanma Barranquero <lekktu@gmail.com> writes:

> As part of the discussion of bug#8220, I'd like to propose to add
>
>   (warn "`_emacs' init file is deprecated, please use `.emacs'")
>
> at the appropriate place in `command-line', as a first past to
> eventually make _emacs obsolete and remove its support (on Windows, of
> course, not MS-DOS).

Sounds fine to me.  Don't forget the NEWS file.

RE: Deprecate _emacs on Windows

[Drew Adams]

Come on.  This is getting silly.  Now there is a _warning_ when you start Emacs
with an init file named `_emacs'.  A ***WARNING***?  You have got to be kidding.
Ridiculous.

No doubt due to a pampered American generation or two having been brought up
with extreme protection, from crash helmets for 3-year-old tricyclists to...
what's next?  Disclaimers that alphabet soup might accidentally spell out
offensive words?

This phenomenon is a by-product of a unique civil law system gone
litigation-crazy.  And the influence extends beyond Amerika, unfortunately.
People everywhere come to think it's only natural to **SCREAM ALARMIST
WARNINGS** at users about the slightest potential boo-boo.

It's one thing for some company to issue such silly warnings to avoid possible
lawsuits; it's another thing for everyone and her brother to act likewise for no
real reason other than habit.

Emacs need not fear a lawsuit in this case - and its users deserve better than
being beat over the head with such silliness.  When pseudo-warnings abound about
anything and everything, any real warnings lose their significance.

Re: Deprecate _emacs on Windows

[Juanma Barranquero]

On Tue, Mar 22, 2011 at 21:38, Drew Adams <drew.adams@oracle.com> wrote:

> Come on.  This is getting silly.  Now there is a _warning_ when you start Emacs
> with an init file named `_emacs'.  A ***WARNING***?  You have got to be kidding.
> Ridiculous.

I think you made your opinion on this issue quite clear before, even
in the same thread where I discussed adding the warning, so it's a
bit... silly? ridiculous? for you to suddenly show such indignation.

That said, if you cool off a bit, perhaps you could wait until the
delayed warning issue is decided, and then we can change the warning
so it still exists, but users can deactivate it from their .emacs...
Sorry, I mean from their _emacs.

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

> Emacs need not fear a lawsuit in this case - and its users deserve better than
> being beat over the head with such silliness.

The users you are trying to protect can avoid that warning with

  C:> ren _emacs .emacs

Hard, isn't?

    Juanma

RE: Deprecate _emacs on Windows

[Drew Adams]

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

Re: Deprecate _emacs on Windows

[Juanma Barranquero]

> Why should it still exist?

Why not? You're making a big, big deal of a small warning that just
tells the user to rename a file.

And, why are you not pissed off by "emacs --unibyte", for example?

> Why should they have to?

Why should they not? By your reasoning, we should deprecate things,
but *never* remove them, because, why should we force users to change
anything? Well, if they are really that interested in keeping _emacs,
they can stay with Emacs 23.

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

We're warning them that in a not-so-distant future they will find
their _emacs no longer working.

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

I fail to understand your reasoning here, sorry.

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

You have already lectured us on your interpretation for the word
"warning". I still disagree.

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

Please! Are you really unable to talk about these matters without
being patronizing?

    Juanma

RE: Deprecate _emacs on Windows

[Drew Adams]

> And, why are you not pissed off by "emacs --unibyte", for example?

I haven't seen it, and I don't know anything about it.  If I got such a warning
each time I fired up Emacs, and if it in fact warned about no danger at all
(dunno whether it does), then I'd no doubt respond similarly about that.

My point is simply that we should warn only about impending danger.  Deprecation
is not such a case (in general).

> > Why should they have to?
> 
> Why should they not? By your reasoning, we should deprecate things,
> but *never* remove them,

What makes you say that?  If we deprecate something then of course we should
remove it at some point.  Users should not have to deactivate the warning
message - they should never see it in the first place; it makes no sense.

My objection here is to the warning, not to the deprecation or to the removal of
support for the feature.

(I also object to this particular deprecation, but that is a different issue.
And if this feature is to be deprecated then of course I am in favor of its
later being desupported - that's the point of deprecation.)

> because, why should we force users to change anything?

How do you justify that generalization?  I objected to _warning_ users simply
because you are deprecating `_emacs'.  You don't seem to get it.

> Well, if they are really that interested in keeping _emacs,
> they can stay with Emacs 23.

Again, off-topic.  My complaint here is about the warning.

> > 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.
> 
> We're warning them that in a not-so-distant future they will find
> their _emacs no longer working.

That's not something to warn about.  There is no danger.  Inform them, yes,
good.  Put a deprecation notice in the manual where we talk about `_emacs'.
That's typically how deprecation is done.

A user should not see warning messages about things that are being deprecated -
unless one of the deprecations leads to some danger.

> > 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.
> 
> I fail to understand your reasoning here, sorry.

When (after desupport) Emacs no longer looks for `_emacs', it will not be found.
Emacs will then no longer issue the warning, presumably.

(Or will you scour the user's hard drive for a `_emacs' file just so you can
warn about it not having been used?)

> > 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.
> 
> You have already lectured us on your interpretation for the word
> "warning". I still disagree.

Google "warning".  Enjoy.

Hey, but the way things are going, at some point you might well be right:
"warning" will not mean anything more than "informing".  We're not there yet,
thank goodness.

> Are you really unable to talk about these matters without
> being patronizing?

ad hominem, ad hominem.  Sticks and stones...

It's not about you, Juanma - and it's not about me.  It's about the
pseudo-warning message, regardless of who is behind that initiative.

The message is not warning about anything.  It's simply telling a user that
`_emacs' is deprecated.  That's not a warning.  There is no danger.

We don't need to tell users this at Emacs startup - it's not a big deal that
`_emacs' is being deprecated.  Users are often frightened by "**WARNING**" - and
that's part of its effect.  But there is no call for frightening users here.

Re: Deprecate _emacs on Windows

[Juanma Barranquero]

On Wed, Mar 23, 2011 at 01:58, Drew Adams <drew.adams@oracle.com> wrote:

> (Or will you scour the user's hard drive for a `_emacs' file just so you can
> warn about it not having been used?)

Yes, Drew, that's exactly what I will do, because in my free time I'm
secretly a James Bond cat-petting villain.

> Google "warning".  Enjoy.

Sorry, but I'm not convinced. Words mean what people use them to mean.

> ad hominem, ad hominem.  Sticks and stones...

My comment wasn't an argument ad hominem; I don't think your arguments
are incorrect because of who you are. I think you're using a lot (a
*lot*) of patronizing, independently of the validity of your technical
(sorry, political... sorry, social... antropological? philosophical?
legal? historical?) arguments.

> It's not about you, Juanma - and it's not about me.  It's about the
> pseudo-warning message, regardless of who is behind that initiative.

Oh, yes, it is a bit about you, as you're the one royaly pissed by the
warning... on behalf of some semi-mythical users that you somehow
stand to protect. You know, that great contingent of / Emacs 24+ /
Windows / users / having an _emacs init file /.

> The message is not warning about anything.  It's simply telling a user that
> `_emacs' is deprecated.  That's not a warning.  There is no danger.

Of course there is a danger. The danger of the user upgrading to a new
Emacs and failing to understand why their _emacs suddenly stopped
working[1]. In fact, if we don't warn about it, some users will be
caught unawares.

[1] Yes, I'm using singular they.

> We don't need to tell users this at Emacs startup - it's not a big deal that
> `_emacs' is being deprecated.  Users are often frightened by "**WARNING**" - and
> that's part of its effect.  But there is no call for frightening users here.

They shouldn't be frightened. They should be warned.

    Juanma

Re: Deprecate _emacs on Windows

[Juanma Barranquero]

On Wed, Mar 23, 2011 at 02:34, Juanma Barranquero <lekktu@gmail.com> wrote:

> Yes, Drew, that's exactly what I will do, because in my free time I'm
> secretly a James Bond cat-petting villain.

Full disclosure: I'm overweight and I have four cats (and between two
and three dogs). So don't think I'm joking. Be prepared for users'
hard disks to be carefully inspected looking for _emacs files and
other warn-able things to warn about. I'm just finishing the patch.

    Juanma

RE: Deprecate _emacs on Windows

[Drew Adams]

> > Google "warning".  Enjoy.
> 
> Sorry, but I'm not convinced. Words mean what people use them to mean.

Precisely.  And words mostly mean what most people use them to mean most of the
time.

Google "warning definition".  English-language dictionaries base definitions on
_usage_ (more so than dictionaries in some other languages).  And web
dictionaries probably do so even more.

So go ahead, see how people actually _use_ "warning"; I invite you.  Google
"warning definition".  But you will say I'm patronizing you by presuming that
Google might teach you something about this...

> > ad hominem, ad hominem.  Sticks and stones...
> 
> My comment wasn't an argument ad hominem;

Yes, that part of your post was ad hominem.  But it was not an _argument_ at
all.  It was nothing but name-calling.  I am not patronizing you just because I
give arguments about a growing tendency to overuse of so-called "warnings".  I
gave reasons why this has been happening.

You can argue with my reasoning or evidence, but please don't stoop to
name-calling.  It's not about me.  And my point is not about you.  I couldn't
care less who is behind this change.

You spoke up saying that my argument about American corporate avoidance of
lawsuits was invalid or irrelevant because you are in Spain.  I argued that this
tendency has extended beyond the American shore.  Counter the argument if you
want, but don't call me patronizing because you don't like the argument or its
implications.

Now you can say that it doesn't really matter _why_ there is this watering down
of the effect and meaning of a word such as "WARNING".  In general that's true,
but it can help to see that there is such a tendency.

If you think (if one thinks) it's normal to be warning people about such minor
things then I'm guessing it could help to know that this watering down is
something relatively new.  And more importantly (because who really cares what
how "warning" might be evolving?), when you overuse and misuse the word this way
it ceases to have the effect it is intended to have when you really need it.

> > It's not about you, Juanma - and it's not about me.  It's about the
> > pseudo-warning message, regardless of who is behind that initiative.
> 
> Oh, yes, it is a bit about you, as you're the one royaly pissed by the
> warning...

That I disagree with issuing the warning message doesn't make this about me.
Unless you take the view that whenever someone disagrees with you it's about
him.

> on behalf of some semi-mythical users that you somehow
> stand to protect. You know, that great contingent of / Emacs 24+ /
> Windows / users / having an _emacs init file /.

I don't speak for other users, nor do I claim to.  But I do want Emacs to be the
best it can be for users in general.  I speak up when the doc or the UI is not
as good as it could be.  I point to specific problems, as I see them.  That does
not mean I'm pretending to speak on behalf of all Emacs users.  I speak for
myself, caring about Emacs's interface with users.

And it doesn't really matter to my point whether there are lots or few users
impacted by this particular message.  My message is about the message; more
precisely, it is about this kind of pseudo-warning message.

> > The message is not warning about anything.  It's simply 
> > telling a user that `_emacs' is deprecated.  That's not a warning.
> > There is no danger.
> 
> Of course there is a danger. The danger of the user upgrading to a new
> Emacs and failing to understand why their _emacs suddenly stopped
> working[1].

Danger of failing to understand.  Hm.  By that logic anything we communicate to
users, to help them understand anything at all, should take the form of a
warning message.  After all, there's always the "danger" that they
misunderstand.

The question is, what is the _danger in misunderstanding_ this deprecation or
being ignorant of it?  Do you catch pneumonia?  Does your data melt down?  Just
what is the danger?  Please stop playing with words ("danger of failing to
understand", indeed), and come out with it: just what danger are we warning
users about here?

> In fact, if we don't warn about it, some users will be
> caught unawares.

And then what?  The _danger_ is?  And please don't repeat that the "danger" is
that they will be caught unaware.

> > We don't need to tell users this at Emacs startup - it's 
> > not a big deal that `_emacs' is being deprecated.  Users are
> > often frightened by "**WARNING**" - and that's part of its effect.
> > But there is no call for frightening users here.
> 
> They shouldn't be frightened.

Some will be.  That's the effect that "WARNING" and "DANGER!" have, at least on
some people.  That's part of their impact.

> They should be warned.

About what?

So far, you've indicated only that they should be helpfully _informed_ about
this deprecation.  I have explicitly agreed that they should.  The place to do
that is in the NEWS file, and possibly also in the manual.

Re: Deprecate _emacs on Windows

[Juanma Barranquero]

On Wed, Mar 23, 2011 at 03:42, Drew Adams <drew.adams@oracle.com> wrote:

> Yes, that part of your post was ad hominem.  But it was not an _argument_ at
> all.  It was nothing but name-calling.  I am not patronizing you just because I
> give arguments about a growing tendency to overuse of so-called "warnings".  I
> gave reasons why this has been happening.

Giving a long lecture about your opinions of worldwide trends in
corporate legal practices, because you don't like a warning in
Emacs... well, yes, that's patronizing. If you want to consider my
opinion about your lectures an ad hominem attack, suit yourself.

> That I disagree with issuing the warning message doesn't make this about me.
> Unless you take the view that whenever someone disagrees with you it's about
> him.

Of course. That's part of my James Bond villain persona.

    Juanma

RE: Deprecate _emacs on Windows

[Stephen J. Turnbull]

Drew Adams writes:

 > I objected to _warning_ users simply because you are deprecating
 > `_emacs'.

In all the projects I know of, your understanding of "how deprecation
is done" notwithstanding, deprecation's semantic content is issuing a
warning.  Formal deprecation is a policy statement that this feature
should *not* be used, *will* be removed, and any current uses should
be ported to the appropriate idiom, and yes, that should indeed get a
warning.

It should be possible to suppress those warnings (it is, in Python and
XEmacs), but the warning should be issued if the user chooses not to
suppress.

 > That's not something to warn about.  There is no danger.

OK, Drew, put

(if (< (random 100) 1) (error "Your .emacs is no longer usable."))

as the first line in your .emacs.  When it triggers, come back and
tell us how you happy you are about losing use of your init file
without warning until it actually happens.  Just how often do you
think long-time users read the section about what the name of the init
file is, anyway?  Or NEWS?

The issue really *is* whether the feature should be removed, and
therefore deprecation and the accompanying warning are warranted, not
whether a deprecation deserves a warning.  Personally, I think _emacs
is harmless, and deprecating it is indeed crying wolf, but that's not
my decision.

Re: Deprecate _emacs on Windows

[Juanma Barranquero]

On Wed, Mar 23, 2011 at 04:20, Stephen J. Turnbull <stephen@xemacs.org> wrote:

> Personally, I think _emacs
> is harmless, and deprecating it is indeed crying wolf, but that's not
> my decision.

I agree that it is harmless. But it is also cruft, and cleaning must
be done sooner or later, IMO. As I've said before, the worldwide set
of Windows users of Emacs 24+ and _emacs isn't likely to be big.
Forcing them to rename _emacs to .emacs (if they want to go forward to
Emacs 24+), and so allowing us to remove exceptional cases from our
code and documentation, is a net win.

    Juanma

Re: Deprecate _emacs on Windows

[Óscar Fuentes]

Juanma Barranquero <lekktu@gmail.com> writes:

> I agree that it is harmless. But it is also cruft, and cleaning must
> be done sooner or later, IMO. As I've said before, the worldwide set
> of Windows users of Emacs 24+ and _emacs isn't likely to be big.
> Forcing them to rename _emacs to .emacs (if they want to go forward to
> Emacs 24+), and so allowing us to remove exceptional cases from our
> code and documentation, is a net win.

Just a minor note: you can't rename _emacs to .emacs with Windows
Explorer, at least on XP.

Re: Deprecate _emacs on Windows

[Juanma Barranquero]

On Wed, Mar 23, 2011 at 06:01, Óscar Fuentes <ofv@wanadoo.es> wrote:

> Just a minor note: you can't rename _emacs to .emacs with Windows
> Explorer, at least on XP.

I said

  C:> ren _emacs .emacs

for a reason ;-)

And, it is trivially done with... Emacs?

    Juanma

Re: Deprecate _emacs on Windows

[Fabian Ezequiel Gallina]

2011/3/23 Juanma Barranquero <lekktu@gmail.com>:
> On Wed, Mar 23, 2011 at 06:01, Óscar Fuentes <ofv@wanadoo.es> wrote:
>
>> Just a minor note: you can't rename _emacs to .emacs with Windows
>> Explorer, at least on XP.
>
> I said
>
>  C:> ren _emacs .emacs
>
> for a reason ;-)
>
> And, it is trivially done with... Emacs?
>
>     Juanma
>

How about to make the warning interactive? giving the user the
posibility to let Emacs rename the file right there when the warning
is prompt?

"_emacs is obsolete, do you want to let Emacs rename it to .emacs now? (y/n)"


Regards,
-- 
Fabián E. Gallina

Re: Deprecate _emacs on Windows

[Juanma Barranquero]

On Wed, Mar 23, 2011 at 13:23, Fabian Ezequiel Gallina
<galli.87@gmail.com> wrote:

> How about to make the warning interactive? giving the user the
> posibility to let Emacs rename the file right there when the warning
> is prompt?
>
> "_emacs is obsolete, do you want to let Emacs rename it to .emacs now? (y/n)"

Are you trying to provoke Drew a heart attack?

Or, more seriously, that would be too intrusive IMO, and you would
need to add a way to silence it anway (in case the user does not want
to rename it).

    Juanma

Re: Deprecate _emacs on Windows

[Fabian Ezequiel Gallina]

2011/3/23 Juanma Barranquero <lekktu@gmail.com>:
> On Wed, Mar 23, 2011 at 13:23, Fabian Ezequiel Gallina
> <galli.87@gmail.com> wrote:
>
>> How about to make the warning interactive? giving the user the
>> posibility to let Emacs rename the file right there when the warning
>> is prompt?
>>
>> "_emacs is obsolete, do you want to let Emacs rename it to .emacs now? (y/n)"
>
> Are you trying to provoke Drew a heart attack?
>
> Or, more seriously, that would be too intrusive IMO, and you would
> need to add a way to silence it anway (in case the user does not want
> to rename it).
>
>     Juanma
>

I think it would be neat if a warning could be a simple string or a
cons where the car is the warning string and the cdr is a callback
that should be interactive (to be called via call-interactively):
Something like this: ("This foo should be a bar" . 'handle-foo-bar).

This way for warnings that can be assisted, a callback can be fired to
help the user to solve it. The "_emacs" to ".emacs" case is a good
example. Also is the case of deprecated vars.

The callback of course should let the user choose to take action or not.


Regards,
-- 
Fabián E. Gallina
http://www.from-the-cloud.com

RE: Deprecate _emacs on Windows

[Drew Adams]

> > How about to make the warning interactive? giving the user the
> > posibility to let Emacs rename the file right there when the warning
> > is prompt?
> >
> > "_emacs is obsolete, do you want to let Emacs rename it to 
> > .emacs now? (y/n)"

BTW, IIUC it is not yet obsolete - it is still supported.  It is being
deprecated at this time, not desupported.
 
> Are you trying to provoke Drew a heart attack?

Can't resist, can you?  Drop the snide remarks, please.  It's not about me,
Juanma, remember?  Stop trying to caricature me.

> Or, more seriously, that would be too intrusive IMO, and you would
> need to add a way to silence it anway (in case the user does not want
> to rename it).

Actually, IMO the suggestion is a reasonable one.

My point was that this information for the user is not a warning of anything, so
it should not scream WARNING.  (I also think it is more appropriate to convey
deprecation info in NEWS and manual, but a non-warning message is OK if it is an
addition.)

As with some other places in Emacs, the user response to the question could be
more than a binary choice.  E.g., (a) rename now, (b) do nothing now, and (c) do
not rename and don't remind me again.  With either (a) or (c) the user will see
the message only once.

Dunno whether there might be any problem from doing this at its current position
during startup: lots of stuff can go on before (just a guess) and after
(definitely) the message appears.  Maybe it should wait until Emacs is idle for
some given period?  Dunno.

Interrupting the user also has the advantage that s?he will necessarily see the
message.  In my case, the *Warning* buffer appeared (splitting the window)
briefly, and then disappeared as the rest of my startup sequence finished.  If I
had not noticed the window-split briefly I would not have been aware that there
was a *Warning* buffer somewhere with a message for me.  Some users with a
shorter startup sequence might well miss it.  (And no, please do not just add a
long `sleep-for' or something.)

On the other hand, perhaps something would need to be done to inhibit the
message when Emacs is used in batch mode.  But that is perhaps in order anyway,
regardless of whether the message asks the user a question.  Maybe this has
already been taken care of - dunno.

RE: Deprecate _emacs on Windows

[Drew Adams]

>  > I objected to _warning_ users simply because you are deprecating
>  > `_emacs'.
> 
> In all the projects I know of, your understanding of "how deprecation
> is done" notwithstanding, deprecation's semantic content is issuing a
> warning.

So you are _not_ saying that in your experience - in all the projects you know
of - there was ever _actually_ a warning message used to convey a deprecation
notice.  You are merely claiming that "semantically" a deprecation amounts to
warning the user about something.

That's an opinion, an interpretation of the meaning of deprecation.  It's also
akin to Juanma's "danger of misunderstanding" or not hearing about the
deprecation.  The question is what you are really warning the user about if
deprecation, by definition, implies warning, as you suggest.

Certainly a deprecation notice informs the user of something, and often
something that might have important consequences.  No one is saying that a
deprecation notice isn't important.

The question is whether any of those consequences constitute a danger.  If so,
then I would agree that _that_ particular deprecation notice should be
accompanied by a warning of the specific danger.  It doesn't follow that all
deprecations imply some potential danger.

> Formal deprecation is a policy statement that this feature
> should *not* be used, 

in the future (deprecation is not desupport; it precedes desupport)

> *will* be removed, 

yes "will", at some point in the future

> and any current uses should be ported to the appropriate idiom,

Agreed - all of that.

> and yes, that should indeed get a warning.

No, that doesn't follow at all.

What danger are you warning users about?

>  > That's not something to warn about.  There is no danger.
> 
> OK, Drew, put
> (if (< (random 100) 1) (error "Your .emacs is no longer usable."))
> as the first line in your .emacs.  When it triggers, come back and
> tell us how you happy you are about losing use of your init file
> without warning until it actually happens.

Informing users is not warning them.  A deprecation notice is typically next to
the relevant material in the doc, and is often in release notes (e.g. NEWS) as
well.

Check your favorite (after Emacs) software's API doc for notice that some
routine or use of some parameter or some such is deprecated as of release XYZ.
Now look to see if the top level of that software screams at you when you invoke
it, letting you know all of the packages, routines, parameters, etc. that have
been deprecated.  Doesn't happen, in general.

Yes, of course, if something is super-important, it might well be called out
additionally in a prominent place or two (typically release notes).  And yes, if
some _real danger_ is involved, then a warning about that danger will be placed
in well chosen places.  But deprecation in general, as a rule, is not
accompanied by WARNINGs.

(You might find other pseudo-warnings occasionally: warnings in name only
(WINO).  But I don't see even those in the doc that I use.)

> Just how often do you think long-time users read the section about
> what the name of the init file is, anyway?  Or NEWS?

I'm not worried about it, frankly, and I'm one of those users.  Depends how
important you think this renaming is, I guess.

In any case, wanting users to be sure they get the message is one thing.
Scaring them with a WARNING is another thing.  You are not warning them about
anything in particular in this case - not AFAICT.

> The issue really *is* whether the feature should be removed,

Then in your opinion *that* should be the discussion: whether _emacs should be
deprecated.  But that has already been decided, so it is no longer an issue.
Are you trying to make it one again?

> and therefore deprecation and the accompanying warning are warranted,

If whether _emacs should be deprecated is still an issue, as you say, then it
does _not_ follow that the deprecation and warning are warranted.

Anyway, nothing says that a given deprecation notice should be accompanied by a
warning.  Some deprecations yes, but not in general.

> Personally, I think _emacs is harmless, and deprecating it is
> indeed crying wolf, but that's not my decision.

We agree about that, at least.

Re: Deprecate _emacs on Windows

[Juanma Barranquero]

On Wed, Mar 23, 2011 at 14:42, Drew Adams <drew.adams@oracle.com> wrote:

> Can't resist, can you?  Drop the snide remarks, please.  It's not about me,
> Juanma, remember?  Stop trying to caricature me.

I honestly swear to drop the snide remarks the day you drop the patronizing.

    Juanma

RE: Deprecate _emacs on Windows

[Stephen J. Turnbull]

Drew Adams writes:

 > So you are _not_ saying that in your experience - in all the
 > projects you know of - there was ever _actually_ a warning message
 > used to convey a deprecation notice.

Hm?  Maybe you should go into reading tea leaves instead of
emacs-devel.  You could make a lot of money with that kind of creative
interpretation.

 > That's an opinion, an interpretation of the meaning of deprecation.

No, it's not *merely* an opinion, it's the official policy of the
Python project.  Google for "DeprecationWarning" and
"PendingDeprecationWarning" and read PEP 5.  (It's short.)

 > > Formal deprecation is a policy statement that this feature
 > > should *not* be used, 
 > 
 > in the future (deprecation is not desupport; it precedes desupport)

Yes, of course that is the relationship between deprecation and
desupport, but there are other consequences of deprecation, in
general.  Deprecated functionality is normally not considered to
warrant support when implementing new features.  It is also often the
case that deprecated features *are* dangerous or buggy-by-design.

Again, it seems to me that you are objecting to accompanying
deprecation with a warning because you thing it's overblown *in this
case*.  I think there is a good rule of thumb: if a feature is not so
bad as to warrant an obtrusive deprecation warning, then it's probably
not worth deprecating.

 > > and yes, that should indeed get a warning.
 > 
 > No, that doesn't follow at all.

Of course it doesn't follow.  It's a policy, more or less arbitrary.
Here, "should indeed" *is* my opinion.

 > What danger are you warning users about?

It happens that three days ago, due to a change someone made in
XEmacs, my init file failed to get loaded.  I was *pissed*.  Another
example: somebody who depends on the init file to set up accessibility
features could be crippled.  Yes, I think this is important enough to
warn people who use this feature.

I infer you think that users should read NEWS.  That's a reasonable
opinion, but one I disagree with, and one many users take *strong*
exception to.  They do not want to read NEWS to continue using an
upgraded program as they are accustomed to.

 > But deprecation in general, as a rule, is not accompanied by
 > WARNINGs.

Of course it is.  Compilers issue warnings all the time about
deprecated features and usages.  That's what they're called,
"warnings".

It's true that in my experience UIs rarely issue deprecation warnings,
but that's mostly because the programs I use almost never deprecate
features that are part of the UI.  They just add new UI.  The only
case I can remember was when XEmacs decided to move from supporting
both the "Emacs" application class and the "XEmacs" application class
in the X resource database to supporting "XEmacs" only.  In that case
we explicitly decided not to warn because it seemed likely that most
people with "Emacs" in their .Xresources would have it there because
they use Emacs as well as XEmacs, so it was inherently ambiguous as to
whether the user needed to be informed -- even once the feature is
removed from XEmacs, it is still needed for use with Emacs.

 > Are you trying to make [the deprecation decision into an issue] again?

No.  You're being exceptionally tendentious this week, Drew.

Re: Deprecate _emacs on Windows

[Stefan Monnier]

> BTW, IIUC it is not yet obsolete - it is still supported.  It is being
> deprecated at this time, not desupported.
 
We rarely stop supporting something before we actually remove it
altogether: obsolete features are usually still supported to the extent
that we try and fix new bugs in them when people report them.


        Stefan

Re: Deprecate _emacs on Windows

[Stephen J. Turnbull]

Juanma Barranquero writes:

 > Full disclosure: I'm overweight and I have four cats (and between two
 > and three dogs). So don't think I'm joking. Be prepared for users'
 > hard disks to be carefully inspected looking for _emacs files and
 > other warn-able things to warn about. I'm just finishing the patch.

This would have been much more effective if you had waited nine days
and just submitted the patch. ;-)

Re: Deprecate _emacs on Windows

[Juanma Barranquero]

On Fri, Mar 25, 2011 at 00:33, Stephen J. Turnbull <stephen@xemacs.org> wrote:

> This would have been much more effective if you had waited nine days
> and just submitted the patch. ;-)

Yeah. I should've done that, and called the patch "the diskraker"...

    Juanma