emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
From: Tom Gillespie <tgbugs@gmail.com>
To: mooss <mooss@protonmail.com>
Cc: "emacs-orgmode@gnu.org" <emacs-orgmode@gnu.org>
Subject: Re: Multiple named code blocks
Date: Sat, 28 Nov 2020 17:59:47 -0500	[thread overview]
Message-ID: <CA+G3_PMOqv0HeBd36N5nvfhmH=+iLzp0cv9RHVOUvb=fGmB1_w@mail.gmail.com> (raw)
In-Reply-To: <2PnBr0V8kH99j60xzpYf0HgMQZZtQ_FTnrNNhbHxzgTnxuJqv3y_tSGDNcv4Pqzvlfy4RLgmUbw83UIRiJXTgV9-_fDlwJOaCIon3zJo_-E=@protonmail.com>

Hi Félix,
   I think that it is probably not a good idea to implicitly
concatenate blocks that share the same name. There are a number of
major downsides. One reason is that all the other parts of org-mode
assume that there is only a single block with that name, or rather
have undefined behavior if there is more than one, so all the other
reference resolving infrastructure will not work as expected and it
will be hard to navigate to additional blocks. The concatenation
behavior you describe does work if you specify the same file for
tangling, however that uses completely different code. Further, if we
were to define behavior for what should happen if there are multiple
blocks or sections with the same name it would probably either be to
signal an error (if you are in the more immutable camp), that the
first named block is the "canonical" block (current implementation),
or that the last defined block is the "canonical" block (if you want
org to be more like a programming language). The current
implementation follows the first named block, but the reason why the
manual states that it is undefined is because even that behavior
should not be relied upon (thus why an error is probably the most
friendly thing to do). Consider also that if you have different blocks
by the same name in different sections and you reorder the sections
the order in which they are nowebbed in will change. Given that that
behavior can be actively dangerous (imagine a block with cd
some-folder followed by a block rm contents/ -r getting reordered),
there are major downsides to trying to guess how to concatenate
multiple blocks and trying to specify restrictions on where and how
using the same name is allowed or can be safely used is not something
that anyone would want to try to do. Best!

  reply	other threads:[~2020-11-28 23:00 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-11-28 22:35 Multiple named code blocks mooss
2020-11-28 22:59 ` Tom Gillespie [this message]
2020-11-29  0:40   ` mooss
2020-11-29  3:24 ` Greg Minshall
2020-11-30 11:38   ` mooss
2020-11-29  8:28 ` Diego Zamboni
2020-11-30 11:39   ` mooss

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='CA+G3_PMOqv0HeBd36N5nvfhmH=+iLzp0cv9RHVOUvb=fGmB1_w@mail.gmail.com' \
    --to=tgbugs@gmail.com \
    --cc=emacs-orgmode@gnu.org \
    --cc=mooss@protonmail.com \


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