Emacs Installer for MS Windows

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

Re: Emacs Installer for MS Windows

[Dhruva Krishnamurthy]

On Tue, 3 Aug 2004 00:17:45 +0200, "Lennart Borgman"
<lennart.borgman.073@student.lu.se> said:
> 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/

Re: Emacs Installer for MS Windows

[Peter 'Luna' Runestig]

On 2004-08-03 06:41, Dhruva Krishnamurthy wrote:
> 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?

-- 
Peter 'Luna' Runestig (fd. Altberg), Sweden <peter@runestig.com>
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

Re: Emacs Installer for MS Windows

[David Kastrup]

"Peter 'Luna' Runestig" <peter@runestig.com> writes:

> On 2004-08-03 06:41, Dhruva Krishnamurthy wrote:
> > 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.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Emacs Installer for MS Windows

[Peter 'Luna' Runestig]

On 2004-08-04 22:55, David Kastrup wrote:
> "Peter 'Luna' Runestig" <peter@runestig.com> writes:
>> 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 (fd. Altberg), Sweden <peter@runestig.com>
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

Re: Emacs Installer for MS Windows

[Peter 'Luna' Runestig]

On 2004-08-05 08:51, Peter 'Luna' Runestig wrote:

> On 2004-08-04 22:55, David Kastrup wrote:
>> "Peter 'Luna' Runestig" <peter@runestig.com> writes:
>>> 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"


-- 
Peter 'Luna' Runestig (fd. Altberg), Sweden <peter@runestig.com>
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

Re: Emacs Installer for MS Windows

[David Kastrup]

"Peter 'Luna' Runestig" <peter@runestig.com> writes:

> On 2004-08-04 22:55, David Kastrup wrote:
> > "Peter 'Luna' Runestig" <peter@runestig.com> writes:
> >> 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.

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

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Emacs Installer for MS Windows

[Dhruva Krishnamurthy]

On Thu, 05 Aug 2004 08:51:00 +0200, "Peter 'Luna' Runestig"
<peter@runestig.com> said:
> On 2004-08-04 22:55, David Kastrup wrote:
> > "Peter 'Luna' Runestig" <peter@runestig.com> writes:
> >> 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/

Re: Emacs Installer for MS Windows

[Lennart Borgman]

----- Original Message ----- 
From: "Dhruva Krishnamurthy" <list@dhruva.fastmail.fm>
> 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.)

>  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

Re: Emacs Installer for MS Windows

[Dhruva Krishnamurthy]

Hello,

On Thu, 5 Aug 2004 16:27:51 +0200, "Lennart Borgman"
<lennart.borgman.073@student.lu.se> said:
> >  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.

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

Re: Emacs Installer for MS Windows

[Richard Stallman]

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

Re: Emacs Installer for MS Windows

[David Kastrup]

Richard Stallman <rms@gnu.org> writes:

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

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Emacs Installer for MS Windows

[Peter 'Luna' Runestig]

On 2004-08-06 15:56, David Kastrup wrote:
> 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 (fd. Altberg), Sweden <peter@runestig.com>
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

Re: Emacs Installer for MS Windows

[Peter 'Luna' Runestig]

On 2004-08-06 19:07, Peter 'Luna' Runestig wrote:
> 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
-- 
Peter 'Luna' Runestig (fd. Altberg), Sweden <peter@runestig.com>
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

Re: Emacs Installer for MS Windows

[Frank Schmitt]

Richard Stallman <rms@gnu.org> writes:

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

-- 
Did you ever realize how much text fits in eighty columns? If you now consider
that a signature usually consists of up to four lines, this gives you enough
space to spread a tremendous amount of information with your messages. So seize
this opportunity and don't waste your signature with bullshit nobody will read.

Re: Emacs Installer for MS Windows

[Eli Zaretskii]

> From: Richard Stallman <rms@gnu.org>
> 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.

Re: Emacs Installer for MS Windows

[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

Re: Emacs Installer for MS Windows

[Stefan Monnier]

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

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

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

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

> I have found it most easy to start up these scripts in site-lisp/default.el.

I'd recommend site-start.el instead.

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

> 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

Re: Emacs Installer for MS Windows

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

> So the choice between those depends on how well it deals with upgrades.
...
> 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.

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

> I'd recommend site-start.el instead.
>
> > 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

Re: Emacs Installer for MS Windows

[Stefan Monnier]

> 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

Re: Emacs Installer for MS Windows

[Lennart Borgman]

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

> 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

Re: Emacs Installer for MS Windows

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

[ 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

Re: Emacs Installer for MS Windows

[Lennart Borgman]

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


> > 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 ..
> > 3) I also offer some keyboard tweaks (CUA-mode, swbuff.el tighed to
C-tab) ..
> > 4) recentf.el are also added, most ms windows programs has something
like..
>
> > 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?

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

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

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

