Changes in dos-fns.el

Changes in dos-fns.el

[Eli Zaretskii]

  2010-05-13  Stefan Monnier  <monnier@iro.umontreal.ca>

	  * dos-fns.el: Add "dos-" prefix for namespace control.
	  (convert-standard-filename): Define as alias for
	  dos-convert-standard-filename but only if applicable.

The more I think about these changes, the less I like them.

These functions are very old, some from 1996, others from 1994, and in
all that time no one complained about them.  What kind of use-case was
important enough to change their names now in an incompatible fashion?

Yes, I've read the comments about convert-standard-filename.  Again,
no one complained about what happens when someone loads dos-fns on
other platforms.  Why is this suddenly an issue now?  And if its _is_
an issue, why it gets fixed only in dos-fns, not in other places where
we have overriding definitions for this function?  In any case, I
could think of better ways of fixing this.  For example, we could lump
all the definitions in the body of a single function on file.el, each
alternative conditioned by the underlying OS.

But if I could somehow understand the motivation for the change of
convert-standard-filename, I have no idea what are the advantages of
renaming venerable functions such as intdos and mode4350.  Can they
really cause name clashes?  And if they can, how come that didn't
happen even once in the last 15 years?  Besides, mode25 and mode4350
are documented in the manual, and I expect them to be fairly popular
amongst DOS users (when I was one, I had a call to mode4350 in my
.emacs).  Why change the name now without leaving behind a defalias?

Unless I miss some very important aspects of this, I really, REALLY
think we should revert these changes.

Re: Changes in dos-fns.el

[Stefan Monnier]

> These functions are very old, some from 1996, others from 1994, and in
> all that time no one complained about them.  What kind of use-case was
> important enough to change their names now in an incompatible fashion?

My Emacs somehow loaded dos-fns.el and became largely unusable as
a result.  The loading was triggered by experimental code which provides
completion for all variables, whether their package is already loaded
or not.

> Yes, I've read the comments about convert-standard-filename.  Again,
> no one complained about what happens when someone loads dos-fns on
> other platforms.

Well, I did complain, in the form of a patch.

> Why is this suddenly an issue now?

Because I suddenly bumped into the problem.

> And if its _is_ an issue, why it gets fixed only in dos-fns, not in
> other places where we have overriding definitions for this function?

Because I haven't bumped into them yet, I guess.

> In any case, I could think of better ways of fixing this.
> For example, we could lump all the definitions in the body of a single
> function on file.el, each alternative conditioned by the
> underlying OS.

By all means, fix it better.  I agree that the "defalias" in dos-fns.el
is really not a good solution to the problem.  It was just a quick fix.

> But if I could somehow understand the motivation for the change of
> convert-standard-filename, I have no idea what are the advantages of
> renaming venerable functions such as intdos and mode4350.

My completion of functions and vars in not-yet-loaded packages works
better if the packages follow the usual namespace convention.

> Can they really cause name clashes?  And if they can, how come that didn't
> happen even once in the last 15 years?  Besides, mode25 and mode4350
> are documented in the manual, and I expect them to be fairly popular
> amongst DOS users (when I was one, I had a call to mode4350 in my
> .emacs).  Why change the name now without leaving behind a defalias?

Feel free to add an obsolete-alias, then.

> Unless I miss some very important aspects of this, I really, REALLY
> think we should revert these changes.

Following naming conventions is important, and following the "loading
a file should be harmless" convention is important as well.
It's difficult to impose those conventions across the board, but when we
do bump into code that breaks them, we should always try and fix it.
Undoing this change would be a step backward, but as DOS maintainer feel
free to improve my change.


        Stefan

Re: Changes in dos-fns.el

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: emacs-devel@gnu.org
> Date: Fri, 14 May 2010 15:39:07 -0400
> 
> Undoing this change would be a step backward, but as DOS maintainer feel
> free to improve my change.

Will do, but in the future please consider talking first.  I would
like to reduce the time I need to spend maintaining the DOS port to
the bare minimum, so as to maximize the part I spend on bidi work.