From: "Dr. Arne Babenhauserheide" <arne_bab@web.de>
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: Wed, 08 Dec 2021 20:22:31 +0100 [thread overview]
Message-ID: <87lf0uvq9s.fsf@web.de> (raw)
In-Reply-To: <YbDmV2AJ9HZ4ogOW@maokai>
[-- Attachment #1: Type: text/plain, Size: 4578 bytes --]
Russell Adams <RLAdams@AdamsInfoServ.Com> writes:
> On Wed, Dec 08, 2021 at 05:16:20PM +0100, Dr. Arne Babenhauserheide wrote:
>>
>> Tim Cross <theophilusx@gmail.com> writes:
>>
>> > Backwards compatibility is important and changes should never be done
>> > lightly. However, that doesn't mean they don't occur (we have already
>> > had breaking changes, so old org files are likely to have issues
>> > already). Backwards compatibility can also become a burden and
>>
>> I already spent several hours fixing old presentations, because of org
>> format changes, so I want to put in a strong vote for backwards
>> compatibility.
>
> I agree completely. Luckily org-lint provides great insights into
> changes. Reading the release notes between major versions is a good
> idea. I have found that anytime I've had a problem it was well
> documented in the release notes, and that I simply neglected to read
> them.
>
>> If you have 1400 slides of lectures, all carefully laid out to convey
>> information as best as possible, and you realize a few days before the
>> lecture when you want to update them that the layout is broken, because
>> of some minor change in interpretation of empty headlines in org-beamer
>> export so you have to go over each slide individually to make sure that
>> nothing is cut off and no layout is broken — and check the compile to
>> latex many times until the layout is working again — that is a huge
>> cost.
>
> I don't see this as much different from the issues encountered with
> compiling code with libraries. During development you have to freeze
> libraries you're working against. After an update, you'll have to
> check again.
>
> I've had this come up in my professional documents on occasion, and
> I've developed habits to help. For instance:
>
> - Every file gets an export header template and all settings are done
> there.
>
> - Exported documents must never depend on variables in my
> init.el. All variables must be stored as file local variables if
> they required customization against Org defaults.
I actually have separate .emacs.d folders and autotools setups for most
of my org-mode projects. But that’s to separate it from my emacs setup,
not as protection against a potentially volatile¹ document format.
> - I run org-lint first if I suspect a problem.
>
> - I pay latex experts to make my templates so I don't have to.
>
> - 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 use org-mode for a lecture I give as small side-job because I like
teaching. It is not my main job.
And I use org-mode for hobby-projects. Yes, the hobby project is a 400
page RPG rulebook, but it is still a hobby project.
And I use org-mode to publish my personal website (also as a Hobby),
with about 150% that size.
And my projects do not end. Some of these documents are already in use
for a decade.
Org-mode is not just a library, it keeps user-data. It should really not
be volatile¹.
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).
To date, I only had a bigger problem once (and that hurt a lot, because
it was just before giving a lecture, so I had to ditch most of the
improvements I wanted to do and instead spend all the time fixing the
document), but the talk here about “sometimes you have to break
compatibility” goes into a direction I consider as very dangerous.
Please do not make org-mode volatile.¹
Org-Mode and Emacs have mostly been stable the past 15 years. And it is
good to be stable; a strength that is highlighted much too seldomly.
Best wishes,
Arne
¹: https://stevelosh.com/blog/2012/04/volatile-software/
--
Unpolitisch sein
heißt politisch sein,
ohne es zu merken.
draketo.de
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 1125 bytes --]
next prev parent reply other threads:[~2021-12-08 19:42 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 [this message]
2021-12-08 20:14 ` Russell Adams
2021-12-08 21:50 ` Tim Cross
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=87lf0uvq9s.fsf@web.de \
--to=arne_bab@web.de \
--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).