Re: [O] contributing to work on citations

[Rasmus]

Hi,

Thanks for looking at this, Matt and Aaron.

Matt Price  writes:

> Anyway, I figure I will try to modify zotxt-emacs so it provides these
> functions and generates conformant cite: links.  That seems the easiest
> solution, and maybe Erik will give me some help once I've made some initial
> progress.  Meanwhile I will try to learn enough about javascript to get
> started on the citeproc-js ocmmand-line tool.  thx,

I use JS sometimes, and FWIW I thinking your plan of altering citeproc-js
upstream is the best approach proposed thus far.

ATM I don’t have much time, and I having a hard time forming a overview of
where to aid wrt. adding citation support.

Rasmus

-- 
And when I’m finished thinking, I have to die a lot

Re: [O] org/android sync

[Nick Dokos]

Rasmus  writes:

> Hi Nick,
>
> Nick Dokos  writes:
>
>> There was a  G+ post in the orgmode community
>> pointing to 
>>
>>http://www.orgzly.com/
>>
>> No idea whether it works or not but I figured if you
>> have an android phone, here's another opportunity to
>> bury your face in it :-)
>
> Note, it's closed source.  There was a big fuss when the author introduced
> it on this list, maybe half a year ago.
>

Ah, sorry - I didn't even think to check either the list for
previous mentions or the website for licensing.

-- 
Nick

Re: [O] Using orgstruct-mode (or just org-cycle) in emacs-lisp-mode

[Nicolas Goaziou]

Hello,

Jonas Bernoulli  writes:

> I would like to use `orgstruct-mode' in `emacs-lisp-mode' but I cannot
> get it to work at all.  So for now I would be happy if I could just use
> `org-cycle' as I used to.

Thank you for the report. 

`orgstruct-mode' really needs some love. Being to much linked with Org's
innards, it prevents us from using faster algorithms in pure Org
buffers.

Anyway, I pushed a fix for the issue.


Regards,

-- 
Nicolas Goaziou

Re: [O] visual-fill-column-mode with org

[Aaron Ecay]

Hi Vikas,

AFAIK, the visual-fill-mode features are implemented at a very low level
in the display code, in C.  It would be nice if it was possible to mark
lines as exempt from wrapping (e.g. by putting a text property on
them).  Org could then arrange for tables to have this text property,
and not be wrapped.  But this would require changes to emacs’s C code.
(I’m also not sure how it would interact with visual-fill-column-mode,
which is a third-party addon.)

Another option would be to use auto-fill-mode to keep your text
paragraphs within your desired width, without affecting tables.

-- 
Aaron Ecay

Re: [O] :noweb no-export and syntax highlighting upon export to html

[Aaron Ecay]

Hi Joost,

2015ko azaroak 8an, Joost Helberg-ek idatzi zuen:
> 
> Dear Aaron,
> 
> I was running close to the development version, but not close
> enough. It's solved now in the current version of org-mode.
> 
> At first I accepted this odd behaviour, but then I realized htmlize is
> supposed to give you what you see on screen, hence this was a bug.

I’m glad the bug has disappeared (at least, that’s what I understand
from your message).  Thanks for the update, and do let us know if it
comes back.

Thanks,

-- 
Aaron Ecay

Re: [O] Conditional link export?

[Nicolas Goaziou]

Hello,

Oleh Krehel  writes:

> I'd appreciate everyone's thoughts on the proposed addition.  Best case
> scenario, Nicolas agrees and it's actually easy to add the new "!()"
> inline Elisp syntax. Mid case, everyone's indifferent and I can add the
> code myself. Worst case, people are opposed to this change and I'm
> sad.

There is already inline syntax for any language, including elisp:

  src_emacs-lisp{(foo)}

and, if you use the library of Babel,

  call_foo{}

I don't see the need to add yet another way to call inline code from an
Org document.


Regards,

-- 
Nicolas Goaziou

[O] footnotes position in html export

[Orm Finnendahl]

Hi,

 when exporting an org-file to html using org-mode.js, the footnotes
appear at the end of the document.

I'd rather have the footnotes at the end of each section. As far as I
understand, this can be achieved by distributung the different
sections to different .org documents and including those from a master
document.

Unfortunately in my document are many sections which are rather short
and I'd prefer to keep them in a single document. Does anybody know of
a way to achieve this? I couldn't find anything related to that on the
web.

--
Orm

Re: [O] Conditional link export?

[Oleh Krehel]

Aaron Ecay  writes:

> Extra elisp inside the org file is an important way of extending the
> power of org markup.  Why don’t you want to use it?

Including boilerplate Elisp, all subtly different into each markup
document, just to extend the markup with the syntax that it should have
in the first place anyway. Doesn't that sound bad to you?

One-off Elisp inclusions relevant to a single document are great and
powerful, but adding boilerplate code, usually more of it that the whole
sum of the markup, doesn't sound great at all.  This could be rectified
somewhat by using `require', but then we don't have a self-contained
document any more. Which is important to facilitate sharing and re-use
of Org-mode documents.

> Not in general.  For small pieces of text, you can use macros.
> Something like:
>
> #+macro: ifinfo (eval (if (org-export-derived-backend 
> org-export-current-backend 'info) "$1" "$2"))
>
> {{{ifinfo([[info:emacs#Pachages]],[[https://]])}}}

The macro definition and call syntax looks very ugly.
Why can't we add inline Elisp calls with the following rules:

1. Any amount of Elisp code can be embedded.
2. The result of the last expression is interpreted either as "%s" or
"%S" appropriately.

I tried this:

For more package manager details, see 
#+begin_src emacs-lisp :exports results
(defun ox-link (link  description)
  (cond ((equal org-export-current-backend 'html)
 (format "%s"
 link
 (or description link)))
(t
 link)))
(cond
  ((equal org-export-current-backend 'texinfo+)
   (ox-link "info:emacs#Packages"))
  (t
   (ox-link 
"https://www.gnu.org/software/emacs/manual/html_node/emacs/Packages.html;)))
#+end_src
.

Here are the problems that I see here:

1. The results aren't embedded and are instead quoted. Extra newlines
are added around the result.
2. Something like `ox-link' isn't built-in.
3. The boundaries are rather verbose, maybe "#+begin_src inline" or
something even shorter would look better.

I think fixing the above three issues would really improve Org-mode's
markup, make it much more powerful. We already have `org-edit-src-code'
which allows us to edit Elisp natively, it only remains to un-constrain
the results from being quoted in a  block, and provide the
standard API (e.g. `ox-link', `ox-src', `ox-tbl') that would work
for all export back ends.

Here's how my example would look, once the above changes are
implemented:

!(cl-case org-export-current-backend
   (texinfo+
(ox-link
 "info:emacs#Packages"))
   (t
(ox-link
 
"https://www.gnu.org/software/emacs/manual/html_node/emacs/Packages.html;)))

Now note that the above is meant to be exported inline, instead of into
a  block. If I wanted such a block, I would Paredit-wrap that
sexp with (ox-pre) - a very quick and simple modification.  And to
remove (ox-pre), simply Paredit-raise. Now this would be a powerful
markup indeed. One very important advantage is that each block can be
efficiently debugged in its native Elisp mode, maybe even ERT-tested,
because all API functions would be bound all the time, not just during
the export.

> Note that the solution I gave you allows the links to be clickable in
> the buffer, whereas a macro does not (sort of).

I think we should completely get rid of macros and simply use inline
Elisp, which is both more powerful and more simple.

> See, even you can’t resist putting elisp in.  :P  You could give the
> your pseudocode a #+name and then call it as an inline babel call.

The #+name thing is powerful because if I understood correctly it allows
to call /any/ language not just Elisp. As I mentioned above, I think
Elisp should be privileged and we should be able to call any bound Elisp
function inline without having to declare it.

>> 2. Does Org-mode support the kbd markup for denoting keyboard shortcuts?
>> I'm guessing that the answer is no, which is a shame since both Texinfo
>> and Github/StackExchange-flavored Markdown support it.
>
> No.  There was recently a thread on small caps syntax:
> 
> where many of the same themes come up.
>
> There’s not enough consensus at present to add any new markup types to
> org syntax.  Macros can be made to serve many of the same functions,
> though.

I see. I understand why Nicolas is reluctant to modify the actual syntax
for every small thing. And macros could indeed be a solution. My issues
with the macros are the following:

1. They're awkward to define.
2. They're awkward to call.

Using inline Elisp instead of macros would solve both problems.  The
first problem is solved by having a standard library e.g. ox-inline.el
bundled with Org. That would include, e.g. `ox-kbd'. Additionally the
users can write their own libraries and simply `require' them.

Here's how it might look like:

To install a 

Re: [O] Conditional link export?

[Nicolas Goaziou]

Oleh Krehel  writes:

> Is that a new feature?

It is probably almost as old as Babel itself.

> First time I've heard about it, and I did google
> for inline code block evaluation before.

You should check the Org manual first: 

  (info "(org) Structure of code blocks")

> In any case, the HTML export result of e.g. this:
>
> The current time is: src_emacs-lisp{(format "%s" 
> "http://google.com; (format-time-string "%H:%M"))}.
>
> is:
>
> The current time is: a href" href="http://google.com/;>http://google.com/"15:50/a=.
>
> which is far from what I want.

Try

The current time is: src_emacs-lisp[:results html]{(format "%s" "http://google.com; (format-time-string "%H:%M"))}.

> And I still think that Elisp could benefit from privileged call
> syntax. Compare:
>
> !(foo)
>
> to
>
> src_emacs-lisp{(foo)}

I'm not a big fan of redundant syntax. Also, I'm trying to move Org
format out of Elisp's grasp. This doesn't help much either.

> Additionally `org-edit-src-code' doesn't work for these blocks.

Do you want to provide a patch for it?


Regards,

Re: [O] patch to keep the level in refile

[Nicolas Goaziou]

Sebastian Fischmeister  writes:

>>> This causes problems, when the level has semantic meaning beyond
>>> defining the hierarchy (e.g., level 3 always indicates a task while
>>> levels 2 and 1 are project headings).
>>
>> Why don't you simply refile into the parent, then?
>
> Because there might not be a lvl 2 heading, but still lvl 3 are tasks.

Good point.

Forcing the level of the heading is not a good idea, because it can
badly alter the structure of the document (e.g., you are refiling under
"A", but the task ends up being a grandson).

Maybe we need a more general mechanism to refile "at" instead of
refiling "within", i.e., a mechanism to refile just before a given
headline, at its very same level, which could be a toggle when calling
org-refile.

Maybe this is overkill, tho.

Regards,

Re: [O] footnotes position in html export

[Orm Finnendahl]

Hi Nicolas,

 thanks a lot, that sounds quite feasible and your suggestions will
probably save me a lot of time! I just started writing the book and
first need some more content but will look into coding it while it's
growing.

I'll post back to the list when I have results in case someone is
interested and has a use for it.

--
Orm

Am Sonntag, den 08. November 2015 um 16:11:03 Uhr (+0100) schrieb Nicolas 
Goaziou:
> Hello,
> 
> Orm Finnendahl  writes:
> 
> > ok, thanks. I'll look into it. Maybe it's not too hard to
> > implement.
> 
> It shouldn't. Basically, you need to:
> 
>   1. Add an optional argument to `org-html-footnote-section' specifying
>  the scope of footnotes, skip
>  `org-export-collect-footnote-definitions' altogether and use
>  `org-element-map' to find "first footnotes references" (see
>  `org-export-footnote-first-reference-p') in the scope.
> 
>  Then with `org-export-get-footnote-definition', you can build the
>  footnote section.
> 
>   2. Call `org-html-footnote-section' from `org-html-section', with the
> parent headline, if any, or the current section otherwise as the
> current scope.
> 
>   3. Create a new variable to toggle behaviour of footnotes.
> 
> HTH,
> 
> Regards,
> 
> -- 
> Nicolas Goaziou

Re: [O] org/android sync

[Rasmus]

Hi Nick,

Nick Dokos  writes:

> There was a  G+ post in the orgmode community
> pointing to 
>
>http://www.orgzly.com/
>
> No idea whether it works or not but I figured if you
> have an android phone, here's another opportunity to
> bury your face in it :-)

Note, it's closed source.  There was a big fuss when the author introduced
it on this list, maybe half a year ago.

Rasmus

-- 
Slaa Patienten ihjel, saa siger Feberen Pas

Re: [O] visual-fill-column-mode with org

[Rasmus]

Vikas Rawal  writes:

> I would like to use visual-fill-column-mode with my org
> files. However, this has a peculiar problem that org tables also start
> wrapping at fill-column. Does anyone use visual-fill-column-mode with
> org and has found a way of telling it to ignore lines starting with a
> |?

Hardly a solution, but you can force columns to only be a certain width
with the  declaration, where n is an integer.

Rasmus

-- 
A clever person solves a problem. A wise person avoids it

Re: [O] :noweb no-export and syntax highlighting upon export to html

[Joost Helberg]

Dear Aaron,

I was running close to the development version, but not close
enough. It's solved now in the current version of org-mode.

At first I accepted this odd behaviour, but then I realized htmlize is
supposed to give you what you see on screen, hence this was a bug.

regards,

Joost

> "Aaron" == Aaron Ecay  writes:
 > From: Aaron Ecay 
 > To: Joost Helberg , emacs-orgmode@gnu.org
 > Subject: Re: [O] :noweb no-export and syntax highlighting upon export
 > Date: 2015-11-05T15:45:34+0100

 > Hi Joost,

 > Org’s html export relies on the syntax of the source block being valid
 > in the block’s language, for the corresponding emacs major mode to
 > highlight it properly.  In general, I wouldn’t rely on it behaving
 > properly in the presence of unexpanded noweb references.  That said...

 > 2015ko azaroak 5an, Joost Helberg-ek idatzi zuen:
 >> 
 >> ls,
 >> 
 >> In the org-code below syntax highlighting in both code-blocks in the
 >> emacs-buffer is fine, but the html-export only works nice in case of
 >> using :noweb yes, the no-export option screws up syntax highlighting in
 >> the html-output (two screenshots included).
 >> 
 >> I understood that htmlize is used for html-export and that it honours
 >> the faces in the emacs-buffer. It seems as if htmlize doesn't do this
 >> after encountering the '>>' token.

 > Your example works fine for me on latest org master.  Can you send your
 > org version?  (M-x org-version)  What happens if you insert the code for
 > t1 into an sh-mode buffer: is it highlighted as expected?

 > -- 
 > Aaron Ecay


-- 
Snow B.V.

Re: [O] footnotes position in html export

[Rasmus]

Hi Orm,

Orm Finnendahl  writes:

>  when exporting an org-file to html using org-mode.js, the footnotes
> appear at the end of the document.

I don't think we maintain an org-mode.js.  Are you talking about Mooz's
org-js project?  Or ox-html.el?

> I'd rather have the footnotes at the end of each section. As far as I
> understand, this can be achieved by distributung the different
> sections to different .org documents and including those from a master
> document.

I guess so, but only if exported to different documents.  #+include merges
the documents before starting the transcoding.

> Unfortunately in my document are many sections which are rather short
> and I'd prefer to keep them in a single document. Does anybody know of
> a way to achieve this? I couldn't find anything related to that on the
> web.

I think this is not possible.  See org-html-inner-template.

Greetings from Nordend,
Rasmus

-- 
⠠⠵

[O] Using orgstruct-mode (or just org-cycle) in emacs-lisp-mode

[Jonas Bernoulli]

Hello,

Until a few months ago I was able to use `org-cycle' in
`emacs-lisp-mode' buffers, and it just worked after turning on
`outline-minor-mode' but not `orgstruct-mode'.  I am using the
development versions of both Emacs (25.0.50) and Org (9.0).

