[O] Babel, bash, :variables, and tangling
Hi List,
I'm having some trouble getting babel executed in Emacs and scripts that are
tangled to behave the same. I think I've distilled it down to an MWE. I'd like
to inject
#+NAME: table
| 1 | 2 |
| 3 | 4 |
into a bash workflow where I need each of those 4 items with their respective
row and column. That is, redefine the table so that it is:
| x | y | z |
| 0 | 0 | 1 |
| 0 | 1 | 2 |
| 1 | 0 | 3 |
| 1 | 1 | 4 |
I can do this in a babel block like this:
#+NAME: import
#+BEGIN_SRC sh :results output :tangle no :var table=table
rm -f tmpfile
lineno=0
echo "${table}" | while read line; do
colno=0
echo ${line} | tr ' ' '\n' | while read entry; do
echo $lineno "|" $colno "|" $entry >> tmpfile
colno=$(( $colno + 1 ))
done
lineno=$(( $lineno + 1 ))
done
echo ""
cat tmpfile
#+END_SRC
#+RESULTS: import
:
: 0 | 0 | 1
: 0 | 1 | 2
: 1 | 0 | 3
: 1 | 1 | 4
And I can call it with:
#+CALL: import(table=table)
And I get the results I want
But when I tangle it out, the tangled file defines "table" like this:
unset table
declare -A table
table['1']='2'
table['3']='4'
And then the algorithm does not work.
Am I doing something incorrectly here with respect to executing babel blocks
inside Emacs v. tangling to external files? Any suggestions how to get similar
behavior inside emacs and outside emacs?
Thanks,
-k.
Re: [O] (no subject)
I'm replying a year late to this thread, post-merge, because I've discovered it breaks interaction with the highlight.js library( https://highlightjs.org/) and therefore my workflow, which depends on highlightjs via reveal.js. My difficulty is with the current version of ~org-html-do-format-code~, which currently surrounds each loc with a ~~ tag and potentially some classes: (format "%s" (if num-start (format " data-ox-html-linenr=\"%s\"" line-num) "") loc) On Mon, Oct 15, 2018 at 4:07 AM Nik Clayton wrote: > Hi, > > I'd like to propose a couple of changes / enhancements to how org-export > exports some data in to HTML files to make it slightly easier to style > those files. > > The first is re line-numbers. > > At the moment those get exported as content in the HTML, although they're > really additional metadata. Amongst other things, this means that if you > copy/paste from the output you get the line numbers included in the text > that's copied. > > CSS supports arbitrary counters that can be associated with content, > starting from an arbitrary value. My current hack that sort of works is the > following CSS: > . > and a change to org-html-do-format-code to wrap each line in its own > ... element: > > ... > ;; Transcoded src line. > (format "%s" loc) > ... > > a) Does that sound reasonable? > b) Should this replace the current approach, or be an option that can be > toggled by a customisation? > > I agree that thisseems to make sense for many applications. But highlight.js is a very widely-used highlighting library that expects exactly one ~~ tag inside a given ~~ block. The additional ~~ tags that org now generates on html export break highlight in ways I don't believe can easily be fixed. I wonder if we could revisit the idea of adding a user option that would allow this feature to be switched off? If this would be of general use I can prepare a patch. Thanks, Matt
Re: [O] org-icalendar: Change dates to today in VEVENT export
Hi there, On Thu, 5 Sep 2019 at 11:53, Nicolas Goaziou wrote: > Michaël Cadilhac writes: > > +(defun org-icalendar-today-timestamp () > > + "Return a TIMESTAMP object for today, at 00:00." > > + (let ((dt (decode-time))) > > +(list 'timestamp > > + (nconc (list :year-start (nth 5 dt) > > +:year-end (nth 5 dt) > > +:month-start (nth 4 dt) > > +:month-end (nth 4 dt) > > +:day-start (nth 3 dt) > > +:day-end (nth 3 dt)) > > This function already exists: `org-timestamp-from-time'. Could you use > that instead? Right, you pointed this out the first time, and I forgot to address this: How would you build such a timestamp *with the -end bits* using org-timestamp-from-time? It seems that org-icalendar-convert-timestamp expects that these be filled. Thanks, M.
Re: [O] org-drill extremely slow with Org 9.2.5
Hi, are all your headlines folded? I found that running "M-x outline-show-all" before the first org- drill call resolves this issue for me with org 9.2 (but not with 9.3). See also my analysis https://bitbucket.org/eeeickythump/org-drill/issues/48/slow-startup Are you aware of the new org-drill releases by Philipp Lord? https://gitlab.com/phillord/org-drill Cheers Christian On Sun, 2019-08-25 at 20:10 +0200, Milan Zamazal wrote: > Hi, after upgrading from Org 9.1 to 9.2, org-drill has become extremely > slow. org-drill has never been fast, but now it stops being usable. > Everything takes much more time than before -- running `M-x org-drill', > both for the first time and again, responding to drill queries, moving > over my Org file. > > My org-drill Org file has over 4,000 entries and almost 50,000 lines. > With Org 9.1, it used to be usable after running `M-x org-drill' for the > first time in the given Emacs session; after the initial Org processing, > I could move over the entries relatively smoothly. But this no longer > helps and org-drill itself is much slower too. > > Is Org 9.2 no longer capable to handle (relatively) large files with a > lot of Org properties? Are there any tricks to speed it up? > > Thanks for any advice, > Milan > > signature.asc Description: This is a digitally signed message part
