From: John Hendy <jw.hendy@gmail.com>
To: David Masterson <dsmasterson@gmail.com>
Cc: emacs-orgmode <emacs-orgmode@gnu.org>
Subject: Re: The Org Package
Date: Sat, 12 Apr 2014 15:07:03 -0500 [thread overview]
Message-ID: <CA+M2ft9aX=oTBD7byPkZ8n=DKHf5jDkLf4fijYPuE2_sjhxfvg@mail.gmail.com> (raw)
In-Reply-To: <86zjjrchmj.fsf@gmail.com>
On Fri, Apr 11, 2014 at 11:10 PM, David Masterson <dsmasterson@gmail.com> wrote:
> John Hendy writes:
>
>> On Fri, Apr 11, 2014 at 9:32 PM, David Masterson wrote:
>
>>> I still need more understanding of the Emacs packaging system.
>>> Something doesn't seem right and I'm sure I'm missing some key in
>>> understanding how its supposed to work. What I see right now seems like
>>> something doesn't match up -- particularly with the Org package:
>>>
>>> 1. Most modern Emacs have Org pre-installed.
>>> 2. Unfortunately, that Org is not up-to-date (24.3 has 7.9.3f).
>>> 3. Therefore, installing the latest Org package seems natural.
>>> 4. However, this does not uninstall the built-in Org package.
>>> 5. Packages are not initialized until after .emacs is run.
>>> 6. Therefore, any of the latest variables are not defined yet.
>>> 7. Therefore, setting a hook may not do what you think.
>>> 8. The documentation for Org suggests hooks (etc.) to set.
>>> 9. I've run into times when org-version was still 7.9.3f.
>>>
>>> Do you see where I'm heading? Does anyone else run into this
>>> problem? Or do most people ignore the Org package and install the
>>> latest from GitHub in a more manual process (a la Bernt Hansen's
>>> paper)? Do we need more concrete documentation on setting up the Org
>>> Package?
>
>> I learned emacs /for/ Org-mode, so keep that in mind as I'm pretty
>> ignorant of emacs in genera. I *think* that packages for emacs are
>> sort of a recent thing, and since I was already using git, I've never
>> bothered to switch my setup. I find git ridiculously easy and have
>> never had a reason to do anything else.
>
> Basically, I'm used to your style here, but let it not be said that I
> didn't, at least, try to be more modern. ;-)
>
>> Once ever:
>>
>> #+begin_src sh
>> mkdir ~/.elisp/
>> cd ~/.elisp
>> git clone [orgmode git path] org.git # I like adding the .git so I
>> know it's a git repo
>> cd org.git
>> make clean && make
>> #+end_src
>
> How do you find the value of "[orgmode git path]"?
Sorry, I was lazy and didn't take time to look it up. Org has
documented this very well. It's right on the main page:
- http://orgmode.org/
That is: ~$ git clone git://orgmode.org/org-mode.git
It's also in the instructions just a bit down on "Staying on the
bleeding edge (Worg)":
- http://orgmode.org/worg/org-faq.html#keeping-current-with-Org-mode-development
That is:
$ git clone git://orgmode.org/org-mode.git # standard repo
$ git clone git://repo.or.cz/org-mode.git # alternate repo
$ git clone http://orgmode.org/org-mode.git # if you can't use git:// (like me)
$ git clone http://repo.or.cz/r/org-mode.git # alternate http
>
>> Then put in config:
>>
>> #+begin_src .emacs
>> (add-to-list 'load-path "~/.elisp/org.git/lisp/")
>> (add-to-list 'load-path "~/.elisp/org.git/contrib/lisp")
>> #+end_src
>
> Where does "/lisp" and "/contrib/lisp" come from? What do they contain?
Not sure exactly what you mean... lisp/ and contrib/lisp/ are simply,
from what I know, where all the .el files for any emacs thingy reside.
You need to tell emacs about the contents of both of those. lisp/
contains the "core" Org stuff, and there are contributed functions in
contrib/lisp that are being evaluated or for whatever reason just not
incorporated into Org yet (I want to say that this might house things
that people who haven't signed FSF legal documents reside, or things
that just aren't quite ready yet).
>
>> That's it. Anywhere between once a week and once every three months, I
>> do:
>>
>> #+begin_src sh
>> cd ~/.elisp/org.git
>> git pull
>> make clean && make
>> #+end_src
>
> Do you run into any problems where something is picked up out of the
> "built-in" Org because of overlapping requires?
Not that I know of, but I never really got a definitive answer (at
least that sunk in my head as the "final verdict" on this thread:
- https://lists.gnu.org/archive/html/emacs-orgmode/2013-09/msg00175.html
Achim and I went back and forth a bit. My understanding from that time
(and from just now re-skimming it) is that as long as `M-x
org-version` shows what you'd expect (a git version) and you don't get
any errors, you're [probably/almost certainly?] safe. My current
output as an example:
M-x org-version
Org-mode version 8.2.5h (release_8.2.5h-881-g957177 @
/home/jwhendy/.elisp/org.git/lisp/)
>
>> Is this more difficult than packages? What is the advantage of ELPA
>> vs. this? I could see it if I had a lot of these sorts of things, but
>> I really just use Org + ESS, so I'm not constantly
>> updating/installing/removing emacs add-ons other than those two.
>
> It's not more difficult and you could probably easily expand on this for
> any number of packages by simply expanding your last shell to walk thru
> all the interesting packages and pull the latest version in.
>
> As far as I can see, ELPA's plus is the GUI for pulling in new versions
> of packages, but its minus is that it moves the package setup *somewhat*
> out of .emacs and into the after-init area. For instance, I'm
> installing org-toodledo which hasn't been packagized yet, so, when you
> (require 'org-toodledo) in your .emacs, the org package is also pulled
> in. However, if you've updated the org package via ELPA, the wrong
> version of org will be pulled in *unless* you (package-initialize) in
> your .emacs. If you follow the basic rules, things work, but the rules
> aren't explicitly documented, so it can be confusing.
>
Not being familiar with ELPA, I really can't comment on how this
works. I will say that I really like the simplicity (or perceived
simplicity!) I've experienced with just using org git. I know where
everything is, I don't run `make install`, so I know that my system is
not littered with files other than where I've cloned the repo, and
to-date I've not had any issues with org setup stuff or alternate
versions (except when I set up a fresh install or something and forget
to add load paths, for example).
Best regards,
John
> --
> David Masterson
>
>
next prev parent reply other threads:[~2014-04-12 20:07 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-04-12 2:32 The Org Package David Masterson
2014-04-12 2:39 ` John Hendy
2014-04-12 4:10 ` David Masterson
2014-04-12 6:01 ` Jacek Generowicz
2014-04-12 20:07 ` John Hendy [this message]
2014-04-15 2:05 ` adam
2014-04-13 1:41 ` Grant Rettke
2014-04-13 7:05 ` Achim Gratz
2014-04-13 7:14 ` Nicolas Richard
2014-04-13 22:27 ` David Masterson
2014-04-14 0:15 ` Thomas S. Dye
2014-04-16 0:04 ` David Masterson
2014-04-16 16:35 ` Achim Gratz
2014-04-14 16:16 ` Achim Gratz
2014-04-17 11:38 ` 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:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.orgmode.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CA+M2ft9aX=oTBD7byPkZ8n=DKHf5jDkLf4fijYPuE2_sjhxfvg@mail.gmail.com' \
--to=jw.hendy@gmail.com \
--cc=dsmasterson@gmail.com \
--cc=emacs-orgmode@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).