Re: ELPA

Re: ELPA

[Eric Schulte]

Scot Becker <scot.becker@gmail.com> writes:

> Dan,

[...]

>> - Would it make sense to have two different packages available via ELPA,
>
> To me, yes.  I like using git for the development tree, but I expect
> that ELPA makes for a nice way for Windows users (and others who don't
> want to or can't use git) to get the latest version easily (and
> possibly even to downgrade if necessary).  The latest release version
> is of course necessary as well, since using it is the main
> recommendation to new users.
>

I would think that it only makes sense to have one Org-mode package in
ELPA, namely the bleeding edge git version of Org-mode.  ELPA serves as
a way to distribute packages which are not (or can't be) part of Emacs,
I don't think it makes sense to use ELPA to re-distribute the version of
Org-mode which users already have installed as part of their Emacs
install.  Un-installing the bleeding edge Org-mode would be equivalent
to downgrading to the Emacs version.

Also, I would tend to think that this would make the most sense if we
automate the ELPA integration s.t. every time a new revision is pushed
up the to git repository, the ELPA version is automatically upgraded
(with a git commit hook).  If this isn't currently possible in ELPA then
I'd agree with a point Jambunathan makes in this thread that this is a
trick we can help ELPA to learn.

The reason I think the above is important is that very frequently the
answer to a question is "oh, I fixed that, please pull the latest from
git", and we'll be constantly frustrating users if ELPA can't keep up
with git.

Best -- Eric

Re: ELPA

[Sebastian Rose]

"Eric Schulte" <schulte.eric@gmail.com> writes:
> I would think that it only makes sense to have one Org-mode package in
> ELPA, namely the bleeding edge git version of Org-mode.  ELPA serves as
> a way to distribute packages which are not (or can't be) part of Emacs,


package.el in emacs-24 lists Org-mode as "built-in".  That's the version
included in Emacs, not a package on elpa.gnu.org as I thought.

The "bleeding edge" package would be the only one there.


> I don't think it makes sense to use ELPA to re-distribute the version of
> Org-mode which users already have installed as part of their Emacs
> install.  Un-installing the bleeding edge Org-mode would be equivalent
> to downgrading to the Emacs version.

+1

> Also, I would tend to think that this would make the most sense if we
> automate the ELPA integration s.t. every time a new revision is pushed
> up the to git repository, the ELPA version is automatically upgraded
> (with a git commit hook).  If this isn't currently possible in ELPA then
> I'd agree with a point Jambunathan makes in this thread that this is a
> trick we can help ELPA to learn.
>
> The reason I think the above is important is that very frequently the
> answer to a question is "oh, I fixed that, please pull the latest from
> git", and we'll be constantly frustrating users if ELPA can't keep up
> with git.
>
> Best -- Eric



  Sebastian

Re: ELPA

[Achim Gratz]

"Eric Schulte" <schulte.eric@gmail.com> writes:
> I would think that it only makes sense to have one Org-mode package in
> ELPA, namely the bleeding edge git version of Org-mode.

I disagree and my vote is still on 'maint', i.e. what a user would be
most likely to install if he was visiting orgmode.org.  Master changes
too often and might have experimental commits that later get reversed.
For anybody not following the mailing list this would be exactly the
wrong version to get through ELPA, especially since ELPA (at least in
standard configuration) does not notify about new versions.

> ELPA serves as a way to distribute packages which are not (or can't
> be) part of Emacs,

This is true of the current ELPA (tromey.com), but I feel the GNU ELPA
might take on an additional role: 1) easily obtaining packages that
would not normally come with the standard install of Emacs and 2)
keeping users updated on packages that are still developed and change
between releases.  Org-mode would fall into the second category since it
will probably stay in the standard package set. 

> Also, I would tend to think that this would make the most sense if we
> automate the ELPA integration s.t. every time a new revision is pushed
> up the to git repository, the ELPA version is automatically upgraded
> (with a git commit hook).  If this isn't currently possible in ELPA then
> I'd agree with a point Jambunathan makes in this thread that this is a
> trick we can help ELPA to learn.

