emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
From: Tim Cross <theophilusx@gmail.com>
To: Russell Adams <RLAdams@AdamsInfoServ.Com>
Cc: emacs-orgmode@gnu.org
Subject: Re: Concrete suggestions to improve Org mode third-party integration :: an afterthought following Karl Voit's Orgdown proposal
Date: Thu, 09 Dec 2021 08:50:56 +1100	[thread overview]
Message-ID: <87lf0uu4mj.fsf@gmail.com> (raw)
In-Reply-To: <YbESNxUo4g9k84sP@maokai>


Russell Adams <RLAdams@AdamsInfoServ.Com> writes:

> On Wed, Dec 08, 2021 at 08:22:31PM +0100, Dr. Arne Babenhauserheide wrote:
>> >  - Anything outside of basic Org syntax, tables and source blocks I do
>> >    directly in latex. Images are a good example. I will use latex code
>> >    for the image, sizing, orientation, etc instead of relying on Org's
>> >    extended syntax for image links, caption, and attributes.
>>
>> > As a result my publishing has been pretty consistent for customer
>> > documents. I also only update my Org between projects. ;]
>>
>> If I had needed a stronger argument for more backwards compatibility,
>> this list of habits is it. That should not be required to keep your
>> org-mode documents working.
>
> I think this may be a problem regarding expectations.
>
> I expect Org to be great at handling it's own format, and to give me
> the editing experience within Emacs that I have come to expect.
>
> That Org can also be used to export to other formats is both a
> blessing and a curse. Org can only do high level constructs in the
> languages it exports to, and really should only be expected to do just
> that. It's a paper thin macro or template over a much more complicated
> document language.
>
> Org's lightweight markup has had things bolted onto it repeatedly for
> years. Typically issues have resulted in changes in the export engine
> defaults (ie: html moving to using css), and not Org itself changing
> the editing experience in Emacs.
>
>> Org-mode is not just a library, it keeps user-data. It should really not
>> be volatile¹.
>
> Org's format isn't volatile. You could view those anytime in Org and
> see what you expect to see. The issue you are having is that an old
> document may not export perfectly over time.
>
> What if Org didn't diverge, the underlying format did?
>
>> If I can’t trust org-mode to keep working but have to check the
>> documents every time I come back to them — and might have to spend hours
>> fixing them — then it not suitable for writing, as much as that would
>> pain me (because it would cast into doubt most of my decisions around
>> writing of the past decade).
>
> You can absolutely trust Org to open, view, and edit it's own files
> even decades old. It's plain text, so there's no risk in experiencing
> a permanent loss of data.
>
> The exporting is the difference in expectations. Org's lightweight
> markup is quite simple, and the documents it produces should be as
> well. This is much like the original HTML specification. Look how
> complicated it is to write HTML now with CSS and Javascript emulating
> mundane functions after decades of bolt on "standards".
>
> If I had a document which had a highly sensitive output format which
> had to remain perfect over decades, I would argue that perhaps Org
> wasn't the correct markup to write it in.
>
> Much like plain text vs original simple HTML, vs Latex. Text was plain
> and simple, with little formatting. Durable and ugly at times, but
> always legible. The original HTML had more markup required, but it was
> hyperlinks and some simple fonts and formats. Prettier, variable
> fonts, colors, pictures. Latex can make pixel perfect PDFs with
> multiple medias and professional results, however it has a very
> specific format and this may be poor for writing in dynamically. HTML
> required decades of tweaks to become "pixel perfect", and HTML a
> decade old rarely renders properly in a "modern" browser.
>
> At some point with each of these languages, the formatting became more
> important than the content.
>
> I write all my customer documentation in Org, with custom Latex
> templates. I've only had to make major changes once, I think between
> v8 and v9. Yes, my old documents won't export identically without the
> changes. The likelihood they still export is high, and 100% that I can
> view and edit them correctly in Org. It's only the polished result
> which could degrade. I may have to tweak them to make them export the
> same way again, but I expect they can without too much effort. I'm OK
> with that.
>
>> Please do not make org-mode volatile.¹
>
> I think our maintainers have done an excellent job of minimizing the
> impact of any changes. However when changes are needed, I trust their
> judgement to have good reason to make a change and document it
> thoroughly.
>
> However I only export Org to be backwardly compatible with itself, not
> the languages it makes exports to.
>

Those are excellent points and highlight the fact much of what org does
is not always under the control of org. As you point out, the HTML
specification has changed a lot in the last 30 years. It use to be
'standard' to use upper case for HTML tags and closing tags were not
always required. However, html5 requires tags in lower case and now
expects closing tags.

