[Orgmode] Re: [BABEL][PROPOSAL] headlines as executable srcnames
Eric
Hi Jambunathan,
So, if I'm understanding correctly, what you are proposing includes two
separate things, first, a new link-style syntax for calling code blocks,
and second, the ability to provide un-named arguments to code blocks.
I'm less sure about expanding link syntax into a means of calling code
blocks. There has been some recent discussion on the list about
expanding link syntax (in fact related to the thread your referenced
below) and my impression was that there is far from unanimous support
for changing the semantics of links in Org-mode. Maybe this would be
appropriate as an optional extension to org, i.e. something in the
contrib directory.
I think I am converging towards having a new 'babel: ' URL scheme.
Requests like colorization, inserting version control information etc on
export rightfully falls under one-off request and a babel: URL scheme
would help achieve all these without any hassles.
In 'babel: ' URLs, the 'path' param is likely to contain a call-site
(srcname) and key,val pairs (for named params). I think one can use or
draw inspiration from standard http URL encoders that posts HTML forms.
My ideas are not fully formed and I refine as I go along... Please be
tolerant.
Jambunathan K.
,
| *Article* #(From: Vinh Nguyen vinhdi...@gmail.com
| Subject: Re: text color + highlight
| Newsgroups: gmane.emacs.orgmode
| To: emacs-orgmode@gnu.org
| Date: Thu, 9 Sep 2010 09:15:05 -0700
| Message-ID: aanlktinr_zorpygjpkskyuo6pt1t3-ztotho32fnh...@mail.gmail.com
| Archived-At: http://permalink.gmane.org/gmane.emacs.orgmode/30143
|
| I'd like to write a concluding email for this thread for future
| searchers to find. This easy solution is brought to you by Eric
| Schulte and Christian Moe.
|
| Place the following in your .emacs or init.el file:
| ;; org-mode color
| (org-add-link-type
| \color\ nil
| (lambda (path desc format)p
| (cond
|((eq format 'html)
| (format \span style=\\\color:%s;\\\%s/span\ path desc))
|((eq format 'latex)
| (format \{color{%s}%s}\ path desc)
| ;; org-mode highlight
| (org-add-link-type
| \hl\ nil
| (lambda (path desc format)
| (cond
|((eq format 'html)
| (format \font style=\\\background-color:%s;\\\%s/font\ path
desc))
|((eq format 'latex)
| (format \colorbox{%s}{%s}\ path desc) ;; require
\\usepackage{color}
|
| Examples:
| [[color:blue][test this out]]
| [[hl:yellow][highlighted text]]
|
`
___
Emacs-orgmode mailing list
Please use `Reply All' to send replies to the list.
Emacs-orgmode@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-orgmode
[Orgmode] Re: [BABEL][PROPOSAL] headlines as executable srcnames
Hi Jambunathan,
So, if I'm understanding correctly, what you are proposing includes two
separate things, first, a new link-style syntax for calling code blocks,
and second, the ability to provide un-named arguments to code blocks.
I definitely agree that the second suggestion would be desirable. Even
if we still use named arguments when writing code blocks it should be
possible to supply un-named arguments when calling code blocks, and use
the order of the arguments to resolve their variable mappings. This has
been on our TODO list for some time and is just waiting for some
development time.
I'm less sure about expanding link syntax into a means of calling code
blocks. There has been some recent discussion on the list about
expanding link syntax (in fact related to the thread your referenced
below) and my impression was that there is far from unanimous support
for changing the semantics of links in Org-mode. Maybe this would be
appropriate as an optional extension to org, i.e. something in the
contrib directory.
Thanks -- Eric
Jambunathan K kjambunat...@gmail.com writes:
I am slightly drifting a bit. I think the broader theme that is emerging
in this thread is this - how Babel as a Org's VM would enable one to
create useful text mashups. Call it Org 2.0 if you may like.
Needless, to say I am having a hammer and everything looks nail to
me. Please be patient with my regurgitations! Read on ...
,
| *Article* #(From: Vinh Nguyen vinhdi...@gmail.com
| Subject: Re: text color + highlight
| Newsgroups: gmane.emacs.orgmode
| To: emacs-orgmode@gnu.org
| Date: Thu, 9 Sep 2010 09:15:05 -0700
| Message-ID: aanlktinr_zorpygjpkskyuo6pt1t3-ztotho32fnh...@mail.gmail.com
| Archived-At: http://permalink.gmane.org/gmane.emacs.orgmode/30143
|
| I'd like to write a concluding email for this thread for future
| searchers to find. This easy solution is brought to you by Eric
| Schulte and Christian Moe.
|
| Place the following in your .emacs or init.el file:
| ;; org-mode color
| (org-add-link-type
| \color\ nil
| (lambda (path desc format)p
| (cond
|((eq format 'html)
| (format \span style=\\\color:%s;\\\%s/span\ path desc))
|((eq format 'latex)
| (format \{color{%s}%s}\ path desc)
| ;; org-mode highlight
| (org-add-link-type
| \hl\ nil
| (lambda (path desc format)
| (cond
|((eq format 'html)
| (format \font style=\\\background-color:%s;\\\%s/font\ path
desc))
|((eq format 'latex)
| (format \colorbox{%s}{%s}\ path desc) ;; require
\\usepackage{color}
|
| Examples:
| [[color:blue][test this out]]
| [[hl:yellow][highlighted text]]
|
| Remarks:
| * Pros
| - don't need to modify org-mode source (just edit your .emacs)
| - use the existing links syntax
| * Cons
| - cannot be used concurrently or with other formatting
| * To Do
| - Hopefully it will be implemented via extensible syntax in the
| future ($[options mytext])
| - highlight and color paragraph or region
|
|
| -- Vinh
|
|
|
| On Thu, Aug 5, 2010 at 1:42 PM, Vinh Nguyen vinhdi...@gmail.com wrote:
| Dear list,
|
| I was wondering if there is an easy way to markup the color of the
| text for html output (and highlight as well). When I prepare meeting
| minutes I'd like to color some things and highlight certain things.
| Right now, I am using emphasizing a major portion of the text. It
| would be great to have colors and highlights to draw attention to
| certain items.
|
| Thanks.
| Vinh
`
I wonder whether there is a way to achieve the requested feature without
too much of elisp programming.
[[color:blue][test this out]]
^ ^ ^
If one imagines this as a macro call
color = babel srcname [accessible through %0 in srcbody]
blue = param1 for srcname [accessible through %1 in srcbody]
test this out = text param for the macro ['this' param for text mashup]
In my earlier post, I tried to argue that if headlines could be srcnames
then the text content of the headline could be considered as an implicit
'this' param (which the 'headline macro' works upon)
Now if link syntax could be used as a macro call (as seen above) then
the description part of the link i.e., text contained within inner []
could be considered as the 'this' param for link-oriented
srcnames. (Think of links as mini, inline headlines and desc as headline
body)
It is important to note that the user still works with text documents
which are very much like existing org documents.
Note also that having positional params and having them canonically
accessible as %0, %1, %2 etc could have it's uses [1]. It is left to the
reader how color macro could be defined with above redefinitions.
Let me reiterate (and I think it is important) Babel's macro expansion
if tweaked and designed for 'text mashups and massages' then much of
user requirements (like the one above) could be implemented by the
[Orgmode] Re: [BABEL][PROPOSAL] headlines as executable srcnames
Jambunathan K kjambunat...@gmail.com writes: [...] If headlines are considered as code blocks one actually inflate headlines and execute them for interesting side-effects. Rather than create new syntax allowing headlines to be interpreted as Org-mode code blocks, we could implement this ability of finding and extending headlines into a code block through the library of babel. This would allow headlines to be expanded easily and concisely from inside of other code blocks without having to make any changes or extensions to Babel. So for example #+source: headline #+begin_src emacs-lisp :var headline=top :results org (org-open-link-from-string (org-make-link-string headline)) (save-restriction (org-narrow-to-subtree) (buffer-string)) #+end_src could then be called from inside of a code block to insert the body of a headline in the same file, e.g. #+begin_src org headline(headline=body) #+end_src This should be useful for easily including large portions of org-mode files into code blocks for generating letters. If this looks good, I'll add it to the library of babel so it's universally available. Best -- Eric ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
[Orgmode] Re: [BABEL][PROPOSAL] headlines as executable srcnames
Jambu I think there is a strong case for making headlines act as babel
Jambu srcnames with their body providing content for noweb expansion
Jambu [3]. This behaviour could be controlled by a buffer local
Jambu variable.
I have some more thoughts on this. Let me capture it before it goes
away. My thoughts are fragmented and my only request is that it be noted
and embraced and extended when you hash out the final details.
I think value of Babel could be tremendously enhanced if '#+results ...'
are revisited and redefined.
So that not I sound too abstract, let us take an example.
Remember the recent thread [1] where there was a request to
automagically 'embed' the revision number of a document in an orgmode
file? This is what emerged as a solution that the original poster was
happy with.
,
| * revision control
| The version of this file is
|src_emacs-lisp{(vc-working-revision (or (buffer-file-name) org-current-:
export-file))}.
`
IMHO, I believe there is an opportunity for improvement. What if the
actual solution ended up like the following ...
* Revision
#+begin_src emacs-lisp
(vc-working-revision (or (buffer-file-name) org-current-export-file))
#+end_src
# Variant-1:
* revision control
Version of the file is Revision()
# Variant-2:
Or better still something like this
* revision control
Version of the file [[Revision()][Rev-1]]
Following items are worthy of note:
1. The body of the headline is provided by executing the blocks
undeneath it.
Worth comparing this with the idea that emerged in the original post
- where the content of the headline is provided by the user (for
example a pdf link or body of a letter) and the results of the
execution is one that obtained by piping the results through a custom
exporter (latex)
2. In both cases there is no notion of a '#+results ' being created.
3. In Variant-2, the org's notion of what a link is redefined (Remember
extensible link syntax proposed by Samuel Wales).
Let's look at how the link is defined in the example
[[Revision()][Rev-1]]
The url portion of the link is actually a 'babel macro call' and
provides the content. Note how the macro call is embedded in the url
portion and there by hidden from human eye and Rev-1 provides a
placeholder. The special link face (or may be a 'babel macro face')
would let the user know that there are more things lurking
underground.
Time to get abstract ...
As I see it, removing 'extra levels of indirection' as the 'results of
source block' travel through org document more the Babel workflow would
seemlessly integrate with org's world view.
In some sense Babel would be more successful if it does it's offices
under the hood and not really make it's presence felt to the person
editing the document :-).
Footnotes:
[1] http://thread.gmane.org/gmane.emacs.orgmode/29690/focus=29792 [2]
Jambunthan K.
___
Emacs-orgmode mailing list
Please use `Reply All' to send replies to the list.
Emacs-orgmode@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-orgmode
[Orgmode] Re: [BABEL][PROPOSAL] headlines as executable srcnames
In the context of 'expanding babel macros', I think it would be useful to think of the context in which the babel macros are expanded. For example, if the macro is expanded with 'point' at the point of macro call then one would be able to pull in information from the current subtree (like property, tags etc etc) I was looking at this post - http://www.mail-archive.com/emacs-orgmode@gnu.org/msg29961.html and reference to the existing #+MACRO facility within orgmode and the need for accessing properties etc triggered this post. Hope I could be of some help even if my thougts are a bit fragmented and in the clouds ... Jambunathan K. ps: In the version control example down below the only context is filename and it doesn't matter where the 'point' is when the macro is expanded. * Revision #+begin_src emacs-lisp (vc-working-revision (or (buffer-file-name) org-current-export-file)) #+end_src # Variant-1: * revision control Version of the file is Revision() # Variant-2: Or better still something like this * revision control Version of the file [[Revision()][Rev-1]] Following items are worthy of note: 1. The body of the headline is provided by executing the blocks undeneath it. Worth comparing this with the idea that emerged in the original post - where the content of the headline is provided by the user (for example a pdf link or body of a letter) and the results of the execution is one that obtained by piping the results through a custom exporter (latex) 2. In both cases there is no notion of a '#+results ' being created. 3. In Variant-2, the org's notion of what a link is redefined (Remember extensible link syntax proposed by Samuel Wales). Let's look at how the link is defined in the example [[Revision()][Rev-1]] The url portion of the link is actually a 'babel macro call' and provides the content. Note how the macro call is embedded in the url portion and there by hidden from human eye and Rev-1 provides a placeholder. The special link face (or may be a 'babel macro face') would let the user know that there are more things lurking underground. ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
[Orgmode] Re: [BABEL][PROPOSAL] headlines as executable srcnames
I am slightly drifting a bit. I think the broader theme that is emerging
in this thread is this - how Babel as a Org's VM would enable one to
create useful text mashups. Call it Org 2.0 if you may like.
Needless, to say I am having a hammer and everything looks nail to
me. Please be patient with my regurgitations! Read on ...
,
| *Article* #(From: Vinh Nguyen vinhdi...@gmail.com
| Subject: Re: text color + highlight
| Newsgroups: gmane.emacs.orgmode
| To: emacs-orgmode@gnu.org
| Date: Thu, 9 Sep 2010 09:15:05 -0700
| Message-ID: aanlktinr_zorpygjpkskyuo6pt1t3-ztotho32fnh...@mail.gmail.com
| Archived-At: http://permalink.gmane.org/gmane.emacs.orgmode/30143
|
| I'd like to write a concluding email for this thread for future
| searchers to find. This easy solution is brought to you by Eric
| Schulte and Christian Moe.
|
| Place the following in your .emacs or init.el file:
| ;; org-mode color
| (org-add-link-type
| \color\ nil
| (lambda (path desc format)p
| (cond
|((eq format 'html)
| (format \span style=\\\color:%s;\\\%s/span\ path desc))
|((eq format 'latex)
| (format \{color{%s}%s}\ path desc)
| ;; org-mode highlight
| (org-add-link-type
| \hl\ nil
| (lambda (path desc format)
| (cond
|((eq format 'html)
| (format \font style=\\\background-color:%s;\\\%s/font\ path desc))
|((eq format 'latex)
| (format \colorbox{%s}{%s}\ path desc) ;; require
\\usepackage{color}
|
| Examples:
| [[color:blue][test this out]]
| [[hl:yellow][highlighted text]]
|
| Remarks:
| * Pros
| - don't need to modify org-mode source (just edit your .emacs)
| - use the existing links syntax
| * Cons
| - cannot be used concurrently or with other formatting
| * To Do
| - Hopefully it will be implemented via extensible syntax in the
| future ($[options mytext])
| - highlight and color paragraph or region
|
|
| -- Vinh
|
|
|
| On Thu, Aug 5, 2010 at 1:42 PM, Vinh Nguyen vinhdi...@gmail.com wrote:
| Dear list,
|
| I was wondering if there is an easy way to markup the color of the
| text for html output (and highlight as well). When I prepare meeting
| minutes I'd like to color some things and highlight certain things.
| Right now, I am using emphasizing a major portion of the text. It
| would be great to have colors and highlights to draw attention to
| certain items.
|
| Thanks.
| Vinh
`
I wonder whether there is a way to achieve the requested feature without
too much of elisp programming.
[[color:blue][test this out]]
^ ^ ^
If one imagines this as a macro call
color = babel srcname [accessible through %0 in srcbody]
blue = param1 for srcname [accessible through %1 in srcbody]
test this out = text param for the macro ['this' param for text mashup]
In my earlier post, I tried to argue that if headlines could be srcnames
then the text content of the headline could be considered as an implicit
'this' param (which the 'headline macro' works upon)
Now if link syntax could be used as a macro call (as seen above) then
the description part of the link i.e., text contained within inner []
could be considered as the 'this' param for link-oriented
srcnames. (Think of links as mini, inline headlines and desc as headline
body)
It is important to note that the user still works with text documents
which are very much like existing org documents.
Note also that having positional params and having them canonically
accessible as %0, %1, %2 etc could have it's uses [1]. It is left to the
reader how color macro could be defined with above redefinitions.
Let me reiterate (and I think it is important) Babel's macro expansion
if tweaked and designed for 'text mashups and massages' then much of
user requirements (like the one above) could be implemented by the user
himself without any help from expert elisp programmers.
Footnotes:
[1] I believe babel as of this writing only permits named param list.
Jambunathan K.
___
Emacs-orgmode mailing list
Please use `Reply All' to send replies to the list.
Emacs-orgmode@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-orgmode
[Orgmode] Re: [BABEL][PROPOSAL] headlines as executable srcnames
Hi Jambunathan, Jambunathan K wrote: Sébastien Vauban wxhgmqzgwmuf-genee64ty+gs+fvcfc7...@public.gmane.org writes: Jambunathan K wrote: [...] Any thoughts on how this could be achieved ... That's going (really) far... But would that be do-able, waaoow! Yes it is going far. Sometimes going far makes us feel elated while at other times it makes us feel down and out ;-). In the present case, the experience would be of the first kind. Otherwise would I dare suggest it? Don't misinterpret me. I said far, not too far! I really desire such possibilities as well... Simply, that's a huge integration, with great power. In other words, go on with this idea, and implement it, or convince the right people that can make this become real. I would provide an example and later summarize what the implications are. Thanks for the other info as well... Best regards, Seb -- Sébastien Vauban ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
