[ELPA] tramp-theme.el

[ELPA] tramp-theme.el

[Michael Albinus]

Hi,

I have written an initial version of tramp-theme.el. It is a
customization theme, which allows to decorate buffers dynamically,
depending on default-directory.

Any objections to add this to GNU ELPA?

Best regards, Michael.

Re: [ELPA] tramp-theme.el

[Marcin Borkowski]

On 2016-02-15, at 16:50, Michael Albinus <michael.albinus@gmx.de> wrote:

> Hi,
>
> I have written an initial version of tramp-theme.el. It is a
> customization theme, which allows to decorate buffers dynamically,
> depending on default-directory.

Wow, cool idea!

Would it be possible to e.g. color dired buffers displaying removable
media in some specific way?

> Best regards, Michael.

Best,

-- 
Marcin Borkowski
http://octd.wmi.amu.edu.pl/en/Marcin_Borkowski
Faculty of Mathematics and Computer Science
Adam Mickiewicz University

Re: [ELPA] tramp-theme.el

[Michael Albinus]

Marcin Borkowski <mbork@mbork.pl> writes:

Hi Marcin,

> Would it be possible to e.g. color dired buffers displaying removable
> media in some specific way?

No, not in the current implementation. It adds the remote host name to
the mode line, and it shows it in inverse when the remote user is
root. The latter one is configurable; you could use different background
colors for different hosts, for example.

But there's always room for improvement.

> Best,

Best regards, Michael.

Re: [ELPA] tramp-theme.el

[Stefan Reichör]

Hallo Michael,

I would like such functionality be part of tramp/Emacs.

As a user I really don't like that a lot of functionality is now moved to ELPA.
When I install a new emacs, I have to re-install also all needed
packages from ELPA.

It would be so much easier when all the batteries in emacs are still included.

This is not only related to tramp.

Am I the only one on this list with these feelings?


Stefan.

> Marcin Borkowski <mbork@mbork.pl> writes:
>
> Hi Marcin,
>
>> Would it be possible to e.g. color dired buffers displaying removable
>> media in some specific way?
>
> No, not in the current implementation. It adds the remote host name to
> the mode line, and it shows it in inverse when the remote user is
> root. The latter one is configurable; you could use different background
> colors for different hosts, for example.
>
> But there's always room for improvement.
>
>> Best,
>
> Best regards, Michael.

Re: [ELPA] tramp-theme.el

[John Wiegley]

>>>>> Stefan Reichör <stefan@xsteve.at> writes:

> As a user I really don't like that a lot of functionality is now moved to
> ELPA. When I install a new emacs, I have to re-install also all needed
> packages from ELPA.
>
> It would be so much easier when all the batteries in emacs are still
> included.

The future plan is to move even more things into ELPA. However, parts of ELPA
will be included in future Emacs tarballs, so your batteries will actually be
there in that future.

So, rather than asking whether things can move back into Emacs, the better
question is: how should we proceed with our plan to deeply integrate ELPA, so
questions like this are resolved in passing. We've had some progress in this
direction, but there are still a few matters of process to resolve.

-- 
John Wiegley                  GPG fingerprint = 4710 CF98 AF9B 327B B80F
http://newartisans.com                          60E1 46C4 BD1A 7AC1 4BA2

Re: [ELPA] tramp-theme.el

[Alexis]

Stefan Reichör <stefan@xsteve.at> writes:

> I would like such functionality be part of tramp/Emacs.
>
> As a user I really don't like that a lot of functionality is now 
> moved to ELPA.  When I install a new emacs, I have to re-install 
> also all needed packages from ELPA.
>
> It would be so much easier when all the batteries in emacs are 
> still included.
>
> This is not only related to tramp.
>
> Am I the only one on this list with these feelings?

My guess is, probably not. :-) i certainly think it's a very 
reasonable preference! My own preference, however, is for /more/ 
things to be moved to GELPA, so that i have more control over what 
is installed in my Emacs.

Having said that, i've got the impression that there might be some 
sort of plan for each stable release of GNU Emacs to come in two 
flavours: one that doesn't come bundled with all the packages on 
GELPA, and one that does. There might in fact be no such plan, 
though; and in any event, i've no idea how much work would be 
involved in creating such flavours (particularly on systems like 
Win and OS X).


Alexis.

Re: [ELPA] tramp-theme.el

