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 upgrad
> "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 sour
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 renam
> 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 inclu
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
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 a
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 t
> "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, Uni
> 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 mo
[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 tha
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 v
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
> f
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
> "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
> "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 Zam
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
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
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.
O
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 waitin
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 re
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 th
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:
> 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:
> 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 nam
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 c
> "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 t
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 wor
"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 emacs2
[CC trimmed to ]
[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
from both?
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 mysel
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
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 t
32 matches
Mail list logo
