Re: custom function for org-babel src block export

[David Bremner]

David Bremner  writes:

> Ihor Radchenko  writes:
>
>> David Bremner  writes:
>>
>>> I am generating slides using org-beamer. I would like certain code
>>> blocks to export as links containing URL-encoded content of the
>>> block.
>>
>> Check out https://orgmode.org/manual/Advanced-Export-Configuration.html
>> You may use export filter or extend ox-beamer backend, creating a new
>> custom backend that will export your code blocks as desired.
>>
>
> Thanks for the suggestion(s).
>
> I tried defining org-export-filter-src-block-functions (see end)
> but I encountered two issues
>

My "good enough for now" solution is to use a second emacs-lisp code
block as below.  This requires a bit of care to keep the link in sync
with the exported code, but is otherwise workable.

#+name: smol-test
#+begin_src smol
  (deffun (f x) (+ x 1))
#+end_src

#+begin_src emacs-lisp :eval true :exports results :noweb yes :results value 
latex
  (db-stacker-link "<>")
#+end_src
#+results:
#+begin_export latex
\href{https://www.example.com/stacker/?program=%28deffun%20%28f%20x%29%20%28+%20x%201%29%29}{execute
 on stacker}
#+end_export

Re: custom function for org-babel src block export

[David Bremner]

Ihor Radchenko  writes:

> David Bremner  writes:
>
>> I am generating slides using org-beamer. I would like certain code
>> blocks to export as links containing URL-encoded content of the
>> block.
>
> Check out https://orgmode.org/manual/Advanced-Export-Configuration.html
> You may use export filter or extend ox-beamer backend, creating a new
> custom backend that will export your code blocks as desired.
>

Thanks for the suggestion(s).

I tried defining org-export-filter-src-block-functions (see end)
but I encountered two issues

1) The text already includes the latex environment (in my case
listings). This is solvable, but did make me wonder if I was using the
right filter.

2) I could not figure out how to cleanly access the source language
   (e.g. "stacker" in my example). It didn't seem to be in "info".  I
   guess I can recover it from the text using e.g. regex, but this seems 
fragile, since
   it would break when switching backends.

;;

