Re: RE : Re: Files from gnulib

[Jim Meyering]

Eli Zaretskii wrote:
>> From: Jim Meyering <address@hidden>
>> Cc: Bastien ROUCARIES <address@hidden>,
>> address@hidden, address@hidden, address@hidden,
>> address@hidden
>> Date: Tue, 25 Jan 2011 15:51:00 +0100
>>
>> Forcing current and future emacs development into the archaic 8.3 mold has
>> a significant cost
>
> The costs are generally mine, and mine alone.  I offered to do the

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.

> renaming job myself, provided some guidance from people who know their
> way through gnulib.
>
>> (just look at how long this thread is)
>
> It could be much shorter if my original request was granted.  It is
> long because people ask me questions and I respect them enough to
> answer those questions in detail.  I don't mind keeping answering
> them, but please don't hold that against me, or present that as
> incurring significant costs on Emacs development.  If we want to cut
> our losses, why not accept my suggestion, and be done with that?  For
> that matter, how about presenting some technical reasons for objecting
> the renaming I suggested, or any alternative renaming?  I explained
> why proposed alternatives were problematic, but didn't yet see any
> explanation of the reasons behind the apparent objection.

If what I said implied I'm holding anything against you personally,
it was not intended.

Why did I speak up?
I'm in the habit of avoiding problems with "old code"
and old processes, and I place great value on "code cleanliness".
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.  Isn't it almost always
better to do a little more work now, when that will save lots of tedious,
manual work later?

>> yet provides relatively little benefit.
>
> See, you are wrong here.  The number of times I found bugs in Emacs
> that are of importance to Posix platforms, just by building the DOS
> port, is not negligible.  The reasons are that the DOS build is very

Obviously building for DOS is worthwhile.
There's no need to stop that.
However, if you can continue doing that,
but with one small shim (assuming it's easy/effective)
and without naming constraints, then everyone would win.

> similar to the Unix build --without-x (which evidently not many people
> who track the development try these days), and its use of menus is
> exactly identical to the no-toolkit X build.  These are evidently rare
> configurations, but they are still supported.
>
> I think that the occasional hour or two I invest once in a few weeks
> when the DOS build becomes broken and I need to fix it is well payed
> by the benefits that brings to Emacs development in general, by
> uncovering bugs in those rare configurations.  And if it does some
> service to a niche user community while at that, what's wrong with
> that?

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.

>> If something like doslfn is reliable enough
>> and not hard to install, then requiring it makes sense: then all emacs
>> developers will be freed of this onerous file-naming constraint.
>
> It's impossible for me to say if doslfn is reliable.  I never used it
> myself, nor was it ever used widely enough by DJGPP users.
>
> As for the onerous file-naming constraint, we have more than 3000
> files in the Emacs tree, and the problem is limited to just 7 or so,
> all of them recent additions.

7 may not seem like a lot to you, but it does imply an ongoing tension.
A small burden...  One of those constraints that we'd like to define-away.

>> Imposing small relatively transparent requirements on users of less common
>> systems is actually a good practice, when doing so permits improvements
>> in the development process.
>
> I'm not aware of any improvements in the development process that the
> DOS port imposes.