Moving my init.el to Org

Moving my init.el to Org

[Marcin Borkowski]

OK,

so the time has come.  Either I'll declare .emacs bankruptcy soon, or
I'll use Org-mode to structure it.

I googled for a while, but couldn't find what I'm looking for: a list
of options with hints (or links to hints) about how to get started, and
possibly their pros and cons.

I know that I could use org-babel-load-file, or outshine.  What are
other possibilities?  What are the caveats (and advantages) of both
(other?) ways?

I am pretty sure that my question *can* be answered by RTFM (Worg
page? some blog post?), so please link the FM if possible.

Best,

-- 
Marcin Borkowski
http://octd.wmi.amu.edu.pl/en/Marcin_Borkowski
Adam Mickiewicz University

Re: Moving my init.el to Org

[Thorsten Jolitz]

Marcin Borkowski <mbork@wmi.amu.edu.pl> writes:

> so the time has come.  Either I'll declare .emacs bankruptcy soon, or
> I'll use Org-mode to structure it.
>
> I googled for a while, but couldn't find what I'm looking for: a list
> of options with hints (or links to hints) about how to get started, and
> possibly their pros and cons.
>
> I know that I could use org-babel-load-file, or outshine.  What are
> other possibilities?  What are the caveats (and advantages) of both
> (other?) ways?

I'm obviously very biased (as outshine author), but the reason outshine
exists is that I became frustrated with my init.org. It was a definite
improvement over my former .emacs though, without any Org like
structure, but with a strong tendency towards chaos and anarchy ... ;)

With outshine I have many of Org-mode's advantages (and using outorg I
can turn my elisp file into an org file in a second and have all of
them), but its still just about a source-file in emacs-lisp-mode, and
thats what makes things convenient, fast and dynamic.

This is a typical use-case where the source-code is (much) more
important than the text - I almost never go to my init.el to read my
comments in there, I always go there to find and modify elisp code, and
that should be as quick and easy as possible, with no intermediate steps
like calling special-edit-buffers or tangling, and no possible confusion
and out-of-sync problems between .el and .org versions of the same file.

OTOH, when you consider your init-file as a kind of complex publication
to be shared with others, like e.g. Bernt Hansen's famous tutorial, then
the text becomes more important and it will feel more natural to keep
your configurations in a text-mode like org-mode.

Just my 2c

-- 
cheers,
Thorsten

Re: Moving my init.el to Org

[Thorsten Jolitz]

Thorsten Jolitz <tjolitz@gmail.com> writes:

> Marcin Borkowski <mbork@wmi.amu.edu.pl> writes:
>
>> so the time has come.  Either I'll declare .emacs bankruptcy soon, or
>> I'll use Org-mode to structure it.

BTW, here is (a variation of) my init.el as an Outshine example:

https://raw.githubusercontent.com/tj64/org-bandbook/master/bandbook-init.el

-- 
cheers,
Thorsten

Re: Moving my init.el to Org

[Rasmus]

Hi Marcin,

Marcin Borkowski <mbork@wmi.amu.edu.pl> writes:

> so the time has come.  Either I'll declare .emacs bankruptcy soon, or
> I'll use Org-mode to structure it.
>
> I googled for a while, but couldn't find what I'm looking for: a list
> of options with hints (or links to hints) about how to get started, and
> possibly their pros and cons.
>
> I know that I could use org-babel-load-file, or outshine.  What are
> other possibilities?  What are the caveats (and advantages) of both
> (other?) ways?

I started with a org init file, but it was too much hazel — maybe
because it was split across files.  I now manage a single 4400 LOC
init file.

Now I use isearch and orgstruct-mode, a minor mode allowing org-like
folding.  I have the following in the top of my init file.

;; -*- orgstruct-heading-prefix-regexp: ";;" -*-

If you want, you could load orgstruct automatically with

;; Local Variables:
;; eval: (orgstruct-mode)
;; End:

in the bottom, but this will mean that Org is loaded automatically a
init, which I would advice against if you enjoy fast Emacs init.

—Rasmus

-- 
Hooray!

Re: Moving my init.el to Org

[Grant Rettke]

Good morning,