[Joost Kremers]

On Tue, Feb 16 2016, Stefan Reichör <stefan@xsteve.at> wrote:
> As a user I really don't like that a lot of functionality is now moved to ELPA.
> When I install a new emacs, I have to re-install also all needed
> packages from ELPA.

Check out use-package:

https://github.com/jwiegley/use-package

Next time, that's the only package you'll need to install manually.


-- 
Joost Kremers
Life has its moments

Future role of ELPA (was: [ELPA] tramp-theme.el)

[Stefan Reichör]

John Wiegley <jwiegley@gmail.com> writes:

>>>>>> Stefan Reichör <stefan@xsteve.at> writes:
>
>> As a user I really don't like that a lot of functionality is now moved to
>> ELPA. When I install a new emacs, I have to re-install also all needed
>> packages from ELPA.
>>
>> It would be so much easier when all the batteries in emacs are still
>> included.
>
> The future plan is to move even more things into ELPA. However, parts of ELPA
> will be included in future Emacs tarballs, so your batteries will actually be
> there in that future.
>
> So, rather than asking whether things can move back into Emacs, the better
> question is: how should we proceed with our plan to deeply integrate ELPA, so
> questions like this are resolved in passing. We've had some progress in this
> direction, but there are still a few matters of process to resolve.

I am reading the emacs devel list. And I know that this is the direction
that is desired by most/all developers.

As I user I am not happy with that direction.
Let me try to explain it.
I use Emacs since about 20 years. I use it daily and it is my primary
interface to computer related tasks. For sure I can adopt to what ever
direction emacs goes.

I use a hand crafted .emacs and I am used to install emacs packes
manually to a site-lisp folders.

Consider a simple customization like tramp-theme. When everything is in
stock emacs: I just can change the value of a customization variable and
see what happens.

With GNU ELPA I have to install the package first and get rid of it if I
don't like it.

My main concern with GNU ELPA is that I have to install a lot of extra
packages manually using the package manager. When they are built-in they
are just there.

So I hope that many useful features will still be shipped with Emacs as
integrated packages.

Stefan.

Re: [ELPA] tramp-theme.el

[Michael Albinus]

Stefan Reichör <stefan@xsteve.at> writes:

> Hallo Michael,

Hi Stefan,

> I would like such functionality be part of tramp/Emacs.
>
> As a user I really don't like that a lot of functionality is now moved to ELPA.
> When I install a new emacs, I have to re-install also all needed
> packages from ELPA.
>
> It would be so much easier when all the batteries in emacs are still included.

Well, I have even a vague plan to provide Tramp itself via ELPA. This
does not exclude it from vanilla Emacs. But Tramp releases happen more
frequently than Emacs releases; everybody would be free to decide which
Tramp version to use: the builtin version, or a fresher one from
ELPA. This is something what org-mode offers already.

tramp-theme.el is another story. It is not part of Tramp (yet), and it
does not use any of the Tramp internal functions. I was going the ELPA
way, because by this all people with older Emacsen could use it
immediately. If requested, I could bring it also to etc/themes. John?

> Stefan.

Best regards, Michael.

Re: [ELPA] tramp-theme.el

[Stefan Reichör]

Joost Kremers <joostkremers@fastmail.fm> writes:

> On Tue, Feb 16 2016, Stefan Reichör <stefan@xsteve.at> wrote:
>> As a user I really don't like that a lot of functionality is now moved to ELPA.
>> When I install a new emacs, I have to re-install also all needed
>> packages from ELPA.
>
> Check out use-package:
>
> https://github.com/jwiegley/use-package
>
> Next time, that's the only package you'll need to install manually.

Wow - this package looks useful :-)

Please include it in emacs! ;-)

Then I (and other users) don't have to install it manually.

Stefan.

Re: Future role of ELPA

[Christian Kruse]

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

Hi,

I am an Emacs user as well, and I so much disagree with you.

Stefan Reichör <stefan@xsteve.at> writes:

> As I user I am not happy with that direction.
> Let me try to explain it.
> I use Emacs since about 20 years. I use it daily and it is my primary
> interface to computer related tasks. For sure I can adopt to what ever
> direction emacs goes.

17 year here, since ‘99. I use Emacs for nearly everything as well.

> I use a hand crafted .emacs and I am used to install emacs packes
> manually to a site-lisp folders.

