Emacs vista build failures

Emacs vista build failures

[Eric Hanchrow]

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

I tried building a very recent version of emacs from CVS (actually
from the git mirror at git://git.sv.gnu.org/emacs.git) on Vista, and
it fails as you can see in the attachment.  The very same commit
builds and runs fine on XP.  Any idea what's wrong?  I started with a
very clean directory, by which I mean: I ran "git-clean -dxf", which
deletes all files that aren't known to git; and I ran "git status" to
ensure that all of the remaining files were identical to their
versions in the repository.
The executive summary is:
    Compiling gnus/nnvirtual.el

    In toplevel form:
    gnus/nnvirtual.el:34:1:Error: Symbol's value as variable is void:
\300\214\300\214

... and many similar mysterious errors during byte-compilation.

[-- Attachment #2: build-failures.gz --]
[-- Type: application/x-gzip, Size: 28681 bytes --]

Re: Emacs vista build failures

[Richard M Stallman]

    I tried building a very recent version of emacs from CVS (actually
    from the git mirror at git://git.sv.gnu.org/emacs.git) on Vista,

My condolences.  See BadVista.org.

Re: Emacs vista build failures

[David Robinow]

On Fri, Jul 11, 2008 at 12:49 PM, Richard M Stallman <rms@gnu.org> wrote:
>    I tried building a very recent version of emacs from CVS (actually
>    from the git mirror at git://git.sv.gnu.org/emacs.git) on Vista,
>
> My condolences.  See BadVista.org.
 This comment is not helpful.

I build emacs on Vista frequently. I use cygwin cvs and Mingw gcc.
Perhaps there's a problem with git?

Re: Emacs vista build failures

[Richard M Stallman]

    > My condolences.  See BadVista.org.
     This comment is not helpful.

On the contrary, steering some people away from Vista
could potentially be of tremendous help to them.

Re: Emacs vista build failures

[David Kastrup]

Richard M Stallman <rms@gnu.org> writes:

>     > My condolences.  See BadVista.org.
>      This comment is not helpful.
>
> On the contrary, steering some people away from Vista
> could potentially be of tremendous help to them.

An Emacs that does not compile will not steer people away from Vista
since it fails to give them the taste of freedom.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Emacs vista build failures

[Richard M Stallman]

    > On the contrary, steering some people away from Vista
    > could potentially be of tremendous help to them.

    An Emacs that does not compile will not steer people away from Vista
    since it fails to give them the taste of freedom.

The question was whether my message was helpful,
not whether the bug in Emacs is helpful.

Re: Emacs vista build failures

[David Kastrup]

Richard M Stallman <rms@gnu.org> writes:

>     > On the contrary, steering some people away from Vista
>     > could potentially be of tremendous help to them.
>
>     An Emacs that does not compile will not steer people away from
>     Vista since it fails to give them the taste of freedom.
>
> The question was whether my message was helpful,
> not whether the bug in Emacs is helpful.

I should think the kind of people desirous of being steered rarely ends
up at our doorstep.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Emacs vista build failures

[Richard M Stallman]

    I should think the kind of people desirous of being steered rarely ends
    up at our doorstep.

I doubt there is anyone so firm of will and so sure of his views
that he is never influenced by the views he hears presented by others.
Our words always tend to influence people, by what they
take for granted as well as what they say.  That is why we
should not take for granted that people use non-free software,
or that they should.

Re: Emacs vista build failures

[David Kastrup]

Richard M Stallman <rms@gnu.org> writes:

>     I should think the kind of people desirous of being steered rarely ends
>     up at our doorstep.
>
> I doubt there is anyone so firm of will and so sure of his views
> that he is never influenced by the views he hears presented by others.
> Our words always tend to influence people, by what they
> take for granted as well as what they say.  That is why we
> should not take for granted that people use non-free software,
> or that they should.

I think you are missing my point.  Those people likely to be on our side
are probably not best recruited by pontification and patronization.
They can have that where they are coming from.

We have something to offer them, not something to take from them.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Emacs vista build failures

[Richard M Stallman]

    I think you are missing my point.  Those people likely to be on our side
    are probably not best recruited by pontification and patronization.

Aside from your namecalling, you have missed my point.  If we talk
about using Windows as if to take for granted that it's ok, we
influence people by our silence.  We can even influence ourselves
that way.

Every so often it is necessary to recall this, so as to prevent that
negative influence.

Mentioning this issue can also be useful to educate people who use
Emacs for practical reasons only, and are not in the habit of thinking
about the issue of their own freedom as software users.

Re: Emacs vista build failures

[David Robinow]

On Fri, Jul 11, 2008 at 12:49 PM, Richard M Stallman <rms@gnu.org> wrote:
>    I tried building a very recent version of emacs from CVS (actually
>    from the git mirror at git://git.sv.gnu.org/emacs.git) on Vista,
>
> My condolences.  See BadVista.org.
 This comment is not helpful.

I build emacs on Vista frequently. I use cygwin cvs and Mingw gcc.
Perhaps there's a problem with git?

Re: Emacs vista build failures

[Miles Bader]

"David Robinow" <drobinow@gmail.com> writes:
>> My condolences.  See BadVista.org.
>
>  This comment is not helpful.

It would be helpful (for both you and the world at large) if it caused
you to abandon vista and give MS the boot once and for all -- and who
knows ...

-Miles

-- 
We have met the enemy, and he is us.  -- Pogo

Re: Emacs vista build failures

[David Robinow]

On Fri, Jul 11, 2008 at 4:39 PM, Miles Bader <miles@gnu.org> wrote:
> "David Robinow" <drobinow@gmail.com> writes:
>>> My condolences.  See BadVista.org.
>>
>>  This comment is not helpful.
>
> It would be helpful (for both you and the world at large) if it caused
> you to abandon vista and give MS the boot once and for all -- and who
> knows ...
>
> -Miles
I've tried several linux distributions. I've never managed to get an
internet connection.
I prefer a solution that works.

Re: Emacs vista build failures

[Lennart Borgman (gmail)]

David Robinow wrote:
> On Fri, Jul 11, 2008 at 4:39 PM, Miles Bader <miles@gnu.org> wrote:
>> "David Robinow" <drobinow@gmail.com> writes:
>>>> My condolences.  See BadVista.org.
>>>  This comment is not helpful.
>> It would be helpful (for both you and the world at large) if it caused
>> you to abandon vista and give MS the boot once and for all -- and who
>> knows ...
>>
>> -Miles

> I've tried several linux distributions. I've never managed to get an
> internet connection.
> I prefer a solution that works.

My impression is that GNU/Linux has improved very much, maybe 
escpecially with the birth of the Ubuntu distribution. I do not run it 
myself, but will as soon as I find time.

The crucial point IMO is letting go of the "we are best" attitude. I 
know of a try 20 years ago where a site at a rather big company really 
did its best to try out unix on the desktops. Several contacts were made 
with the unix vendors. They all responded "we are best and will win the 
market". I think if they had listened and understood the problems faced 
by potential customers the situation might have been totally different 
today.

Re: Emacs vista build failures

[Richard M Stallman]

    The crucial point IMO is letting go of the "we are best" attitude. 

We don't claim to be "best" in a technical sense, because that is a
side issue anyway.  What we claim to be is _ethical_, in contrast to
the evil of proprietary software.

Re: Emacs vista build failures

[Bastien Guerry]

Richard M Stallman <rms@gnu.org> writes:

>     The crucial point IMO is letting go of the "we are best" attitude. 
>
> We don't claim to be "best" in a technical sense, because that is a
> side issue anyway.  What we claim to be is _ethical_, in contrast to
> the evil of proprietary software.

I think Lennart was referring to the "unix vendors".  I can believe they
claim to be "the best" in a technical sense.  

-- 
Bastien

Re: Emacs vista build failures

[David Kastrup]

Bastien Guerry <bzg@altern.org> writes:

> Richard M Stallman <rms@gnu.org> writes:
>
>>     The crucial point IMO is letting go of the "we are best" attitude. 
>>
>> We don't claim to be "best" in a technical sense, because that is a
>> side issue anyway.  What we claim to be is _ethical_, in contrast to
>> the evil of proprietary software.
>
> I think Lennart was referring to the "unix vendors".  I can believe
> they claim to be "the best" in a technical sense.

When comparing themselves to Windows?  Isn't that like using a beauty
pageant for picking the opponent for a fight with Jabba the Hutt?

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Emacs vista build failures

[Bastien Guerry]

"David Robinow" <drobinow@gmail.com> writes:

> I've tried several linux distributions. I've never managed to get an
> internet connection.

Don't stay alone.  Ask for help around you.  I doubt GNU/Linux experts
will leave you with a non-working GNU/Linux distro.

> I prefer a solution that works.

Machines are like people: some don't like to work.  But you can make
people make machines work.  Don't stay alone!

-- 
Bastien

Re: Emacs vista build failures

[Richard M Stallman]

    I've tried several linux distributions. I've never managed to get an
    internet connection.

If what you tried was just Linux, you couldn't manage to type a shell
command.  So they were probably GNU/Linux distributions.

Since GNU/Linux works for so many others, I suspect there was a
problem in installation.  The best way to solve them is to ask an
expert to do it for you.

Re: Emacs vista build failures

[David Robinow]

On Sat, Jul 12, 2008 at 12:35 PM, Richard M Stallman <rms@gnu.org> wrote:
>    I've tried several linux distributions. I've never managed to get an
>    internet connection.
>
> If what you tried was just Linux, you couldn't manage to type a shell
> command.  So they were probably GNU/Linux distributions.
 I'm well aware of the contributions of the GNU projectTo the extent
that you personally have been responsible thank you.
 I am also aware of your preference for the term GNU/Linux. I may be
mistaken but my feeling was that GNU is not to blame for my problems
so I deliberately omitted such mention.
 In any case, I intended only to point out my situation.
>
> Since GNU/Linux works for so many others, I suspect there was a
> problem in installation.  The best way to solve them is to ask an
> expert to do it for you.
 I didn't need an expert for Windows XP Home, Windows XP Pro, or Vista.
I spent 30 years as a computer programmer with a fair amount of unix
experience. I think I should be able to do a simple install.
 I think my issue may be with my ISP but I don't really care to pursue
the issue. Life is short.
I live 20 miles east of Dayton, Ohio. If anybody would like to come
over to help, feel free.

Re: Emacs vista build failures

[Bastien]

"David Robinow" <drobinow@gmail.com> writes:

> I think my issue may be with my ISP but I don't really care to pursue
> the issue. Life is short.

Let's speed things up a bit.  What is your ISP?  What is the distro you
have at hand? (I'm happy to provide help off-list since this is now OT.)

> I live 20 miles east of Dayton, Ohio. If anybody would like to come
> over to help, feel free.

I live in France and I received your message instantly.  
Maybe the web can help helping people without considering distance!

However short it is, life's great, and sharing experience with GNU/Linux
users makes it even greater!

-- 
Bastien

Re: Emacs vista build failures

[Richard M Stallman]

     I didn't need an expert for Windows XP Home, Windows XP Pro, or Vista.

It's an unfortunate fact that hardware developers cooperate with
Microsoft more than they cooperate with us.  I suspect that your
experience is the consequence of that.

What conclusion to derive from that depends on one's values.

If you care strongly about freedom, you could get angry at them for
aiding a company that does not respect our freedom, and you could
resolve not to let them push you into giving up your freedom.

On the other hand, if freedom is far down your list of priorities, you
could do whatever is easiest in the short term, even if that means
giving Microsoft total power over your computer.  In effect, you would
be letting Microsoft herd you wherever it wants.

Re: Emacs vista build failures

[Claus]

FWIW, I'm using Emacs-GIT under Windows Vista as well and as of today
it builds and runs fine.

Let me add to the ongoing Linux vs. Windows discussion that I prefer
GNU/Linux myself and use it at home.

Unfortunately, I'm forced to use Windows at work but that shoudn't
keep me from using Emacs. Freedom of choice, right?

Claus

Re: Emacs vista build failures

[Claus]

Eric,

I'm typing this message under "GNU Emacs 23.0.60.1
(i386-mingw-nt5.0.2195) of 2008-07-13 on CJK-MOBILE".

My latest commit is:

commit 43fe74b7f942596608bcf81e814447f92cd5d5bb
Author: Michael Albinus <michael.albinus@gmx.de>
Date:   Sun Jul 13 15:12:58 2008 +0000
[...]


However, I doubt this is were your problem is. It's more likely some
parts of the toolchain under Windows (Vista) cause problems.

I have a full (incl. make, gcc, ...) Cygwin installation, but for
Emacs-building Cygwin is pushed as last in my execution path.
That is, I'm using MSys/MingGW for the build process.

So, things to check in your build process are:

1. Is your MSys/MingGW installation complete?
2. Is MSys/MingGW first (before Cygwin) in your path?
3. For programs that MSys/MingGW doesn't provide, is there a fallback (Cygwin)?
4. Is your working directory clean?
5. Are your build-flags sane?
6. Are you using mingw32-make?
7. Before building, do you run "clean" and "bootstrap-clean"?
8. Do you bootstrap?

Looking at your log, most of the above steps seem OK and you get
pretty far in the build process.

I had similar errors in the past and the reason everytime was one of the below:

1. I had skipped some build step (configure/bootstrapping)
2. I haven't cleaned up thourougly enough
3. I had missed a MingGW/MSys-package that was needed
4. My Cygwin-installation under Vista was borked (due to Vista's
paranoid security settings).

I have included my build-script below - it works realiably for me
since months; perhaps it gives you some pointers.

HTH,
Claus


##############
#!/bin/bash
#
# Build script to automate preparing, configuring, cleaning, compiling
and installing emacs-CVS from source.
# v0.3 Claus Klingberg <cjk@pobox.com> 29.03.2008
#
echo 'Removing gruft from build-directory...'
rm -f ../lisp/calendar/cal-loaddefs.el ../nt/makefile ../src/makefile
../lisp/mh-e/mh-loaddefs.el ../lisp/loaddefs.el ../lisp/finder-inf.el
../lib-src/makefile ../admin/unidata/makefile
../admin/unidata/unidata-gen.elc ../admin/unidata/unidata.txt
../doc/emacs/makefile ../doc/misc/makefile ../leim/leim-list.el~
../leim/leim-list.el ../leim/makefile ../lisp/cus-load.el
../lisp/makefile ../src/config.h ../src/epaths.h
../doc/lispintro/makefile ../doc/lispref/makefile ../lib-src/makefile
../lisp/loaddefs.el ../lisp/mh-e/mh-loaddefs.el ../lisp/subdirs.el
../nt/config.log ../lisp/calendar/diary-loaddefs.el
../lisp/calendar/hol-loaddefs.el ../lisp/eshell/esh-groups.el
../lisp/finder-inf.el~ ../lisp/loaddefs.el~ ../leim/quail/4Corner.el
../leim/quail/ARRAY30.el ../leim/quail/CCDOSPY.el
../leim/quail/CTLau-b5.el ../leim/quail/CTLau.el
../leim/quail/ECDICT.el ../leim/quail/ETZY.el ../leim/quail/PY-b5.el
../leim/quail/PY.el ../leim/quail/Punct-b5.el ../leim/quail/Punct.el
../leim/quail/QJ-b5.el ../leim/quail/QJ.el ../leim/quail/SW.el
../leim/quail/TONEPY.el ../leim/quail/ZIRANMA.el ../leim/quail/ZOZY.el
../leim/quail/quick-b5.el ../leim/quail/quick-cns.el
../leim/quail/tsang-b5.el ../leim/quail/tsang-cns.el ../lib-src/DOC
../lib-src/ctags.c ../lib-src/getopt.h ../lisp/cus-load.el~

# Prepare path environment: need to put Cygwin back in favour of
MingGW Windows since we use mingw32-make to build emacs:
export PATH='/cygdrive/c/Windows/system32:/cygdrive/c/Windows:/cygdrive/c/Windows/System32/Wbem:/cygdrive/c/prg/MinGW/libexec/gcc/mingw32/3.4.5:/cygdrive/c/MinGW/bin:/cygdrive/c/prg/MSys/bin:/cygdrive/c/prg/libxml:/cygdrive/c/prg/aspell-60.3/bin:/usr/local/bin:/usr/bin:/bin:/usr/X11R6/bin'

echo 'Done preparing build.'

echo 'Running configure...'
if ./configure.bat --no-opt --with-gcc --without-jpeg --without-tiff
--without-gif --cflags -Ic:/work/cjk/src/gnuwin32
then
    echo 'Configuring successful!'
else
    echo -e "Error $0: Configure failed!"
    exit 1
fi

echo 'Cleaning up...'
if mingw32-make clean && mingw32-make bootstrap-clean
then
    echo 'Cleanup successful!'
else
    echo -e "Error $0: Cleanup failed!"
    exit 1
fi

echo 'Bootstrapping...'
if mingw32-make bootstrap
then
    echo 'Bootstrap successful!'
else
    echo -e "Error $0: Bootstrap failed!"
    exit 1
fi

echo 'Running make...'
if mingw32-make
then
    echo 'Make successful!'
else
    echo -e "Error $0: Make failed!"
    exit 1
fi

# Currently building info pages fails:
# mingw32-make info

echo 'Running Make install...'
if mingw32-make install
then
    echo 'Make install successful!'
else
    echo -e "Error $0: Make install failed!"
    exit 1
fi

##############

On Mon, Jul 14, 2008 at 3:54 AM, Eric Hanchrow <offby1@blarg.net> wrote:
>>>>>> "Claus" == Claus  <claus.klingberg@gmail.com> writes:
>
>    Claus> FWIW, I'm using Emacs-GIT under Windows Vista as well and as
>    Claus> of today it builds and runs fine.
>
> Interesting.  Could you give me the commit ID of something that works
> for you, and also tell me what compiler toolchain you're using?  (I'm
> using a current Cygwin, plus "make" from msys (for some reason, Cygwin's
> "make" doesn't work with emacs))
>
> --
> [T]he best strip of the last decade is "Dilbert", and it
> sure isn't because of the drawing.
>        -- Garry Trudeau
>

Re: Emacs vista build failures

[Eric Hanchrow]

>>>>> "Claus" == Claus  <claus.klingberg@gmail.com> writes:

    Claus> I have a full (incl.  make, gcc, ...)  Cygwin installation,
    Claus> but for Emacs-building Cygwin is pushed as last in my
    Claus> execution path.  That is, I'm using MSys/MingGW for the build
    Claus> process.

Same here :-|  And I keep my Cygwin reasonably current.

    Claus> So, things to check in your build process are:

    Claus> 1.  Is your MSys/MingGW installation complete?  

As far as I know.  It used to work fine -- in fact, it _still_ works
fine if I build the commit that corresponds to the 22.2 release.
                                                           
    Claus> 2.  Is MSys/MingGW first (before Cygwin) in your path?  

No, it's not on my PATH at all -- I just invoke c:/msys/1.0/bin/make "by
hand".  That's always worked in the past.
                                                                   
    Claus> 3.  For programs that MSys/MingGW doesn't provide, is there a
    Claus> fallback (Cygwin)?  

Yes.
                               
    Claus> 4.  Is your working directory clean?  

Yes.  I _always_ "git-clean -dxf" before attempting to build.
                                                 
    Claus> 5. Are your build-flags sane?  

I believe so.
                                          
    Claus> 6.  Are you using mingw32-make?  

Yes.
                                            
    Claus> 7.  Before building, do you run "clean" and
    Claus> "bootstrap-clean"?  

Effectively, via "git-clean -dxf".
                               
    Claus> 8.  Do you bootstrap?

Yes.

    Claus> I have included my build-script below - it works realiably
    Claus> for me since months; perhaps it gives you some pointers.

Thanks very much.

-- 
The reason Florence is famous is that in 1450, it was New York.
        -- Paul Graham

Re: Emacs vista build failures

[Richard M Stallman]

    Unfortunately, I'm forced to use Windows at work but that shoudn't
    keep me from using Emacs.

Being able to run Emacs on your machine at work is a good thing,
but don't give up on pressuring against running Windows there.
They are doing something very foolish, and they need to keep
hearing that.  Also, when you find a job that makes better use
of your skills, tell everyone that is why you left.

I saw an article recently saying that in France there is a demand for
people with skills in logiciel libre.  Maybe you can move there and
find work.

Re: Emacs vista build failures

[Chong Yidong]

"David Robinow" <drobinow@gmail.com> writes:

>> Since GNU/Linux works for so many others, I suspect there was a
>> problem in installation.  The best way to solve them is to ask an
>> expert to do it for you.

> I didn't need an expert for Windows XP Home, Windows XP Pro, or Vista.
> I spent 30 years as a computer programmer with a fair amount of unix
> experience. I think I should be able to do a simple install.

As mentioned, GNU/Linux works for so many others that it's probably an
easily solvable problem.

Re: Emacs vista build failures

[Alan Mackenzie]

Hi, everybody!

On Sun, Jul 13, 2008 at 04:46:10PM -0400, Chong Yidong wrote:
> "David Robinow" <drobinow@gmail.com> writes:

> >> Since GNU/Linux works for so many others, I suspect there was a
> >> problem in installation.  The best way to solve them is to ask an
> >> expert to do it for you.

> > I didn't need an expert for Windows XP Home, Windows XP Pro, or Vista.
> > I spent 30 years as a computer programmer with a fair amount of unix
> > experience. I think I should be able to do a simple install.

> As mentioned, GNU/Linux works for so many others that it's probably an
> easily solvable problem.

GNU/Linux _works_ fantastically, but that's not what's under discussion.

_GETTING_ a G/L system working is the issue, and that's best described as
a slog, or a nightmare.  There are any number of blogs which describe how
"you just insert the DVD, and 2 hours later you've got a complete working
system".  I've never met anybody in real life who's had that experience.

Most people I know who've tried to install GNU/Linux have spent, perhaps,
a solid weekend at it then given up for lack of time and energy.  It took
me about a month elapsed time (~20 days work (when I didn't have a day
job)) to get Debian Sarge working reasonably after my old PC died.

Richard, you're perhaps the brightest guy around, here.  How long did it
take you to get your first GNU/Linux installation installed and _fully_
working (i.e. all peripherals, networking, X-Windows, email,
web-browsing, ....  all satisfactory)?

For example, it took more than a day to get printing working (a standard
Linux-supported Samsung Laser printer on the parallel port).  It involved
delving into the printing-HOWTO, and the kernel documentation, enabling
the port support, rebuilding the kernel, struggling through the
undocumented garbage that is (?was) CUPS, discarding that for a
documented printing system, selecting a printing (formatting) driver by
trial and error, .....

This was typical of most things - a long hard slog, fixing problem after
problem after problem, a typical problem taking between 2 and 6 hours to
resolve.

And yes, at the end of that month GNU/Linux did indeed work
fantastically.

By contrast, I could have bought and installed Microsoft Windows XP, and
I would have had that working within a day.  However, MS Windows doesn't
work fantastically, ever.

I have heard that installing G/L has become easier in the last few
years.  But my advice to anybody who asks is still "don't install G/L
yourself unless you're _sure_ you really want it, and you've got the
stamina and stubbornness to see the installation through to the end".

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: Emacs vista build failures

[Alfred M. Szmidt]

   > >> Since GNU/Linux works for so many others, I suspect there was
   > >> a problem in installation.  The best way to solve them is to
   > >> ask an expert to do it for you.

   > > I didn't need an expert for Windows XP Home, Windows XP Pro, or
   > > Vista.  I spent 30 years as a computer programmer with a fair
   > > amount of unix experience. I think I should be able to do a
   > > simple install.

   > As mentioned, GNU/Linux works for so many others that it's
   > probably an easily solvable problem.

   GNU/Linux _works_ fantastically, but that's not what's under discussion.

   _GETTING_ a G/L system working is the issue, and that's best
   described as a slog, or a nightmare.  There are any number of blogs
   which describe how "you just insert the DVD, and 2 hours later
   you've got a complete working system".  I've never met anybody in
   real life who's had that experience.

Sorry, but I have no clue what you are talking about.  I know of no
GNU/Linux system that takes 2 hours to install and then 2 days or more
to get usable...  I recently reinstalled gNewSense and the
installation took me about 5 minutes, excluding the time it takes to
copy data from a CD-ROM to a HDD.  But I know that it does take over a
full day to install Windows XP, it is something I sadly do once every
other week.

Getting a printer working was trivial as well, I did not even need to
specify the driver.


What you say was true some 10 years ago, I still recall having to hand
edit /etc/printcap, write my own filtering rules! and write four
different floppies just to be able to boot a GNU/Linux system that
didn't even have a compiler included.  But this has not been the case
for the past 5+ years, or even close.

GNU/Linux these days is _far_ easier to install than Windows XP or Vista...

Re: Emacs vista build failures

[Alan Mackenzie]

Hi, Alfred!

On Sun, Jul 13, 2008 at 05:40:58PM -0400, Alfred M. Szmidt wrote:
>    > >> Since GNU/Linux works for so many others, I suspect there was
>    > >> a problem in installation.  The best way to solve them is to
>    > >> ask an expert to do it for you.

>    > > I didn't need an expert for Windows XP Home, Windows XP Pro, or
>    > > Vista.  I spent 30 years as a computer programmer with a fair
>    > > amount of unix experience. I think I should be able to do a
>    > > simple install.

>    > As mentioned, GNU/Linux works for so many others that it's
>    > probably an easily solvable problem.

>    GNU/Linux _works_ fantastically, but that's not what's under
>    discussion.

>    _GETTING_ a G/L system working is the issue, and that's best
>    described as a slog, or a nightmare.  There are any number of blogs
>    which describe how "you just insert the DVD, and 2 hours later
>    you've got a complete working system".  I've never met anybody in
>    real life who's had that experience.

> Sorry, but I have no clue what you are talking about.

Translation: "You're a liar or an idiot".  Please, there's no need for
that sort of riposte.  How about "I didn't have that amount of hassle"
instead?

> I know of no GNU/Linux system that takes 2 hours to install and then 2
> days or more to get usable...

No, of course not.  With enough accumulated expertise, any G/L system can
be installed and configured in a few hours.

> I recently reinstalled gNewSense and the installation took me about 5
> minutes, excluding the time it takes to copy data from a CD-ROM to a
> HDD.  But I know that it does take over a full day to install Windows
> XP, it is something I sadly do once every other week.

:-)  OK, but clearly since you do it every other week, the process takes
much less than 20 days.

> Getting a printer working was trivial as well, I did not even need to
> specify the driver.

Good for you!  It just worked.  You had a magic spell in your
distribution.  They either work 100% or totally fail.  In the latter
case, they give you NO information to help you diagnose things.  They
say, in effect "don't worry your pretty little head about this, leave
everything to me".  When they fail, and they always have failed for me,
it takes some experience to realise that the fault is with the magic
spell, not the person invoking it.  I detest this.

> What you say was true some 10 years ago, I still recall having to hand
> edit /etc/printcap, write my own filtering rules! and write four
> different floppies just to be able to boot a GNU/Linux system that
> didn't even have a compiler included.  But this has not been the case
> for the past 5+ years, or even close.

Well, I've described what it took me.  Maybe Debian Sarge was particularly
troublesome.  Maybe I'm just stupid, maybe the original poster here is
just as stupid, and maybe my friend who talked me through configuring my
ethernet card over many days, he earlier having taken just as long, is
also stupid.  But I have illusions of being of around or above average
capability in installing OSs.

> GNU/Linux these days is _far_ easier to install than Windows XP or
> Vista...

The original poster said he couldn't get his Linux connected to the
internet.  I can empathise with that completely.  Network configuration
under Linux (I think it comes from BSD Unix) is brain-damaged - it is
fragmented into many (not merely several) midget sized configuration
files, for which there is no coherent documentation - no network-config
HOWTO, nothing.  Just the man pages for each such file.  And when your
network doesn't work, you're left having to examine the entrails on
/var/log/messages and friends.  You don't get error messages on stderr.
I could strangle the arrogant cretin that created the error message "no
route to foo.bar" when he could so easily have announced "can't open
/etc/route" (or whatever the file actually is).

I challenge you to write a recipe, suitable for a newbie without an
internet connection, how to get a GNU/Linux system connected to the
internet, on the assumption that any magic spells supplied by the
distribution have failed.  Point out where he can find the necessary
info, and how he could discover that that is where he has to look.

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: Emacs vista build failures

[David Kastrup]

Alan Mackenzie <acm@muc.de> writes:

> Well, I've described what it took me.  Maybe Debian Sarge was
> particularly troublesome.

Yes.

> I challenge you to write a recipe, suitable for a newbie without an
> internet connection, how to get a GNU/Linux system connected to the
> internet, on the assumption that any magic spells supplied by the
> distribution have failed.  Point out where he can find the necessary
> info, and how he could discover that that is where he has to look.

Alfred talked about gNewSense (or whatever it is spelled), an Ubuntu
derivative.  Basically this boils down to clicking the obvious icons or
possibly menu points in the obvious places and specifying the obvious
information.  _IF_ things don't work right away anyway.  The exception
may be WLAN which might not work without non-free components (and
gNewSense does not include them).

If that sounds hopelessly optimistic, just try it.  I certainly have had
my share of having configured Unix systems for networking, even before
Linux existed.  Things really have become quite convenient to a point
where one does not ever need a text editor for getting things to run,
unless things are really utterly unexpectedly broken.

Most popular Linux distributions nowadays are in that ballpark, with the
notable exceptions of Debian proper and Slackware.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Emacs vista build failures

[Miles Bader]

David Kastrup <dak@gnu.org> writes:
> Most popular Linux distributions nowadays are in that ballpark, with the
> notable exceptions of Debian proper and Slackware.

Last time I installed Debian, it most certainly was "in that ballpark"...

-Miles

-- 
Carefully crafted initial estimates reward you not only with
reduced computational effort, but also with understanding and
increased self-esteem.         -- Numerical methods in C,
  Chapter 9. "Root Finding and Nonlinear Sets of Equations"

Re: Emacs vista build failures

[Alfred M. Szmidt]

   > I recently reinstalled gNewSense and the installation took me
   > about 5 minutes, excluding the time it takes to copy data from a
   > CD-ROM to a HDD.  But I know that it does take over a full day to
   > install Windows XP, it is something I sadly do once every other
   > week.

   :-) OK, but clearly since you do it every other week, the process
   takes much less than 20 days.

It is done in parallel.


   I challenge you to write a recipe, suitable for a newbie without an
   internet connection, how to get a GNU/Linux system connected to the
   internet, on the assumption that any magic spells supplied by the
   distribution have failed.  Point out where he can find the
   necessary info, and how he could discover that that is where he has
   to look.

http://www.gnewsense.org/

Re: Emacs vista build failures

[Alan Mackenzie]

Good day, Alfred,

On Mon, Jul 14, 2008 at 06:27:57AM -0400, Alfred M. Szmidt wrote:

>    I challenge you to write a recipe, suitable for a newbie without an
>    internet connection, how to get a GNU/Linux system connected to the
>    internet, on the assumption that any magic spells supplied by the
>    distribution have failed.  Point out where he can find the
>    necessary info, and how he could discover that that is where he has
>    to look.

> http://www.gnewsense.org/

A sarcastic patronising non-answer.  I'm sure the original poster,
without an internet connection, is just going to thank you for that, head
off to that site, say "WOW!  How could I have missed this?" and have his
internet connection working within half an hour.  If only.

What really gets up my nose in this whole thread is the attitude that if
somebody can't get G/L installed, the fault lies with that person, not
with the software developers/packagers.  Even more so, that the said
person who, quite understandibly, baulks at the unbounded time and
tedium it takes to complete an installation gets sneered at for not
"placing a high value on freedom".

And Richard, in particular, if somebody feeds the name of their system
through cut -d/ -f2 would you PLEASE not get sarcastic at them.  It
makes you look like a jerk, and it makes me feel embarrassed at being on
the same mailing list.  Surely you can ask people courteously to say
"GNU/Linux".  It happens often enough that you could put pertinent
boilerplate onto a key sequence.

So far in this thread, I think exactly one person has offered the OP
friendly help in setting up a free system.  The said poster seems to
have dropped out of the thread.  I can't blame him.

furrfu!

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: Emacs vista build failures

[Richard M Stallman]

    And Richard, in particular, if somebody feeds the name of their system
    through cut -d/ -f2 would you PLEASE not get sarcastic at them. 

I don't know how to use the cut program, and I don't know what that
command does.  But since you are talking about the name of the system,
I will make the guess that this has to do with the mistake of calling
the system "Linux".

I explain that error a few times every day, and I have lots of
practice in doing it.  I do it in a courtious and straightfoward tone,
and never with sarcasm.

Re: Emacs vista build failures

[Alan Mackenzie]

'evening, Richard!

On Mon, Jul 14, 2008 at 01:39:05PM -0400, Richard M Stallman wrote:
>     And Richard, in particular, if somebody feeds the name of their system
>     through cut -d/ -f2 would you PLEASE not get sarcastic at them. 

> I don't know how to use the cut program, and I don't know what that
> command does.

It prints slice(s) out of a line of text, either by column numbers or (as
here) by field numbers, given a separator.  Spend 5 minutes browsing the
man page or GNU text utilities manual.  It's one of these things that
somehow comes in handy quite a lot, but not _quite_ enough to remember
its details.  For example, this gets the CVS version number of a local
file:

grep cc-mode.el CVS/Entries | cut -d/ -f3

> But since you are talking about the name of the system, I will make
> the guess that this has to do with the mistake of calling the system
> "Linux".

Yes.

> I explain that error a few times every day, and I have lots of
> practice in doing it.  I do it in a courtious and straightfoward tone,
> and never with sarcasm.

Ah, OK, that's all right then.  ;-)

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: Emacs vista build failures

[Alfred M. Szmidt]

Maybe if you stopped with your condescending tone then people might be
more willing to help you.  If you expect me to be friendly to you
after calling me a liar, patronising, and what not, then you are quite
mistaken.

Re: Emacs vista build failures

[Alan Mackenzie]

Hi, Alfred,

On Tue, Jul 15, 2008 at 02:04:06PM -0400, Alfred M. Szmidt wrote:
> Maybe if you stopped with your condescending tone then people might be
> more willing to help you.  If you expect me to be friendly to you
> after calling me a liar, patronising, and what not, then you are quite
> mistaken.

If I've called you a liar, it was by accident and I'm sorry about it.
It's not the sort of thing I do.

I didn't call you patronising - merely one of your replies; this one:

>    I challenge you to write a recipe, suitable for a newbie without an
>    internet connection, how to get a GNU/Linux system connected to the
>    internet, on the assumption that any magic spells supplied by the
>    distribution have failed.  Point out where he can find the necessary
>    info, and how he could discover that that is where he has to look.

> http://www.gnewsense.org/

In fact I found it somewhat offensive, much as you have found some of my
posts offensive.  I don't think I fully understand what you were trying
to say, and apologise for going directly into such a high temperature
mode.  I was in a somewhat turbulent state when I read your reply.

I had a look at the gnewsense website when I got your Email, and there
was no configuration help there for the OP who couldn't configure his
internet connection.

At the time I read your one-line reply as saying to him "you've been a
bit of an idiot spending so much time on such a duff distribution; you'll
never manage to get it set up, so you might as well give up now, chuck it
all away and start again from scratch with a better distro which is sure
to work by magic".  Which if you had said, would have justified me taking
offence.

I think you actually meant something more gentle.

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: Emacs vista build failures

[Chong Yidong]

Please take the discussion of GNU/Linux system installation off-list.
There are many mailing lists dedicated to this topic; this is not one of
them.

Re: Emacs vista build failures

[Thomas Lord]

Chong Yidong wrote:
> Please take the discussion of GNU/Linux system installation off-list.
> There are many mailing lists dedicated to this topic; this is not one of
> them.
>   

At the same time, this is perhaps the only mailing list where
the GNU project, per se, is a topic of interest to more than
a few.

So, I agree about "take it elsewhere" but I wonder if it isn't
time to make a list, forked from here, to talk about the
GNU project, per se.

May we briefly, here, consider that question?

-t






>
>
>   

Re: Emacs vista build failures

[Stefan Monnier]

> May we briefly, here, consider that question?

No, please don't.  There's gnu.discuss already.


        Stefan

Re: Emacs vista build failures

[Miles Bader]

Stefan Monnier <monnier@iro.umontreal.ca> writes:
>> May we briefly, here, consider that question?
>
> No, please don't.  There's gnu.discuss already.

gnu.misc.discuss?  It'd be interesting to have some content there other
than endless stupid troll wars...

-Miles

-- 
The trouble with most people is that they think with their hopes or
fears or wishes rather than with their minds.  -- Will Durant

Re: Emacs vista build failures

[Stefan Monnier]

>>> May we briefly, here, consider that question?
>> No, please don't.  There's gnu.discuss already.
> gnu.misc.discuss?  It'd be interesting to have some content there other
> than endless stupid troll wars...

Isn't that exactly what Tom was asking for?


        Stefan "still not sure if I'm joking or not"

Re: Emacs vista build failures

[Miles Bader]

Stefan Monnier <monnier@iro.umontreal.ca> writes:
>>> No, please don't.  There's gnu.discuss already.
>> gnu.misc.discuss?  It'd be interesting to have some content there other
>> than endless stupid troll wars...
>
> Isn't that exactly what Tom was asking for?

Hmm, well at least a higher level.  The existing trolls can
barely remember to breath between grunts...

-Miles

-- 
`Suppose Korea goes to the World Cup final against Japan and wins,' Moon said.
`All the past could be forgiven.'   [NYT]

Re: Emacs vista build failures

[Thomas Lord]

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

Stefan Monnier wrote:
>> gnu.misc.discuss?  It'd be interesting to have some content there other
>> than endless stupid troll wars...
>>     
>
> Isn't that exactly what Tom was asking for?
>
>
>         Stefan "still not sure if I'm joking or not"
>   


Joking or not I'm sure I've been pointlessly insulted.

-t




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

Re: Emacs vista build failures

[Thomas Lord]

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

Stefan Monnier wrote:
>> May we briefly, here, consider that question?
>>     
>
> No, please don't.  There's gnu.discuss already.
>   

Fine.

GNU is dead.  Long live GNU.

-t




>
>         Stefan
>
>   


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

Re: Emacs vista build failures

[Miles Bader]

Alan Mackenzie <acm@muc.de> writes:
>> Getting a printer working was trivial as well, I did not even need to
>> specify the driver.
>
> Good for you!  It just worked.  You had a magic spell in your
> distribution.  They either work 100% or totally fail.  In the latter
> case, they give you NO information to help you diagnose things.  They
> say, in effect "don't worry your pretty little head about this, leave
> everything to me".

Of course, that's how _everything_ on windows works.  If it doesn't do
the right thing, well, you're fucked, go buy a new computer.

-Miles

-- 
Politeness, n. The most acceptable hypocrisy.

Re: Emacs vista build failures

[Alan Mackenzie]

Hi, Miles,

On Mon, Jul 14, 2008 at 07:45:10PM +0900, Miles Bader wrote:
> Alan Mackenzie <acm@muc.de> writes:
> >> Getting a printer working was trivial as well, I did not even need
> >> to specify the driver.

> > Good for you!  It just worked.  You had a magic spell in your
> > distribution.  They either work 100% or totally fail.  In the latter
> > case, they give you NO information to help you diagnose things.
> > They say, in effect "don't worry your pretty little head about this,
> > leave everything to me".

> Of course, that's how _everything_ on windows works.  If it doesn't do
> the right thing, well, you're fucked, go buy a new computer.

The point is that installing MS-Windows _works_.  Most of the time,
pretty painlessly.  I've done it for a friend a few times.  There was no
need for me to crawl through HOWTOs or search out kernel documentation
to make it work.

That has not been my experience of GNU/Linux, in particular Debian
Sarge and some older versions of SuSE.  I accept that others have had
better experiences installing G/L.

Please don't construe this as me advocating MS-Windows.  I'm not.  It's
just that reality doesn't go away when you shut your eyes.

> -Miles

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: Emacs vista build failures

[joakim]

Alan Mackenzie <acm@muc.de> writes:

>
> The point is that installing MS-Windows _works_.  Most of the time,
> pretty painlessly.  I've done it for a friend a few times.  There was no
> need for me to crawl through HOWTOs or search out kernel documentation
> to make it work.

As a data-point, I've quite often failed to install MS-Windows, and then
flawlessly installed a Fedora GNU/Linux on the same machine. No
magic-incantations, even.

>
> That has not been my experience of GNU/Linux, in particular Debian
> Sarge and some older versions of SuSE.  I accept that others have had
> better experiences installing G/L.
>
> Please don't construe this as me advocating MS-Windows.  I'm not.  It's
> just that reality doesn't go away when you shut your eyes.
>
>> -Miles
-- 
Joakim Verona

Re: Emacs vista build failures

[David Kastrup]

joakim@verona.se writes:

> Alan Mackenzie <acm@muc.de> writes:
>
>>
>> The point is that installing MS-Windows _works_.  Most of the time,
>> pretty painlessly.  I've done it for a friend a few times.  There was
>> no need for me to crawl through HOWTOs or search out kernel
>> documentation to make it work.
>
> As a data-point, I've quite often failed to install MS-Windows, and
> then flawlessly installed a Fedora GNU/Linux on the same machine. No
> magic-incantations, even.

As another data point: I had several laptops die on me (botched BIOS
update, cup of tea).  Both were dual-boot systems with Windows (98 or
2000, I forgot which).  I think the first had been a RedHat system, the
second had been Ubuntu.

I transferred the disk to a new system.  The Linux partition (generic
kernel) noted the change of hardware and came up pretty much without a
hitch.  The Windows partition...  well the first already barfed upon the
disk geometry (different BIOS, different geometry spoofing).  Either had
a wagonload of trouble with drivers and hardware before I could get it
to work again.  Took weeks each time around to make most of it work
(even though Internet access was not a topic due to lack of virus
updates).

Now nowadays things have become easier with Windows XP.  More drivers
are built in, and it won't help you, because XP refuses to come up on a
previously unregistered system.

Last laptop I bought I went into the shop and tried my disk, and the
shop assistant said that it would not work.  It worked, and the reason
was that it was not Windows.

So if you cherish your work environment and your data, don't tie
yourself down to Windows.  You can't move on in a sane way.  Even
disregarding all other aspects of non-freedom, it will stop working
together with the hardware.  And that's a chance one should not be
taking.

-- 
David Kastrup

Re: Emacs vista build failures

[Alfred M. Szmidt]

   > Of course, that's how _everything_ on windows works.  If it
   > doesn't do the right thing, well, you're fucked, go buy a new
   > computer.

   The point is that installing MS-Windows _works_. 

And so does gNewSense.  Please try it; it is quite nice.

Re: Emacs vista build failures

[Lennart Borgman (gmail)]

Alan Mackenzie wrote:
> For example, it took more than a day to get printing working (a standard
> Linux-supported Samsung Laser printer on the parallel port).  It involved
> delving into the printing-HOWTO, and the kernel documentation, enabling
> the port support, rebuilding the kernel, struggling through the
> undocumented garbage that is (?was) CUPS, discarding that for a
> documented printing system, selecting a printing (formatting) driver by
> trial and error, .....
> 
> This was typical of most things - a long hard slog, fixing problem after
> problem after problem, a typical problem taking between 2 and 6 hours to
> resolve.
> 
> And yes, at the end of that month GNU/Linux did indeed work
> fantastically.

 From what you and others have written it looks like the weak point when 
installing GNU/Linux is the hardware. I wonder if this still is the case 
with Ubuntu?

In that case, should not investigating hardware be something that is 
done as earlier as possible in the installation process - with a 
possibility for the user to just back off if the installation process 
finds hardware it does not recognize.

I think that such a scheme could make GNU/Linux reputation in this 
regard much better.

Re: Emacs vista build failures

[Alan Mackenzie]

Hi, Lennart!

On Sun, Jul 13, 2008 at 11:48:43PM +0200, Lennart Borgman (gmail) wrote:
> Alan Mackenzie wrote:
> >For example, it took more than a day to get printing working (a
> >standard Linux-supported Samsung Laser printer on the parallel port).
> >It involved delving into the printing-HOWTO, and the kernel
> >documentation, enabling the port support, rebuilding the kernel,
> >struggling through the undocumented garbage that is (?was) CUPS,
> >discarding that for a documented printing system, selecting a printing
> >(formatting) driver by trial and error, .....

> >This was typical of most things - a long hard slog, fixing problem
> >after problem after problem, a typical problem taking between 2 and 6
> >hours to resolve.

> >And yes, at the end of that month GNU/Linux did indeed work
> >fantastically.

> From what you and others have written it looks like the weak point when
> installing GNU/Linux is the hardware.

Partly.  Partly it's the fragmentation of documentation.  Partly free
software authors are a long way behind proprietary companies in making
installation low-pain.  Very little free software is documented anywhere
near as well as Emacs.

> I wonder if this still is the case with Ubuntu?

I tried Ubuntu.  It's an arrogant and patronising distribution - they try
to pretend that there's no such thing as the root user, and they try to
stop you finding out.  They have their own idiosyncratic init program
with a fragmented, undocumented configuration system.  The response of my
request for this documentation was "hey, why don't _you_ contribute it?". 

Still, if you can cope with that sort of attitude, Ubuntu seems to work
relatively well.  However, it was business as usual (2 - 6 hours per
issue) when I got to installing framebuffer on my Ubuntu.  It took me ~2
hours to get my Emacs to find my site-start.el - Debian (and thus Ubuntu
too) puts a content-free site-start.el somewhere in /etc which blocks out
your own real one.  I keep meaning to complain about this.

> In that case, should not investigating hardware be something that is 
> done as earlier as possible in the installation process - with a 
> possibility for the user to just back off if the installation process 
> finds hardware it does not recognize.

Yes.  I think a bigger problem is that each distribution tries to
"encapsulate" the problem in its own way, but they end up just wrapping
the problem in yet one more layer of undocumented complexity.  Sometimes
I think it would be better if the instructions just said "fill in these
configuration files as follows, using your favourite text editor" rather
than obfuscating the process with layers of scripts and GUI
"friendliness".

> I think that such a scheme could make GNU/Linux reputation in this 
> regard much better.

Perhaps.  Maybe the problem is intractable, due to the intrinsic
complexity of GNU/Linux.  Maybe Alfred's distribution is OK.  It's
something I'd far rather not have to bother about - I'd much rather just
hack Emacs!

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: Emacs vista build failures

[David Kastrup]

Alan Mackenzie <acm@muc.de> writes:

> Hi, Lennart!
>
>> I wonder if this still is the case with Ubuntu?
>
> I tried Ubuntu.  It's an arrogant and patronising distribution - they
> try to pretend that there's no such thing as the root user, and they
> try to stop you finding out.  They have their own idiosyncratic init
> program with a fragmented, undocumented configuration system.  The
> response of my request for this documentation was "hey, why don't
> _you_ contribute it?".
>
> Still, if you can cope with that sort of attitude, Ubuntu seems to
> work relatively well.  However, it was business as usual (2 - 6 hours
> per issue) when I got to installing framebuffer on my Ubuntu.  It took
> me ~2 hours to get my Emacs to find my site-start.el - Debian (and
> thus Ubuntu too) puts a content-free site-start.el somewhere in /etc
> which blocks out your own real one.  I keep meaning to complain about
> this.

Forget about Debian and Emacs.  They use a clever system for sharing
package code between different Emacs versions (which you can install at
the same time) and XEmacs, so clever that nobody understands it.  Not
even Emacs or XEmacs itself (just try M-x list-load-path-shadows RET and
shudder).  Just compile and configure your own Emacs from scratch.

I know of _no_ upstream Emacs or XEmacs developer who claims to
understand or get along with the Debian setup.

> Yes.  I think a bigger problem is that each distribution tries to
> "encapsulate" the problem in its own way, but they end up just
> wrapping the problem in yet one more layer of undocumented complexity.
> Sometimes I think it would be better if the instructions just said
> "fill in these configuration files as follows, using your favourite
> text editor" rather than obfuscating the process with layers of
> scripts and GUI "friendliness".

There are situations, but they get pretty rare.  Nowadays I rarely need
to resort to "look away now and don't ask what I did" when configuring
the computer of somebody else.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Emacs vista build failures

[Don Armstrong]

On Mon, 14 Jul 2008, David Kastrup wrote:
> Alan Mackenzie <acm@muc.de> writes:
> > It took me ~2 hours to get my Emacs to find my site-start.el -
> > Debian (and thus Ubuntu too) puts a content-free site-start.el
> > somewhere in /etc which blocks out your own real one.

Just edit /etc/emacs/site-start.el if you want it emacs wide, or shove
stuff into /etc/emacs<flavor>/site-start.d/; it's pretty trivial.
[Though frankly, most things that people think they should shove into
site-start.el doesn't belong there: it belongs in ~/.emacs.]

> Forget about Debian and Emacs. They use a clever system for sharing
> package code between different Emacs versions (which you can install
> at the same time) and XEmacs, so clever that nobody understands it.

Lots of us understand it; it's pretty trivial. Thanks to that system,
installing packaged emacs add-ons is absolutely trivial.

If you're lost, see
http://www.debian.org/doc/packaging-manuals/debian-emacs-policy

> I know of _no_ upstream Emacs or XEmacs developer who claims to
> understand or get along with the Debian setup.

There's no need for upstream developers to bother, since it's all
handled for them by Debian Developers.


Don Armstrong

-- 
We cast this message into the cosmos. [...] We are trying to survive
our time so we may live into yours. We hope some day, having solved
the problems we face, to join a community of Galactic Civilizations.
This record represents our hope and our determination and our goodwill
in a vast and awesome universe.
 -- Jimmy Carter on the Voyager Golden Record

http://www.donarmstrong.com              http://rzlab.ucr.edu

Re: Emacs vista build failures

[David Kastrup]

Don Armstrong <don@donarmstrong.com> writes:

> On Mon, 14 Jul 2008, David Kastrup wrote:
>
>> I know of _no_ upstream Emacs or XEmacs developer who claims to
>> understand or get along with the Debian setup.
>
> There's no need for upstream developers to bother, since it's all
> handled for them by Debian Developers.

Uh, upstream developers need to compile and test their work, too.  And
it is not feasible to, say, arrange your own package in front of the
load-path somewhere in /usr/local/ since the Debian policy puts .el
files and .elc files in completely different directory hierarchies (and
different places in the load-path order), so things tend to get mixed up
if they are more than once in the load-path.

As one consequence, the diagnostic tool
M-x list-load-path-shadows RET
pretty much goes crazy on Debian.

The only sane way out is to compile and manage your own Emacs and
packages.  And that's what _all_ Emacs and XEmacs developers I know who
are not simultaneously Debian maintainers do.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Emacs vista build failures

[Manoj Srivastava]

On Mon, 14 Jul 2008 23:05:16 +0200, David Kastrup <dak@gnu.org> said: 

> Don Armstrong <don@donarmstrong.com> writes:
>> On Mon, 14 Jul 2008, David Kastrup wrote:
>> 
>>> I know of _no_ upstream Emacs or XEmacs developer who claims to
>>> understand or get along with the Debian setup.
>> 
>> There's no need for upstream developers to bother, since it's all
>> handled for them by Debian Developers.

> Uh, upstream developers need to compile and test their work, too.  And
> it is not feasible to, say, arrange your own package in front of the
> load-path somewhere in /usr/local/ since the Debian policy puts .el
> files and .elc files in completely different directory hierarchies
> (and different places in the load-path order), so things tend to get
> mixed up if they are more than once in the load-path.

        Why does that matter for you in /usr/local? You can put all the
 .el and .elc files in the same directory. As an emacs developer, surely
 you can put a path in front of the system load path? I mean, a
 dumb-as-doornails Debian person like me can  manage to add my elisp
 directories ahead of system paths, so surely an intelligent emacs
 developer can do so as well, unless they wanted to appear unable for
 the sake of a debating point.

> As one consequence, the diagnostic tool M-x list-load-path-shadows RET
> pretty much goes crazy on Debian.

        It is:
A. /usr/share/<current-emacs-flavour> hiding /usr/share/emacs
B. /usr/local/share/emacs/site-lisp/<current-emacs-flavour> hiding 
                                   /usr/share/emacs/site-lisp/

        Frankly, I don't call that going "pretty much crazy". but it
 does make a nice sound bite in a flamewar.

> The only sane way out is to compile and manage your own Emacs and
> packages.  And that's what _all_ Emacs and XEmacs developers I know
> who are not simultaneously Debian maintainers do.

        I think this is not the case, since a trivial work around is
 available (add your dir to the head of the path).

        manoj
-- 
A black cat crossing your path signifies that the animal is going
somewhere. Groucho Marx
Manoj Srivastava <srivasta@acm.org> <http://www.golden-gryphon.com/>  
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C

Re: Emacs vista build failures

[David Kastrup]

Manoj Srivastava <srivasta@ieee.org> writes:

> On Mon, 14 Jul 2008 23:05:16 +0200, David Kastrup <dak@gnu.org> said: 
>
>> Don Armstrong <don@donarmstrong.com> writes:
>>> On Mon, 14 Jul 2008, David Kastrup wrote:
>>> 
>>>> I know of _no_ upstream Emacs or XEmacs developer who claims to
>>>> understand or get along with the Debian setup.
>>> 
>>> There's no need for upstream developers to bother, since it's all
>>> handled for them by Debian Developers.
>
>> Uh, upstream developers need to compile and test their work, too.  And
>> it is not feasible to, say, arrange your own package in front of the
>> load-path somewhere in /usr/local/ since the Debian policy puts .el
>> files and .elc files in completely different directory hierarchies
>> (and different places in the load-path order), so things tend to get
>> mixed up if they are more than once in the load-path.
>
>         Why does that matter for you in /usr/local? You can put all the
>  .el and .elc files in the same directory. As an emacs developer, surely
>  you can put a path in front of the system load path? I mean, a
>  dumb-as-doornails Debian person like me can  manage to add my elisp
>  directories ahead of system paths, so surely an intelligent emacs
>  developer can do so as well, unless they wanted to appear unable for
>  the sake of a debating point.

I am not an intelligent Emacs developer.  And it would appear that there
are pretty few of either them or intelligent XEmacs developers around.
Again: I know of no upstream Emacs or XEmacs developer that is able to
work with the Debian setup.

Yes, we are all stupid.  But since the intelligent ones are rare, it
might be worth adapting the policies to deal with the real world.

>> As one consequence, the diagnostic tool M-x list-load-path-shadows RET
>> pretty much goes crazy on Debian.
>
>         It is:
> A. /usr/share/<current-emacs-flavour> hiding /usr/share/emacs
> B. /usr/local/share/emacs/site-lisp/<current-emacs-flavour> hiding 
>                                    /usr/share/emacs/site-lisp/
>
>         Frankly, I don't call that going "pretty much crazy". but it
>  does make a nice sound bite in a flamewar.

Install a few add-on Elisp packages from Debian, then try again.

>> The only sane way out is to compile and manage your own Emacs and
>> packages.  And that's what _all_ Emacs and XEmacs developers I know
>> who are not simultaneously Debian maintainers do.
>
>         I think this is not the case, since a trivial work around is
>  available (add your dir to the head of the path).

First you would have to find a file which actually gets loaded instead
of bypassed be the Debian scheme.

Anyway, we are on the Emacs developer list.  So if I am talking nonsense
about Emacs developers, you'd expect to hear a correction.  And the same
discussion has been on the XEmacs developer list.

Feel free to conduct a survey if you don't believe me.  I am not
interested in being proven stupid and incapable.  I am perfectly willing
to accept that evaluation.  But I know that I am not alone, and at some
point of time Debian should face reality and figure out how to make use
of all the stupid and incapable people who are seemingly able to get
work done elsewhere.

-- 
David Kastrup

Re: Emacs vista build failures

[Manoj Srivastava]

On Wed, 16 Jul 2008 17:20:03 +0200, David Kastrup <dak@gnu.org> said: 

> Yes, we are all stupid.  But since the intelligent ones are rare, it
> might be worth adapting the policies to deal with the real world.

        The most common target user does not care to override Emacs
 packages for one of their own. And these are the users that Debian
 caters to well.

        But please don't construe that to mean that Debian does not
 cater to Developers, we try to.

>>> As one consequence, the diagnostic tool M-x list-load-path-shadows
>>> RET pretty much goes crazy on Debian.
>> 
>> It is:
>> A. /usr/share/<current-emacs-flavour> hiding /usr/share/emacs
>> B. /usr/local/share/emacs/site-lisp/<current-emacs-flavour> hiding
>>    /usr/share/emacs/site-lisp/
>> 
>> Frankly, I don't call that going "pretty much crazy". but it does
>> make a nice sound bite in a flamewar.

> Install a few add-on Elisp packages from Debian, then try again.

        I have. I have quite a few installed, and still, the two
 directory shadows cover everything on my machine. (cedet, gnus, vm,
 ...)


>>> The only sane way out is to compile and manage your own Emacs and
>>> packages.  And that's what _all_ Emacs and XEmacs developers I know
>>> who are not simultaneously Debian maintainers do.
>> 
>> I think this is not the case, since a trivial work around is
>> available (add your dir to the head of the path).

> First you would have to find a file which actually gets loaded instead
> of bypassed be the Debian scheme.

        My .emacs has never been bypassed. That is where I add my
 directories to the loadpath.

> Feel free to conduct a survey if you don't believe me.  I am not
> interested in being proven stupid and incapable.  I am perfectly
> willing to accept that evaluation.  But I know that I am not alone,
> and at some point of time Debian should face reality and figure out
> how to make use of all the stupid and incapable people who are
> seemingly able to get work done elsewhere.

        Hmm. I just added org-mode to
 /usr/local/share/emacs/site-lisp/org-mode,  and boom, it overrides the
 org-mode built into my emacs-snapshot package. I did absolutely
 nothing to my Debian setup to make that happen.

        Also, anything dumped into my personal lisp directorieas also
 seems to take precedence, and this is the code I use to add them (in my
 .emacs):
--8<---------------cut here---------------start------------->8---

(defvar manoj-lisp-subdirs (list "config" "functions" "bbdb"
                                 "lisp" "mail" "modes" "x-support"
                                 "debian" "news"
                                 (format "emacs%d/gnus" (emacs-major-version))
                                 (format "emacs%d/w3" (emacs-major-version))
                                 )
  "*The list of subdirtectories we want in the path.")

;;; Add the subdirs to the load path
(let ((subdirs (mapcar
                (function
                 (lambda (x)
                   (expand-file-name
                    (concat
                     my-emacs-config-dir "/"  x))))
                manoj-lisp-subdirs)))
  (while subdirs
    (let ((subdir (car subdirs)))
      (if (not (member subdir load-path))
          (setq load-path (cons subdir load-path))))
    (setq subdirs (cdr subdirs))))
--8<---------------cut here---------------end--------------->8---

        So, really, unless I can reproduce the problem you claim to
 have, I can't file bug reports, not can I figure out a scheme to fix
 them.

        From where I sit, at least my bog standard Debian unstable
 distribution does not get in my way when trying to maintain my emacs
 lisp packages. I am sorry your mileage has varied.

        manoj
-- 
Biz is better.
Manoj Srivastava <srivasta@acm.org> <http://www.golden-gryphon.com/>  
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C

Re: Emacs vista build failures

[Stephen J. Turnbull]

Manoj Srivastava writes:

 > > As one consequence, the diagnostic tool M-x list-load-path-shadows RET
 > > pretty much goes crazy on Debian.
 > 
 >         It is:
 > A. /usr/share/<current-emacs-flavour> hiding /usr/share/emacs
 > B. /usr/local/share/emacs/site-lisp/<current-emacs-flavour> hiding 
 >                                    /usr/share/emacs/site-lisp/

Is that "local" a typo?  If not, I consider it a bug.  IMO Debian
should never install anything (except maybe the standard list of
subdirectories) into /usr/local; that's *mine*.

 >         Frankly, I don't call that going "pretty much crazy". but it
 >  does make a nice sound bite in a flamewar.

Well, I can infer that you just don't care about shadows, because that
means that essentially all libraries have shadows.

That *is* crazy, and definitely hinders diagnosing bugs which are due
to a mismatch between version expected and version provided by the
shadowing library.  Developers and beta testers will typically have a
few shadows, but in a standard installation to have *any* *is a bug*.

This should be fixable by (1) linking /usr/share/emacs's .el files
into the emacs-FLAVOR hierarchies, then (2) removing /usr/share/emacs
from load-path.  Ditto for site-lisp.

 > > The only sane way out is to compile and manage your own Emacs and
 > > packages.  And that's what _all_ Emacs and XEmacs developers I know
 > > who are not simultaneously Debian maintainers do.
 > 
 >         I think this is not the case, since a trivial work around is
 >  available (add your dir to the head of the path).

This simply isn't sufficient, except for the case of a person
maintaining one or a few Lisp packages.  Don't bother asking for
details; that's the product of experience with many small confusing
problems, and if I *could* characterize the many confusingly small
problems anything like that simply, I would have tried to fix those
confusingly many small problems (all alike ;-), and probably I'd still
be using Debianized Emacsen.  The best I've heard of is Miles's hack,
but he apparently uses a non-Debianized Emacsen and a .emacs hack
which adds /usr/share/emacs to his load-path (and I bet it's not at
the head).

In other words, you're making the same mistake that Alan did.  Because
the set of people who actively participate in Emacs (and XEmacs)
development on a day-to-day basis does not AFAICT include the Debian
Emacsen maintainers and especially those who maintain the Debian Emacs
Policy, there is nobody who can speak authoritatively about how the
DEP and Emacs development practice could be better integrated.

Nevertheless, you and Joe extrapolate from personal experience and
assume that since you don't run into problems, a little discipline
would solve them for the developers, too.  That's just as wrong as
Alan assuming that with a little more care the DEP could be adjusted
so that he could use a Debianized Emacs in his usual way.

Re: Emacs vista build failures

[Manoj Srivastava]

On Thu, 17 Jul 2008 06:23:56 +0900, Stephen J Turnbull <stephen@xemacs.org> said: 

> Manoj Srivastava writes:
>> > As one consequence, the diagnostic tool M-x list-load-path-shadows
>> > RET pretty much goes crazy on Debian.
>> 
>> It is:
>> A. /usr/share/<current-emacs-flavour> hiding /usr/share/emacs
>> B. /usr/local/share/emacs/site-lisp/<current-emacs-flavour> hiding
>> /usr/share/emacs/site-lisp/

> Is that "local" a typo?  If not, I consider it a bug.  IMO Debian
> should never install anything (except maybe the standard list of
> subdirectories) into /usr/local; that's *mine*.

        I do not think it is a typo. Debian installs an empty directory
 there, and never removes it; it is so that you can drop stuff in there
 to override the vendor installed stuff. I consider that a feature.

>> Frankly, I don't call that going "pretty much crazy". but it does
>> make a nice sound bite in a flamewar.

> Well, I can infer that you just don't care about shadows, because that
> means that essentially all libraries have shadows.

> That *is* crazy, and definitely hinders diagnosing bugs which are due
> to a mismatch between version expected and version provided by the
> shadowing library.  Developers and beta testers will typically have a
> few shadows, but in a standard installation to have *any* *is a bug*.

> This should be fixable by (1) linking /usr/share/emacs's .el files
> into the emacs-FLAVOR hierarchies, then (2) removing /usr/share/emacs
> from load-path.  Ditto for site-lisp.

        Hmm. You mean for every flavour of emacs, symlink the files from
 /usr/share/emacs/ hierarchy into /usr/share/<flavour> hierachy, and
 then drop the former? 

>> > The only sane way out is to compile and manage your own Emacs and
>> > packages.  And that's what _all_ Emacs and XEmacs developers I know
>> > who are not simultaneously Debian maintainers do.
>> 
>> I think this is not the case, since a trivial work around is
>> available (add your dir to the head of the path).

> This simply isn't sufficient, except for the case of a person
> maintaining one or a few Lisp packages.  Don't bother asking for
> details; that's the product of experience with many small confusing
> problems, and if I *could* characterize the many confusingly small
> problems anything like that simply, I would have tried to fix those
> confusingly many small problems (all alike ;-), and probably I'd still
> be using Debianized Emacsen.  The best I've heard of is Miles's hack,
> but he apparently uses a non-Debianized Emacsen and a .emacs hack
> which adds /usr/share/emacs to his load-path (and I bet it's not at
> the head).

        I have in the past maintained Gnus, and still maintain VM, and I
 use CVS versions of org-mode, Emacs, DVC, and a couple of other minoir
 emacs packages. While I might not add much of my code to htese
 packages, I do routinely do git pull's and compiles and use them in my
 almost nihtly recompiles of CVS emacs.

        But hey, perhaps all the problems are indeed far above my
 head. It is just odd that they do not seem to  impede my playing with
 custom lisp code and development versions of Emacs.

> In other words, you're making the same mistake that Alan did.  Because
> the set of people who actively participate in Emacs (and XEmacs)
> development on a day-to-day basis does not AFAICT include the Debian
> Emacsen maintainers and especially those who maintain the Debian Emacs
> Policy, there is nobody who can speak authoritatively about how the
> DEP and Emacs development practice could be better integrated.

        I am one of the people responsible for Debian policies. ANd
 while I am not currently active in Debian Emacs policy, I was one of
 the people involved in crafting it way back when.

> Nevertheless, you and Joe extrapolate from personal experience and
> assume that since you don't run into problems, a little discipline
> would solve them for the developers, too.  That's just as wrong as
> Alan assuming that with a little more care the DEP could be adjusted
> so that he could use a Debianized Emacs in his usual way.

        Since I am actually doing all this, I can see how I can slip
 into the mistake of assuming it can be done.

        Anyway, if you do not want to engage into why normal Debian was
 of using Debianized emacsen do not work for you, and you are happy with
 your current set up, that's no skin off my nose either.

        manoj
-- 
A right is not what someone gives you; it's what no one can take from
you. Ramsey Clark
Manoj Srivastava <srivasta@acm.org> <http://www.golden-gryphon.com/>  
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C

Re: Emacs vista build failures

[Stephen J. Turnbull]

Manoj Srivastava writes:

 >         I do not think it is a typo. Debian installs an empty directory
 >  there, and never removes it; it is so that you can drop stuff in there
 >  to override the vendor installed stuff. I consider that a feature.

I guess it makes sense that /usr/local/share/emacs/site-lisp is on the
load-path when $prefix = /usr, but it causes me cognitive dissonance.
Rationale must be something like you can't go proliferating local
directories (that the admin can populate as she likes) like site-lisp
just because an application thinks that it's obviously for the use of
the admin.

As long as it's just the directory, yes, it's feature.  More than a
convenience, it tells you that it's Debian policy that you can put
stuff there and you can expect its contents to be found via load-path
(XEmacs at least prunes some directories with nothing loadable, so you
might not see it on load-path at first).

 > > That *is* crazy, and definitely hinders diagnosing bugs which are due
 > > to a mismatch between version expected and version provided by the
 > > shadowing library.  Developers and beta testers will typically have a
 > > few shadows, but in a standard installation to have *any* *is a bug*.
 > 
 > > This should be fixable by (1) linking /usr/share/emacs's .el files
 > > into the emacs-FLAVOR hierarchies, then (2) removing /usr/share/emacs
 > > from load-path.  Ditto for site-lisp.
 > 
 >         Hmm. You mean for every flavour of emacs, symlink the files from
 >  /usr/share/emacs/ hierarchy into /usr/share/<flavour> hierachy, and
 >  then drop the former? 

From load-path, yes.  Conceptually that's like a source tree, not
runnable libraries.

 > > This simply isn't sufficient, except for the case of a person
 > > maintaining one or a few Lisp packages.
[...]

 >         I have in the past maintained Gnus, and still maintain VM, and I
 >  use CVS versions of org-mode, Emacs, DVC, and a couple of other minoir
 >  emacs packages. While I might not add much of my code to htese
 >  packages, I do routinely do git pull's and compiles and use them in my
 >  almost nihtly recompiles of CVS emacs.

Which is what I said pushing one or more directories would be good
for.

 >         But hey, perhaps all the problems are indeed far above my
 >  head. It is just odd that they do not seem to  impede my playing with
 >  custom lisp code and development versions of Emacs.

I think you might have more problems with XEmacs since all XEmacsen
are expected to share the package hierarchy.

The other factor is that the problems may be beneath your notice; they
may be minor issues that a Debian maintainer deals with by not doing
stupid things (in the context of maintaining a Debian installation).
For example, Joe's point about what should and shouldn't go into
site-lisp.

 >         I am one of the people responsible for Debian policies. ANd
 >  while I am not currently active in Debian Emacs policy, I was one of
 >  the people involved in crafting it way back when.

And your authoritative suggestions for better integration might be? :-)

 >         Anyway, if you do not want to engage into why normal Debian was
 >  of using Debianized emacsen do not work for you,

Actually, I may just be about to do just that.

But for now, I'm just trying to point out that the experiences of the
two sides of this discussion are pretty much disjoint.  Until
somebody's both been deeply involved in Debian maintenance (of an
Emacs as well as some packages) and in core Emacs development, we all
have to be careful about understanding that people with different
opinions are probably basing them on different history and skills.

Debian's idiosyncratic complexification of Emacs [Was: Emacs vista build failures]

[Alan Mackenzie]

'Evening, Don!

On Mon, Jul 14, 2008 at 01:42:42PM -0700, Don Armstrong wrote:
> On Mon, 14 Jul 2008, David Kastrup wrote:
> > Alan Mackenzie <acm@muc.de> writes:
> > > It took me ~2 hours to get my Emacs to find my site-start.el -
> > > Debian (and thus Ubuntu too) puts a content-free site-start.el
> > > somewhere in /etc which blocks out your own real one.

> Just edit /etc/emacs/site-start.el if you want it emacs wide, or shove
> stuff into /etc/emacs<flavor>/site-start.d/; it's pretty trivial.
> [Though frankly, most things that people think they should shove into
> site-start.el doesn't belong there: it belongs in ~/.emacs.]

You know, there's something about that sort of reply which makes me want
to scream, possibly even want to strangle its writer;  it's the words
like "just" and "pretty trivial".  OF COURSE it's "pretty trivial", after
having wasted ~2 hours of my time tracking down the problem.  Those ~2
hours of my life are permanently lost, they're gone for ever, I'll never
get them back again.

I think I can confidently predict it has wasted similar amounts of time
for lots of other people, too.

What makes it not so bad is the belief that the Debian Emacs guy (is this
you, Don?) didn't create the existing setup with the intention of fouling
up expert Emacs users' setups, wasn't really intending to mess people
around unnecessarily.  However, if that had been his intention, surely he
would have done what he actually did, just with a dose of malice thrown
in.

> > Forget about Debian and Emacs. They use a clever system for sharing
> > package code between different Emacs versions (which you can install
> > at the same time) and XEmacs, so clever that nobody understands it.

> Lots of us understand it; it's pretty trivial. Thanks to that system,
> installing packaged emacs add-ons is absolutely trivial.

Tell me, why is it considered helpful to include a content-free
site-start.el?  The only thing this does is to prevent the loading of the
site-start.el in the standard Emacs place, i.e.
/usr/local/share/emacs/site-lisp/ (This is documented on page "Init File"
of the Emacs manual.)

> If you're lost, see
> http://www.debian.org/doc/packaging-manuals/debian-emacs-policy

Yes, that's all well and good.  Trouble is, when installing an operating
system like Debian, I'm not in the habit of grepping Debian's online
documentation for each package I'm installing, just on the off-chance
that the distro might have silently broken the package's normal
conventions.  That would markedly increase the time and tedium involved.

And even the maintainer of this document, debian-emacs-policy, admits
that it's not in an optimum state.  It's not clear what the purpose of
`debian-startup' is (Emacs works well without it), or to whom Emacs must
indicate its flavour (er, flavor ;-), and what that achieves.

I do not see the purpose of this extra layer of complexity that Debian
has wrapped around (X)Emacs.

> > I know of _no_ upstream Emacs or XEmacs developer who claims to
> > understand or get along with the Debian setup.

> There's no need for upstream developers to bother, since it's all
> handled for them by Debian Developers.

Sorry, Don, you're just wrong here.  It's _precisely_ the Debain
Developers' inclusion of the "blocking library"
(/etc/emacs<..>/site-start.el) which forces upstream developers like me
such bother.

Why is it necessary to include these content-free files?  Is there not
something that the Debian Emacs maintainer could do to resolve this
problem?  How about changing the order of the directories in load-path,
for example?

> Don Armstrong

-- 
Alan Mackenzie (Nuremberg, Germany).

Debian's idiosyncratic complexification of Emacs [Was: Emacs vista build failures]

[Stephen J. Turnbull]

 > On Mon, Jul 14, 2008 at 01:42:42PM -0700, Don Armstrong wrote:
 > > David Kastrup wrote:

 > > > Forget about Debian and Emacs. They use a clever system for sharing
 > > > package code between different Emacs versions (which you can install
 > > > at the same time) and XEmacs, so clever that nobody understands it.
 > 
 > > Lots of us understand it; it's pretty trivial.

I beg to differ.  The Debian Emacs Policy was a major PIMA for a
couple of years.  It may be simple to state by now, but its evolution
was complex.  The current state of peaceful coexistence required a
number of tweaks.

 > > Thanks to that system, installing packaged emacs add-ons is
 > > absolutely trivial.

Well, there are several other systems that make installing packaged
Emacs add-ons absolutely trivial.  Of course Debian would have a
massive case of indigestion if you used them on a Debian-installed
Emacsen, so they're kinda preempted.  And historically, Debian
installed add-ons caused a lot of annoyance to both upstream
developers and users of Debianized Emacsen.

Alan Mackenzie writes:

 > Tell me, why is it considered helpful to include a content-free
 > site-start.el?  The only thing this does is to prevent the loading
 > of the site-start.el in the standard Emacs place, i.e.
 > /usr/local/share/emacs/site-lisp/

Don't you mean $prefix/share/emacs/site-lisp?  IMHO, Debian should
leave /usr/local pretty much entirely alone, maybe looking there
late-ish in load-path or something.  Site configs for Debian's Emacsen
shouldn't be in /usr/local, though.  For the Debian-distributed Emacs,
prefix=/usr, and /usr/share/ needs to be reserved to Debian.  OTOH,
user settings kept in /etc/emacs/ will be carefully preserved by
Debian tools.

At one time it wasn't content-free, either.  In particular, it loaded
the initialization code for packaged Lisp.  This meant that you could
do --no-site-file in XEmacs (what's Emacs's idiom?) and do a packaged-
Lisp-free bug report on core features.  This is especially important
if you've got monkey-patch libraries like APEL around.

The easy thing to do is simply let Debian install an Emacs-to-keep-
deb-deps-happy, and put your developer's Emacs (pl?) in /usr/local or
/opt.  Each Emacsen will then look in the standard place relative to
its own $prefix (modulo Debian's redefinition of "standard").

 > And even the maintainer of this document, debian-emacs-policy, admits
 > that it's not in an optimum state.  It's not clear what the purpose of
 > `debian-startup' is (Emacs works well without it), or to whom Emacs must
 > indicate its flavour (er, flavor ;-), and what that achieves.

Emacs v. XEmacs and Mule v. no-Mule introduce various bytecode
incompatibilities.  "Flavor" is used to point load-path at compiled
Lisp that works for each variant.  AFAIK that's explained in the Emacs
Policy document, but it's been a while since I read it.

The David and Don Show returns:

 > > > I know of _no_ upstream Emacs or XEmacs developer who claims to
 > > > understand or get along with the Debian setup.
 > 
 > > There's no need for upstream developers to bother, since it's all
 > > handled for them by Debian Developers.

Except for bug reports.  Debian's XEmacs (unlike, say, Mandrivel's) is
quite clean of core patches, so I don't recall ever needing to fire up
a Debian XEmacs to diagnose a bug.  (Of course, if it looks like a
load-path issue, I always try to bounce it back to Debian, since it's
their load-path, not ours.  But even there --debug-paths (does Emacs
have this switch?) usually wins if the user comes back to us.)

And back to Alan:

 > Sorry, Don, you're just wrong here.  It's _precisely_ the Debain
 > Developers' inclusion of the "blocking library"
 > (/etc/emacs<..>/site-start.el) which forces upstream developers
 > like me such bother.

In the spirit of the GPL, Debian probably should have a notice on the
splash screen that they've moved the standard startup files, and a
link to an info node describing them.  I'd not be surprised if it's
already there but you just didn't notice it.

 > Why is it necessary to include these content-free files?  Is there not
 > something that the Debian Emacs maintainer could do to resolve this
 > problem?  How about changing the order of the directories in load-path,
 > for example?

"See above", "not much", and "obviously they already do that,
presumably with malice[sic] aforethought".

N.B. I come not to praise the Debian Emacs Policy, but to give it its
due: it's a reasonable compromise for the vast majority of users of
Emacsen.

Re: Debian's idiosyncratic complexification of Emacs

[Miles Bader]

"Stephen J. Turnbull" <stephen@xemacs.org> writes:
> N.B. I come not to praise the Debian Emacs Policy, but to give it its
> due: it's a reasonable compromise for the vast majority of users of
> Emacsen.

My impression is that debian's emacs _policy_ is more or less OK, and
it's a good thing they have one, but the last time I bothered to really
look, the code implementing it was a huge mess.  I asked about it then
on debian-emacsen, and the basic response was "we don't really
understand it either".

I hope it's better these days...

-Miles

-- 
Politeness, n. The most acceptable hypocrisy.

Re: Debian's idiosyncratic complexification of Emacs

[Geoffrey Teale]

On Jul 15, 2008, at 3:05 AM, Miles Bader wrote:

> "Stephen J. Turnbull" <stephen@xemacs.org> writes:
>> N.B. I come not to praise the Debian Emacs Policy, but to give it its
>> due: it's a reasonable compromise for the vast majority of users of
>> Emacsen.
>
> My impression is that debian's emacs _policy_ is more or less OK, and
> it's a good thing they have one, but the last time I bothered to  
> really
> look, the code implementing it was a huge mess.  I asked about it then
> on debian-emacsen, and the basic response was "we don't really
> understand it either".
>
> I hope it's better these days...

Whilst we are on the subject, for a large part of the last five years  
I have had to work with Debian and Debian based distributions and I  
quickly learned to simply not install the Debianised versions of GNU  
Emacs and install from source myself - particularly if I was  
interested in using Emacs 22 (and now 23) as the Debian packages were  
typically less stable.   Moreover I found that start up times for  
emacs on Debian are typically slow.

On a personal note - I find the idea of subverting the norms of an  
application to reduce usability in a distribution, not increase it.   
Especially where the tool in question (Emacs) is intended for a  
technical audience.

I am certain that the Debian set up is there with the best of  
intentions (just like their Common LISP setup), but nothing has made  
me more frustrated in a GNU/Linux distribution than the Emacs setup  
under debian, and anyone of my colleagues at my last employer we  
testify to that :)

-- 
Geoffrey Teale
Software and Technology Consultant, München
tealeg@member.fsf.org

Re: Debian's idiosyncratic complexification of Emacs

[Miles Bader]

Geoffrey Teale <tealeg@member.fsf.org> writes:
> On a personal note - I find the idea of subverting the norms of an
> application to reduce usability in a distribution, not increase it.
> Especially where the tool in question (Emacs) is intended for a
> technical audience.
>
> I am certain that the Debian set up is there with the best of intentions
> (just like their Common LISP setup), but nothing has made  me more
> frustrated in a GNU/Linux distribution than the Emacs setup  under
> debian, and anyone of my colleagues at my last employer we  testify to
> that :)

To be fair though, debian has constraints that don't hold for a normal
emacs installation, like the desire to integrate external elisp packages
seamlessly, have multiple versions of emacs installed simultaneously,
and for those two things to not screw each other up.

From what I know (I haven't looked at the details in ages though), I
think their approach is not too bad, though obviously it has warts,
historical and otherwise.  [I've even hacked up my .emacs so I can use
debian elisp packages, which is kind of convenient.]

Given that debian have reasonable goals, and aren't doing anything
egregiously stupid (no comment on that one, just assuming for the
moment... :-), it would be nice if emacs' default mechanisms would aid
what they're doing.  If there are conflicts, I think in many cases that
means emacs' mechanisms should be extended, rather than meaning debian
should give up their goals.

-Miles

-- 
Carefully crafted initial estimates reward you not only with
reduced computational effort, but also with understanding and
increased self-esteem.         -- Numerical methods in C,
  Chapter 9. "Root Finding and Nonlinear Sets of Equations"

Re: Debian's idiosyncratic complexification of Emacs

[David Kastrup]

Miles Bader <miles.bader@necel.com> writes:

> Given that debian have reasonable goals, and aren't doing anything
> egregiously stupid (no comment on that one, just assuming for the
> moment... :-),

At a sufficiently advanced level, egregiously smart and egregiously
stupid become indistinguishable.

> it would be nice if emacs' default mechanisms would aid what they're
> doing.  If there are conflicts, I think in many cases that means
> emacs' mechanisms should be extended, rather than meaning debian
> should give up their goals.

There is no point in separating the .elc from the .el as far as I can
see.  That is just begging for search path related conflicts and
different load path shadows for .el and .elc.  And since Debian is
restricted to platforms supporting symlinks, you don't even save any
disk space worth noting by working from a single .el directory.

So I don't see a point in making Emacs support what can only be called a
misguided configuration.

-- 
David Kastrup

Re: Debian's idiosyncratic complexification of Emacs

[Ralf Angeli]

* Stephen J. Turnbull (2008-07-15) writes:

> Except for bug reports.  Debian's XEmacs (unlike, say, Mandrivel's) is
> quite clean of core patches, so I don't recall ever needing to fire up
> a Debian XEmacs to diagnose a bug.  (Of course, if it looks like a
> load-path issue, I always try to bounce it back to Debian, since it's
> their load-path, not ours.

Just as an example, the Debian Emacs policy requires all Emacsen to have
/usr/local/share/emacs/site-lisp in `load-path', even XEmacs.  (See also
<URL:http://thread.gmane.org/d6qmdp$uor$1%40sea.gmane.org>.)  Like that
XEmacs will pick up files byte-compiled for Emacs.  This looks pretty
broken to me.

-- 
Ralf

Re: Debian's idiosyncratic complexification of Emacs

[David Kastrup]

Ralf Angeli <angeli@caeruleus.net> writes:

> * Stephen J. Turnbull (2008-07-15) writes:
>
>> Except for bug reports.  Debian's XEmacs (unlike, say, Mandrivel's) is
>> quite clean of core patches, so I don't recall ever needing to fire up
>> a Debian XEmacs to diagnose a bug.  (Of course, if it looks like a
>> load-path issue, I always try to bounce it back to Debian, since it's
>> their load-path, not ours.
>
> Just as an example, the Debian Emacs policy requires all Emacsen to
> have /usr/local/share/emacs/site-lisp in `load-path', even XEmacs.
> (See also <URL:http://thread.gmane.org/d6qmdp$uor$1%40sea.gmane.org>.)
> Like that XEmacs will pick up files byte-compiled for Emacs.  This
> looks pretty broken to me.

No, you don't understand: byte-compiled files should not go into
/usr/local/share/emacs/site-lisp.  This directory is only incidentally
named like a standard Emacs search path directory.  The byte-compiled
files are to be in another directory so that list-load-path-shadows has
something to think about.  And of course, any package installation that
thinks it might work by placing .elc in the same place as .el is naive.
And Emacs has a command byte-recompile-directory just by mistake.

And so on.  Really, the Debian policy is not broken.  It is just that
no-one, including Emacs and XEmacs itself, does not really appreciate
it.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Debian's idiosyncratic complexification of Emacs

[Ralf Angeli]

* David Kastrup (2008-07-15) writes:

> And so on.  Really, the Debian policy is not broken.  It is just that
> no-one, including Emacs and XEmacs itself, does not really appreciate
> it.

I'm assuming this is the dreaded Bavarian double negation.

-- 
Ralf

Re: Debian's idiosyncratic complexification of Emacs

[David Kastrup]

Ralf Angeli <angeli@caeruleus.net> writes:

> * David Kastrup (2008-07-15) writes:
>
>> And so on.  Really, the Debian policy is not broken.  It is just that
>> no-one, including Emacs and XEmacs itself, does not really appreciate
>> it.
>
> I'm assuming this is the dreaded Bavarian double negation.

Guilty, your honor.  However, let's not call it Bavarian.  It is pretty
much an element of any dialect.  How about the Yiddish negative?  "Keyn
mensh, un keyn Emacs un XEmacs nisht, ton keyn froydnshprung nisht."
Something like that.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Debian's idiosyncratic complexification of Emacs

[Manoj Srivastava]

On Tue, 15 Jul 2008 08:50:21 +0200, David Kastrup <dak@gnu.org> said: 

> No, you don't understand: byte-compiled files should not go into
> /usr/local/share/emacs/site-lisp.  This directory is only incidentally
> named like a standard Emacs search path directory.  The byte-compiled
> files are to be in another directory so that list-load-path-shadows
> has something to think about.

        Which directory is that?

> And of course, any package installation that thinks it might work by
> placing .elc in the same place as .el is naive.

        Assuming you are not just trying to pick a fight, the problem
 that needs to be solved is this:

        Any add-on packages that can be byte compiled for multiple
 versions of emacs (even versions not available when the package was
 created) do not know what versions are actually installed on the users
 machine. More than one version might be installed, and flavours of
 emacs might be removed, and other ones installed later on, and the
 elisp package must keep working for the end user, seamlessly.

        So, the elisp packages only ship .el files, and on the end users
 machine, looking at the emacs versions installed, the .el files are
 byte compiled, and kept in a different directory for each version of
 emacs found.

        When a flavour of emacs is installed, it finds all third party
 elisp package on the machine, and byte compiles them, and these byte
 compiled files are removed when that flavour of emacs is removed from
 the machine.

        Now, I think it is a fine idea to hard-link the .el files into
 all these separate emacs flavour directories, and perhaps the policy
 can be evolved to specify that, so you always find the .el files  in
 the same directory as the .elc files.

> And Emacs has a command byte-recompile-directory just by mistake.

        Emacs makes no attempt to cater to the issues facing third party
 elisp packages, so someone has to pick up where emacs developers stop.
 I have emacs 21, emacs 22, emacs-snapshot, and the latest XEmacs on
 this machine, and I also keep a non-debian git checkout emacs in
 /usr/local, and I have VM working flawlessly for all these flavours.

        If you have a better idea on how this should be done, please, I
 am all ears. Snarky remarks really do not help.

        manoj
-- 
broad-mindedness, n: The result of flattening high-mindedness out.
Manoj Srivastava <srivasta@acm.org> <http://www.golden-gryphon.com/>  
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C

Re: Debian's idiosyncratic complexification of Emacs

[David Kastrup]

Manoj Srivastava <srivasta@ieee.org> writes:

>         Now, I think it is a fine idea to hard-link the .el files into
>  all these separate emacs flavour directories, and perhaps the policy
>  can be evolved to specify that, so you always find the .el files  in
>  the same directory as the .elc files.

Should be symlinks, not hardlinks.  Hardlinks across directory
hierarchies can't be depended on since mount points can be anywhere.

-- 
David Kastrup

Re: Debian's idiosyncratic complexification of Emacs

[Stephen J. Turnbull]

Manoj Srivastava writes:
 > On Tue, 15 Jul 2008 08:50:21 +0200, David Kastrup <dak@gnu.org> said: 
 > 
 > > No, you don't understand: byte-compiled files should not go into
 > > /usr/local/share/emacs/site-lisp.  This directory is only incidentally
 > > named like a standard Emacs search path directory.  The byte-compiled
 > > files are to be in another directory so that list-load-path-shadows
 > > has something to think about.
 > 
 >         Which directory is that?

People here (with the exception of Stefan) have been very incautious
about distinguishing $prefix, /usr, and /usr/local.  Is that the issue
you refer to?

 > > And of course, any package installation that thinks it might work by
 > > placing .elc in the same place as .el is naive.
 > 
 >         Assuming you are not just trying to pick a fight, the problem
 >  that needs to be solved is this:

Emacs users and Emacs itself assume that the source for a compiled
library can be found in the same directory as the library itself.  If
as you and David imply, this is not true, the Debian installation
breaks standard practices of a great many long-time Emacs users.
These practices are taught to new users, too.

IOW, you've specified the problem incorrectly, at least if you want to
serve the traditionalists satisfactorily.

 > > And Emacs has a command byte-recompile-directory just by mistake.
 > 
 >         Emacs makes no attempt to cater to the issues facing third party
 >  elisp packages, so someone has to pick up where emacs developers stop.
 >  I have emacs 21, emacs 22, emacs-snapshot, and the latest XEmacs on
 >  this machine, and I also keep a non-debian git checkout emacs in
 >  /usr/local, and I have VM working flawlessly for all these flavours.
 > 
 >         If you have a better idea on how this should be done, please, I
 >  am all ears. Snarky remarks really do not help.

I don't have a better idea.  As David recommends, I'm a xemacs.deb
refusenik, with either a dummy (unused in daily work) installation or
even a virtual installation (ie, an empty package that provides the
emacs virtual package to keep dpkg happy).

The problem (for Debian) that you describe is real, and important.
There are an awful lot of Debian users who just want Emacsen to work,
and who keep all their personal development in .emacs, until it gets
accepted to the mainline.  There are multi-user, multi-Emacs hosts,
and certainly Lisp package maintainers need them.  The system works
well for them AFAICS, with the exception that some XEmacs users want
to use a few XEmacs packages from our archive, and that doesn't mix
well with a Debian installation.

However, trying to work with a Debianized X?Emacs in Emacs development
certainly creates a substantial burden.  Joe made the point that a lot
of stuff that's in many site-start.els doesn't belong there.  Well,
yes and no.  On my personal system, it *is* *my* site, and if I choose
to organize my .emacs by putting stuff that's relevant to all my users
in site-start, and stuff that's relevant only to root, mailman,
postgres, and my personal user respectively in .emacs, it is none of
Debian's business.  Debian's load-path and .d startup infrastructure
is pretty baroque (though easy to understand once you understand the
.d startup infrastructure in *any* context).  Navigating it in case of
a bug that manifests in a Debian install can be quite annoying.

Sure, it can be worked around, but I found it too great a burden for
the benefits, considering that most of the work would be duplicated by
Debian's Lisp package maintainers anyway.

Re: Debian's idiosyncratic complexification of Emacs

[Manoj Srivastava]

On Thu, 17 Jul 2008 05:42:11 +0900, Stephen J Turnbull <stephen@xemacs.org> said: 

> Manoj Srivastava writes:
>> On Tue, 15 Jul 2008 08:50:21 +0200, David Kastrup <dak@gnu.org> said:
>> 
>> > No, you don't understand: byte-compiled files should not go into
>> > /usr/local/share/emacs/site-lisp.  This directory is only
>> > incidentally named like a standard Emacs search path directory.
>> > The byte-compiled files are to be in another directory so that
>> > list-load-path-shadows has something to think about.
>> 
>> Which directory is that?

> People here (with the exception of Stefan) have been very incautious
> about distinguishing $prefix, /usr, and /usr/local.  Is that the issue
> you refer to?

>> > And of course, any package installation that thinks it might work
>> > by placing .elc in the same place as .el is naive.
>> 
>> Assuming you are not just trying to pick a fight, the problem that
>> needs to be solved is this:

> Emacs users and Emacs itself assume that the source for a compiled
> library can be found in the same directory as the library itself.  If
> as you and David imply, this is not true, the Debian installation
> breaks standard practices of a great many long-time Emacs users.
> These practices are taught to new users, too.

> IOW, you've specified the problem incorrectly, at least if you want to
> serve the traditionalists satisfactorily.

        Pardon me, I do think I know the problem that Debian was trying
 to solve when they implemented this mechanism. Yes, it does break the
 expectation that the .el and .elc files live in the same location; I'll
 see what can be done to correct that, while still addressing the
 problem that does need to be solved for Debian users (by adding
 symlinks as David noited is the right thing to do).

> The problem (for Debian) that you describe is real, and important.
> There are an awful lot of Debian users who just want Emacsen to work,
> and who keep all their personal development in .emacs, until it gets
> accepted to the mainline.  There are multi-user, multi-Emacs hosts,
> and certainly Lisp package maintainers need them.  The system works
> well for them AFAICS, with the exception that some XEmacs users want
> to use a few XEmacs packages from our archive, and that doesn't mix
> well with a Debian installation.

        Actually, I just add whole subdir trees (for a site-wide
 install) in /usr/local/share/emacs/site-lisp or add to the loadpath in
 .emacs (for a personal installation); which is slightly different than
 keeping all the code in .emacs.

> However, trying to work with a Debianized X?Emacs in Emacs development
> certainly creates a substantial burden.  Joe made the point that a lot
> of stuff that's in many site-start.els doesn't belong there.  Well,
> yes and no.  On my personal system, it *is* *my* site, and if I choose
> to organize my .emacs by putting stuff that's relevant to all my users
> in site-start, and stuff that's relevant only to root, mailman,
> postgres, and my personal user respectively in .emacs, it is none of
> Debian's business.

        Right. Nothing will ever edit or modify anything you put in
 /etc/emacs/site-start.el. 

> Debian's load-path and .d startup infrastructure is pretty baroque
> (though easy to understand once you understand the .d startup
> infrastructure in *any* context).  Navigating it in case of a bug that
> manifests in a Debian install can be quite annoying.

> Sure, it can be worked around, but I found it too great a burden for
> the benefits, considering that most of the work would be duplicated by
> Debian's Lisp package maintainers anyway.

        Sure. I am just puzzled as to why I am not experiencing _any_ of
 these issues. If I could reproduce some of the issues, perhaps I can do
 my bit to solve the problem for other folks too.

        manoj
-- 
Virtue is a relative term. Spock, "Friday's Child", stardate 3499.1
Manoj Srivastava <srivasta@acm.org> <http://www.golden-gryphon.com/>  
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C

Re: Debian's idiosyncratic complexification of Emacs

[Stephen J. Turnbull]

Manoj Srivastava writes:

 > > IOW, you've specified the problem incorrectly, at least if you want to
 > > serve the traditionalists satisfactorily.
 > 
 >         Pardon me, I do think I know the problem that Debian was trying
 >  to solve when they implemented this mechanism.

My apologies.  I do know who you (Manoj) are, and was addressing you
as a representative of the designers of the DEP.  I'm saying that to
serve this particular set of users, the designers omitted an important
requirement.

 >         Sure. I am just puzzled as to why I am not experiencing _any_ of
 >  these issues. If I could reproduce some of the issues, perhaps I can do
 >  my bit to solve the problem for other folks too.

Well, since nobody has actually been able to describe a problem, how
would you know?  I bet you *have* experienced them, and fixed them.
David and I are just more devious at finding ways to go wrong!

Anyway, after I clean up some other stuff and get moved back to Japan,
I have an XEmacs/distro integration project I'll be working on.  That
will be a good time for me to revisit this thread.

Re: Debian's idiosyncratic complexification of Emacs

[Agustin Martin]

2008/7/17 Manoj Srivastava <srivasta@ieee.org>:
>
>        Pardon me, I do think I know the problem that Debian was trying
>  to solve when they implemented this mechanism. Yes, it does break the
>  expectation that the .el and .elc files live in the same location; I'll
>  see what can be done to correct that, while still addressing the
>  problem that does need to be solved for Debian users (by adding
>  symlinks as David noited is the right thing to do).

Just noting that the symlinks approach has been proposed a while ago,

http://bugs.debian.org/122444

and the proposed change in policy seemed not controversial. However, no
changes in policy were done since then. As a matter of fact, no changes
were done for a long time, last emacsen-common Debian package is of
2006-01-17.

In the meantime some of us are setting symlinks in our packages as
proposed, with no apparent drawback.

Re: Debian's idiosyncratic complexification of Emacs [Was: Emacs vista build failures]

[Don Armstrong]

On Mon, 14 Jul 2008, Alan Mackenzie wrote:
> Those ~2 hours of my life are permanently lost, they're gone for
> ever, I'll never get them back again.

Perhaps I'm being elitist, but it took me all of 5 minutes to look up
the documentation for this, and rework through how this all was done.
 
> However, if that had been his intention, surely he would have done
> what he actually did, just with a dose of malice thrown in.

And no, it's not me.

>  Tell me, why is it considered helpful to include a content-free
> site-start.el?

We don't include a content-free site-start.el; here is its content:

;; Emacsen independent startup file.  All of the various installed
;; flavors of emacs (emacs 19, emacs 20, xemacs) will load this file
;; at startup.  Make sure any code you put here is emacs flavor
;; independent.

;; Package maintainers: do not have Debian packages edit this file.
;; See the policy manual for the proper way to handle Emacs package
;; initialization code.

> The only thing this does is to prevent the loading of the
> site-start.el in the standard Emacs place, i.e.
> /usr/local/share/emacs/site-lisp/ (This is documented on page "Init
> File" of the Emacs manual.)

Configuration files such as site-start.el need to be in /etc by FHS,
and by Debian policy.

> I do not see the purpose of this extra layer of complexity that
> Debian has wrapped around (X)Emacs.

The purpose is to make it possible for packages to work on specific
versions of emacs, all versions of emacs, for users to modify the
files and have their changes automatically respected, and to allow for
add-on packages to be easily installed and automatically configured to
work site-wide without the need for users to modify their own .emacs
files or do anything else to deal with it.

There may be better implementations of that complexity, but the
features that it gives are necessary, and frankly aren't something
that upstreams spend much time contemplating.


Don Armstrong

-- 
<Clint> why the hell does kernel-source-2.6.3 depend on xfree86-common?
<infinity> It... Doesn't?
<Clint> good point

http://www.donarmstrong.com              http://rzlab.ucr.edu

Re: Debian's idiosyncratic complexification of Emacs

[Stefan Monnier]

> We don't include a content-free site-start.el; here is its content:

> ;; Emacsen independent startup file.  All of the various installed
> ;; flavors of emacs (emacs 19, emacs 20, xemacs) will load this file
> ;; at startup.  Make sure any code you put here is emacs flavor
> ;; independent.

> ;; Package maintainers: do not have Debian packages edit this file.
> ;; See the policy manual for the proper way to handle Emacs package
> ;; initialization code.

That qualifies as "content free" in my book.

>> The only thing this does is to prevent the loading of the
>> site-start.el in the standard Emacs place, i.e.
>> /usr/local/share/emacs/site-lisp/ (This is documented on page "Init
>> File" of the Emacs manual.)

> Configuration files such as site-start.el need to be in /etc by FHS,
> and by Debian policy.

Then they should put a symlink from
/usr/share/emacs/site-lisp/site-start.el to /etc/emacs/site-start.el.


        Stefan

Re: Debian's idiosyncratic complexification of Emacs

[Don Armstrong]

On Mon, 14 Jul 2008, Stefan Monnier wrote:
> Then they should put a symlink from
> /usr/share/emacs/site-lisp/site-start.el to
> /etc/emacs/site-start.el.

Feel free to file a wishlist bug.


Don Armstrong

-- 
Frankly, if ignoring inane opinions and noisy people and not flaming
them to crisp is bad behaviour, I have not yet achieved a state of
nirvana.
 -- Manoj Srivastava in 87n04pzhmh.fsf@glaurung.internal.golden-gryphon.com

http://www.donarmstrong.com              http://rzlab.ucr.edu

Re: Debian's idiosyncratic complexification of Emacs [Was: Emacs vista build failures]

[Stephen J. Turnbull]

Don Armstrong writes:

 > Perhaps I'm being elitist, but it took me all of 5 minutes to look up
 > the documentation for this, and rework through how this all was done.

No, you're just forgetting what it is like to live in a world where
"debhelper" is a 9 character string, and nothing more.  FHS is
extremely well-known, but Alan apparently didn't connect that to the
location of site-start.el under /etc.  I've known about the Debian
Emacs Policy for at least 7, maybe more like 10, years by now, but it
doesn't surprise me that typical users would never have heard it
spoken (not even in anger :-).

Re: Debian's idiosyncratic complexification of Emacs [Was: Emacs vista build failures]

[Alan Mackenzie]

'Morning, Don!

On Mon, Jul 14, 2008 at 06:38:45PM -0700, Don Armstrong wrote:
> On Mon, 14 Jul 2008, Alan Mackenzie wrote:
> > Those ~2 hours of my life are permanently lost, they're gone for
> > ever, I'll never get them back again.

> Perhaps I'm being elitist, but it took me all of 5 minutes to look up
> the documentation for this, and rework through how this all was done.

Will you please get the point.  It isn't the time it takes to "look up
documentation", or the 35.72 seconds it takes to edit an elisp startup
file.  It's the two hours it takes from realising "something's not
working here", going through checking things like pertinent disk
partitions are mounted, there's no symbolic links fouling things up.
Maybe I'm hopelessly old-fashioned here, but when I see something not
working, I usually assume it's my fault, first.

If this sort of thing happened on every Debian package, and you install,
say, 100 packages at installation, this would add an extra 200 hours to
the installation process.

> And no, it's not me.

:-)

> >  Tell me, why is it considered helpful to include a content-free
> > site-start.el?

> We don't include a content-free site-start.el; here is its content:

> ;; Emacsen independent startup file.  All of the various installed
> ;; flavors of emacs (emacs 19, emacs 20, xemacs) will load this file
> ;; at startup.  Make sure any code you put here is emacs flavor
> ;; independent.

> ;; Package maintainers: do not have Debian packages edit this file.
> ;; See the policy manual for the proper way to handle Emacs package
> ;; initialization code.

Er, I said "content-free", not "comment-free".

Even so, there is a bug here.  "the policy manual" should be identified,
otherwise another two hours will be wasted by each person who tracks it
down, or more likely, who attempts to track it down.

> > The only thing this does is to prevent the loading of the
> > site-start.el in the standard Emacs place, i.e.
> > /usr/local/share/emacs/site-lisp/ (This is documented on page "Init
> > File" of the Emacs manual.)

> Configuration files such as site-start.el need to be in /etc by FHS,
> and by Debian policy.

<scream of rage> site-start.el typically goes in
/usr/local/share/emacs/site-lisp, according to the Emacs documentation.
So there is a conflict here between an upstream package's recommendations
and Debian's policies.  OK, it's not as bad as for qmail, but it exists.
I've got a lot of sympathy for qmail's author (Dan Bernstein)'s
insistence that qmail's files went into _exactly_ the same location in
any installation.

You seem to be taking the view that it's OK for Debian to completely
supersede upstream policies - you use the wording "need to be" rather
than the more accurate "ought to be".

I don't think this is OK at all.  It causes the waste of lots of lots of
people's time.  I think Debian has an onus to try and conform to upstream
package policies AS WELL AS its own.  For Emacs a solution is clear: put
/etc/... lower in load-path than /usr/local/share/.....

> > I do not see the purpose of this extra layer of complexity that
> > Debian has wrapped around (X)Emacs.

> The purpose is to make it possible for packages to work on specific
> versions of emacs, all versions of emacs, for users to modify the
> files and have their changes automatically respected, and to allow for
> add-on packages to be easily installed and automatically configured to
> work site-wide without the need for users to modify their own .emacs
> files or do anything else to deal with it.

OK, thanks!

> There may be better implementations of that complexity, but the
> features that it gives are necessary, ....

I'm trying to picture where this might be useful.  Typically, an Emacs
user on his home box is going to have exactly one version of (X)Emacs
installed, so the complexity will be a burden.  An Emacs hacker, such as
all of us, is going to have several, or even many, (X)Emacs versions
hanging around, in his own custom built directory structure, and will
probably have built these from source.  I can't see Debian's complexity
being useful for either of these (though I may be wrong).  A sysadmin
administering a mutil-hacker development shop would surely find it
useful.
 
> .... and frankly aren't something that upstreams spend much time
> contemplating.

You're not wrong there!

> Don Armstrong

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: Debian's idiosyncratic complexification of Emacs

[David Kastrup]

Alan Mackenzie <acm@muc.de> writes:

> I'm trying to picture where this might be useful.  Typically, an Emacs
> user on his home box is going to have exactly one version of (X)Emacs
> installed, so the complexity will be a burden.  An Emacs hacker, such
> as all of us, is going to have several, or even many, (X)Emacs
> versions hanging around, in his own custom built directory structure,
> and will probably have built these from source.

An Emacs package hacker will have to have several versions of Emacs as
well as XEmacs installed.  Although he will not really need them
integrated with the system.

On multi-user systems, different Emacsen might be prefered by different
people.

> I can't see Debian's complexity being useful for either of these
> (though I may be wrong).  A sysadmin administering a mutil-hacker
> development shop would surely find it useful.

Probably.  But it should still be sufficient to provide packages just
for a single version of Emacs, and to provide XEmacs packages completely
separately (Sumo alone calls for that).

-- 
David Kastrup

Re: Debian's idiosyncratic complexification of Emacs

[Manoj Srivastava]

On Tue, 15 Jul 2008 10:15:19 +0000, Alan Mackenzie <acm@muc.de> said: 

> 'Morning, Don!
> On Mon, Jul 14, 2008 at 06:38:45PM -0700, Don Armstrong wrote:
>> On Mon, 14 Jul 2008, Alan Mackenzie wrote:
>> > Those ~2 hours of my life are permanently lost, they're gone for
>> > ever, I'll never get them back again.

>> Perhaps I'm being elitist, but it took me all of 5 minutes to look up
>> the documentation for this, and rework through how this all was done.

> Will you please get the point.  It isn't the time it takes to "look up
> documentation", or the 35.72 seconds it takes to edit an elisp startup
> file.  It's the two hours it takes from realising "something's not
> working here", going through checking things like pertinent disk
> partitions are mounted, there's no symbolic links fouling things up.
> Maybe I'm hopelessly old-fashioned here, but when I see something not
> working, I usually assume it's my fault, first.

> If this sort of thing happened on every Debian package, and you
> install, say, 100 packages at installation, this would add an extra
> 200 hours to the installation process.

        Well, on a Debian system, the norm is to expect to be able to
 edit any configuration file under /etc. So, I would start looking into
 /etc for any Debian package -- even emacs (my /usr is mounted
 read-only, and often the /usr/share is actually shared).


>> >  Tell me, why is it considered helpful to include a content-free
>> > site-start.el?

        A placeholder to let users  know there is something to edit, and
 where it is (you can look at the dpkg -L output, and grep for site-start.el

> Even so, there is a bug here.  "the policy manual" should be
> identified, otherwise another two hours will be wasted by each person
> who tracks it down, or more likely, who attempts to track it down.

        I think the Debian technical policy manual hint is for package
 maintainers; they had bloody well better know what the policy
 manual is and what it contains.

>> Configuration files such as site-start.el need to be in /etc by FHS,
>> and by Debian policy.

>> scream of rage> site-start.el typically goes in
> /usr/local/share/emacs/site-lisp, according to the Emacs
> documentation.  So there is a conflict here between an upstream
> package's recommendations and Debian's policies.  OK, it's not as bad
> as for qmail, but it exists.  I've got a lot of sympathy for qmail's
> author (Dan Bernstein)'s insistence that qmail's files went into
> _exactly_ the same location in any installation.

        Well, I am afraid that systems integration means that sometimes
 you have to change upstream conventions in order for the software to
 integrate better into the distribution; though I believe a symbolic
 link in $PREFIX/share/emacs/site-lisp is not a bad idea.

> You seem to be taking the view that it's OK for Debian to completely
> supersede upstream policies - you use the wording "need to be" rather
> than the more accurate "ought to be".

        I think that is an accurate description of Debian's stance on
 systems integration.

> I don't think this is OK at all.  It causes the waste of lots of lots
> of people's time.  I think Debian has an onus to try and conform to
> upstream package policies AS WELL AS its own.  For Emacs a solution is
> clear: put /etc/... lower in load-path than /usr/local/share/.....

        As far as possible, sure. But  when there is a direct conflict,
 the only sane way top resolve this for _all_ packages is to have
 a technical policy that is actually observed, all the time, and not
 just haphazardly.

>> There may be better implementations of that complexity, but the
>> features that it gives are necessary, ....

> I'm trying to picture where this might be useful.  Typically, an Emacs
> user on his home box is going to have exactly one version of (X)Emacs
> installed, so the complexity will be a burden.  An Emacs hacker, such
> as all of us, is going to have several, or even many, (X)Emacs
> versions hanging around, in his own custom built directory structure,
> and will probably have built these from source.  I can't see Debian's
> complexity being useful for either of these (though I may be wrong).
> A sysadmin administering a mutil-hacker development shop would surely
> find it useful.

        But we  also try to catrer to people who are on multi-user
 systems, and thus have different needs; my work machines have multiple
 editors available (couple of emacsen, eclipse, all kinds of vi-clones),
 since different people might use them, and I often have several emacs
 versions installed, in order to test of the few emacs add ons I still
 maintain.
 
        manoj
-- 
Lost interest?  It's so bad I've lost apathy.
Manoj Srivastava <srivasta@acm.org> <http://www.golden-gryphon.com/>  
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C

Re: Debian's idiosyncratic complexification of Emacs

[Stefan Monnier]

>         Well, on a Debian system, the norm is to expect to be able to
>  edit any configuration file under /etc. So, I would start looking into
>  /etc for any Debian package -- even emacs (my /usr is mounted
>  read-only, and often the /usr/share is actually shared).

That's a very good policy indeed.  But it's also good practice for the
same file to also be available at the place usually specified by the
upstream version.  I.e. unify the upstream package's conventions
with Debian's.

E.g. add a symlink from /usr/share/emacs/site-lisp/site-start.el to
/etc/emacs/site-start.el or something like that.

> though I believe a symbolic link in $PREFIX/share/emacs/site-lisp is
> not a bad idea.

That would be great, thanks.


        Stefan

Re: Debian's idiosyncratic complexification of Emacs

[Karl Fogel]

Don Armstrong <don@donarmstrong.com> writes:
>> The only thing this does is to prevent the loading of the
>> site-start.el in the standard Emacs place, i.e.
>> /usr/local/share/emacs/site-lisp/ (This is documented on page "Init
>> File" of the Emacs manual.)
>
> Configuration files such as site-start.el need to be in /etc by FHS,
> and by Debian policy.

Why not put a line in the regular site-start.el -- the one in the
Emacs-standard location, not the one in /etc/emacs/site-start.el -- that
loads /etc/emacs/site-start.el?

Or if the problem is that Debian isn't allowed to touch anything under
/usr/local/, then put code in /etc/emacs/site-start.el that loads
/usr/share/.../site-start.el and /usr/local/share/.../site-start.el (and
same for any other potentially blocked 'site-start.el's).

Wouldn't that solve all the problems here?

Do you need a bug filed at bugs.debian.org, or is this email enough?

Best,
-Karl

Re: Debian's idiosyncratic complexification of Emacs

[Karl Fogel]

On Wed, Jul 16, 2008 at 3:43 PM, Karl Fogel <kfogel@red-bean.com> wrote:
> Or if the problem is that Debian isn't allowed to touch anything under
> /usr/local/, then put code in /etc/emacs/site-start.el that loads
> /usr/share/.../site-start.el and /usr/local/share/.../site-start.el (and
> same for any other potentially blocked 'site-start.el's).

By "loads", I mean "conditionally loads", of course -- no error if the
loadee isn't present.

-K

Re: Debian's idiosyncratic complexification of Emacs

[Manoj Srivastava]

On Wed, 16 Jul 2008 15:43:03 -0400, Karl Fogel <kfogel@red-bean.com> said: 

> Don Armstrong <don@donarmstrong.com> writes:
>>> The only thing this does is to prevent the loading of the
>>> site-start.el in the standard Emacs place, i.e.
>>> /usr/local/share/emacs/site-lisp/ (This is documented on page "Init
>>> File" of the Emacs manual.)
>> 
>> Configuration files such as site-start.el need to be in /etc by FHS,
>> and by Debian policy.

> Why not put a line in the regular site-start.el -- the one in the
> Emacs-standard location, not the one in /etc/emacs/site-start.el --
> that loads /etc/emacs/site-start.el?

> Or if the problem is that Debian isn't allowed to touch anything under
> /usr/local/, then put code in /etc/emacs/site-start.el that loads
> /usr/share/.../site-start.el and /usr/local/share/.../site-start.el
> (and same for any other potentially blocked 'site-start.el's).

        While Debian maintainers can not touch anything under
 /usr/local, Debian install emacs with the PREFIX=/usr, and
 /usr/share/emacs/site-lisp/site-start.el Could be made to load the file
 under /etc.

> Wouldn't that solve all the problems here?

        Either the symlink or the modified version put in
 $PREFIX/share/emacs/site-lisp/site-start.el will solve the issue, yes. 

> Do you need a bug filed at bugs.debian.org, or is this email enough?

        I'll file the bug report. Mind you, I am not the maintainer, so
 I can't guarantee how fast it will be acted upon, but I'll at least put
 in a pointer to this discussion in my bug report.

        manoj
-- 
Genius is one percent inspiration and ninety-nine percent
perspiration. Thomas Alva Edison
Manoj Srivastava <srivasta@acm.org> <http://www.golden-gryphon.com/>  
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C

Re: Debian's idiosyncratic complexification of Emacs

[Karl Fogel]

Manoj Srivastava <srivasta@ieee.org> writes:
>> Or if the problem is that Debian isn't allowed to touch anything under
>> /usr/local/, then put code in /etc/emacs/site-start.el that loads
>> /usr/share/.../site-start.el and /usr/local/share/.../site-start.el
>> (and same for any other potentially blocked 'site-start.el's).
>
>         While Debian maintainers can not touch anything under
>  /usr/local, Debian install emacs with the PREFIX=/usr, and
>  /usr/share/emacs/site-lisp/site-start.el Could be made to load the file
>  under /etc.
>
>> Wouldn't that solve all the problems here?
>
>         Either the symlink or the modified version put in
>  $PREFIX/share/emacs/site-lisp/site-start.el will solve the issue, yes. 

I think we're almost there.

The trick is not to load the one in /etc, but to have the one in /etc
load whatever other ones exist -- some of which may be user-produced and
shadowed by the one in /etc.

The problem, IIUC, is that Emacs loads the first site-start.el it finds
in load-path, and no others.  Since the /etc one is Debian-maintained,
it is free to find the others (in likely places) and load them.  As long
as it does so last, everything will work out fine: user-created code
will be evaluated after Debian-created code, which is what we want.

>> Do you need a bug filed at bugs.debian.org, or is this email enough?
>
>         I'll file the bug report. Mind you, I am not the maintainer, so
>  I can't guarantee how fast it will be acted upon, but I'll at least put
>  in a pointer to this discussion in my bug report.

Thanks.

-Karl

Re: Debian's idiosyncratic complexification of Emacs

[Miles Bader]

Incidentally, while on the issue of debian emacs startup, I have the
following snippet in my .emacs file for hooking my non-debian emacs into
the debian emacs package system:

   ;; Debian stuff
   (unless (boundp 'debian-emacs-flavor)
     (load "/usr/share/emacs/site-lisp/debian-startup")
     (debian-startup 'emacs22)
     (debian-startup 'emacs22))

["emacs22" because there is no emacs23 in debian yet]

It does appear to work (I can even use complicated packages like ecb
installed via aptitude), but is obviously slightly odd; is there a
better way than this?

AFAICT, the multiple calls to `debian-startup' are necessary -- it
doesn't work with just one -- which is one of the weird things nobody
seemed to understand when I asked about it a few years about on
debian-emacsen....

Thanks,

-Miles

-- 
Run away!  Run away!

Re: Debian's idiosyncratic complexification of Emacs

[Manoj Srivastava]

On Tue, 22 Jul 2008 13:27:23 +0900, Miles Bader <miles.bader@necel.com> said: 

> Incidentally, while on the issue of debian emacs startup, I have the
> following snippet in my .emacs file for hooking my non-debian emacs
> into the debian emacs package system:

>    ;; Debian stuff
>    (unless (boundp 'debian-emacs-flavor)
>      (load "/usr/share/emacs/site-lisp/debian-startup")
>      (debian-startup 'emacs22) (debian-startup 'emacs22))

> ["emacs22" because there is no emacs23 in debian yet]

> It does appear to work (I can even use complicated packages like ecb
> installed via aptitude), but is obviously slightly odd; is there a
> better way than this?

> AFAICT, the multiple calls to `debian-startup' are necessary -- it
> doesn't work with just one -- which is one of the weird things nobody
> seemed to understand when I asked about it a few years about on
> debian-emacsen....

        Strange. Here is my variant:
(if (emacs-type-eq 'fsf)
    (if (emacs-version=  23 )
        (progn
          (add-to-list 'load-path "/usr/share/emacs/site-lisp/")
          (add-to-list 'load-path "/usr/local/share/emacs/site-lisp/")
          (defconst debian-emacs-flavor 'emacs22)
          (load "debian-startup")
          (debian-startup 'emacs-snapshot))))

        This seems to work fine, with just a single invocation.

        manoj
-- 
Only God can make random selections.
Manoj Srivastava <srivasta@acm.org> <http://www.golden-gryphon.com/>  
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C

Re: Debian's idiosyncratic complexification of Emacs

[Michael Olson]

[-- Attachment #1.1: Type: text/plain, Size: 849 bytes --]

Miles Bader <miles.bader@necel.com> writes:

> Incidentally, while on the issue of debian emacs startup, I have the
> following snippet in my .emacs file for hooking my non-debian emacs
> into the debian emacs package system:
>
>    ;; Debian stuff
>    (unless (boundp 'debian-emacs-flavor)
>      (load "/usr/share/emacs/site-lisp/debian-startup")
>      (debian-startup 'emacs22)
>      (debian-startup 'emacs22))
>
> ["emacs22" because there is no emacs23 in debian yet]

Here's my setup.  The first attachment is a script to run in the emacs
source directory as root after doing "./configure ; make".  It depends
on a fake emacs-snapshot package built using equivs.

The second attachment is an init file that handles all the Debian stuff,
including a rewrite of `debian-run-directories' to make its
modifications to load-path less intrusive.


[-- Attachment #1.2: Type: application/pgp-signature, Size: 188 bytes --]

[-- Attachment #2: restore-emacs --]
[-- Type: text/plain, Size: 925 bytes --]

#!/bin/bash
#
# Restore custom-compiled emacs

if test ! -d ./lisp/emacs-lisp; then
    echo "You are not in the right directory."
    exit 1
fi

if test "$UID" != "0"; then
    echo "You must be root to run this."
    exit 1
fi

echo "Stage 1: Installing emacs ..."
make install

echo "Stage 2: Install fake emacs-snapshot package ..."
dpkg -i ../../emacs-snapshot_1.0_i386.deb

echo "Done."
echo "Stage 2: Making symlinks ..."
latest=$(cd /usr/local/share/emacs && echo 23.* | tr ' ' '\n' | sort \
    | tail -n 1)
ln -sf /usr/local/share/emacs/$latest /usr/share/emacs-snapshot
ln -sf /usr/local/bin/emacs /usr/bin/emacs-snapshot
mkdir -p /etc/emacs-snapshot/site-start.d

echo "Done."
echo "Stage 3: Installing emacs-snapshot flavor ..."
echo >> /var/lib/emacsen-common/installed-flavors
echo emacs-snapshot >> /var/lib/emacsen-common/installed-flavors
/usr/lib/emacsen-common/emacs-install emacs-snapshot

echo "Done."


[-- Attachment #3: debian-init.el --]
[-- Type: application/emacs-lisp, Size: 4263 bytes --]

[-- Attachment #4: Type: text/plain, Size: 237 bytes --]


-- 
|       Michael Olson  |  FSF Associate Member #652     |
| http://mwolson.org/  |  Hobbies: Lisp, HCoop          |
| Projects: Emacs, Muse, ERC, EMMS, ErBot, DVC, Planner |
`-------------------------------------------------------'

Re: Debian's idiosyncratic complexification of Emacs

[Stefan Monnier]

>> Incidentally, while on the issue of debian emacs startup, I have the
>> following snippet in my .emacs file for hooking my non-debian emacs
>> into the debian emacs package system:
>> 
>> ;; Debian stuff
>> (unless (boundp 'debian-emacs-flavor)
>> (load "/usr/share/emacs/site-lisp/debian-startup")
>> (debian-startup 'emacs22)
>> (debian-startup 'emacs22))
>> 
>> ["emacs22" because there is no emacs23 in debian yet]

It strikes me that Debian's Emacsen seem to not be plain enough.
I mean, Debian seems to change Emacs's startup.el even tho there's no
need for it.  Instead of changing startup.el to (load "debian-startup")
and call some magic function in it, it'd be much better to leave Emacs's
own startup code unchanged and simply provide a site-start.el that loads
debian-startup as well as /etc/emacs/site-start.el and all the rest.

I can't see why this can't work just a well as the current setup, with
the advantage of minimizing the difference between a plain Emacs and
a Debian Emacs (and clearly documenting this difference since it's kept
in a user-visible file rather than stashed in an internal source file
only available if you install the emacs-el package).


        Stefan

Re: Debian's idiosyncratic complexification of Emacs

[Manoj Srivastava]

On Wed, 23 Jul 2008 15:49:59 -0400, Stefan Monnier
<monnier@iro.umontreal.ca> said:  

> It strikes me that Debian's Emacsen seem to not be plain enough.  I
> mean, Debian seems to change Emacs's startup.el even tho there's no
> need for it.  Instead of changing startup.el to (load
> "debian-startup") and call some magic function in it, it'd be much
> better to leave Emacs's own startup code unchanged and simply provide
> a site-start.el that loads debian-startup as well as
> /etc/emacs/site-start.el and all the rest.

        Well, site-start.el was deemed to be for site specific stuff,
 and is shipped empty by the vendor (i.e., Debian). The Studd in
 startup.el is only to cater to the vendor changes for third party Elisp
 packages, and is not really a site specific change. This means that the
 load-path is customized even when --no-site-file is specified.

> I can't see why this can't work just a well as the current setup, with
> the advantage of minimizing the difference between a plain Emacs and a
> Debian Emacs (and clearly documenting this difference since it's kept
> in a user-visible file rather than stashed in an internal source file
> only available if you install the emacs-el package).


        Isn't there some issue with order of loading there? By modifying
 startup.el, changes are made that allow setting load-path before _any_
 action is taken, namely, language setting, window system
 initialization, and option processing.  So the two things are not
 equivalent.

        manoj

        Here is the full extent of the change in startup.el
--8<---------------cut here---------------start------------->8---
@@ -381,6 +381,10 @@ from being initialized."
 
 (defvar normal-top-level-add-subdirs-inode-list nil)
 
+(defconst debian-emacs-flavor 'emacs-snapshot
+  "A symbol representing the particular debian flavor of emacs running.
+Something like 'emacs20, 'xemacs20, etc.")
+
 (defvar no-blinking-cursor nil)
 
 (defvar default-frame-background-mode)
@@ -953,8 +957,13 @@ opening the first frame (e.g. open a connection to an X server).")
     ;; should check init-file-user instead, since that is already set.
     ;; See cus-edit.el for an example.
     (if site-run-file
-	(load site-run-file t t))
-
+        (progn
+          ;; Load all the debian package snippets.
+          ;; It's in here because we want -q to kill it too.
+          (if (load "debian-startup" t t nil)
+              (debian-startup debian-emacs-flavor))
+          ;; Now the normal site file...
+          (load site-run-file t t nil)))
     ;; Sites should not disable this.  Only individuals should disable
     ;; the startup screen.
     (setq inhibit-startup-screen nil)
--8<---------------cut here---------------end--------------->8---

-- 
Forsan et haec olim meminisse juvabit.
Manoj Srivastava <srivasta@acm.org> <http://www.golden-gryphon.com/>  
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C

Re: Debian's idiosyncratic complexification of Emacs

[Stefan Monnier]

>>>>> "Manoj" == Manoj Srivastava <srivasta@ieee.org> writes:

> On Wed, 23 Jul 2008 15:49:59 -0400, Stefan Monnier
> <monnier@iro.umontreal.ca> said:  

>> It strikes me that Debian's Emacsen seem to not be plain enough.  I
>> mean, Debian seems to change Emacs's startup.el even tho there's no
>> need for it.  Instead of changing startup.el to (load
>> "debian-startup") and call some magic function in it, it'd be much
>> better to leave Emacs's own startup code unchanged and simply provide
>> a site-start.el that loads debian-startup as well as
>> /etc/emacs/site-start.el and all the rest.

>         Well, site-start.el was deemed to be for site specific stuff,
>  and is shipped empty by the vendor (i.e., Debian).

AFAICT, Debian's site-specific stuff is in /etc/debian/site-start.el, so
they could use /usr/share/emacs/<revnum>/site-lisp/start-start.el for
the Debian-specific changes.

>  The Studd in startup.el is only to cater to the vendor changes for
>  third party Elisp packages, and is not really a site specific
>  change. This means that the load-path is customized even
>  when --no-site-file is specified.

I don't understand what you mean here.  AFAICT, the Debian changes are
executed iff the site-start.el file is loaded, so they could do it in
the site-start.el file just as well.

>         Isn't there some issue with order of loading there? By modifying
>  startup.el, changes are made that allow setting load-path before _any_
>  action is taken, namely, language setting, window system
>  initialization, and option processing.  So the two things are not
>  equivalent.

There could be.  But as the patch you sent shows, it doesn't apply here:
the debian-specific changes are placed right before loading
site-start.el, so they could just as well be placed directly in
site-start.el.


        Stefan

Re: Debian's idiosyncratic complexification of Emacs

[Lennart Borgman (gmail)]

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

Karl Fogel wrote:
> Manoj Srivastava <srivasta@ieee.org> writes:
>>> Or if the problem is that Debian isn't allowed to touch anything under
>>> /usr/local/, then put code in /etc/emacs/site-start.el that loads
>>> /usr/share/.../site-start.el and /usr/local/share/.../site-start.el
>>> (and same for any other potentially blocked 'site-start.el's).
>>         While Debian maintainers can not touch anything under
>>  /usr/local, Debian install emacs with the PREFIX=/usr, and
>>  /usr/share/emacs/site-lisp/site-start.el Could be made to load the file
>>  under /etc.
>>
>>> Wouldn't that solve all the problems here?
>>         Either the symlink or the modified version put in
>>  $PREFIX/share/emacs/site-lisp/site-start.el will solve the issue, yes. 
> 
> I think we're almost there.
> 
> The trick is not to load the one in /etc, but to have the one in /etc
> load whatever other ones exist -- some of which may be user-produced and
> shadowed by the one in /etc.
> 
> The problem, IIUC, is that Emacs loads the first site-start.el it finds
> in load-path, and no others.  Since the /etc one is Debian-maintained,
> it is free to find the others (in likely places) and load them.  As long
> as it does so last, everything will work out fine: user-created code
> will be evaluated after Debian-created code, which is what we want.


I have attached a site-start.el that maybe can be used for the common
site-start.el



[-- Attachment #2: site-start.el --]
[-- Type: text/plain, Size: 2475 bytes --]

;;; site-start.el --- Common site-start, will start user siste-start
;;
;; Author: Lennart Borgman (lennart O borgman A gmail O com)
;; Created: 2008-07-21T23:48:58+0200 Mon
;; Version: 0.5
;; Last-Updated: 2008-07-22T00:04:41+0200 Mon
;; URL:
;; Keywords:
;; Compatibility:
;;
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;;
;;; Commentary:
;;
;; Written for the Debian packaging problem.
;;
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;;
;;; Change log:
;;
;;
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;;
;; This program is free software; you can redistribute it and/or
;; modify it under the terms of the GNU General Public License as
;; published by the Free Software Foundation; either version 2, or
;; (at your option) any later version.
;;
;; This program is distributed in the hope that it will be useful,
;; but WITHOUT ANY WARRANTY; without even the implied warranty of
;; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
;; General Public License for more details.
;;
;; You should have received a copy of the GNU General Public License
;; along with this program; see the file COPYING.  If not, write to
;; the Free Software Foundation, Inc., 51 Franklin Street, Fifth
;; Floor, Boston, MA 02110-1301, USA.
;;
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;;
;;; Code:

(message "Common site-start running ...")

;; Load the users site-start file.
(let* ((this-dir
        (file-truename
         (file-name-as-directory
          (file-name-directory
           (if load-file-name load-file-name buffer-file-name)))))
       (load-path
        (mapcar
         (lambda (path)
           (unless (string= this-dir
                            (file-truename
                             (file-name-as-directory
                              (expand-file-name path))))
             path))
         load-path)))
  (setq load-path (delq nil load-path))
  ;;(message "this-dir=%s" this-dir)
  ;;(with-current-buffer "*Messages*" (insert (pp-to-string load-path)))
  (let ((user-site-start (locate-library "site-start")))
    (if user-site-start
        (progn
          (message "SITE-START: Loading user %s" user-site-start)
          (load-file user-site-start))
      (message "SITE-START: There was no user specific site-start.el(c)"))))


;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;;; site-start.el ends here

Re: Emacs vista build failures

[Stefan Monnier]

Excuse me, but could you move this discussion elsewhere?
Discussing the relative ethics of Windows and GNU/Linux might be
borderline, but discussing which one is technically better or easier to
install is clearly off topic.


        Stefan

Re: Emacs vista build failures

[Richard M Stallman]

    In that case, should not investigating hardware be something that is 
    done as earlier as possible in the installation process - with a 
    possibility for the user to just back off if the installation process 
    finds hardware it does not recognize.

The best time to investigate hardware is before you buy it.
So we have fsf.org/resource/hw.
(Or maybe it is fsf.org/resources/hw; I can't check from here.)

However, your idea seems like a good one.
I don't know whether distros have already done this or not,
but if they have not, it would be good to suggest this to
maintainers.

Re: Emacs vista build failures

[Richard M Stallman]

    Richard, you're perhaps the brightest guy around, here.  How long did it
    take you to get your first GNU/Linux installation installed and _fully_
    working (i.e. all peripherals, networking, X-Windows, email,
    web-browsing, ....  all satisfactory)?

I have never done this myself.  Perhaps that's why I am the brightest
guy around ;-).

Actually, what's best to do depends on your goals.  If your wish is to
get a machine running ASAP, ask (or even pay) an expert to do it.
If your wish is to learn more about GNU/Linux system administration,
installing it yourself is a good way to learn.

foryou

Re: Emacs vista build failures

[Alan Mackenzie]

'Evening, Richard!

On Mon, Jul 14, 2008 at 01:38:28PM -0400, Richard M Stallman wrote:
>     Richard, you're perhaps the brightest guy around, here.  How long
>     did it take you to get your first GNU/Linux installation installed
>     and _fully_ working (i.e. all peripherals, networking, X-Windows,
>     email, web-browsing, ....  all satisfactory)?

> I have never done this myself.  Perhaps that's why I am the brightest
> guy around ;-).

That's wonderful!  :-)

> Actually, what's best to do depends on your goals.  If your wish is to
> get a machine running ASAP, ask (or even pay) an expert to do it.  If
> your wish is to learn more about GNU/Linux system administration,
> installing it yourself is a good way to learn.

> foryou

I suppose it never really occurred to me to get help.  Hey, I'm a
hacker, an expert, I can do anything!!!!  But, I can get bored to tears
as easily as the next man.

You know, Richard, if by some accident of history you had somehow come
to write a Texinfo manual for GNU/Linux network configuration, the free
software world would now be a much happier place.

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: Emacs vista build failures

[Thomas Lord]

re much discussion around the general theme of:

Alan Mackenzie wrote:
> 'Evening, Richard!
>
> On Mon, Jul 14, 2008 at 01:38:28PM -0400, Richard M Stallman wrote:
>   
>>     Richard, you're perhaps the brightest guy around, here.  How long
>>     did it take you to get your first GNU/Linux installation installed
>>     and _fully_ working (i.e. all peripherals, networking, X-Windows,
>>     email, web-browsing, ....  all satisfactory)?


All of user-space needs to be done over.

The root problem with install difficulties, network config difficulties,
and divergent opinions about how to lay out an emacs install is simply
that unix user space and unix "best" practices for source management
haven't much improved for almost two decades.   People are using
tools closely related to those meant to manage *one* or *fifteen* of
100,000 unix installs (way back when) to now manage 100s of
millions of installs, often enough 10s of millions
at a time.  Nobody has successfully bothered to revisit the
fundamentals.

The GNU project as originally conceived by some close to it
involved fairly radical surgery to rationalize the "complete system"
source tree and to rationalize user-space by homogenizing around
a lispish approach.    For example, what should a default "load path"
be?  Well, that's not just an Emacs question -- it's generic for many
apps (e.g., a C compiler).   It merits a generic solution which is then
adopted as a coding / configuration / & source management standard.

It is a failure of the GNU project and of the free software movement
that there is so much emphasis on monolithic distributions and binary
package distributions.   It is a failure of the GNU project and the free
software movement that one so often encounters distros that offer to
not install source trees and even offer to not install development
environments.  These developments systematically and by design
deprive users of incentive to actually *exercise* their software freedom
as individuals.   These developments encourage a *de facto* (even
if not licensing-based) ceding of software freedom to distribution
projects like Debian or any of the commercial distros.

It is a failure of the GNU project and the free software movement
that there is such a large technical gap between "upstream" projects
and installed systems that massive "distribution projects" (commercial
or Debian) need to exist in between.   *Vetting services* should
exist between upstream and end-users  -- not "distribution vendors".
Vetting services should be in the business of publishing links
to source and checksums, not binaries.

The most important thing in such a large effort as a complete system
is the standards:  standards for coding, for documentation, for
source code management, for configuration, build, install, patching and
rebuild/reinstall, and uninstall.   Have you noticed that these are exactly
the weak areas that cause nearly all of the friction people are 
kvetching about
in this thread?  (Some HW vendors keep secrets and that amplifies the
problem -- but they are not the root of the problem.)

Yes, some binaries are needed to bootstrap from a raw box running
a (hopefully free) BIOS but those should be minimal -- not the
state we see today where you pick your distro.   *My* mentor,
20 years ago, was having fun debating with his peers whether
the number of programs a set of bootstrap binaries required for
a complete unix was closer 10 or closer to 20.   Let's see, you'd
want /bin/sh, for sure.  and /usr/bin/cc.   There's "awk" and "make"
but maybe there's a sweeter spot that slices that a bit differently.....

And in that view a "package" was a version controlled source
bundle with facilities for patching and a very clean, flexible,
configure/build/install procedure that was *standardized*.  Not
at the anemic level of the "GNU Coding Standards" -- but, rather,
usefully standardized.  Where today we have factional camps around
RPM and other package systems -- those shouldn't be afterthought.
Where we have "autoconf" and friends -- those should be central, not
the obscure, resented power-grab of a few.

Instead, we neglected all that grunt work and thus gave rise
to Debian and all of the commercial vendors and all of the problems
those "mid-stream" players create as they dominate the entire economics
of our efforts to create software freedom.

So, now, as a result: we've "succeeded" to the extent that most GNU/Linux
users don't possess most of the source for what they run;  can't rebuild 
from
source; are "locked in" to one distribution vendor or another -- like RMS
hisself, apparently.   And all needlessly so because we failed to put 
forward
good standards for source code management for a couple of decades.

It's amazing, pathetic, and embarrassing to be associated with.


-t

Re: Emacs vista build failures

[Lennart Borgman (gmail)]

Thomas Lord wrote:
> The most important thing in such a large effort as a complete system
> is the standards:  standards for coding, for documentation, for
> source code management, for configuration, build, install, patching and
> rebuild/reinstall, and uninstall.

Yes, standards is the key to success.

There are probably other areas for standards that could be mentioned 
too. One could for example think about OpenOffice and the struggle to 
implement an open standard for word processors.

I find it hard to imagine that GNU/Linux will not be dominating when 
there are (in a bright future) adequate standards. Before that time I 
find it hard to believe that GNU/Linux can dominate.

This is because standards makes it much easier to build on the work of 
others - and the idea of doing that is at the bottom of GNU/Linux IMO.

Re: Emacs vista build failures

[Thomas Lord]

Lennart Borgman (gmail) wrote:
> Thomas Lord wrote:
>> The most important thing in such a large effort as a complete system
>> is the standards:  standards for coding, for documentation, for
>> source code management, for configuration, build, install, patching and
>> rebuild/reinstall, and uninstall.
>
> Yes, standards is the key to success.
>
> There are probably other areas for standards that could be mentioned 
> too. One could for example think about OpenOffice and the struggle to 
> implement an open standard for word processors.

Thanks.

Layering matters there, in my view:

Getting source code management, configure, build, install standards 
right makes application level (e.g. functionality at the level of 
OpenOffice) easier to standardize on -- because you can then publish 
working, useful, reference implementation *components* to deal with 
those app-level standards.


>
> I find it hard to imagine that GNU/Linux will not be dominating when 
> there are (in a bright future) adequate standards. Before that time I 
> find it hard to believe that GNU/Linux can dominate.
>
> This is because standards makes it much easier to build on the work of 
> others - and the idea of doing that is at the bottom of GNU/Linux IMO.
>


Right.  "Composability" (of source components) is the thing to 
optimize.   From there, things can grow without giving over freedom (via 
licensing or more subtle controls) to intermediaries.   The GNU project, 
per say, has failed and needs a reboot.

-t

Re: Emacs vista build failures

[David Kastrup]

Thomas Lord <lord@emf.net> writes:

> re much discussion around the general theme of:
>
> Alan Mackenzie wrote:
>> 'Evening, Richard!
>>
>> On Mon, Jul 14, 2008 at 01:38:28PM -0400, Richard M Stallman wrote:
>>   
>>>     Richard, you're perhaps the brightest guy around, here.  How long
>>>     did it take you to get your first GNU/Linux installation installed
>>>     and _fully_ working (i.e. all peripherals, networking, X-Windows,
>>>     email, web-browsing, ....  all satisfactory)?
>
>
> All of user-space needs to be done over.
>
> The root problem with install difficulties, network config difficulties,
> and divergent opinions about how to lay out an emacs install is simply
> that unix user space and unix "best" practices for source management
> haven't much improved for almost two decades.

Having worked with Unix and Unix-like installations for more than two
decades, I can only say that you are utterly wrong.

And in fact, it is mostly the driving force of the _free_ Unix variants
that has brought forward most advances in source management, package
management, and network configurations.

If you want to get nostalgic at least over configuration, try Slackware
one of these days.  I think it is still pretty much old-spirit.

-- 
David Kastrup

Re: Emacs vista build failures

[Thomas Lord]

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

David Kastrup wrote:
>> The root problem with install difficulties, network config difficulties,
>> and divergent opinions about how to lay out an emacs install is simply
>> that unix user space and unix "best" practices for source management
>> haven't much improved for almost two decades.
>>     
>
> Having worked with Unix and Unix-like installations for more than two
> decades, I can only say that you are utterly wrong.
>   

More than two decades, eh?   Like me, then, you probably cut your teeth
on BSD, BSD-based SunOS, later HP-UX, AIX, Ultrix, Irix, Solaris,
NextStep and eventually, GNU/Linux.

We could trade war stories, no doubt.   It's interesting, for example,
the way that the proliferation of gratuitously different flavors of
unix led to the perceived need and then deployment of Autoconf
in the GNU project and how that in turn influenced coding practices.
Again and again we erect new structures over rotten foundations
rather than fixing the foundations.   Sometimes the solution is not
*more* code but rather less code and better.

In any event, the "make" paradigm and same-but-different tools
comes from slightly before both our times.   The various "/etc"
(and other location) system configuration files come from before
our time;  networking configuration from around our earliest days.
The way that $PATH and later $LD_LIBRARY_PATH works is from
early in yours and my experience and, with those (and older traditions)
came the gist of contemporary directory layouts for system files.
Common version naming and numbering practices go back to then.
"patch" goes back to then.   The absence of any systematic, automated
way to build dependency management in to the development framework
stems from that era.

Though not as standardized as even all those bits, the first attempts
to add automated package management and dependency management
go back to that era as well -- I seem to recall a fair number of Usenix
papers reporting on new variations and experience.   The GNU/Linux
world has most recently spent about a decade recapitulating that 
experience --
poorly.  It was a dead end then and that hasn't changed.


> And in fact, it is mostly the driving force of the _free_ Unix variants
> that has brought forward most advances in source management, package
> management, and network configurations.
>   

And those advances have been and will continue to be purely
incremental, hard-won, and perpetually (perhaps even increasingly)
fragile.   And there *still* is no successful, comprehensive system
for on-line documentation and an expectation that every new serious
package *uses it*.   There are still essentially as many config file 
syntaxes
as there are config files (only now there are more config files).  There
is still, therefore, no robust, systematic way to write higher-level, user
friendly system configuration tools.   There is, therefore, no robust, 
systematic
way to write model-checking tools to sanity check and diagnose 
configurations.
There is still no way to write robust, systematic, transactional and version
control management tools for configs (the oft repeated "just stick /etc 
under
CVS/SVN/whatever" is neither transactional or well version controlled).

The problems of system configuration were well recognized by proprietary
unix vendors and large systems shops those 20-some years ago -- that was
the state when we arrived.   Little has changed, often not clearly for the
better, and only at substantial expense in volunteer labor and user 
frustration
(as evidenced in these threads).   The proprietary vendors were 
constrained by
demand for (approximate, at best) upwards compatibility.   The GNU project
at least had a broad intent to, sure - bootstrap via unix, keep a unix 
kernel,
and unix compatibility BUT - to also move on and build a new kind of user
space, homogenized around a lisp-based, systematically customizable, 
extensible,
and self-documenting architecture.  And, on top of that ambition, some of us
at least recognized that it was equally important to well-modularize and 
standardize
the management of aggregated collections of separately developed source 
packages,
their build and installation, their installed configuration, their 
dependencies,
their auditing and so forth.   The *only* way to solve those latter 
problems is with
coding and packaging standards that are stronger, more thought out, yet 
at least
as easy to follow as the GNU standards -- with tools to help with that.


> If you want to get nostalgic at least over configuration, try Slackware
> one of these days.  I think it is still pretty much old-spirit.
>   

I use a distribution with an excellent reputation for being one of the best
of the breed in terms of ease of configuration, etc., and I find it to be
very much in (the worst aspects of) the "old-spirit" -- with lots of 
junk layered
over the old stuff to make it even worse than the worst of the old.   It 
is fragile, ill-documented,
sprawling and ad hoc.   That is unsurprising when you try to layer a 
simulacrum
of higher-level package management on a rotten, 30 year old foundation that
was never intended in the first place to hold up a structure of this scale.
Before all these recent "improvements" a unix admin had the problem of
grokking lots of different system configuration files and keeping them in
order.   Now, with these improvements, an admin has two problems: dealing
with those files *and* not breaking any of the layered (dog-piled) modern
tools that supposedly assist in managing these files.

The early GNU/Linux vendors set out to lead the free software hackers
of the world to build a substitute for 1990s Solaris and that's exactly what
then happened only the substitute is pluralized by competing GNU/Linux
distros and in many ways none of them are as good as 1990s Solaris.
Just like the proprietary vendors as they were wrapping up serious
unix development we've wound up with some "pretty good" servers
with user applications as an afterthought, requiring serious admin talent
to keep running well, and the orginal GNU vision nowhere in sight.

Give me 10 stout hackers.  Job #1 is to make a minimal (really minimal)
system for bootstrapping and then re-build user space "from scratch" (of
course, not neglecting to repurpose millions of lines of existing code 
-- just
not accepting a constraint of sacrificing robustness, quality, and 
scalability
in favor of going too fast or being gratuitously compatible with traditions
that have never and will never really work.

-t



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

Re: Emacs vista build failures

[Richard M Stallman]

    It is a failure of the GNU project and of the free software movement
    that there is so much emphasis on monolithic distributions and binary
    package distributions.   It is a failure of the GNU project and the free
    software movement that one so often encounters distros that offer to
    not install source trees and even offer to not install development
    environments.

The words "it is a failure of" are ambiguous.  They could literally
mean "it is a goal we have not achieved", but they also suggest
placing the blame for this on us.

Certainly these are goals we have not achieved, but if others do not
follow our recommendations, that's their decision, not ours.  When I
designed the GNU specs for configuring and building source packages, I
hoped that free software developers generally would adopt them, but
they did not.

I tried at one point to convince XFree86 to support the GNU
configuration spec.  I even found a volunteer to implement that as a
wrapper around their existing configuration mechanism.  But they did
not consider such compatibility very important, and I don't think they
installed this wrapper.

To convince free software projects generally to adopt this spec
would require more pressure from the community in general.

It is easy to call names (such as calling the GNU Coding Standards
"anemic"), but given that many programs' developers won't even
implement those, I doubt we would obtain much compliance for stricter
ones.

Re: Emacs vista build failures

[Miles Bader]

Richard M Stallman <rms@gnu.org> writes:
> I tried at one point to convince XFree86 to support the GNU
> configuration spec.  I even found a volunteer to implement that as a
> wrapper around their existing configuration mechanism.  But they did
> not consider such compatibility very important, and I don't think they
> installed this wrapper.

Note that the current standard X distribution, Xorg, now uses gnu auto*
tools for configuration.

-Miles

-- 
Apologize, v. To lay the foundation for a future offense.

Re: Emacs vista build failures

[Richard M Stallman]

    > I tried at one point to convince XFree86 to support the GNU
    > configuration spec.  I even found a volunteer to implement that as a
    > wrapper around their existing configuration mechanism.  But they did
    > not consider such compatibility very important, and I don't think they
    > installed this wrapper.

    Note that the current standard X distribution, Xorg, now uses gnu auto*
    tools for configuration.

That is good news, but the general problem remains
as far as I know.  Has there been a general move towards
supporting the GNU configure and build specs?  That would make
it much easier to build a whole system from source.

Re: Emacs vista build failures

[Miles Bader]

Richard M Stallman <rms@gnu.org> writes:
>     Note that the current standard X distribution, Xorg, now uses gnu auto*
>     tools for configuration.
>
> That is good news, but the general problem remains
> as far as I know.  Has there been a general move towards
> supporting the GNU configure and build specs?

As far as I know (I don't hack on X, I just read the mailing list), the
entire build infrastructure was replaced, and you can now do
"./configure ...; make" etc., and things work in the normal GNU
style.

[X was also modularized so it's not just one huge tree anymore, but
rather a bunch of smaller packages.]

-Miles

-- 
Alliance, n. In international politics, the union of two thieves who have
their hands so deeply inserted in each other's pockets that they cannot
separately plunder a third.

Re: Emacs vista build failures

[Richard M Stallman]

    > That is good news, but the general problem remains
    > as far as I know.  Has there been a general move towards
    > supporting the GNU configure and build specs?

    As far as I know (I don't hack on X, I just read the mailing list), the
    entire build infrastructure was replaced, and you can now do
    "./configure ...; make" etc., and things work in the normal GNU
    style.

We are miscommunicating.  As regards X itself, I took for granted that
that is what you meant.

My question concerns looking beyond X to the free software community
as a whole.  Has there been a broader move towords supporting the GNU
configure and build specs?

Re: Emacs vista build failures

[Johannes Weiner]

Richard M Stallman <rms@gnu.org> writes:

>     > That is good news, but the general problem remains
>     > as far as I know.  Has there been a general move towards
>     > supporting the GNU configure and build specs?
>
>     As far as I know (I don't hack on X, I just read the mailing list), the
>     entire build infrastructure was replaced, and you can now do
>     "./configure ...; make" etc., and things work in the normal GNU
>     style.
>
> We are miscommunicating.  As regards X itself, I took for granted that
> that is what you meant.
>
> My question concerns looking beyond X to the free software community
> as a whole.  Has there been a broader move towords supporting the GNU
> configure and build specs?

Maybe you heard the term `autohell' once?  People tend to forget about
political issues when they are just frustrated with the software.

	Hannes

Re: Emacs vista build failures

[Richard M Stallman]

    > My question concerns looking beyond X to the free software community
    > as a whole.  Has there been a broader move towords supporting the GNU
    > configure and build specs?

    Maybe you heard the term `autohell' once?

Actually no.  It seems to be a criticism of something.
Perhaps Autoconf, or perhaps not -- I have no way to tell.

If you are talking about Autoconf, then you've misunderstood what this
issue is about.  It is not about using Autoconf.  It is about
implementing the interface specified in the GNU Coding Standards.

Let's please stick to the topic.

Re: Emacs vista build failures

[Johannes Weiner]

Hi,

Richard M Stallman <rms@gnu.org> writes:

>     > My question concerns looking beyond X to the free software community
>     > as a whole.  Has there been a broader move towords supporting the GNU
>     > configure and build specs?
>
>     Maybe you heard the term `autohell' once?
>
> Actually no.  It seems to be a criticism of something.
> Perhaps Autoconf, or perhaps not -- I have no way to tell.

autoconf, automake, and so on.  Actually, I heard people referring to
the whole generation of configure scripts and Makefiles as `autohell'.

Yes, it's ovbiously a criticism.

> If you are talking about Autoconf, then you've misunderstood what this
> issue is about.  It is not about using Autoconf.  It is about
> implementing the interface specified in the GNU Coding Standards.
> Let's please stick to the topic.

Which means using the auto tools, be realistic.  Who writes configure
scripts manually?

I have no interest in discussing theory when we have so much reality
going on.

People are not only moving away from the interface itself but also from
the default tools to generate them, because they are still too complex
to use.

The interface difference is worked around by the package maintainers,
they are prepared to support different building mechanisms.

	Hannes

Re: Emacs vista build failures

[Miles Bader]

Johannes Weiner <hannes@saeurebad.de> writes:
> Which means using the auto tools, be realistic.  Who writes configure
> scripts manually?

I certainly have.

It's not a difficult interface to implement.

Doing so _manually_ (as a shell script or something) is not particularly
hard if you have simple needs.  If you're using some other build tool,
it should often be fairly straight-forward to use that tool with a thin
layer on top to implement the GNU configure interface.

AFAICS, it's more a failure of imagination than a technical issue.

-Miles

-- 
Carefully crafted initial estimates reward you not only with
reduced computational effort, but also with understanding and
increased self-esteem.         -- Numerical methods in C,
  Chapter 9. "Root Finding and Nonlinear Sets of Equations"

Re: Emacs vista build failures

[Johannes Weiner]

Hi,

Miles Bader <miles@gnu.org> writes:

> Johannes Weiner <hannes@saeurebad.de> writes:
>> Which means using the auto tools, be realistic.  Who writes configure
>> scripts manually?
>
> I certainly have.
>
> It's not a difficult interface to implement.
>
> Doing so _manually_ (as a shell script or something) is not particularly
> hard if you have simple needs.  If you're using some other build tool,
> it should often be fairly straight-forward to use that tool with a thin
> layer on top to implement the GNU configure interface.

It would be cool to have shell libraries you could use for whipping your
own configure.  I.e. no m4 macros but powerful shell functions you can
just call.

That way you would install the `GNU build libs' (or whatever you would
like to call them) and upstream distributors ship a 20-liner of a
configure script that utilizes these libraries instead of having heaps
of source trees that ship a 12k lines configure script.

> AFAICS, it's more a failure of imagination than a technical issue.

Richard was right with me mixing up the coding standard with the
autotools.  I am sorry.

The problem seems to be that people, including me, associate common GNU
configuration/building mechanism with the autotools.  So if they get
pissed while using them (which is not unlikely, as we already know now),
they probably tend to use something completely different, just because
there is something else that promises working out of the box.

So the more realistic case is that people chose scons or something
instead of dropping autotools and writing their own configure script.

I build a lot of software myself and this is based on half-assed
observation, I might be wrong.

	Hannes

Re: Emacs vista build failures

[Lennart Borgman (gmail)]

Johannes Weiner wrote:
>> Doing so _manually_ (as a shell script or something) is not particularly
>> hard if you have simple needs.  If you're using some other build tool,
>> it should often be fairly straight-forward to use that tool with a thin
>> layer on top to implement the GNU configure interface.
> 
> It would be cool to have shell libraries you could use for whipping your
> own configure.  I.e. no m4 macros but powerful shell functions you can
> just call.


And once again: If this did not work easily on w32 too it might stop 
people from using it.

Re: Emacs vista build failures

[Johannes Weiner]

Hi,

"Lennart Borgman (gmail)" <lennart.borgman@gmail.com> writes:

> Johannes Weiner wrote:
>>> Doing so _manually_ (as a shell script or something) is not particularly
>>> hard if you have simple needs.  If you're using some other build tool,
>>> it should often be fairly straight-forward to use that tool with a thin
>>> layer on top to implement the GNU configure interface.
>>
>> It would be cool to have shell libraries you could use for whipping your
>> own configure.  I.e. no m4 macros but powerful shell functions you can
>> just call.
>
>
> And once again: If this did not work easily on w32 too it might stop
> people from using it.

To be honest, I couldn't give the slightest about w32.  It's a pile of
crap that should have never seen the light of day, all political issues
left aside and I, FWIW, would not consider it when designing software.

	Hannes

Re: Emacs vista build failures

[Lennart Borgman (gmail)]

Johannes Weiner wrote:
> Hi,
> 
> "Lennart Borgman (gmail)" <lennart.borgman@gmail.com> writes:
> 
>> Johannes Weiner wrote:
>>>> Doing so _manually_ (as a shell script or something) is not particularly
>>>> hard if you have simple needs.  If you're using some other build tool,
>>>> it should often be fairly straight-forward to use that tool with a thin
>>>> layer on top to implement the GNU configure interface.
>>> It would be cool to have shell libraries you could use for whipping your
>>> own configure.  I.e. no m4 macros but powerful shell functions you can
>>> just call.
>>
>> And once again: If this did not work easily on w32 too it might stop
>> people from using it.
> 
> To be honest, I couldn't give the slightest about w32.  It's a pile of
> crap that should have never seen the light of day, all political issues
> left aside and I, FWIW, would not consider it when designing software.


I not sure why you tell me that. I see no reason why I should be 
interested in your opinion about it.

I am interested in getting the free software movement forward and "I 
know best" attitudes will not help.

Re: Emacs vista build failures

[Johannes Weiner]

Hi,

"Lennart Borgman (gmail)" <lennart.borgman@gmail.com> writes:

> Johannes Weiner wrote:
>> Hi,
>>
>> "Lennart Borgman (gmail)" <lennart.borgman@gmail.com> writes:
>>
>>> Johannes Weiner wrote:
>>>>> Doing so _manually_ (as a shell script or something) is not particularly
>>>>> hard if you have simple needs.  If you're using some other build tool,
>>>>> it should often be fairly straight-forward to use that tool with a thin
>>>>> layer on top to implement the GNU configure interface.
>>>> It would be cool to have shell libraries you could use for whipping your
>>>> own configure.  I.e. no m4 macros but powerful shell functions you can
>>>> just call.
>>>
>>> And once again: If this did not work easily on w32 too it might stop
>>> people from using it.
>>
>> To be honest, I couldn't give the slightest about w32.  It's a pile of
>> crap that should have never seen the light of day, all political issues
>> left aside and I, FWIW, would not consider it when designing software.
>
>
> I not sure why you tell me that. I see no reason why I should be
> interested in your opinion about it.
>
> I am interested in getting the free software movement forward and "I
> know best" attitudes will not help.

No offence.  You suggested it should work on Windows in a reply to me.
So I stated my opinion about it.

I am also interested in getting the free software movement forward.  I
just don't have any idea how that relates to Windows.

	Hannes

Re: Emacs vista build failures

[Lennart Borgman (gmail)]

Johannes Weiner wrote:
> Hi,
> 
> "Lennart Borgman (gmail)" <lennart.borgman@gmail.com> writes:
> 
>> Johannes Weiner wrote:
>>> Hi,
>>>
>>> "Lennart Borgman (gmail)" <lennart.borgman@gmail.com> writes:
>>>
>>>> Johannes Weiner wrote:
>>>>>> Doing so _manually_ (as a shell script or something) is not particularly
>>>>>> hard if you have simple needs.  If you're using some other build tool,
>>>>>> it should often be fairly straight-forward to use that tool with a thin
>>>>>> layer on top to implement the GNU configure interface.
>>>>> It would be cool to have shell libraries you could use for whipping your
>>>>> own configure.  I.e. no m4 macros but powerful shell functions you can
>>>>> just call.
>>>> And once again: If this did not work easily on w32 too it might stop
>>>> people from using it.
>>> To be honest, I couldn't give the slightest about w32.  It's a pile of
>>> crap that should have never seen the light of day, all political issues
>>> left aside and I, FWIW, would not consider it when designing software.
>>
>> I not sure why you tell me that. I see no reason why I should be
>> interested in your opinion about it.
>>
>> I am interested in getting the free software movement forward and "I
>> know best" attitudes will not help.
> 
> No offence.  You suggested it should work on Windows in a reply to me.
> So I stated my opinion about it.
> 
> I am also interested in getting the free software movement forward.  I
> just don't have any idea how that relates to Windows.

Thanks Hannes! Let us keep up the good work.

I presented (in this thread I believe) some of my arguments about why to 
care about w32 too in my reply to RMS about a portable mini-bash. I 
might be wrong, my arguments might be bad, but I tried to give some 
arguments.

Re: Emacs vista build failures

[Evans Winner]

"Lennart Borgman (gmail)" <lennart.borgman@gmail.com>
writes:
 
    I presented (in this thread I believe) some of my
    arguments about why to care about w32 too in my reply to
    RMS about a portable mini-bash. I might be wrong, my
    arguments might be bad, but I tried to give some
    arguments.

I don't know much about it, but isn't that what MinGW is
supposed to provide?

Re: Emacs vista build failures

[David Kastrup]

Evans Winner <thorne@timbral.net> writes:

> "Lennart Borgman (gmail)" <lennart.borgman@gmail.com>
> writes:
>  
>     I presented (in this thread I believe) some of my
>     arguments about why to care about w32 too in my reply to
>     RMS about a portable mini-bash. I might be wrong, my
>     arguments might be bad, but I tried to give some
>     arguments.
>
> I don't know much about it, but isn't that what MinGW is
> supposed to provide?

Uh, "portable" is not the same as "runs on Windows".  There are other
platforms too, you know.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Emacs vista build failures

[Jason Rumney]

Evans Winner wrote:
> "Lennart Borgman (gmail)" <lennart.borgman@gmail.com>
> writes:
>  
>     I presented (in this thread I believe) some of my
>     arguments about why to care about w32 too in my reply to
>     RMS about a portable mini-bash. I might be wrong, my
>     arguments might be bad, but I tried to give some
>     arguments.
> 
> I don't know much about it, but isn't that what MinGW is
> supposed to provide?

I think Lennart's suggestion is about a having a small POSIX shell that
can be bundled with Emacs (and other programs) to use on systems that do
not have a POSIX shell by default. MinGW/MSYS is an external dependency
which means an extra thing to go wrong for users.

I do think this idea presents a chicken and egg problem though - the
shell is needed by configure, but will not be available until it has
been built by a bootstrap.

Re: Emacs vista build failures

[Lennart Borgman (gmail)]

Jason Rumney wrote:
> Evans Winner wrote:
>> "Lennart Borgman (gmail)" <lennart.borgman@gmail.com>
>> writes:
>>  
>>     I presented (in this thread I believe) some of my
>>     arguments about why to care about w32 too in my reply to
>>     RMS about a portable mini-bash. I might be wrong, my
>>     arguments might be bad, but I tried to give some
>>     arguments.
>>
>> I don't know much about it, but isn't that what MinGW is
>> supposed to provide?
> 
> I think Lennart's suggestion is about a having a small POSIX shell that
> can be bundled with Emacs (and other programs) to use on systems that do
> not have a POSIX shell by default. MinGW/MSYS is an external dependency
> which means an extra thing to go wrong for users.

Yes.

> I do think this idea presents a chicken and egg problem though - the
> shell is needed by configure, but will not be available until it has
> been built by a bootstrap.

Yes, but that can be worked around by saying there is an extra step 
needed. Either downloading a binary or using a platform dependent way of 
building that mini-bash. (Most users will probably download it.)

Re: Emacs vista build failures

[Eli Zaretskii]

> From: Jason Rumney <jasonr@gnu.org>
> Cc: emacs-devel@gnu.org
> 
> I do think this idea presents a chicken and egg problem though - the
> shell is needed by configure, but will not be available until it has
> been built by a bootstrap.

The shell could be built before running the configure.

Unfortunately, I think Lennart's idea is not practical: a typical
configure script exercises many advanced shell features, and so
crafting a shell that could run it will need to implement most of the
features we have in Bash.  Such a shell will be neither small nor
portable, because a Posix shell needs quite a few Posix features.

Re: Emacs vista build failures

[Lennart Borgman (gmail)]

Eli Zaretskii wrote:
>> From: Jason Rumney <jasonr@gnu.org>
>> Cc: emacs-devel@gnu.org
>>
>> I do think this idea presents a chicken and egg problem though - the
>> shell is needed by configure, but will not be available until it has
>> been built by a bootstrap.
> 
> The shell could be built before running the configure.
> 
> Unfortunately, I think Lennart's idea is not practical: a typical
> configure script exercises many advanced shell features, and so
> crafting a shell that could run it will need to implement most of the
> features we have in Bash.  Such a shell will be neither small nor
> portable, because a Posix shell needs quite a few Posix features.

You might have told me before, but what advanced features are you 
thinking of?

Perhaps "portable" is much more important than "small". "Interactive" 
features might not be that important.

Re: Emacs vista build failures

[Eli Zaretskii]

> Date: Tue, 22 Jul 2008 15:58:47 +0200
> From: "Lennart Borgman (gmail)" <lennart.borgman@gmail.com>
> CC: Jason Rumney <jasonr@gnu.org>, thorne@timbral.net, 
>  emacs-devel@gnu.org
> 
> > Unfortunately, I think Lennart's idea is not practical: a typical
> > configure script exercises many advanced shell features, and so
> > crafting a shell that could run it will need to implement most of the
> > features we have in Bash.  Such a shell will be neither small nor
> > portable, because a Posix shell needs quite a few Posix features.
> 
> You might have told me before, but what advanced features are you 
> thinking of?

`fork', for starters.

> Perhaps "portable" is much more important than "small".

If it is not "small", it will be a large job to write it.  Better
invest that effort into making a native port of Bash, instead of
inventing another wheel.

Re: Emacs vista build failures

[James Cloos]

>>>>> "Eli" == Eli Zaretskii <eliz@gnu.org> writes:

Eli> a typical configure script exercises many advanced shell features,
Eli> and so crafting a shell that could run it will need to implement
Eli> most of the features we have in Bash.  Such a shell will be neither
Eli> small nor portable, because a Posix shell needs quite a few Posix
Eli> features.

I thought the whole point of auto-tools was to work with any POSIX
shell.  So dash ought to be enough for that.

When it comes down to it though, given what else is required, I suspect
busybox may be the answer.  It should cover everything needed to run a
configure script.  And is GPL, too.

-JimC
-- 
James Cloos <cloos@jhcloos.com>         OpenPGP: 1024D/ED7DAEA6

Re: Emacs vista build failures

[Lennart Borgman (gmail)]

James Cloos wrote:
> When it comes down to it though, given what else is required, I suspect
> busybox may be the answer.  It should cover everything needed to run a
> configure script.  And is GPL, too.


The busybox site says

"While the current code is fairly Linux specific, it should be fairly 
easy to port the majority of the code to support, say, FreeBSD or 
Solaris, or Mac OS X, or even Windows ..."

Re: Emacs vista build failures

[Alfred M. Szmidt]

   > I do think this idea presents a chicken and egg problem though - the
   > shell is needed by configure, but will not be available until it has
   > been built by a bootstrap.

   The shell could be built before running the configure.

And how would that work for every other platform?  

Really, why not have a shell (say bash) that can be easily installed
on Windows (a .exe that you can put somewhere), and whatever other
platform.  It could be distributed on ftp.gnu.org, like the emacs
binaries for windows and other such unfriendly platforms.

Re: Emacs vista build failures

[David Kastrup]

"Alfred M. Szmidt" <ams@gnu.org> writes:

>    > I do think this idea presents a chicken and egg problem though - the
>    > shell is needed by configure, but will not be available until it has
>    > been built by a bootstrap.
>
>    The shell could be built before running the configure.
>
> And how would that work for every other platform?

By using a subset of C and the respective libraries that is supported
everywhere.  The Lua interpreter is written in that way IIRC.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Emacs vista build failures

[Eli Zaretskii]

> CC: jasonr@gnu.org, thorne@timbral.net, emacs-devel@gnu.org
> Reply-to: ams@gnu.org
> From: "Alfred M. Szmidt" <ams@gnu.org>
> Date: Tue, 22 Jul 2008 16:11:56 -0400
> 
>    > I do think this idea presents a chicken and egg problem though - the
>    > shell is needed by configure, but will not be available until it has
>    > been built by a bootstrap.
> 
>    The shell could be built before running the configure.
> 
> And how would that work for every other platform?  

We were not talking about every other platform, just about w32.  Posix
platforms don't need to build a shell, they already have it.

> Really, why not have a shell (say bash) that can be easily installed
> on Windows (a .exe that you can put somewhere), and whatever other
> platform.  It could be distributed on ftp.gnu.org, like the emacs
> binaries for windows and other such unfriendly platforms.

That'd be the best, but unfortunately there's no native Windows port
of a Posix shell that is bug-free and powerful enough to run a typical
configure script.

Re: Emacs vista build failures

[Eli Zaretskii]

> From: Eli Zaretskii <eliz@gnu.org>
> Date: Tue, 22 Jul 2008 18:14:29 -0400
> Cc: emacs-devel@gnu.org
> Reply-To: Eli Zaretskii <eliz@gnu.org>
> 
> unfortunately there's no native Windows port of a Posix shell that
> is bug-free and powerful enough to run a typical configure script.

At least to my best knowledge, that is.  If someone knows about such a
beast, please tell where to find it.

Re: Emacs vista build failures

[Stephen Leake]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Eli Zaretskii <eliz@gnu.org>
>> Date: Tue, 22 Jul 2008 18:14:29 -0400
>> Cc: emacs-devel@gnu.org
>> Reply-To: Eli Zaretskii <eliz@gnu.org>
>> 
>> unfortunately there's no native Windows port of a Posix shell that
>> is bug-free and powerful enough to run a typical configure script.
>
> At least to my best knowledge, that is.  If someone knows about such a
> beast, please tell where to find it.

Cygwin provides precisely that.

Some might say "it's not 'native'; it relies on the cygwin.dll". I
think that's a quibble; it's easy to install, it provides sufficient
power to run typical configures; that satisfies the stated requirements.

No software is completely "bug-free", but Cygwin bash is as good as
any other port of Gnu bash, in my experience.

-- 
-- Stephe

Re: Emacs vista build failures

[Jason Rumney]

Stephen Leake wrote:

> Some might say "it's not 'native'; it relies on the cygwin.dll".

That is not a real criticism, many Windows programs depend on their own
shared libraries.

A real criticism is that it does not interact well with native Windows
programs, which causes lots of ugly workarounds to be needed in shell
scripts and makefiles.

Re: Emacs vista build failures

[Eli Zaretskii]

> Date: Wed, 23 Jul 2008 09:20:29 +0100
> From: Jason Rumney <jasonr@gnu.org>
> Cc: emacs-devel@gnu.org
> 
> Stephen Leake wrote:
> 
> > Some might say "it's not 'native'; it relies on the cygwin.dll".
> 
> That is not a real criticism, many Windows programs depend on their own
> shared libraries.
> 
> A real criticism is that it does not interact well with native Windows
> programs, which causes lots of ugly workarounds to be needed in shell
> scripts and makefiles.

Yes, exactly.  The /cygdrive stuff, the incompatible command-line
quoting, text/binary mounts of filesystems, reliance on Bash when
`system' is called, signals that only work between Cygwin programs,
etc. etc., -- all this makes Cygwin a perfect environment if, but only
if you confine yourself to running Cygwin programs and nothing else.

Re: Emacs vista build failures

[David Kastrup]

Stephen Leake <stephen_leake@member.fsf.org> writes:

> Eli Zaretskii <eliz@gnu.org> writes:
>
>>> From: Eli Zaretskii <eliz@gnu.org>
>>> Date: Tue, 22 Jul 2008 18:14:29 -0400
>>> Cc: emacs-devel@gnu.org
>>> Reply-To: Eli Zaretskii <eliz@gnu.org>
>>> 
>>> unfortunately there's no native Windows port of a Posix shell that
>>> is bug-free and powerful enough to run a typical configure script.
>>
>> At least to my best knowledge, that is.  If someone knows about such a
>> beast, please tell where to find it.
>
> Cygwin provides precisely that.

No, it doesn't.

> Some might say "it's not 'native'; it relies on the cygwin.dll". I
> think that's a quibble; it's easy to install,

But you can't use it without installing it.  And installing it tampers
with the registry.  And it can't be done in a batch job without user
interaction.

And if you do
  some_command `pwd`
in it, only Cygwin programs will be able to properly interpret the
output of pwd.

> No software is completely "bug-free", but Cygwin bash is as good as
> any other port of Gnu bash, in my experience.

It is useless as an installation helper since it requires you to
interactively install and configure the whole of Cygwin and there is no
easy way to get rid of it again and there is no reasonable way to
entertain more than one installation of Cygwin on a single system since
it tampers with the registry.

-- 
David Kastrup

Re: Emacs vista build failures

[David Kastrup]

Eli Zaretskii <eliz@gnu.org> writes:

>> CC: jasonr@gnu.org, thorne@timbral.net, emacs-devel@gnu.org
>> Reply-to: ams@gnu.org
>> From: "Alfred M. Szmidt" <ams@gnu.org>
>> Date: Tue, 22 Jul 2008 16:11:56 -0400
>> 
>>    > I do think this idea presents a chicken and egg problem though - the
>>    > shell is needed by configure, but will not be available until it has
>>    > been built by a bootstrap.
>> 
>>    The shell could be built before running the configure.
>> 
>> And how would that work for every other platform?  
>
> We were not talking about every other platform, just about w32.  Posix
> platforms don't need to build a shell, they already have it.

I recommend reading
(info "(autoconf) Limitations of builtins")

It would be marvellous if somebody managed to heed _all_ of the
incompatibilities by chance first time round for non-trivial scripts.

And that's just the shell: the autoconf setup requires quite a larger
set of utilities.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Emacs vista build failures

[Alfred M. Szmidt]

   >     I presented (in this thread I believe) some of my
   >     arguments about why to care about w32 too in my reply to
   >     RMS about a portable mini-bash. I might be wrong, my
   >     arguments might be bad, but I tried to give some
   >     arguments.
   > 
   > I don't know much about it, but isn't that what MinGW is
   > supposed to provide?

   I think Lennart's suggestion is about a having a small POSIX shell
   that can be bundled with Emacs (and other programs) to use on
   systems that do not have a POSIX shell by default. MinGW/MSYS is an
   external dependency which means an extra thing to go wrong for
   users.

   I do think this idea presents a chicken and egg problem though -
   the shell is needed by configure, but will not be available until
   it has been built by a bootstrap.

Exactly, wouldn't it be just easier to request the user to install
whatever POSIX shell that is required in INSTALL or similar?

Re: Emacs vista build failures

[Lennart Borgman (gmail)]

Alfred M. Szmidt wrote:
>    >     I presented (in this thread I believe) some of my
>    >     arguments about why to care about w32 too in my reply to
>    >     RMS about a portable mini-bash. I might be wrong, my
>    >     arguments might be bad, but I tried to give some
>    >     arguments.
>    > 
>    > I don't know much about it, but isn't that what MinGW is
>    > supposed to provide?
> 
>    I think Lennart's suggestion is about a having a small POSIX shell
>    that can be bundled with Emacs (and other programs) to use on
>    systems that do not have a POSIX shell by default. MinGW/MSYS is an
>    external dependency which means an extra thing to go wrong for
>    users.
> 
>    I do think this idea presents a chicken and egg problem though -
>    the shell is needed by configure, but will not be available until
>    it has been built by a bootstrap.
> 
> Exactly, wouldn't it be just easier to request the user to install
> whatever POSIX shell that is required in INSTALL or similar?

There is a POSIX shell for w32, but I do not think that interact well 
with normal w32 command line programs. Is there anyone who knows 
something about that?

Re: Emacs vista build failures

[David Kastrup]

"Lennart Borgman (gmail)" <lennart.borgman@gmail.com> writes:

> Alfred M. Szmidt wrote:
>
>> Exactly, wouldn't it be just easier to request the user to install
>> whatever POSIX shell that is required in INSTALL or similar?
>
> There is a POSIX shell for w32, but I do not think that interact well
> with normal w32 command line programs. Is there anyone who knows
> something about that?

MSYS is basically a boxed set of everything you'll likely need for
autoconf (modulo compilers).  We recommend using it with AUCTeX.  It
turns out that it still makes a formidable chore for most people to
install all that and call autoconf, configure, make and so on.

It also happens to be frustratingly hard to write shell, m4 and Makefile
code that is immune to backslashes, spaces in file and directory names
and similar.

And since a typical installation target is
"C:\Documents and Settings\dak\My Programs", you get hit with a lot of
madness by default that could theoretically also occur under Posix-like
systems but usually doesn't (of course, with the advent of MacOSX
and GNOME and other GUI stuff, people tend to become less worried about
using weird characters nowadays, so it's just a matter of time).

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Emacs vista build failures

[Lennart Borgman (gmail)]

David Kastrup wrote:
> MSYS is basically a boxed set of everything you'll likely need for
> autoconf (modulo compilers).  We recommend using it with AUCTeX.  It
> turns out that it still makes a formidable chore for most people to
> install all that and call autoconf, configure, make and so on.

Have you recently looked into the possibility of compiling Emacs using 
MSYS bash? I tried, but that was a while ago:

   http://ourcomments.org/Emacs/w32-build-emacs.htm

Re: Emacs vista build failures

[David Kastrup]

"Lennart Borgman (gmail)" <lennart.borgman@gmail.com> writes:

> David Kastrup wrote:
>> MSYS is basically a boxed set of everything you'll likely need for
>> autoconf (modulo compilers).  We recommend using it with AUCTeX.  It
>> turns out that it still makes a formidable chore for most people to
>> install all that and call autoconf, configure, make and so on.
>
> Have you recently looked into the possibility of compiling Emacs using
> MSYS bash?

Neither recently nor ever.  However, we had AUCTeX developers compile
Emacs for distribution with AUCTeX frequently for a while, so if you
need pointers, it might be an idea to ask on auctex-devel@gnu.org.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Emacs vista build failures

[Lennart Borgman (gmail)]

David Kastrup wrote:
>> Have you recently looked into the possibility of compiling Emacs using
>> MSYS bash?
> 
> Neither recently nor ever.  However, we had AUCTeX developers compile
> Emacs for distribution with AUCTeX frequently for a while, so if you
> need pointers, it might be an idea to ask on auctex-devel@gnu.org.

Thanks, I sent a question.

Re: Emacs vista build failures

[Eli Zaretskii]

> From: David Kastrup <dak@gnu.org>
> Date: Tue, 22 Jul 2008 22:31:58 +0200
> Cc: thorne@timbral.net, ams@gnu.org, Jason Rumney <jasonr@gnu.org>,
> 	emacs-devel@gnu.org
> 
> "Lennart Borgman (gmail)" <lennart.borgman@gmail.com> writes:
> 
> > Alfred M. Szmidt wrote:
> >
> >> Exactly, wouldn't it be just easier to request the user to install
> >> whatever POSIX shell that is required in INSTALL or similar?
> >
> > There is a POSIX shell for w32, but I do not think that interact well
> > with normal w32 command line programs. Is there anyone who knows
> > something about that?
> 
> MSYS is basically a boxed set of everything you'll likely need for
> autoconf (modulo compilers).  We recommend using it with AUCTeX.  It
> turns out that it still makes a formidable chore for most people to
> install all that and call autoconf, configure, make and so on.

MSYS is not a reliable solution, although with enough tinkering it is
possible to tweak it into doing a useful job.  It mangles command-line
quoting, for starters, and also requires one to have a completely
separate set of build tools, just for MSYS's use, in addition to
native ports you use outside of the MSYS shell.

Re: Emacs vista build failures

[Eli Zaretskii]

> From: Johannes Weiner <hannes@saeurebad.de>
> Date: Mon, 21 Jul 2008 20:37:17 +0200
> Cc: lord@emf.net, rms@gnu.org, drobinow@gmail.com, emacs-devel@gnu.org,
> 	acm@muc.de, Miles Bader <miles@gnu.org>
> 
> To be honest, I couldn't give the slightest about w32.  It's a pile of
> crap that should have never seen the light of day, all political issues
> left aside and I, FWIW, would not consider it when designing software.

Such arrogant nonsense can only be forgiven if it's spoken out of
utter ignorance.  Last time you took a good look at a Windows system
was probably in 1998.  Wake up! a lot has changed since then.
Nowadays, w32 systems don't fall short of Gnu/Linux in any aspect:
stability, usability, user-friendliness, etc.  And the current trend
in Gnu/Linux systems to mimic the Windows UI, feel, and touch bring
more and more the worst parts of Windows to Gnu/Linux systems, to the
degree that in a very near future they will be indistinguishable,
anyway.

And if you are interested in OS architectural design, then Linux is
simply boring: a huge monolithic kernel that came straight out of the
dinosaur 70-s.  Whereas modern Windows systems are in this respect
everything the Hurd wanted to be: microkernel with many services
running in user space.  Too bad it is under-documented (but then who
has ever heard about, let alone seen, good internals documentation in
the Free Software world?).

Posix is only one way to go, it is not the only way.  Saying I don't
care for anything but Posix is like sticking to a single programming
language: you will be a poorer programmer, because some paradigms
evade you completely.

But I'm quickly getting off topic (not that this prolonged discussion
was on it, btw).

Re: Emacs vista build failures

[David Kastrup]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Johannes Weiner <hannes@saeurebad.de>
>> Date: Mon, 21 Jul 2008 20:37:17 +0200
>> Cc: lord@emf.net, rms@gnu.org, drobinow@gmail.com, emacs-devel@gnu.org,
>> 	acm@muc.de, Miles Bader <miles@gnu.org>
>> 
>> To be honest, I couldn't give the slightest about w32.  It's a pile of
>> crap that should have never seen the light of day, all political issues
>> left aside and I, FWIW, would not consider it when designing software.
>
> Such arrogant nonsense can only be forgiven if it's spoken out of
> utter ignorance.  Last time you took a good look at a Windows system
> was probably in 1998.  Wake up! a lot has changed since then.
> Nowadays, w32 systems don't fall short of Gnu/Linux in any aspect:
> stability, usability, user-friendliness, etc.

There is no reliable way to quote stuff you want to pass into a "system"
call.  In fact, it is not even guaranteed that calling "exec" will not
mesh up arguments or add or remove quoting.

For a programmer, this is a situation nothing short of ridiculous.

> And the current trend in Gnu/Linux systems to mimic the Windows UI,
> feel, and touch bring more and more the worst parts of Windows to
> Gnu/Linux systems, to the degree that in a very near future they will
> be indistinguishable, anyway.

The UI is one thing: at least this has been through usability labs.  But
the misbegotten programming APIs have not had the same blessing.  And
the degree to which they are messed up at times is utterly amazing to
the unprepared observer.

There are consequences: for example, call-process and its ilk don't work
reliably.  You can't expect the arguments given to them to actually make
it unmolested to the argc/argv of the called program's "main".

And that is not good.  In my book, there is hardly an excuse for such
misbehavior.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Emacs vista build failures

[Eli Zaretskii]

> From: David Kastrup <dak@gnu.org>
> Cc: Johannes Weiner <hannes@saeurebad.de>,  emacs-devel@gnu.org
> Date: Tue, 22 Jul 2008 01:11:26 +0200
> 
> There is no reliable way to quote stuff you want to pass into a "system"
> call.

Of course, there is.  Assuming you know what shell will interpret the
arguments, that is.

> In fact, it is not even guaranteed that calling "exec" will not
> mesh up arguments or add or remove quoting.

`exec' is not a Windows system call.  Squeezing one OS into emulation
of another should be expected to be problematic.

> There are consequences: for example, call-process and its ilk don't work
> reliably.  You can't expect the arguments given to them to actually make
> it unmolested to the argc/argv of the called program's "main".

Only because the surrounding code expects a Posix-compliant set of
functions and syscalls.  It was not written with portability in mind
from the ground up.

Re: Emacs vista build failures

[David Kastrup]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: David Kastrup <dak@gnu.org>
>> Cc: Johannes Weiner <hannes@saeurebad.de>,  emacs-devel@gnu.org
>> Date: Tue, 22 Jul 2008 01:11:26 +0200
>> 
>> There is no reliable way to quote stuff you want to pass into a "system"
>> call.
>
> Of course, there is.  Assuming you know what shell will interpret the
> arguments, that is.

Yes, since COMMAND.COM and CMD.EXE behave quite differently, and also
differently on different versions of Windows.

So tell me: How to you quote the word (written as Lisp string) 
"\"goof\" " to the typical Windows shell?

>> In fact, it is not even guaranteed that calling "exec" will not mesh
>> up arguments or add or remove quoting.
>
> `exec' is not a Windows system call.  Squeezing one OS into emulation
> of another should be expected to be problematic.
>
>> There are consequences: for example, call-process and its ilk don't work
>> reliably.  You can't expect the arguments given to them to actually make
>> it unmolested to the argc/argv of the called program's "main".
>
> Only because the surrounding code expects a Posix-compliant set of
> functions and syscalls.  It was not written with portability in mind
> from the ground up.

I often doubt it was written with anything in mind.  As it stands, it is
a half-baked pseudo-Posix wrappery about CP/M calling conventions.

When looking at design and implementation of first DOS and later
Windows, I often had the feeling "this is so stupid and braindead that I
can hardly believe it".  With UNIX, the feeling was more often "I wish I
would have thought of that".

-- 
David Kastrup

Re: Emacs vista build failures

[Lennart Borgman (gmail)]

David Kastrup wrote:
> When looking at design and implementation of first DOS and later
> Windows, I often had the feeling "this is so stupid and braindead that I
> can hardly believe it".  With UNIX, the feeling was more often "I wish I
> would have thought of that".

Did not that change quite a lot when MS brought in important people from 
Digital Equipment Corp?

Re: Emacs vista build failures

[Eli Zaretskii]

> From: David Kastrup <dak@gnu.org>
> Cc: hannes@saeurebad.de,  emacs-devel@gnu.org
> Date: Tue, 22 Jul 2008 15:24:38 +0200
> 
> Yes, since COMMAND.COM and CMD.EXE behave quite differently, and also
> differently on different versions of Windows.

And zsh behaves differently from Bash which behaves differently from
the Borne shell.

> So tell me: How to you quote the word (written as Lisp string) 
> "\"goof\" " to the typical Windows shell?

See the Emacs makefiles for Windows.

> >> There are consequences: for example, call-process and its ilk don't work
> >> reliably.  You can't expect the arguments given to them to actually make
> >> it unmolested to the argc/argv of the called program's "main".
> >
> > Only because the surrounding code expects a Posix-compliant set of
> > functions and syscalls.  It was not written with portability in mind
> > from the ground up.
> 
> I often doubt it was written with anything in mind.  As it stands, it is
> a half-baked pseudo-Posix wrappery about CP/M calling conventions.

I was talking about Emacs code that implements call-process and its
subroutines.

> When looking at design and implementation of first DOS and later
> Windows, I often had the feeling "this is so stupid and braindead that I
> can hardly believe it".  With UNIX, the feeling was more often "I wish I
> would have thought of that".

Are you sure you know the design and implementation of DOS and Windows
well enough to say this?

Re: Emacs vista build failures

[David Kastrup]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: David Kastrup <dak@gnu.org>
>> Cc: hannes@saeurebad.de,  emacs-devel@gnu.org
>> Date: Tue, 22 Jul 2008 15:24:38 +0200
>> 
>> Yes, since COMMAND.COM and CMD.EXE behave quite differently, and also
>> differently on different versions of Windows.
>
> And zsh behaves differently from Bash which behaves differently from
> the Borne shell.

Not in the basic Bourne shell features.  There _are_ buggy Bourne shells
around.  But they still don't show that sort of variety that Microsoft
manages in its own product line.

>> So tell me: How to you quote the word (written as Lisp string) 
>> "\"goof\" " to the typical Windows shell?
>
> See the Emacs makefiles for Windows.

They don't quote such words.  So care to enlighted me?

>> When looking at design and implementation of first DOS and later
>> Windows, I often had the feeling "this is so stupid and braindead
>> that I can hardly believe it".  With UNIX, the feeling was more often
>> "I wish I would have thought of that".
>
> Are you sure you know the design and implementation of DOS and Windows
> well enough to say this?

I have worked with DOS beginning with version 1.0 when they were still
mainly working with FCBs rather than file descriptors, and I have worked
with CP/M, and I have worked with UNIX on various processors and OS/2.
I have done quite a bit of assembly and system programming in all of
those systems (many of that for pay), so I know a lot of the inheritage,
memory and system layouts, and I know a lot of the implementations, and
what system calls were done with what sort of data structures when what
sort of features were implemented imitating features from elsewhere.

So yes, I am sure that I know design and implementation of DOS and
Windows well enough to say what feelings I have.  And actually, I think
that I should not require all too much of a qualification to be allowed
to state my feelings.

-- 
David Kastrup

Re: Emacs vista build failures

[Eli Zaretskii]

> From: David Kastrup <dak@gnu.org>
> Date: Tue, 22 Jul 2008 16:34:58 +0200
> Cc: hannes@saeurebad.de, emacs-devel@gnu.org
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> From: David Kastrup <dak@gnu.org>
> >> Cc: hannes@saeurebad.de,  emacs-devel@gnu.org
> >> Date: Tue, 22 Jul 2008 15:24:38 +0200
> >> 
> >> Yes, since COMMAND.COM and CMD.EXE behave quite differently, and also
> >> differently on different versions of Windows.
> >
> > And zsh behaves differently from Bash which behaves differently from
> > the Borne shell.
> 
> Not in the basic Bourne shell features.

And COMMAND.COM behaves like CMD.EXE ``in the basic DOS shell
features''.

This can go on forever, you know.  Your bias and lack of objective
comparison are obvious.  No need to continue.

> >> So tell me: How to you quote the word (written as Lisp string) 
> >> "\"goof\" " to the typical Windows shell?
> >
> > See the Emacs makefiles for Windows.
> 
> They don't quote such words.

Yes, they do, see for example `check-declare' in lisp/makefile.w32-in.

> I have worked with DOS beginning with version 1.0 when they were still
> mainly working with FCBs rather than file descriptors, and I have worked
> with CP/M, and I have worked with UNIX on various processors and OS/2.
> I have done quite a bit of assembly and system programming in all of
> those systems (many of that for pay), so I know a lot of the inheritage,
> memory and system layouts, and I know a lot of the implementations, and
> what system calls were done with what sort of data structures when what
> sort of features were implemented imitating features from elsewhere.

Sorry, I'm not interested in a pissing contest.

Re: Emacs vista build failures

[David Kastrup]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: David Kastrup <dak@gnu.org>
>> Date: Tue, 22 Jul 2008 16:34:58 +0200
>> Cc: hannes@saeurebad.de, emacs-devel@gnu.org
>> 
>> Eli Zaretskii <eliz@gnu.org> writes:
>> 
>> >> From: David Kastrup <dak@gnu.org>
>> >> Cc: hannes@saeurebad.de,  emacs-devel@gnu.org
>> >> Date: Tue, 22 Jul 2008 15:24:38 +0200
>> >> 
>> >> Yes, since COMMAND.COM and CMD.EXE behave quite differently, and also
>> >> differently on different versions of Windows.
>> >
>> > And zsh behaves differently from Bash which behaves differently from
>> > the Borne shell.
>> 
>> Not in the basic Bourne shell features.
>
> And COMMAND.COM behaves like CMD.EXE ``in the basic DOS shell
> features''.

The % quoting is different.  Particularly when you get into loops.
Command line parameters are different.  There are other things.

> This can go on forever, you know.  Your bias and lack of objective
> comparison are obvious.  No need to continue.

Sure, I get to different results than you after having worked with
everything.  Naturally that makes me biased.

>> >> So tell me: How to you quote the word (written as Lisp string) 
>> >> "\"goof\" " to the typical Windows shell?
>> >
>> > See the Emacs makefiles for Windows.
>> 
>> They don't quote such words.
>
> Yes, they do, see for example `check-declare' in lisp/makefile.w32-in.

So why don't you just tell me?  You are the expert on Windows, having
tested it thoroughly and found it easy to use.  Just tell me how to pass
the string "\"goof\" " from the command line to a Windows batch file so
that it assigns it to a single positional parameter, including the
quotes and the trailing spaces?

>> I have worked with DOS beginning with version 1.0 when they were
>> still mainly working with FCBs rather than file descriptors, and I
>> have worked with CP/M, and I have worked with UNIX on various
>> processors and OS/2.  I have done quite a bit of assembly and system
>> programming in all of those systems (many of that for pay), so I know
>> a lot of the inheritage, memory and system layouts, and I know a lot
>> of the implementations, and what system calls were done with what
>> sort of data structures when what sort of features were implemented
>> imitating features from elsewhere.
>
> Sorry, I'm not interested in a pissing contest.

Don't question my qualifications if you don't want to hear them.

-- 
David Kastrup

Re: Emacs vista build failures

[Richard M Stallman]

Given that Windows is proprietary software, its technical shortcomings
(or absence of them) is a side issue.  If people want to discuss that,
would you please take it somewhere else?

Re: Emacs vista build failures

[Stephen J. Turnbull]

Eli Zaretskii writes:

 > running in user space.  Too bad it is under-documented (but then who
 > has ever heard about, let alone seen, good internals documentation in
 > the Free Software world?).

I have heard of it, of course; the XEmacs Project aspires to it.  IMO,
I've seen (some); YMMV, of course.

Re: Emacs vista build failures

[Johannes Weiner]

Hi,

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Johannes Weiner <hannes@saeurebad.de>
>> Date: Mon, 21 Jul 2008 20:37:17 +0200
>> Cc: lord@emf.net, rms@gnu.org, drobinow@gmail.com, emacs-devel@gnu.org,
>> 	acm@muc.de, Miles Bader <miles@gnu.org>
>> 
>> To be honest, I couldn't give the slightest about w32.  It's a pile of
>> crap that should have never seen the light of day, all political issues
>> left aside and I, FWIW, would not consider it when designing software.
>
> Such arrogant nonsense can only be forgiven if it's spoken out of
> utter ignorance.  Last time you took a good look at a Windows system
> was probably in 1998.  Wake up! a lot has changed since then.
>
> Nowadays, w32 systems don't fall short of Gnu/Linux in any aspect:
> stability, usability, user-friendliness, etc.  And the current trend
> in Gnu/Linux systems to mimic the Windows UI, feel, and touch bring
> more and more the worst parts of Windows to Gnu/Linux systems, to the
> degree that in a very near future they will be indistinguishable,
> anyway.

I can use a stripped-down version of GNU/Linux.  I neither use KDE nor
Gnome for example.  A lot of the time I chose to a bare screen session
on a VT without running X at all.  But I could start a full-blown
desktop environment at an instant, if I want to.

This modularity I have not seen in Windows so far and I doubt it will
get there soon.

On top of all this modularity, people now start to put blocks on top of
it that make it look like Windows or OS X, maybe.  But I can still chose
which blocks I want to use.

If people like using a complete desktop GNU/Linux distribution that
mimics Windows' look and feel, that's their choice.  And it's only ONE
FLAVOR of the possibilities you have.

> And if you are interested in OS architectural design, then Linux is
> simply boring: a huge monolithic kernel that came straight out of the
> dinosaur 70-s.  Whereas modern Windows systems are in this respect
> everything the Hurd wanted to be: microkernel with many services
> running in user space.

Linux is a fully-functioning, widely tested and bleeding-edge technology
operating system I can study the source code of.

What is your point?  Advertising a blackblox by telling me what cool
stuff it contains (you just have to believe!)?

> Too bad it is under-documented (but then who has ever heard about, let
> alone seen, good internals documentation in the Free Software world?).
>
> Posix is only one way to go, it is not the only way.  Saying I don't
> care for anything but Posix is like sticking to a single programming
> language: you will be a poorer programmer, because some paradigms
> evade you completely.

That is certainly true.  And I wouldn't mind seeing other good
approaches to operating system design.

	Hannes

Re: Emacs vista build failures

[Eli Zaretskii]

> From: Johannes Weiner <hannes@saeurebad.de>
> Cc: emacs-devel@gnu.org
> Date: Tue, 22 Jul 2008 05:41:39 +0200
> 
> What is your point?

That if you put politics aside, there's nothing left to make GNU/Linux
be much better than Windows.  Politics is what makes it stand out.

You said:

> To be honest, I couldn't give the slightest about w32.  It's a pile of
> crap that should have never seen the light of day, all political issues
> left aside and I, FWIW, would not consider it when designing software.

I'm saying that if you put all political issues aside, you are left
with no arguments in comparing these two systems.

Re: Emacs vista build failures

[David Kastrup]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Johannes Weiner <hannes@saeurebad.de>
>> Cc: emacs-devel@gnu.org
>> Date: Tue, 22 Jul 2008 05:41:39 +0200
>> 
>> What is your point?
>
> That if you put politics aside, there's nothing left to make GNU/Linux
> be much better than Windows.  Politics is what makes it stand out.

I've programmed both extensively.  And Windows really is a time sink
with its wagonload of inconsistencies.  The company I am currently
working with is rather Windows-centric.  After about half a year of
offering our main product on Windows as well, we abandoned the effort.
The level of inconsistencies and problems when doing, say, batch file
programming is really staggering, and we were continually getting
tripped up by further little niceties and problems.

Just a small example (stripped to the part of interest):

REM Get current directory
set targetdir=%CD%

REM %targetdir% has to be postprocessed since if it is a root directory,
REM it will end in a backslash which escapes a double quote when calling
REM Java.  So we append a single dot in that case.
for %%l in (%targetdir%) do if "%%~pnl" == "\" (set targetdir=%targetdir%.)

call ant.bat -Dinstaller.path="%targetdir%"


Can you imagine how many mandays get wasted on utterly appalling
workarounds like that?  And of course, this just works on one version of
cmd.exe, and might break on another.

Bourne shell programming is _much_ more consistent, regular, and simple.
Quite fewer commands, quite more uniform constructs, quite more power,
quite fewer exceptions and bad surprises.

And that's when I am talking about seventies level Bourne shell
programming.

Of course, Windows bashing has become a popular sport.  But it is not
all politics and arbitrary.  There are reasons, technical reasons (not
"just" that it is unfree) that Windows gets bashed and loathed.  After
all, there _are_ non-free Unix versions a dime (or was that a million?)
a dozen.

And it is not just a _different_ design that is getting the heat, but
pretty much the absence of much of a design and stupidity and
awkwardness that is hobbling productivity in utterly staggering ways.

This list certainly is not the place to discuss the presence or absence
of merits in Windows.  But if we get a bit more Emacs-specific and you
take a look at conditional code being used when under all sort of UNIX
systems and code being used when under w32, then take a good look at
what code is more complex and awkward.

-- 
David Kastrup

Re: Emacs vista build failures

[Lennart Borgman (gmail)]

David Kastrup wrote:
> Can you imagine how many mandays get wasted on utterly appalling
> workarounds like that?  And of course, this just works on one version of
> cmd.exe, and might break on another.

Why don't you use perl for example instead?

Re: Emacs vista build failures

[David Kastrup]

"Lennart Borgman (gmail)" <lennart.borgman@gmail.com> writes:

> David Kastrup wrote:
>> Can you imagine how many mandays get wasted on utterly appalling
>> workarounds like that?  And of course, this just works on one version of
>> cmd.exe, and might break on another.
>
> Why don't you use perl for example instead?

Chicken and egg.  Installation scripts have to rely on what is there.

-- 
David Kastrup

Re: Emacs vista build failures

[Lennart Borgman (gmail)]

David Kastrup wrote:
> "Lennart Borgman (gmail)" <lennart.borgman@gmail.com> writes:
> 
>> David Kastrup wrote:
>>> Can you imagine how many mandays get wasted on utterly appalling
>>> workarounds like that?  And of course, this just works on one version of
>>> cmd.exe, and might break on another.
>> Why don't you use perl for example instead?
> 
> Chicken and egg.  Installation scripts have to rely on what is there.

But you can build exectutable from perl scripts, or is not that 
possibility there any more?

Re: Emacs vista build failures

[David Kastrup]

"Lennart Borgman (gmail)" <lennart.borgman@gmail.com> writes:

> David Kastrup wrote:
>> "Lennart Borgman (gmail)" <lennart.borgman@gmail.com> writes:
>>
>>> David Kastrup wrote:
>>>> Can you imagine how many mandays get wasted on utterly appalling
>>>> workarounds like that?  And of course, this just works on one version of
>>>> cmd.exe, and might break on another.
>>> Why don't you use perl for example instead?
>>
>> Chicken and egg.  Installation scripts have to rely on what is there.
>
> But you can build exectutable from perl scripts, or is not that
> possibility there any more?

It means pulling in a lot of external technology for just a simple
scripting job.  Why should we do that if what is present in Windows is
so great?

-- 
David Kastrup

Re: Emacs vista build failures

[Lennart Borgman (gmail)]

David Kastrup wrote:
>>>> Why don't you use perl for example instead?
>>> Chicken and egg.  Installation scripts have to rely on what is there.
>> But you can build exectutable from perl scripts, or is not that
>> possibility there any more?
> 
> It means pulling in a lot of external technology for just a simple
> scripting job.  Why should we do that if what is present in Windows is
> so great?

I guess you know perl, of course. I might misunderstand what you are 
actually doing. There is vbs too and different installation software. 
But let us drop this, I just wanted to give a suggestion.

I agree this is a weak and disturbing point on w32, escpecially when you 
are used to have powerful scripting languages available. This is however 
not what w32 programmers use.

Re: Emacs vista build failures

[David Kastrup]

"Lennart Borgman (gmail)" <lennart.borgman@gmail.com> writes:

> David Kastrup wrote:
>>>>> Why don't you use perl for example instead?
>>>> Chicken and egg.  Installation scripts have to rely on what is there.
>>> But you can build exectutable from perl scripts, or is not that
>>> possibility there any more?

We needed a single executable for making installations and upgrades as
simple as possible for customers (they'll break everything otherwise).
A self-extracting batch file is doable reasonably well (once unzip.exe
has been installed).  Appending an archive to a .exe file is not as
feasible, in contrast.

>> It means pulling in a lot of external technology for just a simple
>> scripting job.  Why should we do that if what is present in Windows
>> is so great?
>
> I guess you know perl, of course. I might misunderstand what you are
> actually doing. There is vbs too and different installation
> software. But let us drop this, I just wanted to give a suggestion.

The main point is that we needed something we can support and that does
not deviate too much in functionality from our existing supported code.
Pulling in entirely different external technology just for installation
was not an option when "everything is there".

> I agree this is a weak and disturbing point on w32, escpecially when
>you are used to have powerful scripting languages available. This is
>however not what w32 programmers use.

Whatever.  After wasting in the order of manyears on this endeavor, we
have reverted to GNU/Linux installs.  People insisting on Windows get a
virtual machine.

I don't think I know of any multi-platform free software project where
the Windows port is not responsible for the most hair-tearing and
frustration.

-- 
David Kastrup

Re: Emacs vista build failures

[Lennart Borgman (gmail)]

David Kastrup wrote:
> "Lennart Borgman (gmail)" <lennart.borgman@gmail.com> writes:
>>>> But you can build exectutable from perl scripts, or is not that
>>>> possibility there any more?
> 
> We needed a single executable for making installations and upgrades as
> simple as possible for customers (they'll break everything otherwise).
> A self-extracting batch file is doable reasonably well (once unzip.exe
> has been installed).  Appending an archive to a .exe file is not as
> feasible, in contrast.

The perl script exectutable could perhaps be zipped together with any 
needed archives.

> I don't think I know of any multi-platform free software project where
> the Windows port is not responsible for the most hair-tearing and
> frustration.

When I started looking at Emacs I noticed there were cross platform 
installers emerging that could do quite a bit. (But do not ask me about 
the names of them now.)

Re: Emacs vista build failures

[Eli Zaretskii]

> X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,
> 	UNPARSEABLE_RELAY autolearn=unavailable version=3.1.0
> From: David Kastrup <dak@gnu.org>
> Date: Tue, 22 Jul 2008 17:13:39 +0200
> Cc: Eli Zaretskii <eliz@gnu.org>, Johannes Weiner <hannes@saeurebad.de>,
> 	emacs-devel@gnu.org
> 
> "Lennart Borgman (gmail)" <lennart.borgman@gmail.com> writes:
> 
> > David Kastrup wrote:
> >>>>> Why don't you use perl for example instead?
> >>>> Chicken and egg.  Installation scripts have to rely on what is there.
> >>> But you can build exectutable from perl scripts, or is not that
> >>> possibility there any more?
> 
> We needed a single executable for making installations and upgrades as
> simple as possible for customers (they'll break everything otherwise).
> A self-extracting batch file is doable reasonably well (once unzip.exe
> has been installed).  Appending an archive to a .exe file is not as
> feasible, in contrast.
> 
> >> It means pulling in a lot of external technology for just a simple
> >> scripting job.  Why should we do that if what is present in Windows
> >> is so great?
> >
> > I guess you know perl, of course. I might misunderstand what you are
> > actually doing. There is vbs too and different installation
> > software. But let us drop this, I just wanted to give a suggestion.
> 
> The main point is that we needed something we can support and that does
> not deviate too much in functionality from our existing supported code.
> Pulling in entirely different external technology just for installation
> was not an option when "everything is there".
> 
> > I agree this is a weak and disturbing point on w32, escpecially when
> >you are used to have powerful scripting languages available. This is
> >however not what w32 programmers use.
> 
> Whatever.  After wasting in the order of manyears on this endeavor, we
> have reverted to GNU/Linux installs.  People insisting on Windows get a
> virtual machine.
> 
> I don't think I know of any multi-platform free software project where
> the Windows port is not responsible for the most hair-tearing and
> frustration.
> 
> -- 
> David Kastrup
> 
> 
> 

Re: Emacs vista build failures

[Eli Zaretskii]

> From: David Kastrup <dak@gnu.org>
> Date: Tue, 22 Jul 2008 17:13:39 +0200
> Cc: Eli Zaretskii <eliz@gnu.org>, Johannes Weiner <hannes@saeurebad.de>,
> 	emacs-devel@gnu.org
> 
> I don't think I know of any multi-platform free software project where
> the Windows port is not responsible for the most hair-tearing and
> frustration.

I do.  We have such a project in the software shop where I get my
paycheck.

Re: Emacs vista build failures

[David Kastrup]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: David Kastrup <dak@gnu.org>
>> Date: Tue, 22 Jul 2008 17:13:39 +0200
>> Cc: Eli Zaretskii <eliz@gnu.org>, Johannes Weiner <hannes@saeurebad.de>,
>> 	emacs-devel@gnu.org
>> 
>> I don't think I know of any multi-platform free software project where
>> the Windows port is not responsible for the most hair-tearing and
>> frustration.
>
> I do.  We have such a project in the software shop where I get my
> paycheck.

If it is free software, it should be reasonably easy to get a hold of a
copy.  Where can I take a look?

-- 
David Kastrup

Re: Emacs vista build failures

[Eli Zaretskii]

> From: David Kastrup <dak@gnu.org>
> Date: Tue, 22 Jul 2008 17:26:23 +0200
> Cc: lennart.borgman@gmail.com, hannes@saeurebad.de, emacs-devel@gnu.org
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> From: David Kastrup <dak@gnu.org>
> >> Date: Tue, 22 Jul 2008 17:13:39 +0200
> >> Cc: Eli Zaretskii <eliz@gnu.org>, Johannes Weiner <hannes@saeurebad.de>,
> >> 	emacs-devel@gnu.org
> >> 
> >> I don't think I know of any multi-platform free software project where
> >> the Windows port is not responsible for the most hair-tearing and
> >> frustration.
> >
> > I do.  We have such a project in the software shop where I get my
> > paycheck.
> 
> If it is free software, it should be reasonably easy to get a hold of a
> copy.  Where can I take a look?

It is not free software, but I don't see why should that be relevant
in this context.

Re: Emacs vista build failures

[David Kastrup]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: David Kastrup <dak@gnu.org>
>> Date: Tue, 22 Jul 2008 17:26:23 +0200
>> Cc: lennart.borgman@gmail.com, hannes@saeurebad.de, emacs-devel@gnu.org
>> 
>> Eli Zaretskii <eliz@gnu.org> writes:
>> 
>> >> From: David Kastrup <dak@gnu.org>
>> >> Date: Tue, 22 Jul 2008 17:13:39 +0200
>> >> Cc: Eli Zaretskii <eliz@gnu.org>, Johannes Weiner <hannes@saeurebad.de>,
>> >> 	emacs-devel@gnu.org
>> >> 
>> >> I don't think I know of any multi-platform free software project where
>> >> the Windows port is not responsible for the most hair-tearing and
>> >> frustration.
>> >
>> > I do.  We have such a project in the software shop where I get my
>> > paycheck.
>> 
>> If it is free software, it should be reasonably easy to get a hold of a
>> copy.  Where can I take a look?
>
> It is not free software, but I don't see why should that be relevant
> in this context.

Because you claimed "I do" above when I said "I don't think I know of
any multi-platform free software project ...".

It is clear that our use of language is sufficiently different to make a
discussion worthless.  Even if it were not off-topic.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Emacs vista build failures

[Sven Joachim]

On 2008-07-22 16:47 +0200, Lennart Borgman (gmail) wrote:

> David Kastrup wrote:
>> "Lennart Borgman (gmail)" <lennart.borgman@gmail.com> writes:
>>
>>> David Kastrup wrote:
>>>> Can you imagine how many mandays get wasted on utterly appalling
>>>> workarounds like that?  And of course, this just works on one version of
>>>> cmd.exe, and might break on another.
>>> Why don't you use perl for example instead?
>>
>> Chicken and egg.  Installation scripts have to rely on what is there.
>
> But you can build exectutable from perl scripts, or is not that
> possibility there any more?

If you're referring to perlcc, that was indeed removed from Perl 5.10.

Sven

Re: Emacs vista build failures

[Lennart Borgman (gmail)]

Sven Joachim wrote:
> On 2008-07-22 16:47 +0200, Lennart Borgman (gmail) wrote:
> 
>> David Kastrup wrote:
>>> "Lennart Borgman (gmail)" <lennart.borgman@gmail.com> writes:
>>>
>>>> David Kastrup wrote:
>>>>> Can you imagine how many mandays get wasted on utterly appalling
>>>>> workarounds like that?  And of course, this just works on one version of
>>>>> cmd.exe, and might break on another.
>>>> Why don't you use perl for example instead?
>>> Chicken and egg.  Installation scripts have to rely on what is there.
>> But you can build exectutable from perl scripts, or is not that
>> possibility there any more?
> 
> If you're referring to perlcc, that was indeed removed from Perl 5.10.

I believe there are still a commercial alternative for it.

Re: Emacs vista build failures

[Sean O'Rourke]

"Lennart Borgman (gmail)" <lennart.borgman@gmail.com> writes:

> Sven Joachim wrote:
>> On 2008-07-22 16:47 +0200, Lennart Borgman (gmail) wrote:
>>
>>> David Kastrup wrote:
>>>> "Lennart Borgman (gmail)" <lennart.borgman@gmail.com> writes:
>>>>
>>>>> David Kastrup wrote:
>>>>>> Can you imagine how many mandays get wasted on utterly appalling
>>>>>> workarounds like that?  And of course, this just works on one version of
>>>>>> cmd.exe, and might break on another.
>>>>> Why don't you use perl for example instead?
>>>> Chicken and egg.  Installation scripts have to rely on what is there.
>>> But you can build exectutable from perl scripts, or is not that
>>> possibility there any more?
>>
>> If you're referring to perlcc, that was indeed removed from Perl 5.10.
>
> I believe there are still a commercial alternative for it.

PAR's pp[1] utility does this, I believe, and is free.

Sean

[1] http://search.cpan.org/~smueller/PAR-Packer-0.980/lib/pp.pm

Re: Emacs vista build failures

[Eli Zaretskii]

> From: David Kastrup <dak@gnu.org>
> Date: Tue, 22 Jul 2008 16:04:03 +0200
> Cc: Johannes Weiner <hannes@saeurebad.de>, emacs-devel@gnu.org
> 
> REM Get current directory
> set targetdir=%CD%
> 
> REM %targetdir% has to be postprocessed since if it is a root directory,
> REM it will end in a backslash which escapes a double quote when calling
> REM Java.  So we append a single dot in that case.
> for %%l in (%targetdir%) do if "%%~pnl" == "\" (set targetdir=%targetdir%.)
> 
> call ant.bat -Dinstaller.path="%targetdir%"
> 
> 
> Can you imagine how many mandays get wasted on utterly appalling
> workarounds like that?  And of course, this just works on one version of
> cmd.exe, and might break on another.
> 
> Bourne shell programming is _much_ more consistent, regular, and simple.

Again, you are approaching a non-Posix platforms with Posix-centric
perspective.  Shell programming is a Posix idea.  If you want a
program, write it in a programming language, not in shell.

> This list certainly is not the place to discuss the presence or absence
> of merits in Windows.  But if we get a bit more Emacs-specific and you
> take a look at conditional code being used when under all sort of UNIX
> systems and code being used when under w32, then take a good look at
> what code is more complex and awkward.

I already explained why: the original code was designed with Posix
functionality in mind, that's why it doesn't port easily to anything
else.

Re: Emacs vista build failures

[David Kastrup]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: David Kastrup <dak@gnu.org>
>> Date: Tue, 22 Jul 2008 16:04:03 +0200
>> Cc: Johannes Weiner <hannes@saeurebad.de>, emacs-devel@gnu.org
>> 
>> REM Get current directory
>> set targetdir=%CD%
>> 
>> REM %targetdir% has to be postprocessed since if it is a root directory,
>> REM it will end in a backslash which escapes a double quote when calling
>> REM Java.  So we append a single dot in that case.
>> for %%l in (%targetdir%) do if "%%~pnl" == "\" (set targetdir=%targetdir%.)
>> 
>> call ant.bat -Dinstaller.path="%targetdir%"
>> 
>> 
>> Can you imagine how many mandays get wasted on utterly appalling
>> workarounds like that?  And of course, this just works on one version of
>> cmd.exe, and might break on another.
>> 
>> Bourne shell programming is _much_ more consistent, regular, and simple.
>
> Again, you are approaching a non-Posix platforms with Posix-centric
> perspective.  Shell programming is a Posix idea.  If you want a
> program, write it in a programming language, not in shell.

So what programming languages does Windows come with?  Or are we not
actually talking about Windows after all?  "Windows is great, because
you can get something else to work around its shortcomings."?

>> This list certainly is not the place to discuss the presence or
>> absence of merits in Windows.  But if we get a bit more
>> Emacs-specific and you take a look at conditional code being used
>> when under all sort of UNIX systems and code being used when under
>> w32, then take a good look at what code is more complex and awkward.
>
> I already explained why: the original code was designed with Posix
> functionality in mind, that's why it doesn't port easily to anything
> else.

Whatever.  It is clear that you will not be fazed from your claims.  So
it is rather pointless to continue this charade.

-- 
David Kastrup

Re: Emacs vista build failures

[Johannes Weiner]

Hi,

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Johannes Weiner <hannes@saeurebad.de>
>> Cc: emacs-devel@gnu.org
>> Date: Tue, 22 Jul 2008 05:41:39 +0200
>> 
>> What is your point?
>
> That if you put politics aside, there's nothing left to make GNU/Linux
> be much better than Windows.  Politics is what makes it stand out.
>
> You said:
>
>> To be honest, I couldn't give the slightest about w32.  It's a pile of
>> crap that should have never seen the light of day, all political issues
>> left aside and I, FWIW, would not consider it when designing software.
>
> I'm saying that if you put all political issues aside, you are left
> with no arguments in comparing these two systems.

ROTFL.

Re: Emacs vista build failures

[Richard M Stallman]

    Linux is a fully-functioning, widely tested and bleeding-edge technology
    operating system I can study the source code of.

Linux is a kernel.  If you're thinking about a fully-functioning
operating system, you must mean GNU+Linux.
See http://www.gnu.org/gnu/gnu-linux-faq.html.

Re: Emacs vista build failures

[Johannes Weiner]

Richard M Stallman <rms@gnu.org> writes:

>     Linux is a fully-functioning, widely tested and bleeding-edge technology
>     operating system I can study the source code of.
>
> Linux is a kernel.  If you're thinking about a fully-functioning
> operating system, you must mean GNU+Linux.
> See http://www.gnu.org/gnu/gnu-linux-faq.html.

You might want to throttle your auto-responder that triggers whenever
someone refers to `Linux' without the GNU/ prefix.

I really MEANT the kernel.

Quoting wikipedia:

  An operating system (commonly abbreviated OS and O/S) is the software
  component of a computer system that is responsible for the management
  and coordination of activities and the sharing of the resources of the
  computer. The operating system acts as a host for application programs
  that are run on the machine.

So when I said `fully-functioning operating system' I did not mention
userspace at all.

If that nomenclature is wrong I would be glad if you could adjust the
Wikipedia article.

I hope it makes you happy when I say that I also use, study, improve
(where possible) and propagate GNU software that I use in combination
with the Linux kernel :)

	Hannes

Re: Emacs vista build failures

[Miles Bader]

Johannes Weiner <hannes@saeurebad.de> writes:
> So when I said `fully-functioning operating system' I did not mention
> userspace at all.
>
> If that nomenclature is wrong I would be glad if you could adjust the
> Wikipedia article.

For whatever reason, it's a huge hot-button stupid flamewar frantic
slapfest topic.

I shudder to think what happens on the wikipedia article...

-Miles

-- 
Everywhere is walking distance if you have the time.  -- Steven Wright

Re: Emacs vista build failures

[Richard M Stallman]

    You might want to throttle your auto-responder that triggers whenever
    someone refers to `Linux' without the GNU/ prefix.

That is an insulting thing to say.  I thought about how to respond
to your message, as I always do.

    I really MEANT the kernel.

In that case, you could have made your meaning unambiguous by saying
"kernel".  Since we were talking about Windows, which is a complete
operating system (not a kernel), it was entirely reasonable for me to
think you too meant a complete system.

    Quoting wikipedia:

      An operating system (commonly abbreviated OS and O/S) is the software
      component of a computer system that is responsible for the management
      and coordination of activities and the sharing of the resources of the
      computer. The operating system acts as a host for application programs
      that are run on the machine.

That is one of the two customary meanings of operating system.
The other customary meaning refers to the whole system.

Wikipedia ought to mention both, but I cannot fight them
over this.

Re: Emacs vista build failures

[Johannes Weiner]

Hi,

Richard M Stallman <rms@gnu.org> writes:

>     You might want to throttle your auto-responder that triggers whenever
>     someone refers to `Linux' without the GNU/ prefix.
>
> That is an insulting thing to say.  I thought about how to respond
> to your message, as I always do.

My term was ambiguous to you.  You chose to respond as if I have been
factually wrong rather than having said something debatable.  So I felt
insulted too.

>     I really MEANT the kernel.
>
> In that case, you could have made your meaning unambiguous by saying
> "kernel".  Since we were talking about Windows, which is a complete
> operating system (not a kernel), it was entirely reasonable for me to
> think you too meant a complete system.
>
>     Quoting wikipedia:
>
>       An operating system (commonly abbreviated OS and O/S) is the software
>       component of a computer system that is responsible for the management
>       and coordination of activities and the sharing of the resources of the
>       computer. The operating system acts as a host for application programs
>       that are run on the machine.
>
> That is one of the two customary meanings of operating system.
> The other customary meaning refers to the whole system.
>
> Wikipedia ought to mention both, but I cannot fight them
> over this.

Is there a `them' in Wikipedia? :-)

	Hannes

Re: Emacs vista build failures

[Stefan Monnier]

> Quoting wikipedia:

>   An operating system (commonly abbreviated OS and O/S) is the software
>   component of a computer system that is responsible for the management
>   and coordination of activities and the sharing of the resources of the
>   computer. The operating system acts as a host for application programs
>   that are run on the machine.

That's sufficiently vague to mean either a kernel or a whole OS.
E.g. X11 would probably fall into this description, as would a DNS
caching proxy, the /sbin/init program, or even gdm, network-manager,
gnome-power-manager, nfsd, ...

> So when I said `fully-functioning operating system' I did not mention
> userspace at all.

In most circumstances, nowadays, a kernel is a very far cry from
a "fully functioning operating system".  The Linux kernel is no
exception here.


        Stefan

Re: Emacs vista build failures

[Johannes Weiner]

Hi,

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

>> Quoting wikipedia:
>
>>   An operating system (commonly abbreviated OS and O/S) is the software
>>   component of a computer system that is responsible for the management
>>   and coordination of activities and the sharing of the resources of the
>>   computer. The operating system acts as a host for application programs
>>   that are run on the machine.
>
> That's sufficiently vague to mean either a kernel or a whole OS.
> E.g. X11 would probably fall into this description, as would a DNS
> caching proxy, the /sbin/init program, or even gdm, network-manager,
> gnome-power-manager, nfsd, ...

Well, the most fundamental resource-manager and application host on a
computer is the kernel.  I am sorry if that was unclear.

>> So when I said `fully-functioning operating system' I did not mention
>> userspace at all.
>
> In most circumstances, nowadays, a kernel is a very far cry from
> a "fully functioning operating system".  The Linux kernel is no
> exception here.

I don't know how I respond to that as you said you wouldn't understand
the term `operating system' being a kernel only.

If you meant it as being a whole system including userspace, than it's
surely not a complete operating system.

If you meant it as being a kernel, then what's missing?

	Hannes

Re: Emacs vista build failures

[Richard M Stallman]

    And once again: If this did not work easily on w32 too it might stop 
    people from using it.

We must reject any presumption that free programs should work on
Windows.  It is ok to cooperate with users who want to add such
support, but we must not make it part of the expected goals of a free
software project.  I think the GNU maintainer conventions file talks
about this.

Re: Emacs vista build failures

[Lennart Borgman (gmail)]

Richard M Stallman wrote:
>     And once again: If this did not work easily on w32 too it might stop 
>     people from using it.
> 
> We must reject any presumption that free programs should work on
> Windows.

Yes, but that is a different thing. IF making free programs working on 
windows helps promote GNU/Linux (or Herd) is not that good?

Re: Emacs vista build failures

[David Kastrup]

"Lennart Borgman (gmail)" <lennart.borgman@gmail.com> writes:

> Richard M Stallman wrote:
>>     And once again: If this did not work easily on w32 too it might
>> stop     people from using it.
>>
>> We must reject any presumption that free programs should work on
>> Windows.
>
> Yes, but that is a different thing. IF making free programs working on
> windows helps promote GNU/Linux (or Herd) is not that good?

Our first goal is to have a free operating system.  This benefits
everybody since anybody is free to use that as long as his hardware
supports it.  So if people work on Windows software who would otherwise
work on improving a free system, everybody loses, while only the users
of the non-free operating system gain.

If people who work only on proprietary systems otherwise make free
software work on those systems, nobody loses.

In short, we should not lose our focus.  Winning people to free software
through Emacs on Windows can't work if the free systems become worse
because of the redirection of effort.  If we want to win them over to
free systems, we should make the free systems as good as we can, not the
unfree ones.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Emacs vista build failures

[Bastien]

David Kastrup <dak@gnu.org> writes:

> "Lennart Borgman (gmail)" <lennart.borgman@gmail.com> writes:
>
>> Richard M Stallman wrote:
>>>     And once again: If this did not work easily on w32 too it might
>>> stop     people from using it.
>>>
>>> We must reject any presumption that free programs should work on
>>> Windows.
>>
>> Yes, but that is a different thing. IF making free programs working on
>> windows helps promote GNU/Linux (or Herd) is not that good?
>
> Our first goal is to have a free operating system.  This benefits
> everybody since anybody is free to use that as long as his hardware
> supports it.  So if people work on Windows software who would otherwise
> work on improving a free system, everybody loses, while only the users
> of the non-free operating system gain.
>
> If people who work only on proprietary systems otherwise make free
> software work on those systems, nobody loses.
>
> In short, we should not lose our focus.  Winning people to free software
> through Emacs on Windows can't work if the free systems become worse
> because of the redirection of effort.  If we want to win them over to
> free systems, we should make the free systems as good as we can, not the
> unfree ones.

Very well said.

But proprietary systems are not only tools, they are also a media: while
running on such platforms, free softwares do advertize the free software
movement beyond free systems.

While it's that true you cannot invest too much in communication, it's
also important to recognize that running free software on a proprietary
system is also useful - otherwise you will just strenghten a feeling of
guilt in people working for that purpose!

Of course, the fact that a computer is both a tool and a media tends to
limit the scope of this argument, but maybe it comes close to Lennart's
(and others') point.

-- 
Bastien

Re: Emacs vista build failures

[Richard M Stallman]

    IF making free programs working on 
    windows helps promote GNU/Linux (or Herd) is not that good?

Yes, but we can't assume in general that that is the case.  For a few
programs, such as OpenOffice and Firefox, the fact that they run on
Windows seems to be a signficant aid to migration to GNU/Linux.  But I
don't see that this is true for other free programs.

Re: Emacs vista build failures

[Johannes Weiner]

Hi,

Richard M Stallman <rms@gnu.org> writes:

>     IF making free programs working on 
>     windows helps promote GNU/Linux (or Herd) is not that good?
>
> Yes, but we can't assume in general that that is the case.  For a few
> programs, such as OpenOffice and Firefox, the fact that they run on
> Windows seems to be a signficant aid to migration to GNU/Linux.

Are they really?  I wonder how many users would have migrated if they'd
still have to use Internet Explorer :-)

	Hannes

Re: Emacs vista build failures

[Lennart Borgman (gmail)]

Richard M Stallman wrote:
>     IF making free programs working on 
>     windows helps promote GNU/Linux (or Herd) is not that good?
> 
> Yes, but we can't assume in general that that is the case.  For a few
> programs, such as OpenOffice and Firefox, the fact that they run on
> Windows seems to be a signficant aid to migration to GNU/Linux.  But I
> don't see that this is true for other free programs.

The programs you mention are end user programs. That they are (or seem 
to be) an aid is perhaps rather easy to detect since the effect is 
rather immediate.

Developers programs might not have an immediate effect, but I believe 
the long time aid might be much larger. This effect is more difficult to 
detect since it is a long time effect. And even so since a lot of things 
must cooperate before user sees the effect.

It looks to me that the Mozilla people have drawn a similar conclusion 
since they offer their own portable platform for development (XUL).

Re: Emacs vista build failures

[David Kastrup]

"Lennart Borgman (gmail)" <lennart.borgman@gmail.com> writes:

> Richard M Stallman wrote:
>>     IF making free programs working on     windows helps promote
>> GNU/Linux (or Herd) is not that good?
>>
>> Yes, but we can't assume in general that that is the case.  For a few
>> programs, such as OpenOffice and Firefox, the fact that they run on
>> Windows seems to be a signficant aid to migration to GNU/Linux.  But I
>> don't see that this is true for other free programs.
>
> The programs you mention are end user programs. That they are (or seem
> to be) an aid is perhaps rather easy to detect since the effect is
> rather immediate.
>
> Developers programs might not have an immediate effect, but I believe
> the long time aid might be much larger.

Why?  It makes it easier to stay on proprietary platforms.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Emacs vista build failures

[Richard M Stallman]

    Developers programs might not have an immediate effect, but I believe 
    the long time aid might be much larger.

I see no reason to think such an effect exists.  Meanwhile, people
have told me that the fact that Emacs runs on Windows undercut their
ability to insist on running GNU/Linux at work.

Without some sort of demonstration I decline to believe that this
helps us.

Re: Emacs vista build failures

[Lennart Borgman (gmail)]

Richard M Stallman wrote:
>     Developers programs might not have an immediate effect, but I believe 
>     the long time aid might be much larger.
> 
> I see no reason to think such an effect exists.  Meanwhile, people
> have told me that the fact that Emacs runs on Windows undercut their
> ability to insist on running GNU/Linux at work.

That is a bad effect of course, but I wonder how much impact it really has.

> Without some sort of demonstration I decline to believe that this
> helps us.

It might be difficult to demonstrate but what I am thinking is that if 
more people knows the tools for developing software on/for free system 
they can contribute on their free time. (And in many cases bring 
experience with them from non-free systems.)

One way to look into this question is perhaps to ask people developing 
software that runs on free systems where they have learned it and if it 
has been any help to them that these tools also runs on non-free systems.

At the same time one can ask whether they have got any valuable ideas 
for development when meeting both free and non-free system/software. 
Because such encounters will be more frequent if free software tools 
also runs on non-free systems.

Re: Emacs vista build failures

[Nick Roberts]

 > One way to look into this question is perhaps to ask people developing 
 > software that runs on free systems where they have learned it and if it 
 > has been any help to them that these tools also runs on non-free systems.

It's only worth asking these questions if a negative conclusion would mean that
people are going to stop working on/distributing Emacs on non-free systems.
Since they are probably not going to do that, it's probably best to just
have tolerance for one another.

-- 
Nick                                           http://www.inet.net.nz/~nickrob

Re: Emacs vista build failures

[Lennart Borgman (gmail)]

Nick Roberts wrote:
>  > One way to look into this question is perhaps to ask people developing 
>  > software that runs on free systems where they have learned it and if it 
>  > has been any help to them that these tools also runs on non-free systems.
> 
> It's only worth asking these questions if a negative conclusion would mean that
> people are going to stop working on/distributing Emacs on non-free systems.
> Since they are probably not going to do that, it's probably best to just
> have tolerance for one another.

Don't you when you write this already assume that it is negative to work 
for free software development tools on Windows? Is not your conclusion 
already done then?

I would say that if these questions are asked one might come to the 
conclusion that better support on non-free systems may promote free systems.

I for one has found it quite irritating having to spend so much time 
trying to fix problems with Emacs on w32 instead of raising the level of 
Emacs in different areas.

But it is difficult, or rather impossible, to draw final conclusions. 
You have to take into account many things. What one can hope for is that 
looking into the questions gives input for strategies to use.

Re: Emacs vista build failures

[Richard M Stallman]

    I for one has found it quite irritating having to spend so much time 
    trying to fix problems with Emacs on w32 instead of raising the level of 
    Emacs in different areas.

You could install GNU/Linux on a machine, and do your Emacs
development there.  Then not only your editor, but all the rest of
your system, will not subjugate you.

Re: Emacs vista build failures

[Richard M Stallman]

    It might be difficult to demonstrate but what I am thinking is that if 
    more people knows the tools for developing software on/for free system 
    they can contribute on their free time. (And in many cases bring 
    experience with them from non-free systems.)

In principle, they can.  But do they contribute to things that are
generally useful, or only to porting to their systems?

    One way to look into this question is perhaps to ask people developing 
    software that runs on free systems where they have learned it and if it 
    has been any help to them that these tools also runs on non-free systems.

That would be an interesting question to ask in a survey.

Re: Emacs vista build failures

[Óscar Fuentes]

Richard M Stallman <rms@gnu.org> writes:

>     Developers programs might not have an immediate effect, but I believe 
>     the long time aid might be much larger.
>
> I see no reason to think such an effect exists.  Meanwhile, people
> have told me that the fact that Emacs runs on Windows undercut their
> ability to insist on running GNU/Linux at work.

I was a Windows-only closed-source developer. NTEmacs introduced me to
Free Software. So good was the experience that started to use MinGW and
Cygwin. Inevitably this lead me to GNU/Linux. Today, all my software is
cross-platform and my customers can use it on GNU/Linux, if they wish.

I'm still a Windows closed-source developer. Changing this would mean
the end of my career as computer programmer. None of my customers chose
GNU/Linux, and I all can say is that this is well justified in almost
all cases. However, I still keep my software "GNU/Linux-ready".

NTEmacs is not slowing down my transition to GNU/Linux, because I can't
(fully) go that route. NTEmacs is the responsible of me being a Free
Software advocate... when Free Software makes sense.

So far, the Free Software philosophy is a success when the software is
targeted at hackers (Emacs, gcc, GNU/Linux servers...) and clearly
inferior when targeted at "common" users. IMO, the reason is obvious:
hackers does not understand the needs of common users. And when I say
"inferior" or "needs" I don't mean "user experience" or "features" or
"quality", I mean economics. But you need to think as a businessman to
understand this.

-- 
Oscar

Re: Emacs vista build failures

[Richard M Stallman]

    I'm still a Windows [proprietary software] developer. Changing
    this would mean the end of my career as computer programmer.

You didn't say whether "your software" is free software, and I suspect
it isn't.  If your career as a computer programmer consists of
developing proprietary software, I hope that career ends soon.

     NTEmacs is the responsible of me being a Free
    Software advocate... when Free Software makes sense.

To say that there might be times when Free software doesn't "make
sense" is, in effect, to grant ethical legitimacy.  So you're not
really a free software advocate at all.  You only appreciate using
some free software.

    So far, the Free Software philosophy is a success when the software is
    targeted at hackers (Emacs, gcc, GNU/Linux servers...) and clearly
    inferior when targeted at "common" users.

I think you're mistaken, but that's a side issue.  Your statements
show the clearly that you don't care about freedom for computer users.
Since you don't share our goals, we should not listen to your advice.

Re: Emacs vista build failures

[Eli Zaretskii]

> From: Richard M Stallman <rms@gnu.org>
> Date: Fri, 25 Jul 2008 21:23:55 -0400
> Cc: emacs-devel@gnu.org
> 
>     I'm still a Windows [proprietary software] developer. Changing
>     this would mean the end of my career as computer programmer.
> 
> You didn't say whether "your software" is free software, and I suspect
> it isn't.  If your career as a computer programmer consists of
> developing proprietary software, I hope that career ends soon.

Perhaps we should conduct a survey on this list, to see how many
people here should have their career "end soon".

Re: Emacs vista build failures

[Lennart Borgman (gmail)]

Richard M Stallman wrote:
> If your career as a computer programmer consists of
> developing proprietary software, I hope that career ends soon.

I would like to believe that you speak as a free software advocate when 
you write this and that there is no personal feelings in your words, but 
I am unable to understand your thinking here.

If you consider the sum of all the consequences that Óscar looses his 
job, why do you think this is beneficial for free software?

Re: Emacs vista build failures

[Stefan Monnier]

> If you consider the sum of all the consequences that Óscar looses his job,
> why do you think this is beneficial for free software?

Obviously, Richard's intention is not to say that Oscar should lose his
job, but that he should switch to a job where he's paid to write
Free Software.


        Stefan "What does this have to do with Emacs, again?"

Re: Emacs vista build failures

[Miles Bader]

Richard M Stallman <rms@gnu.org> writes:
> I see no reason to think such an effect exists.  Meanwhile, people
> have told me that the fact that Emacs runs on Windows undercut their
> ability to insist on running GNU/Linux at work.

This seems pretty surprising ... the sort of people that say "just use
windows" are also the sort to say "just use visual studio / notepad / ...".

In my _personal_ experience, emacs on windows has been something of a
nice tool to introduce people to the free software world.  There are
other free apps like firefox that can do this too, but there's something
fairly unique about emacs -- it's not just "a better browser" or even
just "a better editor".

-miles

-- 
Alone, adj. In bad company.

Re: Emacs vista build failures

[Richard M Stallman]

    > I see no reason to think such an effect exists.  Meanwhile, people
    > have told me that the fact that Emacs runs on Windows undercut their
    > ability to insist on running GNU/Linux at work.

    This seems pretty surprising ... the sort of people that say "just use
    windows" are also the sort to say "just use visual studio / notepad / ...".

They said they used to tell the boss, "I have to run GNU/Linux
so I can run Emacs; otherwise I can't be productive."

Re: Emacs vista build failures

[Eli Zaretskii]

> From: Richard M Stallman <rms@gnu.org>
> Date: Thu, 24 Jul 2008 18:04:40 -0400
> Cc: lord@emf.net, drobinow@gmail.com, hannes@saeurebad.de, emacs-devel@gnu.org,
> 	acm@muc.de, miles@gnu.org
> 
>     Developers programs might not have an immediate effect, but I believe 
>     the long time aid might be much larger.
> 
> I see no reason to think such an effect exists.  Meanwhile, people
> have told me that the fact that Emacs runs on Windows undercut their
> ability to insist on running GNU/Linux at work.
> 
> Without some sort of demonstration I decline to believe that this
> helps us.

Why do you believe the former claims more than you believe the latter?
Let those who claim the former "demonstrate" it first.

Re: Emacs vista build failures

[Richard M Stallman]

    > I see no reason to think such an effect exists.  Meanwhile, people
    > have told me that the fact that Emacs runs on Windows undercut their
    > ability to insist on running GNU/Linux at work.
    > 
    > Without some sort of demonstration I decline to believe that this
    > helps us.

    Why do you believe the former claims more than you believe the latter?

Because those people were telling me about what had happened to them
personally.  So far nobody has reported seeing that supporting Emacs
on Windows helps us; it is just speculation.

    Let those who claim the former "demonstrate" it first.

I think their testimony is sufficient proof that it happened to them.

However, I do not know how often this happens.

Re: Emacs vista build failures

[Eli Zaretskii]

> From: Richard M Stallman <rms@gnu.org>
> CC: emacs-devel@gnu.org
> Date: Fri, 25 Jul 2008 21:24:16 -0400
> 
>     > I see no reason to think such an effect exists.  Meanwhile, people
>     > have told me that the fact that Emacs runs on Windows undercut their
>     > ability to insist on running GNU/Linux at work.
>     > 
>     > Without some sort of demonstration I decline to believe that this
>     > helps us.
> 
>     Why do you believe the former claims more than you believe the latter?
> 
> Because those people were telling me about what had happened to them
> personally.  So far nobody has reported seeing that supporting Emacs
> on Windows helps us; it is just speculation.

Someone already posted an opposite experience.  And I've heard similar
evidence from quite a few others.

Re: Emacs vista build failures

[Alan Mackenzie]

Hi, Richard!

On Wed, Jul 23, 2008 at 12:56:12PM -0400, Richard M Stallman wrote:
>     IF making free programs working on windows helps promote GNU/Linux
>     (or Herd) is not that good?

> Yes, but we can't assume in general that that is the case.  For a few
> programs, such as OpenOffice and Firefox, the fact that they run on
> Windows seems to be a signficant aid to migration to GNU/Linux.  But I
> don't see that this is true for other free programs.

This is rather fundamental:  Why do we write free software? My personal
motivation is to make the world a better place.  I think for you, by
contrast, the propagation of free software is an end in itself, so your
answers to the following questions might well be different from mine.

When I ask myself, is the world better for having Emacs and Firefox
running on Microsoft Windows, the answer is an unequivocal yes - people
who hack on MS-Windows can thus do a better job.  Therefore it is
worthwhile spending effort making Emacs work on this (and other
proprietary) systems.

Could the availability of free software on non-free OSs remove an
incentive for people to convert to completely free systems?  It could in
theory, but I don't think it does in practice.  In most of the places
I've worked, there's a massive network of MS-Windows PCs, and sometimes
there's a Unix network too.  Converting to GNU or BSD isn't an option in
these places.

Getting people to use Emacs is, though.  All of the people I've
introduced to Emacs have taken it up because I've shown them what it can
do and they've liked it.  This even includes a project manager, who liked
Hi Lock Mode.  None of them were bothered at all about it being free
software, beyond the welcome lack of licensing hassles.

The availability of free software on proprietary OSs might well cause the
newly enlightened to explore free software further and possibly to start
hacking it.  A lack of free software on these OSs most surely will not.

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: Emacs vista build failures

[David Kastrup]

Alan Mackenzie <acm@muc.de> writes:

> Hi, Richard!
>
> On Wed, Jul 23, 2008 at 12:56:12PM -0400, Richard M Stallman wrote:
>>     IF making free programs working on windows helps promote GNU/Linux
>>     (or Herd) is not that good?
>
>> Yes, but we can't assume in general that that is the case.  For a few
>> programs, such as OpenOffice and Firefox, the fact that they run on
>> Windows seems to be a signficant aid to migration to GNU/Linux.  But I
>> don't see that this is true for other free programs.
>
> This is rather fundamental:  Why do we write free software? My personal
> motivation is to make the world a better place.

But the world is large.  If one can bundle resources by just making one
place that is accessible to everyone better, one can achieve quite more.
And this place are free operating systems.  When there were not any, the
GNU project still worked on making the world better in a lot of hostile
places.  But there is no point to distribute efforts still to places
where nobody really needs to be.

> When I ask myself, is the world better for having Emacs and Firefox
> running on Microsoft Windows, the answer is an unequivocal yes -
> people who hack on MS-Windows can thus do a better job.

But their job does not in general benefit others.  So we are creating
better opportunities for work that does not help the community.

> The availability of free software on proprietary OSs might well cause
> the newly enlightened to explore free software further and possibly to
> start hacking it.  A lack of free software on these OSs most surely
> will not.

But diluting our resources to proprietary dead ends that will not
benefit users of free systems is not a good idea.  If somebody who
otherwise would not do anything else does it, the free software world
does not get reduced.  But that's not the case in general.

-- 
David Kastrup

Re: Emacs vista build failures

[Richard M Stallman]

      If one can bundle resources by just making one
    place that is accessible to everyone better, one can achieve quite more.
    And this place are free operating systems.  When there were not any, the
    GNU project still worked on making the world better in a lot of hostile
    places.  But there is no point to distribute efforts still to places
    where nobody really needs to be.

Very well said.

    > When I ask myself, is the world better for having Emacs and Firefox
    > running on Microsoft Windows, the answer is an unequivocal yes -
    > people who hack on MS-Windows can thus do a better job.

    But their job does not in general benefit others.  So we are creating
    better opportunities for work that does not help the community.

I agree.

Re: Emacs vista build failures

[Eli Zaretskii]

> From: Richard M Stallman <rms@gnu.org>
> Date: Thu, 24 Jul 2008 18:05:28 -0400
> Cc: lord@emf.net, drobinow@gmail.com, lennart.borgman@gmail.com,
> 	hannes@saeurebad.de, emacs-devel@gnu.org, acm@muc.de, miles@gnu.org
> 
>     > When I ask myself, is the world better for having Emacs and Firefox
>     > running on Microsoft Windows, the answer is an unequivocal yes -
>     > people who hack on MS-Windows can thus do a better job.
> 
>     But their job does not in general benefit others.  So we are creating
>     better opportunities for work that does not help the community.
> 
> I agree.

Are you saying that my hacking on the Windows Emacs doesn't benefit
others, including Emacs on other platforms?

Re: Emacs vista build failures

[David Kastrup]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Richard M Stallman <rms@gnu.org>
>> Date: Thu, 24 Jul 2008 18:05:28 -0400
>> Cc: lord@emf.net, drobinow@gmail.com, lennart.borgman@gmail.com,
>> 	hannes@saeurebad.de, emacs-devel@gnu.org, acm@muc.de, miles@gnu.org
>> 
>>     > When I ask myself, is the world better for having Emacs and Firefox
>>     > running on Microsoft Windows, the answer is an unequivocal yes -
>>     > people who hack on MS-Windows can thus do a better job.
>> 
>>     But their job does not in general benefit others.  So we are creating
>>     better opportunities for work that does not help the community.
>> 
>> I agree.
>
> Are you saying that my hacking on the Windows Emacs doesn't benefit
> others, including Emacs on other platforms?

You don't have time left for getting Emacs-Bidi to run on any platform,
right?  Now it is, of course, your choice what to spend your developer
time on, like it is everybody other's choice, too.  In the mean time,
the only workable solutions to enter right-to-left texts remain
proprietary ones, like Unipad under Windows.  And there are a lot of
other tasks that remain to be done in order to arrive at freely
available solutions for everyone and every task, whereas "every
operating system including proprietary ones" is not really crucial.
Keeping the focus on free platforms helps to cut down on distractions.
Of course it is everybody's own choice to set his own priorities.  And
doing something at all is preferable to just mouthing off like I mostly
do.

But it is a good idea to reevaluate one's priorities from time to time
and ask oneself about the net benefits.  And "can people do freely now
what they could not before?" is a more important question for the GNU
project than "can people do on a proprietary platform now what they
could only do on a free one before?".

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Emacs vista build failures

[Lennart Borgman (gmail)]

David Kastrup wrote:
> Eli Zaretskii <eliz@gnu.org> writes:
> 
>>> From: Richard M Stallman <rms@gnu.org>
>>> Date: Thu, 24 Jul 2008 18:05:28 -0400
>>> Cc: lord@emf.net, drobinow@gmail.com, lennart.borgman@gmail.com,
>>> 	hannes@saeurebad.de, emacs-devel@gnu.org, acm@muc.de, miles@gnu.org
>>>
>>>     > When I ask myself, is the world better for having Emacs and Firefox
>>>     > running on Microsoft Windows, the answer is an unequivocal yes -
>>>     > people who hack on MS-Windows can thus do a better job.
>>>
>>>     But their job does not in general benefit others.  So we are creating
>>>     better opportunities for work that does not help the community.
>>>
>>> I agree.
>> Are you saying that my hacking on the Windows Emacs doesn't benefit
>> others, including Emacs on other platforms?
> 
> You don't have time left for getting Emacs-Bidi to run on any platform,
> right?  Now it is, of course, your choice what to spend your developer
> time on, like it is everybody other's choice, too.

Maybe the easiest way to give Eli more time for that is give good 
support for needed tools on w32?

At least a lot of my time has been spent working around different 
deficiencys in GNU tools and other things needed on w32.

I do not know the reasons for these deficiences, but the deficiences are 
there. And they take a lot of time to get around sometimes. (We have 
currently been discussing the build/distribution problem for example.)

I can guess two main reasons for the deficiencies:

1) Lack of knowledge. It is not very common that someone knows both the 
GNU/Linux API and the w32 API in depth. A problem of this kind was the 
network problem with Emacs client on w32 (which took Juanma quite a 
while to solve).

Like most other people I would assume that this kind of problems should 
be worked around with libraries when possible. Something ios maybe wrong 
when this does not work?

2) The other reason I guess is important is attitude. If a lot of people 
with good reputation says that working on w32 is not that important then 
those with a more admiring mind might agree without really diving into 
the subject. That shows up in code quality later.

Re: Emacs vista build failures

[David Kastrup]

"Lennart Borgman (gmail)" <lennart.borgman@gmail.com> writes:

> David Kastrup wrote:
>> Eli Zaretskii <eliz@gnu.org> writes:
>>
>>>> From: Richard M Stallman <rms@gnu.org>
>>>> Date: Thu, 24 Jul 2008 18:05:28 -0400
>>>> Cc: lord@emf.net, drobinow@gmail.com, lennart.borgman@gmail.com,
>>>> 	hannes@saeurebad.de, emacs-devel@gnu.org, acm@muc.de, miles@gnu.org
>>>>
>>>>     > When I ask myself, is the world better for having Emacs and Firefox
>>>>     > running on Microsoft Windows, the answer is an unequivocal yes -
>>>>     > people who hack on MS-Windows can thus do a better job.
>>>>
>>>>     But their job does not in general benefit others.  So we are creating
>>>>     better opportunities for work that does not help the community.
>>>>
>>>> I agree.
>>> Are you saying that my hacking on the Windows Emacs doesn't benefit
>>> others, including Emacs on other platforms?
>>
>> You don't have time left for getting Emacs-Bidi to run on any platform,
>> right?  Now it is, of course, your choice what to spend your developer
>> time on, like it is everybody other's choice, too.
>
> Maybe the easiest way to give Eli more time for that is give good
> support for needed tools on w32?

That sounds suspiciously like "throwing good time after bad time", to
borrow a management term.  It really sounds like a bottomless pit: you
can throw more and more time that way, and the results will be more and
more tasks.

> At least a lot of my time has been spent working around different
> deficiencys in GNU tools and other things needed on w32.

You are not exactly making a shining case for w32 support being not a
major side track for GNU project contributors.

> I do not know the reasons for these deficiences, but the deficiences
> are there.

In the company I am earning my money in, we have been cutting our losses
on Windows recently and now offer only a solution based on Ubuntu
packages.  If you need to run it on Windows, you use a virtual machine.

And that is a proprietary product with industrial customers, and
basically a batch processing product.

So the difficulties were mostly related to setup and installation and
configuration and file paths, nowhere near as complicated as for
something like Emacs.

Go figure.

> I can guess two main reasons for the deficiencies:
>
> 1) Lack of knowledge. It is not very common that someone knows both
> the GNU/Linux API and the w32 API in depth. A problem of this kind was
> the network problem with Emacs client on w32 (which took Juanma quite
> a while to solve).
>
> Like most other people I would assume that this kind of problems
> should be worked around with libraries when possible. Something ios
> maybe wrong when this does not work?
>
> 2) The other reason I guess is important is attitude. If a lot of
> people with good reputation says that working on w32 is not that
> important then those with a more admiring mind might agree without
> really diving into the subject. That shows up in code quality later.

I don't see a problem.  If people spend the time on other things than
w32 support, then it is likely better invested.

I know that I have spent an inordinary amount of time on support Emacs,
XEmacs, various Unices and Windows for AUCTeX.  In particular making the
AUCTeX installation work with MSYS has been a major pain in the ***.
And keeping XEmacs compatibility means tying oneself to abstractions,
APIs and core functionality of Emacs 20.4 or something.

Keeping this compatibility in mind means aiming for abstractions and
modularization and APIs which generate whole new subsystems and lots of
independent fragilities.  At each particular point of coding, the
compatibility costs may be tolerable.  But they add up.

If Emacs image and font and display code just took Gdk, Gtk, Pango, Xft
and other subsystems for granted and used _their_ interfaces
indiscriminately, the code would be likely more transparent,
maintainable and obvious.  Having to abstract to a level that makes it
possible to use w32 rendering, MacOSX rendering, legacy X11 rendering
and so on comes at a cost.

A high cost.  We have slow image rendering, complex loaders, weird code
paths and hard to understand data flow.  And we are getting there with
text rendering, too.

So in addition to the time sink for the proprietary system developers
themselves, our compatibility layers add cruft complicating things for
everyone.  I am not convinced that this offsets the advantages.

Again: I am mostly talk and little work, and so I am hardly in a
position to admonish anybody.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Emacs vista build failures

[Lennart Borgman (gmail)]

David Kastrup wrote:
>>>> Are you saying that my hacking on the Windows Emacs doesn't benefit
>>>> others, including Emacs on other platforms?
>>> You don't have time left for getting Emacs-Bidi to run on any platform,
>>> right?  Now it is, of course, your choice what to spend your developer
>>> time on, like it is everybody other's choice, too.
>> Maybe the easiest way to give Eli more time for that is give good
>> support for needed tools on w32?
> 
> That sounds suspiciously like "throwing good time after bad time", to
> borrow a management term.  It really sounds like a bottomless pit: you
> can throw more and more time that way, and the results will be more and
> more tasks.

I am surprised, David. Where are your arguments?

>> At least a lot of my time has been spent working around different
>> deficiencys in GNU tools and other things needed on w32.

>> I do not know the reasons for these deficiences, but the deficiences
>> are there.

>> I can guess two main reasons for the deficiencies:
>>
>> 1) Lack of knowledge. It is not very common that someone knows both
>> the GNU/Linux API and the w32 API in depth. A problem of this kind was
>> the network problem with Emacs client on w32 (which took Juanma quite
>> a while to solve).
>>
>> Like most other people I would assume that this kind of problems
>> should be worked around with libraries when possible. Something ios
>> maybe wrong when this does not work?
>>
>> 2) The other reason I guess is important is attitude. If a lot of
>> people with good reputation says that working on w32 is not that
>> important then those with a more admiring mind might agree without
>> really diving into the subject. That shows up in code quality later.
> 
> I don't see a problem.  If people spend the time on other things than
> w32 support, then it is likely better invested.

Why are you just guessing?

> Keeping this compatibility in mind means aiming for abstractions and
> modularization and APIs which generate whole new subsystems and lots of
> independent fragilities.  At each particular point of coding, the
> compatibility costs may be tolerable.  But they add up.

The Mozilla folks have done it.

> So in addition to the time sink for the proprietary system developers
> themselves, our compatibility layers add cruft complicating things for
> everyone.  I am not convinced that this offsets the advantages.

It is exactly this attitude I think is a problem. There is not only 
costs there are also benefits. As long as you do not consider the 
benefits your arguments are valid - and you will win the debate. But 
that victory has a cost.

What would it take to convince you?

> Again: I am mostly talk and little work, and so I am hardly in a
> position to admonish anybody.
> 

Re: Emacs vista build failures

[David Kastrup]

"Lennart Borgman (gmail)" <lennart.borgman@gmail.com> writes:

> David Kastrup wrote:
>>>>> Are you saying that my hacking on the Windows Emacs doesn't benefit
>>>>> others, including Emacs on other platforms?
>>>> You don't have time left for getting Emacs-Bidi to run on any platform,
>>>> right?  Now it is, of course, your choice what to spend your developer
>>>> time on, like it is everybody other's choice, too.
>>> Maybe the easiest way to give Eli more time for that is give good
>>> support for needed tools on w32?
>>
>> That sounds suspiciously like "throwing good time after bad time", to
>> borrow a management term.  It really sounds like a bottomless pit: you
>> can throw more and more time that way, and the results will be more and
>> more tasks.
>
> I am surprised, David. Where are your arguments?

Huh?  Your proposal is that "maybe the easiest way" to give developers
diverted by w32 more time is by diverting more developers to w32 on more
general tasks.  And then probably those will get more time by diverting
even more developers on even broader w32 tasks.

That's not an argument.  It is an observation.  You suggest the easiest
way to invest less time on w32 is to invest more time.

And I don't buy it.  That's all.  Whether you think this is an argument
or not is not important to me.

>>> 2) The other reason I guess is important is attitude. If a lot of
>>> people with good reputation says that working on w32 is not that
>>> important then those with a more admiring mind might agree without
>>> really diving into the subject. That shows up in code quality later.
>>
>> I don't see a problem.  If people spend the time on other things than
>> w32 support, then it is likely better invested.
>
> Why are you just guessing?

You wrote "I guess", not me.

>> Keeping this compatibility in mind means aiming for abstractions and
>> modularization and APIs which generate whole new subsystems and lots
>> of independent fragilities.  At each particular point of coding, the
>> compatibility costs may be tolerable.  But they add up.
>
> The Mozilla folks have done it.

And there has been no cost doing it?

>> So in addition to the time sink for the proprietary system developers
>> themselves, our compatibility layers add cruft complicating things
>> for everyone.  I am not convinced that this offsets the advantages.
>
> It is exactly this attitude I think is a problem. There is not only
> costs there are also benefits.

What about "offsets the advantages" did you not understand, except that
I got it backwards, namely that it should read "I am not convinced that
the advantages offset the complications"?

> As long as you do not consider the benefits your arguments are valid -
> and you will win the debate.  But that victory has a cost.

Huh?  This is not a competition.  It is also not an election or decision
forming process.  If arguments of mine are valid, there is neither a
necessity to shoot them down, nor is there one to shoot others down.

We are not in a process of choosing which direction we want to put
blinders on.

> What would it take to convince you?

There is nothing to be gained by convincing me.  In particular since:

>> Again: I am mostly talk and little work, and so I am hardly in a
>> position to admonish anybody.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Emacs vista build failures

[Lennart Borgman (gmail)]

David Kastrup wrote:
> "Lennart Borgman (gmail)" <lennart.borgman@gmail.com> writes:
> 
>> David Kastrup wrote:
>>>>>> Are you saying that my hacking on the Windows Emacs doesn't benefit
>>>>>> others, including Emacs on other platforms?
>>>>> You don't have time left for getting Emacs-Bidi to run on any platform,
>>>>> right?  Now it is, of course, your choice what to spend your developer
>>>>> time on, like it is everybody other's choice, too.
>>>> Maybe the easiest way to give Eli more time for that is give good
>>>> support for needed tools on w32?
>>> That sounds suspiciously like "throwing good time after bad time", to
>>> borrow a management term.  It really sounds like a bottomless pit: you
>>> can throw more and more time that way, and the results will be more and
>>> more tasks.
>> I am surprised, David. Where are your arguments?
> 
> Huh?  Your proposal is that "maybe the easiest way" to give developers
> diverted by w32 more time is by diverting more developers to w32 on more
> general tasks.

I am suggesting that this might save time. I have given the arguments 
for that earlier.

>>>> 2) The other reason I guess is important is attitude. If a lot of
>>>> people with good reputation says that working on w32 is not that
>>>> important then those with a more admiring mind might agree without
>>>> really diving into the subject. That shows up in code quality later.
>>> I don't see a problem.  If people spend the time on other things than
>>> w32 support, then it is likely better invested.
>> Why are you just guessing?
> 
> You wrote "I guess", not me.

Yes, but you did not. But it looks to me you are guessing. What I mean 
is that I think it is better to write "I am guessing" or "this is my 
opinion" instead of stating once own believes as true facts. (Not that I 
always remember to do that.)

>>> Keeping this compatibility in mind means aiming for abstractions and
>>> modularization and APIs which generate whole new subsystems and lots
>>> of independent fragilities.  At each particular point of coding, the
>>> compatibility costs may be tolerable.  But they add up.
>> The Mozilla folks have done it.
> 
> And there has been no cost doing it?

Of course there has been. But they would not at all be that big that 
they are now if they did not invest that effort.

>>> So in addition to the time sink for the proprietary system developers
>>> themselves, our compatibility layers add cruft complicating things
>>> for everyone.  I am not convinced that this offsets the advantages.
>> It is exactly this attitude I think is a problem. There is not only
>> costs there are also benefits.
> 
> What about "offsets the advantages" did you not understand, except that
> I got it backwards, namely that it should read "I am not convinced that
> the advantages offset the complications"?

Sorry, I do not understand.

>> As long as you do not consider the benefits your arguments are valid -
>> and you will win the debate.  But that victory has a cost.
> 
> Huh?  This is not a competition.  It is also not an election or decision
> forming process.  If arguments of mine are valid, there is neither a
> necessity to shoot them down, nor is there one to shoot others down.

Is it not more like a competition if you do not listen to and try to 
further also the argument that you do not like from the beginning?

> We are not in a process of choosing which direction we want to put
> blinders on.
> 
>> What would it take to convince you?
> 
> There is nothing to be gained by convincing me.  In particular since:

Ah, I think there is something to win by convincing you. I have read 
many good posts from you.

>>> Again: I am mostly talk and little work, and so I am hardly in a
>>> position to admonish anybody.
> 

Re: Emacs vista build failures

[Juanma Barranquero]

On Fri, Jul 25, 2008 at 17:08, Lennart Borgman (gmail)
<lennart.borgman@gmail.com> wrote:

> A problem of this kind was the
> network problem with Emacs client on w32 (which took Juanma quite a while to
> solve).

Not sure what problem are you talking about; the implementation of TCP
sockets on emacsclient was stalled for a while because of a
long-standing bug in the Windows port related to server sockets, which
was solved by Kim, not me:

2006-07-14  Kim F. Storm  <storm@cua.dk>

	* w32.c (pfn_WSACreateEvent, pfn_WSACloseEvent): New func ptrs.
	(init_winsock): Load them.  Use ws2_32.dll.
	(sys_listen): Undo last change.  Just set FILE_LISTEN flag.
	(sys_accept): Undo last change.  Instead, set child status to
	STATUS_READ_ACKNOWLEDGED and reset char_avail event so next
	sys_select will wakeup the reader thread.
	(_sys_wait_accept): New function used by reader thread to wait for
	an incoming connection on a server socket.

	* w32.h (_sys_read_ahead, _sys_wait_accept): Add prototypes.

	* w32proc.c (reader_thread): Use _sys_wait_accept to wait on a
	server socket (FILE_LISTEN flag).

2006-07-14  Kim F. Storm  <storm@cua.dk>

	* w32.c: Fix high cpu load for server sockets.
	(pfn_WSAEventSelect): New function ptr.
	(init_winsock): Load it.
	(sys_listen): Set FILE_LISTEN flag.  Set event mask for socket's
	char_avail event object to FD_ACCEPT.
	(sys_accept): Check FILE_LISTEN flag.  Set event mask on new
	socket's char_avail event object to FD_READ|FD_CLOSE.

	* w32.h (FILE_LISTEN): New filedesc flag value.


  Juanma

Re: Emacs vista build failures

[Lennart Borgman (gmail)]

Juanma Barranquero wrote:
> Not sure what problem are you talking about; the implementation of TCP
> sockets on emacsclient was stalled for a while because of a
> long-standing bug in the Windows port related to server sockets, which
> was solved by Kim, not me:


Pardon, my memory.

Re: Emacs vista build failures

[Richard M Stallman]

    > You don't have time left for getting Emacs-Bidi to run on any platform,
    > right?  Now it is, of course, your choice what to spend your developer
    > time on, like it is everybody other's choice, too.

    Maybe the easiest way to give Eli more time for that is give good 
    support for needed tools on w32?

You mean, ask other people to devote themselves to a side issue
in the hope that then Eli will stop doing so?  That would
set the wrong priorities for the whole project.

I'd rather send Eli another computer that runs GNU/Linux
so he can do his editing there.

Re: Emacs vista build failures

[Stefan Monnier]

Can we *PLEASE* stop this discussion (and all other alike)?
No matter what will be said in those endless threads, I will not remove
support for the w32 platform anytime soon, and neither will I devote
more time to that platform.

So, one last time, please stop it before I have to moderate the list.


        Stefan

Re: Emacs vista build failures

[Stefan Monnier]

Hi guys!

Could we get back to Emacs hacking?
Please?


        Stefan

Re: Emacs vista build failures

[Eli Zaretskii]

> From: David Kastrup <dak@gnu.org>
> Cc: rms@gnu.org,  emacs-devel@gnu.org
> Date: Fri, 25 Jul 2008 16:51:05 +0200
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> From: Richard M Stallman <rms@gnu.org>
> >> Date: Thu, 24 Jul 2008 18:05:28 -0400
> >> Cc: lord@emf.net, drobinow@gmail.com, lennart.borgman@gmail.com,
> >> 	hannes@saeurebad.de, emacs-devel@gnu.org, acm@muc.de, miles@gnu.org
> >> 
> >>     > When I ask myself, is the world better for having Emacs and Firefox
> >>     > running on Microsoft Windows, the answer is an unequivocal yes -
> >>     > people who hack on MS-Windows can thus do a better job.
> >> 
> >>     But their job does not in general benefit others.  So we are creating
> >>     better opportunities for work that does not help the community.
> >> 
> >> I agree.
> >
> > Are you saying that my hacking on the Windows Emacs doesn't benefit
> > others, including Emacs on other platforms?
> 
> You don't have time left for getting Emacs-Bidi to run on any platform,
> right?

Irrelevant: Emacs-Bidi cannot be done one hour at a time.

> And there are a lot of other tasks that remain to be done in order
> to arrive at freely available solutions for everyone

Like what?

> But it is a good idea to reevaluate one's priorities from time to time
> and ask oneself about the net benefits.  And "can people do freely now
> what they could not before?" is a more important question for the GNU
> project than "can people do on a proprietary platform now what they
> could only do on a free one before?".

True, but not at all related to my original question above.

Re: Emacs vista build failures

[Richard M Stallman]

    Are you saying that my hacking on the Windows Emacs doesn't benefit
    others, including Emacs on other platforms?

If you make platform-independent improvements then they are a benefit.
I don't know how much of that you do, these days.

Re: Emacs vista build failures

[Eli Zaretskii]

> From: Richard M Stallman <rms@gnu.org>
> CC: emacs-devel@gnu.org
> Date: Fri, 25 Jul 2008 21:24:15 -0400
> 
>     Are you saying that my hacking on the Windows Emacs doesn't benefit
>     others, including Emacs on other platforms?
> 
> If you make platform-independent improvements then they are a benefit.
> I don't know how much of that you do, these days.

There are ChangeLog files for that.

Re: Emacs vista build failures

[Alan Mackenzie]

Morning, everybody!

On Fri, Jul 25, 2008 at 05:20:16PM +0300, Eli Zaretskii wrote:
> > From: Richard M Stallman <rms@gnu.org>
> > Date: Thu, 24 Jul 2008 18:05:28 -0400
> > Cc: lord@emf.net, drobinow@gmail.com, lennart.borgman@gmail.com,
> > 	hannes@saeurebad.de, emacs-devel@gnu.org, acm@muc.de, miles@gnu.org

> >     > When I ask myself, is the world better for having Emacs and Firefox
> >     > running on Microsoft Windows, the answer is an unequivocal yes -
> >     > people who hack on MS-Windows can thus do a better job.

[David K:]
> >     But their job does not in general benefit others.

Hmm.  What if that software written on w32 has satisfied users?  Let's
see, users of mobile telephones, users of automotive control systems
(which reduce pollution), Emacs itself (there is at least one Emacs
developer with his Emacs hosted on w32), .......

[David K:]
> >     So we are creating better opportunities for work that does not
> >     help the community.

"The" community.  That of Free Software is merely one of many
interlocking and interdependent communities.  My view, already
expressed, is that we have a moral imperative to contribute towards the
wellbeing of the world, not just our own restricted subset of it.

[Eli Z:]
> Are you saying that my hacking on the Windows Emacs doesn't benefit
> others, including Emacs on other platforms?

I'll say it benefits an enormous number of people.  It certainly
benefitted me back in the days of 20.n.  Without it, my day job would
have been much more frustrating, and I wouldn't have ended up
contributing to Emacs.

My impression is that a substantial minority, possibly even a majority,
of Emacs users run on this particular non-free OS, and that the cost of
supporting them is low by comparison.  Carry on doing it, Eli!

Again, what is the purpose of free software?  Is it an end in itself,
it's final goal being its exclusive use by everybody, or is it to
improve the world?  If the former, I hope the goal is never scored,
because then free software would by stymied, with nowhere to go.

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: Emacs vista build failures

[David Kastrup]

Alan Mackenzie <acm@muc.de> writes:

> Morning, everybody!
>
> On Fri, Jul 25, 2008 at 05:20:16PM +0300, Eli Zaretskii wrote:
>> > From: Richard M Stallman <rms@gnu.org>
>> > Date: Thu, 24 Jul 2008 18:05:28 -0400
>> > Cc: lord@emf.net, drobinow@gmail.com, lennart.borgman@gmail.com,
>> > 	hannes@saeurebad.de, emacs-devel@gnu.org, acm@muc.de, miles@gnu.org
>
>> >     > When I ask myself, is the world better for having Emacs and Firefox
>> >     > running on Microsoft Windows, the answer is an unequivocal yes -
>> >     > people who hack on MS-Windows can thus do a better job.
>
> [David K:]
>> >     But their job does not in general benefit others.
>
> Hmm.  What if that software written on w32 has satisfied users?

What of it?  Excel, Microsoft Word, Windows Vista and other proprietary
software satisfy far more users than free software does.  And more
Chinese citizens are satisfied with their government than European
citizens.  Does that mean that we should take our standards for human
rights from China?  Do the ends justify the means?

This is not what free software is about.

> Let's see, users of mobile telephones, users of automotive control
> systems (which reduce pollution), Emacs itself (there is at least one
> Emacs developer with his Emacs hosted on w32), .......
>
> [David K:]
>> >     So we are creating better opportunities for work that does not
>> >     help the community.
>
> "The" community.  That of Free Software is merely one of many
> interlocking and interdependent communities.

It is the one the GNU project cares about.

> My view, already expressed, is that we have a moral imperative to
> contribute towards the wellbeing of the world, not just our own
> restricted subset of it.

It is not restricted.  Anybody who cares can be a part of it.  We are no
longer in the situation that you have to run free software off unfree
operating systems.  We don't have a moral imperative to help those who
refuse to be helped.  That's a waste of resources.

> My impression is that a substantial minority, possibly even a
> majority, of Emacs users run on this particular non-free OS, and that
> the cost of supporting them is low by comparison.

The cost is that they don't care about using or improving free systems.

> Carry on doing it, Eli!
>
> Again, what is the purpose of free software?  Is it an end in itself,
> it's final goal being its exclusive use by everybody, or is it to
> improve the world?  If the former, I hope the goal is never scored,
> because then free software would by stymied, with nowhere to go.

It is to improve the world, and the world is not improved by locking
people into Windows.  A developer using Emacs for developing Windows
software will lock his users into Windows.

There is enough other software that has this effect.  It is not a
particularly interesting goal to make Emacs do the same.  The idea of
free software is not to provide a comfortable place for people willing
to give up their rights.  Like with democracy, given the choice many
people will be perfectly happy to take choices compromising their
freedoms.

It is not an objective for free software to make it easier for them.  It
is a sideeffect.  Freedom rarely comes without the choice or ability to
foresake it again.  It is fragile, and only letting people keep that in
mind gives it strength.

It appears that we are not exactly doing a good job.  Emacs is
one-of-a-kind, and so there are not really any technically equivalent
alternatives, free or non-free.  Should we treat this as a strength or
as a weakness?

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Emacs vista build failures

[Lennart Borgman (gmail)]

David Kastrup wrote:
>> My impression is that a substantial minority, possibly even a
>> majority, of Emacs users run on this particular non-free OS, and that
>> the cost of supporting them is low by comparison.
> 
> The cost is that they don't care about using or improving free systems.

I think there is a good bit of psychology involved there because I 
believe you can not generally come to that conclusion without a certain 
view of how people decide what to do.

Different people make their decisions in different ways. There are 
people who in some situations when pressured take a decision in the 
direction towards which they are pressured. That is well known. 
Milgram's experiment is an extreme example of that.

What is propably less well know is that psychological experiments and 
thinking points to that people who are what they call authoritarian in 
their view of other people more often believe that pressure is the 
(only) way to get people to do things.

Perhaps it is easy to be lead to the conclusion that pressure is 
necessary. For some actions it is but are the actions and thinking we 
want really of this type?

Re: Emacs vista build failures

[David Kastrup]

"Lennart Borgman (gmail)" <lennart.borgman@gmail.com> writes:

> David Kastrup wrote:
>>> My impression is that a substantial minority, possibly even a
>>> majority, of Emacs users run on this particular non-free OS, and
>>> that the cost of supporting them is low by comparison.
>>
>> The cost is that they don't care about using or improving free
>> systems.
>
> I think there is a good bit of psychology involved there because I
> believe you can not generally come to that conclusion without a
> certain view of how people decide what to do.

I am not interested in applying psychology to feel comfortable with an
undesirable situation.  That may be fine as long as the situation can't
be changed.

> What is propably less well know is that psychological experiments and
> thinking points to that people who are what they call authoritarian in
> their view of other people more often believe that pressure is the
> (only) way to get people to do things.
>
> Perhaps it is easy to be lead to the conclusion that pressure is
> necessary. For some actions it is but are the actions and thinking we
> want really of this type?

If you consider it as _pressure_ if I voice my opinion, and want to
silence me, then you might want to think about your priorities.  Either
you consider me a babbling idiot who does not make sense, in which case
there is no necessity to change my opinion.  Or you don't, and there may
be sense to what I say.  And if there is, this sense will not go away if
you make me go away.

So we might as well stop.  The world will become neither simpler nor
more complex by us agreeing or disagreeing.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Emacs vista build failures

[Lennart Borgman (gmail)]

David Kastrup wrote:
>> I think there is a good bit of psychology involved there because I
>> believe you can not generally come to that conclusion without a
>> certain view of how people decide what to do.
> 
> I am not interested in applying psychology to feel comfortable with an
> undesirable situation.  That may be fine as long as the situation can't
> be changed.

I can't understand why you are not. Don't you think it can help to make 
things better?

>> What is propably less well know is that psychological experiments and
>> thinking points to that people who are what they call authoritarian in
>> their view of other people more often believe that pressure is the
>> (only) way to get people to do things.
>>
>> Perhaps it is easy to be lead to the conclusion that pressure is
>> necessary. For some actions it is but are the actions and thinking we
>> want really of this type?
> 
> If you consider it as _pressure_ if I voice my opinion, and want to
> silence me,

I do not think so. I wonder why you get that impression. Can you please 
tell me?

> So we might as well stop.  The world will become neither simpler nor
> more complex by us agreeing or disagreeing.

Yes, but I would be glad if you answered the question above (either here 
or private). I am interested in your answers because I think they matters.

Re: Emacs vista build failures

[David Kastrup]

"Lennart Borgman (gmail)" <lennart.borgman@gmail.com> writes:

> David Kastrup wrote:
>>> I think there is a good bit of psychology involved there because I
>>> believe you can not generally come to that conclusion without a
>>> certain view of how people decide what to do.
>>
>> I am not interested in applying psychology to feel comfortable with an
>> undesirable situation.  That may be fine as long as the situation can't
>> be changed.
>
> I can't understand why you are not. Don't you think it can help to
> make things better?

No, I don't think applying psychology to feel comfortable with an
undesirable situation will help to make things better.

There may be situations where temporarily scaling down the size of a
problem prevents capitulation and paralysis.  But there is a difference
between "I won't be able to finish this on my own, but I'll just start
anyway" and "I won't be able to finish this on my own, so I'll pretend
it is not worth doing".

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Emacs vista build failures

[Lennart Borgman (gmail)]

David Kastrup wrote:
> "Lennart Borgman (gmail)" <lennart.borgman@gmail.com> writes:
> 
>> David Kastrup wrote:
>>>> I think there is a good bit of psychology involved there because I
>>>> believe you can not generally come to that conclusion without a
>>>> certain view of how people decide what to do.
>>> I am not interested in applying psychology to feel comfortable with an
>>> undesirable situation.  That may be fine as long as the situation can't
>>> be changed.
>> I can't understand why you are not. Don't you think it can help to
>> make things better?
> 
> No, I don't think applying psychology to feel comfortable with an
> undesirable situation will help to make things better.

Sorry for beeing unclear. I did not mean "applying psychology to feel 
comfortable". I wanted to point to away of thinking about the situation. 
A way to broaden the thinking. Any conclusions from that way of looking 
upon the situation must still be your own, of course.

Thanks for the answer.

> There may be situations where temporarily scaling down the size of a
> problem prevents capitulation and paralysis.  But there is a difference
> between "I won't be able to finish this on my own, but I'll just start
> anyway" and "I won't be able to finish this on my own, so I'll pretend
> it is not worth doing".

Re: Emacs vista build failures

[Alan Mackenzie]

'Morning, David,

On Sat, Jul 26, 2008 at 10:50:01AM +0200, David Kastrup wrote:
> Alan Mackenzie <acm@muc.de> writes:

> > Morning, everybody!

> > On Fri, Jul 25, 2008 at 05:20:16PM +0300, Eli Zaretskii wrote:

> >> >     > When I ask myself, is the world better for having Emacs and Firefox
> >> >     > running on Microsoft Windows, the answer is an unequivocal yes -
> >> >     > people who hack on MS-Windows can thus do a better job.

> > [David K:]
> >> >     But their job does not in general benefit others.

> > Hmm.  What if that software written on w32 has satisfied users?

> What of it?

It refutes your contention "their job does not in general benefit
others".

> > [David K:]
> >> >     So we are creating better opportunities for work that does not
> >> >     help the community.

> > "The" community.  That of Free Software is merely one of many
> > interlocking and interdependent communities.

> It is the one the GNU project cares about.

Along, hopefully, with the one that grows its food, the one that
generates and supplies its electricity, the one the designs and builds
cheap hardware, the ones that enable easy travel, the one that sends in
the sand bags when the Elba floods, ......

> > My view, already expressed, is that we have a moral imperative to
> > contribute towards the wellbeing of the world, not just our own
> > restricted subset of it.

> It is not restricted.  Anybody who cares can be a part of it.  We are
> no longer in the situation that you have to run free software off
> unfree operating systems.  We don't have a moral imperative to help
> those who refuse to be helped.  That's a waste of resources.

I disagree wholeheartedly with the semantic shift, the sentiment and the
characterisation.

> > My impression is that a substantial minority, possibly even a
> > majority, of Emacs users run on this particular non-free OS, and that
> > the cost of supporting them is low by comparison.

> The cost is that they don't care about using or improving free systems.

Again, not true.  Many Emacs users on MS-Windows use Emacs, submit bug
reports and some even hack elisp.

> > Carry on doing it, Eli!

> > Again, what is the purpose of free software?  Is it an end in itself,
> > it's final goal being its exclusive use by everybody, or is it to
> > improve the world?  If the former, I hope the goal is never scored,
> > because then free software would by stymied, with nowhere to go.

> It is to improve the world, and the world is not improved by locking
> people into Windows.  A developer using Emacs for developing Windows
> software will lock his users into Windows.

This will often be the case.  Other times, Windows will be merely a
platform for developing portable software or embedded software.  The
ethos of free software is that its creators do not constrain what its
users may do with it, even if that aim is writing non-free software.

I believe that people are best persuaded to use free software by seeing
how good it is.  The only context an MS-Windows user is going to see free
software in is on MS-Windows.  Firefox and Emacs are prime examples.
I don't believe people will switch operating systems in order to use free
application software - they will switch after seeing how good free
software is.  I think you are of the opposite opinion, and I can accept
that.

> There is enough other software that has this effect.  It is not a
> particularly interesting goal to make Emacs do the same.  The idea of
> free software is not to provide a comfortable place for people willing
> to give up their rights.  Like with democracy, given the choice many
> people will be perfectly happy to take choices compromising their
> freedoms.

> It is not an objective for free software to make it easier for them.  It
> is a sideeffect.  Freedom rarely comes without the choice or ability to
> foresake it again.  It is fragile, and only letting people keep that in
> mind gives it strength.

Here I agree with you.  Freedom cannot happen until people grasp what it
is.  The FSF, especially Richard, have been doing a splendid job here,
but the job is not yet done.

> It appears that we are not exactly doing a good job.  Emacs is
> one-of-a-kind, and so there are not really any technically equivalent
> alternatives, free or non-free.  Should we treat this as a strength or
> as a weakness?

No, we shouldn't.  We should improve Emacs.

> David Kastrup, Kriemhildstr. 15, 44793 Bochum

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: Emacs vista build failures

[David Kastrup]

Alan Mackenzie <acm@muc.de> writes:

> On Sat, Jul 26, 2008 at 10:50:01AM +0200, David Kastrup wrote:
>> Alan Mackenzie <acm@muc.de> writes:
>
>> > Morning, everybody!
>
>> > On Fri, Jul 25, 2008 at 05:20:16PM +0300, Eli Zaretskii wrote:
>
>> >> >     > When I ask myself, is the world better for having Emacs
>> >> >     > and Firefox running on Microsoft Windows, the answer is an
>> >> >     > unequivocal yes - people who hack on MS-Windows can thus
>> >> >     > do a better job.
>
>> > [David K:]
>> >> >     But their job does not in general benefit others.
>
>> > Hmm.  What if that software written on w32 has satisfied users?
>
>> What of it?
>
> It refutes your contention "their job does not in general benefit
> others".

How so?  What about "in general" has been unclear to you?  If they write
software that runs only on non-free system, what's the benefit for free
software?

>> > [David K:]
>> >> >     So we are creating better opportunities for work that does not
>> >> >     help the community.
>
>> > "The" community.  That of Free Software is merely one of many
>> > interlocking and interdependent communities.
>
>> It is the one the GNU project cares about.
>
> Along, hopefully, with the one that grows its food, the one that
> generates and supplies its electricity, the one the designs and builds
> cheap hardware, the ones that enable easy travel, the one that sends
> in the sand bags when the Elba floods, ......

There is nothing to be gained by putting the cart before the horse and
confusing the means to an end with the end itself, to the degree of
abandoning the end in order to run after the means.

>> > My view, already expressed, is that we have a moral imperative to
>> > contribute towards the wellbeing of the world, not just our own
>> > restricted subset of it.
>
>> It is not restricted.  Anybody who cares can be a part of it.  We are
>> no longer in the situation that you have to run free software off
>> unfree operating systems.  We don't have a moral imperative to help
>> those who refuse to be helped.  That's a waste of resources.
>
> I disagree wholeheartedly with the semantic shift, the sentiment and
> the characterisation.

You are free to your disagreement, but that does not mean that I should
be kept from uttering my opinion.

>> > My impression is that a substantial minority, possibly even a
>> > majority, of Emacs users run on this particular non-free OS, and
>> > that the cost of supporting them is low by comparison.
>
>> The cost is that they don't care about using or improving free
>> systems.
>
> Again, not true.  Many Emacs users on MS-Windows use Emacs, submit bug
> reports and some even hack elisp.

Emacs is a free program, not a free system.  And I doubt that people
preferring to use Emacs on Windows do that because they want to use a
free system, but rather because they want to use Emacs.

> This will often be the case.  Other times, Windows will be merely a
> platform for developing portable software or embedded software.  The
> ethos of free software is that its creators do not constrain what its
> users may do with it, even if that aim is writing non-free software.

But the ethos is not that its creators need to applaud or help the users
writing non-free software.

So I don't see that you are doing anything for free software by
attacking my opinion.

> I believe that people are best persuaded to use free software by
> seeing how good it is.

That is the stance of the Open Source proponents.  One can't see "how
good" free software is if it does not yet exist or is technically
inferior.  The principal value of free software is not one of technical
excellence, but that nobody can take it away from you against your will
or capability.  And if you take a look at the current Windows licenses,
Microsoft explicitly reserves the right to remotely destroy your
computer and software if they think it desirable for pressing DRM or
other features.  So even if you don't count in the problem of not being
able to work against obsolescence of a platform (for a free operating
system, you can still find people working on it), Microsoft is free to
stop your copy of Emacs from working even on an existing system.

> The only context an MS-Windows user is going to see free software in
> is on MS-Windows.

That's his problem.

> Firefox and Emacs are prime examples.  I don't believe people will
> switch operating systems in order to use free application software -
> they will switch after seeing how good free software is.  I think you
> are of the opposite opinion, and I can accept that.

Please don't put words into my mouth.  I am of the opinion that we leave
people without a reason to switch to free operating systems if we let
ourselves be distracted into spending all our efforts in making software
run on non-free operating systems rather than improving them on free
operating systems.

I know that in the proprietary company I work, we abandoned supporting
our software on Windows because the cost, in contrast to expectations,
turned out to be prohibitely high.  I am not convinced that the net
payoff for Emacs on free systems is positive, and I don't see that
browbeating me to claim otherwise is going to change the situation
underlying my beliefs.

So why bother?

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Emacs vista build failures

[Alan Mackenzie]

Hi, David!

On Sat, Jul 26, 2008 at 01:11:10PM +0200, David Kastrup wrote:
> Alan Mackenzie <acm@muc.de> writes:

> > On Sat, Jul 26, 2008 at 10:50:01AM +0200, David Kastrup wrote:
> >> Alan Mackenzie <acm@muc.de> writes:

> >> > Morning, everybody!

> >> > On Fri, Jul 25, 2008 at 05:20:16PM +0300, Eli Zaretskii wrote:

> >> >> >     > When I ask myself, is the world better for having Emacs
> >> >> >     > and Firefox running on Microsoft Windows, the answer is
> >> >> >     > an unequivocal yes - people who hack on MS-Windows can
> >> >> >     > thus do a better job.

> >> > [David K:]
> >> >> >     But their job does not in general benefit others.

> >> > Hmm.  What if that software written on w32 has satisfied users?

> >> What of it?

> > It refutes your contention "their job does not in general benefit
> > others".

> How so?  What about "in general" has been unclear to you?

The fact that it's a weasel word, which can mean anything, everything, or
nothing.  ;-)

> If they write software that runs only on non-free system, what's the
> benefit for free software?

Indirect, if any.  But the benefit you were talking about was to "others"
(which means other people), not to free software.  People who hack
software on MS-Windows do provide benefit to other people; their
employers/customers and their own families, for example.

> >> It is the one [community] the GNU project cares about.

> > Along, hopefully, with the one that grows its food, the one that
> > generates and supplies its electricity, the one the designs and
> > builds cheap hardware, the ones that enable easy travel, the one that
> > sends in the sand bags when the Elba floods, ......

> There is nothing to be gained by putting the cart before the horse and
> confusing the means to an end with the end itself, to the degree of
> abandoning the end in order to run after the means.

The central point.  As I said before, I think for Richard (and possibly
for you), free software is an end in itself.  For me it's a tool towards
a better world.  I suspect that's the essential difference between us
which is fuelling this discussion.

[ .... ]

> You are free to your disagreement, but that does not mean that I should
> be kept from uttering my opinion.

Of course not!

> >> The cost is that they don't care about using or improving free
> >> systems.

> > Again, not true.  Many Emacs users on MS-Windows use Emacs, submit bug
> > reports and some even hack elisp.

> Emacs is a free program, not a free system.  And I doubt that people
> preferring to use Emacs on Windows do that because they want to use a
> free system, but rather because they want to use Emacs.

Yes, I think that's true.  A lot of them do want to use a free system
but can't, because their employers' setups won't let them.

> > This will often be the case.  Other times, Windows will be merely a
> > platform for developing portable software or embedded software.  The
> > ethos of free software is that its creators do not constrain what its
> > users may do with it, even if that aim is writing non-free software.

> But the ethos is not that its creators need to applaud or help the users
> writing non-free software.

> So I don't see that you are doing anything for free software by
> attacking my opinion.

Maybe promoting deeper understanding of the issues for both of us?

> > I believe that people are best persuaded to use free software by
> > seeing how good it is.

> That is the stance of the Open Source proponents.  One can't see "how
> good" free software is if it does not yet exist or is technically
> inferior.  The principal value of free software is not one of technical
> excellence, but that nobody can take it away from you against your will
> or capability.  And if you take a look at the current Windows licenses,
> Microsoft explicitly reserves the right to remotely destroy your
> computer and software if they think it desirable for pressing DRM or
> other features.  So even if you don't count in the problem of not being
> able to work against obsolescence of a platform (for a free operating
> system, you can still find people working on it), Microsoft is free to
> stop your copy of Emacs from working even on an existing system.

I agree with all that, and none of it contradicts what I've said.  I
would just add that the fact that software is free tends to promote its
technical excellence, Emacs and Linux being two good examples.

> > The only context an MS-Windows user is going to see free software in
> > is on MS-Windows.

> That's his problem.

:-)  But we can help him.

> > Firefox and Emacs are prime examples.  I don't believe people will
> > switch operating systems in order to use free application software -
> > they will switch after seeing how good free software is.  I think you
> > are of the opposite opinion, and I can accept that.

> Please don't put words into my mouth.  I am of the opinion that we
> leave people without a reason to switch to free operating systems if we
> let ourselves be distracted into spending all our efforts in making
> software run on non-free operating systems rather than improving them
> on free operating systems.

Maybe, but we're talking about a small amount of effort, not all of it.
I think that effort is worth it, particularly when somebody (Eli) is
willing to do it.

> I know that in the proprietary company I work, we abandoned supporting
> our software on Windows because the cost, in contrast to expectations,
> turned out to be prohibitely high.

Interesting, but not too surprising, I suppose.

> I am not convinced that the net payoff for Emacs on free systems is
> positive, ....

OK.  I think it is.

> .... and I don't see that browbeating me to claim otherwise is going to
> change the situation underlying my beliefs.

Browbeating?  We're having a polite discussion.

> So why bother?

I might learn something.  (I have done.)  You might learn something.

> David Kastrup, Kriemhildstr. 15, 44793 Bochum

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: Emacs vista build failures

[David Kastrup]

Alan Mackenzie <acm@muc.de> writes:

> Hi, David!
>
>> There is nothing to be gained by putting the cart before the horse and
>> confusing the means to an end with the end itself, to the degree of
>> abandoning the end in order to run after the means.
>
> The central point.  As I said before, I think for Richard (and
> possibly for you), free software is an end in itself.

It most certainly isn't.  But if the software or its platform is unfree,
it is _utterly_ out of your control whether or not a user might benefit
from it, and whether he has to pay through his nose to be allowed to
reap the benefits of _your_ work.

> For me it's a tool towards a better world.  I suspect that's the
> essential difference between us which is fuelling this discussion.

No, the essential difference is that you consider proprietary
corporations and business models suitable and responsible caretakers for
a better world.

If that were the case, there would have been nothing wrong with letting
the market sort out the problem of software availability.  But the
market will do whatever people let it get away with.  Read a current
Windows license: people are comfortable with signing away their privacy,
their security, and their system contents and control over it to
Microsoft and think that that's what they deserve.

The problem with the notion that it is ok to water down free software is
that free software does not fall from the trees.  You have to _create_
it before you can start with watering it down.  And that is what the GNU
project is about.  The watering down is not what needs our help.  It
will happen anyway.

>> Emacs is a free program, not a free system.  And I doubt that people
>> preferring to use Emacs on Windows do that because they want to use a
>> free system, but rather because they want to use Emacs.
>
> Yes, I think that's true.  A lot of them do want to use a free system
> but can't, because their employers' setups won't let them.

So should we go out of our way to make it _comfortable_ for them to stay
with unfree systems?  There is nothing to be gained except more work and
more demands and fewer free systems and fewer people working on them.

>> > This will often be the case.  Other times, Windows will be merely a
>> > platform for developing portable software or embedded software.
>> > The ethos of free software is that its creators do not constrain
>> > what its users may do with it, even if that aim is writing non-free
>> > software.
>
>> But the ethos is not that its creators need to applaud or help the
>> users writing non-free software.
>
>> So I don't see that you are doing anything for free software by
>> attacking my opinion.
>
> Maybe promoting deeper understanding of the issues for both of us?

You are presuming that I don't understand what I am talking about, and
there is a point to your arguments that I am not able to comprehend.  Do
you really think I (or Richard) have never been where you are?  Do you
think that the marvels of unfree platforms are so rare that only chosen
people like yourself get to see them?

> I agree with all that, and none of it contradicts what I've said.  I
> would just add that the fact that software is free tends to promote
> its technical excellence, Emacs and Linux being two good examples.

Two rather bad examples since they never were non-free to start with, so
you can't say whether the freedom promoted the excellence or not.  Both
projects have certainly much more been impacted by the personality and
the technical decisions of their original creators.  And Linux (by which
you presumably mean the kernel) would have stayed a fringe product
without GNU to run on it.

If you take a look at the development cycles and feature growth of free
software products, you'll find that more often than not they are dwarfed
by proprietary products.  And Emacs is certainly an example for slow
development.

But the freedom means that the software stays around and retains its
breathing space.  And software that keeps getting developed for 30 years
_will_ gather some usefulness over the time.  But the quality attained
through longevity is an indirect consequence of the freedom.  If you
start a free and a closed-shop project with equal developer power at the
same time, there is no reason that the free one should become better.

That does not mean that it's a bad idea to bank on the free project:
that way, every one is a winner.

>> > The only context an MS-Windows user is going to see free software
>> > in is on MS-Windows.
>
>> That's his problem.
>
> :-)  But we can help him.

Taking pity on someone who fails to shoot himself in the foot and
loading his gun for him...

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Emacs vista build failures

[Richard M Stallman]

    Hmm.  What if that software written on w32 has satisfied users?

Our mission is not "satisfying users", it is establishing freedom.

There are users who do not think their freedom is very important, and
they may feel satisfied using proprietary software.  (It isn't ALL
badly written.)  But that doesn't make the proprietary software a good
thing.

Freedom is important even if some people don't understand this, and
taking away people's freedom is bad even if they are foolish enough
not to care.  We do not judge right and wrong by their standards.

Re: Emacs vista build failures

[Barry Fishman]

Richard M Stallman <rms@gnu.org> writes:

>     Hmm.  What if that software written on w32 has satisfied users?
>
> Our mission is not "satisfying users", it is establishing freedom.
>
> There are users who do not think their freedom is very important, and
> they may feel satisfied using proprietary software.  (It isn't ALL
> badly written.)  But that doesn't make the proprietary software a good
> thing.
>
> Freedom is important even if some people don't understand this, and
> taking away people's freedom is bad even if they are foolish enough
> not to care.  We do not judge right and wrong by their standards.

I think you may be loosing sight of some things by still focusing just
on gaining freedom.  A GNU system now exists that people can use
reliably and productively.  Many of us prefer it over the proprietary
alternatives, even if they were free.  Isn't that real freedom.  For
many of us you have already won.

The FSF seems to behave as if this wasn't true.  So much effort still
seems to be put into porting prorietary garbage like .NET to GNU, and
producing a Gnome windowing environment which has all the faults of
MS-Windows.

Why not concentrate on producing something better.  Emacs is far nicer
to work with than GNOME.  So why the interest in making Emacs fit in to
this inferior MS-Windows like environment.  Why not make GNOME work more
like Emacs.  Whats the point of a C based GTK it you don't use it
through a Lisp like layer?  Why is so much of my Gnome configuration
buried in zillions of directories filled with ugly XML files.  Why can't
I query it with simple REPL?

I don't have problems with porting Emacs to Vista.  My problem is with
this strong desire to port Vista to GNU.

-- 
Barry Fishman

Re: Emacs vista build failures

[Richard M Stallman]

    I think you may be loosing sight of some things by still focusing just
    on gaining freedom.  A GNU system now exists that people can use
    reliably and productively.  Many of us prefer it over the proprietary
    alternatives, even if they were free.  Isn't that real freedom.  For
    many of us you have already won.

Not very many.  Less than 10% of computer users use GNU/Linux,
and nearly all of them run non-free software on or in it.
The people who have fully rejected nonfree software are few.

    The FSF seems to behave as if this wasn't true.  So much effort still
    seems to be put into porting prorietary garbage like .NET to GNU, and
    producing a Gnome windowing environment which has all the faults of
    MS-Windows.

That's what we need in order to enable large numbers of users to escape
from freedom-denying proprietary software.

      Why not make GNOME work more
    like Emacs.  Whats the point of a C based GTK it you don't use it
    through a Lisp like layer?  Why is so much of my Gnome configuration
    buried in zillions of directories filled with ugly XML files.  Why can't
    I query it with simple REPL?

I agree with you there.  The sad thing is that GNOME was initially
based on Scheme, and it was possible to do these things.  They do not
listen to me much, so I save my efforts with them for the issues
that are essential to our campaign for freedom.

Re: Emacs vista build failures

[Barry Fishman]

Richard M Stallman <rms@gnu.org> writes:
> Barry Fishman writes:
>> I think you may be loosing sight of some things by still focusing just
>> on gaining freedom.  A GNU system now exists that people can use
>> reliably and productively.  Many of us prefer it over the proprietary
>> alternatives, even if they were free.  Isn't that real freedom.  For
>> many of us you have already won.
>
> Not very many.  Less than 10% of computer users use GNU/Linux,
> and nearly all of them run non-free software on or in it.
> The people who have fully rejected nonfree software are few.

I think there are two issues here.  First it is very difficult to get
people, even those who are politically concerned, to understand the
importance of the issues involved with free software.  This does require
constant educational effort.  I'm not arguing against that.

But one needs a platform that is worth using.  Not just a cheap Vista
clone.

The Japanese started out by making cheap copies of American autos.  It
took them only so far.  They really gained sales by using the quality
control methods that US corporations rejected, and started making better
products.  Now American auto companies try to copy the Japanese.

>> Why not make GNOME work more like Emacs.  Whats the point of a C
>> based GTK it you don't use it through a Lisp like layer?  Why is so
>> much of my Gnome configuration buried in zillions of directories
>> filled with ugly XML files.  Why can't I query it with simple REPL?
>
> I agree with you there.  The sad thing is that GNOME was initially
> based on Scheme, and it was possible to do these things.  They do not
> listen to me much, so I save my efforts with them for the issues
> that are essential to our campaign for freedom.

This whole thread has been about changing the direction of Emacs,
dropping the support for non-free platforms, and integrating it better
within GNU.

My initial concern was that this seemed to mean that Emacs might
loose its identity which made the time my job required me to spend on
proprietary environments much less horrible.  However, its been quite a
few years since this has occurred.

But if Emacs is going to be integrated within GNU, I just hope it
involves more time shaping the direction of GTK, making improvements in
ELisp/Guile, and making a better framework on which things like Gnome
can be built.

For example, one should ultimately be able to do things like have
GnuCash use Emacs/TTY code to display in text windows.

-- 
Barry Fishman

Re: Emacs vista build failures

[Richard M Stallman]

    For example, one should ultimately be able to do things like have
    GnuCash use Emacs/TTY code to display in text windows.

It is a useful goal.  Do you want to work on trying to design a way to
do this?  Preferably it should not involve linking parts of Emacs with
GNUcash.  Too unmodular.  Better to have them communicate somehow.

Re: Emacs vista build failures

[Barry Fishman]

Richard M Stallman <rms@gnu.org> writes:
>     For example, one should ultimately be able to do things like have
>     GnuCash use Emacs/TTY code to display in text windows.
>
> It is a useful goal.  Do you want to work on trying to design a way to
> do this?  Preferably it should not involve linking parts of Emacs with
> GNUcash.  Too unmodular.  Better to have them communicate somehow.

It is a matter of where you draw the module boundaries.  Right now
GNUcash uses Guile, GTK, and some application specific lisp and lower
level C code.  Emacs uses (I guess) its own ELisp, buffers, GTK (among
other possibilities) under Emacs's rendering code and application
specific Lisp and lower level C code.

From what I understand, Emacs will be moving to Guile (or at least a
Guile updated to meet its needs).  If GTK is integrated and updated in a
way that supports frames and buffers, and allow for a similar objects
for TTY frames and buffers, a merge of GNUcash and Emacs becomes more
like a bit of a lisp based connective code, to let GNUcash use TTY
frames/windows instead of GTK ones.

Does integration of Emacs into the GNU Desktop mean that Emacs just
starts picking up Gnome and dbus facilities, and dropping portability
concerns, or does it becomes a source of components and ideas that can
be used in other applications.  Otherwise I am afraid that the "make GNU
look like Windows" people will bury us in the sort of fragile C++
monoliths like Firefox, that leave most everyone out.

I think freedom is not just having source, and the permission to make
changes and distribute them.  Its also about it being straightforward to
actually modify applications in ways that are useful.  Emacs is excellent
at this.  I must have thousands of lines of elisp code, of probably no
interest to anyone else, that I have written to tune simple Emacs
features.  One can easily make changes where the authors did not allow
for them (without maintaining patches to the original sources):

;; FQDN patch - Force smtpmail to use mail-host-address
(autoload 'smtpmail-fqdn "smtpmail" nil nil)
(defadvice smtpmail-fqdn (around change-smtpmail-fqdn activate)
  "Supply a domain which is meaningful but wrong"
  (setq ad-return-value mail-host-address))
(setq message-user-fqdn mail-host-address)

-- 
Barry Fishman

Re: Emacs vista build failures

[tomas]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Mon, Jul 28, 2008 at 09:00:19PM -0400, Barry Fishman wrote:
> Richard M Stallman <rms@gnu.org> writes:
> >     For example, one should ultimately be able to do things like have
> >     GnuCash use Emacs/TTY code to display in text windows.
> >
> > It is a useful goal.  Do you want to work on trying to design a way to
> > do this?  Preferably it should not involve linking parts of Emacs with
> > GNUcash.  Too unmodular.  Better to have them communicate somehow.
> 
> It is a matter of where you draw the module boundaries [...]

> Does integration of Emacs into the GNU Desktop mean that Emacs just
> starts picking up Gnome and dbus facilities, and dropping portability
> concerns, or does it becomes a source of components and ideas that can
> be used in other applications.  Otherwise I am afraid that the "make GNU
> look like Windows" people will bury us in the sort of fragile C++
> monoliths like Firefox, that leave most everyone out.

Note that the basic architecture of Firefox is very much parallel to
that of Emacs: a C[++] core and a scripting layer on top to write most
of the user functionality in (Javascript + XML). Not that I am a big fan
of Javascript (even less of XML), I'd take Lisp over it any day, and the
sheer bloatyness of Firefox gives me the feeping creeps, but just to
point that out.

> I think freedom is not just having source, and the permission to make
> changes and distribute them.  Its also about it being straightforward to
> actually modify applications [...]

Amen. Also called the "low hacktivation energy".

Regards
- -- tomás
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFIjrbxBcgs9XrR2kYRAkwDAJ9rr2op2wtYDg8DjyCWUs57Fbe4yACdGgSl
L9tR2yZ9smuDSON7LhjOXq0=
=wjKk
-----END PGP SIGNATURE-----

Re: Emacs vista build failures

[Barry Fishman]

tomas@tuxteam.de writes:
> On Mon, Jul 28, 2008 at 09:00:19PM -0400, Barry Fishman wrote:
>>                           Otherwise I am afraid that the "make GNU
>> look like Windows" people will bury us in the sort of fragile C++
>> monoliths like Firefox, that leave most everyone out.
>
> Note that the basic architecture of Firefox is very much parallel to
> that of Emacs: a C[++] core and a scripting layer on top to write most
> of the user functionality in (Javascript + XML). Not that I am a big fan
> of Javascript (even less of XML), I'd take Lisp over it any day, and the
> sheer bloatyness of Firefox gives me the feeping creeps, but just to
> point that out.

I may be just repeating wrong information, but doesn't Windows (at least
historically) use Basic and assorted data files as its extension
facility.  I assume Vista is moving toward .NET.

As far as Firefox is concerned, I see things like:
   http://developer.mozilla.org/en/docs/Building_an_Extension
It seems to be more a patchwork of extendable areas, rather that
what is going on in Emacs.

I think of Emacs as a lisp program which uses C components to improve
performance and connect to OS facilities.

I think Python has done the best job of doing Emacs style things.  It is
even developing Pyrex, a typed python subset to C translator, to avoid
some of the fragile C macro hacks used in Emacs, Guile, and other C
based Lisps.  It is even REPL based.  But it doesn't have the extendability
and flexibility of Lisp.  Unlike programing in Lisp, Python has the feel
that you are talking down to a small child rather than a peer (child or
adult).

>> From what I understand, Emacs will be moving to Guile (or at least a
>> Guile updated to meet its needs).

Miles Bader <miles@gnu.org> writes:
> This was sort of a vague goal a decade or more ago, but seems pretty
> unlikely to actually happen.

Scheme is going though a painful growth spurt (via R6RS), and its
probably not stable enough to consider at the moment.  Common Lisp has
been excluded by RMS, although some people are going ahead via CL-EMACS.
I assume he feels that its complexity would reduce the hacking community
working on it.

I think there is a continuum from "limited but simple" to "powerful but
complex".  Commercial applications can flourish working at the
extremes, limited but simple for the user, powerful but complex for the
internal developers.  I think free projects really need to provide access
to the middle of the spectrum where hacking can be a incremental
process.

The ideal would probably be to support the large numbers of people
satisfied with the simple but limited area, but with support for more
productive levels of "powerful but more complex" to keep a large
development community happy.  To me this requires the ability to
dynamically build clean application specific sub-languages in the way
only Lisp can do.

My point is maybe some effort needs to be put on how Emacs ideas and
shareable code can be used in a more general framework for building GNU
applications.  Guile, GDK/GTK seem to be steps in the right direction,
but only if they could at least theoretically be used to build an Emacs
that runs at least as fast as it runs now.  But the Gnome juggernaut
seems to be pulling in a different direction.  One where Microsoft is
leading the way.  I just don't want it to overpower Emacs!  I don't want
my frame layouts to be saved in dozens of
"~/.gconf/apps/emacs/**/%gconfg.xml" files!

My own ~/.emacs file based setup has a growing "forward into the past"
section where I roll back new default features that I find better living
without.  Please don't make it the bulk of my code.

-- 
Barry Fishman

Re: Emacs vista build failures

[Richard M Stallman]

The reasons I reject CL support in Emacs include incompatibility and
the fact that CL is so complex that documenting it in the Emacs Lisp
Ref Manual would be prohibitive.

Re: Emacs vista build failures

[Richard M Stallman]

    > I think freedom is not just having source, and the permission to make
    > changes and distribute them.  Its also about it being straightforward to
    > actually modify applications [...]

    Amen. Also called the "low hacktivation energy".

We must never lump together injustice with mere imperfection.  This is
a fundamental confusion.  The former we can condemn, and perhaps stamp
out.  The latter we can only work to reduce.

Re: Emacs vista build failures

[Richard M Stallman]

    >From what I understand, Emacs will be moving to Guile (or at least a
    Guile updated to meet its needs).

That is a long-term possibility, but nowhere near reality.
We would have to make Guile coexist well with Emacs Lisp,
and until we try it we won't know if it really can work.

    Does integration of Emacs into the GNU Desktop mean that Emacs just
    starts picking up Gnome and dbus facilities,

Why not?  (It already does dbus.)

						 and dropping portability
    concerns,

Certainly not!

Re: Emacs vista build failures

[Richard M Stallman]

    When I ask myself, is the world better for having Emacs and Firefox
    running on Microsoft Windows, the answer is an unequivocal yes - people
    who hack on MS-Windows can thus do a better job.

Our goal is to replace and eliminate proprietary operating systems,
not help people use them.

Re: Emacs vista build failures

[Richard M Stallman]

    So the more realistic case is that people chose scons or something
    instead of dropping autotools and writing their own configure script.

If we are ever to be able to build whole systems from source
in a simple way, our community will have to overcome that erroneous
practice.

Re: Emacs vista build failures

[Thomas Lord]

Just a quick note:

Johannes Weiner wrote:
> autoconf, automake, and so on.  Actually, I heard people referring to
> the whole generation of configure scripts and Makefiles as `autohell'.
>
> Yes, it's ovbiously a criticism.
>   

There are some very well known problems with that suite of tools,
for some users.    A few that come to mind:

1) Sometimes, after downloading this or that source package,
    perhaps making some changes, it is necessary simply to
    regenerate the configure script.   Yet, from time to time,
    the script can not be regenerated using the auto* suite already
    installed, the user must install alternate versions as well.
    A very frustrating experience occurs when building a program
    that requires, say, 3 separate libraries from various sources
    to be built first, each library using autoconf, ultimately requiring
    a total of four separate versions of autoconf to get the job done.
    This doesn't happen (in my experience) often, but often enough
    that it has left me with a bad feeling about the autoconf suite.

2) The autoconf suite has grown over the years and is now quite
    complicated both internally, and in use.   On the one hand, this
    reflects a needed accumulation of capabilities to be able to handle
    a very wide range of requirements from all the programs that use
    this suite.   On the other hand, it is "nervous making" to have 
something
    so fundamental to a project as its build process rely on such 
complicated
    tools that only a handful of people really understand well.

3) As Johannes mentioned, a special problem occurs if, in spite of its large
    number of features, a programmer needs to write a new macro or otherwise
    customize autoconf to do something new.   It can be very hard to 
pull together
    enough documentation and examples to be able to do this at all.   It 
is very
    hard to be confident, even when one gets something "working", that 
it works
    properly.

I think that those are *part* of the reason that in recent years more 
and more
people have written new configure/build systems, either general purpose or
targeted to a specific scripting language or other "closed universe" system.

Another reason (as far as I can tell) that scripting languages (and 
Java) often
use language-specific configure/build systems is because they want 
additional
functionality that deals with concepts not found in the autoconf suite.  
Most
commonly, configure/build/install is integrated with a *package system* by
which I mean a system for bundling and naming source in standard ways,
managing version numbering in standard ways, and creating "one step"
tools that find a desired package on the net, download it, recursively find
and download all prerequisite packages needed, then configure, build, and
install all of those.   The autoconf suite doesn't try to help with 
that.   It
is easier to build systems which do that for a single-language "closed 
universe",
and so several such systems exist.

Of course, finally, scripting languages often use their own
package / configure / build / install systems because writing such
a thing is a way to show-off the scripting language.   E.g.,
since you've already installed Ruby core, now here is a nice
package system written in Ruby (nevermind this /bin/sh, m4 stuff)
that is easy to use.

When I (as I said, probably in a few weeks after we move) put forward
straw-man recommendations, I do intend to implicitly address the problems
described above.   That is:  Yes, package management and prerequisite 
management
should be built-in to the GNU conventions;  other concepts such as 
validation
(checksum and signature checking) and auditing of trees on disk are also 
important;
conventions for handling multiple installed versions of packages cleanly 
are needed;
and, yes, the tools supporting these things do need to be simpler (yet 
without
sacrificing a short "bootstrapping path" to get them working -- the 
build tools
have to have relatively few dependencies on other packages).


-t

Re: Emacs vista build failures

[Richard M Stallman]

    > Actually no.  It seems to be a criticism of something.
    > Perhaps Autoconf, or perhaps not -- I have no way to tell.

    autoconf, automake, and so on.  Actually, I heard people referring to
    the whole generation of configure scripts and Makefiles as `autohell'.

    Yes, it's ovbiously a criticism.

Then it is a vague and nonconstructive one.  Please stick to
constructive comments if you want to be helpful.

    > If you are talking about Autoconf, then you've misunderstood what this
    > issue is about.  It is not about using Autoconf.  It is about
    > implementing the interface specified in the GNU Coding Standards.
    > Let's please stick to the topic.

    Which means using the auto tools, be realistic.  Who writes configure
    scripts manually?

It is easy to write a configure script that is just a wrapper for
some other configuration mechanism.

Re: Emacs vista build failures

[Miles Bader]

Richard M Stallman <rms@gnu.org> writes:
> If you are talking about Autoconf, then you've misunderstood what this
> issue is about.  It is not about using Autoconf.  It is about
> implementing the interface specified in the GNU Coding Standards.

This seems to be something of a problem in general actually -- even
though the GNU coding standards specify an interface which can be
implemented in many ways, people often seem to mentally conflate them
with using the auto* tools, and if they decide to use some other build
system/tool, they don't even consider trying to follow that interface
(even though it's often rather simple to do so in many cases).

-Miles

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

Re: Emacs vista build failures

[Lennart Borgman (gmail)]

Richard M Stallman wrote:
>     > That is good news, but the general problem remains
>     > as far as I know.  Has there been a general move towards
>     > supporting the GNU configure and build specs?
> 
>     As far as I know (I don't hack on X, I just read the mailing list), the
>     entire build infrastructure was replaced, and you can now do
>     "./configure ...; make" etc., and things work in the normal GNU
>     style.
> 
> We are miscommunicating.  As regards X itself, I took for granted that
> that is what you meant.
> 
> My question concerns looking beyond X to the free software community
> as a whole.  Has there been a broader move towords supporting the GNU
> configure and build specs?

I can't help but thinking about the problems with building Emacs itself 
on w32. Is not one of the problems there the lack of a sh/bash or 
whatever that can easily be used when building Emacs?

Something like a portable mini-bash (with more limited capabilities) 
that runs also on w32 and could be used together with w32 programs would 
perhaps make this better.

Re: Emacs vista build failures

[Richard M Stallman]

    Something like a portable mini-bash (with more limited capabilities) 
    that runs also on w32 and could be used together with w32 programs would 
    perhaps make this better.

It would be a shame for people that care about free software to spend
time implementing free software specifically to run on Windows.

Re: Emacs vista build failures

[David Kastrup]

Richard M Stallman <rms@gnu.org> writes:

>     Something like a portable mini-bash (with more limited
>     capabilities) that runs also on w32 and could be used together
>     with w32 programs would perhaps make this better.
>
> It would be a shame for people that care about free software to spend
> time implementing free software specifically to run on Windows.

It does not get better if time is spent multiply times for porting
efforts.  If the total of window porting efforts can be reduced by
dedicated efforts, that's not the worst thing.

Anyway, the proposal does not seem to encompass just Windows, but pretty
much every platform, free or not.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Emacs vista build failures

[Lennart Borgman (gmail)]

Richard M Stallman wrote:
>     Something like a portable mini-bash (with more limited capabilities) 
>     that runs also on w32 and could be used together with w32 programs would 
>     perhaps make this better.
> 
> It would be a shame for people that care about free software to spend
> time implementing free software specifically to run on Windows.

Are you sure? What are your arguments? Why can't this be a benefit for 
free software?

As David pointed out this would not be specific to w32. It would rather 
be a tool that we could rely on that we could use everywhere.


IMO relevant tools that are cross-platform can help free software. One 
reason is that we can rely on that they work. Another reason is that we 
can more easily find people who understand those tools.

The last argument is important since most programmers are forced to work 
on w32 in their daily work. If we can give them tools they can use there 
then they can more easily contribute to free software during their free 
time.

I also believe that cross platform knowledge creates new ideas that can 
be really good for free software.

It looks to me there are not that many people who both know w32 and 
GNU/Linux in depth. Cross platform tools will help those who wants to 
get such knowledge.

Re: Emacs vista build failures

[Richard M Stallman]

    As David pointed out this would not be specific to w32. It would rather 
    be a tool that we could rely on that we could use everywhere.

If it is for use on multiple platforms, maybe it is a good thing.

On the other hand, maybe it is better to migrate to using Scons,
and make simple wrappers to implement the GNU configuration spec
and make spec.

Re: Emacs vista build failures

[Stephen J. Turnbull]

Richard M Stallman writes:
 >     > I tried at one point to convince XFree86 to support the GNU
 >     > configuration spec.  I even found a volunteer to implement that as a
 >     > wrapper around their existing configuration mechanism.  But they did
 >     > not consider such compatibility very important, and I don't think they
 >     > installed this wrapper.
 > 
 >     Note that the current standard X distribution, Xorg, now uses gnu auto*
 >     tools for configuration.
 > 
 > That is good news, but the general problem remains
 > as far as I know.  Has there been a general move towards
 > supporting the GNU configure and build specs?  That would make
 > it much easier to build a whole system from source.

It depends on what you mean by "general move" and "whole system".  For
example, the 'BSDs continue to use their traditional hierarchy of Make
include files.  Presumbly you mean to exclude those systems from
"general", however.

Regarding the "system", among the programs I use that are written in C
for the GNU system, almost all use the autotools for configuration and
make to run the build.  But dissatisfaction with autotools and even
make runs throughout the "open source" community (ie, the community
that uses free software licenses for whatever reason, not limited to
principled support for freedom).[1]

While I don't know off hand of any C programs that use other build
control tools, few of the scripting languages and web frameworks do.
Python has its setup.py and dist-tools, I believe Ruby and Perl have
similar build systems, Haskell has its Cabal, and there are a number
of more general rivals to the autotools such as Scons which are
attracting attention.  These days more and more important software is
written in languages like Python (eg, bzr, Emacs's recently anointed
distributed version control system) and Perl (eg, debbugs, Emacs's
recently anointed bug tracking system).  I don't know about bzr
offhand, but debbugs includes separate Perl scripts "build", "clean",
and "debian/debbugsconfig", as well as the Makefile which seems to be
used only to install the package.  Not to mention that every package
management system has its own standards, usually supported by
utilities like Debian's debhelper.

If in "system" you intend to include such applications, then I would
have to guess that programs that don't conform to GNU standards for
configuration and build are proliferating rapidly.  I also know of
several free software programs for Mac OS X which presumably could be
ported to GNUStep, but AFAIK are dependent on Apple's proprietary
Xcode tool (a build manager like Scons, or maybe even an IDE
comparable to Eclipse without the extensibility).  Thus they might
require substantial extra effort in porting.

BTW, I haven't used Scons, but every time XEmacs has a build issue
somebody brings it up.  The Scons blurb says:

    What is SCons?
    SCons is an Open Source software construction tool---that is, a
    next-generation build tool. Think of SCons as an improved,
    cross-platform substitute for the classic Make utility with integrated
    functionality similar to autoconf/automake and compiler caches such as
    ccache. In short, SCons is an easier, more reliable and faster way to
    build software.

There seem to be a fair number who have drunk of the Scons Kool-Aid
and say it lives up to its advertising.

Footnotes: 
[1]  In case it's not clear, I mention the open source community not
to identify it with the free software community, but because not all
useful free software originates within the free software community,
and where such software is useful but nonconformant to GNU standards,
you may need to spend effort adapting it.

Re: Emacs vista build failures

[Richard M Stallman]

    While I don't know off hand of any C programs that use other build
    control tools, few of the scripting languages and web frameworks do.

That has two directly opposite meanings.
Few of the scripting languages use other build control tools?
Few of the scripting languages use the GNU build control tools?

However, the issue I'm concerned with is about interfaces, not
implementation.

    Python has its setup.py and dist-tools, I believe Ruby and Perl have
    similar build systems, Haskell has its Cabal, and there are a number
    of more general rivals to the autotools such as Scons which are
    attracting attention.

Would it be possible to put wrappers around these other methods
so as to implement the GNU configure and build specs around those
other methods?

    If in "system" you intend to include such applications, then I would
    have to guess that programs that don't conform to GNU standards for
    configuration and build are proliferating rapidly.

Is this because people are using those other languages
in which people tend not to support our specs,
or are C programs also increasingly ignoring our specs?

      I also know of
    several free software programs for Mac OS X which presumably could be
    ported to GNUStep, but AFAIK are dependent on Apple's proprietary
    Xcode tool

That is very bad.  What are the names of these programs?

Re: Emacs vista build failures

[Richard M Stallman]

    [1]  In case it's not clear, I mention the open source community not
    to identify it with the free software community, but because not all
    useful free software originates within the free software community,

There is no such thing as the "the open source community".  Our
community includes activists for free software and supporters of open
source, but it was built by the free software movement, so it is the
free software community.

Re: Emacs vista build failures

[Stephen J. Turnbull]

Richard M Stallman writes:

 > There is no such thing as the "the open source community".

Of course, there is.  I feel sorry for you that you feel a need to
deny it.

Re: Emacs vista build failures

[Richard M Stallman]

     > There is no such thing as the "the open source community".

    Of course, there is.  I feel sorry for you that you feel a need to
    deny it.

I am sorry that you seek to rename the free software commnuity
so as to deny that the free software movement built it.

Re: Emacs vista build failures

[David Kastrup]

Richard M Stallman <rms@gnu.org> writes:

>      > There is no such thing as the "the open source community".
>
>     Of course, there is.  I feel sorry for you that you feel a need to
>     deny it.
>
> I am sorry that you seek to rename the free software commnuity
> so as to deny that the free software movement built it.

A group that rejects the ideological base of works they continue to
build upon can't reasonably be a priori identified as part of the
original community.  Even though it is a rather popular outside stance
towards today's inhabitants of Germany.

-- 
David Kastrup

Re: Emacs vista build failures

[Richard M Stallman]

    A group that rejects the ideological base of works they continue to
    build upon can't reasonably be a priori identified as part of the
    original community.

Not at all.  It's normal for a community to contain people
with different views; just because people adopt a different set
of politics does not make them a separate community.

Re: Emacs vista build failures

[David Kastrup]

Richard M Stallman <rms@gnu.org> writes:

>     A group that rejects the ideological base of works they continue to
>     build upon can't reasonably be a priori identified as part of the
>     original community.
>
> Not at all.  It's normal for a community to contain people
> with different views; just because people adopt a different set
> of politics does not make them a separate community.

Then it would appear that we are part of the preexisting UNIX community,
and the "free software community" is a myth.

-- 
David Kastrup

Re: Emacs vista build failures

[Richard M Stallman]

    > Not at all.  It's normal for a community to contain people
    > with different views; just because people adopt a different set
    > of politics does not make them a separate community.

    Then it would appear that we are part of the preexisting UNIX community,
    and the "free software community" is a myth.

That's a nonsequitur if I ever saw one.

Free software and open source stand for political views, but in our
commuity people with various views often work together developing the
same program.  That's why we are all part of one community.

GNU and Unix are different systems developed by different groups that
cannot work together.  It's no accident that GNU's Not Unix; that was
a necessary requirement to achieve the goal.  We made a clean break.

Re: Emacs vista build failures

[Stephen J. Turnbull]

Richard M Stallman writes:
 >      > There is no such thing as the "the open source community".
 > 
 >     Of course, there is.  I feel sorry for you that you feel a need to
 >     deny it.
 > 
 > I am sorry that you seek to rename the free software commnuity
 > so as to deny that the free software movement built it.

OK, Richard, I concede; you rule here.  So I'll take my leave.  I
gather you have no need of my opinions about why large portions of the
soi-disant free software community could care less about "GNU
standards", and what you might want to do about that.  I'm certain I'm
no longer interested in having that conversation with you.

Re: Emacs vista build failures

[Thomas Lord]

Stephen J. Turnbull wrote:
> Richard M Stallman writes:
>  >      > There is no such thing as the "the open source community".
>  > 
>  >     Of course, there is.  I feel sorry for you that you feel a need to
>  >     deny it.
>  > 
>  > I am sorry that you seek to rename the free software commnuity
>  > so as to deny that the free software movement built it.
>
> OK, Richard, I concede; you rule here.  So I'll take my leave.  I
> gather you have no need of my opinions about why large portions of the
> soi-disant free software community could care less about "GNU
> standards", and what you might want to do about that.  I'm certain I'm
> no longer interested in having that conversation with you.
>   

I hope, Stephen, that you will please stick around for (off-list) 
discussion of
build / configure / install / audit / package / validate tools.   Your
earlier comments on the topic were very helpful.   You seem to have
a broad perspective on the matter.


On the disagreement about naming the "community":

I think the original error is to try to use the word "community" in
any but the vaguest sense of the word and, when used that way,
there is hardly any point to either qualifier ("free software" or
"open source").

The problem is that "community", used other than vaguely, is a
highly contentious and loaded word.   To some, it implies little more
than a set of people with some common interest (e.g., the radio-controlled
airplane community).   To others, it implies a group bound together by a
set of social norms and expectations which create systems of mutual support
and social cohesion (e.g., the immigrant community in Little OldWorldistan
District of the city).

In many contexts, a more precise noun clause is available.   Sometimes
one means "the free software movement," other times, "programmers
who develop free software."   Sometimes one means "people enthusiastic
about OSI-approved licenses".   Sometimes one means "people enthusiastic
about the commercial impact of the Open Source Definition".

Those more precise phrases are also (relatively more) objective, so
there is less to argue over.   A person decides to join the free software
movement or doesn't.   A person develops free software or doesn't.
A person is or is not enthusiastic about the OSI license list.   One
person can be any two out of three of those or all three. 

There is no "ownership" of the crowd to be contended - no branded
"community" - and no (wishful thinking) positing of a shared set of
norms and expectations.

The issue of "credit where credit is due" is unaffected by those
vocabulary recommendations, except that with those other words,
the credit debate is easier to speak of more precisely.

For example, what do we make of a hypothetical programmer (though
I'm certain many real examples of this exist) who writes a new
C program, announces it to his GNU hacker friends, but also who
chooses a BSD license and explains that, ethically, he feels it is right
to permit proprietary derivatives of the new program.   It goes without
saying what GNU hackers might say *to* that hacker but that isn't
the question -- the question is how we *describe* this hacker in terms
of "credit" for the conditions that gave rise to that choice.

The free software movement probably gets credit for creating a general
level of interest in libre licensing.   The free software movement gets
credit for having produced most of the development tools that programmer
will use.   The Regents of the University of California and their agents get
credit for the introduction of the BSD license.   The Open Source Iniative
and its allies get credit for spreading that idea (right or wrong, it's 
not the
question here) that going out of ones way to permit proprietary derivatives
of a program might be ethically good, or at least neutral.

In contrast, if we're forced to debate whether or not that programmer is
part of the "free software community" or the "open source community" or
both or neither I guess I'd want to start asking questions like "Who will
he help in a barn raising?    Whose celebrations will he participate in?
Whose defeats will he make sacrifices to mitigate?" -- that kind of thing.
The most accurate answer might turn out to be "He is not part of either
community.   As a programmer, he is mainly part of the hobbyist
community at Springfield High School, a group which is quite agnostic
about software freedom."

-t




>
>   

Re: Emacs vista build failures

[Thomas Lord]

Richard M Stallman wrote:
>     It is a failure of the GNU project and of the free software movement
>     that there is so much emphasis on monolithic distributions and binary
>     package distributions.   It is a failure of the GNU project and the free
>     software movement that one so often encounters distros that offer to
>     not install source trees and even offer to not install development
>     environments.
>
> The words "it is a failure of" are ambiguous.  They could literally
> mean "it is a goal we have not achieved", but they also suggest
> placing the blame for this on us.
>   

You're a better speaker than me, I think. 

It's not blame.  It's an attempt to egg on in a direction for which I 
wish to
advocate.




> Certainly these are goals we have not achieved, but if others do not
> follow our recommendations, that's their decision, not ours.  When I
> designed the GNU specs for configuring and building source packages, I
> hoped that free software developers generally would adopt them, but
> they did not.
>   

A heck of a lot of them did.  That isn't the problem.   In my view the 
problem
is that the specs were short-sighted in some key ways -- too much pain 
and not
enough benefit.   I'd be happy to take discussion of this view off-list 
though I'm
reluctant to go into it here, given Stefan's recent feedback.



> I tried at one point to convince XFree86 to support the GNU
> configuration spec.  I even found a volunteer to implement that as a
> wrapper around their existing configuration mechanism.  But they did
> not consider such compatibility very important, and I don't think they
> installed this wrapper.
>   

The GNU standards buy a little but not a lot and there are better ways
to do it.  We should talk.



> To convince free software projects generally to adopt this spec
> would require more pressure from the community in general.
>   

No.  A lot of the reason people *do* more or less use GNU standards
is personal convenience -- autoconf / GNU make / etc. make it easier
than many alternatives.

Better standards and better (and simpler) tools could amplify that
effect and have nicer side effects.

To be fair, you folks were solving a different problem, in the moment,
way back then.   A complete GNU system was quite a ways off and, as
a good tactic, the most immediate need was producing packages that
were not hard to build and install on a diverse range of proprietary Unix
systems.   That problem got solved pretty well but at a strategic cost of
being under-prepared for the "scale up" problems of managing source for
a complete system (imo). 



> It is easy to call names (such as calling the GNU Coding Standards
> "anemic"), but given that many programs' developers won't even
> implement those, I doubt we would obtain much compliance for stricter
> ones.
>   

If you ever think I'm "calling names" except in the case of geopolitical
polemics about fascists and such then please first, instead, think: 
"This is
an area where I can help Tom improve his writing," since I almost certainly
did not mean to "call names."

I do mean "anemic" in the sense of "vulnerable" or "slightly feeble".
It took and takes a lot of code to support those standards and the pay-off
fails to address many of the needs of a complete, portable system.

Stricter standards, better thought out, with simpler tools that realize them
might (plausibly would) find stepped up adoption.

So, I guess now I have to echo Stefan to me and say, to be clear,
that I assure you I intended no insult.

-t



>
>   

Re: Emacs vista build failures

[Richard M Stallman]

I'm interested in seeing what ideas you have for improving our
build and installation specs, etc.  I have cc'd Karl Berry
hoping that in a few days he will set up another list where we can
discuss that.

And thanks for explaining that the harsh-sounding words were not meant
that way.

Re: Emacs vista build failures

[Thomas Lord]

Richard M Stallman wrote:
> I'm interested in seeing what ideas you have for improving our
> build and installation specs, etc.  I have cc'd Karl Berry
> hoping that in a few days he will set up another list where we can
> discuss that.
>   

Thank you.   I hope that will develop into a productive conversation
rather than a dud.

I should caution that between now and a few days into August I
will be very busy because we're in the middle of a household move.
I have lots of packing to do, shelves to build, etc.    So I will have
to get off to a slow start in that discussion.    (This is probably
helpful, as a side effect:  I can better collect and organize my
thoughts that way.)

I trust that Karl will ping us when the mailing list is ready.


> And thanks for explaining that the harsh-sounding words were not meant
> that way.
>
>   

I am consistently surprised at the different measures I find among
people I know about what is or is not harsh, insulting, etc.   This
is both in reaction to things I say and in reaction to things others
say.

-t

Re: Emacs vista build failures

[Karl Berry]

    I'm interested in seeing what ideas you have for improving our
    build and installation specs, etc.  I have cc'd Karl Berry
    hoping that in a few days he will set up another list where we can
    discuss that.

I've set up a new list, emacs-build@gnu.org, and subscribed these
addresses (you should have received welcome msgs):

acm@muc.de
cyd@stupidchicken.com
drobinow@gmail.com
lord@emf.net
monnier@iro.umontreal.ca
rms@gnu.org

Anyone else who wants to join can do so via
http://lists.gnu.org/mailman/listinfo/emacs-build.

By the way, any administrator of the Emacs project at savannah can
create (or remove) emacs-* mailing lists through the savannah web
interface.

karl

Re: Emacs vista build failures

[Thomas Lord]

Karl Berry wrote:
>     I'm interested in seeing what ideas you have for improving our
>     build and installation specs, etc.  I have cc'd Karl Berry
>     hoping that in a few days he will set up another list where we can
>     discuss that.
>
> I've set up a new list, emacs-build@gnu.org, and subscribed these
> addresses (you should have received welcome msgs):
>   

I don't mind using that address although I understand the
topic to be larger in scope than just emacs.

-t

Re: Emacs vista build failures

[Gilaras Drakeson]

Hi,

>> I've set up a new list, emacs-build@gnu.org, and subscribed these
>> addresses (you should have received welcome msgs):

> I don't mind using that address although I understand the
> topic to be larger in scope than just emacs.


[Since I am not sure if the name of that list will change, I post my
comment here. I apologize if this is not the right mailing-list.]

I really hope to see a portable build system in a reasonable lisp. To
me, "the complexity of configure scripts" reads as "the accumulated
outcome of a not so great language for the job"[*]. I hope the emergence
of ad hoc build systems around various scripting languages and also ones
using XML will inspire people to pick a (or rather, the) proper language
for a build system of the future.

A POSIX compatibility layer [**] and a large library of build/packaging
related functions/macros will make a good head start. One ought to take
a look at dh_* scripts in Debian [***] for packaging related utilities,
which is an aspect sometimes overlooked in build systems.

I shouldn't be saying this, since you all know way better than me, that
the build system is a vital component in the software distribution (and
it is even more crucial for free software). Yet it is in the sad state
that we have today.

The `bootstrapping' problem for a new build system won't be solved
unless there is a concerted effort to push such a new system until it
becomes a [de facto] standard.

Such day-dreaming can really happen sometime in the future, if at least
some of us are convinced that it is something important to have.

[*]: I am not saying that at the time the choice of the language was
made it was a mistake. I am arguing that lisp will make a much better
choice for a future system.

[**]: A Windows compatibility layer is also important to have.

[***]: Those scripts come with the package `debhelper'

-- 
Gilaras Drakeson

Re: Emacs vista build failures

[Richard M Stallman]

    the build system is a vital component in the software distribution (and
    it is even more crucial for free software). Yet it is in the sad state
    that we have today.

I think the main reason our configuration and build methods
are so clumsy is that they were designed to run on lots of different
systems using only the programs we could expect to be available on them.

Re: Emacs vista build failures

[Thomas Lord]

Richard M Stallman wrote:
>     the build system is a vital component in the software distribution (and
>     it is even more crucial for free software). Yet it is in the sad state
>     that we have today.
>
> I think the main reason our configuration and build methods
> are so clumsy is that they were designed to run on lots of different
> systems using only the programs we could expect to be available on them.
>   



I agree.

It's a mistake worth correcting that more than (say) 10 GNU programs
rely on a system designed with those constraints.  (Then those "10" (or
so) can be used, exclusively, to bootstrap all of the rest of GNU 
user-space.).


-t