There are as many /right ways/ to use `org' for *literate programming*
as there are flowers. They are all delightful and everyone has their own
personal preference.

My personal preference is to embrace /literate programming/ in the
truest sense of the word: the document everything. It is for humans, and
computers, and anything else that needs to read it in any form
whatsoever.

My primary audience is myself, but since I am an English speaking human
others may value it, too, but it is all personal preference.

Here are some direct links:
• [The human readable part]
• [The Emacs readable part]
• [All of the artifacts]

[The human readable part]
https://github.com/grettke/home/blob/master/TC3F.txt

[The Emacs readable part]
https://github.com/grettke/home/blob/master/.emacs.el

[All of the artifacts] https://github.com/grettke/home

Kind regards,

Grant Rettke | ACM, ASA, FSF
gcr@wisdomandwonder.com | http://www.wisdomandwonder.com/
“Wisdom begins in wonder.” --Socrates
((λ (x) (x x)) (λ (x) (x x)))
“Life has become immeasurably better since I have been forced to stop
taking it seriously.” --Thompson


On Sun, Aug 31, 2014 at 3:37 AM, Marcin Borkowski <mbork@wmi.amu.edu.pl> wrote:
> OK,
>
> so the time has come.  Either I'll declare .emacs bankruptcy soon, or
> I'll use Org-mode to structure it.
>
> I googled for a while, but couldn't find what I'm looking for: a list
> of options with hints (or links to hints) about how to get started, and
> possibly their pros and cons.
>
> I know that I could use org-babel-load-file, or outshine.  What are
> other possibilities?  What are the caveats (and advantages) of both
> (other?) ways?
>
> I am pretty sure that my question *can* be answered by RTFM (Worg
> page? some blog post?), so please link the FM if possible.
>
> Best,
>
> --
> Marcin Borkowski
> http://octd.wmi.amu.edu.pl/en/Marcin_Borkowski
> Adam Mickiewicz University
>

Re: Moving my init.el to Org

[Alan Schmitt]

[-- Attachment #1: Type: text/plain, Size: 578 bytes --]

On 2014-08-31 11:20, Thorsten Jolitz <tjolitz@gmail.com> writes:

> With outshine I have many of Org-mode's advantages (and using outorg I
> can turn my elisp file into an org file in a second and have all of
> them), but its still just about a source-file in emacs-lisp-mode, and
> thats what makes things convenient, fast and dynamic.

It there an easy way to turn an org file with many lisp source blocks
into an outshine file? I cannot start from the tangled file as it's
lacking all the org structure.

Thanks,

Alan

-- 
OpenPGP Key ID : 040D0A3B4ED2E5C7

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 494 bytes --]

Re: Moving my init.el to Org

[Thorsten Jolitz]

Alan Schmitt <alan.schmitt@polytechnique.org> writes:

> On 2014-08-31 11:20, Thorsten Jolitz <tjolitz@gmail.com> writes:
>
>> With outshine I have many of Org-mode's advantages (and using outorg I
>> can turn my elisp file into an org file in a second and have all of
>> them), but its still just about a source-file in emacs-lisp-mode, and
>> thats what makes things convenient, fast and dynamic.
>
> It there an easy way to turn an org file with many lisp source blocks
> into an outshine file? I cannot start from the tangled file as it's
> lacking all the org structure.

Yes, use

,----[ C-h f outorg-convert-org-to-outshine RET ]
| outorg-convert-org-to-outshine is a Lisp function in `outorg.el'.
| 
| (outorg-convert-org-to-outshine &optional MODE INFILE OUTFILE BATCH)
| 
| Convert an existing Org-mode file into an Outshine buffer.
| 
| If MODE is non-nil, the Outshine buffer will be put in this
| major-mode, otherwise the major-mode of the language of the first
| source-code block in the Org-mode buffer will be used.
| 
| If INFILE is non-nil, the specified Org-mode file will be
| visited, otherwise the current buffer will be used (i.e. the
| buffer content will be copied to a temporary *outorg-edit-buffer*
| for further processing).
| 
| If OUTFILE is non-nil, the converted Outshine buffer will be
| saved in this file. Its the user's responsability to make sure
| that OUTFILE's file-extension is suited for the major-mode of the
| Outshine buffer to be saved. When in doubt, consult variable
| `auto-mode-alist' for associations between file-extensions and
| major-modes.
| 
| If BATCH is non-nil (and OUTFILE is non-nil, otherwise it makes
| no sense), the new Outshine file is saved and its buffer
| deleted.
`----

Note: 

1. I think I took care of converting

,----
| #+BEGIN_SRC emacs-lisp :cache no
|  (+ 2 2)
| #+END_SRC
`----

to 

,----
| ;; #+header: :cache no
| (+ 2 2)
`----

in outorg, but it was not flawless IIRC. You could run 

,----[ C-h f org-dp-toggle-headers RET ]
| org-dp-toggle-headers is an interactive Lisp function in
| `org-dp-lib.el'.
| 
| (org-dp-toggle-headers &optional ACTION)
| 
| Toggle header argument representation.
| With prefix-arg, prompt user for ACTION, otherwise, if non-nil,
| it should take one the values `swap', `header' or `param',
| meaning to either swap :header and :parameter values, or make
| them all :header or :parameter values repectively.
`----

on your src-blocks before conversion, as an alternative, like this

