Eli Zaretskii wrote: >> From: Jim Meyering <[email protected]> >> Cc: Eli Zaretskii <[email protected]>, Paul Eggert <[email protected]>, >> bug-gnulib <[email protected]>, [email protected], >> [email protected], [email protected], Bruno Haible >> <[email protected]> >> Date: Wed, 26 Jan 2011 17:36:42 +0100 >> >> Here are some of the reasons to try hard to avoid 8.3 constraints >> altogether. The following are some of the tuples of names in gnulib >> that collide in 8.3-land: > > I have no doubt that there are a lot of these in gnulib. But the > chances that Emacs will ever want to use them are slim at the moment. > I don't see any reasons to try to solve a theoretical problem which > might never come our way. If it does come, and in these quantities, > not even I will dream of asking for such wholesale renames. Or maybe > the DOS build will be dead by then, who knows? > > So I suggest not to try to solve a problem until it is on the table. > I think what Bruno proposed is reasonable and easily maintainable, so > I would go for that. > >> I would feel better about this if Eli were gung-ho >> to use something like doslfn, had tried it, but had found that there >> were some fundamentally unfixable and show-stopping flaw in its design. > > Talking about some kind of add-on that all users of DOS Emacs will > have to install is a no-starter. Whoever wants long file names in > DJGPP programs can much more easily install any version of Windows and > be done with it. OTOH, those who do need DOS want it as plain and > un-tainted by unmaintained add-ons of dubious quality as possible.
There are two issues here. Requiring doslfn solely for those *building* emacs on DOS would allow the names of all C source and other build-only files to be "long". To gain that benefit, users would *not* have to install doslfn. However, to extend that benefit to files loaded by emacs at run time, they would.