(defun db-ox-src-filter (text backend info)
  (when (org-export-derived-backend-p backend 'latex)
(db-stacker-link text)))

(add-to-list 'org-export-filter-src-block-functions
 #'db-ox-src-filter)

Re: custom function for org-babel src block export

[Ihor Radchenko]

David Bremner  writes:

> I am generating slides using org-beamer. I would like certain code
> blocks to export as links containing URL-encoded content of the
> block.

Check out https://orgmode.org/manual/Advanced-Export-Configuration.html
You may use export filter or extend ox-beamer backend, creating a new
custom backend that will export your code blocks as desired.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

custom function for org-babel src block export

[David Bremner]

I am generating slides using org-beamer. I would like certain code
blocks to export as links containing URL-encoded content of the
block. As an example I would like the following block 

#+begin_src stacker 
(defvar x 1)
(deffun (f)
  (defvar y 2)
  (deffun (h)
(+ x y))
  (h))
(f)
#+end_src

would be exported as something like

\href{https://www.example.com/stacker/?program=%28defvar%20x%201%29%0A%28deffun%20%28f%29%0A%20%20%28defvar%20y%202%29%0A%20%20%28deffun%20%28h%29%0A%20%20%20%20%28+%20x%20y%29%29%0A%20%20%28h%29%29%0A%28f%29}{execute
 on stacker}

I can do the encoding easily enough (see end), but I did not see a way
of hooking that up to org-babel, while retaining the ability to also use
minted or listings for other blocks.

I need the ability to use noweb expansion, so using a custom block type
seems unattractive (at least at first glance).

;;
(defvar stacker-base
"\href{https://www.example.com/stacker/?program=%}{execute on stacker}")


(defun db-stacker-link (prog)
  (format stacker-base 
  (org-link-encode prog '(?? ?  ?( ?) ?\n

Re: Documentation of hline symbol in source blocks results

[Ihor Radchenko]

Tim Landscheidt  writes:

> this is just a data point for anyone looking at restructur-
> ing the Org documentation.
>
> I wanted an Emacs Lisp source block to produce a table with
> a column name and a horizontal line separating the column
> name and the data cells.  The data-only source block:
> ...
> I wanted to get the result:
>
> | #+RESULTS:
> | | Number |
> | ||
> | |  1 |
> | |  2 |
> | |  3 |
>
> It took me quite a while to figure out that the first row
> returned from the source block can be viewed as the column
> name, and a horizontal line can be achieved by returning the
> symbol 'hline:

AFAIK, producing tables with column names in
emacs-lisp code blocks is not officially supported.
The `hline' is not documented.

> The only reference to this behaviour I could find, is liter-
> ally the last (!, :-)) paragraph in the info file:
>
> |For complicated translations the generic translator function could be
> | replaced by a custom translator function.  Such a custom function must
> | take two arguments and return a single string containing the formatted
> | table.  The first argument is the table whose lines are a list of fields
> ^^
> | or the symbol ‘hline’.

This happens to be the machinery Org babel uses to convert tables from
Elisp format to Org mode format. We do not give you any guarantee that
we are going to keep using `orgtbl-to-generic' in future the same way.

> Just for further inspiration how the documentation could be
> rewritten, consider the current wording of "Results of Eval-
> uation/Collection/value":
>
> |  Default for most Babel libraries(1).  Functional mode.  Org gets
> |  the value by wrapping the code in a function definition in the
> |  language of the source block.  That is why when using ‘:results
> |  value’, code should execute like a function and return a value.
> |  For languages like Python, an explicit ‘return’ statement is
> |  mandatory when using ‘:results value’.  Result is the value
> |  returned by the last statement in the code block.
>
> |  When evaluating the code block in a session (see *note Environment
> |  of a Code Block::), Org passes the code to an interpreter running
> |  as an interactive Emacs inferior process.  Org gets the value from
> |  the source code interpreter’s last statement output.  Org has to
> |  use language-specific methods to obtain the value.  For example,
> |  from the variable ‘_’ in Ruby, and the value of ‘.Last.value’ in R.
>
> Wrapping the code?  "Code /should/"?  "Like a function"?
> Why is the Python requirement stated here?

I am sorry, but I do not fully understand the problem.
What we are saying is that the code block should return a value.
And give an example that python blocks, in order to return a value,
should have `return' statement.

> ... Why "using
> ‘:results value’" when the paragraph should (only) document
> this?

Emm.. But we are documenting :results value is this paragraph.
Mentioning it again is a bit redundant, but not the end of the world.
Improvements welcome, of course.

> ... "Result is the value"?  What kind of value?  Why are
> there references to Ruby and R here?  All this confuses me
> and does not provide the information I searched for (empha-
> sis on me).

 Ruby and R have their own syntax to return value, just like "return" in
 python.
 
I hope it is clear now for you.

> I would probably prefer a clean-slate approach that starts
> with something along the lines of: "Source blocks produce
> results that can be integrated into an Org document and used
> as input for other source blocks.  The abstract specifica-
> tion for source blocks looks like this ("structured table
> data" vs. "text dump", header arguments, export, etc.).
> Emacs Lisp source blocks produce these values in this way.
> Python that way.  Shell scripts return tables in this way."
>
> Org is extremely powerful, but (I think I wrote it somewhere
> before) the documentation reads like users having had an is-
> sue ("my Python code does not produce (correct) results")
> and then someone feeling the need to document the solution
> right then and there.  IMNSHO this leads to documentation
> that is not very usable for the general audience.

AFAIK, the particular paragraph you pointed out does not mention Python
just to address someone issue. Python/R/Ruby are just examples used.

Though I do agree that this (and many other) sections of the manual can
be improved. Patches welcome!

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

Documentation of hline symbol in source blocks results

[Tim Landscheidt]

Hi,

this is just a data point for anyone looking at restructur-
ing the Org documentation.

I wanted an Emacs Lisp source block to produce a table with
a column name and a horizontal line separating the column
name and the data cells.  The data-only source block:

| #+BEGIN_SRC emacs-lisp
|   '((1)
| (2)
| (3))
| #+END_SRC

produces the result:

| #+RESULTS:
| | 1 |
| | 2 |
| | 3 |

I wanted to get the result:

| #+RESULTS:
| | Number |
| ||
| |  1 |
| |  2 |
| |  3 |

It took me quite a while to figure out that the first row
returned from the source block can be viewed as the column
name, and a horizontal line can be achieved by returning the
symbol 'hline:

| #+BEGIN_SRC emacs-lisp
|   '(("Number")
| hline
| (1)
| (2)
| (3))
| #+END_SRC

The only reference to this behaviour I could find, is liter-
ally the last (!, :-)) paragraph in the info file:

|For complicated translations the generic translator function could be
| replaced by a custom translator function.  Such a custom function must
| take two arguments and return a single string containing the formatted
| table.  The first argument is the table whose lines are a list of fields
^^
| or the symbol ‘hline’.  The second argument is the property list
  ^
| consisting of parameters specified in the ‘#+ORGTBL: SEND’ line.  Please
| share your translator functions by posting them to the Org users mailing
| list, at .

Just for further inspiration how the documentation could be
rewritten, consider the current wording of "Results of Eval-
uation/Collection/value":

|  Default for most Babel libraries(1).  Functional mode.  Org gets
|  the value by wrapping the code in a function definition in the
|  language of the source block.  That is why when using ‘:results
|  value’, code should execute like a function and return a value.
|  For languages like Python, an explicit ‘return’ statement is
|  mandatory when using ‘:results value’.  Result is the value
|  returned by the last statement in the code block.

|  When evaluating the code block in a session (see *note Environment
|  of a Code Block::), Org passes the code to an interpreter running
|  as an interactive Emacs inferior process.  Org gets the value from
|  the source code interpreter’s last statement output.  Org has to
|  use language-specific methods to obtain the value.  For example,
|  from the variable ‘_’ in Ruby, and the value of ‘.Last.value’ in R.

Wrapping the code?  "Code /should/"?  "Like a function"?
Why is the Python requirement stated here?  Why "using
‘:results value’" when the paragraph should (only) document
this?  "Result is the value"?  What kind of value?  Why are
there references to Ruby and R here?  All this confuses me
and does not provide the information I searched for (empha-
sis on me).

I would probably prefer a clean-slate approach that starts
with something along the lines of: "Source blocks produce
results that can be integrated into an Org document and used
as input for other source blocks.  The abstract specifica-
tion for source blocks looks like this ("structured table
data" vs. "text dump", header arguments, export, etc.).
Emacs Lisp source blocks produce these values in this way.
Python that way.  Shell scripts return tables in this way."

Org is extremely powerful, but (I think I wrote it somewhere
before) the documentation reads like users having had an is-
sue ("my Python code does not produce (correct) results")
and then someone feeling the need to document the solution
right then and there.  IMNSHO this leads to documentation
that is not very usable for the general audience.

Tim

Re: How can I use org-add-note with emacsclient?

[Ihor Radchenko]

equal.moon0...@fastmail.com writes:

> I'm trying to figure out how to start a note (C-c C-z) on the currently 
> clocked task from emacsclient. Here's what I have so far:
> ...
> emacsclient -s test -nw --eval '(progn (org-clock-goto) (org-add-note))'
>
> This seems to have no effect. Oddly, if I paste this into M-:, it works fine. 
> I've tried a number of things with e.g. plain capture templates that run the 
> above code :after-finalize, using call-interactively, etc. After a cursory 
> reading through the info manual on interactivity I find I'm still a bit lost. 
> Can anyone explain what I'm doing wrong and hopefully point me to the right 
> manual page to read on this?

`org-add-note' is implemented a bit awkwardly using post-command-hook,
which makes it work only interactively.
The hook does not trigger when you use --eval. That's why you are not
seeing the note buffer after running the above shell command.

What you can do is manually call the function used to raise the note
buffer:

emacsclient -nw --eval '(progn (org-clock-goto) (org-add-note) 
(org-add-log-note))'

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

Re: Provide org-insert-subitem

[Ihor Radchenko]

Bastien  writes:

>> 1. For org-insert-heading, we have multiple variants that allow
>>inserting heading at point, after current subtree, and the same
>>variants for TODO heading. We don't have enough key combinations left
>>to allow all the equivalents for subheadings.
>>
>> 2. With `org-cycle-level-after-item/entry-creation' set to t (default),
>>it is actually very easy to create a subheading/subitem using the
>>available C/M-[S]- commands. Just do M- . And the same
>>will work for inserting todo headings.
>
> I'm not sure I follow the reasoning here: do you say that we don't
> need to find a keybinding for `org-insert-subheading/subitem' because
> it is already easy enough to insert a subheading/item using a certain
> combinaison of commands?

> Or do you suggest we need to find another prefix than "C-M-"? Which
> one?

I mean that it seems to be easy to insert subheading/subitem already.

You can try:

* Heading
M-RET TAB

or

* Heading
C-S-RET TAB

or

- item
M-RET TAB

We even have this documented in the Structural Editing section of the
manual:

‘’ (‘org-cycle’)
 In a new entry with no text yet, the first ‘’ demotes the
 entry to become a child of the previous one.  The next ‘’
 makes it a parent, and so on, all the way to top level.  Yet
 another ‘’, and you are back to the initial level.

Probably, we should mention "subitem/subheading" words in the index or
find some other way to emphasize that it is possible to demote
subheading with TAB.

> What matter the most to me here is the consistency of commands, but if
> the keybindings can reflect that, all the better.

For me, it is important to keep consistency of the keys as well - these
are the core Org keys, and they should be as intuitive as possible.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

Re: Provide org-insert-subitem

[Bastien]

Hi Adam,

Adam Porter  writes:

> The "C-M-RET" binding doesn't feel quite right to me.  Using "shift"
> feels like a mnemonic for "sub", whereas "C-M" seems like it should do
> something much less frequently used, since it requires two
> modifiers.

I agree that S- suggests "sub".

I've been playing around with C-RET, M-RET, S-RET and I do believe
there is room for improvement here, along with a dedicated keybinding
for `org-insert-subheading/subitem'.  I will refine my proposal later
on.

> Ihor also made some good points in his message about the combinations
> of commands to insert before/after, with/without TODO, etc, and that
> "M- " is already a quick way to insert a subheading (I
> wasn't aware of the option
> `org-cycle-level-after-item/entry-creation').  So maybe this idea of
> mine isn't as important as I thought.  :)

Even if we end up not binding a new key for `org-insert-subheading',
it will be good to add org-clone-item and org-insert-subitem and
perhaps to improve bindings in this area. I will think again about
this.

Thanks!

-- 
 Bastien

Re: Provide org-insert-subitem

[Bastien]

Ihor Radchenko  writes:

>> S-RET already "copy down" a table cells, so I'm really suggesting a
>> generalization of the current keybinding.
>
> This makes sense.
>
>> - S-RET on a list item calls `org-insert-subitem`, a new command.
>
> Did you mean `org-clone-item'?

Yes, sorry (`org-clone-item' is better than `org-item-copy-down', the
other idea that comes naturally.)

>> - C-M-RET on a heading calls `org-insert-subheading', the existing
>>   command.
>>
>> - C-M-RET on a list item calls `org-insert-subitem', a new command.
>>
>> I like C-M-RET better than S-RET because inserting a subheading is
>> like a "subkey" or inserting a heading.
>
> I tried to play around a bit with various flavours of X- commands
> and I am not sure if I like C-M-RET:
>
> 1. For org-insert-heading, we have multiple variants that allow
>inserting heading at point, after current subtree, and the same
>variants for TODO heading. We don't have enough key combinations left
>to allow all the equivalents for subheadings.
>
> 2. With `org-cycle-level-after-item/entry-creation' set to t (default),
>it is actually very easy to create a subheading/subitem using the
>available C/M-[S]- commands. Just do M- . And the same
>will work for inserting todo headings.

I'm not sure I follow the reasoning here: do you say that we don't
need to find a keybinding for `org-insert-subheading/subitem' because
it is already easy enough to insert a subheading/item using a certain
combinaison of commands?

Or do you suggest we need to find another prefix than "C-M-"? Which
one?

What matter the most to me here is the consistency of commands, but if
the keybindings can reflect that, all the better.

-- 
 Bastien

Re: [PATCH] Justify/align image previews in org-mode

[Bastien Guerry]

Ihor Radchenko  writes:

>> From eb1b287c009c2f7eb83e7e31d64980ba79f44527 Mon Sep 17 00:00:00 2001
>> From: Karthik Chikmagalur 
>> Date: Mon, 18 Dec 2023 12:56:33 -0800
>> Subject: [PATCH] org: Add image alignment
>
> Bastien, may you please confirm that Karthik's FSF assignment is in
> order?

Yes it is, since 2021.  Thanks for contributing!

-- 
 Bastien Guerry