Org-mode mailing list
 help / color / mirror / Atom feed
From: Achim Gratz <>
Subject: Re: org-plus-contrib: Invalid function: org-no-popups
Date: Fri, 25 Jan 2013 20:59:58 +0100
Message-ID: <874ni5owxt.fsf@Rainer.invalid> (raw)
In-Reply-To: <>

Bastien writes:
> Achim Gratz <> writes:
>> I happen to think that this suggestion goes too far (if you think nobody
>> should use OIrg from ELPA, then you'd need to stop making it available
>> there and hopefully we already agreed that this isn't an option).  
> No, we did not agreed this isn't an option.

My reading comprehension may be at an all-time low, but this is what you
wrote in another thread:

>>> This [removing Org from ELPA -ed] is using Org users as hostages, I
>>> don't want to do this.

> I think this is an option.

Hm… I'm obviously missing some piece.

> How can you make sure that Org-mode has not been used before people 
> want to install an updated version through GNU/Org ELPA?

That's what the patch does that you didn't like.

> I can't think of any good way.
> Until someone have an idea about this, I'm very serious about removing
> the possibility of installing Org through ELPA.  But as I said I won't
> do this before getting a sense of what the users use and expect.

There are exactly two possibilities to get into this situation:

The first is using Org anything before opening the package manager.  I
think it should be possible to educate users that it's better t use a
fresh Emacs instance for updating or installing packages until this has
been fixed in package manager.

The second are things like starter-kit.  I'm thinking that it should be
the responsibility of such software to load and unload Org if they
really need to use it before activating packages and ask for support
from Emacs devs in how to do this properly.  Package manager is a first
class citizen of Emacs by now which means any add-on has to cope with
its existence.  It's interesting to see that the bugs seem to get
chalked up to the packages that are in ELPA rather than the mechanisms
that install them (or prevent proper initialization of Emacs) and it
kind of seems to fly under the radar for this reason even though it
seems to affect many users and has had for quite some time already.

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

Wavetables for the Waldorf Blofeld:

  parent reply	other threads:[~2013-01-25 20:00 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-01-23 17:42 Moritz Ulrich
2013-01-24 14:08 ` Bastien
2013-01-24 20:42 ` Achim Gratz
2013-01-24 21:59   ` Bastien
2013-01-25  6:48     ` Achim Gratz
2013-01-25  8:51       ` Bastien
2013-01-25 10:33         ` Bastien
2013-01-25 19:59         ` Achim Gratz [this message]
2013-01-26 10:45           ` Bastien
2013-01-26 12:48             ` Achim Gratz
2013-01-26 13:11               ` Bastien

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

  List information:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=874ni5owxt.fsf@Rainer.invalid \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

Org-mode mailing list

This inbox may be cloned and mirrored by anyone:

	git clone --mirror list/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 list list/ \
	public-inbox-index list

Example config snippet for mirrors.
Newsgroups are available over NNTP:

AGPL code for this site: git clone