,----
| (org-dp-toggle-headers &optional 'header)
`----

to avoid losing the src-block header-args during conversion. 


2. Call 'outorg-convert-org-to-outshine' just once, its only for the
initial conversion. Then you have an outshine file that you convert to
org occasionally with the usual 'outorg-edit-as-org'.

-- 
cheers,
Thorsten

Re: Moving my init.el to Org

[Brady Trainor]

On 8/31/2014 1:37 AM, Marcin Borkowski wrote:

> I know that I could use org-babel-load-file, or outshine.  What are
> other possibilities?  What are the caveats (and advantages) of both
> (other?) ways?

Another pro for `outshine`, I've made a folding expression for Vim that 
respects `outshine` behavior, as far as I use it.

augroup filetype_lisp
     au!
     au FileType lisp setlocal foldmethod=expr foldexpr=ELispLevel()
augroup END

function! ELispLevel()
     let n = len(matchstr(getline(v:lnum), '^;\+'))
     let l = n - 2
     if n >= 3
         return ">" . l
     else
         return "="
     endif
endfunction

 From Vim, typing `:help fold-expr RET` will give a clue as to the ">" 
and "=" expressions.

I tried the init.org for a while, it was fun so you should try it for a 
while, but I've been trying to reduce how many conversions I have in my 
projects. And I finally succumbed to the convention of breaking some 
parts of my init file into parts (nav, org, etc). Trying to keep my init 
files easy to drop-in and understand was a factor, as I'm always trying 
to convert people to Emacs and org-mode (success zero so far). And 
troubleshooting may be considered easier.

More specifically, consider that if you try to convert someone to Emacs 
and org-mode via an init.org file, they will have to deal with three new 
problems at once.

1. The order of loading org, babel, and the .org file, and any possible 
issues with old versions of org builtin to Emacs
2. As you show them the emacs-lisp, they may get distracted by all the 
#+BEGIN_SRC emacs-lisp etc., wondering simultaneously how everything 
fits together
3. Learning org-mode and .emacs in an intertwined way


Brady

Re: Moving my init.el to Org

[Oleh]

> I know that I could use org-babel-load-file, or outshine.  What are
> other possibilities?  What are the caveats (and advantages) of both
> (other?) ways?

I'm using a one .el file per mode approach, with around 4000 lines
split into 40 files.

This approach simplifies things a lot: for instance I haven't touched
Javascript in ages, but all my customizations for it are sitting in
javascript.el without getting in the way of the stuff that I'm using
now. They aren't even loaded unless I open a js file.

The rest of my codes are published and I just use them via
MELPA.  I use my own package to navigate and maintain code
(https://github.com/abo-abo/lispy).  Here's a short screencast if you
haven't seen it before: https://vimeo.com/86894158.

regards,
Oleh

Re: Moving my init.el to Org

[Alan Schmitt]

[-- Attachment #1: Type: text/plain, Size: 1059 bytes --]

Hello Thorsten,

I gave this a try, and here are some observations.

On 2014-08-31 16:12, Thorsten Jolitz <tjolitz@gmail.com> writes:

> on your src-blocks before conversion, as an alternative, like this
>
> ,----
> | (org-dp-toggle-headers &optional 'header)
> `----
>
> to avoid losing the src-block header-args during conversion. 

I don't use headers in that file so I skipped that step.

> 2. Call 'outorg-convert-org-to-outshine' just once, its only for the
> initial conversion. Then you have an outshine file that you convert to
> org occasionally with the usual 'outorg-edit-as-org'.

As it's not interactive, I had to evaluate it. The only thing I then saw
is the reply "nil". I searched for a created buffer and I found it, but
the results are surprising. With this small input file:

* test
** test2
#+begin_src emacs-lisp
(+ 2 2)
#+end_src

I got this output

;; * test

;; #+header: 
;; #+header: ** test2
;; #+begin_src emacs-lisp
;; (+ 2 2)
;; #+end_src

Alan

-- 
OpenPGP Key ID : 040D0A3B4ED2E5C7

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 494 bytes --]

Re: Moving my init.el to Org

[Thorsten Jolitz]

Alan Schmitt <alan.schmitt@polytechnique.org> writes:

Hello Thorsten,

