Emacs Installer for MS Windows

[Lennart Borgman]

I am very new to this list, but have been visiting the archives to get some
info. I am working on an installation package for MS Windows. Nothing very
fancy, just an installation program as you get with most programs on MS
Windows. I did write down some lines on http://www.emacswiki.org/ about it,
but I did not publish anything yet. (Search for LennartBorgman there, that
seems most simple.)

I got a mail telling that Frank Schmitt may have been doing something a bit
similar a year ago, but I can't find very much about it.

I would appreciate comments and suggestions. Where could I publish it?
Thoughts about it?

Kind regards,
Lennart

[Dhruva Krishnamurthy]

On Tue, 3 Aug 2004 00:17:45 +0200, "Lennart Borgman"

Post by Lennart Borgman
info. I am working on an installation package for MS Windows. Nothing very
fancy, just an installation program as you get with most programs on MS
Windows. I did write down some lines on http://www.emacswiki.org/ about it,

What ever approach you/anyone writing an Installation program for MS OS
takes, IMO, please make sure we do not have to have _admin_ rights to
install. This is a real stopper. I have found many users giving up on
lot of tools due to this limitation.

with best regards,
dhruva
________________________________________
Dhruva Krishnamurthy
Proud FSF member: #1935
http://schemer.fateback.com/

[Peter 'Luna' Runestig]

Post by Dhruva Krishnamurthy
What ever approach you/anyone writing an Installation program for MS OS
takes, IMO, please make sure we do not have to have _admin_ rights to
install. This is a real stopper. I have found many users giving up on
lot of tools due to this limitation.

Why? Why should "lusers" install new software on a computer?

[David Kastrup]

Post by Peter 'Luna' Runestig

Post by Dhruva Krishnamurthy
What ever approach you/anyone writing an Installation program for
MS OS takes, IMO, please make sure we do not have to have _admin_
rights to install. This is a real stopper. I have found many users
giving up on lot of tools due to this limitation.

Why? Why should "lusers" install new software on a computer?

Because freedom is too important to be contrained to the ranks of
revolutionists and appointed Windows administrators?

That's why we support operating systems like Windows in the first
place when it can be done with reasonable effort and without
sacrificing quality for the free systems. If you want to have people
come to you, the way is not by barricading their doors and telling
them to jump out of windows if they want to be free.

[Peter 'Luna' Runestig]

Post by David Kastrup

Post by Peter 'Luna' Runestig
Why? Why should "lusers" install new software on a computer?

Because freedom is too important to be contrained to the ranks of
revolutionists and appointed Windows administrators?

By "install new software on a computer", I mean putting software in a
common location, for all users on the computer to use. Surely you don't
suggest that any users should have the abillity to do that?

[Peter 'Luna' Runestig]

Post by Peter 'Luna' Runestig

Post by David Kastrup

Post by Peter 'Luna' Runestig
Why? Why should "lusers" install new software on a computer?

Because freedom is too important to be contrained to the ranks of
revolutionists and appointed Windows administrators?

By "install new software on a computer", I mean putting software in a
common location, for all users on the computer to use. Surely you don't
suggest that any users should have the abillity to do that?

^
Typo ----------------| should be "user"

[David Kastrup]

Post by Peter 'Luna' Runestig

Post by David Kastrup

Post by Peter 'Luna' Runestig
Why? Why should "lusers" install new software on a computer?

Because freedom is too important to be contrained to the ranks of
revolutionists and appointed Windows administrators?

By "install new software on a computer", I mean putting software in
a common location, for all users on the computer to use.

But the meaning here was completely unambiguously referring to putting
software in a location not requiring administrator rights so that the
user may at least be using the software himself.

Post by Peter 'Luna' Runestig
Surely you don't suggest that any users should have the abillity to
do that?

A user wanting to use Emacs should be able to install it for his uses
without having to beg his system administrator.

[Dhruva Krishnamurthy]

On Thu, 05 Aug 2004 08:51:00 +0200, "Peter 'Luna' Runestig"

Post by Peter 'Luna' Runestig

Post by David Kastrup

Post by Peter 'Luna' Runestig
Why? Why should "lusers" install new software on a computer?

Because freedom is too important to be contrained to the ranks of
revolutionists and appointed Windows administrators?

By "install new software on a computer", I mean putting software in a
common location, for all users on the computer to use. Surely you don't
suggest that any users should have the abillity to do that?

IMO, A user _must_ be able to install software for him/her self. In the
registry (on Windoze), there are areas not accessible to the users (or
better "lusers") and an installation trying to write into such locations
will not work with normal user rights (HKEY_CURRENT_USER and
HKEY_LOCAL_MACHINE). This is the only issue I can foresee which might
cause a limitation based on access rights during the proposed GNU Emacs
installation. As we do not need to do any DLL/COM service registration,
we are saved in GNU Emacs.
The one environment variable that the installer might want to modify is
PATH. This could be done under HKEY_LOCAL_MACHINE if the current user
is found to have access to it or modify it under HKEY_CURRENT_USER.
Infact, an option like in Cygwin installation could be made "Just for
me/For all users" during installation.

What installer is thought of? I have used NullSoft's installer and it
is very easy to implement.

with best regards,
dhruva
________________________________________
Dhruva Krishnamurthy
Proud FSF member: #1935
http://schemer.fateback.com/

[Lennart Borgman]

----- Original Message -----

Post by Dhruva Krishnamurthy
IMO, A user _must_ be able to install software for him/her self. In the
registry (on Windoze), there are areas not accessible to the users (or
better "lusers") and an installation trying to write into such locations
will not work with normal user rights (HKEY_CURRENT_USER and
HKEY_LOCAL_MACHINE). This is the only issue I can foresee which might
cause a limitation based on access rights during the proposed GNU Emacs
installation. As we do not need to do any DLL/COM service registration,
we are saved in GNU Emacs.
The one environment variable that the installer might want to modify is
PATH. This could be done under HKEY_LOCAL_MACHINE if the current user
is found to have access to it or modify it under HKEY_CURRENT_USER.
Infact, an option like in Cygwin installation could be made "Just for
me/For all users" during installation.

I agree. Do you know exactly what privileges are required for HKLM and HKCR
write? (Admin or Poweruser are those my installer chooses between.)

Post by Dhruva Krishnamurthy
What installer is thought of? I have used NullSoft's installer and it
is very easy to implement.

I am using Inno Setup. I have not heard of NullSoft before.

Kind regards,
Lennart

[Dhruva Krishnamurthy]

Hello,

On Thu, 5 Aug 2004 16:27:51 +0200, "Lennart Borgman"

Post by Lennart Borgman

Post by Dhruva Krishnamurthy
PATH. This could be done under HKEY_LOCAL_MACHINE if the current user
is found to have access to it or modify it under HKEY_CURRENT_USER.
Infact, an option like in Cygwin installation could be made "Just for
me/For all users" during installation.

I agree. Do you know exactly what privileges are required for HKLM and HKCR
write? (Admin or Poweruser are those my installer chooses between.)

I think a power user is sufficient for HKLM. Not sure for HKCR though.
The best way I check whether a user has valid permissions is by
attempting to create a key under say HKLM. If the user does not have
access, the call fails and I will know the user has insufficient
previlages, I then suggest a local installation for the current user
only.

Post by Lennart Borgman

Post by Dhruva Krishnamurthy
What installer is thought of? I have used NullSoft's installer and it
is very easy to implement.

I am using Inno Setup. I have not heard of NullSoft before.

I had tried Inno setup but found some limitations which I cannot thing
of immediately (I am not sure whether they exist now though). For
NullSoft's installer, you can have a look at
http://nsis.sourceforge.net/. They have very good support for scripting
which I found gave better/finer control.

with best regards,
dhruva
________________________________________
Dhruva Krishnamurthy
Proud FSF member: #1935
http://schemer.fateback.com/

[Richard Stallman]

Post by Dhruva Krishnamurthy
What installer is thought of? I have used NullSoft's installer and it
is very easy to implement.

I am using Inno Setup. I have not heard of NullSoft before.

Please keep in mind that any installer we use for GNU Emacs
must be free software.

I don't use MS Windows so I wouldn't know if either of those is free.
If one of them is free, then I suppose we could use it.

[David Kastrup]

Post by Lennart Borgman

Post by Dhruva Krishnamurthy
What installer is thought of? I have used NullSoft's installer and it
is very easy to implement.

I am using Inno Setup. I have not heard of NullSoft before.
Please keep in mind that any installer we use for GNU Emacs
must be free software.
I don't use MS Windows so I wouldn't know if either of those is free.
If one of them is free, then I suppose we could use it.

Didn't Microsoft recently release some installer tool Wix under the
CPL? More info is at
<URL:http://blogs.msdn.com/robmen/archive/2004/04/05/107709.aspx>.

AFAIR, the CPL, while being Open Source, is not GPL compatible.
However, since we are really talking about aggregation here, I don't
think this should be relevant.

I also have no idea whether this thing will actually be useful for our
purposes, but it is probably something worth taking a look at, if it
is a standard way of installing Windows software and at least freely
available with source, even if not under the GPL.

[Peter 'Luna' Runestig]

Post by David Kastrup
Didn't Microsoft recently release some installer tool Wix under the
CPL? More info is at
<URL:http://blogs.msdn.com/robmen/archive/2004/04/05/107709.aspx>.
AFAIR, the CPL, while being Open Source, is not GPL compatible.
However, since we are really talking about aggregation here, I don't
think this should be relevant.
I also have no idea whether this thing will actually be useful for our
purposes, but it is probably something worth taking a look at, if it
is a standard way of installing Windows software and at least freely
available with source, even if not under the GPL.

No, I don't think this is what you want. It creates Windows Installer
MSI packages, which IS the standard way to install stuff on Windows, but
to install them, you must be admin (AFAIK anyway).

As per http://lists.gnu.org/archive/html/emacs-devel/2003-09/msg00358.html
I wrote some C code some time ago, to create such an installer package,
as part of the normal build process. I thought it to be really cool, but
it seemed I was the only one excited, so the development of my MSI
Toolkit kind of died out. I still use it for making installer packages
of stuff like Mozilla, OpenSSL, Perl, Emacs though, take a look at
http://ftp.runestig.com/pub/ if you're curious.

[Peter 'Luna' Runestig]

Post by Peter 'Luna' Runestig
As per http://lists.gnu.org/archive/html/emacs-devel/2003-09/msg00358.html
I wrote some C code some time ago, to create such an installer package,
as part of the normal build process. I thought it to be really cool, but
it seemed I was the only one excited, so the development of my MSI
Toolkit kind of died out. I still use it for making installer packages
of stuff like Mozilla, OpenSSL, Perl, Emacs though, take a look at
http://ftp.runestig.com/pub/ if you're curious.

Since this thread seems to be really popular, I can't resist, pluging
myself again:

Here you have a free Emacs installer for Windows, based on CVS 2004-08-25:
ftp://www.runestig.com/pub/emacs/Emacs-21.3.50-20040825.msi
http://www.runestig.com/pub/emacs/Emacs-21.3.50-20040825.msi

Yes, to install MSI (Windows Installer) packages, you have to be "admin"
of your system. As apparent from my previous postings about that, I
thought that to be a minor problem; who is not an admin of their Windows
box? (I guess the one who's using someone else's Windows box) But I
learned that that was a crucial thing.

Anyway, I think this is at least an option to consider, if you want an
Emacs installer for Windows. I would say that the Windows Installer is
the de-facto standard to install stuff on Windows; I'd say 9 out of 10
(or even more) commercial software packages uses it. It blends right in
with Active Directory, e.g. you can install Emacs on every Windows PC in
your domain automaticly, out-of-the-box.

