RE : Re: Files from gnulib

RE : Re: Files from gnulib

[Bastien ROUCARIES]

[-- Attachment #1: Type: text/plain, Size: 805 bytes --]

Btw does doslfn not available these days?

Bastien

Le 25 janv. 2011 05:00, "Eli Zaretskii" <eliz@gnu.org> a écrit :

> Date: Mon, 24 Jan 2011 15:26:06 -0800

> From: Paul Eggert <eggert@cs.ucla.edu>
> CC: Stefan Monnier <monnier@iro.umontreal.ca>, bug-gnulib@gnu.org,
>  emacs-devel@gnu.org
>

> On 01/23/11 20:01, Eli Zaretskii wrote:
> > The program used to unpack the .tar.gz archives automa...
There are no special tarballs for MSDOS.  People use the tarball from
the GNU FTP site.  So this solution will not work.


> * The conflicting names in m4/* don't matter, for the same
> reason that conflicts in admin/* a...
The files in m4/ still matter because you need to unpack the tarball,
and the utility that does that won't silently overwrite files due to
file-name clashes.

[-- Attachment #2: Type: text/html, Size: 1284 bytes --]

Re: RE : Re: Files from gnulib

[Eli Zaretskii]

> Date: Tue, 25 Jan 2011 09:20:48 +0100
> From: Bastien ROUCARIES <roucaries.bastien@gmail.com>
> Cc: emacs-devel@gnu.org, monnier@iro.umontreal.ca, bug-gnulib@gnu.org, 
> 	Paul Eggert <eggert@cs.ucla.edu>
> 
> Btw does doslfn not available these days?

It can be downloaded (although unmaintained since 2006), but I don't
know whether it can be a viable solution.  It was never widely used
with DJGPP, so its compatibility with the Long File Name (LFN)
functions used by DJGPP is unknown.  DJGPP implementation of the
Standard C library assumes that any LFN support implements the full
range of LFN functions that Windows 9X provided.  There isn't a single
LFN function that is not used by some library function in DJGPP.

If someone wants LFN support nowadays, they can easily enough install
Windows (where DJGPP programs can run and support long file names).
Which may explain why doslfn is not used too much.

So I'd rather not request users to install doslfn.  None of the other
DJGPP ports requires LFN as a prerequisite for building it, so doing
so for Emacs sounds like a bad idea to me, when the alternative is to
rename a few files.

Re: RE : Re: Files from gnulib

[Jim Meyering]

Eli Zaretskii wrote:
>> Date: Tue, 25 Jan 2011 09:20:48 +0100
>> From: Bastien ROUCARIES <roucaries.bastien@gmail.com>
>> Cc: emacs-devel@gnu.org, monnier@iro.umontreal.ca, bug-gnulib@gnu.org,
>> 	Paul Eggert <eggert@cs.ucla.edu>
>>
>> Btw does doslfn not available these days?
>
> It can be downloaded (although unmaintained since 2006), but I don't
> know whether it can be a viable solution.  It was never widely used
> with DJGPP, so its compatibility with the Long File Name (LFN)
> functions used by DJGPP is unknown.  DJGPP implementation of the
> Standard C library assumes that any LFN support implements the full
> range of LFN functions that Windows 9X provided.  There isn't a single
> LFN function that is not used by some library function in DJGPP.
>
> If someone wants LFN support nowadays, they can easily enough install
> Windows (where DJGPP programs can run and support long file names).
> Which may explain why doslfn is not used too much.
>
> So I'd rather not request users to install doslfn.  None of the other
> DJGPP ports requires LFN as a prerequisite for building it, so doing
> so for Emacs sounds like a bad idea to me, when the alternative is to
> rename a few files.

Forcing current and future emacs development into the archaic 8.3 mold has
a significant cost (just look at how long this thread is), yet provides
relatively little benefit.  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.

This is like various shims we've used over the years. (remember ansi2knr?)
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.

Re: RE : Re: Files from gnulib

[Eli Zaretskii]

> From: Jim Meyering <jim@meyering.net>
> Cc: Bastien ROUCARIES <roucaries.bastien@gmail.com>,  eggert@cs.ucla.edu,  bug-gnulib@gnu.org,  monnier@iro.umontreal.ca,  emacs-devel@gnu.org
> 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
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.

> 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
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?

> 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.

> 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.

Re: RE : Re: Files from gnulib

[Jim Meyering]

Eli Zaretskii wrote:
>> From: Jim Meyering <jim@meyering.net>
>> Cc: Bastien ROUCARIES <roucaries.bastien@gmail.com>,
>> eggert@cs.ucla.edu, bug-gnulib@gnu.org, monnier@iro.umontreal.ca,
>> emacs-devel@gnu.org
>> 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.

Re: RE : Re: Files from gnulib

[Eli Zaretskii]

> From: Jim Meyering <jim@meyering.net>
> Cc: roucaries.bastien@gmail.com,  eggert@cs.ucla.edu,  bug-gnulib@gnu.org,  monnier@iro.umontreal.ca,  emacs-devel@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.

Re: RE : Re: Files from gnulib

[Miles Bader]

Eli Zaretskii <eliz@gnu.org> writes:
> Here's Miles again, asking his perennial "how many users are there"

Do you think that's an irrelevant question?

-miles

-- 
Liberty, n. One of imagination's most precious possessions.

Re: RE : Re: Files from gnulib

[Eli Zaretskii]

> From: Miles Bader <miles@gnu.org>
> Cc: Jim Meyering <jim@meyering.net>,  roucaries.bastien@gmail.com,  eggert@cs.ucla.edu,  bug-gnulib@gnu.org,  monnier@iro.umontreal.ca,  emacs-devel@gnu.org
> System-Type: x86_64-unknown-linux-gnu
> Date: Wed, 26 Jan 2011 09:45:15 +0900
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> > Here's Miles again, asking his perennial "how many users are there"
> 
> Do you think that's an irrelevant question?

It wasn't irrelevant when it was asked (and answered) the first time.
When asked for the umpteenth time, it sounds like you are actually
asking something else.

Re: RE : Re: Files from gnulib

[Miles Bader]

Eli Zaretskii <eliz@gnu.org> writes:
>> Do you think that's an irrelevant question?
>
> It wasn't irrelevant when it was asked (and answered) the first time.
> When asked for the umpteenth time, it sounds like you are actually
> asking something else.

The answer most likely does not remain the same over time, though, so
it's appropriate to re-ask such questions periodically.

-Miles

-- 
My spirit felt washed.  With blood.  [Eli Shin, on "The Passion of the Christ"]

Re: RE : Re: Files from gnulib

[Leo]

On 2011-01-26 02:48 +0800, Eli Zaretskii wrote:
> 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!)...

Please don't take that personally. People are annoyed by 8+3 not by you
and we users value very much your tireless and long-term contribution to
Emacs. The thing though is 8+3 is on everybody's mind so they will
unconsciously name files that way even in cases difficult to do so.

BTW, what I meant by weirdly-named files are, for example, those c.el,
dired.el etc in cedet. One has to look at its enclosing directory to
guess what it does.

Leo

-- 
Oracle is the new evil

Re: RE : Re: Files from gnulib

[Eli Zaretskii]

> From: Leo <sdl.web@gmail.com>
> Cc: Jim Meyering <jim@meyering.net>,  roucaries.bastien@gmail.com,  eggert@cs.ucla.edu,  bug-gnulib@gnu.org,  monnier@iro.umontreal.ca,  emacs-devel@gnu.org
> Date: Wed, 26 Jan 2011 10:42:13 +0800
> 
> On 2011-01-26 02:48 +0800, Eli Zaretskii wrote:
> > 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!)...
> 
> Please don't take that personally.

Everything is personal in this world.  People who don't take things
personal are people you should stay away of.

> People are annoyed by 8+3 not by you
> and we users value very much your tireless and long-term contribution to
> Emacs. The thing though is 8+3 is on everybody's mind so they will
> unconsciously name files that way even in cases difficult to do so.

Well, let your consciousness kick in.

> BTW, what I meant by weirdly-named files are, for example, those c.el,
> dired.el etc in cedet. One has to look at its enclosing directory to
> guess what it does.

And cedet-dired.el is more helpful how?

Re: RE : Re: Files from gnulib

[Jim Meyering]

Eli Zaretskii wrote:
>> From: Leo <sdl.web@gmail.com>
...
>> Please don't take that personally.
>
> Everything is personal in this world.  People who don't take things
> personal are people you should stay away of.

??
On the contrary.
Projects can improve/evolve more rapidly when egos don't interfere.
I find that people get a lot more real work done when they do not
interpret constructive criticism of their code as a personal attack.
It can be challenging, esp. when problem reports and "suggestions"
are worded undiplomatically, but dissociating ego from code is well
worth the effort.  "Assume the best" is almost always a better policy
than assuming the worst, both for you and for the people you deal with.
And for "the code".

Imagine that you didn't have to worry about 8.3 and Paul did not have
to jump through its hoops...  How many bugs would you two have fixed with
the saved time?  How much new code would you have been able to write
without contributing to this email thread.

>> People are annoyed by 8+3 not by you
>> and we users value very much your tireless and long-term contribution to

Re: RE : Re: Files from gnulib

[Eli Zaretskii]

> From: Jim Meyering <jim@meyering.net>
> Cc: Leo <sdl.web@gmail.com>,  roucaries.bastien@gmail.com,  eggert@cs.ucla.edu,  bug-gnulib@gnu.org,  monnier@iro.umontreal.ca,  emacs-devel@gnu.org
> Date: Wed, 26 Jan 2011 11:52:12 +0100
> 
> Eli Zaretskii wrote:
> >> From: Leo <sdl.web@gmail.com>
> ...
> >> Please don't take that personally.
> >
> > Everything is personal in this world.  People who don't take things
> > personal are people you should stay away of.
> 
> ??
> On the contrary.
> Projects can improve/evolve more rapidly when egos don't interfere.

"Personally" != "ego".  People who take their jobs personally are the
best ones I ever met.  Being emotional about your job is not a vice;
on the contrary.

But I _really_, REALLY don't want to start a sub-thread on this.

> I find that people get a lot more real work done when they do not
> interpret constructive criticism of their code as a personal attack.

We are not talking about any criticism of my code.  The analogy is
inappropriate.  There were no technical reasons for rejecting my
simple original suggestion.  Only dogmatic arguments, whose intent is
very clear: to resist any effort, even an infinitesimal one, on the
Posix side, even if it imposes an unduly heavy burden on me and on the
end users.  There's nothing between this and constructive criticism on
the one hand, and "ego" on the other.

> Imagine that you didn't have to worry about 8.3 and Paul did not have
> to jump through its hoops...  How many bugs would you two have fixed with
> the saved time?  How much new code would you have been able to write
> without contributing to this email thread.

Imagine that instead of arguing, the files would be simply renamed.
But we are repeating ourselves.

Re: RE : Re: Files from gnulib

[Jim Meyering]

Eli Zaretskii wrote:
>> From: Jim Meyering <jim@meyering.net>
...
>> Eli Zaretskii wrote:
>> >> From: Leo <sdl.web@gmail.com>
>> ...
>> >> Please don't take that personally.
>> >
>> > Everything is personal in this world.  People who don't take things
>> > personal are people you should stay away of.
>>
>> ??
>> On the contrary.
>> Projects can improve/evolve more rapidly when egos don't interfere.
>
> "Personally" != "ego".  People who take their jobs personally are the
> best ones I ever met.  Being emotional about your job is not a vice;
> on the contrary.

Taking well-intended technical suggestions as a personal attack
(and responding in kind) is counterproductive, no matter what you call it.

> But I _really_, REALLY don't want to start a sub-thread on this.
>
>> I find that people get a lot more real work done when they do not
>> interpret constructive criticism of their code as a personal attack.
>
> We are not talking about any criticism of my code.  The analogy is

We are talking about process restrictions that you want to continue
to impose on the code of all developers, solely for the sake of the
DOS port.  Paul has been patient and professional, constantly proposing
alternatives intended to ease the maintenance of the DOS port.  Yet,
you seem to reject each of those without giving him a chance.

> inappropriate.  There were no technical reasons for rejecting my
> simple original suggestion.  Only dogmatic arguments, whose intent is
> very clear: to resist any effort, even an infinitesimal one, on the
> Posix side, even if it imposes an unduly heavy burden on me and on the
> end users.  There's nothing between this and constructive criticism on
> the one hand, and "ego" on the other.

We're trying to minimize or eliminate your burden,
but you seem unwilling to consider the slightest change.

Re: RE : Re: Files from gnulib

[Eli Zaretskii]

> From: Jim Meyering <jim@meyering.net>
> Cc: sdl.web@gmail.com,  roucaries.bastien@gmail.com,  eggert@cs.ucla.edu,  bug-gnulib@gnu.org,  monnier@iro.umontreal.ca,  emacs-devel@gnu.org
> Date: Wed, 26 Jan 2011 14:09:39 +0100
> 
> Taking well-intended technical suggestions as a personal attack

It cannot be anything else, when "technical suggestions" boil down to
making the job of a fellow developer 1000 times harder for no good
technical reasons, just because of "oh no, not that again" kind of
irrationalities.  The attack could be unintended, but any reasonable
grown-up will realize that this is the result.

> We are talking about process restrictions that you want to continue
> to impose on the code of all developers

The restrictions are minuscule.  In my latest suggestion, rename only
3 *.m4 files, in a way that still keeps descriptive names.  I wonder
how much time will be wasted on bykeshedding that one.

> We're trying to minimize or eliminate your burden, but you seem
> unwilling to consider the slightest change.

I suggested a compromise solution a few hours ago, which does, I hope,
constitute a change, but have yet to see any response.

Re: Files from gnulib

[Ulrich Mueller]

>>>>> On Tue, 25 Jan 2011, Eli Zaretskii wrote:

>> Forcing current and future emacs development into the archaic 8.3
>> mold has a significant cost

> The costs are generally mine, and mine alone.

Unfortunately, that is not entirely true.

For example, most files of CEDET were renamed to 8+3 some time ago,
breaking other elisp packages (e.g. company-mode, ecb, jde, matlab,
speechd-el) depending on them.

Ulrich

Re: Files from gnulib

[Eli Zaretskii]

> Date: Tue, 25 Jan 2011 17:50:59 +0100
> From: Ulrich Mueller <ulm@gentoo.org>
> Cc: eggert@cs.ucla.edu, bug-gnulib@gnu.org, Jim Meyering <jim@meyering.net>,
> 	emacs-devel@gnu.org, monnier@iro.umontreal.ca, roucaries.bastien@gmail.com
> 
> For example, most files of CEDET were renamed to 8+3 some time ago,
> breaking other elisp packages (e.g. company-mode, ecb, jde, matlab,
> speechd-el) depending on them.

Reality check: there were many changes made in CEDET due to admission
into the Emacs distribution.  File-name changes were only a small part
of them, and the changes just moved some files into subdirectories,
such that foo-bar.el became foo/bar.el.

Re: Files from gnulib

[Ulrich Mueller]

>>>>> On Tue, 25 Jan 2011, Eli Zaretskii wrote:

>> For example, most files of CEDET were renamed to 8+3 some time ago,
>> breaking other elisp packages (e.g. company-mode, ecb, jde, matlab,
>> speechd-el) depending on them.

> Reality check: there were many changes made in CEDET due to admission
> into the Emacs distribution.  File-name changes were only a small part
> of them, and the changes just moved some files into subdirectories,
> such that foo-bar.el became foo/bar.el.

Which still breaks compatibility, because (require 'foo-bar) in any
elisp package will fail now.

Re: Files from gnulib

[Eli Zaretskii]

> Date: Tue, 25 Jan 2011 20:31:30 +0100
> From: Ulrich Mueller <ulm@gentoo.org>
> Cc: eggert@cs.ucla.edu, bug-gnulib@gnu.org, jim@meyering.net,
> 	emacs-devel@gnu.org, monnier@iro.umontreal.ca, roucaries.bastien@gmail.com
> 
> > Reality check: there were many changes made in CEDET due to admission
> > into the Emacs distribution.  File-name changes were only a small part
> > of them, and the changes just moved some files into subdirectories,
> > such that foo-bar.el became foo/bar.el.
> 
> Which still breaks compatibility, because (require 'foo-bar) in any
> elisp package will fail now.

And that was the single backward-incompatible change in CEDET?

Re: Files from gnulib

[Ulrich Mueller]

>>>>> On Tue, 25 Jan 2011, Eli Zaretskii wrote:

>> > Reality check: there were many changes made in CEDET due to admission
>> > into the Emacs distribution.  File-name changes were only a small part
>> > of them, and the changes just moved some files into subdirectories,
>> > such that foo-bar.el became foo/bar.el.
>> 
>> Which still breaks compatibility, because (require 'foo-bar) in any
>> elisp package will fail now.

> And that was the single backward-incompatible change in CEDET?

No, but your original statement was: "The costs are generally mine,
and mine alone."

These renamed files have to be taken account for in all packages using
CEDET, and that means additional work for the upstreams of these
packages and for distro builders. Therefore, at least in the case of
CEDET, the costs are not yours alone.

Re: Files from gnulib

[Eli Zaretskii]

> Date: Tue, 25 Jan 2011 21:00:16 +0100
> Cc: eggert@cs.ucla.edu, bug-gnulib@gnu.org, jim@meyering.net,
>         emacs-devel@gnu.org, monnier@iro.umontreal.ca,
>         roucaries.bastien@gmail.com
> From: Ulrich Mueller <ulm@gentoo.org>
> 
> >>>>> On Tue, 25 Jan 2011, Eli Zaretskii wrote:
> 
> >> > Reality check: there were many changes made in CEDET due to admission
> >> > into the Emacs distribution.  File-name changes were only a small part
> >> > of them, and the changes just moved some files into subdirectories,
> >> > such that foo-bar.el became foo/bar.el.
> >> 
> >> Which still breaks compatibility, because (require 'foo-bar) in any
> >> elisp package will fail now.
> 
> > And that was the single backward-incompatible change in CEDET?
> 
> No, but your original statement was: "The costs are generally mine,
> and mine alone."

The word "generally" is there for a reason.

Re: Files from gnulib

[Óscar Fuentes]

Eli Zaretskii <eliz@gnu.org> writes:

>> For example, most files of CEDET were renamed to 8+3 some time ago,
>> breaking other elisp packages (e.g. company-mode, ecb, jde, matlab,
>> speechd-el) depending on them.
>
> Reality check: there were many changes made in CEDET due to admission
> into the Emacs distribution.  File-name changes were only a small part
> of them, and the changes just moved some files into subdirectories,
> such that foo-bar.el became foo/bar.el.

Those changes were a burden the day I tried to use an external package
which adds CEDET-based C# code completion to Emacs. I thought that as
the supposedly difficult part of installing CEDET was already done
thanks to its integration into the Emacs distribution, applying the
simple instructions for adding the C# package would be a piece of
cake. But soon discovered that the instructions and the .el file
referenced several files that apparently were missing from Emacs. After
some investigation I learned that those files were moved. It was not fun
to locate each file and patch the external package. Moving the files
will cause extra work to those who maintain external CEDET packages, so
they must introduce changes for supporting the new places while keeping
compatibility with the old ones.

This is just to demonstrate that the 8+3 issue is not as irrelevant as
you say. That said, I'm glad that the DOS port provides motivation for
keeping you as an Emacs maintainer, some renaming from time to time is a
little price to pay for that.

Re: Files from gnulib

[Eli Zaretskii]

> From: Óscar Fuentes <ofv@wanadoo.es>
> Cc: Ulrich Mueller <ulm@gentoo.org>,  eggert@cs.ucla.edu,  jim@meyering.net,  emacs-devel@gnu.org,  monnier@iro.umontreal.ca,  roucaries.bastien@gmail.com
> Date: Tue, 25 Jan 2011 20:52:22 +0100
> 
> This is just to demonstrate that the 8+3 issue is not as irrelevant as
> you say.

Well, I didn't really mean to say they were irrelevant, just that they
are not as significant as this thread seems to indicate.

> That said, I'm glad that the DOS port provides motivation for
> keeping you as an Emacs maintainer, some renaming from time to time is a
> little price to pay for that.

Thank you for your kind words.

Re: Files from gnulib

[Stefan Monnier]

> For example, most files of CEDET were renamed to 8+3 some time ago,
> breaking other elisp packages (e.g. company-mode, ecb, jde, matlab,
> speechd-el) depending on them.

Indeed the CEDET renaming was (and still is) a source of problems
because there is still an "upstream" that hasn't done the same renaming
yet (or has been done, finally?).
But in this particular case, I'd argue that the restructuring was for
the better.

This said, I'd be happy if we could solve the 8+3 issue differently.
Eli, what do you think of Paul's suggestion to use

  "djtar -n emacs-25.chg emacs-25.tgz"


-- Stefan

Re: Files from gnulib

[Eli Zaretskii]

> From: Stefan Monnier <monnier@IRO.UMontreal.CA>
> Cc: Eli Zaretskii <eliz@gnu.org>, eggert@cs.ucla.edu, bug-gnulib@gnu.org,
>         Jim Meyering <jim@meyering.net>, emacs-devel@gnu.org,
>         roucaries.bastien@gmail.com
> Date: Tue, 25 Jan 2011 14:04:44 -0500
> 
> This said, I'd be happy if we could solve the 8+3 issue differently.

I will go with any solution that does not unduly increases the burden
and does not involve tedious manual work down the line.  For now, the
only alternatives I heard more or less told me to go screw myself.

> Eli, what do you think of Paul's suggestion to use
> 
>   "djtar -n emacs-25.chg emacs-25.tgz"

I already replied: this kind of scheme is used by GDB, and it works
very badly.  I don't want to go that way in Emacs.

Re: Files from gnulib

[Bastien ROUCARIES]

Le mardi 25 janvier 2011 16:33:40, Eli Zaretskii a écrit :
> 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?
> 
> > 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.
> 
> > 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.
A quick search on google show that doslfn is used by DJGPP user. 

Moreover, instead of fixing bugs in source package, it will allow a final fix for dos. And instead of renaming and thus using your 
time doing every time the same stuff, you could fix the doslfn package is buggy. If fixed once, it will definitvly fix the 8.3 problem 
(if and only if doslfn is buggy, and it does not seems according to a quick search).

Bastien

Re: Files from gnulib

[Eli Zaretskii]

> From: Bastien ROUCARIES <roucaries.bastien@gmail.com>
> Date: Tue, 25 Jan 2011 23:37:08 +0100
> Cc: Jim Meyering <jim@meyering.net>,
>  eggert@cs.ucla.edu,
>  bug-gnulib@gnu.org,
>  monnier@iro.umontreal.ca,
>  emacs-devel@gnu.org
> 
> (if and only if doslfn is buggy, and it does not seems according to a quick search).

Your search was too quick.

Re: Files from gnulib

[Jim Meyering]

Eli Zaretskii wrote:
>> From: Bastien ROUCARIES <roucaries.bastien@gmail.com>
>> Date: Tue, 25 Jan 2011 23:37:08 +0100
>>
>> (if and only if doslfn is buggy, and it does not seems according to
>> a quick search).
>
> Your search was too quick.

Considering your wish to continue supporting emacs on DOS,
I would have thought you would jump at a possible solution like this.
If it works (and indications are that it does), then it defines
away the whole problem.  Wouldn't you welcome the idea of a DOS
port with no risk of 8.3 collisions?

What if the solution really is as easy as it appears?  Here is a
recently-updated FAQ:

    http://www-user.tu-chemnitz.de/~heha/hs_freeware/what_lfn.htm.en

Please give it an honest try before dismissing it.

Just because someone wrote about a problem does not
mean using it to build Emacs will trigger the same one.
And even if it does, report it nicely and someone might
even fix it right away.

Re: Files from gnulib

[Bastien ROUCARIES]

Le mercredi 26 janvier 2011 12:02:47, Jim Meyering a écrit :
> Eli Zaretskii wrote:
> >> From: Bastien ROUCARIES <roucaries.bastien@gmail.com>
> >> Date: Tue, 25 Jan 2011 23:37:08 +0100
> >> 
> >> (if and only if doslfn is buggy, and it does not seems according to
> >> a quick search).
> > 
> > Your search was too quick.
> 
> Considering your wish to continue supporting emacs on DOS,
> I would have thought you would jump at a possible solution like this.
> If it works (and indications are that it does), then it defines
> away the whole problem. 

Know bug list is pretty short note

> Wouldn't you welcome the idea of a DOS
> port with no risk of 8.3 collisions?
> 
> What if the solution really is as easy as it appears?  Here is a
> recently-updated FAQ:
> 
>     http://www-user.tu-chemnitz.de/~heha/hs_freeware/what_lfn.htm.en
> 
> Please give it an honest try before dismissing it.
> 
> Just because someone wrote about a problem does not
> mean using it to build Emacs will trigger the same one.
> And even if it does, report it nicely and someone might
> even fix it right away.

Moreover freedos seems to use routinly doslfn. So it is a least a little bit tested.

Bastien

Re: Files from gnulib

[Bastien ROUCARIES]

Le mercredi 26 janvier 2011 12:52:33, Bastien ROUCARIES a écrit :
> Le mercredi 26 janvier 2011 12:02:47, Jim Meyering a écrit :
> > Eli Zaretskii wrote:
> > >> From: Bastien ROUCARIES <roucaries.bastien@gmail.com>
> > >> Date: Tue, 25 Jan 2011 23:37:08 +0100
> > >> 
> > >> (if and only if doslfn is buggy, and it does not seems according to
> > >> a quick search).
> > > 
> > > Your search was too quick.
> > 
> > Considering your wish to continue supporting emacs on DOS,
> > I would have thought you would jump at a possible solution like this.
> > If it works (and indications are that it does), then it defines
> > away the whole problem.
> 
> Know bug list is pretty short note
> 
> > Wouldn't you welcome the idea of a DOS
> > port with no risk of 8.3 collisions?
> > 
> > What if the solution really is as easy as it appears?  Here is a
> > 
> > recently-updated FAQ:
> >     http://www-user.tu-chemnitz.de/~heha/hs_freeware/what_lfn.htm.en
> > 
> > Please give it an honest try before dismissing it.
> > 
> > Just because someone wrote about a problem does not
> > mean using it to build Emacs will trigger the same one.
> > And even if it does, report it nicely and someone might
> > even fix it right away.
> 
> Moreover freedos seems to use routinly doslfn. So it is a least a little
> bit tested.
and used by 4dos one of the most usuable dos file manager
http://4dos.isgreat.org

Bastien

Re: Files from gnulib

[Eli Zaretskii]

> From: Bastien ROUCARIES <roucaries.bastien@gmail.com>
> Date: Wed, 26 Jan 2011 12:52:33 +0100
> Cc: Eli Zaretskii <eliz@gnu.org>,
>  emacs-devel@gnu.org,
>  eggert@cs.ucla.edu,
>  bug-gnulib@gnu.org,
>  monnier@iro.umontreal.ca
> 
> Moreover freedos seems to use routinly doslfn. So it is a least a
> little bit tested.

FreeDOS has known issues with DJGPP.

Re: Files from gnulib

[Eli Zaretskii]

> From: Jim Meyering <jim@meyering.net>
> Cc: Bastien ROUCARIES <roucaries.bastien@gmail.com>,  emacs-devel@gnu.org,  eggert@cs.ucla.edu,  bug-gnulib@gnu.org,  monnier@iro.umontreal.ca
> Date: Wed, 26 Jan 2011 12:02:47 +0100
> 
> Eli Zaretskii wrote:
> >> From: Bastien ROUCARIES <roucaries.bastien@gmail.com>
> >> Date: Tue, 25 Jan 2011 23:37:08 +0100
> >>
> >> (if and only if doslfn is buggy, and it does not seems according to
> >> a quick search).
> >
> > Your search was too quick.
> 
> Considering your wish to continue supporting emacs on DOS,
> I would have thought you would jump at a possible solution like this.

The solution would need to be rock solid, for me to jump at it.  DJGPP
is very stable on plain DOS, and its users expect stability.

>     http://www-user.tu-chemnitz.de/~heha/hs_freeware/what_lfn.htm.en
> 
> Please give it an honest try before dismissing it.

It obviously has problems with protected-mode programs and
environments, and with DOS extenders.  DJGPP programs switch the
machine to 32-bit protected mode, so any programs that have
difficulties with that environment are not promising.  And the fact
that DJGPP is not mentioned as a solution for DOS programs that
support LFN does not help to remove the cloud.

Re: Files from gnulib

[Bastien ROUCARIES]

> > Considering your wish to continue supporting emacs on DOS,
> > I would have thought you would jump at a possible solution like this.
> 
> The solution would need to be rock solid, for me to jump at it.  DJGPP
> is very stable on plain DOS, and its users expect stability.
> 
> >     http://www-user.tu-chemnitz.de/~heha/hs_freeware/what_lfn.htm.en
> > 
> > Please give it an honest try before dismissing it.
> 
> It obviously has problems with protected-mode programs and
> environments, and with DOS extenders.  DJGPP programs switch the
> machine to 32-bit protected mode, so any programs that have
> difficulties with that environment are not promising.  And the fact
> that DJGPP is not mentioned as a solution for DOS programs that
> support LFN does not help to remove the cloud.

according to http://www.delorie.com/djgpp/doc/kb/kb_10.html
"The DJGPP library features transparent and automatic support for long file names on Windows 9X(1) The DJGPP startup code queries 
the system for the availability of the LFN API, and if it's available, all low-level file-oriented primitives are automatically 
switched to using the special LFN-aware functions. This run-time detection of the LFN support means that the same executable will 
run on DOS and on Windows, and will automatically support long file names when it runs on Windows 9X"

They are a faq entry on lfn:
http://www.delorie.com/djgpp/v2faq/faq22_16.html
And it seems that lfn is supported since djgpp 2.01 so since October 19, 1996.

according to 
http://www.unet.univie.ac.at/~a0503736/php/drdoswiki/index.php?n=Main.DevelCppBeginners
It could be used under drdos and with djgpp

I agree with you about bug but they seems minor like this
http://permalink.gmane.org/gmane.comp.emulators.freedos.kernel/1372
and could be fixed

doslfn is moreover well supported due to adoption of win95 even on fat12. 

Therefore since 2001 (creation of doslfn), 8.3 name problem should not exist. 

Instead of tackling the main problem lack of 8.3 support and use the new api, you are stick in the 90's. 

Thanks 

Bastien

Re: Files from gnulib

[Eli Zaretskii]

> From: Bastien ROUCARIES <roucaries.bastien@gmail.com>
> Date: Wed, 26 Jan 2011 14:33:54 +0100
> Cc: Jim Meyering <jim@meyering.net>,
>  emacs-devel@gnu.org,
>  eggert@cs.ucla.edu,
>  bug-gnulib@gnu.org,
>  monnier@iro.umontreal.ca
> 
> according to http://www.delorie.com/djgpp/doc/kb/kb_10.html
> "The DJGPP library features transparent and automatic support for long file names on Windows 9X(1) The DJGPP startup code queries 
> the system for the availability of the LFN API, and if it's available, all low-level file-oriented primitives are automatically 
> switched to using the special LFN-aware functions. This run-time detection of the LFN support means that the same executable will 
> run on DOS and on Windows, and will automatically support long file names when it runs on Windows 9X"

Yes, I know.  I wrote some of those "low-level file-oriented primitives".

> They are a faq entry on lfn:
> http://www.delorie.com/djgpp/v2faq/faq22_16.html

Did you see who wrote that FAQ?

> And it seems that lfn is supported since djgpp 2.01 so since October 19, 1996.

That's not the issue, you misunderstood my comment.  The issue is that
DJGPP programs switch the CPU to 32-bit protected mode, and use a DPMI
server to issue real-mode DOS and BIOS system calls from protected
mode.  doslfn seems to have problems with such programs (which is not
surprising, since any TSR that hooks interrupts might have problems in
protected mode).

Re: Files from gnulib

[Bastien ROUCARIES]

Le mercredi 26 janvier 2011 14:48:18, Eli Zaretskii a écrit :
> > "The DJGPP library features transparent and automatic support for long
> > file names on Windows 9X(1) The DJGPP startup code queries the system
> > for the availability of the LFN API, and if it's available, all
> > low-level file-oriented primitives are automatically switched to using
> > the special LFN-aware functions. This run-time detection of the LFN
> > support means that the same executable will run on DOS and on Windows,
> > and will automatically support long file names when it runs on Windows
> > 9X"
> 
> Yes, I know.  I wrote some of those "low-level file-oriented primitives".
>
> > They are a faq entry on lfn:
> > http://www.delorie.com/djgpp/v2faq/faq22_16.html
> 
> Did you see who wrote that FAQ?

Yes you :)

> > And it seems that lfn is supported since djgpp 2.01 so since October 19,
> > 1996.
> 
> That's not the issue, you misunderstood my comment.  The issue is that
> DJGPP programs switch the CPU to 32-bit protected mode, and use a DPMI
> server to issue real-mode DOS and BIOS system calls from protected
> mode.  doslfn seems to have problems with such programs (which is not
> surprising, since any TSR that hooks interrupts might have problems in
> protected mode).

This is the real bug, and I suppose "might have problems" means this bug could be fixed. 

And do not talk about bare metal. DPMI is not bare metal dos*. So we could add another layer, that is doslfn in order to compile 
emacs...

Bastien

* at least in my sense

Re: Files from gnulib

[Eli Zaretskii]

> From: Bastien ROUCARIES <roucaries.bastien@gmail.com>
> Date: Wed, 26 Jan 2011 16:26:05 +0100
> Cc: jim@meyering.net,
>  emacs-devel@gnu.org,
>  eggert@cs.ucla.edu,
>  bug-gnulib@gnu.org,
>  monnier@iro.umontreal.ca
> 
> And do not talk about bare metal. DPMI is not bare metal dos*.

Yes, it is, because DJGPP includes a DPMI host in its development kit,
and each DJGPP program (including Emacs) loads that DPMI host into
memory if it is not already there at startup time.  So you only need a
plain stock DOS system to run DJGPP.

Re: Files from gnulib

[Bastien ROUCARIES]

Le mercredi 26 janvier 2011 16:46:29, Eli Zaretskii a écrit :
> > From: Bastien ROUCARIES <roucaries.bastien@gmail.com>
> > Date: Wed, 26 Jan 2011 16:26:05 +0100
> > Cc: jim@meyering.net,
> > 
> >  emacs-devel@gnu.org,
> >  eggert@cs.ucla.edu,
> >  bug-gnulib@gnu.org,
> >  monnier@iro.umontreal.ca
> > 
> > And do not talk about bare metal. DPMI is not bare metal dos*.
> 
> Yes, it is, because DJGPP includes a DPMI host in its development kit,
> and each DJGPP program (including Emacs) loads that DPMI host into
> memory if it is not already there at startup time.  So you only need a
> plain stock DOS system to run DJGPP.

For sure and why not supply a doslfn module (fixed) in djgpp ? 

And you do not answer about:
>This is the real bug, and I suppose "might have problems" means this bug could be fixed. 
I suppose the problem could be fixed because some scsi disk/network disk of this era use tsr and could be browsed from dpmi mode.

Bastien

Re: Files from gnulib

[Eli Zaretskii]

> From: Bastien ROUCARIES <roucaries.bastien@gmail.com>
> Date: Wed, 26 Jan 2011 16:57:10 +0100
> Cc: jim@meyering.net,
>  emacs-devel@gnu.org,
>  eggert@cs.ucla.edu,
>  bug-gnulib@gnu.org,
>  monnier@iro.umontreal.ca
> 
> why not supply a doslfn module (fixed) in djgpp ? 

Because DJGPP has seen its last release 8.5 years ago, and will not
see another one.  Its development is finished.  (There are a couple of
enthusiasts who still work on development, but the development code
will never leave the alpha status, for lack of heavy users to test it
well enough for it to get to release quality.)

> And you do not answer about:
> >This is the real bug, and I suppose "might have problems" means this bug could be fixed. 
> I suppose the problem could be fixed because some scsi disk/network disk of this era use tsr and could be browsed from dpmi mode.

I doubt we will find someone to fix that.

Re: Files from gnulib

[Andy Moreton]

On Wed 26 Jan 2011, Bastien ROUCARIES wrote:

> Therefore since 2001 (creation of doslfn), 8.3 name problem should not
> exist.
>
> Instead of tackling the main problem lack of 8.3 support and use the
> new api, you are stick in the 90's.

It seems odd to me that the developers of a GNU library fight so
hard to avoid their code being portable. The gnulib manual [1] says:

  Gnulib is useful to enhance various aspects of a package:

    * Portability: With Gnulib, a package maintainer can program
      against the POSIX and GNU libc APIs and nevertheless expect good
      portability to platforms that don't implement POSIX.

    * Maintainability: When a package uses modules from Gnulib instead
      of code written specifically for that package, the maintainer has
      less code to maintain.

It seems that manual promotes exactly the features that Eli needs.

    AndyM


[1] http://www.gnu.org/software/gnulib/manual/html_node/Benefits.html#Benefits

Re: Files from gnulib

[Bastien ROUCARIES]

Le mercredi 26 janvier 2011 15:35:52, Andy Moreton a écrit :
> On Wed 26 Jan 2011, Bastien ROUCARIES wrote:
> > Therefore since 2001 (creation of doslfn), 8.3 name problem should not
> > exist.
> > 
> > Instead of tackling the main problem lack of 8.3 support and use the
> > new api, you are stick in the 90's.
> 
> It seems odd to me that the developers of a GNU library fight so
> hard to avoid their code being portable. The gnulib manual [1] says:
> 
>   Gnulib is useful to enhance various aspects of a package:
> 
>     * Portability: With Gnulib, a package maintainer can program
>       against the POSIX and GNU libc APIs and nevertheless expect good
>       portability to platforms that don't implement POSIX.
> 
>     * Maintainability: When a package uses modules from Gnulib instead
>       of code written specifically for that package, the maintainer has
>       less code to maintain.
> 
> It seems that manual promotes exactly the features that Eli needs.
> 
>     AndyM

8.3 limitation is really of another age, and could be lifted on dos is doslfn is fixed. DJGPP need dpmi adding a prerequist of 
doslfn is not so hard in order to compile (not run) emacs.

Bastien

Re: Files from gnulib

[Miles Bader]

Bastien ROUCARIES <roucaries.bastien@gmail.com> writes:
>> It seems odd to me that the developers of a GNU library fight so
>> hard to avoid their code being portable. The gnulib manual [1] says:
>
> 8.3 limitation is really of another age, and could be lifted on dos is
> doslfn is fixed. DJGPP need dpmi adding a prerequist of
> doslfn is not so hard in order to compile (not run) emacs.

Indeed:  "portability" is a good goal in general, but it's a vague word.
There are obviously points at which it can be taken too far, where the
benefit isn't enough to justify the effort required and resulting
obfuscation of the code base.

Where these points are, of course, shifts over time.

[E.g., the once fairly widespread goal of supporting pre-ANSI C
compilers seems to have been largely abandoned these days.]

I'm not saying MSDOS has reached that point yet, just that a goal of
"portability" needs to be judged in the appropriate context.

-miles

-- 
Joy, n. An emotion variously excited, but in its highest degree arising from
the contemplation of grief in another.

Re: Files from gnulib

[Eli Zaretskii]

> From: Bastien ROUCARIES <roucaries.bastien@gmail.com>
> Date: Wed, 26 Jan 2011 16:31:04 +0100
> Cc: Andy Moreton <andrewjmoreton@gmail.com>, emacs-devel@gnu.org
> 
> DJGPP need dpmi adding a prerequist of doslfn is not so hard in
> order to compile (not run) emacs.

Not true.  Once we allow any clashes of file names anywhere in Emacs,
soon enough we will have them in the Lisp files, and then LFNs will be
a necessity for Emacs to run as well, not just to be built.

Re: Files from gnulib

[Simon Josefsson]

Andy Moreton <andrewjmoreton@gmail.com> writes:

> On Wed 26 Jan 2011, Bastien ROUCARIES wrote:
>
>> Therefore since 2001 (creation of doslfn), 8.3 name problem should not
>> exist.
>>
>> Instead of tackling the main problem lack of 8.3 support and use the
>> new api, you are stick in the 90's.
>
> It seems odd to me that the developers of a GNU library fight so
> hard to avoid their code being portable. The gnulib manual [1] says:
>
>   Gnulib is useful to enhance various aspects of a package:
>
>     * Portability: With Gnulib, a package maintainer can program
>       against the POSIX and GNU libc APIs and nevertheless expect good
>       portability to platforms that don't implement POSIX.
>
>     * Maintainability: When a package uses modules from Gnulib instead
>       of code written specifically for that package, the maintainer has
>       less code to maintain.
>
> It seems that manual promotes exactly the features that Eli needs.

This could probably be clarified in the gnulib manual, but my impression
is that gnulib has always been agreesive about abandoning support for
platforms that are not commercially supported and that we can't access
and test patches on.  For example, I believe SunOS 4 falls into this
category.

/Simon

Re: Files from gnulib

[Paul Eggert]

On 01/27/2011 02:54 AM, Simon Josefsson wrote:

> my impression is that gnulib has always been agreesive about
> abandoning support for platforms that are not commercially supported
> and that we can't access and test patches on.

I'm not sure what "aggressive" means, but the general rule is that we
try not to waste resources maintaining code that cannot easily be
tested and that increases the maintenance burden for ordinary
development.  Another way of putting it is, if the original platform
distributor no longer supports something, that's a good indication
that we shouldn't bother either, as it indicates that the audience is
too small to be worth committing our scarce resources to.

> For example, I believe SunOS 4 falls into this category.

SunOS 4 is still documented as being a target, though this
may change as per the above.  I personally haven't used
SunOS 4 in years; has anyone else?

> This could probably be clarified in the gnulib manual

Here's what it currently says.  Can you suggest which
clarifications would be helpful?

   Originally much of the Gnulib code was portable to ancient hosts like
   4.2BSD, but it is a maintenance hassle to maintain compatibility with
   unused hosts, so currently we assume at least a freestanding C89
   compiler, possibly operating with a C library that predates C89.  The
   oldest environment currently ported to is probably SunOS 4 + GCC 1.x,
   though we haven't tested this exact combination.  SunOS 4 last shipped
   on 1998-09-30, and Sun dropped support for it on 2003-10-01, so at
   some point we may start assuming a C89 library as well.

   ...

   Even if the include files conform to C89, the library itself may not.
   For example, SunOS 4's (free (NULL)) can dump core, so Gnulib code
   must avoid freeing a null pointer, even though C89 allows it.
   You can work around some of these problems by requiring the relevant
   modules, e.g., the Gnulib 'free' module supplies a conforming 'free'.

Re: Files from gnulib

[Bastien ROUCARIES]

[sorry for retrieving this old thread]
On Wed, Jan 26, 2011 at 1:02 PM, Jim Meyering <jim@meyering.net> wrote:
> Eli Zaretskii wrote:
>>> From: Bastien ROUCARIES <roucaries.bastien@gmail.com>
>>> Date: Tue, 25 Jan 2011 23:37:08 +0100
>>>
>>> (if and only if doslfn is buggy, and it does not seems according to
>>> a quick search).
>>
>> Your search was too quick.
>
> Considering your wish to continue supporting emacs on DOS,
> I would have thought you would jump at a possible solution like this.
> If it works (and indications are that it does), then it defines
> away the whole problem.  Wouldn't you welcome the idea of a DOS
> port with no risk of 8.3 collisions?
>
> What if the solution really is as easy as it appears?  Here is a
> recently-updated FAQ:
>
>     http://www-user.tu-chemnitz.de/~heha/hs_freeware/what_lfn.htm.en
>
> Please give it an honest try before dismissing it

Moreover doslfn is activelly maintened. The upsteam release a new
version in february. (http://adoxa.3eeweb.com/doslfn/), so time to
drop 8.3 limitation  in emacs build ?

Bastien

Re: Files from gnulib

[Eli Zaretskii]

> Date: Thu, 23 Aug 2012 13:36:16 +0200
> From: Bastien ROUCARIES <roucaries.bastien@gmail.com>
> Cc: Eli Zaretskii <eliz@gnu.org>, emacs-devel@gnu.org, eggert@cs.ucla.edu, 
> 	bug-gnulib@gnu.org, monnier@iro.umontreal.ca
> 
> [sorry for retrieving this old thread]

I suggest to let the sleeping dogs lie.

Re: RE : Re: Files from gnulib

[Leo]

On 2011-01-25 22:51 +0800, Jim Meyering wrote:
> Forcing current and future emacs development into the archaic 8.3 mold has
> a significant cost (just look at how long this thread is), yet provides
> relatively little benefit.

I also think it is insane, the 8+3 thing. It is a huge burden evidenced
by loads of weirdly-named files in the repo.

Leo

-- 
Oracle is the new evil

Re: RE : Re: Files from gnulib

[Miles Bader]

Leo <sdl.web@gmail.com> writes:
>> Forcing current and future emacs development into the archaic 8.3 mold has
>> a significant cost (just look at how long this thread is), yet provides
>> relatively little benefit.
>
> I also think it is insane, the 8+3 thing. It is a huge burden evidenced
> by loads of weirdly-named files in the repo.

I don't know whether to call it a "huge" burden, but it is clearly a burden.

I wonder if there are actually any users...

-Miles

-- 
Egotist, n. A person of low taste, more interested in himself than in me.

Re: RE : Re: Files from gnulib

[Stephen J. Turnbull]

Miles Bader writes:

 > I wonder if there are actually any users [of DJGPP Emacs] ...

Yes, there are; Eli gets at least one or two messages of thanks for
every release.  If you want a count, I'd suggest asking on the DJGPP
list.

Re: RE : Re: Files from gnulib

[Dan Nicolaescu]

Miles Bader <miles@gnu.org> writes:

> Leo <sdl.web@gmail.com> writes:
>>> Forcing current and future emacs development into the archaic 8.3 mold has
>>> a significant cost (just look at how long this thread is), yet provides
>>> relatively little benefit.
>>
>> I also think it is insane, the 8+3 thing. It is a huge burden evidenced
>> by loads of weirdly-named files in the repo.
>
> I don't know whether to call it a "huge" burden, but it is clearly a burden.
>
> I wonder if there are actually any users...

When we removed support for a lot of old systems 3 years ago MSDOS was
on the list of systems to be removed, nobody claimed to still use
Emacs on that platform.
Since then, there was a single user that said that he still used it.

Re: RE : Re: Files from gnulib

[Stefan Monnier]

> When we removed support for a lot of old systems 3 years ago MSDOS was
> on the list of systems to be removed, nobody claimed to still use
> Emacs on that platform.
> Since then, there was a single user that said that he still used it.

MS-DOS nowadays is a pretty special niche, so I'm not surprised we don't
hear from them much here.


        Stefan

Re: RE : Re: Files from gnulib

[Dan Nicolaescu]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> When we removed support for a lot of old systems 3 years ago MSDOS was
>> on the list of systems to be removed, nobody claimed to still use
>> Emacs on that platform.
>> Since then, there was a single user that said that he still used it.
>
> MS-DOS nowadays is a pretty special niche, so I'm not surprised we don't
> hear from them much here.

At what point can we say that this pretty special niche is served well
enough by emacs-2X.Y, so that we don't need to support it in new releases?

Re: RE : Re: Files from gnulib

[Eli Zaretskii]

> From: Leo <sdl.web@gmail.com>
> Date: Wed, 26 Jan 2011 00:03:18 +0800
> Cc: bug-gnulib@gnu.org
> 
> I also think it is insane, the 8+3 thing. It is a huge burden evidenced
> by loads of weirdly-named files in the repo.

What on Earth are you talking about? what "loads" of which
"weirdly-named" files do you mean?  And how is that related to this
discussion?  The number of times I asked for renaming files was quite
small, so if there are "loads" of files that annoy you, MSDOS
compatibility is not the reason.