Again, Emacs24 ELPA will be able to query multiple archives, something
that current ELPA can't.  So Emacs24 will by default look at
elpa.gnu.org and users should be able to find the latest stable version
there (it may not show up exactly in the minute it is released on
orgmode.org).  It should then be easy enough to configure ELPA (from
org-mode even?) to look for updates on orgmode.org first and get
bleeding edge from there if the user asks to do this.  If GNU ELPA
adopts a different package update policy then both the stable and
bleeding edge version would need to be on orgmode.org -- has anybody had
a chance to ask or followed the discussion on the emacs.devel list?


Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

SD adaptation for Waldorf microQ V2.22R2:
http://Synth.Stromeko.net/Downloads.html#WaldorfSDada

Re: ELPA

[Richard Riley]

Achim Gratz <Stromeko@nexgo.de> writes:

> "Eric Schulte" <schulte.eric@gmail.com> writes:
>> I would think that it only makes sense to have one Org-mode package in
>> ELPA, namely the bleeding edge git version of Org-mode.
>
> I disagree and my vote is still on 'maint', i.e. what a user would be
> most likely to install if he was visiting orgmode.org.  Master changes
> too often and might have experimental commits that later get reversed.
> For anybody not following the mailing list this would be exactly the
> wrong version to get through ELPA, especially since ELPA (at least in
> standard configuration) does not notify about new versions.

I'd be interested to hear how many people actually use ELPA. I haunt the
#emacs channel a little bit and I know only a handful that use it. Is
the idea that it will be used more or central to emacs in the future?

Re: ELPA

[Scot Becker]

On Tue, Sep 28, 2010 at 6:48 PM, Eric Schulte <schulte.eric@gmail.com> wrote:
> I don't think it makes sense to use ELPA to re-distribute the version of
> Org-mode which users already have installed as part of their Emacs
> install.  Un-installing the bleeding edge Org-mode would be equivalent
> to downgrading to the Emacs version.

Sure that doesn't make sense, but remember that Emacs development
protocol is very conservative, and requires included packages to stop
all changes except bug fixes long in advance of new Emacs releases,
for stability.  This typically has had the result that an Emacs
version is released with an org-mode version which is a good few
org-mode releases behind---even on the day the Emacs release becomes
official.  In that case it would never happen that ELPA would be
re-distributing the version already installed with Emacs.  The latest
org-mode release will always be an advance on what got from a stock
Emacs.  This means that if you think that there is a place for people
to run the latest org release (as opposed to the dev version), then,
it seems, there is a decent place in ELPA for it, or?

How-to disable persistent *EBDB-Message* buffer?

[Pankaj Jangid]

Whenever I type partial names in address fields and press tab,
completion buffer appears. That is fine. But after completion and new
buffer *EBDB-Message* appears in a separate window and it remains
open. How can I prevent this buffer from opening a new window?

I have tried setting ‘ebdb-mua-pop-up’ to nil, but I guess that is for
something else.

--
Regards
Pankaj

Re: How-to disable persistent *EBDB-Message* buffer?

[Eric Abrahamsen]

Pankaj Jangid <pankaj@codeisgreat.org> writes:

> Whenever I type partial names in address fields and press tab,
> completion buffer appears. That is fine. But after completion and new
> buffer *EBDB-Message* appears in a separate window and it remains
> open. How can I prevent this buffer from opening a new window?
>
> I have tried setting ‘ebdb-mua-pop-up’ to nil, but I guess that is for
> something else.

Hi, thanks for the report! The `ebdb-mua-pop-up' option definitely
should govern this, but I see that you'd actually need to set another
option to nil to really make it work: `ebdb-completion-display-record'.
That should solve the immediate problem for you.

All of the completion stuff in EBDB is due for an overhaul, one of my
New Year's resolutions!

Thanks,
Eric

Re: How-to disable persistent *EBDB-Message* buffer?

