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