Bastien <[email protected]> writes: Hi Bastien,
your post touches two topics that I'm currently dealing with, so here are two questions with regards to this topics: (1) >> I'm not certain why the distributor refers to this as "a rather >> drastic measure." From my perspective as a user, whose interests >> required using the git version of Org from the beginning, the Emacs >> distribution of Org has been nothing but trouble, leading to >> perplexing (for me) problems with mixed installs that I would rather >> have avoided. > > The distribution of Org as a built-in package in Emacs is *not* the > problem. > > Installing Org through git or through .tar.gz/.zip on top of the Emacs > distribution does not create problems if you follow the instructions > in the manual -- I made a special effort to simplify them. I recently experienced some casual trouble when updating Org-mode from Git (I simply updated at a moment, when actual org.el wouldn't load due to a bug that was to be fixed soon fixed soon. Here is the related thread on the mailing list: [[gnus:nntp%2Bnews.gmane.org:gmane.emacs.orgmode#[email protected]][Email from Thorsten Jolitz: Re: {BUG} `org-load-noerror-m]] In this thread, I was told that I'm causing 'a future train wreck' with my habit to simply trash the org folder from the Emacs installation and replace it with a symlink to the git version in my home dir (I had enough trouble with mixed installs, and this seems to avoid them - having only the git version, no Elpa and no Emacs version). Now I was told there will be troubles with the autoloads, and I would like to understand better what the possible implications are. I do 'make autoloads' in the git version of org, so there is a loaddefs.el. There is of course another loaddefs.el in the Emacs directory that is not updated when I replace the Emacs org folder with a symlink to the (slightly different) git version. Is there really 'big trouble' possible due to this? Should I run 'make autoloads' in the Emacs installation directory again? (2) > Also, I consider outline.el to be completely unusable, and Org is > first an enhanced version of it, which Emacs strongly needs. I plan > to push so that files in Emacs use org.el when they use outline.el. When I started with Emacs, I had one .emacs init-file that became more and more chaotic over time (and a real pain for navigation and maintainment). Then I started to use a multi-file set-up, first Elisp files, then using .org files via the starter-kit. Now I know about M-x occur and recently discovered that outline-minor-mode enables me to define my own outline-regexps in an .el file, so I'm back to the start - using one big /.emacs.d/init.el, but this time with all the outline functionality. Here is a short excerpt from the init.el, showing that my outline-headings just look like outcommented org-headings: ,---------------------------------------------------- | ;; * Recovery from Problems | | ;; ** Debugging | | (when section-debugging (message "99 Debugging...") | | ... | | (message "99 Debugging... Done")) | | ;; Local Variables: | ;; coding: utf-8 | ;; mode: emacs-lisp | ;; eval: (outline-minor-mode) | ... | ;; outline-regexp: ";; [*]+ " | ;; End: `---------------------------------------------------- Except for the extraordinary weird key-bindings of outline-minor-mode (e.g. C-c @ C-n), that I still did not manage to override (with the usual Org-mode bindings), I'm very satisfied with this set-up, it gives me the best of both worlds (full outline functionality and the very simple and direct approach of having just one init.el). Why do you consider outline(-minor-mode) as completely unusable? And how would you replace it in my use case with org(-struct?)? I'm asking just out of curiosity, and to learn a bit more, there are no urgent problems to be solved on my side here. -- cheers, Thorsten