[Pankaj Jangid]

Eric Abrahamsen <eric@ericabrahamsen.net> writes:
> Hi, thanks for the report! The `ebdb-mua-pop-up' option definitely
> should govern this, but I see that you'd actually need to set another
> option to nil to really make it work: `ebdb-completion-display-record'.
> That should solve the immediate problem for you.
>
> All of the completion stuff in EBDB is due for an overhaul, one of my
> New Year's resolutions!

Thanks for the workaround. It worked for me.

Thanks for all your work. I would like to see ebdb as part of built-in
packages. But since it is in ELPA, that is also okay.

ELPA (was: Re: How-to disable persistent *EBDB-Message* buffer?)

[Emanuel Berg via Users list for the GNU Emacs text editor]

Pankaj Jangid wrote:

> Thanks for all your work. I would like to see ebdb as part
> of built-in packages. But since it is in ELPA, that is
> also okay.

What is that, like ~/.mailrc ?

As for ELPA ... this has happened to me for as long as
I can remember.

  Packages that can be upgraded: 11; type ‘U’ to mark
  for upgrading.
  
  (hit U)
  
  package-menu--mark-upgrades-1: Wrong type argument:
  package-desc, nil

Also... can you do it without having to do this

  byte-compile=$(emacs) \
     -batch \
     -eval "(setq load-path (append load-path '(\"~/.emacs.d/elpa/gnuplot-mode-20171013.1616/\" \"~/.emacs.d/elpa/vterm-20201004.2057\" \"~/.emacs.d/elpa/markdown-mode-20201015.1327\" \"~/.emacs.d/elpa/w3m-20200818.141\" \"~/.emacs.d/emacs-init\" \"~/.emacs.d/emacs-init/ide\" \"~/.emacs.d/emacs-init/w3m\" \"~/.emacs.d/emacs-init/gnus\" \"~/.emacs.d/elpa/google-translate-20190620.1416\" )))" \
     -f batch-byte-compile

In the Makefile? (Set the load-path again for every pack, I mean.)

https://dataswamp.org/~incal/emacs-init/Makefile

-- 
underground experts united
http://user.it.uu.se/~embe8573
https://dataswamp.org/~incal

Re: ELPA

[Eric Abrahamsen]

Emanuel Berg via Users list for the GNU Emacs text editor
<help-gnu-emacs@gnu.org> writes:

> Pankaj Jangid wrote:
>
>> Thanks for all your work. I would like to see ebdb as part
>> of built-in packages. But since it is in ELPA, that is
>> also okay.
>
> What is that, like ~/.mailrc ?

It's a port/rewrite of BBDB, so it's full-blown contact management, not
just mail completion.

> As for ELPA... this has happened to me for as long as
> I can remember.
>
>   Packages that can be upgraded: 11; type ‘U’ to mark
>   for upgrading.
>   
>   (hit U)
>   
>   package-menu--mark-upgrades-1: Wrong type argument:
>   package-desc, nil
>
> Also... can you do it without having to do this

I don't think either of these things should be happening. Do you have
something like this in your init file?

(require 'package)
(setq package-archives
      '(("gnu" . "https://elpa.gnu.org/packages/")
	("melpa" . "https://melpa.org/packages/")
	("org" . "http://orgmode.org/elpa/")))

