emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
From: "Eric Schulte" <schulte.eric@gmail.com>
To: Jambunathan K <kjambunathan@gmail.com>
Cc: Dan Davison <davison@stats.ox.ac.uk>, emacs-orgmode@gnu.org
Subject: Re: [BABEL] [PROPOSAL] Seemless editing of Babel Blocks
Date: Sun, 05 Sep 2010 14:22:24 -0600	[thread overview]
Message-ID: <877hizlwk6.fsf@gmail.com> (raw)
In-Reply-To: 818w3gv7j7.fsf@gmail.com

Hi Jambunathan,

Jambunathan K <kjambunathan@gmail.com> writes:

> Eric
>
>>
>> I've just pushed up an implementation of the functionality described at
>> the link above, see [1] for examples and details.
>>
>
>> Footnotes: 
>> [1]  http://eschulte.github.com/babel-dev/DONE-tangle-entire-org-mode-file-in-comments.html
>>
>
> I have pulled your changes and examined it. Some commets:
>
> Comment #1: Org Manual
>
>> Org Manual - Section 14.8.2.7 comments
>
>> org - Include text from the original org-mode file which preceded the
>> code block as a comment which precedes the tangled code.
>
> I suggest the following wording - 
>
> "Include text from the org-mode file as a comment. 
>
>  The text is picked from the leading context of the tangled code and is
>  limited by the nearest headline or source block as the case may be."
>

Thanks, I've made this change in the manual.

>
> Comment #2: Perceived gaps
>
> In my original case,
>
> 1. Tangling happens in-place.
>
>    The source and target buffers are one and the same only their major
>    made changes. i.e., it is destructive. Think of 'replace-region' ...
>
> 2. There is no lossage.
>
>    I can tangle to elisp-mode and untangle it to org-mode without any
>    round-trip losses.
>
>    With your changes, the following are lost - the 'trailing' text and
>    the 'stars' in the headline.
>
>
> That said, I have upgraded my request to a generic API (see attachment)
> and I am not too particular about my original use-case (which I agree as
> 'contrived', 'drastic' and 'one-off')
>

Great.  I've acted on your API request so hopefully that will supersede
the need for more drastic tangling extensions.

Thanks -- Eric

>
> Jambunathan K.
>
> Attachments: This for the benefit of the list. 
>
> I had accidentally unicast the reply. My recent transition to gnus has
> made me very clumsy.
>
> From: Jambunathan K <kjambunathan@gmail.com>
> To: "Eric Schulte" <schulte.eric@gmail.com>
> Subject: Re: [BABEL] [PROPOSAL] Seemless editing of Babel Blocks
> References: <4C459236.3@gmail.com> <87k4opu5fk.fsf@gmail.com>
> 	<81hbivx88y.fsf@gmail.com> <8139ueykvc.fsf_-_@gmail.com>
> 	<878w3j1zos.fsf@stats.ox.ac.uk> <81k4n13mww.fsf@gmail.com>
> 	<87r5h9czxf.fsf@gmail.com>
> X-Draft-From: ("nntp+news.gmane.org:gmane.emacs.orgmode" 29790)
> Date: Sun, 05 Sep 2010 14:28:16 +0530
> In-Reply-To: <87r5h9czxf.fsf@gmail.com> (Eric Schulte's message of "Sat, 04
> 	Sep 2010 09:04:03 -0600")
> Message-ID: <81d3ssva6v.fsf@gmail.com>
> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1.91 (windows-nt)
> --text follows this line--
>
> jambu> How about providing user-accessible tapping points within
> jambu> 'org-babel-map-src-blocks' (or a variation thereof) that would
> jambu> enable me have a custom command in my .emacs.
> jambu>
> jambu> For the sake of record, my suggestion is very closely related to
> jambu> what is discussed here.
> jambu>
> jambu> http://eschulte.github.com/babel-dev/PROPOSED-tangle-entire-org-mode-file-in-comments.html
>
> Eric> I've just pushed up an implementation of the functionality
> Eric> described at the link above, see [1] for examples and details.
> Eric>
> Eric> Is this sufficient to satisfy the need you were addressing?  If
> Eric> not how could it be improved?
>
> Eric> Footnotes: 
> Eric> [1]  http://eschulte.github.com/babel-dev/DONE-tangle-entire-org-mode-file-in-comments.html
>
> I am making a request for an API from BABEL core which roughly parallels
> org's org-map-entries.
>
> Using this API a user should be able to 'traverse' babel and non-babel
> blocks within a given scope (region, buffer), examine the local state
> (say a tag or a user-defined property on a subtree), provide a verdict
> on it's inclusion (yes I want it, no skip it) or possibly return a
> transformed custom content (as a list).
>
> 'org-babel-map-src-blocks' has the skeletal structure for this API. All
> it needs is some minimal tinkering to take on a more user-pluggable
> form.
>
> The proposed API would make UseCase-1 and UseCase-2 possible.
>
> UseCase-1: 
> http://article.gmane.org/gmane.emacs.orgmode/28823
>
> Section-6 provides an illustration.
> Section-5 helps one visualize the essentials of the propsed API.
>
> a) org-to-org-src-view => potential consumer of the proposed API.
> b) beg-org, end-org, beg-babel, end-babel => strategic 'points' of
>    user-interest.
> c) body, body1 => Hooks for user
>
> UseCase-2: Tangling with custom pragmas.
> http://article.gmane.org/gmane.emacs.orgmode/29805
>
> Additional Note: Thinking out loud here (aka contrived, over-the-top
> requirement). 
>
> A user might want to override the in-buffer babel-control parameters
> while tangling or execution.
>
> Think of this scenario, I would like to tangle but with comments and
> line nos as a one-off (say for circulating to my colleagues). The
> in-buffer 'static/default' settings suppresses comments. I couldn't be
> bothered to edit the in-buffer settings just for this one-off case. Is
> there a possible way I can achieve this?
>
> Jambunathan K.

      parent reply	other threads:[~2010-09-05 21:17 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-07-20 12:10 [BABEL] Seemless editing of Babel Blocks Jambunathan K
2010-07-20 22:58 ` Eric Schulte
2010-08-16  8:38   ` Jambunathan K
2010-08-16  9:20     ` [BABEL] [PROPOSAL] " Jambunathan K
2010-09-02 23:41       ` Dan Davison
2010-09-02 23:50         ` Erik Iverson
2010-09-03 19:08         ` Tom Short
2010-09-03 20:45           ` Dan Davison
2010-09-04  8:58         ` Jambunathan K
2010-09-04 15:04           ` Eric Schulte
2010-09-05  9:55             ` Jambunathan K
2010-09-05 15:58               ` Dan Davison
2010-09-05 19:12                 ` Eric Schulte
2010-09-05 20:22               ` Eric Schulte [this message]

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=877hizlwk6.fsf@gmail.com \
    --to=schulte.eric@gmail.com \
    --cc=davison@stats.ox.ac.uk \
    --cc=emacs-orgmode@gnu.org \
    --cc=kjambunathan@gmail.com \
    /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).