Me, too, and I hated it. It was *SO* much work to keep track of
everything I installed this way; for bigger packages I even had to
change the load path to get it installed properly.

Nowadays I just hit „install“ - done.

> With GNU ELPA I have to install the package first and get rid of it if I
> don't like it.

That’s easier now as well. Just `rm -rf` the sub-directory in the elpa
directory and be done with it. Try to remove e.g. org-mode from the
Emacs distribution.

> My main concern with GNU ELPA is that I have to install a lot of extra
> packages manually using the package manager. When they are built-in they
> are just there.

That’s exactly what I like about ELPA. I decide what I’d like to have
installed, and not some maintainer. For example I would never install
tramp, this bugged piece of software caused me so much trouble (for
example, `/dev/null` gets overwritten everytime I use tramp and I have
to do a `mknod` everytime to re-create it).

Moving more things to ELPA means more control for me, and it also means
faster bugfixes for packages I use. I don’t have to wait for a new Emacs
release to get a bugfix for e.g. org-mode, but I can install a new
version as soon as it has been released just by hitting enter on the
install button.

I totally like the way of moving things to ELPA.

Best regards,
-- 
Christian Kruse
https://wwwtech.de/about

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 818 bytes --]

Re: Future role of ELPA

[Michael Albinus]

Christian Kruse <cjk@defunct.ch> writes:

> Hi,

Hi Christian,

> That’s exactly what I like about ELPA. I decide what I’d like to have
> installed, and not some maintainer. For example I would never install
> tramp, this bugged piece of software caused me so much trouble (for
> example, `/dev/null` gets overwritten everytime I use tramp and I have
> to do a `mknod` everytime to re-create it).

Honour to whom honour is due: its'a a bash bug. See Bug#19731.

And I agree with you: with Tramp being also in ELPA, you would have get
a bug fix already, instead of waiting for Emacs 25.1.

> Best regards,

Best regards, Michael.

Re: [ELPA] tramp-theme.el

[Joost Kremers]

On Tue, Feb 16 2016, Stefan Reichör <stefan@xsteve.at> wrote:
> Joost Kremers <joostkremers@fastmail.fm> writes:
>> Check out use-package:
>>
>> https://github.com/jwiegley/use-package
>>
>> Next time, that's the only package you'll need to install manually.
>
> Wow - this package looks useful :-)

Yes. I recently started using it and I think it's great. I especially
like the fact that by default use-package will simply ignore packages
that it cannot find. That makes it possible to have different Emacs
configs on different machines while still being able to sync your init
file between them. Some of the packages I use are fairly
resource-intensive, which is fine on my main machine but would make
Emacs unusable on my lower-spec'ed netbook. With use-package, I can
simply forego installing them on the netbook and all is well.

Of course, that requires that the relevant packages are *not* part of
Emacs core, so I tend to see ELPA as being a good thing.

> Please include it in emacs! ;-)

*hear hear*

-- 
Joost Kremers
Life has its moments

Re: Future role of ELPA

[Oleh Krehel]

Stefan Reichör <stefan@xsteve.at> writes:

> I am reading the emacs devel list. And I know that this is the direction
> that is desired by most/all developers.

> Consider a simple customization like tramp-theme. When everything is in
> stock emacs: I just can change the value of a customization variable and
> see what happens.
>
> With GNU ELPA I have to install the package first and get rid of it if I
> don't like it.
>
> My main concern with GNU ELPA is that I have to install a lot of extra
> packages manually using the package manager. When they are built-in they
> are just there.
>
> So I hope that many useful features will still be shipped with Emacs as
> integrated packages.

This can easily be made configurable.  There's nothing that prevents us
from injecting selected ELPA packages (like gnus or tramp) into the main
lisp/ directory during Emacs installation. Then, instead of
`package-install', a plain `require' would work.

My impression was that this is the way the "bundled ELPA" packages will
work. The slightly tricky part is modifying `package-initialize' so that
any package in GELPA would supersede the bundled version, since it's
newer. But it's just a matter of calling it once and sorting
`load-path'.

    Oleh

Re: Future role of ELPA

[Christian Kruse]

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

Hi Michael,

Michael Albinus <michael.albinus@gmx.de> writes:

