Manoj == Manoj Srivastava [EMAIL PROTECTED] writes:
Manoj Hi,
Christian == Christian Lynbech [EMAIL PROTECTED] writes:
Christian I am not quite so pessimistic about the possibilities of
Christian recompiling installed elisp files.
Manoj Please, people, do download the sources for tm and
Two further small reasons against install time .el compilation of large
packages:
1. I have to install .el sources even when I don't need them.
2. Slow installation.
The first is a problem on computers with limited disk space (e.g. my
laptop).
The second is the problem when I perform major
Rob == Rob Browning [EMAIL PROTECTED] (and others) writes:
Rob Think multi-user system.
Point taken. I was thinking in singleuser system terms.
---+--
Christian Lynbech | Computer Science Department, University
I am not quite so pessimistic about the possibilities of recompiling
installed elisp files.
I see three situations where makefile do special things in order to
compile elisp files:
1) generating/editing .el files (gnats and tm are examples of this) at
build-time. This is not a problem since
Christian Lynbech [EMAIL PROTECTED] writes:
1) generating/editing .el files (gnats and tm are examples of this) at
build-time. This is not a problem since the generated .el file is
installed as part of the .deb file.
This is a problem if these packages need to work with both emacs and
Hi,
Christian == Christian Lynbech [EMAIL PROTECTED] writes:
Christian I am not quite so pessimistic about the possibilities of
Christian recompiling installed elisp files.
Please, people, do download the sources for tm and compile a
local copy before you display such unwarranted
I've had a look at all the current packages, details are below (some
programs are probably fine). I think most of these packages should be
fixed is someway - either:
depending on emacs|xemacs
description includes does not work with Xemacs
description includes already included with
Brian White [EMAIL PROTECTED] writes:
Is the emacs package being renamed into emacs19? (I saw several
mentions of that name.) If so, could not both emacs19 and xemacsnn both
Provides: emacs?
The new emacs package is going to be named emacs20. The older one may
or may not be renamed to
Sten Anderson [EMAIL PROTECTED] writes:
If elisp files should be compiled in a postinst script, then which
postint script should do it?
It should just be handled the same way as the menu package. It'll
usually be the postinst of the package installing the .el files. All
of these packages
Rob Browning [EMAIL PROTECTED] writes:
It should just be handled the same way as the menu package.
You are right, it might be possible. You would know that better than
me anyway. But I don't like the idea because it is unnecessary. Why
should a resource-hungry emacs compilation be executed
Sten Anderson [EMAIL PROTECTED] writes:
You are right, it might be possible. You would know that better than
me anyway. But I don't like the idea because it is unnecessary. Why
should a resource-hungry emacs compilation be executed just to
install dpkg-dev? Is it really that important that
Rob Browning [EMAIL PROTECTED] writes:
OK, I haven't investigated the compilation resource requirements that
thoroughly [1],
Well, neither have I, so you are excused :-)
[1] Though is it really that big a deal as long as it gets forked off
to the background like the TeX or manpage
Sten Anderson [EMAIL PROTECTED] writes:
Imagine the initial dselect session. A zillion packages with elisp
files are being installed simultaneously with one or two emacsen...
No, you'd want to do it like the menu package. If I understand
correctly, menu forks off into the background waiting
Hi,
Also consider the fact that all maintainers may not have
enough resources to have all possible flavours of Emacsen on their
machines (Xemacs19, Xemacs20, emacs19, emacs20, emacs20-no-mule,
Xemacs-no-mule, ...), and keep track of which versions were elc
compatible anyway.
I think the number one question we need to address is whether we want
to support running Xemacs and GNU emacs at the *same* time.
If we do not, it becomes more difficult for users to test out the
other, but it becomes much easier to maintain the emacs setup. I do
not believe that one can sensibly
Rob Browning [EMAIL PROTECTED] writes:
Sten Anderson [EMAIL PROTECTED] writes:
You are right, it might be possible. You would know that better than
me anyway. But I don't like the idea because it is unnecessary. Why
should a resource-hungry emacs compilation be executed just to
install
CL == Christian Lynbech on satellite [EMAIL PROTECTED] writes:
CL: I think the number one question we need to address is whether we
CL: want to support running Xemacs and GNU emacs at the *same* time.
Of course we want. There are some *multiuser* Debian machines. :-)
Milan Zamazal
MS == Manoj Srivastava [EMAIL PROTECTED] writes:
MS: Hi, Also consider the fact that all maintainers may not have
MS: enough resources to have all possible flavours of Emacsen on
MS: their machines (Xemacs19, Xemacs20, emacs19, emacs20,
MS: emacs20-no-mule, Xemacs-no-mule, ...),
Hi,
Arto == Arto Astala [EMAIL PROTECTED] writes:
Arto How about rigging emacsen so that when they start they will
Arto compile these? It may even come as side effect of your scheme
Arto already?
I rarely need to run Emacs as root, so this will not work for
me (apart from being ugly; my
From: Milan Zamazal [EMAIL PROTECTED]
Subject: Re: Taking over production of emacs20 package.
Date: 17 Dec 1997 13:37:49 +0100
What I would prefer as a user is to have multiple packages:
foo-el.deb
foo-elc-emacs.deb
foo-elc-xemacs.deb
foo-elc-whateveremacs.deb
...
In debian
Manoj Srivastava [EMAIL PROTECTED] writes:
Also consider the fact that all maintainers may not have
enough resources to have all possible flavours of Emacsen on their
machines (Xemacs19, Xemacs20, emacs19, emacs20, emacs20-no-mule,
Xemacs-no-mule, ...), and keep track of which
[EMAIL PROTECTED] (Christian Lynbech on satellite) writes:
I think the number one question we need to address is whether we want
to support running Xemacs and GNU emacs at the *same* time.
The answer is if it's not an unbelievable technical obstacle, then
yes, we do.
I do not believe that
I think the number one question we need to address is whether we want
to support running Xemacs and GNU emacs at the *same* time.
Yes, we do want to support running both Emacsen. I don't see how
dropping one for the other can even be considered a viable option.
If we do not, it becomes more
Mark recently informed me that he'd accepted my offer to work on the
new emacs20 package. I just wanted to let everyone know that I was
getting started. I'd like to get something out very soon, but the
holidays may interfere a little.
Feel free to let me know if you have suggestions about how
Rob Browning [EMAIL PROTECTED] writes:
Feel free to let me know if you have suggestions about how this
package should be handled. I'm planning to cooperate with the xemacs
and emacs (19) package maintainers to make sure we support the
simultaneous installation of all three packages.
I am
Mark recently informed me that he'd accepted my offer to work on the
new emacs20 package. I just wanted to let everyone know that I was
getting started. I'd like to get something out very soon, but the
holidays may interfere a little.
I had already offered to package up emacs20
[CC trimmed to debian-devel]
[Raul Miller]
Hmm.. seems like XEmacs should Provide: auctex. I can't see any
formal problem if auctex is installed as a separate package as
well... [Why someone would want to is beyond me.]
What if you have Xemacs *and* Emacs installed, and want to use auctex
Adam P. Harris [EMAIL PROTECTED] writes:
What if you have Xemacs *and* Emacs installed, and want to use auctex
from both?
My suggestion would be that whichever package provides auctex, whether
it's xemacs or a separate package, would register the .el files
somehow so that when say emacs20 is
Adam P. Harris [EMAIL PROTECTED] wrote:
What if you have Xemacs *and* Emacs installed, and want to use auctex
from both?
Last time (a couple weeks ago) I tried selecting both xemacs and emacs,
I found that they conflicted.
--
Raul
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word
Raul == Raul Miller [EMAIL PROTECTED] writes:
Raul Hmm.. seems like XEmacs should Provide: auctex. I can't see
Raul any formal problem if auctex is installed as a separate
Raul package as well... [Why someone would want to is beyond
Raul me.]
There's support for that in
On Tue, Dec 16, 1997 at 12:01:28PM +0500, Adam P. Harris wrote:
[You (Sten Anderson)]
I am not a developer, but I have a few comments.
When I run dselect, I see some Emacs packages as seperate deb
packages, e.g. auctex. Now, I prefer XEmacs, which includes auctex,
but how could I know
Rob Browning [EMAIL PROTECTED] writes:
For .el files like debian-changelog-mode.el that are generic enough
elisp that they should work with any emacs (19, 20, or x) we need a
shared directory or something. The only problem with this is that
when the files are byte-compiled there's a naming
32 matches
Mail list logo
