From: Tim Cross <email@example.com> To: Marko Schuetz-Schmuck <MarkoSchuetz@web.de> Cc: firstname.lastname@example.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: <email@example.com> (raw) In-Reply-To: <firstname.lastname@example.org> 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 basis. 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 patches. 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
next prev parent 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 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 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: 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 \ --email@example.com \ --firstname.lastname@example.org \ --cc=MarkoSchuetz@web.de \ --email@example.com \ --subject='Re: A requires/provides approach to linking source code blocks' \ /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
Code repositories for project(s) associated with this 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).