See above.

> 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

Re: Emacs Installer for MS Windows

[Stefan]

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

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

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

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

Re: Emacs Installer for MS Windows

[Lennart Borgman]

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


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

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

Re: Emacs Installer for MS Windows

[David Kastrup]

"Lennart Borgman" <lennart.borgman.073@student.lu.se> writes:

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

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Emacs Installer for MS Windows

[Stefan Monnier]

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

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

Re: Emacs Installer for MS Windows

[Lennart Borgman]

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


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

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

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

> 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"))

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

Re: Emacs Installer for MS Windows

[Eli Zaretskii]

> From: "Lennart Borgman" <lennart.borgman.073@student.lu.se>
> 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
> 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.

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.

Re: Emacs Installer for MS Windows

[Peter 'Luna' Runestig]

On 2004-08-25 06:15, Eli Zaretskii wrote:
[...]
> 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.

-- 
Peter 'Luna' Runestig (fd. Altberg), Sweden <peter@runestig.com>
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

Re: Emacs Installer for MS Windows

[Lennart Borgman]

----- Original Message ----- 
From: "Peter 'Luna' Runestig" <peter@runestig.com>
> If you put this in .emacs:
> 
> (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

Re: Emacs Installer for MS Windows

[Eli Zaretskii]

> Date: Wed, 25 Aug 2004 09:09:12 +0200
> From: "Peter 'Luna' Runestig" <peter@runestig.com>
> 
> 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

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.

Re: Emacs Installer for MS Windows

[Vinicius Jose Latorre]

 > From: "Eli Zarestkii" <eliz@gnu.org>
 >
 > >From: "Lennart Borgman" <lennart.borgman.073@student.lu.se>
 > >> 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 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.
 >
 >
 > 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.


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

Re: Emacs Installer for MS Windows

[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 ----- 
From: "Vinicius Jose Latorre" <viniciusjl@ig.com.br>
>  > >From: "Lennart Borgman" <lennart.borgman.073@student.lu.se>
>  > >> 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?

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

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

Re: Emacs Installer for MS Windows

[Vinicius Jose Latorre]

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

Re: Emacs Installer for MS Windows

[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

Re: Emacs Installer for MS Windows

[Gian Uberto Lauri]

>>>>> "VJL" == Vinicius Jose Latorre <viniciusjl@ig.com.br> writes:

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" )

-- 
 /\            ___
/___/\__|_|\_|__|___Gian Uberto Lauri_____________________
  //--\ | | \|  |   Integralista GNUslamico, fancazzista 
\/                  e coltivatore diretto di software

Re: Emacs Installer for MS Windows

[Lennart Borgman]

----- Original Message ----- 
From: "Gian Uberto Lauri" <GianUberto.Lauri@eng.it>


> >>>>> "VJL" == Vinicius Jose Latorre <viniciusjl@ig.com.br> writes:
>
> 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

Re: Emacs Installer for MS Windows

[Vinicius Jose Latorre]

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

Re: Emacs Installer for MS Windows

[Stefan Monnier]

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

Re: Emacs Installer for MS Windows

[Gian Uberto Lauri]

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

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

-- 
 /\            ___
/___/\__|_|\_|__|___Gian Uberto Lauri_____________________
  //--\ | | \|  |   Integralista GNUslamico e fancazzista 
\/

Re: Emacs Installer for MS Windows

[Lennart Borgman]

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


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

Re: Emacs Installer for MS Windows

[Benjamin Riefenstahl]

Hi Lennart,


"Lennart Borgman" <lennart.borgman.073@student.lu.se> writes:
> 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

Re: Emacs Installer for MS Windows

[Lennart Borgman]

----- Original Message ----- 
From: "Benjamin Riefenstahl" <Benjamin.Riefenstahl@epost.de>

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

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

> 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

Re: Emacs Installer for MS Windows

[Benjamin Riefenstahl]

Hi Lennart,


"Lennart Borgman" <lennart.borgman.073@student.lu.se> writes:
> 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.


Benjamin Riefenstahl wrote:
>> [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

Re: Emacs Installer for MS Windows

[Stefan Monnier]

>   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

Re: Emacs Installer for MS Windows

[Benjamin Riefenstahl]

Hi Stefan,

Stefan Monnier <monnier@iro.umontreal.ca> writes:
>>   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

Re: Emacs Installer for MS Windows

[Lennart Borgman]

----- Original Message ----- 
From: "Benjamin Riefenstahl" <Benjamin.Riefenstahl@epost.de>


> 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

Re: Emacs Installer for MS Windows

[Gian Uberto Lauri]

>>>>> "LB" == Lennart Borgman <lennart.borgman.073@student.lu.se> writes:

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

-- 
 /\            ___
/___/\__|_|\_|__|___Gian Uberto Lauri_____________________
  //--\ | | \|  |   Integralista GNUslamico, fancazzista 
\/                  e coltivatore diretto di software

Re: Emacs Installer for MS Windows

[Benjamin Riefenstahl]

Hi Lennart,


"Lennart Borgman" <lennart.borgman.073@student.lu.se> writes:
> 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.

> 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

Re: Emacs Installer for MS Windows

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

Re: Emacs Installer for MS Windows

[Lennart Borgman]

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


> 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

Re: Emacs Installer for MS Windows

[David Kastrup]

"Lennart Borgman" <lennart.borgman.073@student.lu.se> writes:

> From: "Benjamin Riefenstahl" <Benjamin.Riefenstahl@epost.de>
> To: "Lennart Borgman" <lennart.borgman.073@student.lu.se>
> Cc: "Emacs Devel" <emacs-devel@gnu.org>
> Subject: Re: Emacs Installer for MS Windows
> 
> > 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.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Emacs Installer for MS Windows

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

Re: Emacs Installer for MS Windows

[Lennart Borgman]

----- Original Message ----- 
From: "Gian Uberto Lauri" <GianUberto.Lauri@eng.it>


> 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

Re: Emacs Installer for MS Windows

[Lennart Borgman]

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


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

Re: Emacs Installer for MS Windows

[Vinicius Jose Latorre]

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


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

Re: Emacs Installer for MS Windows

[Lennart Borgman]

----- Original Message ----- 
From: "Vinicius Jose Latorre" <viniciusjl@ig.com.br>

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

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.

> 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

Re: Emacs Installer for MS Windows

[Eli Zaretskii]

> From: "Lennart Borgman" <lennart.borgman.073@student.lu.se>
> 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
> 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

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

Re: Emacs Installer for MS Windows

[Benjamin Riefenstahl]

Hi Lennart,


"Lennart Borgman" <lennart.borgman.073@student.lu.se> writes:
> 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

Re: Emacs Installer for MS Windows

[David Kastrup]

"Lennart Borgman" <lennart.borgman.073@student.lu.se> writes:

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

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

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

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Emacs Installer for MS Windows

[Dhruva Krishnamurthy]

On Mon, 23 Aug 2004 21:21:04 +0200, "Lennart Borgman"
<lennart.borgman.073@student.lu.se> said:
> 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"?

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.

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

Re: Emacs Installer for MS Windows

[Benjamin Riefenstahl]

Hi Dhruva,


> On Mon, 23 Aug 2004 21:21:04 +0200, "Lennart Borgman"
> <lennart.borgman.073@student.lu.se> said:
>> Which one would you prefer? What about using "c:\program files"?

"Dhruva Krishnamurthy" <list@dhruva.fastmail.fm> writes:
> 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

Re: Emacs Installer for MS Windows

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

Re: Emacs Installer for MS Windows

[David Kastrup]

Richard Stallman <rms@gnu.org> writes:

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

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.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Emacs Installer for MS Windows

[Eli Zaretskii]

> From: Richard Stallman <rms@gnu.org>
> Date: Tue, 24 Aug 2004 17:02:41 -0400
> Cc: emacs-devel@gnu.org
> 
> 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.

Re: Emacs Installer for MS Windows

[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" <eliz@gnu.org>
To: <rms@gnu.org>
Cc: <lennart.borgman.073@student.lu.se>; <emacs-devel@gnu.org>
Sent: Wednesday, August 25, 2004 6:06 AM
Subject: Re: Emacs Installer for MS Windows


> > From: Richard Stallman <rms@gnu.org>
> > Date: Tue, 24 Aug 2004 17:02:41 -0400
> > Cc: emacs-devel@gnu.org
> >
> > 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.
>

Re: Emacs Installer for MS Windows

[Eli Zaretskii]

> From: "Lennart Borgman" <lennart.borgman.073@student.lu.se>
> 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.

Re: Emacs Installer for MS Windows

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

Re: Emacs Installer for MS Windows

[Paul Pogonyshev]

Peter 'Luna' Runestig wrote:
> On 2004-08-04 22:55, David Kastrup wrote:
> > "Peter 'Luna' Runestig" <peter@runestig.com> writes:
> >> 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

Re: Emacs Installer for MS Windows

[Stefan Monnier]

> 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

Re: Emacs Installer for MS Windows

[Stefan Monnier]

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

Re: Emacs Installer for MS Windows

[Lennart Borgman]

----- Original Message ----- 
From: "Stefan Monnier" <monnier@iro.umontreal.ca>
...
> > 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

Re: Emacs Installer for MS Windows

[Stephen J. Turnbull]

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

    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.

-- 
Institute of Policy and Planning Sciences     http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba                    Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
               Ask not how you can "do" free software business;
              ask what your business can "do for" free software.

Re: Emacs Installer for MS Windows

[David Kastrup]

"Stephen J. Turnbull" <stephen@xemacs.org> writes:

> >>>>> "Stefan" == Stefan Monnier <monnier@iro.umontreal.ca> writes:
> 
>     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?

[...]

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

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Emacs Installer for MS Windows

[Robert Anderson]

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

>On 2004-08-03 06:41, Dhruva Krishnamurthy wrote:
>> 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?
>
>-- 
>Peter 'Luna' Runestig (fd. Altberg), Sweden <peter@runestig.com>
>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

RE: Emacs Installer for MS Windows

[Berndl, Klaus]

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

Re: Emacs Installer for MS Windows

[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

On Aug 24, 2004, at 12:04 AM, Berndl, Klaus wrote:

>>> 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
> Emacs-devel@gnu.org
> http://lists.gnu.org/mailman/listinfo/emacs-devel

Re: Emacs Installer for MS Windows

[David Kastrup]

Steven Tamm <steventamm@mac.com> writes:

> 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

    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.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Emacs Installer for MS Windows

[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

On Aug 24, 2004, at 11:08 AM, David Kastrup wrote:

> Steven Tamm <steventamm@mac.com> writes:
>
>> 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
>
>     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.
>
> -- 
> David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Emacs Installer for MS Windows

[Stefan Monnier]

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

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


        Stefan

Re: Emacs Installer for MS Windows

[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

On Aug 24, 2004, at 2:35 PM, Stefan Monnier wrote:

>> 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
> Emacs-devel@gnu.org
> http://lists.gnu.org/mailman/listinfo/emacs-devel

Re: Emacs Installer for MS Windows

[Stefan]

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

> "C:\program files\GNU Emacs" or
> "C:\program files\GNU\Emacs" or
> "C:\program files\Emacs".

I wouldn't care either way.


        Stefan

Re: Emacs Installer for MS Windows

[Eli Zaretskii]

> From: Steven Tamm <steventamm@mac.com>
> Date: Tue, 24 Aug 2004 18:02:55 -0700
> 
> 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?

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

Re: Emacs Installer for MS Windows

[David Kastrup]

Steven Tamm <steventamm@mac.com> writes:

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

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.

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

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.

> Others may think it's a bad idea.

I do.

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

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

> 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, Kriemhildstr. 15, 44793 Bochum

Re: Emacs Installer for MS Windows

[David Kastrup]

Steven Tamm <steventamm@mac.com> writes:

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

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

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Emacs Installer for MS Windows

[Lennart Borgman]

From: "David Kastrup" <dak@gnu.org>
> > 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

Re: Emacs Installer for MS Windows

[David Kastrup]

"Lennart Borgman" <lennart.borgman.073@student.lu.se> writes:

> From: "David Kastrup" <dak@gnu.org>
> > > 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.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Emacs Installer for MS Windows

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

Re: Emacs Installer for MS Windows

[David Kastrup]

Richard Stallman <rms@gnu.org> writes:

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

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

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Emacs Installer for MS Windows

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

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

Re: Emacs Installer for MS Windows

[David Kastrup]

Richard Stallman <rms@gnu.org> writes:

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

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Emacs Installer for MS Windows

[Kim F. Storm]

David Kastrup <dak@gnu.org> writes:

> Richard Stallman <rms@gnu.org> writes:
> 
> >     > 	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.

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: Emacs Installer for MS Windows

[David Kastrup]

storm@cua.dk (Kim F. Storm) writes:

> What about:
> 
> 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.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum