Re: [O] refile workflow -- move to same heading in different file?

[Adam Porter]

"Raymond Zeitler"  writes:

> 1.  org-refile-targets ... value is ((org-agenda-files :regexp . "Tasks"))
> Seems OK.  But then I see that org-refile-target-verify-function is nil,
> which seems like a problem.  Mind you, this is the default configuration,
> and I'm not sure what to change it to.
>
> 2.  I placed the let block below into a subheading of Tasks in my todo.org
> and then evaluated it.  The error that Emacs returned follows that:
> (let ((org-refile-targets (quote (((org-agenda-files) :regexp . "Tasks")
> (org-refile))
> org-find-base-buffer-visiting: Wrong type argument: stringp,
> org-agenda-files

It seems that describe-variable isn't printing the variable structure
the way it really is, so then when you try to evaluate it, it doesn't
work.  Note that according to the docstring:

#+BEGIN_QUOTE
This is a list of cons cells.  Each cell contains:

- a specification of the files to be considered, either a list of files,
  or a symbol...
- A specification of how to find candidate refile targets.  This may be
  any of:
  ...
  - a cons cell (:regexp . "REGEXP") with a regular expression matching
headlines that are refiling targets.
#+END_QUOTE

So the variable is a list, which should contain at least one cons cell,
and the cons cells should have another cons cell as their cdrs.

Try this, it seems to work for me:

(let ((org-refile-targets '((org-agenda-files . (:regexp . "Tasks")
  (org-refile))

This is one advantage of the customize system: it makes it harder to get
these structures wrong.  :)

Re: [O] setting local variables

[Eric Abrahamsen]

Eric Abrahamsen  writes:

> Nicolas Goaziou  writes:
>
>> Eric Abrahamsen  writes:
>>
>>> Oh I don't think it's about shortcomings, just about having a version
>>> that's tweaked specifically for writing Emacs manuals. I _really_ want
>>> my packages to have info manuals, and I _really_ don't want to learn how
>>> to write texinfo. I saw Rasmus' Org manual in org, and it looked like a
>>> lot of work. Then I noticed that the Magit manuals used this
>>> texinfo-plus thing, and it seemed good enough.
>>
>> I think "ox-texinfo" is (almost) able to write Emacs manuals.
>>
>> IMO, you are comparing oranges and apples. Org's manual is historically
>> written as a (very convoluted) pure Texinfo document, with many macros
>> and different authors. Trying to convert it to Org for an Org to Texinfo
>> process is bound to be painful. OTOH, Magit's manual is probably more
>> straightforward, i.e., written as an Org document from the beginning,
>> with simpler requirements.
>>
>> In both cases, you cannot eschew learning a bit of Texinfo, if only for
>> the various indices commands and the installation part in the Info
>> directory.
>
> Well, I'll admit laziness has been my major motivation throughout the
> whole process.
>
>>> I think what might be nice would be to have another exporter, derived
>>> from ox-texinfo, specifically for writing Emacs manuals, that helps
>>> authors conform to the Emacs manual conventions. The way texinfo-plus
>>> handles lists of keybindings/user options/etc is nice, and it appears to
>>> set up the indexes for you, you only have to add concept index entries
>>> manually.
>>
>> AFAIU, the way texinfo-plus handles lists of ... is certainly nice, but
>> it's unrelated to Emacs manual conventions. It helps authors conform
>> Magit's author conventions. Those are fine, but I'm pretty sure not all
>> Emacs manuals follow them (Org doesn't, obviously).
>
> The main thing I was after was semi-automated indexing (obviously some
> of it you have to do yourself). I just looked more closely at the texi
> output that texinfo-plus produced, and it seems to only be doing concept
> and key indexing, not function or variable indexing. So that's not as
> helpful as I thought.

And regarding the lists of commands and keys, what would be the
recommended way of making a list of @deffns and corresponding index
entries? Perhaps it would be enough to expand the example document in
the texinfo section of the Org manual.

Eric

Re: [O] [feature-request] make org-quote-csv-field customizable

[Tim Cross]

and from memory, you can also tell excel what the data type of each
column in a csv file is.

Nicolas Goaziou writes:

> Hello,
>
> Thomas von Dein  writes:
>
>> currently when exporting a table to CSV, fields are quoted automatically
>> if they contain a comma or a quote character. The regexp for this
>> determination is hard-coded in 'org-quote-csv-field.
>>
>> This is good for most use cases. However, if you want to import such a
>> CSV with MS Excel then some unquoted fields will be automatically
>> converted by Excel into another format.
>>
>> An example is a field containing 192.168.10.233. 'org-quote-csv-field
>> doesn't quote it, but Excel - for reasons I cannot fathom - considers
>> this a number (it doesn't do this when the last octet is below 233
>> though) and converts it to 19216810233 - which is wrong.
>>
>> I wrote the following code to circumvent this Excel bug:
>>
>> (defun tvd-org-quote-csv-field (s)
>>   "Quote every field and precede it with = to disable excel automatisms."
>>   (if (string-match "." s)
>>   (concat "=\"" (mapconcat 'identity
>>(split-string s "\"") "\"\"") "\"")
>> s))
>>
>> (defun table-to-excel ()
>>   "export current org table to CSV format suitable for MS Excel."
>>   (interactive)
>>   ;; quote everything, map temporarily 'org-quote-csv-field
>>   ;; to my version
>>   (cl-letf (((symbol-function 'org-quote-csv-field)
>>  #'tvd-org-quote-csv-field))
>>(org-table-export "/tmp/ex.csv" "orgtbl-to-csv")))
>>
>> To make this customizable, it would be good to have a variable which
>> contains the regex to determine what to quote. A parameter to
>> org-table-export would be an even better solution.
>
> It is already possible. When asked for a format for conversion, you can
> write something like:
>
>   orgtbl-to-csv :fmt tvd-org-quote-csv-field
>
>
> You can also define your own format:
>
> (defun my-orgtbl-to-Excel (table params)
>   "Convert the orgtbl-mode table to Excel.
> This does take care of the proper quoting of fields with comma or quotes."
>   (orgtbl-to-generic table
>(org-combine-plists '(:sep "," :fmt 
> tvd-org-quote-csv-field)
>params)))
>
> and use it when prompted for a format in `org-table-export'.
>
> Regards,


-- 
Tim Cross

Re: [O] setting local variables

[Eric Abrahamsen]

Nicolas Goaziou  writes:

> Eric Abrahamsen  writes:
>
>> Oh I don't think it's about shortcomings, just about having a version
>> that's tweaked specifically for writing Emacs manuals. I _really_ want
>> my packages to have info manuals, and I _really_ don't want to learn how
>> to write texinfo. I saw Rasmus' Org manual in org, and it looked like a
>> lot of work. Then I noticed that the Magit manuals used this
>> texinfo-plus thing, and it seemed good enough.
>
> I think "ox-texinfo" is (almost) able to write Emacs manuals.
>
> IMO, you are comparing oranges and apples. Org's manual is historically
> written as a (very convoluted) pure Texinfo document, with many macros
> and different authors. Trying to convert it to Org for an Org to Texinfo
> process is bound to be painful. OTOH, Magit's manual is probably more
> straightforward, i.e., written as an Org document from the beginning,
> with simpler requirements.
>
> In both cases, you cannot eschew learning a bit of Texinfo, if only for
> the various indices commands and the installation part in the Info
> directory.

Well, I'll admit laziness has been my major motivation throughout the
whole process.

>> I think what might be nice would be to have another exporter, derived
>> from ox-texinfo, specifically for writing Emacs manuals, that helps
>> authors conform to the Emacs manual conventions. The way texinfo-plus
>> handles lists of keybindings/user options/etc is nice, and it appears to
>> set up the indexes for you, you only have to add concept index entries
>> manually.
>
> AFAIU, the way texinfo-plus handles lists of ... is certainly nice, but
> it's unrelated to Emacs manual conventions. It helps authors conform
> Magit's author conventions. Those are fine, but I'm pretty sure not all
> Emacs manuals follow them (Org doesn't, obviously).

The main thing I was after was semi-automated indexing (obviously some
of it you have to do yourself). I just looked more closely at the texi
output that texinfo-plus produced, and it seems to only be doing concept
and key indexing, not function or variable indexing. So that's not as
helpful as I thought.

>> Does that sound feasible? It would be great if this was available out of
>> the box.
>
> Even though such specialized back-ends are a good thing, I don't think
> Org needs another Texinfo back-end in core, however.
>
> "ox-texinfo.el" is really getting better. It is very versatile so it can
> bend to almost any convention.
>
> I won't pretend it makes learning Texinfo useless, though, because you
> need to learn it to write good manuals. The devil is in the details, and
> those are sometimes located at the Texinfo level.

I guess what I'm missing is clear guidelines on how to write manuals for
Emacs. I did look around, didn't find anything, and then just decided I
would use the easiest solution to hand, even if it wasn't ideal. If I
had a clear sense of what I was working towards, I'd probably put in the
time to learn the basics of texi and ox-texinfo. I guess I'll ask on
emacs.help.

At any rate, all this was in no way meant to be a criticism of
ox-texinfo, which I obviously haven't taken the time to learn...

Eric

Re: [O] Change in appearance of org-todo-keywords

[Adam Porter]

Colin Baxter  writes:

> Thanks for the suggestion, but I think I may be missing something. My
> emacs init has not changed. My org keyword settings have worked for a
> few years satisfactorily - until that is today. I think I need to bisect
> org-mode to find the case? I've tried reverting a couple of recent
> org-mode commits but to no avail.

Oh, I didn't realize you were on Org's bleeding edge.  ;)  If Org's the
only thing that's changed, then yeah, a git bisect should find it.

You might try with "emacs -q" first (loading the current Org files
manually).

Re: [O] [feature-request] make org-quote-csv-field customizable

[Nicolas Goaziou]

Hello,

Thomas von Dein  writes:

> currently when exporting a table to CSV, fields are quoted automatically
> if they contain a comma or a quote character. The regexp for this
> determination is hard-coded in 'org-quote-csv-field.
>
> This is good for most use cases. However, if you want to import such a
> CSV with MS Excel then some unquoted fields will be automatically
> converted by Excel into another format.
>
> An example is a field containing 192.168.10.233. 'org-quote-csv-field
> doesn't quote it, but Excel - for reasons I cannot fathom - considers
> this a number (it doesn't do this when the last octet is below 233
> though) and converts it to 19216810233 - which is wrong.
>
> I wrote the following code to circumvent this Excel bug:
>
> (defun tvd-org-quote-csv-field (s)
>   "Quote every field and precede it with = to disable excel automatisms."
>   (if (string-match "." s)
>   (concat "=\"" (mapconcat 'identity
>(split-string s "\"") "\"\"") "\"")
> s))
>
> (defun table-to-excel ()
>   "export current org table to CSV format suitable for MS Excel."
>   (interactive)
>   ;; quote everything, map temporarily 'org-quote-csv-field
>   ;; to my version
>   (cl-letf (((symbol-function 'org-quote-csv-field)
>  #'tvd-org-quote-csv-field))
>(org-table-export "/tmp/ex.csv" "orgtbl-to-csv")))
>
> To make this customizable, it would be good to have a variable which
> contains the regex to determine what to quote. A parameter to
> org-table-export would be an even better solution.

It is already possible. When asked for a format for conversion, you can
write something like:

  orgtbl-to-csv :fmt tvd-org-quote-csv-field


You can also define your own format:

(defun my-orgtbl-to-Excel (table params)
  "Convert the orgtbl-mode table to Excel.
This does take care of the proper quoting of fields with comma or quotes."
  (orgtbl-to-generic table
 (org-combine-plists '(:sep "," :fmt 
tvd-org-quote-csv-field)
 params)))

and use it when prompted for a format in `org-table-export'.

Regards,

-- 
Nicolas Goaziou

Re: [O] run bash sessions without config files

[Adam Porter]

Tyler Smith  writes:

> On Wed, Aug 2, 2017, at 11:53 AM, Tyler Smith wrote:
>> 
>> Is it possible to configure org-babel to ignore any customization files,
>> such as .emacs.d/init_bash.el and .bashrc?
>> 
> After some digging around, it looks like this isn't possible.
> ~org-babel~ starts shell sessions via the standard function ~(shell)~.
> Loading ~init_bash.el~ is hard-coded into this function, so there's no
> user-visible way to direct Emacs not to read it for org-mode code
> blocks, while still using it in other contexts. 

Could you run the code in the source block within "bash --noprofile
--norc"?  You could use "-c" to pass the rest of the commands as a
string, or "-s" to pass to STDIN with a heredoc.  I don't know if it
will work, but it might...

Re: [O] setting local variables

[Nicolas Goaziou]

Eric Abrahamsen  writes:

> Oh I don't think it's about shortcomings, just about having a version
> that's tweaked specifically for writing Emacs manuals. I _really_ want
> my packages to have info manuals, and I _really_ don't want to learn how
> to write texinfo. I saw Rasmus' Org manual in org, and it looked like a
> lot of work. Then I noticed that the Magit manuals used this
> texinfo-plus thing, and it seemed good enough.

I think "ox-texinfo" is (almost) able to write Emacs manuals.

IMO, you are comparing oranges and apples. Org's manual is historically
written as a (very convoluted) pure Texinfo document, with many macros
and different authors. Trying to convert it to Org for an Org to Texinfo
process is bound to be painful. OTOH, Magit's manual is probably more
straightforward, i.e., written as an Org document from the beginning,
with simpler requirements.

In both cases, you cannot eschew learning a bit of Texinfo, if only for
the various indices commands and the installation part in the Info
directory.

> I think what might be nice would be to have another exporter, derived
> from ox-texinfo, specifically for writing Emacs manuals, that helps
> authors conform to the Emacs manual conventions. The way texinfo-plus
> handles lists of keybindings/user options/etc is nice, and it appears to
> set up the indexes for you, you only have to add concept index entries
> manually.

AFAIU, the way texinfo-plus handles lists of ... is certainly nice, but
it's unrelated to Emacs manual conventions. It helps authors conform
Magit's author conventions. Those are fine, but I'm pretty sure not all
Emacs manuals follow them (Org doesn't, obviously).

> Does that sound feasible? It would be great if this was available out of
> the box.

Even though such specialized back-ends are a good thing, I don't think
Org needs another Texinfo back-end in core, however.

"ox-texinfo.el" is really getting better. It is very versatile so it can
bend to almost any convention.

I won't pretend it makes learning Texinfo useless, though, because you
need to learn it to write good manuals. The devil is in the details, and
those are sometimes located at the Texinfo level.

Regards,

Re: [O] Change in appearance of org-todo-keywords

[Colin Baxter]

Dear Adam,
> Adam Porter  writes:

> I don't mean this in a snide way, but do you keep your config in
> version control?  e.g. if you have it stored in git, you can
> bisect it and find the change that caused the problem.

> Other than that, you can probably find the problem using the
> bug-hunter package.  It can bisect your init file and find the
> lisp form that's causing it.

Thanks for the suggestion, but I think I may be missing something. My
emacs init has not changed. My org keyword settings have worked for a
few years satisfactorily - until that is today. I think I need to bisect
org-mode to find the case? I've tried reverting a couple of recent
org-mode commits but to no avail.

Best wishes,

Colin.

-- 
--
Colin Baxter
m43...@yandex.com
GnuPG fingerprint: 68A8 799C 0230 16E7 BF68  2A27 BBFA 2492 91F5 41C8

Re: [O] run bash sessions without config files

[Tyler Smith]

On Wed, Aug 2, 2017, at 11:53 AM, Tyler Smith wrote:
> 
> Is it possible to configure org-babel to ignore any customization files,
> such as .emacs.d/init_bash.el and .bashrc?
> 

After some digging around, it looks like this isn't possible.
~org-babel~ starts shell sessions via the standard function ~(shell)~.
Loading ~init_bash.el~ is hard-coded into this function, so there's no
user-visible way to direct Emacs not to read it for org-mode code
blocks, while still using it in other contexts. 

Best,

Tyler

Re: [O] [NOT SOLVED: BUG?]

[Uwe Brauer]

>>> "Berry," == Berry, Charles  writes:

>> On Aug 3, 2017, at 1:04 AM, Uwe Brauer  wrote:
>> 
>> 
>> 
>> I just checked and situation is absurd. Here is the minimal example:
>> [snip]
>> 
>> When I set org-export-babel-evaluate nil, then the code is *not*
>> evaluated, *but* the code block *and* the result are exported.
>> 
> [snip]
>> When I set org-export-babel-evaluate to t, export but say no to the
>> question whether or not to evaluate, *only* the result is exported,
>> which is what I want.
>> 
>> Is this a *bug*? I wait a day, then I will file a bug report.

> No. It is *obsolete* and its replacement is not recommended for your 
application. 

Thanks I did not finish reading the documentation, my bad

So I tried
#+begin_src matlab  :results output latex :exports results  :eval never-export 
X=[1];
disp('\begin{displaymath}')
fprintf('X&=%g \n', X)
disp('\end{displaymath}')
#+end_src

which then worked as expected. Before I played around with
code I found in
https://emacs.stackexchange.com/questions/17744/is-there-a-way-to-make-org-mode-ignore-src-blocks-when-exporting-to-html

But your suggestion is cleaner. Thanks

Uwe 

Re: [O] Happily exporting LaTeX, now want to export to text and HTML, can't figure how to handle latex markup

[Jeremie Juste]

"Berry, Charles"  writes:
Hello, 

Thanks for the update
>> 
>
> I think this is obsolete. It fails on org-9.0.9. What version of org are you 
> using? 
>
> In any case replacing the ~(if ...)~ by ~org-export-current-backend~ will fix 
> it.
>
>

> Another case were adding dates to Worg entries might help.

will keep that in mind.


Best regards,

Jeremie

Re: [O] org-babel python eval discrepancy

[Dushyant Juneja]

Hey Dov,

Bull's eye! Never realized that could hurt.

It so happened that I set the correct python version in my shell before
starting emacs. However, my bashrc file was hardwired to a different
version, which org used every time for evaluating the src blocks.

Thanks for the help!
Dushyant

On Thu, Aug 3, 2017 at 2:22 PM Dov Grobgeld  wrote:

> Shell is using python3 and org-mode python2?
>
> On Aug 3, 2017 8:31 PM, "Dushyant Juneja" 
> wrote:
>
>> Hi,
>>
>> I have the following code block in my org mode based literate programming
>> notes:
>>
>> #+BEGIN_SRC python
>> print('1+2 > 4 is ', 1+2 > 4)
>> print("What is 3 + 2?", 3 + 2)
>> #+END_SRC
>>
>> When I tangle it and run the script, it gives me expected output as
>> follows:
>>
>> > python notes.py
>> 1+2 > 4 is  False
>> What is 3 + 2? 5
>>
>> However, in buffer evaluation (using =C-c C-c= with cursor on src block)
>> gives me the following output, which seems unexpected:
>>
>> #+BEGIN_SRC python
>> print('1+2 > 4 is ', 1+2 > 4)
>> print("What is 3 + 2?", 3 + 2)
>> #+END_SRC
>>
>> #+RESULTS:
>> : ('1+2 > 4 is ', False)
>> : ('What is 3 + 2?', 5)
>>
>> Any hints what may be going wrong?
>>
>> Dushyant
>>
>

[O] Change in appearance of org-todo-keywords

[Colin Baxter]

Hello,

As of today, TODO now appears with three sets of un-requested double
colons after it, as in TODO :: :: ::

The behaviour doesn't occur with emacs -q, so the cause is presumably in
my ~/.emacs. I can't work out what's wrong with my org-todo-sequence,
which is:

(setq org-todo-keywords (quote((sequence "TODO(t)" "STARTED(s)"
"NEXT(n@/!)" "WAITING(w@/!)"
"HOLD(h@/!)" "CANCELLED(c@/!)"
"PHONE(p)"  "BREAK(b)" "MEETING(m)" "DONE(d@/!)"


Also, HOLD now appears as a tag when I change from TODO to HOLD. Any
suggestions as to how I might begin tracking down the cause? It's
driving me nuts.

Thanks.

Colin.

-- 
--
Colin Baxter
m43...@yandex.com
GnuPG fingerprint: 68A8 799C 0230 16E7 BF68  2A27 BBFA 2492 91F5 41C8

Re: [O] Change in appearance of org-todo-keywords

[Adam Porter]

I don't mean this in a snide way, but do you keep your config in version
control?  e.g. if you have it stored in git, you can bisect it and find
the change that caused the problem.

Other than that, you can probably find the problem using the bug-hunter
package.  It can bisect your init file and find the lisp form that's
causing it.

Re: [O] org-babel python eval discrepancy

[Adam Porter]

Lookup "Org babel results" in Google and you should find the right
section of the manual.  You need to set the :results keyword. 

Re: [O] org-babel python eval discrepancy

[Dov Grobgeld]

Shell is using python3 and org-mode python2?

On Aug 3, 2017 8:31 PM, "Dushyant Juneja"  wrote:

> Hi,
>
> I have the following code block in my org mode based literate programming
> notes:
>
> #+BEGIN_SRC python
> print('1+2 > 4 is ', 1+2 > 4)
> print("What is 3 + 2?", 3 + 2)
> #+END_SRC
>
> When I tangle it and run the script, it gives me expected output as
> follows:
>
> > python notes.py
> 1+2 > 4 is  False
> What is 3 + 2? 5
>
> However, in buffer evaluation (using =C-c C-c= with cursor on src block)
> gives me the following output, which seems unexpected:
>
> #+BEGIN_SRC python
> print('1+2 > 4 is ', 1+2 > 4)
> print("What is 3 + 2?", 3 + 2)
> #+END_SRC
>
> #+RESULTS:
> : ('1+2 > 4 is ', False)
> : ('What is 3 + 2?', 5)
>
> Any hints what may be going wrong?
>
> Dushyant
>

[O] Adding custom arguments to org-babel src code eval

[Dushyant Juneja]

Hi,

Is it possible to add custom arguments to source code evaluation in org
babel? For example, if the source code block is:

#+BEGIN_SRC python
# valid comment 1
print("Hi there!") # valid comment 2
print("# Invalid comment! #UsefulForHashtags!")
print ("Space is fine here!")
#+END_SRC

The general C-c C-c will evaluate it using the python interpreter. Hence
the result:
#+RESULTS:
: Hi there!
: # Invalid comment! #UsefulForHashtags!
: Space is fine here!

However, I would like to pass '-m trace --trace' arguments to the
interpreter, so that the resulting text capture is basically an output of
the following command:

> python -m trace --trace notes.py
 --- modulename: notes, funcname: 
notes.py(2): print("Hi there!") # valid comment 2
Hi there!
notes.py(3): print("# Invalid comment! #UsefulForHashtags!")
# Invalid comment! #UsefulForHashtags!
notes.py(4): print ("Space is fine here!")
Space is fine here!
 --- modulename: trace, funcname: _unsettrace
trace.py(77): sys.settrace(None)

So far, I know I can do this via #+call syntax and a custom shell script.
However, that looks like an overkill for passing simple arguments to the
interpreter. I have tried :cmdline and :args "-m trace --trace", and
neither seem to work.

Any ideas?

Dushyant

[O] org-babel python eval discrepancy

[Dushyant Juneja]

Hi,

I have the following code block in my org mode based literate programming
notes:

#+BEGIN_SRC python
print('1+2 > 4 is ', 1+2 > 4)
print("What is 3 + 2?", 3 + 2)
#+END_SRC

When I tangle it and run the script, it gives me expected output as follows:

> python notes.py
1+2 > 4 is  False
What is 3 + 2? 5

However, in buffer evaluation (using =C-c C-c= with cursor on src block)
gives me the following output, which seems unexpected:

#+BEGIN_SRC python
print('1+2 > 4 is ', 1+2 > 4)
print("What is 3 + 2?", 3 + 2)
#+END_SRC

#+RESULTS:
: ('1+2 > 4 is ', False)
: ('What is 3 + 2?', 5)

Any hints what may be going wrong?

Dushyant

Re: [O] Happily exporting LaTeX, now want to export to text and HTML, can't figure how to handle latex markup

[Berry, Charles]

> On Aug 2, 2017, at 4:22 PM, Jeremie Juste  wrote:
> 
> 
> 
> Hello 
> 
>> 
>> Putting together a macro seems like the best option.  Recall that you
>> can use elisp in macros by placing it between `(eval’ and `)', so the
>> following emits “def’ in all but latex exports and “abc” for latex.
>> 
> 
> 
> Yes I found this nice piece of code  
> 
> It switches to svg if backend is html and to raw latex if backend is
> latex. You only have to tweak it your needs.
> 

I think this is obsolete. It fails on org-9.0.9. What version of org are you 
using? 

In any case replacing the ~(if ...)~ by ~org-export-current-backend~ will fix 
it.


> #+header: :file (by-backend (html "tree.svg") (t 'nil))
> #+header: :imagemagick
> #+header: :results (by-backend (pdf "latex") (t "raw"))
> #+begin_src latex
>  \usetikzlibrary{trees}
>  \begin{tikzpicture}
>\node [circle, draw, fill=red!20] at (0,0) {1}
>child { node [circle, draw, fill=blue!30] {2}
>  child { node [circle, draw, fill=green!30] {3} }
>  child { node [circle, draw, fill=yellow!30] {4} }};
>  \end{tikzpicture}
> #+end_src
> 
> * COMMENT setup
> #+begin_src emacs-lisp :results silent
>  (setq org-babel-latex-htlatex "htlatex")
>  (defmacro by-backend ( body)
>`(case (if (boundp 'backend) (org-export-backend-name backend) nil) 
> ,@body))
> #+end_src
> 
> The reference 
> http://orgmode.org/worg/org-contrib/babel/languages/ob-doc-LaTeX.html
> 

Another case were adding dates to Worg entries might help.

Chuck

Re: [O] [NOT SOLVED: BUG?] (was: [SOLVED])

[Berry, Charles]

> On Aug 3, 2017, at 1:04 AM, Uwe Brauer  wrote:
> 
> 
> 
> I just checked and situation is absurd. Here is the minimal example:
> [snip]
> 
> When I set org-export-babel-evaluate nil, then the code is *not*
> evaluated, *but* the code block *and* the result are exported.
> 
[snip]
> When I set org-export-babel-evaluate to t, export but say no to the
> question whether or not to evaluate, *only* the result is exported,
> which is what I want.
> 
> Is this a *bug*? I wait a day, then I will file a bug report.

No. It is *obsolete* and its replacement is not recommended for your 
application. 

,[ C-h v org-export-babel-evaluate RET ]
| org-export-babel-evaluate is a variable defined in ‘org-compat.el’.
| Its value is t
| 
|   This variable is an alias for ‘org-export-use-babel’.
|   This variable is obsolete since Org 9.1;
|   use ‘org-export-use-babel’ instead.
| 
| Documentation:
| Switch controlling code evaluation and header processing during export.
| When set to nil no code will be evaluated as part of the export
| process and no header arguments will be obeyed.  When set to
| ‘inline-only’, only inline code blocks will be executed.  Users
| who wish to avoid evaluating code on export should use the header
| argument ‘:eval never-export’.
| 
| You can customize this variable.
| 
| [back]
`

You want `:eval never-export'.


Chuck

Re: [O] setting local variables

[Eric Abrahamsen]

Nicolas Goaziou  writes:

> Hello,
>
> Eric Abrahamsen  writes:
>
>> I'm writing an Emacs manual in Org, using
>> https://github.com/tarsius/ox-texinfo-plus to make things a bit
>> easier.
>
> I don't know that library, but as a biased POV, it would be nice to use
> "ox-texinfo" and let us know about its shortcomings. Just saying.

Oh I don't think it's about shortcomings, just about having a version
that's tweaked specifically for writing Emacs manuals. I _really_ want
my packages to have info manuals, and I _really_ don't want to learn how
to write texinfo. I saw Rasmus' Org manual in org, and it looked like a
lot of work. Then I noticed that the Magit manuals used this
texinfo-plus thing, and it seemed good enough.

I think what might be nice would be to have another exporter, derived
from ox-texinfo, specifically for writing Emacs manuals, that helps
authors conform to the Emacs manual conventions. The way texinfo-plus
handles lists of keybindings/user options/etc is nice, and it appears to
set up the indexes for you, you only have to add concept index entries
manually.

Does that sound feasible? It would be great if this was available out of
the box.

Eric

Re: [O] [PATCH] ob-vala.el: Add Vala support to Babel

[Nicolas Goaziou]

Hello,

Christian Garbs  writes:

> The next iteration of the patch should include ob-vala.el itself, some
> tests and an ORG-NEWS entry.

Great! Thank you.

> Regarding the lexical-binding:  How can I check if byte-compiling is
> successful?

M-x emacs-lisp-byte-compile

Regards,

-- 
Nicolas Goaziou

Re: [O] setting local variables

[Nicolas Goaziou]

Hello,

Eric Abrahamsen  writes:

> I'm writing an Emacs manual in Org, using
> https://github.com/tarsius/ox-texinfo-plus to make things a bit
> easier.

I don't know that library, but as a biased POV, it would be nice to use
"ox-texinfo" and let us know about its shortcomings. Just saying.

Regards,

-- 
Nicolas Goaziou

Re: [O] Adding single cell movement to org-table

[Nicolas Goaziou]

Hello,

Chris Kauffman  writes:

> Apologies for the earlier diff-blast: I did not see the advice on the
> org-mode contributions page that patches generated via
>   git format-patch master
> are preferred.  Please find four patches attached which now include
> modifications to ORG-NEWS, org.texi, orgguid.texi, and keybindings
> suggested by Carsten: S-up, S-down, S-left, S-right in org.el (via
> org-shiftup etc.).

Thank you! Some comments follow.

>  ;;;###autoload
> +(defun org-table-max-line-col ()
> +  "Return the maximum line and column of the current table as a
> +list of two numbers"
> +  (when (not (org-at-table-p))
> +(user-error "Not in an org-table"))
> +  (let ((table-end (org-table-end)))
> +(save-mark-and-excursion
> + (goto-char table-end)
> + (org-table-previous-field)
> + (list (org-table-current-line) (org-table-current-column)

I don't think this function is necessary. There is already a similar
mechanism with `org-table-current-ncol' and `org-table-current-dlines'.
Besides, you only need to check if point is within the table, which is
trivial:

  (skip-chars-backward " \t")
  (or (bolp) (looking-at-p "[ \t]*$"))

for the row, `org-table-goto-line' returns nil if there is no such line.

> +;;;###autoload
> +(defun org-table-swap-cells (row1 col1 row2 col2)
> +  "Swap two cells indicated by the coordinates provided"

Final dot missing. ROW1 COL1 ROW2 COL2 should be explained.

> +  (let ((content1 (org-table-get row1 col1))
> + (content2 (org-table-get row2 col2)))
> +(org-table-put row1 col1 content2)
> +(org-table-put row2 col2 content1)
> +(org-table-align)))

This function can be made internal: no need to autoload it, and rename
it as `org-table--swap-cells'. Besides, it shouldn't call
`org-table-align', which is out of its scope.

> +;;;###autoload
> +(defun org-table-move-single-cell (direction)
> +  "Move the current cell in a cardinal direction according to the

First line should be a sentence on its own.

DIRECTION should be more explicit in the docstring.

> +parameter symbol: 'up 'down 'left 'right. Swaps contents of

`up', `down', `left' or `right'.

Also, mind the two spaces after a full stop.

> +adjacent cell with current one."
> +  (unless (org-at-table-p)
> +(error "No table at point"))
> +  (let ((drow 0) (dcol 0))
> +(cond ((equal direction 'up)(setq drow -1))
> +   ((equal direction 'down)  (setq drow +1))
> +   ((equal direction 'left)  (setq dcol -1))
> +   ((equal direction 'right) (setq dcol +1))
> +   (t (error "Not a valid direction, must be one of 'up 'down 'left 
> 'right")))
> +(let* ((row1 (org-table-current-line))
> +(col1 (org-table-current-column))
> +(row2 (+ row1 drow))
> +(col2 (+ col1 dcol))
> +(max-row-col (org-table-max-line-col))
> +(max-row (car max-row-col))
> +(max-col (cadr max-row-col)))
> +  (when (or (< col1 1) (< col2 1) (> col2 max-col) (< row2 1) (> row2 
> max-row))
> + (user-error "Cannot move cell further"))
> +  (org-table-swap-cells row1 col1 row2 col2)
> +  (org-table-goto-line row2)
> +  (org-table-goto-column col2

This should be an internal function: `org-table--move-single-cell', and
not autoloaded.

As an internal function, there is no need to check for `org-at-table-p'.
It's the responsibility of the callers to do so. Also,
`org-table-check-inside-data-field' is more appropriate here.

> +;;;###autoload
> +(defun org-table-move-single-cell-up ()
> +  "Move a single cell up in a table; swap with anything in target cell"

Missing final full stop.

> +  (interactive)
> +  (org-table-move-single-cell 'up))

Per above, I suggest adding (org-table-check-inside-data-field) after
the (interactive). The same goes for the other functions.

Could you send an updated patch?

Regards,

-- 
Nicolas Goaziou0x80A93738

Re: [O] Bug: Wrong type argument: integer-or-marker-p, nil on refile

[Adam Porter]

Michaël Cadilhac  writes:

> Here's the ECM.
>
> init.el:
> (require 'org)
> (setq org-refile-use-outline-path (quote file))
>
> Now open an Org file, say foo.org, and type C-u C-c C-w foo.org/ RET
> At org.el:11832, pos is nil.

Confirmed here with Org 9.0.5.  I think it's from
org-refile-check-position: (pos (nth 3 refile-pointer)) causes the error
because the refile-pointer doesn't have a position set, because you
selected the top-level, file-only completion without a heading.

Re: [O] refile workflow -- move to same heading in different file?

[Adam Porter]

"Raymond Zeitler"  writes:

> C-c C-w cannot seem to recognize any of my agenda files, even though
> org-refile-targets is set to (in custom-set-variables):
>
> (org-refile-targets (quote ((org-agenda-files :regexp . "Tasks"
>
> Suppose org-agenda-files contains "~/proj1.org" "~/proj2.org" "~/proj3.org" 
> "~/todo.org".
>
> My expectation is that when I press C-c C-w with point on a subheading
> of Tasks in todo.org, I can specify, say proj1.org and get the
> subheading moved to proj1.org under Tasks. However, org-refile
> responds [No Match], even if I provide the file as ~/proj1.org. And
> Emacs is visiting proj1.org in another buffer.

Hi Raymond,

Going on what you've provided, it sounds like it should work.  A few
suggestions:

1.  In case you haven't yet (but you probably have), check
describe-variable for org-refile-targets.

2.  If you have any doubt about org-refile-targets being set correctly,
experiment with setting it and calling org-refile inside a (let).

3.  I haven't used the default Emacs completion in years; I'm so used to
having Helm that when I have to run "emacs -q" now and then, completing
buffer names and such is painful!  :)  So I'd suggest temporarily, at
least, using Helm as the default completing-read method, which will make
it much easier to debug by showing you the full list of candidates.
That way, if it's empty to begin with, you know something's really
wrong; or if it's full, but it shows [No Match] after you type something
in, that should help you narrow down the cause.

Hope this helps.

Re: [O] Finding calc/elisp methods

[Adam Porter]

Karl Voit  writes:

> Leslie helped here by mentioning vmin/vmax which is that obvious
> that I do feel embarrassed now ;-)
>
> #+TBLFM: 
> @2$1=vmin(remote(myvalues,@2$1..@>$1))::@2$2=vmax(remote(myvalues,@2$1..@>$1))::@2$3=vmean(remote(myvalues,@2$1..@>$1))::@2$4=remote(myvalues,@2$1)::@2$5=remote(myvalues,@>$1)
>
> However, let's make this thread a valuable one by adding a question:
> how does somebody find such things? Is there a source of information
> where I could find calc methods by "apropos" method together with
> elisp methods?
>
> "M-h a minimum" returns only calc-find-minimum which is hardly of
> any help in this case. "apropos-documentation" returns more results
> but still lacks "vmin".
>
> What is your method of choice to find answers to those kind of
> questions? At least my internet search engine of choice did not help
> me in the first place.

IIRC these kinds of things are in the Org manual and info pages.  Helm's
helm-info-org command is very helpful for finding things in the Org info
manual.

I learned something new today: I didn't realize that Org could use
calc-mode commands in tables.  Wow.  Org never ceases to surprise and
amaze me!

So googling for "org table calc" I got the manual page:
http://orgmode.org/manual/Formula-syntax-for-Calc.html

It wouldn't hurt to add a section to that page explaining how to find
more info about the calc functions...  ;)

Re: [O] Determine min/max values in a table

[Adam Porter]

Thierry Banel  writes:

> Alternatively you have the orgtbl-aggregate package available on Melpa.
>
> #+BEGIN: aggregate :table "myvalues" :cols "min(Values) max(Values)
> mean(Values)"
>
> | min(Values) | max(Values) | mean(Values) |
> |-+-+--|
> |   2 |   7 |  4.5 |

Wow, that's very cool!  Had no idea about that package.

Karl, if that doesn't work for you, you might look at the
org-table-to-lisp function.  Here's an example of a function that uses
it to sum columns in the current region:

#+BEGIN_SRC elisp
(defun org-fitness-sum-table-lines ()
"Sum each numeric column in table lines touched by the region."
(interactive)
(org-with-wide-buffer
 (let* (
;; Add empty column because (org-table-get-specials) leaves the 
empty one out, which throws off the indices
(header (cons nil (org-table-column-names)))
(start (save-excursion
 (goto-line (line-number-at-pos (region-beginning)))
 (line-beginning-position)))
(end (save-excursion
   (goto-line (line-number-at-pos (region-end)))
   (line-end-position)))
(lines (buffer-substring-no-properties start end))
(table (--remove (equal 'hline it)
 (org-table-to-lisp lines)))
(indices (cdr  ; Drop index representing first column, which is 
always empty
  (butlast  ; Drop index representing last column, which is 
comments
   (-find-indices (lambda (col)
(or (string= col "")
(string= col "0")
(string= col "0.0")
(string= col "0.00")
(< 0 (string-to-number col
  (car table)
(sums (cl-loop for i in indices
   collect (-reduce '+ (-map 'string-to-number
 (-select-column i 
table)
(result (-zip (-select-by-indices indices header) sums)))
   (org-fitness-display-values result :prefix "Lines: "
#+END_SRC

[O] [NOT SOLVED: BUG?] (was: [SOLVED])

[Uwe Brauer]

I just checked and situation is absurd. Here is the minimal example:
,
| 
| #+begin_src matlab   :results output latex :exports results 
| X=[1];
| disp('\begin{displaymath}')
| fprintf('X&=%g \n', X)
| disp('\end{displaymath}')
| #+end_src
| 
| #+RESULTS:
| #+BEGIN_EXPORT latex
| \begin{displaymath}
| X&=1\\ 
| \end{displaymath}
| #+END_EXPORT
`


When I set org-export-babel-evaluate nil, then the code is *not*
evaluated, *but* the code block *and* the result are exported.
,
| 
| \begin{document}
| 
| 
\lstset{style=Matlab-editor,basicstyle=\mlttfamily,escapechar=",mlshowsectionrules=true,mathescape=true,morecomment=[s]{\%\{}{\%\}},language=Matlab,label=
 ,caption= ,captionpos=b,numbers=none}
| \begin{lstlisting}
| X=[1];
| disp('\begin{displaymath}')
| fprintf('X&=%g \n', X)
| disp('\end{displaymath}')
| \end{lstlisting}
| 
| \begin{displaymath}
| X&=1\\ 
| \end{displaymath}
| \end{document}
`

When I set org-export-babel-evaluate to t, export but say no to the
question whether or not to evaluate, *only* the result is exported,
which is what I want.
,
| 
| \begin{document}
| 
| \begin{displaymath}
| X&=1\\ 
| \end{displaymath}
| \end{document}
`

Is this a *bug*? I wait a day, then I will file a bug report.

Uwe Brauer 

[O] [SOLVED] (was: exporting org to latex, execute matlab before exporting)

[Uwe Brauer]

>>> "Uwe" == Uwe Brauer  writes:


   > Which is what I want. When I convert the org file to latex I am again
   > asked to execute the src block, which I don't want since it is already
   > executed. How can I avoid this question, without deleting the src block.
   > This is important if I have a lot of blocks which I already have
   > executed, and want to export the file without denying is executing every
   > time I am asked.

To answer my own question put

# -*- org-export-babel-evaluate: nil -*-

At the beginning of the file.