Re: Line breaks in org-mode having version control in mind

[Jambunathan K <kjambunathan@gmail.com>]

If you have really l...o...n...g lines you need to turn on some sort of
caching so that Emacs display doesn't start sucking.  

I believe the variable you need is this.  Just double check.  I use
development version of Emacs so the details could differ for your
specific version.

    cache-long-scans
      Variable: Non-nil means that Emacs should use caches in attempt to
                speedup buffer scans.

    ** `cache-long-line-scans' has been renamed to `cache-long-scans'
    because it affects caching of paragraph scanning results as well.

----------------------------------------------------------------

Org files in sense paragraph oriented and not line-oriented.  There was
some work on Org Merge Driver.  (Search for it in the list).  I had also
pointed out this LibreOffice GSoC project earlier -
http://gsoc-tzvetelina.blogspot.in/ - the ideas discussed therein could
be of some relevance to building a Org merge driver.

Dror Atariah <drorata@gmail.com> writes:

> I am trying to extend my usage of org, and one of the things I want to
> integrate is version controlling of my org files. This is obviously
> straight forward, but I am wondering about the best line breaking
> approach to use. In my LaTeX docs I maintain one physical line per
> sentence [1]. This way, when I change one word in a paragraph, it
> affects only one line, and looking for differences between versions is
> easy. Otherwise, when using fill-paragraph for instance, one gets
> messy changes of the file, as the one word change can influence the
> whole paragraph.
>
> Therefore, as I mentioned, in LaTeX I use visual-line-mode and I
> insert manually line breaks at the end of sentences (or where *I* find
> appropriate). What would be the best practice for org? I understand
> that visual-line-mode has some problems when it comes to
> tables... What other issues are there? What do you do when you keep
> your org file under VC?
>
> Thanks in advance,
> Dror
>
> [1] http://tex.stackexchange.com/a/4378/412