Announcement: org-one-to-many

Announcement: org-one-to-many

[Marcin Borkowski]

Hi all,

a long time ago I asked here about a way to split an Org file into a
bunch of smaller ones.  One of the answers I got was that the tricky
part is maintaining internal links in a reasonable way.

It is probably overoptimistic on my side, but it seems that this problem
is solved now.  The code is not very elegant, and I will be actively
working on it (I want to write an org-to-e-learning exporter, based on
the HTML one, and this is a small part of that effort), but here it is
for testing/review/bug reports/feature requests/any other kind of
feedback.

And here it is: https://github.com/mbork/org-one-to-many

Best,

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

Re: Announcement: org-one-to-many

[Eric Abrahamsen]

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

> Hi all,
>
> a long time ago I asked here about a way to split an Org file into a
> bunch of smaller ones.  One of the answers I got was that the tricky
> part is maintaining internal links in a reasonable way.
>
> It is probably overoptimistic on my side, but it seems that this problem
> is solved now.  The code is not very elegant, and I will be actively
> working on it (I want to write an org-to-e-learning exporter, based on
> the HTML one, and this is a small part of that effort), but here it is
> for testing/review/bug reports/feature requests/any other kind of
> feedback.
>
> And here it is: https://github.com/mbork/org-one-to-many

Oooh, cool. I'll look forward to reading it!

Re: Announcement: org-one-to-many

[Marcin Borkowski]

On 2014-10-21, at 18:10, Eric Abrahamsen wrote:

> Marcin Borkowski <mbork@wmi.amu.edu.pl> writes:
>
>> Hi all,
>>
>> a long time ago I asked here about a way to split an Org file into a
>> bunch of smaller ones.  One of the answers I got was that the tricky
>> part is maintaining internal links in a reasonable way.
>>
>> It is probably overoptimistic on my side, but it seems that this problem
>> is solved now.  The code is not very elegant, and I will be actively
>> working on it (I want to write an org-to-e-learning exporter, based on
>> the HTML one, and this is a small part of that effort), but here it is
>> for testing/review/bug reports/feature requests/any other kind of
>> feedback.
>>
>> And here it is: https://github.com/mbork/org-one-to-many
>
> Oooh, cool. I'll look forward to reading it!

Thanks, but don't expect too much, I'm still learning Elisp.  I'll be
thankful for your feedback!

My idea to solve the problem of links is that I first mark the parts
which will be exported to various files using text property
:otm-filename, then walk all the internal links (in reverse order, which
is important, since I first gather them in a list, so I don't want to
mess the begin/end positions of the links) and change them according to
that property of their destination (unless they point to the same
portion, in which case they stay the same), and only then split the file
(again using the text property).  This might not be the most elegant
thing in the world, but it seems to work.

Best,

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

Re: Announcement: org-one-to-many

[Daniel Clemente]

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

Hi,
breaking a big .org file in many small pieces is one of my major concerns
with .org and one which gives me lots of problems. Thank you very much for
having the clear objective of one-to-many.

If your goal is HTML export, you can do a function that iterates over all
headers and exports them (see below). But then links are broken, you need
to decide filenames, etc. Which is what your project solves.

org-one-to-many has a shortcoming which is present in so many "org to blog"
systems: it expects a particular structure (in this case, all headers at
the same level). I suggest you iterate over search results of a normal
search:

For instance, you can get all headers tagged with "tobesplit" like this:
(org-map-entries (lambda () (line-number-at-pos))  "+tobesplit" 'agenda)

One of the possible searches is "headers at level 2", so this new system
would include the one you have.

Greetings

On Tue, Oct 21, 2014 at 10:02 PM, Marcin Borkowski <mbork@wmi.amu.edu.pl>
wrote:

> Hi all,
>
> a long time ago I asked here about a way to split an Org file into a
> bunch of smaller ones.  One of the answers I got was that the tricky
> part is maintaining internal links in a reasonable way.
>
> It is probably overoptimistic on my side, but it seems that this problem
> is solved now.  The code is not very elegant, and I will be actively
> working on it (I want to write an org-to-e-learning exporter, based on
> the HTML one, and this is a small part of that effort), but here it is
> for testing/review/bug reports/feature requests/any other kind of
> feedback.
>
> And here it is: https://github.com/mbork/org-one-to-many
>
> Best,
>
> --
> Marcin Borkowski
> http://octd.wmi.amu.edu.pl/en/Marcin_Borkowski
> Adam Mickiewicz University
>
>

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

Re: Announcement: org-one-to-many

[Marcin Borkowski]

On 2014-10-23, at 16:39, Daniel Clemente wrote:

> Hi,
> breaking a big .org file in many small pieces is one of my major concerns
> with .org and one which gives me lots of problems. Thank you very much for
> having the clear objective of one-to-many.

You're welcome!

> If your goal is HTML export, you can do a function that iterates over all
> headers and exports them (see below). But then links are broken, you need
> to decide filenames, etc. Which is what your project solves.

Or I hope so – at least;-).

