Re: Emacs will never be a WYSIWYG-editor and should not try to

[Andreas Röhler]

Am 26.11.2013 22:45, schrieb Achim Gratz:
> Andreas Röhler writes:
> > If you take a look into the org-directory, you'll see several files,
> > whose name indicate the purpose beside from org-mode in its strict
> > sense.
>
> Before you send others to read those, why not have a look yourself?

Why such a tune?
All I'm saying is, a lot of useful things exist in org-mode, which might be of 
use outside too.
There is an org-timer.el and a timer.el, and org-table.el and a table.el etc.

> > Probably it would be great to have the exporter(s?) --which may output
> > into HTML, PDF or ODF-- available in all text-modes.
>
> You might want to take notice that the exporters do exactly nothing
> without org-element and org-element defines Org syntax and nothing else.

Which also means: some parts of org-mode could be re-considered WRT to 
modularity.
Indeed org-mode didn't invent exporting, so it's useful probably to look into 
muse or whatever too.


> >  From my perspective porting org-footnote.el would pay.
>
> This too depends on the rest of Org to figure out what it is looking at
> and where to place the actual content (and then find it again).
>
> > Well, the code providing literal programming is quite an item by
> > themselves, no trivial thing.  Just being surprised it should not work
> > outside org-mode too ;)
>
> Again, it relies heavily on the infrastructure provided by Org.

If there is an infrastructure useful for org-mode, part of these infrastructure 
will turn out useful for all Emacs.
There is a bad and a good thing. The god thing is, these things exist. The bad: people a compelled into a separate ecosystem, with its own issues and quirks, a separate 
bug-reporting etc.


> There are bits and pieces in Org that would likely benefit from
> generalization that might re-factor them out of Org (or not, since
> nobody tried yet).

It might be done step by step, starting with useful subroutines like org-trim.
Make a common trim in subr.el from it etc.

That would reduce parallel programming, reduce the volume of the sources etc.

 But such refactoring would be a lot of work and
> you won't be able to contribute, so…

The FSF recieved my disclaimer. Maybe it's sufficient to port the trim 
function? ;)