>> That’s exactly what I like about ELPA. I decide what I’d like to have
>> installed, and not some maintainer. For example I would never install
>> tramp, this bugged piece of software caused me so much trouble (for
>> example, `/dev/null` gets overwritten everytime I use tramp and I have
>> to do a `mknod` everytime to re-create it).
>
> Honour to whom honour is due: its'a a bash bug. See Bug#19731.

I don’t even use Bash but ZSH, sorry ;-)

I didn’t want to be offensive, sorry about that. I noticed that I was
offensive now, after I read the cite. I’m sorry.

Best regards,
-- 
Christian Kruse
https://wwwtech.de/about

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 818 bytes --]

Re: Future role of ELPA

[Michael Albinus]

Christian Kruse <cjk@defunct.ch> writes:

> Hi Michael,

Hi Christian,

>> Honour to whom honour is due: its'a a bash bug. See Bug#19731.
>
> I don’t even use Bash but ZSH, sorry ;-)

It's about the shell on the remote host, which is invoked via /bin/sh.

Anyway, if you want to get rid of this bug, use the recent Tramp release
2.2.13 (not available via ELPA yet). Or the pretest version of Emacs 25.1.

> Best regards,

Best regards, Michael.

Re: Future role of ELPA

[Przemysław Wojnowski]

W dniu 2016-02-16 09:46, Michael Albinus napisał(a):
[...]
> And I agree with you: with Tramp being also in ELPA, you would have get
> a bug fix already, instead of waiting for Emacs 25.1.

This is the main reason I would like to see all packages in a repository 
instead of bundled with Emacs. This would make Emacs smaller, easier to 
maintain, release and value (features, new packages, bugfixes, etc.) 
would be faster delivered to users.

Is there any reason why, let's say, cc-mode cannot be in ELPA? Certainly 
not.

Re: Future role of ELPA

[Christian Kruse]

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

Hi Michael,

Michael Albinus <michael.albinus@gmx.de> writes:
> Anyway, if you want to get rid of this bug, use the recent Tramp release
> 2.2.13 (not available via ELPA yet). Or the pretest version of Emacs 25.1.

Thanks; just intalled the updated version and M-x tramp-version says
2.2.13. I hope this bug is finally gone :)

Freundliche Grüsse,
-- 
Christian Kruse
https://wwwtech.de/about

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 818 bytes --]

RE: Future role of ELPA (was: [ELPA] tramp-theme.el)

[Drew Adams]

> >> As a user I really don't like that a lot of functionality is now moved to
> >> ELPA. When I install a new emacs, I have to re-install also all needed
> >> packages from ELPA.

A reasonable critique, I think.

> >> It would be so much easier when all the batteries in emacs are still
> >> included.
> >
> > The future plan is to move even more things into ELPA. However, parts of
> > ELPA will be included in future Emacs tarballs, so your batteries will
> > actually be there in that future.
> >
> > So, rather than asking whether things can move back into Emacs, the better
> > question is: how should we proceed with our plan to deeply integrate ELPA,
> > so questions like this are resolved in passing. We've had some progress in
> > this direction, but there are still a few matters of process to resolve.

Exactly.  I'm glad that this user (Stefan) posed the question and made known
his use case.  It should be taken into account ("resolved in passing").

> I am reading the emacs devel list. And I know that this is the direction
> that is desired by most/all developers.
> 
> As I user I am not happy with that direction.
> Let me try to explain it.
> I use Emacs since about 20 years. I use it daily and it is my primary
> interface to computer related tasks. For sure I can adopt to what ever
> direction emacs goes.
> 
> I use a hand crafted .emacs and I am used to install emacs packes
> manually to a site-lisp folders.
> 
> Consider a simple customization like tramp-theme. When everything is in
> stock emacs: I just can change the value of a customization variable and
> see what happens.
> 
> With GNU ELPA I have to install the package first and get rid of it if I
> don't like it.
> 
> My main concern with GNU ELPA is that I have to install a lot of extra
> packages manually using the package manager. When they are built-in they
> are just there.

Indeed.

> So I hope that many useful features will still be shipped with Emacs as
> integrated packages.

I agree with you.  But I also agree that it is good to modularize the
Emacs code, e.g. by moving some of it to GNU ELPA.  That can help both
Emacs development and the use cases of some users.

I agree with you that a user should be able to ask Emacs about something
(e.g., a command) that has traditionally been provided with the Emacs
distribution, without having to use the package system to add it.