What I think is cool about my code, is that it's just that; C text code
(free of course), that creates the installer package (which is actually
a database of information for "msiexec.exe" to interpret), as part of
the normal build process (using the Platform SDK anyway). The binary MSI
file above, were created from my CVS checkout per 2004-08-25, like this:

patch -T -p1 < emacs-20030920-msi-20030923.patch
cd nt
configure.bat
nmake bootstrap
nmake info
nmake msi

Done!

But as I said before, it seems I'm the only one, thinking this is cool.
So the MSI generating code, in "makemsi.c", can be improved, especially
when it comes to upgrading possibilities; I'm aware of that, and I can
fix it, if there's any "demand" for it. OTOH, it works quite fine as it
is, but you have to uninstall the package, before you install a newer one.

Cheers,
- Peter

[Frank Schmitt]

Post by Lennart Borgman

Post by Dhruva Krishnamurthy
What installer is thought of? I have used NullSoft's installer and it
is very easy to implement.

I am using Inno Setup. I have not heard of NullSoft before.
Please keep in mind that any installer we use for GNU Emacs
must be free software.
I don't use MS Windows so I wouldn't know if either of those is free.
If one of them is free, then I suppose we could use it.

Inno Setups license can be found on:
http://www.jrsoftware.org/files/is/license.txt

[Eli Zaretskii]

Date: Fri, 06 Aug 2004 09:43:37 -0400
Please keep in mind that any installer we use for GNU Emacs
must be free software.
I don't use MS Windows so I wouldn't know if either of those is free.
If one of them is free, then I suppose we could use it.

A Windows installer that is Free Software was written by Andrew Innes
several years ago, for the "GNU Software for MS-Windows and MS-DOS"
CD-ROM (sold at the time by the FSF). I guess it might need some work
to add some bells and whistles, but it's a good starting point, and it
at least did TRT with all Windows varieties, from Windows 9X to W2K.

If someone needs its sources, I can dig them up.

[Lennart Borgman]

I have been struggling a bit with the installer. First I want to thank you
for all suggestions. I have tried to take a look at most of them.

Further down you will find a summary of my personal view of some different
installers for MS Windows. I decided to use Inno Setup. I had already done
some work with it, it is free, it has good scripting capabilities (which I
needed in this case).

Now I would like some suggestions. I hope you do not mind. First about where
to install Emacs. On ms windows most programs are installed in "c:\program
files\" as I guess you know. I see some alternatives (which I illustrate
with where emacs.exe is found):

A) "c:\program files\emacs\bin\emacs.exe
B) "c:\program files\emacs-21.3\bin\emacs.exe
C) "c:\program files\emacs\emacs\bin\emacs.exe
D) "c:\program files\emacs\emacs-21.3\bin\emacs.exe

Which one would you prefer? What about using "c:\program files"?

I include gnuclient and wonder where to put these exe-files. Currently I use
a structure like C) and put them in "c:\program files\emacs\w32bin". I also
put a copy of 7za.exe from 7-zip here to be able to unpack tar.gz files.
(With permission from the author of course.)

The installer also adds some elisp files that are ms windows specific or at
least specific for ms windows users. Where should I put these? Is site-lisp
a good place or should I use a separate directory not to mix it with the
users own or downloaded lisp files?

I have found it most easy to start up these scripts in site-lisp/default.el.
Default.el is run after .emacs which means I can use customization without
having to worry about the order in .emacs.

It may sound a bit strange but the installation script has now grown rather
large and I am thinking about where to put it. I must make it a bit more
pretty so someone else than me can understand it but after this I want to
upload it. I would like some suggestions of a preffered location.


*************
Let me then make a summary of my reading on ms windows installers. Just if
someone else should need it for something. (There is nothing else than this
below in this mail.) I took a little dive into the Win32 Installer Sea. As
far as i swimmed I saw three alternatives:

1) Inno Setup: Free, open source, copyrighted. (Not GPL. See license for
details: http://www.jrsoftware.org/files/is/license.txt.) Win32 only. Well
proven. Multilingual installations. Standard Windows 2000/XP-style or
"classic" installer wizard interface. Small footstep, easy to use for all
common tasks (file copying, checking admin privs, making shortcuts, adding
registry entries, choosing tasks, running programs after install,
uninstallation etc). The more common tasks are made in an INI-file like
syntax. Object Pascal script for more complicated tasks. LZMA/Zip/Bzip
compression *** I know this one fairly well ***

2) NSIS (Nullsoft Scriptable Install System): (Not GPL. License:
http://nsis.sourceforge.net/features/license/.) Very similar to Inno Setup.
Maybe not so well proven yet? Script syntax described by some as "more
arcane" (I tend to agree here). Some additions: web installation, plug ins.
*** I do not know this installer ***

"For windows setup projects. I would highly recommend Inno Setup.
http://www.jrsoftware.org/ It doesn't have the plugin architecture of NSIS,
but you can write code in Object Pascal, which is a little less arcane than
the pseudo assembler of NSIS."
(http://www.peterprovost.org/archive/0001/01/01/1040.aspx)

Comparing Inno and NSIS again:
http://diveintomark.org/archives/2003/04/09/nsis_an_open_source_installer_maker

3) Wix. I found it to be to much trouble taking a closer look at this. I did
read most of the blog that David Kastrup mentioned that was released under
CPL (not GPL) from MS:
<URL:http://blogs.msdn.com/robmen/archive/2004/04/05/107709.aspx>. The
advantage seemed to be use of XML, but I did not see very good scripting
facilities (but maybe they are there).

There seem to be a free version that existed before MS released this.
According to what I read the free version (which I can't remember the name
of right now) seemed to be able to do all that the MS version could do and a
bit more.

- Lennart

[Stefan Monnier]

Post by Lennart Borgman
A) "c:\program files\emacs\bin\emacs.exe
B) "c:\program files\emacs-21.3\bin\emacs.exe
C) "c:\program files\emacs\emacs\bin\emacs.exe
D) "c:\program files\emacs\emacs-21.3\bin\emacs.exe

I think an important aspect is "how do I upgrade" (as well as "how do
I uninstall", tho it's most common use is in the case of an upgrade).
So the choice between those depends on how well it deals with upgrades.

Post by Lennart Borgman
I include gnuclient and wonder where to put these exe-files. Currently I use
a structure like C) and put them in "c:\program files\emacs\w32bin". I also
put a copy of 7za.exe from 7-zip here to be able to unpack tar.gz files.
(With permission from the author of course.)

I recommend to keep separate packages separate (and to kep the packages as
vanilla as possible), so if you put extra packages in
c:\program files\emacs\w32bin, I'd expect you to use option B, C, or D, but
not A.

Post by Lennart Borgman
The installer also adds some elisp files that are ms windows specific or at
least specific for ms windows users. Where should I put these?

If they are Windows specific, they should probably just be part of Emacs
(and/or included in one of the existing windows-specific files such as
w32-*.el).
If they are specific to your installer, I'd also tend to argue that they
should just be submitted for inclusion.

Post by Lennart Borgman
Is site-lisp a good place or should I use a separate directory not to mix
it with the users own or downloaded lisp files?

As the name implies "site-lisp" is for things specific to the "site",
i.e. things that the user adds on her own. It should start empty.
But if there's stuff you need to add and you can't get it to be included in
macs proper, than site-lisp is probably the best choice indeed.

Post by Lennart Borgman
I have found it most easy to start up these scripts in site-lisp/default.el.

I'd recommend site-start.el instead.

Post by Lennart Borgman
Default.el is run after .emacs which means I can use customization without
having to worry about the order in .emacs.

Putting things in site-start.el makes it behave much more like all the rest
of the default Emacs settings: they are already set when the .emacs is
executed and won't be changed afterwards, so the user can "easily" change
them if she so wishes.

Post by Lennart Borgman
It may sound a bit strange but the installation script has now grown rather
large and I am thinking about where to put it. I must make it a bit more
pretty so someone else than me can understand it but after this I want to
upload it. I would like some suggestions of a preffered location.