(tbh even the `require' might not be necessary)

With that, all the load paths should be set correctly. And I wouldn't be
surprised if the earlier error would be resolved as well.

Re: ELPA

[Emanuel Berg via Users list for the GNU Emacs text editor]

Eric Abrahamsen wrote:

> I don't think either of these things should be happening.
> Do you have something like this in your init file?
>
> (require 'package)
> (setq package-archives
>       '(("gnu" . "https://elpa.gnu.org/packages/")
> 	("melpa" . "https://melpa.org/packages/")
> 	("org" . "http://orgmode.org/elpa/")))

Yes, otherwise it wouldn't work at all :)

(setq package-archives
  '(( "gnu elpa" . "https://elpa.gnu.org/packages/")
    (    "melpa" . "https://melpa.org/packages/") )) ; [1]

> (tbh even the `require' might not be necessary)

Maybe not necessary but byte-compiler will complain
without it.

[1] https://dataswamp.org/~incal/emacs-init/elpa.el

-- 
underground experts united
http://user.it.uu.se/~embe8573
https://dataswamp.org/~incal

Re: ELPA

[Eric Abrahamsen]

Emanuel Berg via Users list for the GNU Emacs text editor
<help-gnu-emacs@gnu.org> writes:

> Eric Abrahamsen wrote:
>
>> I don't think either of these things should be happening.
>> Do you have something like this in your init file?
>>
>> (require 'package)
>> (setq package-archives
>>       '(("gnu" . "https://elpa.gnu.org/packages/")
>> 	("melpa" . "https://melpa.org/packages/")
>> 	("org" . "http://orgmode.org/elpa/")))
>
> Yes, otherwise it wouldn't work at all :)

Actually it looks like package-archives defaults to containing gnu and
nongnu, so unless you're installing from melpa you wouldn't even need
that. But that might be a recent change -- what version of Emacs are you
running?

I wonder if you have a package in `package-selected-packages' that no
longer exists, and that's why the update is failing?

Re: ELPA

[Emanuel Berg via Users list for the GNU Emacs text editor]

Eric Abrahamsen wrote:

>>> (require 'package)
>>> (setq package-archives
>>>       '(("gnu" . "https://elpa.gnu.org/packages/")
>>> 	("melpa" . "https://melpa.org/packages/")
>>> 	("org" . "http://orgmode.org/elpa/")))
>>
>> Yes, otherwise it wouldn't work at all :)
>
> Actually it looks like package-archives defaults to
> containing gnu and nongnu, so unless you're installing from
> melpa you wouldn't even need that.

  Original value was (("gnu" . "https://elpa.gnu.org/packages/"))

So yep, could just push melpa then...

> But that might be a recent change -- what version of Emacs
> are you running?

GNU Emacs 28.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version
3.24.5, cairo version 1.16.0) of 2020-10-23

> I wonder if you have a package in
> `package-selected-packages' that no longer exists, and
> that's why the update is failing?

  with-editor w3m vterm timp slime seq quiz markdown-mode
  lua-mode google-translate gnuplot-mode crontab-mode
  ascii-art-to-unicode

-- 
underground experts united
http://user.it.uu.se/~embe8573
https://dataswamp.org/~incal

Re: ELPA

[Eric Abrahamsen]

Emanuel Berg via Users list for the GNU Emacs text editor
<help-gnu-emacs@gnu.org> writes:

> Eric Abrahamsen wrote:
>
>>>> (require 'package)
>>>> (setq package-archives
>>>>       '(("gnu" . "https://elpa.gnu.org/packages/")
>>>> 	("melpa" . "https://melpa.org/packages/")
>>>> 	("org" . "http://orgmode.org/elpa/")))
>>>
>>> Yes, otherwise it wouldn't work at all :)
>>
>> Actually it looks like package-archives defaults to
>> containing gnu and nongnu, so unless you're installing from
>> melpa you wouldn't even need that.
>
>   Original value was (("gnu" . "https://elpa.gnu.org/packages/"))
>
> So yep, could just push melpa then...
>
>> But that might be a recent change -- what version of Emacs
>> are you running?
>
> GNU Emacs 28.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version
> 3.24.5, cairo version 1.16.0) of 2020-10-23
>
>> I wonder if you have a package in
>> `package-selected-packages' that no longer exists, and
>> that's why the update is failing?
>
>   with-editor w3m vterm timp slime seq quiz markdown-mode
>   lua-mode google-translate gnuplot-mode crontab-mode
>   ascii-art-to-unicode

Well that was a red herring. I don't actually know that much about
package.el, sorry! It almost looks more like a problem with
tabulated-list-mode. Would you do M-x toggle-debug-on-error and trigger
the error again, and post the full backtrace? Maybe someone will be able
to make sense of it, or we can do a proper bug report.

Re: ELPA

[Stefan Monnier]

> As for ELPA ... this has happened to me for as long as
> I can remember.
>
>   Packages that can be upgraded: 11; type ‘U’ to mark
>   for upgrading.
>   
>   (hit U)
>   
>   package-menu--mark-upgrades-1: Wrong type argument:
>   package-desc, nil

Sounds like a bug.  Please report it.  And if you can, try to get
a backtrace (e.g. via `M-x toggle-debug-on-error RET`).

> Also... can you do it without having to do this

Not sure what "it" refers to.

>   byte-compile=$(emacs) \
>      -batch \
>      -eval "(setq load-path (append load-path '(\"~/.emacs.d/elpa/gnuplot-mode-20171013.1616/\" \"~/.emacs.d/elpa/vterm-20201004.2057\" \"~/.emacs.d/elpa/markdown-mode-20201015.1327\" \"~/.emacs.d/elpa/w3m-20200818.141\" \"~/.emacs.d/emacs-init\" \"~/.emacs.d/emacs-init/ide\" \"~/.emacs.d/emacs-init/w3m\" \"~/.emacs.d/emacs-init/gnus\" \"~/.emacs.d/elpa/google-translate-20190620.1416\" )))" \
>      -f batch-byte-compile
>
> In the Makefile? (Set the load-path again for every pack, I mean.)

Which Makefile?

I think the answer is something like:

    byte-compile=$(emacs)                      \
       --batch --eval "(package-activate-all)" \
       -f batch-byte-compile


        Stefan

Re: ELPA

[Emanuel Berg via Users list for the GNU Emacs text editor]

Stefan Monnier wrote:

>> Packages that can be upgraded: 11; type ‘U’ to mark
>> for upgrading.
>>   
>> (hit U)
>>   
>> package-menu--mark-upgrades-1: Wrong type argument:
>> package-desc, nil
>
> Sounds like a bug. Please report it. And if you can, try to
> get a backtrace (e.g. via `M-x toggle-debug-on-error RET`).

OK.

>> byte-compile=$(emacs) \
>>   -batch \
>>   -eval "(setq load-path (append load-path '(\"~/.emacs.d/elpa/gnuplot-mode-20171013.1616/\" \"~/.emacs.d/elpa/vterm-20201004.2057\" \"~/.emacs.d/elpa/markdown-mode-20201015.1327\" \"~/.emacs.d/elpa/w3m-20200818.141\" \"~/.emacs.d/emacs-init\" \"~/.emacs.d/emacs-init/ide\" \"~/.emacs.d/emacs-init/w3m\" \"~/.emacs.d/emacs-init/gnus\" \"~/.emacs.d/elpa/google-translate-20190620.1416\" )))" \
>>   -f batch-byte-compile
>>
>> In the Makefile? (Set the load-path again for every pack, I mean.)
>
> Which Makefile?

https://dataswamp.org/~incal/emacs-init/Makefile

> I think the answer is something like:
>
>     byte-compile=$(emacs)                      \
>        --batch --eval "(package-activate-all)" \
>        -f batch-byte-compile

80 errors of this, the same kind:

count.el: 
edit.el: 
buc.el: 
In toplevel form:
align-new.el:7:1: Error: Cannot open load file: No such file or directory, my-string
r-regexp

In toplevel form:
align-new.el:7:1: Error: Cannot open load file: No such file or directory, my-string
r-regexp

align-new.el: 
In toplevel form:
align-new.el:7:1: Error: Cannot open load file: No such file or directory, my-string
r-regexp

...

-- 
underground experts united
http://user.it.uu.se/~embe8573
https://dataswamp.org/~incal

Re: ELPA

[Emanuel Berg via Users list for the GNU Emacs text editor]

Stefan Monnier wrote:

>> Packages that can be upgraded: 11; type ‘U’ to mark
>> for upgrading.
>>   
>> (hit U)
>>   
>> package-menu--mark-upgrades-1: Wrong type argument:
>> package-desc, nil
>
> Sounds like a bug. Please report it. And if you can, try to
> get a backtrace (e.g. via `M-x toggle-debug-on-error RET`).

*Messages*

  Packages that can be upgraded: 10; type ‘U’ to mark for upgrading.
  package-menu--mark-upgrades-1: Wrong type argument: package-desc, nil

*Backtrace*

  Debugger entered--Lisp error: (wrong-type-argument package-desc nil)
  signal(wrong-type-argument (package-desc nil))
  package-menu--mark-upgrades-1()
  package-menu-mark-upgrades()
  funcall-interactively(package-menu-mark-upgrades)
  call-interactively(package-menu-mark-upgrades nil nil)
  command-execute(package-menu-mark-upgrades)

-- 
underground experts united
http://user.it.uu.se/~embe8573
https://dataswamp.org/~incal

Re: ELPA (was: Re: How-to disable persistent *EBDB-Message* buffer?)

[Emanuel Berg via Users list for the GNU Emacs text editor]

> Also... can you do it without having to do this
>
>   byte-compile=$(emacs) \
>      -batch \
>      -eval "(setq load-path (append load-path '(\"~/.emacs.d/elpa/gnuplot-mode-20171013.1616/\" \"~/.emacs.d/elpa/vterm-20201004.2057\" \"~/.emacs.d/elpa/markdown-mode-20201015.1327\" \"~/.emacs.d/elpa/w3m-20200818.141\" \"~/.emacs.d/emacs-init\" \"~/.emacs.d/emacs-init/ide\" \"~/.emacs.d/emacs-init/w3m\" \"~/.emacs.d/emacs-init/gnus\" \"~/.emacs.d/elpa/google-translate-20190620.1416\" )))" \
>      -f batch-byte-compile
>
> In the Makefile? (Set the load-path again for every pack, I mean.)
>
> https://dataswamp.org/~incal/emacs-init/Makefile

You can make it little more photogenic, a little less
error-prone, and give you a little more control by doing THIS,
but it's still the same, manual approach. Looks a lot better
tho so yeah, do it :)

emacs=/usr/local/bin/emacs

ema-path=~/.emacs.d/emacs-init
ema-gnus=\"${ema-path}/gnus\"
ema-ide=\"${ema-path}/ide\"
ema-init=\"${ema-path}\"
ema-w3m=\"${ema-path}/w3m\"
ema=${ema-gnus} ${ema-ide} ${ema-init} ${ema-w3m}

elpa-path=~/.emacs.d/elpa
markdown-mode=\"${elpa-path}/markdown-mode-20201220.253\"
w3m=\"${elpa-path}/w3m-20210104.424\"
elpa=${markdown-mode} ${w3m}

packs=${ema} ${elpa}

byte-compile=$(emacs)                                       \
	--batch                                                  \
	--eval "(setq load-path (append load-path '(${packs})))" \
	-f batch-byte-compile

-- 
underground experts united
http://user.it.uu.se/~embe8573
https://dataswamp.org/~incal

Re: ELPA

[Stefan Monnier]

>>> byte-compile=$(emacs) \
>>>   -batch \
>>>   -eval "(setq load-path (append load-path
>>> '(\"~/.emacs.d/elpa/gnuplot-mode-20171013.1616/\"
>>> \"~/.emacs.d/elpa/vterm-20201004.2057\"
>>> \"~/.emacs.d/elpa/markdown-mode-20201015.1327\"
>>> \"~/.emacs.d/elpa/w3m-20200818.141\" \"~/.emacs.d/emacs-init\"
>>> \"~/.emacs.d/emacs-init/ide\" \"~/.emacs.d/emacs-init/w3m\"
>>> \"~/.emacs.d/emacs-init/gnus\"
>>> \"~/.emacs.d/elpa/google-translate-20190620.1416\" )))" \
>>>   -f batch-byte-compile
>>>
>>> In the Makefile? (Set the load-path again for every pack, I mean.)
>>
>> Which Makefile?
>
> https://dataswamp.org/~incal/emacs-init/Makefile
>
>> I think the answer is something like:
>>
>>     byte-compile=$(emacs)                      \
>>        --batch --eval "(package-activate-all)" \
>>        -f batch-byte-compile
>
> 80 errors of this, the same kind:

I didn't mean for you to use this literally.  Obviously, you'll need to
adapt it to your specific circumstance.  The `package-activate-all`
should take care of all the ~/.emacs.d/elpa/*


        Stefan

Re: ELPA

[Emanuel Berg via Users list for the GNU Emacs text editor]

Stefan Monnier wrote:

>>> I think the answer is something like:
>>>
>>>     byte-compile=$(emacs)                      \
>>>        --batch --eval "(package-activate-all)" \
>>>        -f batch-byte-compile
>>
>> 80 errors of this, the same kind:
>
> I didn't mean for you to use this literally. Obviously,
> you'll need to adapt it to your specific circumstance.
> The `package-activate-all` should take care of all the
> ~/.emacs.d/elpa/*

Yes, that works!

... but I don't know what stuff there is in ~/.emacs.d/elpa/*
- the explicit method seems to offer more control.

emacs=/usr/local/bin/emacs

ema-path=~/.emacs.d/emacs-init
ema-gnus=\"${ema-path}/gnus\"
ema-ide=\"${ema-path}/ide\"
ema-init=\"${ema-path}\"
ema-w3m=\"${ema-path}/w3m\"
ema=${ema-gnus} ${ema-ide} ${ema-init} ${ema-w3m}

byte-compile=$(emacs)                                       \
	--batch                                                  \
   --eval "(package-activate-all)"                          \
	--eval "(setq load-path (append load-path '(${ema})))"   \
	-f batch-byte-compile

-- 
underground experts united
http://user.it.uu.se/~embe8573
https://dataswamp.org/~incal

Re: ELPA

[Stefan Monnier]

>> I didn't mean for you to use this literally. Obviously,
>> you'll need to adapt it to your specific circumstance.
>> The `package-activate-all` should take care of all the
>> ~/.emacs.d/elpa/*
>
> Yes, that works!
>
> ... but I don't know what stuff there is in ~/.emacs.d/elpa/*
> - the explicit method seems to offer more control.

I suggested it based on your request:

    Also... can you do it without having to do this
    [...]
    In the Makefile? (Set the load-path again for every pack, I mean.)

So, either you want to enumerate every pack in order "to offer more
control", or you want to "do it without having to [...] set the
load-path again for every pack".

I don't think you can have your cake and eat it too, tho maybe it's just
me being too pessimistic.


        Stefan

Re: ELPA

[Emanuel Berg via Users list for the GNU Emacs text editor]

Stefan Monnier wrote:

>>> I didn't mean for you to use this literally. Obviously,
>>> you'll need to adapt it to your specific circumstance.
>>> The `package-activate-all` should take care of all the
>>> ~/.emacs.d/elpa/*
>>
>> Yes, that works!
>>
>> ... but I don't know what stuff there is in
>> ~/.emacs.d/elpa/* - the explicit method seems to offer
>> more control.
>
> I suggested it based on your request:
>
>     Also... can you do it without having to do this
>     [...]
>     In the Makefile? (Set the load-path again for every pack, I mean.)
>
> So, either you want to enumerate every pack in order "to
> offer more control", or you want to "do it without having to
> [...] set the load-path again for every pack".
>
> I don't think you can have your cake and eat it too, tho
> maybe it's just me being too pessimistic.

I think there should be a way to recursively add a directory
to the load path, so all the subdirs would be added as well,
but without doing anything else, after that one could compile,
require, load, etc, without restrictions.

-- 
underground experts united
http://user.it.uu.se/~embe8573
https://dataswamp.org/~incal

Re: ELPA

[Emanuel Berg via Users list for the GNU Emacs text editor]

> I think there should be a way to recursively add a directory
> to the load path, so all the subdirs would be added as well,
> but without doing anything else, after that one could
> compile, require, load, etc, without restrictions.

Like this maybe?

(require 'cl-lib)

(defun push-all (base)
  (let ((dirs (cl-remove-if-not
               (lambda (f) (file-accessible-directory-p f))
               (directory-files-recursively base "" t))))
    (setf load-path (nconc dirs load-path) )))

-- 
underground experts united
http://user.it.uu.se/~embe8573
https://dataswamp.org/~incal

Re: ELPA

[Stefan Monnier]

> *Backtrace*
>
>   Debugger entered--Lisp error: (wrong-type-argument package-desc nil)
>   signal(wrong-type-argument (package-desc nil))
>   package-menu--mark-upgrades-1()
>   package-menu-mark-upgrades()
>   funcall-interactively(package-menu-mark-upgrades)
>   call-interactively(package-menu-mark-upgrades nil nil)
>   command-execute(package-menu-mark-upgrades)

Hmm.. from which buffer did you run `package-menu-mark-upgrades`?

If you put point in the like that says

    signal(wrong-type-argument (package-desc nil))

in the backtrace buffer and then do:

   e (point) RET

that should give you the position in the *Packages* buffer where it
found line that for some reason doesn't have the expected
`tabulated-list-id` text-property, so you might want to move to that
position in the buffer and look at that line, maybe select it to get
more info about that package.


        Stefan

Re: ELPA

[Emanuel Berg via Users list for the GNU Emacs text editor]

Stefan Monnier wrote:

> Hmm.. from which buffer did you run
> `package-menu-mark-upgrades`?
>
> If you put point in the like that says
>
>     signal(wrong-type-argument (package-desc nil))
>
> in the backtrace buffer and then do:
>
>    e (point) RET
>
> that should give you the position in the *Packages* buffer

I've now tried several places in *Packages* - the same.

> where it found line that for some reason doesn't have the
> expected `tabulated-list-id` text-property, so you might
> want to move to that position in the buffer and look at that
> line, maybe select it to get more info about that package.

Buffer *Packages*, line 4, column 2, looking-at "2048-game".

U

package-menu--mark-upgrades-1: Wrong type argument:
package-desc, nil

`describe-text-properties', then tabulated-list-id [Show]

