emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
From: Achim Gratz <Stromeko@nexgo.de>
To: emacs-orgmode@gnu.org
Subject: Re: Literate Programming - Continue a Source Block?
Date: Sun, 12 Jun 2011 10:32:01 +0200	[thread overview]
Message-ID: <87mxhn8n7i.fsf@Rainer.invalid> (raw)
In-Reply-To: 8739jhv4ma.fsf@gmail.com

Eric Schulte <schulte.eric@gmail.com> writes:
> I think "append" is just as clear as concatenate,

Fair enough, in my mind "append" needs an existing entity, but I guess
it could be an empty one.

> and collate implies shuffling which is not happening.

Well, I was getting ahead of myself...  I hope you don't mind me harping
on about this.

> I'm wary of adding too much duplicate functionality.  It is already
> possible to organize the tangling of many named code blocks using noweb
> reference expansion (a feature which I've used myself on real projects
> in the past).  This existing method allows for unique block names and
> for arbitrary tangling order.

The examples presented in this thread pointed out one difficulty with
how noweb references currently work, namely that you need to know in
advance all block names for finally tangling them and that when adding
or removing things you need to remember to keep these references current
in potentially many places.

> Simplicity is the only reason that the new name-based appending behavior
> was implemented, simplicity which (in my opinion) is lost when the user
> defines a naming and sorting schema.

My general objection is that since you now require that the names be all
the same, there is no way to distinguish between those blocks anymore.
This will come back to bite you when you then later need to make a
distinction since you'll then have to rework everything to unique names
again.  I consider that sort of simplicity a trap for the unwary.

Splitting between a basename and an index extension would instead allow
for appending with the basename and still getting at individual blocks
using the full name (with the index part).  I've had one specific
use-case in mind where this would be needed.  You'd normally just
concatenate all source blocks (let's assume for the moment that the
index part is separated from the basename by "::")

  <<source::*>>

Let's say you have three source blocks and need to point-patch the
second one for this run:

  <<source::1>>
  <<source-patch::2>>
  <<source::3>>

If the three source blocks are all just named "source", there's no way
to do this short of changing their names and all the references that use
them.

The index part doesn't have to be numeric, it just needs to be
orderable.  Anyone not using index extensions gets an implicit one by
order of appearance, so that wouldn't require any code duplication and
you can in this case still say

  <<source>>

Being able to provide custom naming and sorting schemes could be
deferred to hook functions the user has to provide, as they will indeed
be rarely needed.  So an implementation that keeps current behaviour
would provide an implicit indexer (by order of appearance), an empty
sorter and three selectors (all=append, first last).  Anyone who needs
more than that has to customize those functions, but I suppose the more
common application scenarios will sneak into the baseline sooner or
later.  The move from implicit to explicit indexing should be supported
by providing another hook in the implicit indexer.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Factory and User Sound Singles for Waldorf Blofeld:
http://Synth.Stromeko.net/Downloads.html#WaldorfSounds

  reply	other threads:[~2011-06-12  8:32 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-06-08  5:47 Literate Programming - Continue a Source Block? Neeum Zawan
2011-06-08  7:34 ` Sebastien Vauban
2011-06-08 15:20   ` Neeum Zawan
2011-06-08 19:40     ` Eric Schulte
2011-06-08 21:20       ` Neeum Zawan
2011-06-10  4:55         ` Avdi Grimm
2011-06-10 19:09         ` Eric Schulte
2011-06-10 19:27           ` Achim Gratz
2011-06-10 20:00             ` Eric Schulte
2011-06-12  8:32               ` Achim Gratz [this message]
2011-06-13 22:04                 ` Eric Schulte
2011-06-14 20:48                   ` Achim Gratz
2011-06-15 17:23                     ` Eric Schulte
2011-06-15 21:19                       ` Achim Gratz
2011-06-16  4:54                         ` Eric Schulte
2011-06-16  2:35                       ` Neeum Zawan
2011-06-11  1:02             ` Neeum Zawan
2011-06-11  0:44           ` Neeum Zawan
2011-06-11 20:08             ` Eric Schulte
2011-06-12  5:36               ` Neeum Zawan
2011-06-13 21:57                 ` Eric Schulte
2011-06-15  5:17                   ` Neeum Zawan
2011-06-15 17:27                     ` Eric Schulte
2011-06-15 19:37                       ` Neeum Zawan
2011-06-16  2:26                         ` Eric Schulte
2011-06-17  4:30                           ` Neeum Zawan
2011-06-17  4:39                             ` Eric Schulte
2011-06-17  7:00                               ` Sebastien Vauban
2011-06-19 23:38                                 ` Neeum Zawan
2011-06-16 10:14     ` Olaf.Hamann

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=87mxhn8n7i.fsf@Rainer.invalid \
    --to=stromeko@nexgo.de \
    --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).