In a way, perhaps what is needed is a "super autoload" facility, that
is, a more sophisticated way of making use of the package system,
so that the same behavior as before a breakup into separate packages
is still available seamlessly, even if under the covers packages are
brought into play.

The key here is "under the covers": A user should not _need_ to do
anything or even to be aware that packages are being jockeyed into
place automatically to accommodate an inquiry or an on-demand use
of a feature.

A user should not be required to (consciously, manually) use the
package system at all, to interact usefully with Emacs.  A user
should be able to have everything that s?he had from Emacs
previously on disk, locally, without jumping through any hoops.

There should be no need to connect to the Internet to work with
Emacs, at least regarding the large set of commands, options, etc.
that has traditionally been distributed with Emacs.

IOW, it should be possible for a user to use Emacs without the
package system, just as easily as before.  Adding the package
system should be only a plus, not a plus and a minus.  Users should
be able to interact with Emacs in different ways, and not be obliged
to get only a tiny core by default and then have to install the
pieces they feel are missing.

At the same time, it would be good if the Emacs code were composable
from libraries in a repository such as GNU ELPA.  How these two needs
can best be composed I don't know.  But I don't think we should
be sacrificing user access to what used to be the Emacs code base on
the alter of the package system.

What is convenient for Emacs development and for some users some of
the time should not trump the ability of other users (or the same
users at other times) to interact with Emacs as they would have
before the package system.  If you need to activate a package to get
information about `forward-sexp' or whatever, then we have lost something.

That users _can_ choose not to "install" Tramp or whatever is a
good thing, no doubt.  But it is not necessarily a good thing that
users should have to manually "install" Tramp or whatever, just to
be able to talk to Emacs about it or even to make use of it.

All this is a way of saying that we might need to think some more
about how Emacs and Emacs Dev make use of the package system, a
system that, on its own, is a good thing.  It should not become
a sledgehammer that makes everything in Emacs look like a nail.

Re: Future role of ELPA

[John Wiegley]

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

>>>>> Stefan Reichör <stefan@xsteve.at> writes:

> My main concern with GNU ELPA is that I have to install a lot of extra
> packages manually using the package manager. When they are built-in they are
> just there.

Hi Stefan,

Have no fear: I never use package.el myself, since I also prefer to curate
hand-installed packages.

So what does moving to ELPA mean?

There would be a large set of ELPA packages (maybe all of them to start) that
will appear in the tarball when you download and install Emacs. This means --
I think -- that they should populate the site-wide site-lisp directory, and
appear to users as if they had come "with Emacs"; that is, either autoloading
or a manual `require' statement to make the functionality available.

There are a few advantages to this:

  1. After installation of Emacs, package.el can be used to upgrade select
     packages independent of our release cycle.

  2. Developers can get packages into the Emacs distribution without having to
     justification inclusion in core.

  3. Code "in development" is free to appear in ELPA, whereas we tend to frown
     on APIs that will change often in Emacs itself.

The bottom line is that, as a user, you shouldn't notice much difference after
installation, but you'll gain the benefit of optionally performing frequent
updates of ELPA packages. As an Emacs developer, the advantage is that it
simplifies the Emacs Git repository, and makes it easier for external authors
to focus on maintaining their packages within ELPA.

-- 
John Wiegley                  GPG fingerprint = 4710 CF98 AF9B 327B B80F
http://newartisans.com                          60E1 46C4 BD1A 7AC1 4BA2

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 629 bytes --]

Re: [ELPA] tramp-theme.el

[John Wiegley]

>>>>> Stefan Reichör <stefan@xsteve.at> writes:

>> https://github.com/jwiegley/use-package

> Please include it in emacs! ;-)

:) It's on its way. I'm still gathering copyright assignments from everyone
who contributed over the last few years. Once that's done, it will appear in
the part of ELPA that ends up in the 26.1 tarball.

The only reason it wouldn't appear in Emacs core is that nothing in core needs
it; it's only going to be there for users, which is a pretty clear criterion
for when something belongs in GNU ELPA rather than in core.

-- 
John Wiegley                  GPG fingerprint = 4710 CF98 AF9B 327B B80F
http://newartisans.com                          60E1 46C4 BD1A 7AC1 4BA2

Re: [ELPA] tramp-theme.el

[John Wiegley]

>>>>> Michael Albinus <michael.albinus@gmx.de> writes:

> tramp-theme.el is another story. It is not part of Tramp (yet), and it does
> not use any of the Tramp internal functions. I was going the ELPA way,
> because by this all people with older Emacsen could use it immediately. If
> requested, I could bring it also to etc/themes. John?

I'd say that's up to you, Michael.  I wouldn't mind see the "theme library"
move into ELPA, since only users -- not core -- requires it, but we're still
quite flexible on these points.

-- 
John Wiegley                  GPG fingerprint = 4710 CF98 AF9B 327B B80F
http://newartisans.com                          60E1 46C4 BD1A 7AC1 4BA2

Re: [ELPA] tramp-theme.el

[Stefan Reichör]

John Wiegley <jwiegley@gmail.com> writes:

>>>>>> Stefan Reichör <stefan@xsteve.at> writes:
>
>>> https://github.com/jwiegley/use-package
>
>> Please include it in emacs! ;-)
>
> :) It's on its way. I'm still gathering copyright assignments from everyone
> who contributed over the last few years. Once that's done, it will appear in
> the part of ELPA that ends up in the 26.1 tarball.
>
> The only reason it wouldn't appear in Emacs core is that nothing in core needs
> it; it's only going to be there for users, which is a pretty clear criterion
> for when something belongs in GNU ELPA rather than in core.

Well, following this logic, you have to move every package to GNU ELPA.
Nothing in emacs core needs dired, eshell, c-mode, python-mode, ...

I think something like use-package is a very important core component of
emacs. Since it allows a user to depend on a package. No matter if it is
already installed or not.

In my opinion this is a requirement when packages are shifted to ELPA.

The transition that I will do is, replacing require and load statements
in my .emacs by use-package statements. That is something that is
do-able.


Stefan.

Re: Future role of ELPA

[Stefan Reichör]

John Wiegley <jwiegley@gmail.com> writes:

>>>>>> Stefan Reichör <stefan@xsteve.at> writes:
>
>> My main concern with GNU ELPA is that I have to install a lot of extra
>> packages manually using the package manager. When they are built-in they are
>> just there.
>
> Hi Stefan,
>
> Have no fear: I never use package.el myself, since I also prefer to curate
> hand-installed packages.
>
> So what does moving to ELPA mean?
>
> There would be a large set of ELPA packages (maybe all of them to start) that
> will appear in the tarball when you download and install Emacs. This means --
> I think -- that they should populate the site-wide site-lisp directory, and
> appear to users as if they had come "with Emacs"; that is, either autoloading
> or a manual `require' statement to make the functionality available.
>
> There are a few advantages to this:
>
>   1. After installation of Emacs, package.el can be used to upgrade select
>      packages independent of our release cycle.
>
>   2. Developers can get packages into the Emacs distribution without having to
>      justification inclusion in core.
>
>   3. Code "in development" is free to appear in ELPA, whereas we tend to frown
>      on APIs that will change often in Emacs itself.
>
> The bottom line is that, as a user, you shouldn't notice much difference after
> installation, but you'll gain the benefit of optionally performing frequent
> updates of ELPA packages. As an Emacs developer, the advantage is that it
> simplifies the Emacs Git repository, and makes it easier for external authors
> to focus on maintaining their packages within ELPA.

I see.
A simpler way to upgrade selected packages is good thing.

Some things that should be considered for the package system:

1. Not only emacs provides a package manager. Linux distributions also
   provide some packages. Not sure if this is a good idea.
   The same situation is e.g. for python. You can use pip to install
   packages. And there are python packages provided by distributions.
   Some people prefer OS packages, some prefer the native package manager.
   Not sure what to do about this situation.

2. The packages should not be too fine grained. It is not very useful to
   split e.g. tramp in 20 sub-packages for example.
   I don't want to be overwhelmed by 100s or 1000s of packages.
   Perhaps we could have some kind of installation counter to find
   useful packages. Or even some kind of voting system.

Stefan.

Re: Future role of ELPA

[Michael Albinus]

Stefan Reichör <stefan@xsteve.at> writes:

> 2. The packages should not be too fine grained. It is not very useful to
>    split e.g. tramp in 20 sub-packages for example.

Don't fear this, I'm not going this way. tramp-theme.el has just stolen
the name from Tramp because it is a brand. It does not depend on Tramp
itself, and it cooperates with any other file name handler which offers
file-remote-p functionality.

> Stefan.

Best regards, Michael.

Re: Future role of ELPA

[John Wiegley]

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

>>>>> Stefan Reichör <stefan@xsteve.at> writes:

> 1. Not only emacs provides a package manager. Linux distributions also
> provide some packages. Not sure if this is a good idea. The same situation
> is e.g. for python. You can use pip to install packages. And there are
> python packages provided by distributions. Some people prefer OS packages,
> some prefer the native package manager. Not sure what to do about this
> situation.

I afraid that solving this is out of scope for us.

> 2. The packages should not be too fine grained. It is not very useful to
> split e.g. tramp in 20 sub-packages for example. I don't want to be
> overwhelmed by 100s or 1000s of packages. Perhaps we could have some kind of
> installation counter to find useful packages. Or even some kind of voting
> system.

Certainly, this is a matter of wisdom on the part of package submitters.
Egregious exceptions will need to be considered on a case-by-case basis.

-- 
John Wiegley                  GPG fingerprint = 4710 CF98 AF9B 327B B80F
http://newartisans.com                          60E1 46C4 BD1A 7AC1 4BA2

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 629 bytes --]

Re: [ELPA] tramp-theme.el

[John Wiegley]

>>>>> Stefan Reichör <stefan@xsteve.at> writes:

> Well, following this logic, you have to move every package to GNU ELPA.
> Nothing in emacs core needs dired, eshell, c-mode, python-mode, ...

We aren't going to be rigid about making this divide. Anything currently in
core will pretty much stay in core, unless and until it makes obvious sense to
move it out to GNU ELPA.

-- 
John Wiegley                  GPG fingerprint = 4710 CF98 AF9B 327B B80F
http://newartisans.com                          60E1 46C4 BD1A 7AC1 4BA2

Re: [ELPA] tramp-theme.el

[Michael Albinus]

John Wiegley <jwiegley@gmail.com> writes:

>> tramp-theme.el is another story. It is not part of Tramp (yet), and it does
>> not use any of the Tramp internal functions. I was going the ELPA way,
>> because by this all people with older Emacsen could use it immediately. If
>> requested, I could bring it also to etc/themes. John?
>
> I'd say that's up to you, Michael.  I wouldn't mind see the "theme library"
> move into ELPA, since only users -- not core -- requires it, but we're still
> quite flexible on these points.

I've pushed it to ELPA. The version is 0.1, meaning the API is not solid
yet. ELPA might be the better place, therefore.

Best regards, Michael.

Re: Future role of ELPA

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > 1. Not only emacs provides a package manager. Linux distributions also
  >    provide some packages.

You're talking about versions of the GNU system.
Please don't call them "Linux distributions"!
That gives the credit for our system
to someone else, and not at all to us.
It treats us very badly.

See http://gnu.org/gnu/linux-and-gnu.html and
http://gnu.org/gnu/gnu-linux-faq.html, plus the history in
http://gnu.org/gnu/the-gnu-project.html.

-- 
Dr Richard Stallman
President, Free Software Foundation (gnu.org, fsf.org)
Internet Hall-of-Famer (internethalloffame.org)
Skype: No way! See stallman.org/skype.html.

Re: Future role of ELPA

[Phillip Lord]

Stefan Reichör <stefan@xsteve.at> writes:
>
> I am reading the emacs devel list. And I know that this is the direction
> that is desired by most/all developers.
>
> As I user I am not happy with that direction.
> Let me try to explain it.
> I use Emacs since about 20 years. I use it daily and it is my primary
> interface to computer related tasks. For sure I can adopt to what ever
> direction emacs goes.
>
> I use a hand crafted .emacs and I am used to install emacs packes
> manually to a site-lisp folders.

I stopped doing that in favour of use a package-install statement, in
this case via use-package. In total this means that, 

(require 'feature)

get replaced by

(use-package feature :ensure t)

There's even a way to avoid doing the :ensure bit if you want. In the
.emacs, the use of package.el can be pretty invisible.


> Consider a simple customization like tramp-theme. When everything is in
> stock emacs: I just can change the value of a customization variable and
> see what happens.

One thing that is an issue with package.el as it stands is
discoverability. Currently, if I open a *.lua file, I get fundamental
mode. While if I open a *.python file, I get python mode. Clearly the
former is unfriendly, and nothing tells me that installing lua-mode
solves the problem. If python-mode (for example) moved to ELPA, then
clearly we'd have the same problem there.

I think that there are two solutions to this: some packages should go to
ELPA, but could be packaged up with an Emacs distribution. Emacs "point"
releases then might have no changes to the core, but just changes to
ELPA packages.

The other possibility would be to have an something like autoloads for
ELPA packages. So, the first time you open a *.py file, and Emacs says
"Do you want to install python-mode".


> With GNU ELPA I have to install the package first and get rid of it if I
> don't like it.

Just leave it -- disk space is cheap!

> My main concern with GNU ELPA is that I have to install a lot of extra
> packages manually using the package manager. When they are built-in they
> are just there.
>
> So I hope that many useful features will still be shipped with Emacs as
> integrated packages.

I would modify this to "I hope that many useful features will continue
to be as usable as currently". Do you really care about whether they are
integrated, or if they just appear to be but some magic is happening
somewhere.

Phil

Re: Future role of ELPA

[Stefan Monnier]

> 1. Not only emacs provides a package manager. Linux distributions also
>    provide some packages. Not sure if this is a good idea.
>    The same situation is e.g. for python. You can use pip to install
>    packages. And there are python packages provided by distributions.
>    Some people prefer OS packages, some prefer the native package manager.
>    Not sure what to do about this situation.

It's easy to make a .deb package which installs an Elisp package in the
way package.el would have installed it (but with global scope).

The two aren't 100% equivalent (upgrading/removing a dpkg-installed
package via package.el won't do the right thing), but the Debian
packages can easily do better than what is there now.


        Stefan

Re: Future role of ELPA

[Philipp Stephani]

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

Stefan Monnier <monnier@iro.umontreal.ca> schrieb am So., 21. Feb. 2016 um
03:19 Uhr:

> > 1. Not only emacs provides a package manager. Linux distributions also
> >    provide some packages. Not sure if this is a good idea.
> >    The same situation is e.g. for python. You can use pip to install
> >    packages. And there are python packages provided by distributions.
> >    Some people prefer OS packages, some prefer the native package
> manager.
> >    Not sure what to do about this situation.
>
> It's easy to make a .deb package which installs an Elisp package in the
> way package.el would have installed it (but with global scope).
>
> The two aren't 100% equivalent (upgrading/removing a dpkg-installed
> package via package.el won't do the right thing), but the Debian
> packages can easily do better than what is there now.
>

That would be great, but it would mean the Debian Emacs policy (
https://www.debian.org/doc/packaging-manuals/debian-emacs-policy) and the
emacsen-common package, which provides the necessary infrastructure, would
need to be upgraded.
My understanding is as follows: to build such a Debian package, you'd have
to install the byte-compiled files in a directory with the same name as the
Emacs package, and add its parent to package-directory-list in
site-start.d, is that roughly correct?

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

Re: Future role of ELPA

[Stefan Monnier]

> My understanding is as follows: to build such a Debian package, you'd have
> to install the byte-compiled files in a directory with the same name as the
> Emacs package, and add its parent to package-directory-list in
> site-start.d, is that roughly correct?

Something like that, yes.  And include <pkg>-autoloads.el and
<pkg>-pkg.el files in there as well.


        Stefan

Re: Future role of ELPA

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

If we are going to offer our own .deb packages of Emacs, that doesn't
mean we have to follow all of Debian's policies.  In general, we
should follow our own policies when they disagree with Debian's.

If you see a practical reason to depart from that, please discuss
it with me.

-- 
Dr Richard Stallman
President, Free Software Foundation (gnu.org, fsf.org)
Internet Hall-of-Famer (internethalloffame.org)
Skype: No way! See stallman.org/skype.html.

Re: Future role of ELPA

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

I looked at https://www.debian.org/doc/packaging-manuals/debian-emacs-policy.
It involves substantial changes which we don't have a reason to make.

I don't mind that Debian makes these changes for its Emacs packages,
but we don't have to do it when we package the development Emacs.

If you build Emacs from source, on Debian, does that cause conflicts
with Debian's Emacs patches?  If not, then there won't be a conflict
if we package Emacs as it stands.

-- 
Dr Richard Stallman
President, Free Software Foundation (gnu.org, fsf.org)
Internet Hall-of-Famer (internethalloffame.org)
Skype: No way! See stallman.org/skype.html.