#s(package-desc 2048-game
                (20200417 259)
                "play 2048 in Emacs" nil single "melpa" nil
                ((:commit . "aad4a590ea91f9a3256233b9b345e9159c6993f2")
                 (:authors
                  ("Zachary Kanfer" . "zkanfer@gmail.com"))
                 (:maintainer "Zachary Kanfer" . "zkanfer@gmail.com")
                 (:url . "https://hg.sr.ht/~zck/game-2048"))
                nil)
                
-- 
underground experts united
http://user.it.uu.se/~embe8573
https://dataswamp.org/~incal

Re: ELPA

[Stefan Monnier]

>> Hmm.. from which buffer did you run
>> `package-menu-mark-upgrades`?
>>
>> If you put point in the like that says
>>
>>     signal(wrong-type-argument (package-desc nil))
>>
>> in the backtrace buffer and then do:
>>
>>    e (point) RET
>>
>> that should give you the position in the *Packages* buffer
>
> I've now tried several places in *Packages* - the same.

Not sure what you mean "the same", but the value returned by `(point)`
above should not depend on where you are in *Packages* when you do the
`e` or what you do the `U`.  The `U` command will go through the
*Packages* buffer collecting info on each line, and the above `e`
command should tell you at which buffer position it bumped into
a problem.

In any case, I think we need more info about your situation.
E.g. can you reproduce it from `emacs -Q`?
If not, try to reduce your Emacs's init file as much as possible until
you find a recipe to reproduce the problem starting from `emacs -Q`.


        Stefan