emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
From: Tim Cross <theophilusx@gmail.com>
To: Marko Schuetz-Schmuck <MarkoSchuetz@web.de>
Cc: emacs-orgmode@gnu.org
Subject: Re: A requires/provides approach to linking source code blocks
Date: Fri, 09 Jul 2021 05:32:35 +1000	[thread overview]
Message-ID: <87k0m0tw5l.fsf@gmail.com> (raw)
In-Reply-To: <87czrsai4w.fsf@tpad-m.i-did-not-set--mail-host-address--so-tickle-me>

Marko Schuetz-Schmuck <MarkoSchuetz@web.de> writes:

> [[PGP Signed Part:Undecided]]
> Dear All,
> AFAIU in the current support for literate programming I can establish
> sequence between blocks by either tangling the entire file whereby the
> blocks are written to the source code file in the sequence in which they
> appear in the org-mode file or I can name the blocks and use noweb
> linking to explicitly state the precise sequence in which the blocks
> appear in the source code file.
> I would find it useful to have a more declarative way for specifying
> sequence. I imagine e.g. using "#+REQUIRES:" and "#+PROVIDES:" to
> capture dependency and then have the exporter compute a sequence
> satisfying these. I would think that this makes the maintenance of the
> dependencies more convenient.
> I'd be interested in feedback on the idea.
> Please include my email address in the reply as I am not subscribed to
> the list.

My concern here is with the additional complexity. This is already a
somewhat complex aspect of org mode and the behaviour you describe can
effectively be done using noweb, although as you say, not as
declarative in style.

I'm not sure the added complexity is worth the additional maintenance
overhead and I would be concerned regarding how much confusion this
could cause i.e. someone uses both noweb and declarative
provide/require. These additions are also likely to hamper any efforts
to improve performance - a topic which comes up on a fairly regular

This could just be me, but recently, I'm becoming very concerned about
the growth of additional features and options in org mode. Many of the
new things being requested are for relatively narrow use cases and
represent functionality which can largely be achieved with existing
features. At the same time, there also seems to be a growing
frequency in patches which introduce regression bugs and patches to fix

This is all beginning to feel like we are running very close to the
tipping point at which time we will have something that is so complex
that only a very few people are able to maintain the code base and keep
the system stable. New maintainers are discouraged because of the code
complexity. We could end up in a position where really important issues
cannot be addressed or addressed in a timely manner because of the
overall complexity of the code base and time it takes to fix and test
and dependence on a very few number of maintainers who are already
swamped with work. 

At some point, I think we may want to consider a temporary freeze on new
functionality and spend a few months just focusing on bug fixes and code
base improvements or re-factoring. It might also be worthwhile providing
some guidelines or criteria/procedures for assessing proposed new
features to avoid a perception of new features being accepted/rejected
based on personality, loudness of voice or some other real or perceived
and irrelevant basis.

Tim Cross

  reply	other threads:[~2021-07-08 20:18 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-07-08 16:24 A requires/provides approach to linking source code blocks Marko Schuetz-Schmuck
2021-07-08 19:32 ` Tim Cross [this message]
2021-07-09  8:22   ` Slowing down new features Timothy
2021-07-09 13:38   ` A requires/provides approach to linking source code blocks Maxim Nikulin
2021-07-09 20:27   ` Berry, Charles via General discussions about Org-mode.
2021-07-09  7:29 ` Stefan Nobis
  -- strict thread matches above, loose matches on Subject: below --
2021-07-09 17:00 autofrettage
2021-07-12  9:55 ` Alexander Adolf
2021-07-13 19:18   ` Tom Gillespie
2021-07-13 19:42     ` George Mauer
2021-07-14  0:44     ` Tim Cross
2021-07-14  1:53       ` Samuel Wales

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:

  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=87k0m0tw5l.fsf@gmail.com \
    --to=theophilusx@gmail.com \
    --cc=MarkoSchuetz@web.de \
    --cc=emacs-orgmode@gnu.org \


* 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


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).