Re: Proposed gnulib renames

[Jim Meyering]

Eli Zaretskii wrote:
>> From: Jim Meyering <address@hidden>
>> Cc: Eli Zaretskii <address@hidden>, Paul Eggert <address@hidden>,
>> bug-gnulib <address@hidden>, address@hidden,
>> address@hidden, address@hidden, Bruno Haible
>> <address@hidden>
>> 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.