But somewhere along the way `org-cycle' partially broke when used like
this.  When switching to the CHILDREN state I now see this:

  ;;; heading
  
  ...
  ;;; next heading

instead of (when there is only code in the section)

  ;;; heading
  
  (defun foo ()...
  (defun bar ()...
  ;;; next heading

or (when there are subheadings)

  ;;; heading
   sub-heading one...
   sub-heading two...
  ;;; next heading

I would like to use `orgstruct-mode' in `emacs-lisp-mode' but I cannot
get it to work at all.  So for now I would be happy if I could just use
`org-cycle' as I used to.

Finally I have gotten around to investigate this and came across this:

  ;; This is done in `emacs-lisp-mode':
  (setq-local outline-regexp ";;;\\(;* [^ \t\n]\\|###autoload\\)\\|(")

  (defun lisp-outline-level ()
"Lisp mode `outline-level' function."
(let ((len (- (match-end 0) (match-beginning 0
  (if (looking-at "(\\|;;;###autoload")
  1000
len)))

This doesn't make any sense to me.  Maybe these values now take the
needs of `orgstruct-mode' into account, but when thinking just of
`outline-minor-mode', then I would expect something like this instead:

  (setq-local outline-regexp "\\(;;;+ \\)\\|(")

  (defun lisp-outline-level ()
(cond ((match-beginning 1) (- (length (match-string 1)) 2))
  ((match-beginning 0) 6)))

In addition to that I also had to add this for `org-cycle' to work in
`emacs-lisp-mode' again.

  (add-hook 'org-cycle-hook 'org-cycle-elisp-kludge)
  
  (defun org-cycle-elisp-kludge (state)
(when (and (eq state 'children)
   (derived-mode-p 'emacs-lisp-mode))
  (save-excursion
(goto-char eoh)
(beginning-of-line)
(outline-show-branches
  
  (defun org-before-first-heading-p ()
(if (derived-mode-p 'emacs-lisp-mode)
nil ; in that mode the below always return t
  (save-excursion
(end-of-line)
(null (re-search-backward org-outline-regexp-bol nil t)

Now, I am probably barking at the wrong tree here, but since I also
couldn't get `orgstruct-mode' to work at all, I just investigated the
code which I still somewhat understood, `orgstruct-setup' et al is
beyond me.

So I guess my questions are:

1. In what way does the default value of `outline-regexp' and the
   definition of `lisp-outline-level' make sense?

2. How do I get from `emacs -Q' to TAB on a heading in `emacs-lisp-mode'
   cycling though the tree states (with or without `orgstruct-mode').

The Org manual sais this:

>   You can also use Org structure editing to fold and unfold headlines
> in _any_ file, provided you defined ‘orgstruct-heading-prefix-regexp’:
> the regular expression must match the local prefix to use before Org’s
> headlines.  For example, if you set this variable to ‘";; "’ in Emacs
> Lisp files, you will be able to fold and unfold headlines in Emacs Lisp
> commented lines.  Some commands like ‘org-demote’ are disabled when the
> prefix is set, but folding/unfolding will work correctly.

At least for me that wasn't the case at all (what keys do I have to
press to do the folding/unfolding?).

  Thanks for your help,
  Jonas

Re: [O] footnotes position in html export

[Rasmus]

Hi,

Orm Finnendahl  writes:

> Am Sonntag, den 08. November 2015 um 12:10:59 Uhr (+0100) schrieb Rasmus:
>> 
>> I don't think we maintain an org-mode.js.  Are you talking about Mooz's
>> org-js project?  Or ox-html.el?
>
> sorry, I meant "org-info.js"

OK.  I haven't used it for years.  Skimming ox-html, no code in  is
changed based on info.js.

>> I think this is not possible.  See org-html-inner-template.
>> 
>
> ok, thanks. I'll look into it. Maybe it's not too hard to
> implement. The org manual has footnotes on every page if it is
> exported into different documents. Is there any information somewhere
> about how the org manual html pages were generated? I couldn't
> find the sources of the manual. Are they available somewhere?

The manual is generated via texinfo.  You can check doc/Makefile

I guess the difference between

http://orgmode.org/org.html

and

http://orgmode.org/manual/

is whether the --no-split was issued to texinfo.

The Magit-2 manual is generated from Org via ox-texinfo.el.

>> Greetings from Nordend,
>
> I'm also in Nordend, but that's a part of Frankfurt, Germany ;-)

That was the intended reference.

Rasmus

-- 
Hvor meget poesi tror De kommer ud af et glas isvand?

Re: [O] Lexical binding bug in org-list.el?

[Nicolas Goaziou]

Aaron Ecay  writes:

> I don’t think we should unit-test only public API functions.

I didn't say that. However, I wouldn't write tests for "--" functions.

> Indeed, I find it easier to write unit tests for small functions,
> since I don’t have to construct a lot of extra context to exercise all
> the corner cases.

That's not my point. However I'd rather spent my time elsewhere than
writing tests for worker functions.

>>> In view of this, do you think it would be desirable in the long term to
>>> refactor code like this into top-level functions?
>> 
>> No, I don't. I see no reason to pollute name space with these very
>> specific functions.
>
> I’m not sure I get it – interned symbols are cheap, and with the new-ish
> double-dash convention for private functions users/downstream developers
> can be pretty sure they don’t need to worry about them.

I see no reason to define at top level a worker function with a very
limited scope. Much like let bindings I find it much clearer to keep the
scope of a function as close as possible to its real use, as long as the
function isn't too large. If one day, it is deemed useful in another
function, then it can be lifted to top level.

Anyway, this we're really nitpicking. There's nothing fundamentally
wrong in either choice.

>>   - change `org-list-parse-list' to provide a simpler output and update
>> Babel should to use that new output.

So the new output could be

  plain-list = (type item+)
  type = ordered | unordered | descriptive
  item = ((text|plain-list)+)

Thus,

  1. first item
 + sub-item one
 + [X] sub-item two
 more text in first item
  2. [@3] last item

is parsed as

  (ordered
   ("first item"
(unordered
 ("sub-item one")
 ("[X] sub-item two"))
"more text in first item")
   ("[@3] last item"))

The slightly tricky part is taking care of the indentation when text
contains more than one line.

Also, for completeness, a descriptive list, e.g.,

  - tag :: text

would be simply parsed as

  (descriptive ("tag :: text"))

The objective is to make this syntax easy to create programmatically,
e.g. for Babel. Making something out of it would be the goal of
`org-list-to-generic'.

WDYT?

>>   - re-implement `org-list-to-subtree' using directly Elements, or even
>> string massaging.
>
> OK, these both sound do-able.

Meanwhile, I fixed the current issue. It is as ugly as before, but at
least, no error is thrown anymore.

>>   - start a poll on the ML to guess the potential user base for radio
>> lists. Depending on the results, we might either deprecate the whole
>> thing, as you suggest, or implement in a more powerful and clean
>> way. Note that first item implies `org-list-to-generic' should be
>> updated to handle new output for `org-list-parse-list'.

Having slept over the idea, I think we could simply update
`org-list-to-generic' to be more robust and be done with it. I can
implement it in a couple of hours (and debug it in a couple of
months...).


Regards,

Re: [O] Conditional link export?

[Oleh Krehel]

Nicolas Goaziou  writes:

> Oleh Krehel  writes:
>
>> Is that a new feature?
>
> It is probably almost as old as Babel itself.
>
>> First time I've heard about it, and I did google
>> for inline code block evaluation before.
>
> You should check the Org manual first: 
>
>   (info "(org) Structure of code blocks")

OK, I was looking at
http://orgmode.org/manual/Exporting-code-blocks.html instead.


>
>> In any case, the HTML export result of e.g. this:
>>
>> The current time is: src_emacs-lisp{(format "%s"
>> "http://google.com; (format-time-string "%H:%M"))}.
>>
>> is:
>>
>> The current time is: a href"> href="http://google.com/;>http://google.com/"15:50/a=.
>>
>> which is far from what I want.
>
> Try
>
> The current time is: src_emacs-lisp[:results html]{(format " href=%S>%s" "http://google.com; (format-time-string "%H:%M"))}.

This is quite restrictive, since it implies that I want to export to
HTML. What I really want is to insert a raw string, with no further
processing into the export, whatever format the export may have.

>> And I still think that Elisp could benefit from privileged call
>> syntax. Compare:
>>
>> !(foo)
>>
>> to
>>
>> src_emacs-lisp{(foo)}
>
> I'm not a big fan of redundant syntax. Also, I'm trying to move Org
> format out of Elisp's grasp. This doesn't help much either.

I think it's better to have people use !(foo) than to be turned away by
src_emacs-lisp[:results html]{(foo)} and use nothing at all.  Besides,
Elisp is a very strong library for Org. We could also have e.g.

#+INLINE_LANG Elisp

to set the language for !() in the current document.

>> Additionally `org-edit-src-code' doesn't work for these blocks.
>
> Do you want to provide a patch for it?

I could provide a patch for `org-edit-src-code' to work with !().  I'm
not interested in using the current inline syntax.  I'll implement the
!(progn (foo) (bar)) style for my config anyway, then it's up to you
whether you'll want to merge it or not.

[O] patch for adding some dutch translations in ox.el

[Joost Helberg]

ls,

attached is a patch for org-mode (pulled 15 minutes ago) which will
change the defconst org-export-dictionary in lisp/ox.el only:

  add Dutch translations for some (12) export-labels (like List of
  Tables etc.) and adds a "List of Figures" label with the Dutch
  translation.

The patch for getting the list of figures into exported HTML will come
later.

>From c3dbd57fc1536816a15b430139155ed9ac54a8c9 Mon Sep 17 00:00:00 2001
From: Joost Helberg 
Date: Sun, 8 Nov 2015 14:01:34 +0100
Subject: [PATCH] added some Dutch translations and added List of Figures as a
 label to be translated

---
 lisp/ox.el | 14 ++
 1 file changed, 14 insertions(+)

diff --git a/lisp/ox.el b/lisp/ox.el
index a37de04..acf88e4 100644
--- a/lisp/ox.el
+++ b/lisp/ox.el
@@ -5500,6 +5500,7 @@ them."
  ("et" :html "Vrrand" :utf-8 "Võrrand")
  ("fr" :ascii "Equation" :default "Équation")
  ("ja" :default "方程式")
+ ("nl" :default "Vergelijking")
  ("no" :default "Ligning")
  ("nb" :default "Ligning")
  ("nn" :default "Likning")
@@ -5514,6 +5515,7 @@ them."
  ("es" :default "Figura")
  ("et" :default "Joonis")
  ("ja" :default "図" :html "")
+ ("nl" :default "Figuur")
  ("no" :default "Illustrasjon")
  ("nb" :default "Illustrasjon")
  ("nn" :default "Illustrasjon")
@@ -5528,6 +5530,7 @@ them."
  ("et" :default "Joonis %d:")
  ("fr" :default "Figure %d :" :html "Figure%d:")
  ("ja" :default "図%d: " :html "%d: ")
+ ("nl" :default "Figuur %d")
  ("no" :default "Illustrasjon %d")
  ("nb" :default "Illustrasjon %d")
  ("nn" :default "Illustrasjon %d")
@@ -5568,6 +5571,7 @@ them."
  ("et" :default "Loendite nimekiri")
  ("fr" :default "Liste des programmes")
  ("ja" :default "ソースコード目次")
+ ("nl" :default "Broncode")
  ("no" :default "Dataprogrammer")
  ("nb" :default "Dataprogrammer")
  ("ru" :html " "
@@ -5580,6 +5584,7 @@ them."
  ("et" :default "Tabelite nimekiri")
  ("fr" :default "Liste des tableaux")
  ("ja" :default "表目次")
+ ("nl" :default "Tabellen")
  ("no" :default "Tabeller")
  ("nb" :default "Tabeller")
  ("nn" :default "Tabeller")
@@ -5588,6 +5593,8 @@ them."
   :utf-8 "Список таблиц")
  ("sv" :default "Tabeller")
  ("zh-CN" :html "" :utf-8 "表格目录"))
+("List of Figures"
+ ("nl" :default "Figuren"))
 ("Listing"
  ("da" :default "Program")
  ("de" :default "Programmlisting")
@@ -5595,6 +5602,7 @@ them."
  ("et" :default "Loend")
  ("fr" :default "Programme" :html "Programme")
  ("ja" :default "ソースコード")
+ ("nl" :default "Broncode")
  ("no" :default "Dataprogram")
  ("nb" :default "Dataprogram")
  ("pt_BR" :default "Listagem")
@@ -5608,6 +5616,7 @@ them."
  ("et" :default "Loend %d")
  ("fr" :default "Programme %d :" :html "Programme%d:")
  ("ja" :default "ソースコード%d:")
+ ("nl" :default "Broncode")
  ("no" :default "Dataprogram %d")
  ("nb" :default "Dataprogram %d")
  ("pt_BR" :default "Listagem %d")
@@ -5617,6 +5626,7 @@ them."
 ("References"
  ("fr" :ascii "References" :default "Références")
  ("de" :default "Quellen")
+ ("nl" :default "Bronnen")
  ("es" :default "Referencias"))
 ("See section %s"
  ("da" :default "jævnfør afsnit %s")
@@ -5625,6 +5635,7 @@ them."
  ("et" :html "Vaata peatkki %s" :utf-8 "Vaata peatükki %s")
  ("fr" :default "cf. section %s")
  ("ja" :default "セクション %s を参照")
+ ("nl" :default "Zie sectie %s")
  ("pt_BR" :html "Veja a seo %s" :default "Veja a seção %s"
   :ascii "Veja a secao %s")
  ("ru" :html ".  %s"
@@ -5636,6 +5647,7 @@ them."
  ("et" :default "Tabel")
  ("fr" :default "Tableau")
  ("ja" :default "表" :html "")
+ ("nl" :default "Tabel")
  ("pt_BR" :default "Tabela")
  ("ru" :html ""
   :utf-8 "Таблица")
@@ -5647,6 +5659,7 @@ them."
  ("et" :default "Tabel %d")
  ("fr" :default "Tableau %d :")
  ("ja" :default "表%d:" :html "%d:")
+ ("nl" :default "Tabel %d")
  ("no" :default "Tabell %d")
  ("nb" :default "Tabell %d")
  ("nn" :default "Tabell %d")
@@ -5688,6 +5701,7 @@ them."
  ("et" :default "Tundmatu viide")
  ("fr" :ascii "Destination inconnue" :default "Référence inconnue")
  ("ja" :default "不明な参照先")
+ ("nl" :default "Onbekende verwijzing")
  ("pt_BR" :default "Referência desconhecida"
   :ascii "Referencia desconhecida")
  ("ru" :html " "
-- 
1.9.1


regards,

Joost Helberg

-- 
Snow B.V.

Re: [O] footnotes position in html export

[Nicolas Goaziou]

Hello,

Orm Finnendahl  writes:

> ok, thanks. I'll look into it. Maybe it's not too hard to
> implement.

It shouldn't. Basically, you need to:

  1. Add an optional argument to `org-html-footnote-section' specifying
 the scope of footnotes, skip
 `org-export-collect-footnote-definitions' altogether and use
 `org-element-map' to find "first footnotes references" (see
 `org-export-footnote-first-reference-p') in the scope.

 Then with `org-export-get-footnote-definition', you can build the
 footnote section.

  2. Call `org-html-footnote-section' from `org-html-section', with the
parent headline, if any, or the current section otherwise as the
current scope.

  3. Create a new variable to toggle behaviour of footnotes.

HTH,

Regards,

-- 
Nicolas Goaziou

Re: [O] Conditional link export?

[Nicolas Goaziou]

Oleh Krehel  writes:

> Nicolas Goaziou  writes:
>
>> The current time is: src_emacs-lisp[:results html]{(format "> href=%S>%s" "http://google.com; (format-time-string "%H:%M"))}.
>
> This is quite restrictive, since it implies that I want to export to
> HTML. What I really want is to insert a raw string, with no further
> processing into the export, whatever format the export may have.

Then use [:results raw]. This is also in the manual.

> I think it's better to have people use !(foo) than to be turned away by
> src_emacs-lisp[:results html]{(foo)} and use nothing at all.

You don't have to write [:results html] or [:results raw] for every
inline block you write. You can set the results per subtree, per
document, or globally. So really, it boils down to:

  src_emacs-lisp{(foo)}

You can even define a macro for that

  #+MACRO: eval src_emacs-lisp[:results raw]{($1)}

  {{{eval(foo)}}}

even less characters.

> Besides, Elisp is a very strong library for Org. We could also have
> e.g.
>
> #+INLINE_LANG Elisp
>
> to set the language for !() in the current document.

Again, having duplicate syntax is out of question, IMO. I don't think
the current one is hideous either. With all due respect, the fact that
you don't like it is really insufficient as a justification for
introducing a special alternate syntax.

>> Do you want to provide a patch for it?
>
> I could provide a patch for `org-edit-src-code' to work with !().  I'm
> not interested in using the current inline syntax.

Too bad, then.


Regards,

Re: [O] footnotes position in html export

[Orm Finnendahl]

Am Sonntag, den 08. November 2015 um 12:10:59 Uhr (+0100) schrieb Rasmus:
> 
> I don't think we maintain an org-mode.js.  Are you talking about Mooz's
> org-js project?  Or ox-html.el?

sorry, I meant "org-info.js"

> 
> I think this is not possible.  See org-html-inner-template.
> 

ok, thanks. I'll look into it. Maybe it's not too hard to
implement. The org manual has footnotes on every page if it is
exported into different documents. Is there any information somewhere
about how the org manual html pages were generated? I couldn't
find the sources of the manual. Are they available somewhere?

> Greetings from Nordend,

I'm also in Nordend, but that's a part of Frankfurt, Germany ;-)

Orm

Re: [O] patch for adding some dutch translations in ox.el

[Nicolas Goaziou]

Hello,

Joost Helberg  writes:

> attached is a patch for org-mode (pulled 15 minutes ago) which will
> change the defconst org-export-dictionary in lisp/ox.el only:
>
>   add Dutch translations for some (12) export-labels (like List of
>   Tables etc.) and adds a "List of Figures" label with the Dutch
>   translation.
>
> The patch for getting the list of figures into exported HTML will come
> later.

Thank you.

However, I suggest to remove the translation of "List of Figures" from
this patch, since the feature itself doesn't exist yet. You can add it
in the second patch.

The commit message needs to specify the defconst modified. E.g.,

  ox: Add dutch translations

  * lisp/org-list.el (org-list-parse-list): Added some Dutch
translations.


Regards,

-- 
Nicolas Goaziou

Re: [O] Using orgstruct-mode (or just org-cycle) in emacs-lisp-mode

[Jonas Bernoulli]

Nicolas Goaziou  writes:

> `orgstruct-mode' really needs some love.

It's really hard to understand what is going on for someone not familiar
with the Org code.  Furthermore I am not using the default Emacs
bindings (but I also tested with emacs -Q), so code that generates
commands and bindings, like `outstruct-setup' does, always makes me
uncomfortable, as it usually isn't flexible enough to deal with heavily
modified bindings.

> Anyway, I pushed a fix for the issue.

Thanks.  But could you please change it to

  (if (or outline-minor-mode orgstruct-mode)
  (call-interactively #'show-children)
...)

`outline-minor-mode' combined with `org-cycle' gives me the feature I
*really* want/need.  `orgstruct-mode' sounds like it could be really
useful too, but as I mentioned it doesn't work for me at all.  So for
now I would like to stick to just `outline-minor-mode'.

  Thanks
  Jonas

Ps: I am still not sure whether I am just doing something stupid or why
else `orgstruct-mode' doesn't work for me.  So I would apprechiate a
little tutorial starting from emacs -Q that demonstrates what setup
is required and what keys I have to press for things to happen.

Re: [O] Using orgstruct-mode (or just org-cycle) in emacs-lisp-mode

[Aaron Ecay]

Hi Jonas,

2015ko azaroak 8an, Jonas Bernoulli-ek idatzi zuen:
> 
> `outline-minor-mode' combined with `org-cycle' gives me the feature I
> *really* want/need.

Thorsten Jolitz wrote the outshine library to provide something like
this.  Sadly it’s not actively maintained ATM, but I believe it still
works fine, and it may be an alternative route towards the features you
are looking for.

The package is on github: .  It’s also
available through melpa.

-- 
Aaron Ecay

Re: [O] patch for adding some dutch translations in ox.el

[Joost Helberg]

Nicolas,

will do. I should have read the contribution page a but more carefull.

regards,

Joost

> "Nicolas" == Nicolas Goaziou  writes:
 > From: Nicolas Goaziou 
 > To: Joost Helberg 
 > Cc: emacs-orgmode@gnu.org
 > Subject: Re: patch for adding some dutch translations in ox.el
 > Date: 2015-11-08T15:34:39+0100

 > Hello,

 > Joost Helberg  writes:

 >> attached is a patch for org-mode (pulled 15 minutes ago) which will
 >> change the defconst org-export-dictionary in lisp/ox.el only:
 >> 
 >> add Dutch translations for some (12) export-labels (like List of
 >> Tables etc.) and adds a "List of Figures" label with the Dutch
 >> translation.
 >> 
 >> The patch for getting the list of figures into exported HTML will come
 >> later.

 > Thank you.

 > However, I suggest to remove the translation of "List of Figures" from
 > this patch, since the feature itself doesn't exist yet. You can add it
 > in the second patch.

 > The commit message needs to specify the defconst modified. E.g.,

 >   ox: Add dutch translations

 >   * lisp/org-list.el (org-list-parse-list): Added some Dutch
 > translations.


 > Regards,

 > -- 
 > Nicolas Goaziou


-- 
Snow B.V.

Re: [O] Changes to contrib

[Aaron Ecay]

Hi Rasmus,

2015ko azaroak 8an, Rasmus-ek idatzi zuen:

[...]

> 
> Do you have signed FSF papers?  I don't know if there's any desire to move
> ox-taskjuggler.el to core, nor whether it would be possible (since I don’t
> know if "tj" and Baptiste have signed FSF papers).
> 

[...]

> Also, you introduce a dependency on subr-x, which may or may not be an
> issue since it’s in contrib.

FWIW, my impression of the way contrib is handled is that copyright
assignment is not required, though it is strongly encouraged to leave
open the possibility of moving a package to core.  Similarly, the
restrictions on emacs version support in org core do not apply.

This is just what I’ve surmised from observation, thoguh.  Others can
speak more informatively than me.

(I do like this system since it allows org-related packages to be
effectively community-maintained, and different people take on their
maintenance at different times, as we see here.  I’d be happy if of
the org-related packages on github were migrated to contrib, so that
they don’t bitrot when their original authors move on.  One thing that
might help with that is if we could provide an ELPA repo with the
individual contrib packages, though I’ve no idea how complex that task
would be.)

-- 
Aaron Ecay

Re: [O] Using orgstruct-mode (or just org-cycle) in emacs-lisp-mode

[Jorge A. Alfaro-Murillo]

Jonas Bernoulli writes:

`orgstruct-mode' sounds like it could be really useful too, but 
as I mentioned it doesn't work for me at all.  So for now I 
would like to stick to just `outline-minor-mode'. 


  Thanks
  Jonas 

Ps: I am still not sure whether I am just doing something stupid 
or why else `orgstruct-mode' doesn't work for me.  So I would 
apprechiate a little tutorial starting from emacs -Q that 
demonstrates what setup is required and what keys I have to 
press for things to happen. 


Generally it is enough to set orgstruct-heading-prefix-regexp and 
turn-on-orgstruct. I do this on a per mode basis, for example:


#+BEGIN_SRC emacs-lisp
 (add-hook 'elisp-mode-hook 'turn-on-orgtbl)
 (add-hook 'elisp-mode-hook
   (lambda ()
   (setq-local orgstruct-heading-prefix-regexp
   ";; ")))
#+END_SRC

Then you can organize your code using

;; * section-name

;; ** subsection-name

and folding with TAB, shift-TAB, etc will work when you are in 
those lines.


To use lists you just have to start a line with -, +, 1., etc and 
then lists keybindings work, for example M-C-m for new items. I do 
not know why lists do not respect orgstruct-heading-prefix-regexp, 
it has always seem weird to me that I cannot gain orgstruct 
functionality with something like:


;; - first item
;; - second item

--
Jorge.

Re: [O] Conditional link export?

[Aaron Ecay]

Hi Oleh,

2015ko azaroak 8an, Oleh Krehel-ek idatzi zuen:
> 
> Aaron Ecay  writes:
> 
>> Extra elisp inside the org file is an important way of extending the
>> power of org markup.  Why don’t you want to use it?
> 
> Including boilerplate Elisp, all subtly different into each markup
> document, just to extend the markup with the syntax that it should have
> in the first place anyway. Doesn't that sound bad to you?
> 
> One-off Elisp inclusions relevant to a single document are great and
> powerful, but adding boilerplate code, usually more of it that the whole
> sum of the markup, doesn't sound great at all.  This could be rectified
> somewhat by using `require', but then we don't have a self-contained
> document any more. Which is important to facilitate sharing and re-use
> of Org-mode documents.

I’m not sure I understand you.  You’re against putting elisp into the
document, but that seems like the main thrust of your proposal.  You
also want self-contained documents, but insofar as these rely on new
features being added to org, they will introduce dependencies on
specific org versions, which is an potential obstacle to sharing and
reuse.

> 
>> Not in general.  For small pieces of text, you can use macros.
>> Something like:
>> 
>> #+macro: ifinfo (eval (if (org-export-derived-backend 
>> org-export-current-backend 'info) "$1" "$2"))
>> 
>> {{{ifinfo([[info:emacs#Pachages]],[[https://]])}}}
> 
> The macro definition and call syntax looks very ugly.

For aesthetic considerations when editing, check out
‘org-hide-macro-markers’.

I think Nicolas gave you very thorough responses to the rest of your
proposal.  Just a one more additional comment.

[...]

> 2. Something like `ox-link' isn't built-in.

Thorsten Jolitz’s org-dp library might provide you a base on which to
build such functions, if you’re motivated.
.  The readme is a little dense IMO (the
docstrings are better), but you should be able to do something like:

(defun ox-link (dest)
  (let* ((elements (split-string dest ":"))
 (type (nth 0 elements))
 (path (mapconcat #'identity (cdr elements) ":")))
(org-dp-create 'link nil nil
   :type type
   :path path)))

If you build a library of such functions and they prove useful, we could
put them in org-contrib and (eventually perhaps) into core.

Hope this is helpful,

-- 
Aaron Ecay

Re: [O] Bug: org-batch-agenda will not search for tags of length 2 [8.3.2 (8.3.2-10-g00dacd-elpaplus @ /Users/cg/.emacs.d/elpa/org-plus-contrib-20151005/)]

[Nicolas Goaziou]

Hello,

Christoph Gaitzsch  writes:

> Calling e.g. (org-batch-agenda 'ab') will report "Invalid agenda key"
> instead of printing headlines with tag "ab".
>
> To fix, change the macro line 10 to
>
> (defmacro org-batch-agenda (cmd-key  parameters)
>   "Run an agenda command in batch mode and send the result to STDOUT.
> If CMD-KEY is a string of length 1, it is used as a key in
> `org-agenda-custom-commands' and triggers this command.  If it is a
> longer string it is used as a tags/todo match string.
> Parameters are alternating variable names and values that will be bound
> before running the agenda command."
>   (org-eval-in-environment (org-make-parameter-alist parameters)
> (let (org-agenda-sticky)
>   (if (> (length cmd-key) 1)  ;; CHANGE HERE TO 1 
> (org-tags-view nil cmd-key)
>   (org-agenda nil cmd-key
>   (set-buffer org-agenda-buffer-name)
>   (princ (buffer-string)))

Applied. Thank you.

Regards,

-- 
Nicolas Goaziou

Re: [O] Changes to contrib

[Rasmus]

Hi Aaron,

Aaron Ecay  writes:

> Hi Rasmus,
>
> 2015ko azaroak 8an, Rasmus-ek idatzi zuen:
>
> [...]
>
>> 
>> Do you have signed FSF papers?  I don't know if there's any desire to move
>> ox-taskjuggler.el to core, nor whether it would be possible (since I don’t
>> know if "tj" and Baptiste have signed FSF papers).
>> 
>
> [...]
>
>> Also, you introduce a dependency on subr-x, which may or may not be an
>> issue since it’s in contrib.
>
> FWIW, my impression of the way contrib is handled is that copyright
> assignment is not required, though it is strongly encouraged to leave
> open the possibility of moving a package to core.  Similarly, the
> restrictions on emacs version support in org core do not apply.

AFAIK: this is correct.  But we can't move a package from contrib to core
if significant parts are written by authors without assigned copyright.
As I said, I don’t know what a taskjuggler is, so I don’t know how
relevant that consideration is here.

> (I do like this system since it allows org-related packages to be
> effectively community-maintained, and different people take on their
> maintenance at different times, as we see here.

Indeed.  But it has a risk if contrib is thought of as a staging area.
Again, I guess this should be done on a case-by-case basis.

> I’d be happy if of the org-related packages on github were migrated to
> contrib, so that they don’t bitrot when their original authors move on.

I agree with you, but others want to move stuff out of contrib.

Rasmus

-- 
m-mm-mmm- bacon!

[O] Bug: org-batch-agenda will not search for tags of length 2 [8.3.2 (8.3.2-10-g00dacd-elpaplus @ /Users/cg/.emacs.d/elpa/org-plus-contrib-20151005/)]

[Christoph Gaitzsch]

Remember to cover the basics, that is, what you expected to happen and
what in fact did happen.  You don't know how to make a good report?  See

 http://orgmode.org/manual/Feedback.html#Feedback

Your bug report will be posted to the Org-mode mailing list.


Calling e.g. (org-batch-agenda 'ab') will report "Invalid agenda key"
instead of printing headlines with tag "ab".

To fix, change the macro line 10 to

(defmacro org-batch-agenda (cmd-key  parameters)
  "Run an agenda command in batch mode and send the result to STDOUT.
If CMD-KEY is a string of length 1, it is used as a key in
`org-agenda-custom-commands' and triggers this command.  If it is a
longer string it is used as a tags/todo match string.
Parameters are alternating variable names and values that will be bound
before running the agenda command."
  (org-eval-in-environment (org-make-parameter-alist parameters)
(let (org-agenda-sticky)
  (if (> (length cmd-key) 1)  ;; CHANGE HERE TO 1 
  (org-tags-view nil cmd-key)
(org-agenda nil cmd-key
  (set-buffer org-agenda-buffer-name)
  (princ (buffer-string)))

Emacs  : GNU Emacs 24.5.1 (x86_64-apple-darwin15.0.0, NS apple-appkit-1404.13)
 of 2015-11-07 on hal9000.local
Package: Org-mode version 8.3.2 (8.3.2-10-g00dacd-elpaplus @ 
/Users/cg/.emacs.d/elpa/org-plus-contrib-20151005/)

Re: [O] Lexical binding bug in org-list.el?

[Aaron Ecay]

Hi Nicolas,

2015ko azaroak 8an, Nicolas Goaziou-ek idatzi zuen:

[...]

> Anyway, this we're really nitpicking. There's nothing fundamentally
> wrong in either choice.

You’re right, and I’m not trying to be quarrelsome.  At least for me,
it’s helpful to understand the perspective on things like this, so I can
try to model what is normative guidance and what is not.  Thanks for
humoring me.

> 
>>> - change `org-list-parse-list' to provide a simpler output and update
>>> Babel should to use that new output.
> 
> So the new output could be

[...] details elided

> 
> WDYT?

LGTM.  I’ve probably met my quota of org-related fun for the day (see
below...), but implementing this in terms of elements will be my next
org-list related task.

> 
>>> - re-implement `org-list-to-subtree' using directly Elements, or even
>>> string massaging.

It’s obvious to me that string-massaging causes friction in parts of
org’s code, so I’d like to try a different approach here.  The attached
patch makes a stab at doing the reimplementation in terms of elements.
I think it came out rather nicely, but I’d really value hearing your
opinion on it.

It’s very lightly tested so far.  I basically just used the following
snippet as a test case: put it in an org-mode buffer, put your cursor
somewhere inside the list, and M-: (org-list-to-subtree2)

- foo
- *bar*
  blorfle
- [X] baz
  - quux
  - 123

> Having slept over the idea, I think we could simply update
> `org-list-to-generic' to be more robust and be done with it. I can
> implement it in a couple of hours (and debug it in a couple of
> months...).

OK.  Don’t hesitate to ask if there’s some way we can help, of course.

Thanks,

-- 
Aaron Ecay
>From 2c41ae7704c133086a772b8651a1c3cd67feab78 Mon Sep 17 00:00:00 2001
From: Aaron Ecay 
Date: Sun, 8 Nov 2015 19:37:22 +
Subject: [PATCH] draft implementation of org-list-to-subtree in terms of
 org-element

---
 lisp/org-list.el | 104 +++
 1 file changed, 104 insertions(+)

diff --git a/lisp/org-list.el b/lisp/org-list.el
index 19d5b03..1612e4e 100644
--- a/lisp/org-list.el
+++ b/lisp/org-list.el
@@ -3263,6 +3263,110 @@ syntax.  Return converted list as a string."
   (require 'ox-texinfo)
   (org-export-string-as list 'texinfo t))
 
+(defun org-list--partial-parse-contents (parse)
+  "Get the actual contents of a partial org-mode parse.
+
+Specifically, when parsing a piece of text smaller than a
+headline, `org-element-parse-buffer' wraps its result with a
+dummy `section' element, as well as the standard `org-data'
+wrapper.  This function removes these, returning a list of
+org-elements.
+
+TODO: maybe this needs a more general name."
+  (org-element-contents
+   ;; strip the org-data element
+   (nth 0 (org-element-contents
+	   ;; and the section element
+	   parse
+
+(defun org-list--split-first-line (contents)
+  "Remove the first line of text from an org-element item.
+
+CONTENTS are the contents of the item org-element: at least a
+paragraph followed by zero or more other elements.
+
+Returns a cons of the first textual line and a list of
+org-elements representing the structure of the item minus this
+line.
+
+TODO: is the first daughter of an item always a paragraph?"
+  (let ((graf (nth 0 contents)))
+(unless (eq (org-element-type graf) 'paragraph)
+  (error "`org-list--split-first-line' got confused"))
+(goto-char (org-element-property :begin graf))
+(let* ((eol (point-at-eol))
+	   (end (org-element-property :end graf))
+	   (first-line (buffer-substring-no-properties (point) eol)))
+  (if (> (1+ eol) end)
+	  ;; One line paragraph: it becomes the entirety of the
+	  ;; headline, and we remove it from contents
+	  (setq contents (cdr contents))
+	;; Multi-line paragraph: narrow the buffer to lines 2-N, parse
+	;; them, and set them as the contents of the paragraph.
+	(save-restriction
+	  (widen)
+	  (narrow-to-region (1+ eol) end)
+	  (org-element-set-contents graf
+(org-list--partial-parse-contents
+ ;; TODO: We're playing a trick on
+ ;; the parser here.  AFAICT, the
+ ;; parse does not rely on the
+ ;; cache.  But maybe we should
+ ;; let org-element-use-cache to
+ ;; nil around this call, in case
+ ;; that changes in the future.
+ (org-element-parse-buffer)
+  (cons first-line contents
+
+(defun org-list--item-to-headline (item level)
+  "Convert an org-element list item to a headline.
+
+The first line of the list item becomes the "
+  (unless (eq (car item) 'item)
+(error "`org-list--item-to-headline' expects an item argument"))
+  (let* ((r (org-list--split-first-line (org-element-contents item)))
+	 (title (car r))
+	 (other-contents (cdr r)))
+(list 'headline
+	  `(:level ,level
+		   ,@(when (eq (org-element-property :checkbox item) 'on)
+		   (list :todo-keyword
+			 ;; TODO: how to fish the approporiate
+			 

[O] Rendering quoted HTML outside the last headline's HTML.

[Emanuele Santoro]

Hi there!

I render the org-mode project of my website using HTML export
functions.

I created a three-columns layout by using the Bootstrap
(http://getbootstrap.com/) and by wrapping the first three columns
within a div element of class "row". 

I do this by prepending and appending some static html via the #+HTML
directive, as in:

#+HTML: 

and 

#+HTML: 

Also, I set the HTML_CONTAINER variable to use proper css classes:

#+HTML_CONTAINER: div class="col-md-4"


Now the problems arise:

1) I have noticed that when closing the headline tag, org will generate
a syntactically wrong  tag. Most browser will
ignore such mistakes but it's still annoying.

2) Everything works okay if there are three or less columns. When
adding another column, I close the "row" container and open another
one, by adding

#+HTML: 
#+HTML: 

But this code is rendered within the HTML code of the previous
headline.
In general, it is not clear "where" a piece of HTML will be rendered.
Is there a way to specify that? Is there a way to say, like: "this piece
of HTML is not part of the current headline and should be rendered after
the last headline has been rendered" ?

Thanks in advance,
-- 
Emanuele Santoro

Re: [O] Using link abbrevations for EXPORT_FILE_NAME ?

[Nicolas Goaziou]

Hello,

AW  writes:

> on orgmode 8.3.2 I've got a large org-file. Offen, I need to export a subtree 
> like this:
>
> -
> * Subtree to be exported
> :PROPERTIES:
> :EXPORT_FILE_NAME: /PATH/TO/FOLDER/filename
> :EXPORT_TITLE:
> :END:
>
> foo
>
> -
>
> I'd like to save the exported file in a project folder, as you can see in 
> EXPORT_FILE_NAME .
>
> It would be very helpful to use link abbrevations in EXPORT_FILE_NAME :
>
> (setq org-link-abbrev-alist
>'(("anglisky" . "~/Path/whereever/%s")))
>
> in .emacs and write:
>
> -
> * Subtree to be exported
> :PROPERTIES:
> :EXPORT_FILE_NAME: anglisky:filename
> :EXPORT_TITLE:
> :END:
>
> foo
>
> -
>
> Possible? Feature Request?

Not possible. Also, link syntax sounds awkward because most links
wouldn't make sense there.

What about introducing a new property:

  :EXPORT_FILE_DIRECTORY:

When set, e.g. to "dir", assuming EXPORT_FILE_NAME is set to "foo/file",
export file name becomes "dir/file".

Since you can set it per subtree or document, I think it would help in
your situation.

WDYT?


Regards,

-- 
Nicolas Goaziou

Re: [O] visual-fill-column-mode with org

[Vikas Rawal]

> Another option would be to use auto-fill-mode to keep your text
> paragraphs within your desired width, without affecting tables.
> 

I do not like auto-fill-mode inserting hard returns at fill-column. This 
creates problems for version control, as sentences cannot be correctly 
identified.

I would like each sentence to be on a single line, wrapped only for visual 
effect, without having hard-returns, so that git can correctly identify changes 
in each sentence.

That is the reason I am looking at visual-fill-column-mode.

Joost Kremers, author of visual-fill-column-mode, says that this would not be 
possible since "visual-fill-column-mode does not really do any filling / 
wrapping”.

So, at the moment, we really do not have any appropriate solution.

Vikas

Re: [O] visual-fill-column-mode with org

[Vikas Rawal]

> Another option would be to use auto-fill-mode to keep your text
> paragraphs within your desired width, without affecting tables.
> 

I do not like auto-fill-mode inserting hard returns at fill-column. This 
creates problems for version control, as sentences cannot be correctly 
identified.

I would like each sentence to be on a single line, wrapped only for visual 
effect, without having hard-returns, so that git can correctly identify changes 
in each sentence.

That is the reason I am looking at visual-fill-column-mode.

Joost Kremers, author of visual-fill-column-mode, says that this would not be 
possible since "visual-fill-column-mode does not really do any filling / 
wrapping”.

So, at the moment, we really do not have any appropriate solution.

Vikas

Re: [O] Minor regression

[Kyle Meyer]

Hello,

Simon Thum  writes:

> Hi all,
>
> I have a strange symptom when trying to add a line behind a SCHEDULED: line:
>
> *** TODO BU
> SCHEDULED: <2016-01-14 Di>x <-- press CR here
>
> I keep getting a message:
>
> user-error: No link found
>
> and cannot insert that line from the point described. I'm on maint
> (54d3032cdcc2c2c30efac41e84ae4ab0543f7ad2, to be precise) and only
> recently noticed this behaviour.

I'm not able to reproduce this on your example.  Are you still having
this issue?

-- 
Kyle

Re: [O] Rendering quoted HTML outside the last headline's HTML.

[Rasmus]

Hi,

Emanuele Santoro  writes:

> Hi there!
>
> I render the org-mode project of my website using HTML export
> functions.
>
> I created a three-columns layout by using the Bootstrap
> (http://getbootstrap.com/) and by wrapping the first three columns
> within a div element of class "row". 
>
> I do this by prepending and appending some static html via the #+HTML
> directive, as in:
>
> #+HTML: 
>
> and 
>
> #+HTML: 
>
> Also, I set the HTML_CONTAINER variable to use proper css classes:
>
> #+HTML_CONTAINER: div class="col-md-4"

Does this do what you want?

* h
:PROPERTIES:
:HTML_CONTAINER_CLASS: col-md-4
:END:
p


> Now the problems arise:
>
> 1) I have noticed that when closing the headline tag, org will generate
> a syntactically wrong  tag. Most browser will
> ignore such mistakes but it's still annoying.
>
> 2) Everything works okay if there are three or less columns. When
> adding another column, I close the "row" container and open another
> one, by adding
>
> #+HTML: 
> #+HTML: 
>
> But this code is rendered within the HTML code of the previous
> headline.
> In general, it is not clear "where" a piece of HTML will be rendered.
> Is there a way to specify that? Is there a way to say, like: "this piece
> of HTML is not part of the current headline and should be rendered after
> the last headline has been rendered" ?

I guess you could use a filter.  Perhaps the cleanest way would be to do
something like the following and use a filter to clean up row.  Perhaps
you could use a function similar to org-export-ignore-headlines in
ox-extra in contrib.

 * row
 :PROPERTIES:
 :HTML_CONTAINER_CLASS: row
 :END:
 ** h
 :PROPERTIES:
 :HTML_CONTAINER_CLASS: col-md-4
 :END:
 p
 ** h
 :PROPERTIES:
 :HTML_CONTAINER_CLASS: col-md-4
 :END:
 p

 ** h
 :PROPERTIES:
 :HTML_CONTAINER_CLASS: col-md-4
 :END:
 p

Hope it helps,
Rasmus

-- 
May contains speling mistake

Re: [O] Minor regression

[Kyle Meyer]

Kyle Meyer  writes:

> Hello,
>
> Simon Thum  writes:
>
>> Hi all,
>>
>> I have a strange symptom when trying to add a line behind a SCHEDULED: line:
>>
>> *** TODO BU
>> SCHEDULED: <2016-01-14 Di>x <-- press CR here
>>
>> I keep getting a message:
>>
>> user-error: No link found
>>
>> and cannot insert that line from the point described. I'm on maint
>> (54d3032cdcc2c2c30efac41e84ae4ab0543f7ad2, to be precise) and only
>> recently noticed this behaviour.
>
> I'm not able to reproduce this on your example.  Are you still having
> this issue?

Doh, please ignore that.  I forgot about this other thread and am
assuming those fixes solved your issue.

http://thread.gmane.org/gmane.emacs.orgmode/102054/focus=102455

-- 
Kyle

[O] Changes to contrib

[Kosyrev Serge]

Good day folks!

I have tried to use ox-taskjuggler and faced what appeared to be a
mountain of.. infelicities and semi-broken functionality.

A need shapes the man, so I plowed through the most direct obstacles,
and finally managed to get what I want from the beast -- mostly by
adding direct Org-property -> TJ-attribute export pathways.

I don't know what is the proper way to submit patches for the contrib/
directory, so I made a branch on github:

  https://github.com/deepfire/org-mode/commits/ox-taskjuggler-fixes

Please, do tell how you would like to proceed from there.

(One immediate nitpick, of course, is that none of the additions
 are documented..)

-- 
с уважениe / respectfully,
Косырев Сергей

Re: [O] visual-fill-column-mode with org

[Vikas Rawal]

> 
>> I would like to use visual-fill-column-mode with my org
>> files. However, this has a peculiar problem that org tables also start
>> wrapping at fill-column. Does anyone use visual-fill-column-mode with
>> org and has found a way of telling it to ignore lines starting with a
>> |?
> 
> Hardly a solution, but you can force columns to only be a certain width
> with the  declaration, where n is an integer.
> 

Reducing width of the table to fill-column is hardly usable. It will not work 
if I zoom in.

Also, I will have to keep doing this for every table. Everything will get more 
complicated if the table is result of a babel code block.

No..

Vikas

Re: [O] Conditional link export?

[Oleh Krehel]

Hi Nicolas,

Nicolas Goaziou  writes:
> There is already inline syntax for any language, including elisp:
>
>   src_emacs-lisp{(foo)}
>
> and, if you use the library of Babel,
>
>   call_foo{}
>
> I don't see the need to add yet another way to call inline code from an
> Org document.

Is that a new feature? First time I've heard about it, and I did google
for inline code block evaluation before.

In any case, the HTML export result of e.g. this:

The current time is: src_emacs-lisp{(format "%s" 
"http://google.com; (format-time-string "%H:%M"))}.

is:

The current time is: a href"http://google.com/;>http://google.com/"15:50/a=.

which is far from what I want.

And I still think that Elisp could benefit from privileged call
syntax. Compare:

!(foo)

to

src_emacs-lisp{(foo)}

No one would quickly forget the first call syntax after using it once,
while the second one is highly forgettable and clumsy.

Additionally `org-edit-src-code' doesn't work for these blocks.

regards,
Oleh

Re: [O] [PATCH] ox-extra.el: Fix filtering of latex header blocks

[Kyle Meyer]

Hello,

Sebastian Christ  writes:

> Hi group,
>
> I'd like to provide a patch to
> ox-extra.el. `org-latex-header-blocks-filter' still calls
> `org-edit-src-find-region-and-lang' and raises therefore an undefined
> function error.

Thanks for the patch.  Sorry for the delayed response.

> * ox-extra.el (org-latex-header-blocks-filter): Use `org-element' API to
>   find begin and end of latex header blocks.

s|ox-extra.el|contrib/lisp/ox-extra.el|
s/begin/beginning/

[...]

>(mapc (lambda (pos)
> -   (goto-char (nth 2 pos))
> -   (destructuring-bind
> -   (beg end  ignore)
> -   (org-edit-src-find-region-and-lang)
> - (let ((contents-lines (split-string
> -(buffer-substring-no-properties beg end)
> -"\n")))
> -   (delete-region (nth 0 pos) (nth 1 pos))
> -   (dolist (line contents-lines)
> - (insert (concat "#+latex_header: "
> - (replace-regexp-in-string "\\` *" "" line)
> - "\n"))
> +  (let* ((beg (third pos))
> + (end (second pos))
> + (post-affiliated (first pos))

Nitpick: nth is more commonly used in the Org code base.

Hmm, the pos items are constructed as

(list (org-element-property :begin block)
  (org-element-property :end block)
  (org-element-property :post-affiliated block)))

so shouldn't beg be the first element and post-affiliated the third?

Hopefully Aaron will get a chance to have a look.

--
Kyle

Re: [O] some org-contacts icons property value questions

[Kyle Meyer]

Hello,

I've never used icons with Org Contacts, but here are my guesses based
on glancing at the code.

stardiviner  writes:

> How to edit the org-contacts property ~:ICON~ value?

You should be able to edit it like you would any other property (e.g.,
manually or with org-set-property).

> I tried use `filename.jpg` which file is in same directory with
> contacts file.

I think it should be a path to a file [1], like you're using.  In the
end, create-image is called with the file.  Can you give specific steps
to reproduce what's not working on your end?  IIUC, icons are only used
when the org-contacts command is called.

> And what kind of image size should I use for icon?

If gnus-rescale-image is available, it will be rescaled to
org-contacts-icon-size x org-contacts-icon-size.

> Can I use a custom function to show this icon?

Do you want to change the way it's inserted in the agenda buffer, or are
you trying to show it in some other context?  If it's the latter, you
could write a command to get the image like org-contacts-icon-as-string
does and then do what you want with it.

> Can I show multiple icons for one contact?

That doesn't seem to be supported.

[1] A gravatar can be used for the icon instead, but that's done based
on the email property.

--
Kyle