I don't know what this script is used for (e.g. is it used when you build
the package, or is it used when you run the installer). The best place (if
possible at all) might be to put in the `admin' directory in the CVS
archive.


Stefan

[Lennart Borgman]

Thank you for all answers. I have decided to use "c:\program files" since
this is standard and it seems like this is what most of you prefer. (Though
I kind of like c:\GNU too.)

Post by Stefan Monnier
So the choice between those depends on how well it deals with upgrades.

...

Post by Stefan Monnier
I recommend to keep separate packages separate (and to kep the packages as
vanilla as possible), so if you put extra packages in

Then I believe the comments above from Stefan are important. At least for me
this kind of thinking use to turn out best in the long run.

Post by Stefan Monnier
On systems where the current copy of Emacs is not
necessarily in the path, invocation-directory is the first choice for
looking for gnuclient.

I believe I write a small command file called emacs.cmd for calling
gnuclientw.exe from the command file instead. This file can be put by the
user in the path. I could try writing the file to some dir in the path but
this might fail without privileges so I leave it to the user to place this
in the path if no one has a better idea.

Post by Stefan Monnier
I'd recommend site-start.el instead.

Post by Lennart Borgman
Default.el is run after .emacs which means I can use customization without
having to worry about the order in .emacs.

Putting things in site-start.el makes it behave much more like all the rest
of the default Emacs settings: they are already set when the .emacs is
executed and won't be changed afterwards, so the user can "easily" change
them if she so wishes.

I tend to disagree here but I may be misunderstanding something. As I have
seen it the order of execution is

1) site-start.el
2) .emacs
3) default.el

Emacs customization (i. e. custom-set-variables and custom-set-faces) are
run in .emacs normally. This mean I can use the the customization if I load
things from default.el. I can't do that from site-start.el. Or?

- Lennart

[Stefan Monnier]

Post by Lennart Borgman
I tend to disagree here but I may be misunderstanding something. As I have
seen it the order of execution is
1) site-start.el
2) .emacs
3) default.el
Emacs customization (i. e. custom-set-variables and custom-set-faces) are
run in .emacs normally. This mean I can use the the customization if
I load things from default.el. I can't do that from site-start.el. Or?

I guess it depends on what you want to do in default.el. I've just always
found it harder as a user when I was given a place (such as .emacs) where
I had to take into account future changes (as in: set toto here so that
later code in default.el will change foo to bar) as opposed to being
provided a state (setup by site-start.el) and being able to change it
directly without havnig to know or worry about what might come later.

But without more concrete details, it's difficult to discuss this.


Stefan

[Lennart Borgman]

----- Original Message -----

Post by Stefan Monnier
I guess it depends on what you want to do in default.el. I've just always
found it harder as a user when I was given a place (such as .emacs) where
I had to take into account future changes (as in: set toto here so that
later code in default.el will change foo to bar) as opposed to being
provided a state (setup by site-start.el) and being able to change it
directly without havnig to know or worry about what might come later.
But without more concrete details, it's difficult to discuss this.

Ok, I believe we think the same way. What I want to do is just add some
things to make it more easy to get started using Emacs for an ms windows
user:

1) Gnuserv is loaded

2) Some windows specific printing entries to the menus since printing
otherwise tends to be a problem when you start with Emacs on ms windows. I
also remove the unix-related printing entries from the menus because they do
not work or do not work as you expect them to. Of course I make this as
customization options.

3) I also offer some keyboard tweaks (CUA-mode, swbuff.el tighed to C-tab)
that can be good for an ms windows user. It is of course also in this case
very important that they are customization options.

4) recentf.el are also added, most ms windows programs has something like
this.

If no one has a good objection I will load things from default.el then. I
will do this by loading one file only from default.el to not clutter
default.el.

- Lennart

[Stefan Monnier]

Ok, I believe we think the same way. What I want to do is just add some
things to make it more easy to get started using Emacs for an ms windows
1) Gnuserv is loaded
2) Some windows specific printing entries to the menus since printing
otherwise tends to be a problem when you start with Emacs on ms windows. I
also remove the unix-related printing entries from the menus because they do
not work or do not work as you expect them to. Of course I make this as
customization options.
3) I also offer some keyboard tweaks (CUA-mode, swbuff.el tighed to C-tab)
that can be good for an ms windows user. It is of course also in this case
very important that they are customization options.
4) recentf.el are also added, most ms windows programs has something like
this.
If no one has a good objection I will load things from default.el then.
I will do this by loading one file only from default.el to not clutter
default.el.

[ I think changes to the default should be done in Emacs proper rather than
in packages of Emacs. So I basically disagree with all those changes
since they are not intrinsically bound to your package. I might agree to
changing some of those defaults, but I think we should clearly separate
the packaging from the user-preferences. I.e. keep things as vanilla as
possible. ]

- If printing doesn't work right out of the box, it should be fixed directly
in Emacs. Fixing it in your package is a bad solution.
- I don't understand exactly what you mean by "...that they are customization
options".
- Assuming a user disagrees with your choice, how is she to revert
your changes in her .emacs file?

let's say I start your Emacs and see "gee he turned on CUA-mode, that sucks
for me". What do I do? Normally, to turn CUA off, a user should do
(CUA-mode -1) or you use custom. Your site-start.el or default.el changes
should correctly react to either one of those things.


Stefan

[Lennart Borgman]

----- Original Message -----
From: "Stefan Monnier" <***@iro.umontreal.ca>
To: "Lennart Borgman" <***@student.lu.se>
Cc: "Emacs Devel" <emacs-***@gnu.org>
Sent: Tuesday, August 24, 2004 9:58 PM
Subject: Re: Emacs Installer for MS Windows

Post by Stefan Monnier

Ok, I believe we think the same way. What I want to do is just add some
things to make it more easy to get started using Emacs for an ms windows
1) Gnuserv is loaded
2) Some windows specific printing entries to the menus since printing ..
3) I also offer some keyboard tweaks (CUA-mode, swbuff.el tighed to

C-tab) ..

Post by Stefan Monnier

4) recentf.el are also added, most ms windows programs has something

like..

Post by Stefan Monnier

If no one has a good objection I will load things from default.el then.
I will do this by loading one file only from default.el to not clutter
default.el.

[ I think changes to the default should be done in Emacs proper rather than
in packages of Emacs. So I basically disagree with all those changes
since they are not intrinsically bound to your package. I might agree to
changing some of those defaults, but I think we should clearly separate
the packaging from the user-preferences. I.e. keep things as vanilla as
possible. ]

I agree that the packaging and user-preferences basically should be
separated. But it is also important to make a more easy road to emacs for an
ms windows user. To turn on all these things above are options at the
installation (except for gnuserv and the printing, see below).

However I realize more clearly after your comments that I should remove some
more of the things I have done.

I think that gnuserv always should be installed. Since I am only using ms
windows (I have never time to switch to Linux) I am not sure how it looks on
other platforms. I believe I read that gnuserv is included there (or
something similar). Is that correct?

Post by Stefan Monnier
- If printing doesn't work right out of the box, it should be fixed directly
in Emacs. Fixing it in your package is a bad solution.

I agree. Some time ago I sent a pointer to w32-printing.el that I have
uploaded to http://www.emacswiki.org/. Since I uploaded this I have realized
that I want to change some things in it, but basically it contain what I
believe is an easy and sufficiently good printing solution for Emacs on ms
windows. It does not however have all the options that printing.el have, it
is a much simpler solution. The advantage it has is that it uses the default
windows printing setup. I wrote it simply because I had trouble printing to
the network printers at my job from Emacs. It can print in two ways:
a) Through Notepad using just "notepad.exe /p"
b) Through Internet Explorer. This uses htmlize.el to color the printout.

A user may want to use both this and the postscript printing. Postscript
printing does not work without Ghostview which most users on ms windows does
not have installed. So I believe by default this entry should be hidden on
the file menu, but entries from w32-print.el should be visible. This of
course however makes Emacs a little bit different on ms windows.

Post by Stefan Monnier
- I don't understand exactly what you mean by "...that they are customization
options".

I mean that you can change them through "Options - Customize Emacs" in the
menus.

Post by Stefan Monnier
- Assuming a user disagrees with your choice, how is she to revert
your changes in her .emacs file?

See above.

Post by Stefan Monnier
let's say I start your Emacs and see "gee he turned on CUA-mode, that sucks
for me". What do I do? Normally, to turn CUA off, a user should do
(CUA-mode -1) or you use custom. Your site-start.el or default.el changes
should correctly react to either one of those things.

I turn on the options just as if the user had used "Options - Customize
Emacs" so I do not believe it is a problem.


Please give me more feedback on these things!

- Lennart

[Stefan]

Post by Lennart Borgman
I agree that the packaging and user-preferences basically should be
separated. But it is also important to make a more easy road to emacs for an
ms windows user. To turn on all these things above are options at the
installation (except for gnuserv and the printing, see below).

There are also W32 users who've learned Emacs before and who e.g. don't want
CUA-mode. I understand your desire, and I think the best way to do that is
to have an installation option to install a "vanilla Emacs" or "Emacs with
w32 tweaks". I think it's important to make it clear that it's not quite
"plain vanilla Emacs" for reasons of bug-reporting and things like that.

Post by Lennart Borgman
I think that gnuserv always should be installed. Since I am only using ms
windows (I have never time to switch to Linux) I am not sure how it looks on
other platforms. I believe I read that gnuserv is included there (or
something similar). Is that correct?

I think adding gnuserv is fine, since it replaces the missing
emacsclient/emacsserver (of course, what should really happen is that we
should get emacscliant/emacsserver working on w32 so you don't need to add
gnuserv, but in the mean time it's a good workaround).

[ I don't know enough about w32 printing to comment on your suggestion. ]

Post by Lennart Borgman

Post by Stefan Monnier
let's say I start your Emacs and see "gee he turned on CUA-mode, that

sucks

Post by Stefan Monnier
for me". What do I do? Normally, to turn CUA off, a user should do
(CUA-mode -1) or you use custom. Your site-start.el or default.el changes
should correctly react to either one of those things.

I turn on the options just as if the user had used "Options - Customize
Emacs" so I do not believe it is a problem.

Huh? How do you do that? If you call custom-set-variables in site-start.el
or default.el, it won't be the same as if you called it in .emacs because
the user has no way to change those settings AFAIK. Have you tried it?
Actually maybe it works from site-start.el?
Have you also tried the case where the user uses (CUA-mode -1) instead
of using customize?
Note also that if you call custom-set-variables, if the user subsequently
does a custom-save, it will put a duplicate of your custom-set-variables
into her .emacs (because Emacs doesn't know that those settings were not
originally made from .emacs).

Incidentally, isn't this a case where a custom theme could advantageously
be used?


Stefan

[Lennart Borgman]

----- Original Message -----

Post by Stefan

Post by Lennart Borgman

Post by Stefan Monnier
let's say I start your Emacs and see "gee he turned on CUA-mode, that

sucks

Post by Stefan Monnier
for me". What do I do? Normally, to turn CUA off, a user should do
(CUA-mode -1) or you use custom. Your site-start.el or default.el changes
should correctly react to either one of those things.

I turn on the options just as if the user had used "Options - Customize
Emacs" so I do not believe it is a problem.

Huh? How do you do that? If you call custom-set-variables in

site-start.el

Post by Stefan
or default.el, it won't be the same as if you called it in .emacs because
the user has no way to change those settings AFAIK. Have you tried it?

I do it by calling emacs this way

emacs.exe -l set-vars.el -f kill-emacs

where set-vars.el contains something like

(put 'custom-var 'saved-value (list "custom value"))
(custom-save-all)

As Stefan has pointed out to me this will only affect the user that is
installing Emacs. However I think that is no big problem on ms windows.

I do not feel really comfortable with this solution since it requires
internal knowledge of custom, but I can't find any other way. If there is
one, please tell me.

- Lennart

[David Kastrup]

Post by Lennart Borgman

Post by Stefan

Post by Lennart Borgman
I turn on the options just as if the user had used "Options -
Customize Emacs" so I do not believe it is a problem.

Huh? How do you do that? If you call custom-set-variables in
site-start.el or default.el, it won't be the same as if you called
it in .emacs because the user has no way to change those settings
AFAIK. Have you tried it?

I do it by calling emacs this way
emacs.exe -l set-vars.el -f kill-emacs
where set-vars.el contains something like
(put 'custom-var 'saved-value (list "custom value"))
(custom-save-all)
As Stefan has pointed out to me this will only affect the user that is
installing Emacs. However I think that is no big problem on ms windows.

(customize-set-value 'custom-var "custom value")
...
(customize-save-customized)

[Stefan Monnier]

Post by David Kastrup

Post by Lennart Borgman
As Stefan has pointed out to me this will only affect the user that is
installing Emacs. However I think that is no big problem on ms windows.

I think that's only acceptable if there's no good way to do The Right Thing.

Post by David Kastrup
(customize-set-value 'custom-var "custom value")
...
(customize-save-customized)

Yes, that's better. But the problem is still here: this will only affect
the current user, and (worse) this will modify his .emacs, potentially
throwing away some of his own customizations.

My take on it is to create a site-start.el (or default.el) file which does
something along the lines of:

(unless (file-exists-p "~/.emacs")
(customize-set-value 'custom-var1 "custom value1")
(customize-set-value 'custom-var2 "custom value2")
(customize-set-value 'custom-var3 "custom value3"))

This way, if the user already has a .emacs, nothing happens.
And if she every changes something via customize, the settings will be added
to her .emacs so those settings will apply to any Emacs (which is a good
thing: you want to be able to move your .emacs from one place to another,
including from w32 to unix and vice-versa).


Stefan

[Lennart Borgman]

----- Original Message -----

Post by Stefan Monnier

Post by David Kastrup

Post by Lennart Borgman
As Stefan has pointed out to me this will only affect the user that is
installing Emacs. However I think that is no big problem on ms windows.

I think that's only acceptable if there's no good way to do The Right Thing.

I really think TRT is undoable here. I will instead leave Emacs untweaked
for other users.

Post by Stefan Monnier

Post by David Kastrup
(customize-set-value 'custom-var "custom value")
...
(customize-save-customized)

Yes, that's better.

It looks better, but it however has one big fault - it does not save the
changes.

Post by Stefan Monnier
But the problem is still here: this will only affect
the current user, and (worse) this will modify his .emacs, potentially
throwing away some of his own customizations.

It seems acceptable to modify .emacs if I ask first.

Post by Stefan Monnier
My take on it is to create a site-start.el (or default.el) file which does
(unless (file-exists-p "~/.emacs")
(customize-set-value 'custom-var1 "custom value1")
(customize-set-value 'custom-var2 "custom value2")
(customize-set-value 'custom-var3 "custom value3"))

There have been many good points on this and this is one. The essential
thing as I understand it is to honor the users setting. My first idea has
been to create a minor mode for the w32 tweaks. Maybe I still can do this,
but the discussion shows I have to be very careful then.

- Lennart

[Eli Zaretskii]

Date: Wed, 25 Aug 2004 02:06:10 +0200
I agree that the packaging and user-preferences basically should be
separated. But it is also important to make a more easy road to emacs for an
ms windows user.

Please don't do that: a freshly installed Emacs on Windows should
behave the same as on Unix. Anything else calls for problems and
misunderstandings when peopel report bugs.

I completely agree with Stefan: anything that doesn't work out of the
box on Windows is a bug that should be solved in the core
distribution, not in add-on packages.

I agree. Some time ago I sent a pointer to w32-printing.el that I have
uploaded to http://www.emacswiki.org/. Since I uploaded this I have realized
that I want to change some things in it, but basically it contain what I
believe is an easy and sufficiently good printing solution for Emacs on ms
windows. It does not however have all the options that printing.el have, it
is a much simpler solution. The advantage it has is that it uses the default
windows printing setup. I wrote it simply because I had trouble printing to
a) Through Notepad using just "notepad.exe /p"
b) Through Internet Explorer. This uses htmlize.el to color the printout.

This is IMHO ridiculous: we should not use these tools to print, we
should instead add the code to Emacs to do whatever they do to find
the default printer. Ghostscript does that, and Ghostscript is free
software, so someone should be able to look in its code and find the
trick.

A user may want to use both this and the postscript printing. Postscript
printing does not work without Ghostview which most users on ms windows does
not have installed.

Postscript print does not automatically work on Unix, either, if you
don't have access to a Postscript-able printer.

[Peter 'Luna' Runestig]

On 2004-08-25 06:15, Eli Zaretskii wrote:
[...]

Post by Eli Zaretskii
This is IMHO ridiculous: we should not use these tools to print, we
should instead add the code to Emacs to do whatever they do to find
the default printer. Ghostscript does that, and Ghostscript is free
software, so someone should be able to look in its code and find the
trick.

We already have that, since 2004-01-28, when this patch was committed:
http://lists.gnu.org/archive/html/emacs-devel/2003-09/msg00115.html

If you put this in .emacs:

(setq printer-name nil)

a CVS build of Emacs on Windows prints to the Windows default printer.

[Lennart Borgman]

----- Original Message -----

Post by Peter 'Luna' Runestig
(setq printer-name nil)
a CVS build of Emacs on Windows prints to the Windows default printer.

That is very nice! Does this allow printing in color too?

- Lennart

[Eli Zaretskii]

Date: Wed, 25 Aug 2004 09:09:12 +0200
http://lists.gnu.org/archive/html/emacs-devel/2003-09/msg00115.html

Ah, sorry, I somehow thought that this wasn't working properly in some
situation.

So the print-related hacks can go from the Windows install issue.

[Vinicius Jose Latorre]

Post by Eli Zaretskii

Date: Wed, 25 Aug 2004 02:06:10 +0200
I agree that the packaging and user-preferences basically should be
separated. But it is also important to make a more easy road to emacs for an
ms windows user.

Please don't do that: a freshly installed Emacs on Windows should
behave the same as on Unix. Anything else calls for problems and
misunderstandings when peopel report bugs.
I completely agree with Stefan: anything that doesn't work out of the
box on Windows is a bug that should be solved in the core
distribution, not in add-on packages.

I also completely agree with Eli and Stefan.

Post by Eli Zaretskii

I agree. Some time ago I sent a pointer to w32-printing.el that I have
uploaded to http://www.emacswiki.org/. Since I uploaded this I have realized
that I want to change some things in it, but basically it contain what I
believe is an easy and sufficiently good printing solution for Emacs on ms
windows. It does not however have all the options that printing.el have, it
is a much simpler solution. The advantage it has is that it uses the default
windows printing setup. I wrote it simply because I had trouble printing to
a) Through Notepad using just "notepad.exe /p"
b) Through Internet Explorer. This uses htmlize.el to color the printout.

This is IMHO ridiculous: we should not use these tools to print, we
should instead add the code to Emacs to do whatever they do to find
the default printer. Ghostscript does that, and Ghostscript is free
software, so someone should be able to look in its code and find the
trick.

Indeed, Emacs already has code in Emacs Lisp to deal with this, the packages
are:

lpr.el --- print Emacs buffer on line printer
Copyright (C) 1985, 1988, 1992, 1994, 2001, 2003
Free Software Foundation, Inc.

ps-print.el --- print text from the buffer as PostScript
Copyright (C) 1993, 1994, 1995, 1996, 1997, 1998, 1999, 2000, 2001, 2002,
2003, 2004 Free Software Foundation, Inc.

printing.el --- printing utilities
Copyright (C) 2000, 2001, 2002, 2003, 2004
Free Software Foundation, Inc.

Post by Eli Zaretskii

A user may want to use both this and the postscript printing. Postscript
printing does not work without Ghostview which most users on ms windows does
not have installed.

Postscript print does not automatically work on Unix, either, if you
don't have access to a Postscript-able printer.

Ghostview is used for previewing a PostScript file. It also can be used to
preview a PDF file.

Ghostscript is used for printing a PostScript file if you don't have a
PostScript printer.

To print a PostScript file in Windows, Unix or any other OS you need to
have a
PostScript printer.

[Lennart Borgman]

Excuse me for the length of this mail. I just want to be clear because of
the risk of confusion here.

----- Original Message -----

Post by Vinicius Jose Latorre

Post by Eli Zaretskii

Date: Wed, 25 Aug 2004 02:06:10 +0200
I agree that the packaging and user-preferences basically should be
separated. But it is also important to make a more easy road to
emacs for an ms windows user.

Please don't do that: a freshly installed Emacs on Windows should
behave the same as on Unix. Anything else calls for problems and
misunderstandings when peopel report bugs.
I completely agree with Stefan: anything that doesn't work out of the
box on Windows is a bug that should be solved in the core
distribution, not in add-on packages.

I also completely agree with Eli and Stefan.

I believe there are two different problems here. One is when something does
not work or does not work as expected. The second is when Emacs behaves in a
way that is unexpected to an MS Windows user. In this case I mostly think
about key bindings.

In the first case I agree of course. No problem at all.

In the second case I am a little bit more doubtful. However I believe that
Stefan's suggestion to "have an installation option to install a "vanilla
Emacs" or "Emacs with
w32 tweaks"" is the best.

I understand the concern about the bug reports but I hope that it can be
solved by clearly stating that some things in Emacs are changed if "w32
tweaks" are choosen. Anyway is not this a normal problem with bug reports
for Emacs?

...

Post by Vinicius Jose Latorre

Post by Eli Zaretskii

windows printing setup. I wrote it simply because I had trouble

printing to

Post by Eli Zaretskii

a) Through Notepad using just "notepad.exe /p"
b) Through Internet Explorer. This uses htmlize.el to color the

printout.

Post by Eli Zaretskii
This is IMHO ridiculous: we should not use these tools to print, we
should instead add the code to Emacs to do whatever they do to find
the default printer. Ghostscript does that, and Ghostscript is free
software, so someone should be able to look in its code and find the
trick.

Indeed, Emacs already has code in Emacs Lisp to deal with this, the packages
lpr.el --- print Emacs buffer on line printer
Copyright (C) 1985, 1988, 1992, 1994, 2001, 2003
Free Software Foundation, Inc.
ps-print.el --- print text from the buffer as PostScript
Copyright (C) 1993, 1994, 1995, 1996, 1997, 1998, 1999, 2000, 2001, 2002,
2003, 2004 Free Software Foundation, Inc.
printing.el --- printing utilities
Copyright (C) 2000, 2001, 2002, 2003, 2004
Free Software Foundation, Inc.

I am glad for the clarification, but I still see some confusion here. Please
correct me if I am wrong. As far as I know the tools above does not honor
the setting of the default printer in ms windows. That is simply because
this option is not available in the current Emacs release (but it will be in
the next).

When this is available there is of course no reason to use notepad.exe for
printing ;-)

However since I have never been able to use any of the above I still wonder
about colored printouts. I surely want colored printouts on my default ms
windows printer. Will they allow this? I do not care whether it is a
PostScript printer or not. I just want the printout. The solution I
suggested is indeed far from an optimal solution but it gives me the colored
printout.

- Lennart

[Vinicius Jose Latorre]

Post by Lennart Borgman
However since I have never been able to use any of the above I still wonder
about colored printouts. I surely want colored printouts on my default ms
windows printer. Will they allow this? I do not care whether it is a
PostScript printer or not. I just want the printout. The solution I
suggested is indeed far from an optimal solution but it gives me the colored
printout.

Please, read ps-print.el documentation (the comments in the beginning of
ps-print.el source).

You can also remap colors/bold/italic/etc so when printing has the suitable
look in the paper.

Of course, you'll need to have a color PostScript printer. But if you
have a
black/white PostScript printer, you can also remap colors/bold/italic/etc to
other things like:

bold
italic
underline
gray
strikeout - like underline, but the line is in middle of text.
overline - like underline, but the line is over the text.
shadow - text will have a shadow.
box - text will be surrounded by a box.
outline - print characters as hollow outlines.

And a mixing of all above.

[Stefan Monnier]

Of course, you'll need to have a color PostScript printer. But if you have

I think the most common situation nowadays for home-use is that the printer
is not using postscript. Under Unix it makes no difference since most
printing systems will use ghostscript for you anyway, but on w32 that's not
the case, so the question is really "how can get fontified printouts in w32
without a postscript printer".
Maybe the best answer is indeed to tell people to install ghostscript, but
then the Emacs installer should make that clear and easy.


Stefan

[Gian Uberto Lauri]

VJL> Ghostscript is used for printing a PostScript file if you don't have a
VJL> PostScript printer.

VJL> To print a PostScript file in Windows, Unix or any other OS you need to
VJL> have a PostScript printer.

Ahem...

(setq ps-printer-name "")
(setq ps-lpr-command "d:\\gs\\gsview\\gsprint.exe")
(setq ps-lpr-switches " -sDEVICE=mswinprn -q -dNOPAUSE -dBATCH" )

[Lennart Borgman]

----- Original Message -----

Post by Gian Uberto Lauri
VJL> Ghostscript is used for printing a PostScript file if you don't have a
VJL> PostScript printer.
VJL> To print a PostScript file in Windows, Unix or any other OS you need to
VJL> have a PostScript printer.
Ahem...
(setq ps-printer-name "")
(setq ps-lpr-command "d:\\gs\\gsview\\gsprint.exe")
(setq ps-lpr-switches " -sDEVICE=mswinprn -q -dNOPAUSE -dBATCH" )

Will the new version of Emacs detect whether the default printer is a
PostScript printer?

- Lennart

[Vinicius Jose Latorre]

Post by Lennart Borgman
Will the new version of Emacs detect whether the default printer is a
PostScript printer?

Does Word detect if the default printer is PostScript printer or you have to
set default PostScript printer in Windows?

[Stefan Monnier]

Post by Vinicius Jose Latorre

Post by Lennart Borgman
Will the new version of Emacs detect whether the default printer is a
PostScript printer?

Does Word detect if the default printer is PostScript printer or you have to
set default PostScript printer in Windows?

You don't have to tell Word what kind of printer you have: you just choose
the printer and that's it. You do have to tell which printer it is at some
point, of course, but that's done system-wide when you setup the printer.

As for what kind of format is used between applications and the printer's
driver, I have no idea.


Stefan

[Gian Uberto Lauri]

Post by Vinicius Jose Latorre

Post by Lennart Borgman
Will the new version of Emacs detect whether the default printer is a
PostScript printer?

Does Word detect if the default printer is PostScript printer or you have to
set default PostScript printer in Windows?

SM> You don't have to tell Word what kind of printer you have: you just choose
SM> the printer and that's it. You do have to tell which printer it is at some
SM> point, of course, but that's done system-wide when you setup the printer.

SM> As for what kind of format is used between applications and the printer's
SM> driver, I have no idea.

The applications, AFAIK, create a "graphic context" and then they draw on
it both shapes and character gliphs.

In the example I posted the gs program (from the ghostgum suite - I
fear it could be non-free) was told to use that system.

With some saner printer design you can send data directly to the
printer (on the LPT port or to the network address/port) bypassing the
driver, but dumber "I need the windows driver" printers do exist (HP
do you hear me :) ?)

[Lennart Borgman]

----- Original Message -----
From: "Vinicius Jose Latorre" <***@ig.com.br>
To: "Lennart Borgman" <***@student.lu.se>
Cc: <***@eng.it>; "Eli Zaretskii" <***@gnu.org>; <emacs-***@gnu.org>
Sent: Thursday, August 26, 2004 7:40 PM
Subject: Re: Emacs Installer for MS Windows

Post by Vinicius Jose Latorre

Post by Lennart Borgman
Will the new version of Emacs detect whether the default printer is a
PostScript printer?

Does Word detect if the default printer is PostScript printer or you have to
set default PostScript printer in Windows?

I am not sure of the details of how it is organized, but I will try to
explain the principles as far as I understand them. Word (or any other
program that wants to print) talks to a printer driver. This driver has
specific information about the printer choosen. Whether the translation to
PostScript takes place in Word or in the printer driver is not entirely
clear to me. However the version of Acrobat that create the pdf document
acts as a printer dirver and it has the capability to create a pdf document
from any program from which you can print. This makes me believe there is
some kind of meta-language for description of the printout that is
translated to PostScript by the printer driver.

Probably there then must be open source code for things like this in Open
Office and Mozilla.

- Lennart

[Benjamin Riefenstahl]

Hi Lennart,

Word (or any other program that wants to print) talks to a printer
driver. This driver has specific information about the printer
choosen. Whether the translation to PostScript takes place in Word
or in the printer driver is not entirely clear to me.

In the Word/Notepad/Mozilla scenario the fact that the printer uses
PostScript is a private agreement between the printer driver and the
printer device. The printer driver is a plugin DLL for the Windows
graphics API, the so-called "GDI". Word (or Notepad or Mozilla) is
just calling the GDI API to print. The GDI routes all calls from the
application to the printer driver. The printer driver does the right
thing, it creatES PostScript, PCL, Epson escape sequences or whatever.
Than the driver gets that to the device or to an intermediate printer
queue.

However the version of Acrobat that create the pdf document acts as
a printer dirver and it has the capability to create a pdf document
from any program from which you can print.

A printer driver in the above scenario can do anything it wants with
the application calls. Adobe's PDF-driver just decides not to connect
to any hardware device, instead it asks the user for a filename. As
this is all in DLLs (shared libraries) inside the printing foreground
process, putting up a dialog to ask for a filename is not considered a
problem.

This makes me believe there is some kind of meta-language for
description of the printout that is translated to PostScript by the
printer driver.

Usually there is no intermediate format involved, just calls to the
API and from there to the driver interface.

You *can* just collect all those calls into a file and re-play that
file later, that's the format that is called a Windows metafile (WMF
or more recently EMF). But that is an exception, not the usual case.

Probably there then must be open source code for things like this in
Open Office and Mozilla.

Emacs works differently at the moment. It creates a representation
that it thinks is suitable for a printer and than it calls a program
to put this formatted document directly into a printer queue. This
by-passes the Windows printer driver. Emacs has two implementations
for formatting, one using line-printer style plain text (lpr.el) and
one using PostScript (ps-print.el).

This mode of operation does work where either of these formats is
supported and sufficient. For nicer-looking results you want to use
ps-print.el, of course. Non-PostScript printers can be made to work
on Windows in this manner by using Ghostscript as the program to call,
as was already mentioned. Ghostscript includes a driver that uses GDI
for its work (more or less the reverse of that PDF printer driver
above). This mode works with any Windows printer. Of course
printer-specific Ghostscript drivers should give better results.

If you want OOTB printing for Emacs on Windows for any printer, you
need either bundle (and automatically configure) Ghostscript, or you
need to write a third printing implementation similar to ps-print.el
that uses GDI calls. The first solution is larger, but much easier to
implement and automatically compatible with code that builds on top of
ps-print.el. Given that disk space and bandwidth is cheap these days
and that Ghostscript is free, it may be the way to go.

This could be part of the Windows installer. You may want to download
Ghostscript as an automated step during installation and only, when it
is not already installed. I.e. make a customization option in the
installer to either download Ghostscript or pick an existing
installation or to do neither (that option would only be available at
"expert" level, I guess).


benny

[Lennart Borgman]

----- Original Message -----

Post by Benjamin Riefenstahl
printer device. The printer driver is a plugin DLL for the Windows
graphics API, the so-called "GDI". Word (or Notepad or Mozilla) is

Thank you for the good descriptions.

Post by Benjamin Riefenstahl
If you want OOTB printing for Emacs on Windows for any printer, you
need either bundle (and automatically configure) Ghostscript, or you
need to write a third printing implementation similar to ps-print.el
that uses GDI calls. The first solution is larger, but much easier to
implement and automatically compatible with code that builds on top of
ps-print.el. Given that disk space and bandwidth is cheap these days
and that Ghostscript is free, it may be the way to go.

I think using colored printing the way I suggested earlier is often good
enough. The advantage it has is that it is very simple. (Of course it is not
very elegant, but it is existing.) It is also a solution that probably can
be made portable since printing a html file is certainly a thing I guess can
be done on most main operating systems. It is in this way an interface to
the operating system for printing that is stable. That should be a main
concern I believe.

Post by Benjamin Riefenstahl
This could be part of the Windows installer. You may want to download
Ghostscript as an automated step during installation and only, when it
is not already installed. I.e. make a customization option in the
installer to either download Ghostscript or pick an existing
installation or to do neither (that option would only be available at
"expert" level, I guess).

I will try. Please tell me which Ghostscript to use.

- Lennart

[Benjamin Riefenstahl]

Hi Lennart,

Post by Lennart Borgman
I think using colored printing the way I suggested earlier is often
good enough. The advantage it has is that it is very simple. (Of
course it is not very elegant, but it is existing.) It is also a
solution that probably can be made portable since printing a html
file is certainly a thing I guess can be done on most main operating
systems.

Most OSs have no idea what HTML is. The user installs a browser of
his choice (or other tools) and that handles the HTML. Sorry if this
sounds pedantic, but my point is "a browser of his choice", which
implies that in general there is no fixed stable interface to an HTML
processing facility.

On Windows you always have Internet Explorer, but a) it's printing
output may not be acceptable and b) it is constantly changing with
feature updates as well as security patches.

Post by Lennart Borgman

[About Ghostscript:] This could be part of the Windows installer.

I will try. Please tell me which Ghostscript to use.

In the end you will have to decide for yourself. A quick look into my
sources indicate that you probably want

ftp://mirror.cs.wisc.edu/pub/mirrors/ghost/AFPL/gs814/gs814w32.exe

That looks like the latest AFPL version (for non-commercial use only,
but with source available), the version that is also used by GSView.
In 5 minutes I can't find a simple way to get the free version as a
precompiled Windows binary. You can probably just use the previous
AFPL version, which should be identical to the free version,
i.e. [...]/gs704/gs704w32.exe .

For more information see the pages that i just checked:

http://www.gnu.org/software/ghostscript/ghostscript.html
http://www.cs.wisc.edu/~ghost/doc/AFPL/get814.htm
http://www.cs.wisc.edu/~ghost/doc/AFPL/8.00/New-user.htm#Find_Ghostscript


benny

[Stefan Monnier]

Post by Benjamin Riefenstahl
ftp://mirror.cs.wisc.edu/pub/mirrors/ghost/AFPL/gs814/gs814w32.exe
That looks like the latest AFPL version (for non-commercial use only,

Clearly not acceptable: it has to be free software.


Stefan

[Benjamin Riefenstahl]

Hi Stefan,

Post by Stefan Monnier

Post by Benjamin Riefenstahl
ftp://mirror.cs.wisc.edu/pub/mirrors/ghost/AFPL/gs814/gs814w32.exe
That looks like the latest AFPL version (for non-commercial use only,

Clearly not acceptable: it has to be free software.

I think the options were pretty clear in the parts of my post that you
snipped.

I am not a lawyer so I shouldn't discuss the details of the legal
issues. Also I am not the one to build an installer, so my interest
in this is limited anyway.

benny

[Lennart Borgman]

----- Original Message -----
From: "Stefan Monnier" <***@iro.umontreal.ca>
To: "Benjamin Riefenstahl" <***@epost.de>
Cc: "Lennart Borgman" <***@student.lu.se>; "Emacs Devel"
<emacs-***@gnu.org>
Sent: Friday, August 27, 2004 3:20 PM
Subject: Re: Emacs Installer for MS Windows

Post by Stefan Monnier

Post by Benjamin Riefenstahl
ftp://mirror.cs.wisc.edu/pub/mirrors/ghost/AFPL/gs814/gs814w32.exe
That looks like the latest AFPL version (for non-commercial use only,

Clearly not acceptable: it has to be free software.

It seems like this is the only available precompiled version.

- Lennart

[Lennart Borgman]

----- Original Message -----

Post by Benjamin Riefenstahl
Most OSs have no idea what HTML is. The user installs a browser of
his choice (or other tools) and that handles the HTML. Sorry if this
sounds pedantic, but my point is "a browser of his choice", which
implies that in general there is no fixed stable interface to an HTML
processing facility.
On Windows you always have Internet Explorer, but a) it's printing
output may not be acceptable and b) it is constantly changing with
feature updates as well as security patches.

Surprise again. Do you mean that Mac and Linux (to leave out more technical
alternatives) do not have something like Windows Explorer where you can
double-click (or something similar) on a HTML file to open it? Or is not
this feature integrated and available to other programs through some kind of
API?

- Lennart

[Gian Uberto Lauri]

LB> Surprise again. Do you mean that Mac and Linux (to leave out more technical
LB> alternatives) do not have something like Windows Explorer where you can
LB> double-click (or something similar) on a HTML file to open it?

Mac does it. Linux could if you use KDE or Gnome, bloating stuff not at
all this necessary. Even if free.

Many Emacs users under Linux or Unix just use a plain window manager
under Unix or Linux and something called command line ( :) :) ). Some
of them claim that bash is almost as powerful as Emacs :).

[Lennart Borgman]

----- Original Message -----

Post by Gian Uberto Lauri
LB> Surprise again. Do you mean that Mac and Linux (to leave out more technical
LB> alternatives) do not have something like Windows Explorer where you can
LB> double-click (or something similar) on a HTML file to open it?
Mac does it. Linux could if you use KDE or Gnome, bloating stuff not at
all this necessary. Even if free.
Many Emacs users under Linux or Unix just use a plain window manager
under Unix or Linux and something called command line ( :) :) ). Some
of them claim that bash is almost as powerful as Emacs :).

Personally I always use the command line because it is much faster. The ms
windows Command Prompt on NT integrates this feature with the command line.
That is very important for me. I hoped that this was an available interface
for handling files on most major modern operating systems.

- Lennart

[Benjamin Riefenstahl]

Hi Lennart,

Post by Lennart Borgman
Surprise again. Do you mean that Mac and Linux (to leave out more
technical alternatives) do not have something like Windows Explorer
where you can double-click (or something similar) on a HTML file to
open it?

Usually they have some browser installed, so if (and only if)
"usually" is enough for you, that would not be a problem.

Post by Lennart Borgman
Or is not this feature integrated and available to other programs
through some kind of API?

On Mac there is a standard API for doing that.

But AFAIK on Linux/Unix the way to do it depends on the type of
desktop and file manager (KDE, Gnome, etc) that you have installed.

In all cases, the browser has to integrate with the framework used.

Also I thought you were talking about printing, not just viewing as
HTML. That requires that the HTML browser is correctly setup for
printing.

Finally while most desktop systems probably implement automatic
printing in their framework, experience shows that applications often
don't implement that feature or don't implement it correctly. So I
expect that in a lot of cases the user still has to select the print
menu himself in the browser.


benny

[Richard Stallman]

Surprise again. Do you mean that Mac and Linux (to leave out more technical
alternatives) do not have something like Windows Explorer where you can

Linux is just a kernel--it does not include web browsers.
If you're talking about the GNU/Linux operating system, it
includes various web browsers such as Lynx, Mozilla, and Galeon,
but please don't call the system "Linux".

(The GNU standard format for documentation files is Texinfo.)

[Lennart Borgman]

----- Original Message -----
From: "Benjamin Riefenstahl" <***@epost.de>
To: "Lennart Borgman" <***@student.lu.se>
Cc: "Emacs Devel" <emacs-***@gnu.org>
Sent: Friday, August 27, 2004 11:22 AM
Subject: Re: Emacs Installer for MS Windows

Post by Benjamin Riefenstahl
In the end you will have to decide for yourself. A quick look into my
sources indicate that you probably want
ftp://mirror.cs.wisc.edu/pub/mirrors/ghost/AFPL/gs814/gs814w32.exe
That looks like the latest AFPL version (for non-commercial use only,
but with source available), the version that is also used by GSView.

Since www.gnu.org was down I happened to download the AFPL version
yesterday. Reading the license it seems free enough. You can use it
commercially, there is no restriction on its use as far as I can see. You
can however not redistribute it and charge for it.

- Lennart

[David Kastrup]

Post by Robert Anderson
Subject: Re: Emacs Installer for MS Windows

Post by Benjamin Riefenstahl
In the end you will have to decide for yourself. A quick look into my
sources indicate that you probably want
ftp://mirror.cs.wisc.edu/pub/mirrors/ghost/AFPL/gs814/gs814w32.exe
That looks like the latest AFPL version (for non-commercial use only,
but with source available), the version that is also used by GSView.

Since www.gnu.org was down I happened to download the AFPL version
yesterday. Reading the license it seems free enough. You can use it
commercially, there is no restriction on its use as far as I can
see. You can however not redistribute it and charge for it.

And that's the snag that makes it nonfree. Effectively redistributing
free software is done in Linux distributions, CD collections,
subscriptions, whatever. All of these are done for a fee. If you
order GNU software from the FSF, for example, there is a price tag.
Software that is not free to redistribute, is not useful for our
purposes, since it can't be generally included into free software
offerings.

[Richard Stallman]

Since www.gnu.org was down I happened to download the AFPL version
yesterday. Reading the license it seems free enough.

It does not qualify as a free software license; see
http://www.gnu.org/licenses/license-list.html for the explanation of
why.

See http://www.gnu.org/philosophy/free-sw.html for the criteria for
free software.

[Vinicius Jose Latorre]

Post by Stefan Monnier

Post by Lennart Borgman
2) Some windows specific printing entries to the menus since printing
otherwise tends to be a problem when you start with Emacs on ms windows. I
also remove the unix-related printing entries from the menus because they do
not work or do not work as you expect them to. Of course I make this as
customization options.

What kind of problems?

The printing entries in the menu are not unix-related, it should work
also on
Windows.

Post by Stefan Monnier

Post by Lennart Borgman
If no one has a good objection I will load things from default.el then.
I will do this by loading one file only from default.el to not clutter
default.el.

[ I think changes to the default should be done in Emacs proper rather than
in packages of Emacs. So I basically disagree with all those changes
since they are not intrinsically bound to your package. I might agree to
changing some of those defaults, but I think we should clearly separate
the packaging from the user-preferences. I.e. keep things as vanilla as
possible. ]
- If printing doesn't work right out of the box, it should be fixed directly
in Emacs. Fixing it in your package is a bad solution.

What did you try? Could you give the steps you used to print on Windows?

Have you read the ps-print.el documentation?

[Lennart Borgman]

----- Original Message -----

Post by Lennart Borgman

Post by Lennart Borgman
2) Some windows specific printing entries to the menus since printing
otherwise tends to be a problem when you start with Emacs on ms

windows. I

Post by Lennart Borgman
also remove the unix-related printing entries from the menus

because they do

Post by Lennart Borgman
not work or do not work as you expect them to. Of course I make

this as

Post by Lennart Borgman
customization options.

What kind of problems?
The printing entries in the menu are not unix-related, it should work
also on Windows.

I am sorry, but I do not understand. We must be misunderstanding each other
here. If I just install a vanilla Emacs on ms windows and try "File - Print
Buffer" on the menus I get something like this:

Loading lpr...done
Spooling with options (page headers are not supported)...
direct-print-region-helper: IO error writing c:/PRN: Bad file descriptor

I get similar results if I use "File - PostScript Print Buffer". I guess
this is the reason there are so many advices on printing in the "GNU Emacs
FAQ For Windows 95/98/ME/NT/XP and 2000"
(http://www.gnu.org/software/emacs/windows/big.html#printing-emacs).

MS Windows users expect things to work right out of the box. I struggled
with the advices above but still had big difficulties. I am not quite sure
about this, but as I remember it it still did not work when I finally found
out the network UNC adress (\\server\printer) of the printer I wanted to
use. (I am curious, I will try it again, since so many people seem to insist
it does work if you use the UNC adress and I do not remember exactly now.
Maybe it was some part of it that did not work.)

But at that point I just gave it up, realizing most people just do not want
to make that work.

Post by Lennart Borgman
Have you read the ps-print.el documentation?

I did look at it and I am sure that it does a lot of things that can be
useful for me if it just used the default printer.

- Lennart

[Benjamin Riefenstahl]

Hi Lennart,

Post by Lennart Borgman
I did look at it and I am sure that it does a lot of things that can
be useful for me if it just used the default printer.

In a world that directly uses printer devices, PRN *is* the default
printer. In the days of DOS, some ingenuity went into making that
happen.

But MS has decided very long ago that they don't care about this mode
of operation any more. And so connecting PRN to the default printer
is not automatic.

A program can get the information about the default printer from where
Windows stores it and it can use the device that is indicated there.
As I understand it (I haven't tested it) that is what the latest CVS
code does. Note that these days not all printers actually *have* an
associated device on Windows (e.g. USB and LPR network printers), so
this is still not the most reliable way of doing things.


benny

[Eli Zaretskii]

Date: Thu, 26 Aug 2004 18:52:15 +0200
I am sorry, but I do not understand. We must be misunderstanding each other
here. If I just install a vanilla Emacs on ms windows and try "File - Print
Loading lpr...done
Spooling with options (page headers are not supported)...
direct-print-region-helper: IO error writing c:/PRN: Bad file descriptor

That is exactly the kind of problem that the CVS code solves, AFAIU.

[David Kastrup]

Post by Lennart Borgman
I have been struggling a bit with the installer. First I want to thank you
for all suggestions. I have tried to take a look at most of them.
Further down you will find a summary of my personal view of some different
installers for MS Windows. I decided to use Inno Setup. I had already done
some work with it, it is free, it has good scripting capabilities (which I
needed in this case).
Now I would like some suggestions. I hope you do not mind. First about where
to install Emacs. On ms windows most programs are installed in "c:\program
files\" as I guess you know. I see some alternatives (which I illustrate
A) "c:\program files\emacs\bin\emacs.exe
B) "c:\program files\emacs-21.3\bin\emacs.exe
C) "c:\program files\emacs\emacs\bin\emacs.exe
D) "c:\program files\emacs\emacs-21.3\bin\emacs.exe
Which one would you prefer? What about using "c:\program files"?

Most GNU programs have a concept of a "prefix" that folds out into
bin/lib/var/share subdirectories. So the main idea would be to let
the user specify this "prefix" (for example, when installing into an
existing Cygwin tree) and let the prefix default to
c:\program files\emacs
This would land the executable in choice A) or B).

Post by Lennart Borgman
I include gnuclient and wonder where to put these exe-files.

Same place. On systems where the current copy of Emacs is not
necessarily in the path, invocation-directory is the first choice for
looking for gnuclient.

[Dhruva Krishnamurthy]

On Mon, 23 Aug 2004 21:21:04 +0200, "Lennart Borgman"

Post by Lennart Borgman
Now I would like some suggestions. I hope you do not mind. First about where
to install Emacs. On ms windows most programs are installed in
"c:\program
files\" as I guess you know. I see some alternatives (which I illustrate
A) "c:\program files\emacs\bin\emacs.exe
B) "c:\program files\emacs-21.3\bin\emacs.exe
C) "c:\program files\emacs\emacs\bin\emacs.exe
D) "c:\program files\emacs\emacs-21.3\bin\emacs.exe
Which one would you prefer? What about using "c:\program files"?

Folder names with spaces are always a nightmare in scripts. Can we avoid
this and try to install
directly under "C:/GNU/emacs" or "C:/GNU/emacs-21.3 ".
IMO, many users using GNU Emacs use lot of other GNU software, having a
top level GNU folder might help proper grouping of related tools.

Post by Lennart Borgman
I include gnuclient and wonder where to put these exe-files. Currently I use
a structure like C) and put them in "c:\program files\emacs\w32bin". I also
put a copy of 7za.exe from 7-zip here to be able to unpack tar.gz files.
(With permission from the author of course.)

How about "C:/GNU/bin" as _some_ of the tools or execs are not just
specific to GNU Emacs.

I use the following folder setup and have some of the following
advantages.
Under D:/GNU, I have:
D:/GNU/bin
D:/GNU/info
D:/GNU/emacs-beta
D:/GNU/emacs-rel
D:/GNU/site-lisp

1. GNUclient, GNUserv and other image libraries are in D:/GNU/bin. I
have added this folder into PATH env. Since these files do not get
modified too often, I need not worry during upgrading GNU Emacs.
2. I can selectively add "D:/GNU/emacs-beta/bin" or
"D:/GNU/emacs-rel/bin" in the PATH env. Based on this, the GNUclient
will launch "emacs.exe" for the desired version. With this, I can have
multiple versions of GNU Emacs. May not be useful for a plain user
though.
3. All user specific elisp code goes into D:/GNU/site-lisp, this is
again version independent.
4. With this setup, an upgrade just means, removing the version specific
GNU Emacs folder (and remove it from PATH) and copy a new version folder
(and add it to PATH).
Note:
Adding to PATH could be done like:
GNUEMACSPATH=D:/GNU/bin;D:/GNU/emacs-21.3/bin
PATH=%GNUEMACSPATH%;%PATH%
For an upgrade, you just need to modify the contents of "GNUEMACSPATH"
env. I know it can be difficult to or unwise to modify the PATH env
directly.

with best regards,
dhruva
________________________________________
Dhruva Krishnamurthy
Proud FSF member: #1935
http://schemer.fateback.com/

[Benjamin Riefenstahl]

Hi Dhruva,

Post by Dhruva Krishnamurthy
On Mon, 23 Aug 2004 21:21:04 +0200, "Lennart Borgman"

Post by Lennart Borgman
Which one would you prefer? What about using "c:\program files"?

Folder names with spaces are always a nightmare in scripts.

I'd phrase it differently: Folder names with spaces tend to expose
bugs in shell scripts. As folders like that are rather common on
desktop systems, it's a good idea to install in such a folder, so that
these bugs get smoked out as early as possible.


benny

[Richard Stallman]

The installer needs to be free software, on ethical groups.
Also, it needs to have a GPL-compatible license in order to
combine it with Emacs. The license of Inno Setup qualifies.
The CPL does not.

A side issue:
In hacker terminology, calling something a "win" is a form of praise.
If you wish to praise Microsoft Windows, you're free to do so; but if you
don't, then you might want to think twice about using the term "win32".

[David Kastrup]

Post by Richard Stallman
The installer needs to be free software, on ethical groups.
Also, it needs to have a GPL-compatible license in order to
combine it with Emacs. The license of Inno Setup qualifies.
The CPL does not.
In hacker terminology, calling something a "win" is a form of
praise.

Actually, I am afraid that in hacker terminology, the word has gone
down the drain a bit already. For example, it is not uncommon to
refer to computers running under Windows as "Wintendo" systems to
indicate that they are not suitable for serious use.

[Eli Zaretskii]

Date: Tue, 24 Aug 2004 17:02:41 -0400
The installer needs to be free software, on ethical groups.
Also, it needs to have a GPL-compatible license in order to
combine it with Emacs.

Yes, and that is why I suggested to start with the installer developed
as part of the "GNU Software for MS-Windows and MS-DOS" CD-ROM.
AFAIR, no one responded to that suggestion.

[Lennart Borgman]

Eli, I am sorry for not responding to your previous mail. I noticed it but
thought that this installer propably was of little use now when there are
powerful free installers like Inno available. I also thought that it might
be a bit dated. I should of course have answered anyway.

Do you have a description of this installer somewhere that I can read? Maybe
there are some good ideas that I can still use?

- Lennart



----- Original Message -----
From: "Eli Zaretskii" <***@gnu.org>
To: <***@gnu.org>
Cc: <***@student.lu.se>; <emacs-***@gnu.org>
Sent: Wednesday, August 25, 2004 6:06 AM
Subject: Re: Emacs Installer for MS Windows

Post by Eli Zaretskii

Date: Tue, 24 Aug 2004 17:02:41 -0400
The installer needs to be free software, on ethical groups.
Also, it needs to have a GPL-compatible license in order to
combine it with Emacs.

Yes, and that is why I suggested to start with the installer developed
as part of the "GNU Software for MS-Windows and MS-DOS" CD-ROM.
AFAIR, no one responded to that suggestion.

[Eli Zaretskii]

Date: Wed, 25 Aug 2004 18:21:19 +0200
Eli, I am sorry for not responding to your previous mail. I noticed it but
thought that this installer propably was of little use now when there are
powerful free installers like Inno available. I also thought that it might
be a bit dated.

It might be less powerful and dated, but it's 100% free software
released under the GPL, and it managed to satisfy hundreds of people
who bought the CD-ROM and installed it on every Windows version out
there except XP (which simply didn't exist back then).

So it should be a good starting point.

Do you have a description of this installer somewhere that I can read? Maybe
there are some good ideas that I can still use?

I can simply mail you the code, I have the sources somewhere in my
home directory on gnu.org machines.

[Richard Stallman]

I wrote:

The installer needs to be free software, on ethical groups.

I meant

The installer needs to be free software, on ethical grounds.

[Paul Pogonyshev]

Post by Peter 'Luna' Runestig

Post by David Kastrup

Post by Peter 'Luna' Runestig
Why? Why should "lusers" install new software on a computer?

Because freedom is too important to be contrained to the ranks of
revolutionists and appointed Windows administrators?

By "install new software on a computer", I mean putting software in a
common location, for all users on the computer to use. Surely you don't
suggest that any users should have the abillity to do that?

Any user should be able to install software for his own use, without
affecting the others and without asking the admins.

Paul

[Stefan Monnier]

Post by Paul Pogonyshev
Any user should be able to install software for his own use, without
affecting the others and without asking the admins.

Maybe not "any", but at least normal (i.e. non-admin, non-power users)
users should be able to. Special users like `www', or `news', or `guest'
might be more restricted for security reasons.


Stefan

[Stefan Monnier]

Post by Peter 'Luna' Runestig

Post by Dhruva Krishnamurthy
What ever approach you/anyone writing an Installation program for MS OS
takes, IMO, please make sure we do not have to have _admin_ rights to
install. This is a real stopper. I have found many users giving up on
lot of tools due to this limitation.

Why? Why should "lusers" install new software on a computer?

Why not? If the admin gave them the right to do that (which is the case by
default)?


Stefan


PS: Another request: make sure the installer does not require to agree to
the GPL before installing. You can put a blurb about "this is GPL'd
isn't that grand", but don't put one of those silly "you have to agree
to the licence before I can continue" thingies since the GPL is
irrelevant to the user's right to install and run the software.

[Lennart Borgman]

----- Original Message -----
From: "Stefan Monnier" <***@iro.umontreal.ca>
...

Post by Stefan Monnier

Post by Peter 'Luna' Runestig
Why? Why should "lusers" install new software on a computer?

Why not? If the admin gave them the right to do that (which is the case by
default)?
Stefan
PS: Another request: make sure the installer does not require to agree to
the GPL before installing. You can put a blurb about "this is GPL'd
isn't that grand", but don't put one of those silly "you have to agree
to the licence before I can continue" thingies since the GPL is
irrelevant to the user's right to install and run the software.

An interesting discussion ;-)

Good point. I believe I am beginning to understand why the guys in Redmond
put up the license agreement in such a small window: it has to be there, but
they do not want to disturb. I actually have to read the license I put in
the install kit ;-(

- Lennart

[Stephen J. Turnbull]

Stefan> PS: Another request: make sure the installer does not
Stefan> require to agree to the GPL before installing. You can
Stefan> put a blurb about "this is GPL'd isn't that grand", but
Stefan> don't put one of those silly "you have to agree to the
Stefan> licence before I can continue" thingies since the GPL is
Stefan> irrelevant to the user's right to install and run the
Stefan> software.

If that's true, sections 11 and 12 of the GPL are irrelevant, too?

I've never liked the "'running the program' and 'suing the copyright
holders and distributors' are outside of the scope of this license
[but if you do run the program, despite saying we weren't going to
impose such conditions, we are anyway going to impose the condition
that you not sue us]" wording in Section 0; it belongs in the
Preamble. I hope a reasonable judge would rule that the clear intent
is explanation of the basic scope of a copyright license, not to give
up certain special rights of self-defense that the copyright entails.

However, intentionally omitting this chance to get the user's
agreement just props that door wide open again.

I suspect that there may be legal obligations (eg, the contract with
ETL, and maybe even the assignments) on the part of the FSF to avoid
this.

IANAL, but I hope somebody asks a real one before omitting it.

[David Kastrup]

Post by Stephen J. Turnbull
Stefan> PS: Another request: make sure the installer does not
Stefan> require to agree to the GPL before installing. You can
Stefan> put a blurb about "this is GPL'd isn't that grand", but
Stefan> don't put one of those silly "you have to agree to the
Stefan> licence before I can continue" thingies since the GPL is
Stefan> irrelevant to the user's right to install and run the
Stefan> software.
If that's true, sections 11 and 12 of the GPL are irrelevant, too?

[...]

Post by Stephen J. Turnbull
However, intentionally omitting this chance to get the user's
agreement just props that door wide open again.
I suspect that there may be legal obligations (eg, the contract with
ETL, and maybe even the assignments) on the part of the FSF to avoid
this.
IANAL, but I hope somebody asks a real one before omitting it.

Well, the GPL also has

5. You are not required to accept this License, since you have not
signed it. However, nothing else grants you permission to modify or
distribute the Program or its derivative works. These actions are
prohibited by law if you do not accept this License. Therefore, by
modifying or distributing the Program (or any work based on the
Program), you indicate your acceptance of this License to do so, and
all its terms and conditions for copying, distributing or modifying
the Program or works based on it.

Since the licence itself states you are not required to accept it for
running the program, there is little point in explicitly accepting
that you need not accept the licence.

[Robert Anderson]

--- Original Message ---
From: "Peter 'Luna' Runestig" <***@runestig.com>
To: Dhruva Krishnamurthy <***@dhruva.fastmail.fm>
CC: Lennart Borgman <***@student.lu.se>, Emacs
Devel <emacs-***@gnu.org>
Subject: Re: Emacs Installer for MS Windows

Post by Peter 'Luna' Runestig

Post by Dhruva Krishnamurthy
What ever approach you/anyone writing an Installation program

for MS OS

Post by Peter 'Luna' Runestig

Post by Dhruva Krishnamurthy
takes, IMO, please make sure we do not have to have _admin_

rights to

Post by Peter 'Luna' Runestig

Post by Dhruva Krishnamurthy
install. This is a real stopper. I have found many users

giving up on

Post by Peter 'Luna' Runestig

Post by Dhruva Krishnamurthy
lot of tools due to this limitation.

Why? Why should "lusers" install new software on a computer?
--
PGP Key ID: 0xD07BBE13
Fingerprint: 7B5C 1F48 2997 C061 DE4B 42EA CB99 A35C D07B BE13
AOL Instant Messenger Screen name: PRunestig
Yahoo! Messenger profile name: altberg

So they can use it, perhaps?

Bob

[Berndl, Klaus]

Post by Dhruva Krishnamurthy

Post by Lennart Borgman
A) "c:\program files\emacs\bin\emacs.exe
B) "c:\program files\emacs-21.3\bin\emacs.exe
C) "c:\program files\emacs\emacs\bin\emacs.exe
D) "c:\program files\emacs\emacs-21.3\bin\emacs.exe
Which one would you prefer? What about using "c:\program files"?

Folder names with spaces are always a nightmare in scripts. Can we avoid
this and try to install
directly under "C:/GNU/emacs" or "C:/GNU/emacs-21.3 ".
IMO, many users using GNU Emacs use lot of other GNU software, having a
top level GNU folder might help proper grouping of related tools.

Definitely not... i would really recommend using "program files" because this is THE place where windows-programs are installled for most of the users... at least this should be the default place your installer should recommend because if a user wants it at different place he is able to change this, isn't he? At least i hope so, because any installer which doesn't allow where to install the stuff is quite useless...

Klaus

[Steven Tamm]

GTK is placed inside "c:\program files\common files", while gaim (and
other programs I can find) are placed inside "C:\program files". It's
not a very good standard, but it is a standard. I have found no
trouble when installing emacs in any location. I would recommend
following this convention as the default. The command shell on modern
Win32 systems correctly handles spaces in many situations, and any
scripts written should be able to handle any location, even with
spaces.

As for "C:\GNU". On Mac OS X, a decision was made by Fink team to
create a directory called "/sw" into which all free software is placed.
They did this to maintain a clear separation between the software that
comes with darwin and the software installed by fink. When the system
is upgraded, the fink software remains without being clobbered by any
changes made in darwin (unlike /usr/local). This is a very good idea
for them because the entire directory is controlled by one entity (the
fink software). This argument also applies to cygwin.

Emacs for Win32, on the other hand, is a first class application, not a
suite. It should be treated like another first class application (like
gaim, which also defaults to Program Files). As for scripting, that
will be a tiny fraction of all users, and those can change the
directory. GNUserv uses the registry, by default to

As for personal preference, I would do the following:

%PROGRAM_FILES%\GNU Emacs\bin\emacs.exe
or possibly this, although less desirable since there aren't any
symbolic links
%PROGRAM_FILES%\GNU Emacs\21.3\bin\emacs.exe

I will, of course, change it to c:\emacs whatever the installer does;
but the most "Windows-like" default would be the above.
-Steven

Post by Berndl, Klaus

Post by Dhruva Krishnamurthy

Post by Lennart Borgman
A) "c:\program files\emacs\bin\emacs.exe
B) "c:\program files\emacs-21.3\bin\emacs.exe
C) "c:\program files\emacs\emacs\bin\emacs.exe
D) "c:\program files\emacs\emacs-21.3\bin\emacs.exe
Which one would you prefer? What about using "c:\program files"?

Folder names with spaces are always a nightmare in scripts. Can we avoid
this and try to install
directly under "C:/GNU/emacs" or "C:/GNU/emacs-21.3 ".
IMO, many users using GNU Emacs use lot of other GNU software, having a
top level GNU folder might help proper grouping of related tools.

Definitely not... i would really recommend using "program files"
because this is THE place where windows-programs are installled for
most of the users... at least this should be the default place your
installer should recommend because if a user wants it at different
place he is able to change this, isn't he? At least i hope so, because
any installer which doesn't allow where to install the stuff is quite
useless...
Klaus
_______________________________________________
Emacs-devel mailing list
http://lists.gnu.org/mailman/listinfo/emacs-devel

[David Kastrup]

Post by Steven Tamm
%PROGRAM_FILES%\GNU Emacs\bin\emacs.exe
or possibly this, although less desirable since there aren't any
symbolic links
%PROGRAM_FILES%\GNU Emacs\21.3\bin\emacs.exe

File: efaq, Node: Difference between Emacs and XEmacs, Next: Emacs for MS-DOS, Prev: Current GNU distributions, Up: Finding Emacs and related packages

What is the difference between Emacs and XEmacs (formerly "Lucid Emacs")?
=========================================================================

First of all, they're both GNU Emacs. XEmacs is just as much a later
version of GNU Emacs as the FSF-distributed version. This FAQ refers to
the latest version to be distributed by the FSF as "Emacs," partly
because the XEmacs maintainers now refer to their product using the
"XEmacs" name, and partly because there isn't any accurate way to
differentiate between the two without getting mired in paragraphs of
legalese and history.

Please just use "Emacs" as a name. Anything else would be misleading
in that context.

[Steven Tamm]

Point taken. I guess I should have said "FSF Emacs"?

One problem with the Mac OS X version of Emacs is being able to
distinguish the windowing system/gui used: None (curses), X11, or
Carbon. On my machine I have each version running; and on windows I
have an NT/Win32 and a cygwin (X11) version as well. Should the
installer make explicit which GUI version it is installing?

-Steven

Post by David Kastrup

Post by Steven Tamm
%PROGRAM_FILES%\GNU Emacs\bin\emacs.exe
or possibly this, although less desirable since there aren't any
symbolic links
%PROGRAM_FILES%\GNU Emacs\21.3\bin\emacs.exe

Emacs for MS-DOS, Prev: Current GNU distributions, Up: Finding Emacs
and related packages
What is the difference between Emacs and XEmacs (formerly "Lucid Emacs")?
=======================================================================
==
First of all, they're both GNU Emacs. XEmacs is just as much a later
version of GNU Emacs as the FSF-distributed version. This FAQ refers to
the latest version to be distributed by the FSF as "Emacs," partly
because the XEmacs maintainers now refer to their product using the
"XEmacs" name, and partly because there isn't any accurate way to
differentiate between the two without getting mired in paragraphs of
legalese and history.
Please just use "Emacs" as a name. Anything else would be misleading
in that context.
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum

[Stefan Monnier]

Post by Steven Tamm
Point taken. I guess I should have said "FSF Emacs"?

No, just "Emacs".
"XEmacs" is not "Emacs", just like "train" is not "rain".


Stefan

[Steven Tamm]

My point was not to have an adjective, nor as a comparison to XEmacs.
There is only one Emacs. However, it seems to be a style among many
applications to group by manufacturer. Either with:
"C:\program files\Microsoft Office"
"C:\program files\Microsoft Visual Studio"
"C:\program files\apache group\apache"
"C:\program files\Mozilla Firefox"

Some people on the list may express a preference to do the same thing
either with:
"C:\program files\GNU Emacs" or
"C:\program files\GNU\Emacs" or
"C:\program files\Emacs".
Others may think it's a bad idea. The point was not to distinguish
flavours of Emacs; there is only one Visual Studio and only one
Firefox. It's a stylistic decision that should be made explicitly, as
opposed to being stumbled upon. Microsoft's Installer SDK doesn't
describe what to do (although it is adamant about putting it in
ProgramFiles).

It seems based on the feedback (or is that smackdown) that
%PROGRAM_FILES%\Emacs is the location that causes the least discomfort.

Right?
-Steven

Post by Stefan Monnier

Post by Steven Tamm
Point taken. I guess I should have said "FSF Emacs"?

No, just "Emacs".
"XEmacs" is not "Emacs", just like "train" is not "rain".
Stefan
_______________________________________________
Emacs-devel mailing list
http://lists.gnu.org/mailman/listinfo/emacs-devel

[Stefan]

Post by Steven Tamm
"C:\program files\Microsoft Office"
"C:\program files\Microsoft Visual Studio"
"C:\program files\apache group\apache"
"C:\program files\Mozilla Firefox"

It's a marketing gimmick that I personally despise. But

Post by Steven Tamm
"C:\program files\GNU Emacs" or
"C:\program files\GNU\Emacs" or
"C:\program files\Emacs".

I wouldn't care either way.


Stefan

[Eli Zaretskii]

Date: Tue, 24 Aug 2004 18:02:55 -0700
Some people on the list may express a preference to do the same thing
"C:\program files\GNU Emacs" or
"C:\program files\GNU\Emacs" or
"C:\program files\Emacs".
Others may think it's a bad idea. The point was not to distinguish
flavours of Emacs; there is only one Visual Studio and only one
Firefox. It's a stylistic decision that should be made explicitly, as
opposed to being stumbled upon. Microsoft's Installer SDK doesn't
describe what to do (although it is adamant about putting it in
ProgramFiles).
It seems based on the feedback (or is that smackdown) that
%PROGRAM_FILES%\Emacs is the location that causes the least discomfort.
Right?

Just "Emacs" and "XEmacs" is distinctive enough, I think.

[David Kastrup]

Post by Steven Tamm
My point was not to have an adjective, nor as a comparison to XEmacs.
There is only one Emacs. However, it seems to be a style among many
"C:\program files\Microsoft Office"
"C:\program files\Microsoft Visual Studio"
"C:\program files\apache group\apache"
"C:\program files\Mozilla Firefox"

That's not a grouping by manufacturer (apart from "apache group").
The problem is that those are the proper names: you could not hope to
trademark a generic term like "Office" or "Word" (well, Microsoft is
still keeping up its "Windows" trademark with a somewhat expensive
bully&settle strategy, but that's a bit of an exception).

I'd not expect many people starting to use "Emacs" as a generic term,
however.

Post by Steven Tamm
Some people on the list may express a preference to do the same thing
"C:\program files\GNU Emacs" or
"C:\program files\GNU\Emacs" or
"C:\program files\Emacs".

That leaves no sensible name for XEmacs. The difference between the
two is not GNU and non-GNU, and "GNU XEmacs" would be seriously
misleading to other people.

Post by Steven Tamm
Others may think it's a bad idea.

I do.

Post by Steven Tamm
The point was not to distinguish flavours of Emacs; there is only
one Visual Studio and only one Firefox.

It is their choice how to call their directories.

Post by Steven Tamm
It's a stylistic decision that should be made explicitly, as opposed
to being stumbled upon.

Well, I would not call quoting the Emacs FAQ on this exactly stumbling.

Post by Steven Tamm
It seems based on the feedback (or is that smackdown) that
%PROGRAM_FILES%\Emacs is the location that causes the least
discomfort.
Right?

Right.

[David Kastrup]

Post by Steven Tamm
Point taken. I guess I should have said "FSF Emacs"?

If you really want to get people upset, that is a pretty certain way
to do so. Emacs is Emacs, and the FSF, while being the copyright
holder, is so on behalf of the GNU project and its developers.

If someone chose to forked a version of AUCTeX (of which I am
maintainer) and then somebody suggested that the version that I am
maintaining and distributing should be renamed to "Kastrup AUCTeX", I
would be offended. Because the project is not just a private pet of
mine.

The proper directory name for Emacs is usually "emacs" on Unix-like
systems (which are traditionally all-lowercase). As a subdirectory of
"C:\My Programs" however, "Emacs" would appear more appropriate.

There is no reason to call the directory anything else, since no other
program calls itself "Emacs". The only possible consideration might
be appending the version number to better facilitate parallel
installations of multiple Emacsen. However, I would advise against
making this the default: it only means that it becomes harder to find
the currently "canonical" Emacs on a computer. If somebody wants to
install parallel versions, he can easily enough change the default
name.

Post by Steven Tamm
One problem with the Mac OS X version of Emacs is being able to
distinguish the windowing system/gui used: None (curses), X11, or
Carbon. On my machine I have each version running; and on windows I
have an NT/Win32 and a cygwin (X11) version as well. Should the
installer make explicit which GUI version it is installing?

It should display it, but I don't think it should be reflected in the
proposed default name of the directory.

[Lennart Borgman]

Post by David Kastrup

Post by Steven Tamm
One problem with the Mac OS X version of Emacs is being able to
distinguish the windowing system/gui used: None (curses), X11, or
Carbon. On my machine I have each version running; and on windows I
have an NT/Win32 and a cygwin (X11) version as well. Should the
installer make explicit which GUI version it is installing?

It should display it, but I don't think it should be reflected in the
proposed default name of the directory.

Excuse me, but what should be displayed? Should the installation say that it
is installing the NT/Win32 version?

- Lennart

[David Kastrup]

Post by Lennart Borgman

Post by David Kastrup

Post by Steven Tamm
One problem with the Mac OS X version of Emacs is being able to
distinguish the windowing system/gui used: None (curses), X11, or
Carbon. On my machine I have each version running; and on windows I
have an NT/Win32 and a cygwin (X11) version as well. Should the
installer make explicit which GUI version it is installing?

It should display it, but I don't think it should be reflected in the
proposed default name of the directory.

Excuse me, but what should be displayed? Should the installation say that it
is installing the NT/Win32 version?

Yes.

[Richard Stallman]

First of all, they're both GNU Emacs. XEmacs is just as much a later
version of GNU Emacs as the FSF-distributed version.

It isn't a later version, it it is a fork.
Aside from that, this statement is accurate.

[David Kastrup]

Post by David Kastrup
First of all, they're both GNU Emacs. XEmacs is just as much a later
version of GNU Emacs as the FSF-distributed version.
It isn't a later version, it it is a fork.

"as much a later version as" is pretty much the same as "fork".
Anyway, that was a quote from the Emacs FAQ as distributed with Emacs.
I would prefer not using the word "fork" there because of its negative
associations. While the Emacs/XEmacs split certainly _is_ not
positive, there is really nothing to be gained anymore from stoking
the flames.

Post by David Kastrup
Aside from that, this statement is accurate.

It better be, as we are distributing it with Emacs. I find it a bit
contorted myself, but I don't have a better suggestion to make that
would seem worth the effort of discussion and polishing.

[Richard Stallman]

Post by David Kastrup
First of all, they're both GNU Emacs. XEmacs is just as much a later
version of GNU Emacs as the FSF-distributed version.
It isn't a later version, it it is a fork.

"as much a later version as" is pretty much the same as "fork".

I misread it until now. Now I agree, it is correct, but since it is
hard to read, clearer wording would be good.

[David Kastrup]

Post by David Kastrup

Post by David Kastrup
First of all, they're both GNU Emacs. XEmacs is just as much a later
version of GNU Emacs as the FSF-distributed version.
It isn't a later version, it it is a fork.

"as much a later version as" is pretty much the same as "fork".
I misread it until now. Now I agree, it is correct, but since it is
hard to read, clearer wording would be good.

How about: XEmacs is a descendant of the same GNU Emacs source code
from which the FSF-distributed version is derived.

[Kim F. Storm]

Post by David Kastrup

Post by David Kastrup

Post by David Kastrup
First of all, they're both GNU Emacs. XEmacs is just as much a later
version of GNU Emacs as the FSF-distributed version.
It isn't a later version, it it is a fork.

"as much a later version as" is pretty much the same as "fork".
I misread it until now. Now I agree, it is correct, but since it is
hard to read, clearer wording would be good.

How about: XEmacs is a descendant of the same GNU Emacs source code
from which the FSF-distributed version is derived.

Not much clearer imo.

What about:

Emacs and XEmacs both descend from the same code base, but development
of the two separated many years ago.

[David Kastrup]

Post by Kim F. Storm
Emacs and XEmacs both descend from the same code base, but
development of the two separated many years ago.

The purpose was to explain why GNU Emacs/XEmacs is not a correct
naming pair. That's what this was all about.

Ok: Emacs and XEmacs both descend from an earlier common version of
GNU Emacs.

Whatever. I don't think that the single sentence is really that
important. Richard wanted to have a go at it. Once he is finished, I
might be tempted to take a look at the whole entry, anyway.