> I gave this a try, and here are some observations.
>
> On 2014-08-31 16:12, Thorsten Jolitz <tjolitz@gmail.com> writes:
>
>> on your src-blocks before conversion, as an alternative, like this
>>
>> ,----
>> | (org-dp-toggle-headers &optional 'header)
>> `----
>>
>> to avoid losing the src-block header-args during conversion. 
>
> I don't use headers in that file so I skipped that step.
>
>> 2. Call 'outorg-convert-org-to-outshine' just once, its only for the
>> initial conversion. Then you have an outshine file that you convert to
>> org occasionally with the usual 'outorg-edit-as-org'.
>
> As it's not interactive, I had to evaluate it. The only thing I then saw
> is the reply "nil". I searched for a created buffer and I found it, but

Yes, since this is most likely a seldom used function (every file is
converted just once) I did not bother to make it interactive. And IIRC
it returns nil and doesn't change window-config because it was written
with batch calls in mind. 

> the results are surprising. With this small input file:
>
> * test
> ** test2
> #+begin_src emacs-lisp
> (+ 2 2)
> #+end_src
>
> I got this output
>
> ;; * test
>
> ;; #+header: 
> ;; #+header: ** test2
> ;; #+begin_src emacs-lisp
> ;; (+ 2 2)
> ;; #+end_src


Thats a bug, it should be fixed now in branch tj-outorg (which should
actually be faster and better than master anyway and will hopefully be
merged in a few weeks or so).

Here is my org-mode test buffer:

#+BEGIN_ORG
* test
** test2
#+begin_src emacs-lisp
(+ 2 2)
#+end_src

#+begin_src picolisp :exports code
(+ 2 2)
#+end_src

#+begin_src emacs-lisp :results value :cache no
(+ 2 2)
#+end_src
#+END_ORG

and here the emacs-lisp-mode output buffer:

#+BEGIN_SRC emacs-lisp
;; * test
;; ** test2
(+ 2 2)

;; #+begin_src picolisp :exports code
;; (+ 2 2)
;; #+end_src

;; #+header: :cache no
;; #+header: :results value
(+ 2 2)
#+END_SRC
 
which looks ok so far. can you test it too?

PS

What about switches? AFAIK they don't work yet as #+header args, is
that correct? If so, is it planned to make them work as #+header args
in the future?

-- 
cheers,
Thorsten

Re: Moving my init.el to Org

[Alan Schmitt]

[-- Attachment #1: Type: text/plain, Size: 611 bytes --]

On 2014-09-01 23:24, Thorsten Jolitz <tjolitz@gmail.com> writes:

> Thats a bug, it should be fixed now in branch tj-outorg (which should
> actually be faster and better than master anyway and will hopefully be
> merged in a few weeks or so).

Great, thanks.

> can you test it too?

Unfortunately I install navi as a package, so it's not easy for me to
switch branches. Let me know when you do the merge and I'll definitely
test then. (There is no hurry as I manually converted the file to
outshine format, which was less painful than I feared.)

Alan

-- 
OpenPGP Key ID : 040D0A3B4ED2E5C7

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 494 bytes --]

Re: Moving my init.el to Org

[Rainer M Krug]

[-- Attachment #1: Type: text/plain, Size: 1224 bytes --]

Oleh <ohwoeowho@gmail.com> writes:

>> I know that I could use org-babel-load-file, or outshine.  What are
>> other possibilities?  What are the caveats (and advantages) of both
>> (other?) ways?
>
> I'm using a one .el file per mode approach, with around 4000 lines
> split into 40 files.
>
> This approach simplifies things a lot: for instance I haven't touched
> Javascript in ages, but all my customizations for it are sitting in
> javascript.el without getting in the way of the stuff that I'm using
> now. They aren't even loaded unless I open a js file.

Interesting - is your configuration online, so that one could take a
look at it? I did not find them on your github page?
 
Or how do you do it, that the e.g. javascript.el is only loaded when a
js file is opened? Because this is exactly what I would like to have.

Cheers,

Rainer

>
> The rest of my codes are published and I just use them via
> MELPA.  I use my own package to navigate and maintain code
> (https://github.com/abo-abo/lispy).  Here's a short screencast if you
> haven't seen it before: https://vimeo.com/86894158.
>
> regards,
> Oleh
>
>

-- 
Rainer M. Krug
email: Rainer<at>krugs<dot>de
PGP: 0x0F52F982

[-- Attachment #2: Type: application/pgp-signature, Size: 494 bytes --]

Re: Moving my init.el to Org

[Thorsten Jolitz]

Alan Schmitt <alan.schmitt@polytechnique.org> writes:

> On 2014-09-01 23:24, Thorsten Jolitz <tjolitz@gmail.com> writes:
>
>> Thats a bug, it should be fixed now in branch tj-outorg (which should
>> actually be faster and better than master anyway and will hopefully be
>> merged in a few weeks or so).
>
> Great, thanks.
>
>> can you test it too?
>
> Unfortunately I install navi as a package, so it's not easy for me to
> switch branches. Let me know when you do the merge and I'll definitely
> test then. (There is no hurry as I manually converted the file to
> outshine format, which was less painful than I feared.)

Too bad, I thought I found a beta-tester for the outshine/outorg/navi
"tj" branches before merging them into master ;)

And sorry for the hassle of manual converting, the bug was actually in
this function, so in case you want to convert another org file, here is
the (hopefully) fixed version:

#+BEGIN_SRC emacs-lisp
(defun outorg-transform-active-source-block-headers ()
  "Move switches and arguments on top of block.

This functions transforms all active source-blocks, i.e. those
with the associated source-code buffer's major-mode as
language. If there are switches and header arguments after the
language specification on the #+BEGIN_SRC line, they are moved on
top of the block.

The idea behind this function is that it should be possible to
specify permanent switches and arguments even for source-code
blocks that are transformed back to code after
`outorg-copy-and-switch' is called. They will remain as comment
lines directly over their code section in the source-code buffer,
and thus be transformed to text - and thereby activated - everytime
`outorg-edit-as-org' is called."
  (save-excursion
    (let* ((mode (outorg-get-buffer-mode
		  (marker-buffer outorg-code-buffer-point-marker)))
	   (active-lang
	    (outorg-get-babel-name mode 'as-strg-p)))
      (org-babel-map-src-blocks nil
	(when (string-equal active-lang lang)
	  (let ((sw switches)
		(args header-args))
	    (goto-char end-lang)
	    (delete-region (point) (line-end-position))
	    (goto-char beg-block)
	    (forward-line -1)
	    (when (org-string-nw-p sw)
	      (newline)
	      (insert (format "#+header: %s" sw)))
	    (when (org-string-nw-p args)
	      (let ((params
		     (ignore-errors
		       (org-split-string args)))
		    headers)
		(while params
		  (setq headers
			(cons
			 (format "#+header: %s %s"
				 (org-no-properties (pop params))
				 (org-no-properties (pop params)))
			 headers)))
		(newline)
		(insert (mapconcat 'identity headers "\n"))))))))))
#+END_SRC

-- 
cheers,
Thorsten

Re: Moving my init.el to Org

[Rasmus]

Rainer M Krug <Rainer@krugs.de> writes:

> Oleh <ohwoeowho@gmail.com> writes:
>
>>> I know that I could use org-babel-load-file, or outshine.  What are
>>> other possibilities?  What are the caveats (and advantages) of both
>>> (other?) ways?
>>
>> I'm using a one .el file per mode approach, with around 4000 lines
>> split into 40 files.
>>
>> This approach simplifies things a lot: for instance I haven't touched
>> Javascript in ages, but all my customizations for it are sitting in
>> javascript.el without getting in the way of the stuff that I'm using
>> now. They aren't even loaded unless I open a js file.
>
> Interesting - is your configuration online, so that one could take a
> look at it? I did not find them on your github page?
>  
> Or how do you do it, that the e.g. javascript.el is only loaded when a
> js file is opened? Because this is exactly what I would like to have.

How about something like this: 

(with-eval-after-load 'js-mode (load "javascript.el"))

Use eval-after-load if you are using an older Emacs.  Note I don't
know if there's anything called js-mode. . .

-- 
Summon the Mothership!

Re: Moving my init.el to Org

[Jonathan Leech-Pepin]

[-- Attachment #1: Type: text/plain, Size: 1747 bytes --]

Hello,

On 2 September 2014 08:42, Rasmus <rasmus@gmx.us> wrote:

> Rainer M Krug <Rainer@krugs.de> writes:
>
> > Oleh <ohwoeowho@gmail.com> writes:
> >
> >>> I know that I could use org-babel-load-file, or outshine.  What are
> >>> other possibilities?  What are the caveats (and advantages) of both
> >>> (other?) ways?
> >>
> >> I'm using a one .el file per mode approach, with around 4000 lines
> >> split into 40 files.
> >>
> >> This approach simplifies things a lot: for instance I haven't touched
> >> Javascript in ages, but all my customizations for it are sitting in
> >> javascript.el without getting in the way of the stuff that I'm using
> >> now. They aren't even loaded unless I open a js file.
> >
> > Interesting - is your configuration online, so that one could take a
> > look at it? I did not find them on your github page?
> >
> > Or how do you do it, that the e.g. javascript.el is only loaded when a
> > js file is opened? Because this is exactly what I would like to have.
>
> How about something like this:
>
> (with-eval-after-load 'js-mode (load "javascript.el"))
>
> Use eval-after-load if you are using an older Emacs.  Note I don't
> know if there's anything called js-mode. . .
>

I've been using use-package (https://github.com/jwiegley/use-package) for
only loading the various package-specific configurations when needed.

For that example it would be:

(use-package js-mode
  :mode ("\\.js\\'" . js-mode)
  :config (require 'javascript) ;; or (load "javascript.el") if not provided
)

In my case it's still all in my init.el (with Outshine headings for each
mode that use-package manages), but could easily extract the portions into
their own files (especially for larger configurations like org)

Regards,
Jon

[-- Attachment #2: Type: text/html, Size: 2674 bytes --]

Re: Moving my init.el to Org

[Rainer M Krug]

[-- Attachment #1: Type: text/plain, Size: 2238 bytes --]

Jonathan Leech-Pepin <jonathan.leechpepin@gmail.com> writes:

> Hello,
>
> On 2 September 2014 08:42, Rasmus <rasmus@gmx.us> wrote:
>
>> Rainer M Krug <Rainer@krugs.de> writes:
>>
>> > Oleh <ohwoeowho@gmail.com> writes:
>> >
>> >>> I know that I could use org-babel-load-file, or outshine.  What are
>> >>> other possibilities?  What are the caveats (and advantages) of both
>> >>> (other?) ways?
>> >>
>> >> I'm using a one .el file per mode approach, with around 4000 lines
>> >> split into 40 files.
>> >>
>> >> This approach simplifies things a lot: for instance I haven't touched
>> >> Javascript in ages, but all my customizations for it are sitting in
>> >> javascript.el without getting in the way of the stuff that I'm using
>> >> now. They aren't even loaded unless I open a js file.
>> >
>> > Interesting - is your configuration online, so that one could take a
>> > look at it? I did not find them on your github page?
>> >
>> > Or how do you do it, that the e.g. javascript.el is only loaded when a
>> > js file is opened? Because this is exactly what I would like to have.
>>
>> How about something like this:
>>
>> (with-eval-after-load 'js-mode (load "javascript.el"))
>>
>> Use eval-after-load if you are using an older Emacs.  Note I don't
>> know if there's anything called js-mode. . .
>>
>
> I've been using use-package (https://github.com/jwiegley/use-package) for
> only loading the various package-specific configurations when needed.
>
> For that example it would be:
>
> (use-package js-mode
>   :mode ("\\.js\\'" . js-mode)
>   :config (require 'javascript) ;; or (load "javascript.el") if not provided
> )

That is what I was looking for - I'll try it out soon - step by step -
one package at a time.

>
> In my case it's still all in my init.el (with Outshine headings for each
> mode that use-package manages), but could easily extract the portions into
> their own files (especially for larger configurations like org)

I think it makes sense to extract these into different files, and have
them in one org file which is then tangled.

Thanks,

Rainer

>
> Regards,
> Jon

-- 
Rainer M. Krug
email: Rainer<at>krugs<dot>de
PGP: 0x0F52F982

[-- Attachment #2: Type: application/pgp-signature, Size: 494 bytes --]

Re: Moving my init.el to Org

[Oleh]

>> I'm using a one .el file per mode approach, with around 4000 lines
>> split into 40 files.
>>
>> This approach simplifies things a lot: for instance I haven't touched
>> Javascript in ages, but all my customizations for it are sitting in
>> javascript.el without getting in the way of the stuff that I'm using
>> now. They aren't even loaded unless I open a js file.
>
> Interesting - is your configuration online, so that one could take a
> look at it? I did not find them on your github page?

It's not online since it's a hassle to put it up.

> Or how do you do it, that the e.g. javascript.el is only loaded when a
> js file is opened? Because this is exactly what I would like to have.

It's a three-part setup that goes like this.
In hooks.el that's loaded unconditionally:

    ...
    (add-hook 'java-mode-hook 'oleh-java-hook)
    (add-hook 'tuareg-mode-hook 'oleh-tuareg-hook)
    (add-hook 'js-mode-hook 'oleh-javascript-hook)
    (add-hook 'markdown-mode-hook 'oleh-markdown-hook)
    ...

In modes/javascript.el that's not loaded:

    ;;;###autoload
    (defun oleh-javascript-hook ()
      (smart-insert-operator-hook)
      (moz-minor-mode 1)
      (define-key js-mode-map (kbd "<f5>") 'js-f5)
      (define-key js-mode-map (kbd "C-<f5>") 'js-C-f5)
      ...
      )

And this function generates the autoloads when a new file is added:

    ;;;###autoload
    (defun update-all-autoloads ()
      (interactive)
      (let ((generated-autoload-file (concat emacs.d "loaddefs.el")))
        (when (not (file-exists-p generated-autoload-file))
          (with-current-buffer (find-file-noselect generated-autoload-file)
            (insert ";;") ;; create the file with non-zero size to
appease autoload
            (save-buffer)))
        (mapcar #'update-directory-autoloads
                '("" "oleh" "oleh/modes" "matlab-emacs"))))

The file loaddefs.el is loaded unconditionally as well.  So when a js
file is opened, `js-mode-hook` is called and the autoloaded
`oleh-javascript-hook` is called, making sure that
"oleh/modes/javascript.el" is loaded.

regards,
Oleh

Re: Moving my init.el to Org

[Rainer M Krug]

[-- Attachment #1: Type: text/plain, Size: 2521 bytes --]

Oleh <ohwoeowho@gmail.com> writes:

>>> I'm using a one .el file per mode approach, with around 4000 lines
>>> split into 40 files.
>>>
>>> This approach simplifies things a lot: for instance I haven't touched
>>> Javascript in ages, but all my customizations for it are sitting in
>>> javascript.el without getting in the way of the stuff that I'm using
>>> now. They aren't even loaded unless I open a js file.
>>
>> Interesting - is your configuration online, so that one could take a
>> look at it? I did not find them on your github page?
>
> It's not online since it's a hassle to put it up.

No problem.

>
>> Or how do you do it, that the e.g. javascript.el is only loaded when a
>> js file is opened? Because this is exactly what I would like to have.
>
> It's a three-part setup that goes like this.
> In hooks.el that's loaded unconditionally:
>
>     ...
>     (add-hook 'java-mode-hook 'oleh-java-hook)
>     (add-hook 'tuareg-mode-hook 'oleh-tuareg-hook)
>     (add-hook 'js-mode-hook 'oleh-javascript-hook)
>     (add-hook 'markdown-mode-hook 'oleh-markdown-hook)
>     ...
>
> In modes/javascript.el that's not loaded:
>
>     ;;;###autoload
>     (defun oleh-javascript-hook ()
>       (smart-insert-operator-hook)
>       (moz-minor-mode 1)
>       (define-key js-mode-map (kbd "<f5>") 'js-f5)
>       (define-key js-mode-map (kbd "C-<f5>") 'js-C-f5)
>       ...
>       )
>
> And this function generates the autoloads when a new file is added:
>
>     ;;;###autoload
>     (defun update-all-autoloads ()
>       (interactive)
>       (let ((generated-autoload-file (concat emacs.d "loaddefs.el")))
>         (when (not (file-exists-p generated-autoload-file))
>           (with-current-buffer (find-file-noselect generated-autoload-file)
>             (insert ";;") ;; create the file with non-zero size to
> appease autoload
>             (save-buffer)))
>         (mapcar #'update-directory-autoloads
>                 '("" "oleh" "oleh/modes" "matlab-emacs"))))
>
> The file loaddefs.el is loaded unconditionally as well.  So when a js
> file is opened, `js-mode-hook` is called and the autoloaded
> `oleh-javascript-hook` is called, making sure that
> "oleh/modes/javascript.el" is loaded.

Thanks - looks like an interesting approach which avoids having to use
use-package or req-package.

Thanks a lot for the info,

Rainer
 

>
> regards,
> Oleh
>
>

-- 
Rainer M. Krug
email: Rainer<at>krugs<dot>de
PGP: 0x0F52F982

[-- Attachment #2: Type: application/pgp-signature, Size: 494 bytes --]

Re: Moving my init.el to Org

[Marcin Borkowski]

Hi,

and thanks for all the great replies!

I ended up using orgstruct mode, which is probably the simplest one,
and (AFAIU) it will enable me to switch easily to outshine if (when?)
orgstruct is not enough for me.

And now there's another problem: I'd like to have my init file
collapsed to only headlines on opening.  Since I visit my init file
through a custom command (which finds it and turns on orgstruct), I
don't need to use file local variables for that - I just need a
command to do it.  So:

how do I (programmatically, in elisp) collapse the view of
an orgstruct .el file?

TIA,

-- 
Marcin Borkowski
http://octd.wmi.amu.edu.pl/en/Marcin_Borkowski
Adam Mickiewicz University

Re: Moving my init.el to Org

[Thorsten Jolitz]

Marcin Borkowski <mbork@wmi.amu.edu.pl> writes:

> Hi,
>
> and thanks for all the great replies!
>
> I ended up using orgstruct mode, which is probably the simplest one,
> and (AFAIU) it will enable me to switch easily to outshine if (when?)
> orgstruct is not enough for me.
>
> And now there's another problem: I'd like to have my init file
> collapsed to only headlines on opening.  Since I visit my init file
> through a custom command (which finds it and turns on orgstruct), I
> don't need to use file local variables for that - I just need a
> command to do it.  So:
>
> how do I (programmatically, in elisp) collapse the view of
> an orgstruct .el file?

Try 'org-overview'. Both, 'org-overview' and 'show-all' work
with outshine too, so they should work with org-struct.

-- 
cheers,
Thorsten

Re: Moving my init.el to Org

[Eduardo Ochs]

Hi all, I hope you don't mind me jumping into this thread to ask an
org-beginner question...

My .emacs is about 15000 lines long, and that's fine for me because I
have "anchors" at some points of it, and an index at the top, and
convenient ways to jump quickly to any anchors. If anyone is curious,
here are some links - my package that implements those things is
called eev.

  http://angg.twu.net/.emacs.html
  http://angg.twu.net/eev-intros/find-eval-intro.html
  http://angg.twu.net/eev-intros/find-anchors-intro.html
  http://angg.twu.net/#eev

I know that Org implements something similar to that, but I don't know
how to use it. This sexp, when executed,

  (find-angg ".emacs" "unquote-printable")

Jumps to the first occurrence of the string "<<unquote-printable>>" in
my ~/.emacs - in the htmlized version, the target of that sexp is:

  http://angg.twu.net/.emacs.html#unquote-printable

So, questions:

1) what is the user-ish way to create a link in Org to the first
   occurrence of the string "<<unquote-printable>>" in ~/.emacs?

2) I know that Org lets users implement new kinds of hyperlinks. If
   the syntax for doing what I asked in (1) is too clumsy, how do we
   implement a better syntax?

3) The

     (find-angg ".emacs" "unquote-printable")

   calls my functions to visit a file and jump to a position. How can
   I jump to that position using Org's functions *from Lisp*? Or,
   better, how do we write sexps to expose what Org does? My guess is
   that that would be done be several sexps, more or less like this
   pseudocode:

     (org-hyperlink-method-and-args "file:///~/.emacs#<<unquote-printable>>")
     ;; --> (file-and-anchor "~/.emacs" "<<unquote-printable>>")

     (org-hyperlink-do 'file-and-anchor "~/.emacs" "<<unquote-printable>>")


  Thanks in advance! =)
  Eduardo Ochs
  eduardoochs@gmail.com
  http://angg.twu.net/#eev

On Fri, Sep 5, 2014 at 11:49 PM, Thorsten Jolitz <tjolitz@gmail.com> wrote:
> Marcin Borkowski <mbork@wmi.amu.edu.pl> writes:
>
>> Hi,
>>
>> and thanks for all the great replies!
>>
>> I ended up using orgstruct mode, which is probably the simplest one,
>> and (AFAIU) it will enable me to switch easily to outshine if (when?)
>> orgstruct is not enough for me.
>>
>> And now there's another problem: I'd like to have my init file
>> collapsed to only headlines on opening.  Since I visit my init file
>> through a custom command (which finds it and turns on orgstruct), I
>> don't need to use file local variables for that - I just need a
>> command to do it.  So:
>>
>> how do I (programmatically, in elisp) collapse the view of
>> an orgstruct .el file?
>
> Try 'org-overview'. Both, 'org-overview' and 'show-all' work
> with outshine too, so they should work with org-struct.
>
> --
> cheers,
> Thorsten
>
>

Re: Moving my init.el to Org

[Thorsten Jolitz]

Eduardo Ochs <eduardoochs@gmail.com> writes:

Hi, 

> So, questions:
>
> 1) what is the user-ish way to create a link in Org to the first
>    occurrence of the string "<<unquote-printable>>" in ~/.emacs?

see http://orgmode.org/manual/Internal-links.html

>
> 2) I know that Org lets users implement new kinds of hyperlinks. If
>    the syntax for doing what I asked in (1) is too clumsy, how do we
>    implement a better syntax?

and if its not too clumpsy? ;)

> 3) The
>
>      (find-angg ".emacs" "unquote-printable")
>
>    calls my functions to visit a file and jump to a position. How can
>    I jump to that position using Org's functions *from Lisp*? 


maybe calling

,----[ C-h f org-store-link RET ]
| org-store-link is an interactive autoloaded compiled Lisp function in
| `org.el'.
| 
| (org-store-link ARG)
| 
| Store an org-link to the current location.
| This link is added to `org-stored-links' and can later be inserted
| into an org-buffer with C-c C-l.
| 
| For some link types, a prefix arg is interpreted.
| For links to Usenet articles, arg negates `org-gnus-prefer-web-links'.
| For file links, arg negates `org-context-in-file-links'.
| 
| A double prefix arg force skipping storing functions that are not
| part of Org's core.
| 
| A triple prefix arg force storing a link for each line in the
| active region.
| 
| [back]
`----

Unfortunately many many org commands do not expose their args as
function arguments but unconditionally prompt for them, which makes
(re)using them in programs pretty difficult and is a real shame IMO.

One would need to change signature and interactive spec for many org
commands to make them easily available as kind of 'library functions',
and add an option for suppressing any user prompting for non-interactive
use. Then direct binding to keys would not be possible anymore, one
would need to use convenience commands or lambda expressions that take
care of the function arguments. 

-- 
cheers,
Thorsten

OrgStruct: start with collapsed view (was: Moving my init.el to Org)

[Karl Voit]

Hi!

* Thorsten Jolitz <tjolitz@gmail.com> wrote:
> Marcin Borkowski <mbork@wmi.amu.edu.pl> writes:
>
>> And now there's another problem: I'd like to have my init file
>> collapsed to only headlines on opening.  Since I visit my init file
>> through a custom command (which finds it and turns on orgstruct), I
>> don't need to use file local variables for that - I just need a
>> command to do it.  So:
>>
>> how do I (programmatically, in elisp) collapse the view of
>> an orgstruct .el file?
>
> Try 'org-overview'. Both, 'org-overview' and 'show-all' work
> with outshine too, so they should work with org-struct.

I also transformed my 3657 lines of init.el to OrgStruct.

Similar to Marcin, I want to see a collapsed view of my headings
when I open my init.el file. org-overview gives me a weird view of
all lines that start a parenthesis on top level (defun, setq, ...)
and not my top level OrgStruct comment lines.

Has somebody successfully managed to get a collapsed init.el view
when opening the file?

Thanks!

Re: OrgStruct: start with collapsed view

[Rasmus]

Karl Voit <devnull@Karl-Voit.at> writes:

> Hi!
>
> * Thorsten Jolitz <tjolitz@gmail.com> wrote:
>> Marcin Borkowski <mbork@wmi.amu.edu.pl> writes:
>>
>>> And now there's another problem: I'd like to have my init file
>>> collapsed to only headlines on opening.  Since I visit my init file
>>> through a custom command (which finds it and turns on orgstruct), I
>>> don't need to use file local variables for that - I just need a
>>> command to do it.  So:
>>>
>>> how do I (programmatically, in elisp) collapse the view of
>>> an orgstruct .el file?
>>
>> Try 'org-overview'. Both, 'org-overview' and 'show-all' work
>> with outshine too, so they should work with org-struct.
>
> I also transformed my 3657 lines of init.el to OrgStruct.
>
> Similar to Marcin, I want to see a collapsed view of my headings
> when I open my init.el file. org-overview gives me a weird view of
> all lines that start a parenthesis on top level (defun, setq, ...)
> and not my top level OrgStruct comment lines.
>
> Has somebody successfully managed to get a collapsed init.el view
> when opening the file?

Nope.  And `org-overview' produces a mess of my file as well.  I have,

;; -*- orgstruct-heading-prefix-regexp: ";;" -*-

And headings look like

;;* h
;;** h1

—Rasmus

-- 
m-mm-mmm-mmmm bacon!

Re: OrgStruct: start with collapsed view

[Thorsten Jolitz]

Karl Voit <devnull@Karl-Voit.at> writes:

> Hi!
>
> * Thorsten Jolitz <tjolitz@gmail.com> wrote:
>> Marcin Borkowski <mbork@wmi.amu.edu.pl> writes:
>>
>>> And now there's another problem: I'd like to have my init file
>>> collapsed to only headlines on opening.  Since I visit my init file
>>> through a custom command (which finds it and turns on orgstruct), I
>>> don't need to use file local variables for that - I just need a
>>> command to do it.  So:
>>>
>>> how do I (programmatically, in elisp) collapse the view of
>>> an orgstruct .el file?
>>
>> Try 'org-overview'. Both, 'org-overview' and 'show-all' work
>> with outshine too, so they should work with org-struct.
>
> I also transformed my 3657 lines of init.el to OrgStruct.
>
> Similar to Marcin, I want to see a collapsed view of my headings
> when I open my init.el file. org-overview gives me a weird view of
> all lines that start a parenthesis on top level (defun, setq, ...)
> and not my top level OrgStruct comment lines.
>
> Has somebody successfully managed to get a collapsed init.el view
> when opening the file?

Not a solution, but an alternative (and an interesting experiment):

What if you try navi-mode with your orgstruct init.el? It works with
outshine and with org-mode, so maybe with orgstruct too?

I always have the source file in 'show-all' mode side-by-side with its
*Navi* buffer that give me the overview (and dozens of other views
too). Constantly changing visibility in a file is to much action and
distraction IMO, I rather have a 2nd buffer for the overview.

Let me know if it works, I did not try navi-mode with orgstruct yet.

-- 
cheers,
Thorsten

Re: OrgStruct: start with collapsed view

[Scott Randby]

On 10/30/2014 08:41 AM, Thorsten Jolitz wrote:
> Karl Voit <devnull@Karl-Voit.at> writes:
>
>> Hi!
>>
>> * Thorsten Jolitz <tjolitz@gmail.com> wrote:
>>> Marcin Borkowski <mbork@wmi.amu.edu.pl> writes:
>>>
>>>> And now there's another problem: I'd like to have my init file
>>>> collapsed to only headlines on opening.  Since I visit my init file
>>>> through a custom command (which finds it and turns on orgstruct), I
>>>> don't need to use file local variables for that - I just need a
>>>> command to do it.  So:
>>>>
>>>> how do I (programmatically, in elisp) collapse the view of
>>>> an orgstruct .el file?
>>>
>>> Try 'org-overview'. Both, 'org-overview' and 'show-all' work
>>> with outshine too, so they should work with org-struct.
>>
>> I also transformed my 3657 lines of init.el to OrgStruct.
>>
>> Similar to Marcin, I want to see a collapsed view of my headings
>> when I open my init.el file. org-overview gives me a weird view of
>> all lines that start a parenthesis on top level (defun, setq, ...)
>> and not my top level OrgStruct comment lines.
>>
>> Has somebody successfully managed to get a collapsed init.el view
>> when opening the file?
>
> Not a solution, but an alternative (and an interesting experiment):
>
> What if you try navi-mode with your orgstruct init.el? It works with
> outshine and with org-mode, so maybe with orgstruct too?

I found this on http://orgmode.org/worg/org-tutorials/org-outside-org.html.

   "orgstruct currently does NOT work with outorg and navi-mode..."

Scott Randby

>
> I always have the source file in 'show-all' mode side-by-side with its
> *Navi* buffer that give me the overview (and dozens of other views
> too). Constantly changing visibility in a file is to much action and
> distraction IMO, I rather have a 2nd buffer for the overview.
>
> Let me know if it works, I did not try navi-mode with orgstruct yet.
>

Re: OrgStruct: start with collapsed view

[Karl Voit]

* Scott Randby <srandby@gmail.com> wrote:
> On 10/30/2014 08:41 AM, Thorsten Jolitz wrote:
>> Karl Voit <devnull@Karl-Voit.at> writes:
>>
>> Not a solution, but an alternative (and an interesting experiment):
>>
>> What if you try navi-mode with your orgstruct init.el? It works with
>> outshine and with org-mode, so maybe with orgstruct too?
>
> I found this on http://orgmode.org/worg/org-tutorials/org-outside-org.html.
>
>    "orgstruct currently does NOT work with outorg and navi-mode..."

So maybe I'll test Outshine as well.

Re: OrgStruct: start with collapsed view

[Thorsten Jolitz]

Scott Randby <srandby@gmail.com> writes:

>> What if you try navi-mode with your orgstruct init.el? It works with
>> outshine and with org-mode, so maybe with orgstruct too?
>
> I found this on http://orgmode.org/worg/org-tutorials/org-outside-org.html.
>
>   "orgstruct currently does NOT work with outorg and navi-mode..."

Ups, than I wrote this (and forgot about it). I still wonder why it
wouldn't work if 'natural' header conventions are used like

,----
| ;; * 1st level
| ;; ** 2nd level
`----

or 

,----
| ;;; 1st level
| ;;;; 2nd level
`----

but I somehow remember that orgstructs default conventions are
different. 

Well, thinking about it, its probably a matter of buffer-local vars for
outline-mode, and orgstructs sets its own variables leaving the outline
vars as-is (correct?), but outshine uses the outline vars and thus does
not find regexps for Org-style headers. Or so...

-- 
cheers,
Thorsten