Irony here is we are dealing with a mediam which is inherently
susceptible to change. Talk to any archivist and they will tell you
about the huge challenges they 'digital age' has created for them. They
will tell you about all the data they have stored in various formats
which either cannot be read (there are miles of tapes out there where
you cannot even find a hardware device capable of reading them) or which
have degraded too much. The life expectancy of digital media is far less
than printed media. Much of what large archiving sites do these days is
constantly copying digital artefacts from one bit of media to another.
Often, this isn't even because of format change, but simply due to the
way digital data degrades over time. I'm still amazed when people seem
shocked when I tell them that those CDs or DVDs they burnt with all that
gigabytes of critical data will begin to degrade after about 5 years and
after 10 years you will see increasing instances of data corruption. In
some instances, critical digital data is still printed to paper because
the printed format still has a much, much longer shelf life than digital
data. We can still read books printed by Gutenberg, Meanwhile, there
are disks of documents you saved in 2000 which will likely have access
problems, assuming you still have a device which can read that format.

As you point out, the big benefit of org mode is that the files are
plain text. This means you will always be able to 'fix' any issues which
arise from change. It might not be convenient and you may be frustrated
by such change, but you will likely have a much better outcome than you
would with any other document formatting system which is not based on
plain text. 


  reply	other threads:[~2021-12-08 22:14 UTC|newest]

Thread overview: 59+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-12-05  7:35 Concrete suggestions to improve Org mode third-party integration :: an afterthought following Karl Voit's Orgdown proposal Ihor Radchenko
2021-12-05  9:16 ` Juan Manuel Macías
2021-12-05 10:24   ` Ihor Radchenko
2021-12-05 11:08     ` Juan Manuel Macías
2021-12-05 11:54       ` Heinz Tuechler
2021-12-05 12:08       ` Ihor Radchenko
2021-12-05 13:32         ` Tim Cross
2021-12-05 13:52           ` Bruce D'Arcus
2021-12-05 22:20             ` Tim Cross
2021-12-05 14:30           ` Ihor Radchenko
2021-12-05 22:39             ` Tim Cross
2021-12-08 13:47               ` Ihor Radchenko
2021-12-08 14:39                 ` Tim Cross
2021-12-08 16:16                   ` Dr. Arne Babenhauserheide
2021-12-08 17:07                     ` Russell Adams
2021-12-08 19:22                       ` Dr. Arne Babenhauserheide
2021-12-08 20:14                         ` Russell Adams
2021-12-08 21:50                           ` Tim Cross [this message]
2021-12-09  8:12                             ` Dr. Arne Babenhauserheide
2021-12-08 21:25                         ` Tim Cross
2021-12-09  8:07                           ` Dr. Arne Babenhauserheide
2021-12-09  8:36                             ` Timothy
2021-12-09  9:18                               ` Ihor Radchenko
2021-12-09 10:46                     ` Eric S Fraga
2021-12-09 15:21                       ` Russell Adams
2021-12-09 16:25                         ` Eric S Fraga
2021-12-09 21:15                           ` Samuel Wales
2021-12-09 23:27                         ` Dr. Arne Babenhauserheide
2021-12-10  2:42                           ` Tim Cross
2021-12-10  6:08                             ` Dr. Arne Babenhauserheide
2021-12-11 10:03                   ` Ihor Radchenko
2021-12-11 21:19                     ` Tim Cross
2021-12-06 19:41             ` Karl Voit
2021-12-05 18:59         ` Juan Manuel Macías
2021-12-05 23:24           ` Russell Adams
2021-12-06  5:57             ` Juan Manuel Macías
2021-12-06  6:02               ` Timothy
2021-12-06  7:24                 ` Juan Manuel Macías
2021-12-06 10:04                   ` Greg Minshall
2021-12-06 14:59                     ` Juan Manuel Macías
2021-12-06 17:59                       ` Tom Gillespie
2021-12-06 18:25                         ` M. ‘quintus’ Gülker
2021-12-06 18:42                           ` Russell Adams
2021-12-06 18:47                             ` Timothy
2021-12-06 19:28                               ` Russell Adams
2021-12-06 19:34                                 ` Timothy
2021-12-06 18:30                         ` Russell Adams
2021-12-06 19:10                         ` Gerry Agbobada
2021-12-08 12:56                           ` Ihor Radchenko
2021-12-06 10:08         ` Greg Minshall
2021-12-06 19:45         ` Karl Voit
2021-12-07 11:08           ` Vincent Breton
2021-12-08 13:13             ` Ihor Radchenko
2021-12-08 13:30           ` Ihor Radchenko
2021-12-05 13:06   ` Tim Cross
2021-12-05 14:55     ` Ihor Radchenko
2021-12-05 18:54 ` Timothy
2021-12-06 11:08 ` Max Nikulin
2021-12-06 18:43 ` Russell Adams

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.orgmode.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87lf0uu4mj.fsf@gmail.com \
    --to=theophilusx@gmail.com \
    --cc=RLAdams@AdamsInfoServ.Com \
    --cc=emacs-orgmode@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).