> From: Jim Meyering <j...@meyering.net> > Cc: roucaries.bast...@gmail.com, egg...@cs.ucla.edu, bug-gnulib@gnu.org, > monn...@iro.umontreal.ca, emacs-de...@gnu.org > Date: Tue, 25 Jan 2011 17:32:27 +0100 > > Not being able to use a preferred file name due to the archaic 8.3 > naming limitations is onerous, even if someone else handles the > renaming task. Just because it's a cost incurred mostly by you > doesn't diminish the fact that it's a cost.
"What's in a name?" How is unistd.in.h substantially different from unistd-in.h or some such, that preferring one over the other is a "cost"? > I'm in the habit of avoiding problems with "old code" > and old processes, and I place great value on "code cleanliness". What is not "clean" in unistd-in.h? > When I see effort being expended in an attempt to work around DOS 8.3 > name collisions, my "oh, no, not that again" reflex kicks in and I can't > resist the urge to hype an approach that may relieve you and others of > the trouble of worrying about 8.3 ever again. How about honoring a small request of a veteran Emacs hacker? Does that have any weight in this discussion? It's certainly not less important than the knee-jerk reaction on behalf of 8.3. You are talking about costs? How about _my_ costs -- the need to endure these endless "why-don't-you-go-away-with-your-stupid-DOS" discussions? Here's Miles again, asking his perennial "how many users are there", here's Leo inventing "loads of weird files" that somehow are the fault of supporting the DOS port, here's Ulrich Mueller reminding me that I asked for eliminating file-name clashes in CEDET (in Oct 2009!)... How do you think I feel after all this hazing I need to go through, because of a simple request? What do you think this does to my motivation to continue development of the bidirectional editing support for a community that treats me like that? So I have a weak spot, so what? who doesn't? Why everybody and their dog here feel a need to probe that spot with a pique? > Isn't it almost always better to do a little more work now, when > that will save lots of tedious, manual work later? It is, but no one yet suggested such a magic way of solving this. All of the alternatives proposed until now mean more work, which is more tedious and more manual than a simple one-time rename. > Obviously building for DOS is worthwhile. > There's no need to stop that. If others cannot build it reliably and seamlessly, then there's no incentive for me to continue maintaining this port. Is that the intent here -- to make this progressively harder and harder for me, until I give up and go away? > Portability is great. For all I know, there may be many DOS-only emacs > users and developers. But portability is even better when archaic > constraints do not impede (not even slightly) development for more > modern systems. There's no impediment. File names can continue being long and descriptive, they just should be different either in the first 8 characters before the dot or the first 3 characters after the dot. That's it. All that's needed is a few seconds of thought when selecting a file name. It's not like this is the only restriction we need to cope with when naming files. The only "impediment" here is that knee-jerk irrational reaction.
