* How-to disable persistent *EBDB-Message* buffer?
@ 2021-01-04 14:22 Pankaj Jangid
2021-01-04 17:58 ` Eric Abrahamsen
0 siblings, 1 reply; 26+ messages in thread
From: Pankaj Jangid @ 2021-01-04 14:22 UTC (permalink / raw)
To: help-gnu-emacs; +Cc: Eric Abrahamsen
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
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: How-to disable persistent *EBDB-Message* buffer?
2021-01-04 14:22 How-to disable persistent *EBDB-Message* buffer? Pankaj Jangid
@ 2021-01-04 17:58 ` Eric Abrahamsen
2021-01-05 3:47 ` Pankaj Jangid
0 siblings, 1 reply; 26+ messages in thread
From: Eric Abrahamsen @ 2021-01-04 17:58 UTC (permalink / raw)
To: help-gnu-emacs
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
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: How-to disable persistent *EBDB-Message* buffer?
2021-01-04 17:58 ` Eric Abrahamsen
@ 2021-01-05 3:47 ` Pankaj Jangid
2021-01-05 5:03 ` ELPA (was: Re: How-to disable persistent *EBDB-Message* buffer?) Emanuel Berg via Users list for the GNU Emacs text editor
0 siblings, 1 reply; 26+ messages in thread
From: Pankaj Jangid @ 2021-01-05 3:47 UTC (permalink / raw)
To: Eric Abrahamsen; +Cc: help-gnu-emacs
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.
^ permalink raw reply [flat|nested] 26+ messages in thread
* ELPA (was: Re: How-to disable persistent *EBDB-Message* buffer?)
2021-01-05 3:47 ` Pankaj Jangid
@ 2021-01-05 5:03 ` Emanuel Berg via Users list for the GNU Emacs text editor
2021-01-05 17:06 ` ELPA Eric Abrahamsen
` (2 more replies)
0 siblings, 3 replies; 26+ messages in thread
From: Emanuel Berg via Users list for the GNU Emacs text editor @ 2021-01-05 5:03 UTC (permalink / raw)
To: help-gnu-emacs
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
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: ELPA
2021-01-05 5:03 ` ELPA (was: Re: How-to disable persistent *EBDB-Message* buffer?) Emanuel Berg via Users list for the GNU Emacs text editor
@ 2021-01-05 17:06 ` Eric Abrahamsen
2021-01-05 18:15 ` ELPA Emanuel Berg via Users list for the GNU Emacs text editor
2021-01-05 19:45 ` ELPA Stefan Monnier
2021-01-12 19:53 ` ELPA (was: Re: How-to disable persistent *EBDB-Message* buffer?) Emanuel Berg via Users list for the GNU Emacs text editor
2 siblings, 1 reply; 26+ messages in thread
From: Eric Abrahamsen @ 2021-01-05 17:06 UTC (permalink / raw)
To: help-gnu-emacs
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.
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: ELPA
2021-01-05 17:06 ` ELPA Eric Abrahamsen
@ 2021-01-05 18:15 ` Emanuel Berg via Users list for the GNU Emacs text editor
2021-01-05 18:52 ` ELPA Eric Abrahamsen
0 siblings, 1 reply; 26+ messages in thread
From: Emanuel Berg via Users list for the GNU Emacs text editor @ 2021-01-05 18:15 UTC (permalink / raw)
To: help-gnu-emacs
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
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: ELPA
2021-01-05 18:15 ` ELPA Emanuel Berg via Users list for the GNU Emacs text editor
@ 2021-01-05 18:52 ` Eric Abrahamsen
2021-01-05 18:57 ` ELPA Emanuel Berg via Users list for the GNU Emacs text editor
0 siblings, 1 reply; 26+ messages in thread
From: Eric Abrahamsen @ 2021-01-05 18:52 UTC (permalink / raw)
To: help-gnu-emacs
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?
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: ELPA
2021-01-05 18:52 ` ELPA Eric Abrahamsen
@ 2021-01-05 18:57 ` Emanuel Berg via Users list for the GNU Emacs text editor
2021-01-05 19:27 ` ELPA Eric Abrahamsen
0 siblings, 1 reply; 26+ messages in thread
From: Emanuel Berg via Users list for the GNU Emacs text editor @ 2021-01-05 18:57 UTC (permalink / raw)
To: help-gnu-emacs
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
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: ELPA
2021-01-05 18:57 ` ELPA Emanuel Berg via Users list for the GNU Emacs text editor
@ 2021-01-05 19:27 ` Eric Abrahamsen
0 siblings, 0 replies; 26+ messages in thread
From: Eric Abrahamsen @ 2021-01-05 19:27 UTC (permalink / raw)
To: help-gnu-emacs
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.
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: ELPA
2021-01-05 5:03 ` ELPA (was: Re: How-to disable persistent *EBDB-Message* buffer?) Emanuel Berg via Users list for the GNU Emacs text editor
2021-01-05 17:06 ` ELPA Eric Abrahamsen
@ 2021-01-05 19:45 ` Stefan Monnier
2021-01-05 21:37 ` ELPA Emanuel Berg via Users list for the GNU Emacs text editor
2021-01-12 19:53 ` ELPA (was: Re: How-to disable persistent *EBDB-Message* buffer?) Emanuel Berg via Users list for the GNU Emacs text editor
2 siblings, 1 reply; 26+ messages in thread
From: Stefan Monnier @ 2021-01-05 19:45 UTC (permalink / raw)
To: help-gnu-emacs
> 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
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: ELPA
2021-01-05 19:45 ` ELPA Stefan Monnier
@ 2021-01-05 21:37 ` Emanuel Berg via Users list for the GNU Emacs text editor
2021-01-12 18:00 ` ELPA Emanuel Berg via Users list for the GNU Emacs text editor
2021-01-12 20:21 ` ELPA Stefan Monnier
0 siblings, 2 replies; 26+ messages in thread
From: Emanuel Berg via Users list for the GNU Emacs text editor @ 2021-01-05 21:37 UTC (permalink / raw)
To: help-gnu-emacs
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
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: ELPA
2021-01-05 21:37 ` ELPA Emanuel Berg via Users list for the GNU Emacs text editor
@ 2021-01-12 18:00 ` Emanuel Berg via Users list for the GNU Emacs text editor
2021-01-12 22:21 ` ELPA Stefan Monnier
2021-01-12 20:21 ` ELPA Stefan Monnier
1 sibling, 1 reply; 26+ messages in thread
From: Emanuel Berg via Users list for the GNU Emacs text editor @ 2021-01-12 18:00 UTC (permalink / raw)
To: help-gnu-emacs
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
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: ELPA
2021-01-12 18:00 ` ELPA Emanuel Berg via Users list for the GNU Emacs text editor
@ 2021-01-12 22:21 ` Stefan Monnier
2021-01-12 23:02 ` ELPA Emanuel Berg via Users list for the GNU Emacs text editor
0 siblings, 1 reply; 26+ messages in thread
From: Stefan Monnier @ 2021-01-12 22:21 UTC (permalink / raw)
To: help-gnu-emacs
> *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
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: ELPA
2021-01-12 22:21 ` ELPA Stefan Monnier
@ 2021-01-12 23:02 ` Emanuel Berg via Users list for the GNU Emacs text editor
2021-01-13 15:01 ` ELPA Stefan Monnier
0 siblings, 1 reply; 26+ messages in thread
From: Emanuel Berg via Users list for the GNU Emacs text editor @ 2021-01-12 23:02 UTC (permalink / raw)
To: help-gnu-emacs
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
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: ELPA
2021-01-12 23:02 ` ELPA Emanuel Berg via Users list for the GNU Emacs text editor
@ 2021-01-13 15:01 ` Stefan Monnier
0 siblings, 0 replies; 26+ messages in thread
From: Stefan Monnier @ 2021-01-13 15:01 UTC (permalink / raw)
To: help-gnu-emacs
>> 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
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: ELPA
2021-01-05 21:37 ` ELPA Emanuel Berg via Users list for the GNU Emacs text editor
2021-01-12 18:00 ` ELPA Emanuel Berg via Users list for the GNU Emacs text editor
@ 2021-01-12 20:21 ` Stefan Monnier
2021-01-12 20:23 ` ELPA Emanuel Berg via Users list for the GNU Emacs text editor
1 sibling, 1 reply; 26+ messages in thread
From: Stefan Monnier @ 2021-01-12 20:21 UTC (permalink / raw)
To: help-gnu-emacs
>>> 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
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: ELPA
2021-01-12 20:21 ` ELPA Stefan Monnier
@ 2021-01-12 20:23 ` Emanuel Berg via Users list for the GNU Emacs text editor
2021-01-12 21:29 ` ELPA Stefan Monnier
0 siblings, 1 reply; 26+ messages in thread
From: Emanuel Berg via Users list for the GNU Emacs text editor @ 2021-01-12 20:23 UTC (permalink / raw)
To: help-gnu-emacs
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
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: ELPA
2021-01-12 20:23 ` ELPA Emanuel Berg via Users list for the GNU Emacs text editor
@ 2021-01-12 21:29 ` Stefan Monnier
2021-01-12 21:35 ` ELPA Emanuel Berg via Users list for the GNU Emacs text editor
0 siblings, 1 reply; 26+ messages in thread
From: Stefan Monnier @ 2021-01-12 21:29 UTC (permalink / raw)
To: help-gnu-emacs
>> 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
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: ELPA
2021-01-12 21:29 ` ELPA Stefan Monnier
@ 2021-01-12 21:35 ` Emanuel Berg via Users list for the GNU Emacs text editor
2021-01-12 21:57 ` ELPA Emanuel Berg via Users list for the GNU Emacs text editor
0 siblings, 1 reply; 26+ messages in thread
From: Emanuel Berg via Users list for the GNU Emacs text editor @ 2021-01-12 21:35 UTC (permalink / raw)
To: help-gnu-emacs
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
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: ELPA
2021-01-12 21:35 ` ELPA Emanuel Berg via Users list for the GNU Emacs text editor
@ 2021-01-12 21:57 ` Emanuel Berg via Users list for the GNU Emacs text editor
0 siblings, 0 replies; 26+ messages in thread
From: Emanuel Berg via Users list for the GNU Emacs text editor @ 2021-01-12 21:57 UTC (permalink / raw)
To: help-gnu-emacs
> 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
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: ELPA (was: Re: How-to disable persistent *EBDB-Message* buffer?)
2021-01-05 5:03 ` ELPA (was: Re: How-to disable persistent *EBDB-Message* buffer?) Emanuel Berg via Users list for the GNU Emacs text editor
2021-01-05 17:06 ` ELPA Eric Abrahamsen
2021-01-05 19:45 ` ELPA Stefan Monnier
@ 2021-01-12 19:53 ` Emanuel Berg via Users list for the GNU Emacs text editor
2 siblings, 0 replies; 26+ messages in thread
From: Emanuel Berg via Users list for the GNU Emacs text editor @ 2021-01-12 19:53 UTC (permalink / raw)
To: help-gnu-emacs
> 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
^ permalink raw reply [flat|nested] 26+ messages in thread
* [PROPOSAL] Quick and easy installation instructions
@ 2010-09-26 13:33 Dan Davison
2010-09-26 17:37 ` Achim Gratz
0 siblings, 1 reply; 26+ messages in thread
From: Dan Davison @ 2010-09-26 13:33 UTC (permalink / raw)
To: emacs org-mode mailing list
I think that the documentation concerning installation should be made
more user-friendly. My impression is that the Org manual makes all this
sound much harder than it needs to be, and I suspect that this is an
entry-barrier for new Org users. For example, the first thing users
encounter in the manual section is an instruction to edit a Makefile.
I suggest we provide a "quick and easy installation" section to the
manual, that shows people how to start using the latest version of
Org-mode without messing about with compilation and installation (I
rarely compile and have never "installed" Org-mode). It would also be
helpful to include notes on how to find your ".emacs" file.
This would involve the following changes to section 1.2 Installation:
1. The first thing it should say would be along the lines of
"A reasonably recent version of Org is included in Emacs. Are you
sure you need the latest version of Org? If not, skip to the
Activation section and start using Org!"
2. Then we should lay out an easy route and a full route:
1. Quick and easy
Download, set your load-path and (require 'org-install)
Optionally compile (within emacs[1]?)
Suggested text below.
2. Full install
Based on existing instructions
What do people think? Is it just the info files which are the issue?
What does a single-user machine gain from installation other than info
files?
Dan
Footnotes:
[1] How about including in Org-mode a function `org-compile' based on
http://orgmode.org/worg/org-hacks.php#compiling-org-without-make
and `org-reload'
Example quick and Easy installation text:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1. Download the latest version
.zip and .tar.gz version are kept at
http://orgmode.org/org-latest.zip
http://orgmode.org/org-latest.tar.gz
2. Extract the archived files
This will create a folder called "org-mode". Let's say that the
location of this folder is "~/path/to/org-mode" (for Windows see
footnote [1])
3. Add the following lines to your .emacs file (note that we're pointing
to the "lisp" folder *within* the main "org-mode" folder):
(setq load-path (cons "~/path/to/org-mode/lisp" load-path)
(require 'org-install)
That's it. However, this will not install the latest info files, so
these will be out of date (corresponding to whatever version of Org
shipped with your emacs). See XXXX for instructions on installing the
info files.
Now, Emacs should load whatever version of Org-mode you put at
"~/path/to/org-mode". So to update Org in the future, simply delete that
folder and replace it with a new one (steps 1 and 2 above).
Footnotes:
[1] On Windows, this path might look something like
"C:\\path\to\org-mode"
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [PROPOSAL] Quick and easy installation instructions
2010-09-26 13:33 [PROPOSAL] Quick and easy installation instructions Dan Davison
@ 2010-09-26 17:37 ` Achim Gratz
2010-09-26 18:22 ` Dan Davison
0 siblings, 1 reply; 26+ messages in thread
From: Achim Gratz @ 2010-09-26 17:37 UTC (permalink / raw)
To: emacs-orgmode
Dan Davison <davison@stats.ox.ac.uk> writes:
> I think that the documentation concerning installation should be made
> more user-friendly. My impression is that the Org manual makes all this
> sound much harder than it needs to be, and I suspect that this is an
> entry-barrier for new Org users. For example, the first thing users
> encounter in the manual section is an instruction to edit a Makefile.
Agreed. It was easy enough to follow for me, but I can see that others
may find it too technical.
> I suggest we provide a "quick and easy installation" section to the
> manual, that shows people how to start using the latest version of
> Org-mode without messing about with compilation and installation (I
> rarely compile and have never "installed" Org-mode). It would also be
> helpful to include notes on how to find your ".emacs" file.
Just as a counter-point, I always compile and install (even bleeding
edge, that just goes into a different place) because that allows me to
separate production from experimental code more easily.
> This would involve the following changes to section 1.2 Installation:
>
> 1. The first thing it should say would be along the lines of
> "A reasonably recent version of Org is included in Emacs. Are you
> sure you need the latest version of Org? If not, skip to the
> Activation section and start using Org!"
Don't assume what version of Emacs the user may have and it may be
configured in crazy ways, too. To read the instructions one would
already have had to find and go to orgmode.org, so there is little
further effort to fix them up with the latest stable version. Right now
there is no official Emacs release that uses Org 7.x, for instance.
> 2. Then we should lay out an easy route and a full route:
> 1. Quick and easy
> Download, set your load-path and (require 'org-install)
> Optionally compile (within emacs[1]?)
> Suggested text below.
I'd really suggest putting it into site-lisp as that removes the need to
muck about with load-path (which isn't customizable...), the dangers of
which you demonstrate yourself:
> (setq load-path (cons "~/path/to/org-mode/lisp" load-path)
(yes, just a missing closing paren). The other thing of course is that
by putting it there all other users on the system will benefit from it.
That's a plus even under Windows.
While we are at it, I think both org and org-babel have enough files to
better go into sub-directories (maybe org-install should stay on
top-level).
Achim.
--
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+
SD adaptation for Waldorf Blofeld V1.15B11:
http://Synth.Stromeko.net/Downloads.html#WaldorfSDada
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [PROPOSAL] Quick and easy installation instructions
2010-09-26 17:37 ` Achim Gratz
@ 2010-09-26 18:22 ` Dan Davison
2010-09-26 19:27 ` Achim Gratz
0 siblings, 1 reply; 26+ messages in thread
From: Dan Davison @ 2010-09-26 18:22 UTC (permalink / raw)
To: Achim Gratz; +Cc: emacs-orgmode
Achim Gratz <Stromeko@nexgo.de> writes:
> Dan Davison <davison@stats.ox.ac.uk> writes:
>
>> I think that the documentation concerning installation should be made
>> more user-friendly. My impression is that the Org manual makes all this
>> sound much harder than it needs to be, and I suspect that this is an
>> entry-barrier for new Org users. For example, the first thing users
>> encounter in the manual section is an instruction to edit a Makefile.
>
> Agreed. It was easy enough to follow for me, but I can see that others
> may find it too technical.
Hi Achim,
OK, so we're agreed. But your points below don't seem to describe a less
technical route. Could you describe the less technical version of the
instructions for the method that you are advocating?
Dan
>
>> I suggest we provide a "quick and easy installation" section to the
>> manual, that shows people how to start using the latest version of
>> Org-mode without messing about with compilation and installation (I
>> rarely compile and have never "installed" Org-mode). It would also be
>> helpful to include notes on how to find your ".emacs" file.
>
> Just as a counter-point, I always compile and install (even bleeding
> edge, that just goes into a different place) because that allows me to
> separate production from experimental code more easily.
>
>> This would involve the following changes to section 1.2 Installation:
>>
>> 1. The first thing it should say would be along the lines of
>> "A reasonably recent version of Org is included in Emacs. Are you
>> sure you need the latest version of Org? If not, skip to the
>> Activation section and start using Org!"
>
> Don't assume what version of Emacs the user may have and it may be
> configured in crazy ways, too. To read the instructions one would
> already have had to find and go to orgmode.org, so there is little
> further effort to fix them up with the latest stable version. Right now
> there is no official Emacs release that uses Org 7.x, for instance.
>
>> 2. Then we should lay out an easy route and a full route:
>> 1. Quick and easy
>> Download, set your load-path and (require 'org-install)
>> Optionally compile (within emacs[1]?)
>> Suggested text below.
>
> I'd really suggest putting it into site-lisp as that removes the need to
> muck about with load-path (which isn't customizable...), the dangers of
> which you demonstrate yourself:
>
>> (setq load-path (cons "~/path/to/org-mode/lisp" load-path)
>
> (yes, just a missing closing paren). The other thing of course is that
> by putting it there all other users on the system will benefit from it.
> That's a plus even under Windows.
>
> While we are at it, I think both org and org-babel have enough files to
> better go into sub-directories (maybe org-install should stay on
> top-level).
>
>
> Achim.
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [PROPOSAL] Quick and easy installation instructions
2010-09-26 18:22 ` Dan Davison
@ 2010-09-26 19:27 ` Achim Gratz
2010-09-26 20:57 ` ELPA [WAS] " Dan Davison
0 siblings, 1 reply; 26+ messages in thread
From: Achim Gratz @ 2010-09-26 19:27 UTC (permalink / raw)
To: emacs-orgmode
Dan Davison <davison@stats.ox.ac.uk> writes:
> OK, so we're agreed. But your points below don't seem to describe a less
> technical route. Could you describe the less technical version of the
> instructions for the method that you are advocating?
Installing is something technical and I'm a tech-head, so you're asking
something of me I'm not really qualified to do. :-)
My points were:
- I think that a proper installation via make is the way to go, but I
recognize that some folks don't want or need to do that.
- There is a default place where Emacs expects this kind of stuff and
has some magic implemented to make it work without further
configuration, and that place is site-lisp. You can put it someplace
else, but then you have to alter the load-path or you are at the mercy
of some special configuration to make the same magic work in other
places, too (I've had ~/lisp set up that way when I was still
compiling Emacs myself).
- If org was delivered and compiled in 'org/' rather than 'lisp/', one
could instruct users to just take that folder and copy/drag it into
the site-lisp directory of their Emacs installation. You can do that
with the lisp folder, but I'd at least tell people to please rename it
to org after doing the copy.
If you want to get any less technical than that, I'd suggest ELPA or
something like it (as has been discussed already in another thread).
ELPA packages build and configure themselves as far as possible, so that
should take out the guesswork for novice users. Also it looks like it
will come standard with Emacs24 (with a GNU archive and the possibility
to add additional archives, which could take care of the "bleeding
edge"), so there will be absolutely no "installation" work required from
the user from then on.
Regards,
Achim.
--
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+
DIY Stuff:
http://Synth.Stromeko.net/DIY.html
^ permalink raw reply [flat|nested] 26+ messages in thread
* ELPA [WAS] Re: [PROPOSAL] Quick and easy installation instructions
2010-09-26 19:27 ` Achim Gratz
@ 2010-09-26 20:57 ` Dan Davison
2010-09-28 10:52 ` Scot Becker
0 siblings, 1 reply; 26+ messages in thread
From: Dan Davison @ 2010-09-26 20:57 UTC (permalink / raw)
To: Achim Gratz; +Cc: emacs-orgmode
Achim Gratz <Stromeko@nexgo.de> writes:
> Dan Davison <davison@stats.ox.ac.uk> writes:
>> OK, so we're agreed. But your points below don't seem to describe a less
>> technical route. Could you describe the less technical version of the
>> instructions for the method that you are advocating?
>
> Installing is something technical and I'm a tech-head, so you're asking
> something of me I'm not really qualified to do. :-)
>
> My points were:
>
> - I think that a proper installation via make is the way to go, but I
> recognize that some folks don't want or need to do that.
>
> - There is a default place where Emacs expects this kind of stuff and
> has some magic implemented to make it work without further
> configuration, and that place is site-lisp. You can put it someplace
> else, but then you have to alter the load-path or you are at the mercy
> of some special configuration to make the same magic work in other
> places, too (I've had ~/lisp set up that way when I was still
> compiling Emacs myself).
>
> - If org was delivered and compiled in 'org/' rather than 'lisp/', one
> could instruct users to just take that folder and copy/drag it into
> the site-lisp directory of their Emacs installation. You can do that
> with the lisp folder, but I'd at least tell people to please rename it
> to org after doing the copy.
>
> If you want to get any less technical than that, I'd suggest ELPA or
> something like it (as has been discussed already in another thread).
> ELPA packages build and configure themselves as far as possible, so that
> should take out the guesswork for novice users. Also it looks like it
> will come standard with Emacs24 (with a GNU archive and the possibility
> to add additional archives, which could take care of the "bleeding
> edge"), so there will be absolutely no "installation" work required from
> the user from then on.
Hi Achim,
Thanks, that was very helpful.
Using ELPA does seem like an attractive route, especially if it
(package.el) is going to be in Emacs24.
- How much work would it take to put and maintain Org-mode on ELPA?
- Would it make sense to have two different packages available via ELPA,
i.e. Latest Release and Latest?
- Will it be possible for the Org project to have control over the files
that ELPA points at (in which case we might be able to keep the latest
updated a few times a day or something), or do we have to submit them
to a server that's out of our control?
- Will ELPA be able to get the info files installed suitably?
Dan
>
>
> Regards,
> Achim.
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: ELPA [WAS] Re: [PROPOSAL] Quick and easy installation instructions
2010-09-26 20:57 ` ELPA [WAS] " Dan Davison
@ 2010-09-28 10:52 ` Scot Becker
2010-09-28 17:48 ` ELPA Eric Schulte
0 siblings, 1 reply; 26+ messages in thread
From: Scot Becker @ 2010-09-28 10:52 UTC (permalink / raw)
To: Dan Davison; +Cc: Achim Gratz, emacs-orgmode
Dan,
I have no special expertise on this, but I'll hazzard an answer as a
simple ELPA user:
> Using ELPA does seem like an attractive route, especially if it
> (package.el) is going to be in Emacs24.
To me too, ELPA is a great idea. It probably needs some perfecting,
but if it works for these purposes, we only help the perfecting by
encouraging it's use.
> - How much work would it take to put and maintain Org-mode on ELPA?
I'll let someone else answer that, but I'd be suprised if it couldn't
be automated.
> - 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.
> - Will it be possible for the Org project to have control over the files
An excellent and important question. We'd rather not be dependent on
personal intervention from others to update, especially the '-latest'
version. And even for the releases, we'd probably be glad to see them
propagate to the repository pretty quickly. (The current non-gnu ELPA
repo only updates every two weeks or so. This is fine for many
projects, but probably not enough even for org-mode releases.)
> - Will ELPA be able to get the info files installed suitably?
In principle, yes. ELPA does concern itself with both the load-path
and the info-path.
Scot
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: ELPA
2010-09-28 10:52 ` Scot Becker
@ 2010-09-28 17:48 ` Eric Schulte
2010-09-28 18:35 ` ELPA Sebastian Rose
` (2 more replies)
0 siblings, 3 replies; 26+ messages in thread
From: Eric Schulte @ 2010-09-28 17:48 UTC (permalink / raw)
To: Scot Becker; +Cc: Dan Davison, Achim Gratz, emacs-orgmode
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
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: ELPA
2010-09-28 17:48 ` ELPA Eric Schulte
@ 2010-09-28 18:35 ` Sebastian Rose
2010-09-28 18:59 ` ELPA Achim Gratz
2010-09-28 20:43 ` ELPA Scot Becker
2 siblings, 0 replies; 26+ messages in thread
From: Sebastian Rose @ 2010-09-28 18:35 UTC (permalink / raw)
To: Eric Schulte; +Cc: Dan Davison, Achim Gratz, emacs-orgmode
"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
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: ELPA
2010-09-28 17:48 ` ELPA Eric Schulte
2010-09-28 18:35 ` ELPA Sebastian Rose
@ 2010-09-28 18:59 ` Achim Gratz
2010-09-28 19:09 ` ELPA Richard Riley
2010-09-28 20:43 ` ELPA Scot Becker
2 siblings, 1 reply; 26+ messages in thread
From: Achim Gratz @ 2010-09-28 18:59 UTC (permalink / raw)
To: emacs-orgmode
"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
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: ELPA
2010-09-28 18:59 ` ELPA Achim Gratz
@ 2010-09-28 19:09 ` Richard Riley
0 siblings, 0 replies; 26+ messages in thread
From: Richard Riley @ 2010-09-28 19:09 UTC (permalink / raw)
To: emacs-orgmode
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?
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: ELPA
2010-09-28 17:48 ` ELPA Eric Schulte
2010-09-28 18:35 ` ELPA Sebastian Rose
2010-09-28 18:59 ` ELPA Achim Gratz
@ 2010-09-28 20:43 ` Scot Becker
2 siblings, 0 replies; 26+ messages in thread
From: Scot Becker @ 2010-09-28 20:43 UTC (permalink / raw)
To: Eric Schulte; +Cc: Dan Davison, Achim Gratz, emacs-orgmode
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?
^ permalink raw reply [flat|nested] 26+ messages in thread
end of thread, other threads:[~2021-01-13 15:01 UTC | newest]
Thread overview: 26+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2021-01-04 14:22 How-to disable persistent *EBDB-Message* buffer? Pankaj Jangid
2021-01-04 17:58 ` Eric Abrahamsen
2021-01-05 3:47 ` Pankaj Jangid
2021-01-05 5:03 ` ELPA (was: Re: How-to disable persistent *EBDB-Message* buffer?) Emanuel Berg via Users list for the GNU Emacs text editor
2021-01-05 17:06 ` ELPA Eric Abrahamsen
2021-01-05 18:15 ` ELPA Emanuel Berg via Users list for the GNU Emacs text editor
2021-01-05 18:52 ` ELPA Eric Abrahamsen
2021-01-05 18:57 ` ELPA Emanuel Berg via Users list for the GNU Emacs text editor
2021-01-05 19:27 ` ELPA Eric Abrahamsen
2021-01-05 19:45 ` ELPA Stefan Monnier
2021-01-05 21:37 ` ELPA Emanuel Berg via Users list for the GNU Emacs text editor
2021-01-12 18:00 ` ELPA Emanuel Berg via Users list for the GNU Emacs text editor
2021-01-12 22:21 ` ELPA Stefan Monnier
2021-01-12 23:02 ` ELPA Emanuel Berg via Users list for the GNU Emacs text editor
2021-01-13 15:01 ` ELPA Stefan Monnier
2021-01-12 20:21 ` ELPA Stefan Monnier
2021-01-12 20:23 ` ELPA Emanuel Berg via Users list for the GNU Emacs text editor
2021-01-12 21:29 ` ELPA Stefan Monnier
2021-01-12 21:35 ` ELPA Emanuel Berg via Users list for the GNU Emacs text editor
2021-01-12 21:57 ` ELPA Emanuel Berg via Users list for the GNU Emacs text editor
2021-01-12 19:53 ` ELPA (was: Re: How-to disable persistent *EBDB-Message* buffer?) Emanuel Berg via Users list for the GNU Emacs text editor
-- strict thread matches above, loose matches on Subject: below --
2010-09-26 13:33 [PROPOSAL] Quick and easy installation instructions Dan Davison
2010-09-26 17:37 ` Achim Gratz
2010-09-26 18:22 ` Dan Davison
2010-09-26 19:27 ` Achim Gratz
2010-09-26 20:57 ` ELPA [WAS] " Dan Davison
2010-09-28 10:52 ` Scot Becker
2010-09-28 17:48 ` ELPA Eric Schulte
2010-09-28 18:35 ` ELPA Sebastian Rose
2010-09-28 18:59 ` ELPA Achim Gratz
2010-09-28 19:09 ` ELPA Richard Riley
2010-09-28 20:43 ` ELPA Scot Becker
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.