> org-one-to-many has a shortcoming which is present in so many "org to blog"
> systems: it expects a particular structure (in this case, all headers at
> the same level). I suggest you iterate over search results of a normal
> search:
>
> For instance, you can get all headers tagged with "tobesplit" like this:
> (org-map-entries (lambda () (line-number-at-pos))  "+tobesplit" 'agenda)
>
> One of the possible searches is "headers at level 2", so this new system
> would include the one you have.

I thought about it.  I'd like to first make my code a bit cleaner and
fix one bug I know of.  I think this will be fairly easy; I could split
headers with some property (a tag might not be a good idea, since tags
are inherited).

> Greetings

Thanks for your input!

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

Re: Announcement: org-one-to-many

[Daniel Clemente]

El Thu, 23 Oct 2014 19:58:48 +0200 Marcin Borkowski va escriure:
> > For instance, you can get all headers tagged with "tobesplit" like this:
> > (org-map-entries (lambda () (line-number-at-pos))  "+tobesplit" 'agenda)
> >
> > One of the possible searches is "headers at level 2", so this new system
> > would include the one you have.
> 
> I thought about it.  I'd like to first make my code a bit cleaner and
> fix one bug I know of.  I think this will be fairly easy; I could split
> headers with some property (a tag might not be a good idea, since tags
> are inherited).
> 

Tag inheritance is customizable (org-use-tag-inheritance). I don't use it.

Anyway, if I have:
* aaaa    :publish:
** bbbbb
** ccc    :publish:
** dddd
* eeee

Well, it makes sense to export 2 .org: aaa.org (including bbbb,cccc,ddd) and ccc.org (including only ccc)

Re: Announcement: org-one-to-many

[Marcin Borkowski]

Hello everybody,

so I've got this little library of mine, called org-one-to-many, which
can split an Org file into pieces, modifying internal links so that they
still point to the same place (even if now in another file).

But I have a problem with it.  I would like to export all the resulting
files into, say, HTML, and the problem is that all the options
(obviously) don't propagate to the “subfiles” – so that if I say e.g.

#+LANGUAGE: pl

anywhere in the file, it is not copied to all the resulting files
(generated from headings), unless this line happens to be in one of them
(and then it disappears from the “main” file).

I can see two solutions to this problem.  One is to somehow recognize
these lines and copy them to all the resulting files.  One trouble with
that is that I’d have to decide, for instance, /where/ to put them – at
the beginning?

The easier solution, which /might/ also be “cleaner” in a sense, is to
recognize some kind of “special” heading - for instance,

* COMMENT Config
#+LANGUAGE: pl

or something like that, and copy it verbatim to all the generated files,
say – at their end.

What do you think?  Can you see another solution?  If not, which of the
above do you consider a better one?

TIA,

-- 
Marcin Borkowski
http://octd.wmi.amu.edu.pl/en/Marcin_Borkowski
Faculty of Mathematics and Computer Science
Adam Mickiewicz University

Re: Announcement: org-one-to-many

[John Kitchin]

I think it would be easy to copy all the file keywords. One way would
just be searching by regexp. Another way could be similar to:

http://kitchingroup.cheme.cmu.edu/blog/2013/05/05/Getting-keyword-options-in-org-files/

if you know in advance what the important ones are.

Marcin Borkowski writes:

> Hello everybody,
>
> so I've got this little library of mine, called org-one-to-many, which
> can split an Org file into pieces, modifying internal links so that they
> still point to the same place (even if now in another file).
>
> But I have a problem with it.  I would like to export all the resulting
> files into, say, HTML, and the problem is that all the options
> (obviously) don't propagate to the “subfiles” – so that if I say e.g.
>
> #+LANGUAGE: pl
>
> anywhere in the file, it is not copied to all the resulting files
> (generated from headings), unless this line happens to be in one of them
> (and then it disappears from the “main” file).
>
> I can see two solutions to this problem.  One is to somehow recognize
> these lines and copy them to all the resulting files.  One trouble with
> that is that I’d have to decide, for instance, /where/ to put them – at
> the beginning?
>
> The easier solution, which /might/ also be “cleaner” in a sense, is to
> recognize some kind of “special” heading - for instance,
>
> * COMMENT Config
> #+LANGUAGE: pl
>
> or something like that, and copy it verbatim to all the generated files,
> say – at their end.
>
> What do you think?  Can you see another solution?  If not, which of the
> above do you consider a better one?
>
> TIA,

--
Professor John Kitchin
Doherty Hall A207F
Department of Chemical Engineering
Carnegie Mellon University
Pittsburgh, PA 15213
412-268-7803
@johnkitchin
http://kitchingroup.cheme.cmu.edu

Re: Announcement: org-one-to-many

[Marcin Borkowski]

On 2015-02-13, at 00:43, John Kitchin <jkitchin@andrew.cmu.edu> wrote:

> I think it would be easy to copy all the file keywords. One way would
> just be searching by regexp. Another way could be similar to:
>
> http://kitchingroup.cheme.cmu.edu/blog/2013/05/05/Getting-keyword-options-in-org-files/
>
> if you know in advance what the important ones are.

Thanks for your input!

OTOH, /getting/ keywords/options is only one half of the problem, the
other half being is /putting/ them in some place.  Personally, I think
putting them in the section of their own might be a good idea.

Best,

-- 
Marcin Borkowski
http://octd.wmi.amu.edu.pl/en/Marcin_Borkowski
Faculty of Mathematics and Computer Science
Adam Mickiewicz University

Re: Announcement: org-one-to-many

[John Kitchin]

I think it doesn't matter where they go. I usally put them at the top,
but sometimes at the bottom, sometimes in a section I mark noexport to
keep them out of the way. It depends on whether someone should actually
read them, or if this is just an intermediate to an end.

Marcin Borkowski writes:

> On 2015-02-13, at 00:43, John Kitchin <jkitchin@andrew.cmu.edu> wrote:
>
>> I think it would be easy to copy all the file keywords. One way would
>> just be searching by regexp. Another way could be similar to:
>>
>> http://kitchingroup.cheme.cmu.edu/blog/2013/05/05/Getting-keyword-options-in-org-files/
>>
>> if you know in advance what the important ones are.
>
> Thanks for your input!
>
> OTOH, /getting/ keywords/options is only one half of the problem, the
> other half being is /putting/ them in some place.  Personally, I think
> putting them in the section of their own might be a good idea.
>
> Best,

--
Professor John Kitchin
Doherty Hall A207F
Department of Chemical Engineering
Carnegie Mellon University
Pittsburgh, PA 15213
412-268-7803
@johnkitchin
http://kitchingroup.cheme.cmu.edu

Re: Announcement: org-one-to-many

[Sebastien Vauban]

Hello Marcin,

Marcin Borkowski wrote:
> so I've got this little library of mine, called org-one-to-many, which
> can split an Org file into pieces, modifying internal links so that they
> still point to the same place (even if now in another file).
>
> But I have a problem with it.  I would like to export all the resulting
> files into, say, HTML, and the problem is that all the options
> (obviously) don't propagate to the “subfiles” [...]

Maybe you've already explained it, but it's not clear to me whether you
really cut one big Org file into smaller ones (once and for all) or you
simply export one big Org file into different HTML ones. Can you
restate it?

Best regards,
  Seb

-- 
Sebastien Vauban