Re: [O] advice please: best way to export to DOC(X) with maths

[Adrian Bradd]

According to Karl's post [1], pandoc now supports conversion with some
template support. I haven't tried it myself though.

Cheers,

Adrian

[1] http://www.karl-voit.at/2017/12/17/pandoc-docx-reference/

Tim O'Callaghan  writes:

> Thanks!
> I will experiment with this work-flow, but i have one other issue, any
> advice on working with existing (word) document templates?
> I have to work within templates, so it would be great if i could manage to
> conform.
>
> On 19 December 2017 at 06:09,  wrote:
>
>> On 2017-12-15 12:28, Eric S Fraga wrote:
>>
>>> On Friday, 15 Dec 2017 at 03:20, ed...@openmail.cc wrote:
>>>
>>> [...]
>>>
>>> I only know how to do a rough approximation by means of pandoc:

 #+BEGIN_SRC bash
pandoc -f org+smart my-original.org -t docx+smart -o my-output.docx
 #+END_SRC

>>>
>>> What version of pandoc are you using?  My Debian (testing) has pandoc
>>> 1.19.2.4 and it does not seem to recognise the +smart bits...
>>>
>>> But, in any case, pandoc (without the smart bits) does seem to do a
>>> reasonable job and creates proper maths entities.  This is good enough
>>> for me!  My once a year pain is relieved.  :-)
>>>
>>> Thanks,
>>> eric
>>>
>>
>> I'm sorry for the very late response (deadlines). I will check for the
>> pandoc version and let you know. One of the distros that I use is a rolling
>> linux. The other one is the same as yours. I would also like to note that I
>> got the pandoc snippet from Dr. Kitchin's website:
>> http://kitchingroup.cheme.cmu.edu/blog/2015/01/29/Export-org
>> -mode-to-docx-with-citations-via-pandoc/
>>
>> I checked, and I am very satisfied with ~C-c C-e o o~. I set #+OPTIONS:
>> dvipng. You can't edit the formulas, but I don't care about that. All my
>> equations look fine and the pictures too. I also have to copy my references
>> by hand, but that is the least of my issues, and I only do it when the
>> final version is ready. I also get my source blocks right.
>>
>> I think that the only thing which is really missing from Org as related to
>> exporting is handling pictures inside tables (a way to create subfigures).
>> There is a partial solution with ox-latex-subfigure [[
>> https://github.com/linktohack/ox-latex-subfigure]], but is limited in the
>> :width parameter. One of these days I will learn LISP and implement it
>> myself (unless another brave soul goes for it first). Even Beamer columns
>> can be used to this end, but this would only work for presentations. I
>> don't know any other way.
>>
>>
>> -
>>
>> ONLY AT VFEmail! - Use our Metadata Mitigator to keep your email out of
>> the NSA's hands!
>> $24.95 ONETIME Lifetime accounts with Privacy Features!  15GB disk! No
>> bandwidth quotas!
>> Commercial and Bulk Mail Options!
>>


-- 
Adrian

Bioelectronic Systems Lab,
Columbia University

Re: [O] BUG: TODO statistics in parent heading prevent evaluation of TODOs with TRIGGER property

[Adrian Bradd]

Just wanted to bump this.

Let me know if there is a preferred/better way to attack this issue and
I can give it a shot.

Cheers,

Adrian

Adrian Bradd  writes:

> I should probably add that this will require org-depend.el to be loaded.
>
> On 10 December 2017 at 17:50, Adrian Bradd  wrote:
>
>> Hello,
>>
>> ECM:
>>
>> * Top-Heading with process indicator [/]
>>
>> ** TODO Here I invoke org-todo to DONE
>> :PROPERTIES:
>> :TRIGGER:  2021-12-03-target(TODO)
>> :END:
>>
>> ** This should be changed to TODO
>> :PROPERTIES:
>> :ID: 2021-12-03-target
>> :END:
>>
>> If you run org-todo on the "Here I invoke org-todo to DONE" headline the
>> headline will change to DONE, but the trigger will not update the "This
>> should be changed to TODO" headline. There is further discussion in another
>> thread where the user reported the issue [1].
>>
>> The issue is Line 12534 in org.el:
>>
>> (when org-provide-todo-statistics
>>   (org-update-parent-todo-statistics))
>>
>> which traverses the tree and updates the todo progress statistics. If the
>> statistic is [/], as in the ECM above, or [%] it will add 1 or more
>> characters which is enough to push the :position property up to the line
>> above. I wasn't sure how to deal with this as it seems
>> `org-update-parent-todo-statistics' could update more than one parent
>> heading and the number of additional characters isn't clear without some
>> feedback from `org-update-parent-todo-statistics'.
>>
>> Cheers,
>>
>> Adrian
>>
>> [1] https://lists.gnu.org/archive/html/emacs-orgmode/2017-12/msg00058.html
>>
>> On 10 December 2017 at 16:53, Nicolas Goaziou 
>> wrote:
>>
>>> Hello,
>>>
>>> Adrian Bradd  writes:
>>>
>>> > Please see the patch attached.
>>> >
>>> > When completing a TODO with a TRIGGER property that has statistics in
>>> the
>>> > parent headline the trigger would not evaluate because the :position
>>> > property in `change-plist' may now refer to the line above the original
>>> > TODO.
>>> >
>>> > I have used a marker to avoid the issue with the point moving due to the
>>> > addition of characters
>>> > ​ in the parent headline​
>>> > . Not sure if this is the best way to solve the problem.
>>>
>>> IIUC, point is moved between `startpos' and `change-plist' bindings? Do
>>> you know when that happens? Would you have an ECM for the issue?
>>>
>>> Thank you.
>>>
>>> Regards,
>>>
>>> --
>>> Nicolas Goaziou
>>>
>>
>>


-- 
Adrian

Bioelectronic Systems Lab,
Columbia University

Re: [O] Searching all attachments in org-files

[Ihor Radchenko]

Dear Narendra,

Here is what I am using:

(defun org-att-complete-link ( arg)
  "Completion dispatcher for att: links (rewritten from org-attach-open)"
  (let* ((attach-dir (org-attach-dir t))
 (files (org-attach-file-list attach-dir))
 (file (if (= (length files) 1)
   (car files)
 (completing-read "att: "
  (mapcar #'list files) nil t)))
 (path (expand-file-name file attach-dir)))
(concat "att:" file)))
(add-to-list 'org-link-abbrev-alist '("att" . org-attach-expand-link))
(org-link-set-parameters
 "att"
 :complete 'org-att-complete-link)

Regards,
Ihor


Narendra Joshi  writes:

> Hi,
>
> Is there a way to quick get a link to an existing attachment? A lot of
> times, I find myself referring to the same file. I like to keep files as
> attachments so that they are committed with my org-files. Any help here,
> either in fixing my workflow or helping me figure out how to get a link
> to an existing file that is attached to an org-heading, would be greatly
> appreciated.
>
> Thanks,
> -- 
> Narendra Joshi
>

-- 
Ihor Radchenko,
PhD Student
Singapore University of Technology and Design,
8 Somapah Road Singapore 487372
Email: yanta...@gmail.com, ihor_radche...@mymail.sutd.edu.sg
Tel: +6584017977


signature.asc
Description: PGP signature

Re: [O] Confusing org-cycle invocation when cursor is in invisible text

[Nicolas Goaziou]

Hello,

Ruy Exel  writes:

> Consider the following simple tree structure
>
> -
>
> * Trees
> ** Pine
> It is a conifer
> ** Oak
> Place cursor here ->
> It belongs to the genus Quercus
>
> -
>
> If you place the cursor where indicated (i.e. after the sentence
> "Place cursor here ->" above) and press  (org-shifttab),
> your buffer will show
>
> * Trees...
>
> with the cursor placed on the first of the three dots.  If you then go
> to the kitchen to prepare a coffee and come back, you will probably
> not going to remember where the cursor was before the visibility went
> to the OVERVIEW state.  Suppose you then decide to expand your tree by
> pressing  (org-cycle) without having changed cursor position.  In
> this case your buffer will turn to
>
> * Trees...
> ** Oak
> Place cursor here ->
> It belongs to the genus Quercus
>
> and you might then be led to thinking that your header "Trees" has
> only one sub-header, namely "Oak".  Yes I know that the three dots
> after "Trees" is meant to indicate that there is still some hidden
> text but, given that your intention was to expand "Trees" and that you
> pressed the correct key for this purpose you might (incorrectly) feel
> assured that you achieved the appropriate goal and hence not pay due
> attention to the three dots.
>
> The point I want to raise is that I believe users should not be
> required to remember the position of the cursor when it falls inside
> hiddent text.  Even more so, the state of the system at any given time
> should not depend on said position.
>
> Thus, after the first press of , above, the cursor should
> go by default to the beginning (maybe the end) of the hidden text.

I agree the current situation is not satisfactory, but I also think TAB
or S-TAB should never, ever, move point. For example, I use S-TAB to get
a quick overview of the structure of the document.

I fixed this by making TAB show more when called from an invisible part
of the buffer.

Thank you for the report.

Regards,

-- 
Nicolas Goaziou

Re: [O] Add contents-begin and contents-end to src-block in org-element.el

[Nicolas Goaziou]

"Somelauw ."  writes:


I suggest the following.

For contents begin:

(save-excursion
  (goto-char (org-element-property :post-affiliated element))
  (line-beginning-position 2))

For contents end:

(save-excursion
  (goto-char (org-element-property :end element))
  (skip-chars-backward " \t\n")
  (line-beginning-position))

Regards,

[O] Searching all attachments in org-files

[Narendra Joshi]

Hi,

Is there a way to quick get a link to an existing attachment? A lot of
times, I find myself referring to the same file. I like to keep files as
attachments so that they are committed with my org-files. Any help here,
either in fixing my workflow or helping me figure out how to get a link
to an existing file that is attached to an org-heading, would be greatly
appreciated.

Thanks,
-- 
Narendra Joshi

Re: [O] Add contents-begin and contents-end to src-block in org-element.el

[Somelauw .]

2017-12-25 9:49 GMT+01:00 Nicolas Goaziou 
> "Somelauw ."  writes:
>
>> By the way, do you know of any other org-elements that have an inner
>> body that doesn't classify as "data in Org syntax"?
>
> comment, comment blocks, example blocks, export blocks, fixed-width,
> keyword, latex-environment, node property.

Thanks I'll consider these

>
> These elements usually set :value property instead.

Thank you. What I need is the beginning and ending position of :value
so I can yank/kill/delete/select it (or create a text-object in Evil).
I think a general solution to find the inner body of these elements is
using (forward-search (org-get-property :value element)) and reading
match-data afterwards.

Merry Christmas,
Somelauw

Re: [O] babel header argument :var is not expanded when tangling

[numbch...@gmail.com]

I see. I will use noweb style for now.
But should tangle expand :var variables when tangling? I think this is the
correct behaviour.

[stardiviner] GPG key ID: 47C32433
IRC(freeenode): stardiviner Twitter:  @numbchild
Key fingerprint = 9BAA 92BC CDDD B9EF 3B36  CB99 B8C4 B8E5 47C3 2433
Blog: http://stardiviner.github.io/

On Sun, Dec 24, 2017 at 11:40 PM, Grant Rettke 
wrote:

> > Here is a quick test:
> >
> > * Test tangle will auto expand and substitute :var
> >
> > #+begin_src js :tangle kk.js
> > console.log("hello, world!");
> > #+end_src
> >
> > #+begin_src js :var name="chris" :tangle require-kk.js
> > // require("kk.js");
> > console.log("Hi, ", name);
> > #+end_src
> >
> > #+RESULTS:
> > : Hi,  chris
> >
> > #+NAME: check whether tangle expand and substitute :var
> > #+begin_src shell
> > cat require-kk.js
> > #+end_src
> >
> > #+RESULTS: check whether tangle expand and substitute :var
> > : var name="chris";
> > : console.log("Hi, ", name);
> >
> > The upper result should be: ~console.log("Hi, ", "chris");~.
>
> Here are your two source blocks. They each do literate programming,
> one with Variable style and the other with Noweb style. When you
> evaluate them you get an identical result. When you tangle them you
> get two different pieces of code, that generate the same result. You
> can peek at what the tangled code will look like by calling
> org-babel-expand-src-block inside the source block. That is how it
> will look in the tangled file. I think that want Noweb style.
>
> When I use the Variable approach like this
>
> #+begin_src js :var name="chris" :tangle kk.js
> console.log("Hi, ", name);
> #+end_src
>
> I get this in the tangled output file
>
> var name="chris";
> console.log("Hi, ", name);
>
> When I use the the Noweb approach like this
>
> #+NAME: name
> #+BEGIN_SRC emacs-lisp
> chris
> #+END_SRC
>
> #+NAME: org_gcr_2017-12-23_mara_3D887FDD-163D-4BE1-80E8-464BF29DABEA
> #+BEGIN_SRC js :tangle noweb-kk.js :comments no
> console.log("Hi, ", "«name»");
> #+END_SRC
>
> I get this in the tangled  output file
>
> console.log("Hi, ", "chris");
>
> WDYT?
>

Re: [O] TIL about use of eval in user Org macros.. Documentation?

[Nicolas Goaziou]

Hello,

Kaushal Modi  writes:

> #+MACRO: sec (eval (concat "" (number-to-string
> (org-macro--counter-increment $1 $2)) ""))

Or,

#+MACRO: sec @@html:@@{{{n($1,$2)}}}@@html:@@

> 1. Can you please document the use of eval form in Org macro definitions in
> the Org manual(.org)? Its awesome wasn't evident to me until I read that
> commit message.

Done.

Regards,

-- 
Nicolas Goaziou

Re: [O] Add contents-begin and contents-end to src-block in org-element.el

[Nicolas Goaziou]

Hello,

"Somelauw ."  writes:

> 2017-12-24 16:05 GMT+01:00 Nicolas Goaziou :
>> Contents mean "data in Org syntax". There are no such contents in source
>> blocks. Therefore, the parser does not provide :contents-begin
>> and :contents-end for them.
>
> Thanks for your quick response As I understand from your reply,
> :contents-begin/end should be reserved for elements that can contain
> other org-elements or org-objects.
>
> I'm writing a plugin that allows one to operate on the inner body of
> an org-element and so far I'm relying on :contents-begin and
> :contents-end. This has worked pretty well so far on most org
> elements, but org-src-blocks seem to be an exception. I may want to
> special-case these.
>
> By the way, do you know of any other org-elements that have an inner
> body that doesn't classify as "data in Org syntax"?

comment, comment blocks, example blocks, export blocks, fixed-width,
keyword, latex-environment, node property.

These elements usually set :value property instead.

Regards,

-- 
Nicolas Goaziou