Re: [O] Cannot display local images with orgmode under macOS

[Rick Frankel]

On Thu, Sep 12, 2019 at 02:48:15PM +0200, Marco Wahl wrote:
> Hi,
> > Orgmode under macOS cannot display local images correctly, but it can 
> > display internet images
> > without problem.

> > After bisecting org-mode source code I found out that this commit 
> > causes the problem:
> >
> > 
> > https://code.orgmode.org/bzg/org-mode/commit/48da60f47a77f4b99b4160fa620f258896ff4da3
> >
> > Reverting to previous commit fixes the problem.
>
> Gaa!  Looks like I did this.  With the commit one should be able to see
> inline images also in the case when Emacs has been build without
> imagemagick support, at least for newer Emacsens in the 27 line.
>
> Unfortunately I don't have a Mac and cannot examine the behavior you
> describe AFAICS.
>

On a mac, latest org and emacs masters, inline images work find

Org version:

  commit 6f32e7af88805441c1261e16f729172639d8b3fa (HEAD -> master, 
origin/master, origin/HEAD)


Abbreviated emacs config output (no imagemagick):

  What compiler should emacs be built with?   clang -O
  What window system should Emacs use?nextstep
  What toolkit should Emacs use?  none
  Does Emacs use -lXaw3d? no
  Does Emacs use -lXpm?   no
  Does Emacs use -ljpeg?  no
  Does Emacs use -ltiff?  no
  Does Emacs use a gif library?   no
  Does Emacs use a png library?   no
  Does Emacs use -lrsvg-2?yes
  Does Emacs use cairo?   no
  Does Emacs use -llcms2? yes
  Does Emacs use imagemagick? no
  Does Emacs use -lgmp?   yes
  Does Emacs directly use zlib?   yes
  Does Emacs have dynamic modules support?no
  Does Emacs use toolkit scroll bars? yes
  Does Emacs support Xwidgets (requires gtk3)?no

Re: [O] S5 HTML export - org9.1.1

[Rick Frankel]

As the orginal author -- who hasn't looked @ or used ox-s5 in years ;O, just
confirming the patch looks correct to me. I don't think i have commit
privilges anymore (lost that ssh key), so i appreciate your applying it.

thanks,
rick

On Sat, Oct 07, 2017 at 06:51:05PM +, Kyle Meyer wrote:
> dchechi...@gmail.com writes:
> > I have evaluated the following function found in ox-html.el
> > and indeed the S5 html works when this function is defined.
> >
> > (defun org-html-end-plain-list (type)
> >   "Insert the end of the HTML list depending on TYPE."
> >   (case type
> > (`ordered "")
> > (`unordered "")
> > (`descriptive "")))
> 
> Yes, that's the function that was removed in 8855c23c6.
> 
> > I don't know if this function should appear accordly in
> > ox-S5.el or elsewhere. As I don't use development environment
> > I don't know how a patch has to be submitted.
> >
> > Anyway thank for your help. Hope it can be useful for the
> > person who knows how to implement it and where.
> 
> I don't use ox-s5.el, but the I think the below fix should do.  I'll
> push it in a few days if no one objects.
> 
> -- >8 --
> Subject: [PATCH] ox-s5: Don't use org-html-end-plain-list
> 
> * contrib/lisp/ox-s5.el (org-s5-plain-list): Adjust for the removal of
> org-html-end-plain-list.
> 
> The function org-html-end-plain-list was deleted in
> 8855c23c6 (ox-html: Plain list supports arbitrary attributes,
> 2017-02-13).
> 
> Reported-by: 
> 
> ---
>  contrib/lisp/ox-s5.el | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/contrib/lisp/ox-s5.el b/contrib/lisp/ox-s5.el
> index 8f9501058..0496aae19 100644
> --- a/contrib/lisp/ox-s5.el
> +++ b/contrib/lisp/ox-s5.el
> @@ -292,7 +292,8 @@ (defun org-s5-plain-list (plain-list contents info)
>   "<%s class='org-%s%s'>" tag tag
>   (if (org-export-get-node-property :INCREMENTAL plain-list t)
>   " incremental" ""))
> -contents (org-html-end-plain-list type
> +contents
> + (format "" tag
>  
>  (defun org-s5-inner-template (contents info)
>"Return body of document string after HTML conversion.

Re: [O] [RFC] Shrink columns dynamically

[Rick Frankel]

So I haven't posted in a while, but i use table a lot, so here's my $0.02.

Personally, my use of width cookies has been mostly for visual display of
columns are very long and will wrap in an html or latex table export, but
would force the display too wide. My ideal default would be to have a setting
which would shrink tables a reasonable (fill-column?, window-width?) visual
display, with perhaps a min-column-width option and trying to balance the
width of each column base on its un-narrowed total width, perhaps trying to
keep narrow columns as-is in the process. For me this would probably align
cognitively with how much info is needed to grok the cell contents. As to your
behavior questions:

On Wed, Jul 12, 2017 at 12:17:26PM +0200, Nicolas Goaziou wrote:


> - Do we need two commands, one for narrowing (to a given number of
>   characters) and one for shrinking (to one character only)? Or would
>   a command toggling between the three states be sufficient?

I like a single cycling command.

> - Is there some rule of thumb to narrow a column when no width cookie is
>   supplied or should we consider this kind of columns has only two
>   states, shrunk and expanded?

So i think you are saying that a column w/ a width cookie would have three
states and one without only two? I think this in some ways negates the appeal
of separating narrowing from the cookies. Also, my suggested default narrowing
approach above would probably remove the need for cookies in many if not most
cases.

> - Supposing we focus on a single, cycling, command, how should it behave
>   when called on multiple columns at a time? Since some columns may have
>   two states and other ones three, it may end up being confusing for the
>   user.

Wouldn't a min-column-width setting to use when there is no cookie solve the
the bi- vs tri-state problem (every column has three states)

rick

P.S. and (somewhat) off topic: The doc string for
`org-ascii-table-use-ascii-art' is out of date. `ascii-art-to-unicode.el' is
now in elpa and the url no longer works.

Re: [O] [BUG] Inserting new heading

[Rick Frankel]

On Thu, Mar 16, 2017 at 01:03:18PM +0100, Nicolas Goaziou wrote:
> Hello,
> 
> Rick Frankel <r...@rickster.com> writes:
> 
> > There is a bug w/ inserting new headings after a collapsed heading (w/
> > C-return, org-insert-heading-respect-content) if the last content under the
> > heading (or a subhead) is a RESULTS: block. This occurs w/ the value of
> > org-blank-before-new-entry as either '(heading . auto) or '(heading . nil).
> >
> > This started a few months ago, but I just figured out what actually causes 
> > the
> > behavior.

> Fixed. I couldn't reproduce it on maint tho, so the commit landed on
> master branch.

Confirmed in master. Not suprised it wasn't in maint, it's a fairly recent bug.

thanx,
rick

[O] [BUG] Inserting new heading

[Rick Frankel]

There is a bug w/ inserting new headings after a collapsed heading (w/
C-return, org-insert-heading-respect-content) if the last content under the
heading (or a subhead) is a RESULTS: block. This occurs w/ the value of
org-blank-before-new-entry as either '(heading . auto) or '(heading . nil).

This started a few months ago, but I just figured out what actually causes the
behavior.


Given the following org file:

--
* C-return tests
** Results w/ ending blank line removed
#+BEGIN_SRC sh
echo 'foo'
#+END_SRC

#+RESULTS:
: foo
** Results w/ ending blank line
#+BEGIN_SRC sh
echo 'foo'
#+END_SRC

#+RESULTS:
: foo

** A heading
--

Steps to reproduce:

  For "Correct" (expected) results:
1. Collapse all the headings.
2. Place the cursor On the line "Results w/ ending blank line removed".
3. Hit  (org-insert-heading-respect-content)

A new heading is inserted just before the following heading.

  For "Incorrect" results:
1. Collapse all the headings.
2. Place the cursor On the line "Results w/ ending blank line".
3. Hit  (org-insert-heading-respect-content)

The new heading characters ('**') are appended to the end of the result
block (the end of the heading line after the '...')

BTW, if the heading containing the source block is expanded it works correctly.

rick

[O] [PATCH] Update ob-ruby for inf-ruby 2.5

[Rick Frankel]

inf-ruby (melpa stable) has recently been updated to v2.5. The library has
been significantly re-factored, and `run-ruby` no longer accepts `nil` has
the command name. The following patch updates ob-ruby so that it continues
to work w/ inf-ruby v2.5. It should still (untested) work with the previous
version (2.4).


rick

>From aa836b45487e61de6e74b6edde3c07ab5b885eb8 Mon Sep 17 00:00:00 2001
From: Rick Frankel <r...@rickster.com>
Date: Mon, 26 Dec 2016 15:00:32 -0500
Subject: [PATCH] Update ob-ruby for inf-ruby 2.5

 * lisp/ob-ruby.el (org-babel-ruby-initiate-session): `run-ruby` has
   very different semantics in inf-ruby 2.5. Set ruby command to the
   default which used to be set by `run-ruby` and try and find already
   existing buffer before invocation.
---
 lisp/ob-ruby.el | 12 
 1 file changed, 8 insertions(+), 4 deletions(-)

diff --git a/lisp/ob-ruby.el b/lisp/ob-ruby.el
index 6415f354b..e510fc753 100644
--- a/lisp/ob-ruby.el
+++ b/lisp/ob-ruby.el
@@ -150,12 +150,16 @@ If there is not a current inferior-process-buffer in 
SESSION
 then create one.  Return the initialized session."
   (unless (string= session "none")
 (require 'inf-ruby)
-(let ((session-buffer (save-window-excursion
-   (run-ruby nil session) (current-buffer
+(let* ((cmd (cdr (assoc inf-ruby-default-implementation
+   inf-ruby-implementations)))
+  (buffer (get-buffer (format "*%s*" session)))
+  (session-buffer (or buffer (save-window-excursion
+   (run-ruby cmd session)
+   (current-buffer)
   (if (org-babel-comint-buffer-livep session-buffer)
  (progn (sit-for .25) session-buffer)
-(sit-for .5)
-(org-babel-ruby-initiate-session session)
+   (sit-for .5)
+   (org-babel-ruby-initiate-session session)
 
 (defvar org-babel-ruby-eoe-indicator ":org_babel_ruby_eoe"
   "String to indicate that evaluation has completed.")
-- 
2.11.0

Re: [O] [BUG] org-create-formula-image requires 'gs' when it doesn't look like to be necessary (causing issues on Windows)

[Rick Frankel]

On Fri, Nov 11, 2016 at 10:02:00AM -0500, Frederick Giasson wrote:
> > Do you mean that "gs" could be removed from all entries in
> > `org-preview-latex-process-alist'?
> > 
> > I'm Cc'ing Feng Shu, who implemented the new LaTeX preview mechanism. He
> > hopefully knows why this dependency was introduced in the first place.
> 
> I think so yes, at least on Windows (didn't try on Linux nor OSX)

I've checked all three converters on os x as well (but not linux). ghostscript
is included an a dependency for all of them, so won't work on osx w/o
explicitly installing ghostscript, but in fact, work fine w/o it. I am not
sure why it has been set for each converter as a dependency since it does not
seem to be used by any of the conversion chains. As an aside, it is not
mentioned in the documentation (info).


rick

Re: [O] Nested ordered (numbered) lists

[Rick Frankel]

On Sat, Jun 25, 2016 at 10:34:35PM +0300, ST wrote:
> Hi,
> 
> is there a way to produce nested ordered (numbered) lists and get it
> exported (to pdf/html) properly? Like:
> 
> 1. item_1
> 2. item_2
>2.1. subitem_2_1
>   2.1.1. subsubitem_2_1_1
>2.2. subitem_2_2
> 3. item_3

have you tried:

# 
#+LATEX_HEADER_EXTRA: \usepackage{enumitem} 
\setlist[enumerate]{label*=\arabic*.}

* Numbered lists
1. item_1
2. item_2
   1. subitem_2_1
   1. subsubitem_2_1_1
   2. subitem_2_2
3. item_3

rick

Re: [O] Combine tables which are results from calculations?

[Rick Frankel]

On Wed, Nov 04, 2015 at 10:03:48AM +0100, Rainer M Krug wrote:
> Rick Frankel <r...@rickster.com> writes:
>
> > On Tue, Nov 03, 2015 at 02:18:05PM +0100, Rainer M Krug wrote:
> >> Hi
> >>
> >> Considering the following example:
> >
> > here's a way to do it in ruby. There is probably a way in {emacs,cl}-lisp, 
> > but
> > I'm not sure how...
> >
> > #+BEGIN_SRC ruby :var a=t1[,0] b=t2[,0] c=t3[,0] :colnames '(a b c)
> >   r = [a, b, c]
> >   len = r.collect(&:length).max
> >   r.each { |l| l.fill('', l.length, len - l.length) }
> >   a.zip(b, c)
> > #+END_SRC
>
> Thanks - I'll look into this and see if I can do something similar in R
> or elisp.

Here's a elisp version:

* zip lists
#+name: a
| a |
|---|
| 1 |
| 2 |


#+name: b
| b |
|---|
| 4 |
| 5 |
| 6 |
| 7 |
| 8 |

#+name: c
|  c |
||
|  9 |
| 10 |
| 11 |

#+BEGIN_SRC emacs-lisp :var a=a[,0] b=b[,0] c=c[,0] :colnames '(a b c)
  (let*  ((l (list a b c))
  (max (apply #'max (mapcar #'length l
(apply
 #'mapcar* #'list
 (mapcar (lambda (x) (append x (make-list (- max (length x)) ""))) l)))
#+END_SRC


rick

Note: previous reply was not to list (whoops) CC'ing the list on this so the
answer is saved for posterity :).

Re: [O] HTML Export, CSS Styling

[Rick Frankel]

On Fri, Aug 21, 2015 at 09:13:13PM -0700, David A. Gershman wrote:
 I've been reading all evening about HTML exporting, style sheets, etc. 
 Maybe I've been inundated with information, but I haven't been able to
 determine an answer to my question: can text in the middle of a
 paragraph by styled?  For example:
 
 * Heading 1
This is the paragraph body that will allow *bold*
or /italic/ or even _underline_, but what if I want
only THIS word to have styling?  Such as making it
red to indicate importance?

Also, note that the above examples are exported by default as:

  - bbold/b
  - iitalic/i
  - span class=underlineunderline/span

So you can redefine the css associated with them if you want.

Also, you can customize `org-html-text-markup-alist' to change the markup.

rick

Re: [O] HTML export / list issues

[Rick Frankel]

On Fri, Aug 21, 2015 at 02:58:35PM +0200, Nicolas Goaziou wrote:
 Hello,
 
 Jarmo Hurri jarmo.hu...@iki.fi writes:
 
  Below is a (hopefully) self-explanatory org file of my problem and the
  associated html export.
 
  Jarmo
 
  * Problem description
The examples below illustrate three problems I have with lists and
html export at the moment.
1. lists alphabetized in org are enumerated in html
 
 Actually this is a wrong assumption. Org only distinguishes enumerated,
 itemized and description lists. There are no sub-categories.
 
 In the buffer, you may write an enumerated list item 1., 1), a.,
 A., a) or A), but they are all the same.
 
 For this kind of thing, setting an appropriate CSS could be an option.

Correct. try ~list-style-type: lower-alpha;~ in your css to get lowercase
alphanumeric labels for an enumerated list (~ol~).

2. code evaluation breaks list continuation
3. centering of raw html does not work using begin center and
   end center
  * Example
I am making a hierarchical list with some code in it.
1. level 1 first
   a) level 2 first; I was hoping this would be alphabetized in html
  like it is in org, but it is still enumerated
   b) the next item has some code in it; it has been evaluated with
  C-c C-c to obtain the result
   c) 
  #+BEGIN_SRC elisp :exports results
  (+ 1 2)
  #+END_SRC
 
   #+RESULTS:
   : 3
 
 This is because a) is not recognized as a list item in your buffer.
 
  Make sure you have a non-nil `org-list-allow-alphabetical' and
 `org-plain-list-ordered-item-terminator' is either t or ?). These
 variables need to be set before Org is loaded. If you set them in
 current session, make sure to reload Org.
 
2. here is another element with some code; I am trying to center the
   result of the evalution of this code in html
   #+NAME: code-example
   #+BEGIN_SRC elisp :exports results :results raw
   (- 9 14) #+END_SRC
 
   #+BEGIN_CENTER
   #+RESULTS: code-example
   -5
   #+END_CENTER
3. but for some reason the result is not centered
 
 This generates
 
   div class=center
   p
   -5
   /p
   /div
 
 perhaps someone more versed in HTML could tell what is wrong here.

I would assume it's because there is no css for ~div.center~. Try (untested):

  div.center  p { text-align: center; }

Note that this will center each line, separately. To center the entire
paragraph as a block is more complex. This will do if if you specify the
paragraph width.

  div.center  p {
margin-left: auto;
margin-right: auto;
width: {X}em;
  }

See http://www.w3.org/Style/Examples/007/center#viewport3 for a CSS3 (less
backward compatible) approach. that doesn't require setting the width of the
paragraph.

I usually just set a left margin or padding as opposed to trying to float
the block in the middle. (e.g. ~margin-left: 2em~.)

rick

Re: [O] controlling how htmlize fontifies code

[Rick Frankel]

On Mon, Aug 03, 2015 at 02:50:27PM +0100, Eric S Fraga wrote:
 On Sunday,  2 Aug 2015 at 09:19, Rick Frankel wrote:
  Check the documentation for the variable `org-html-htmlize-output-type'. 
  Since
  ox-reveal is derived from ox-html, it should work as specified. I personally
  use ox-deck (also derived from html), so YMMV.

 On Sunday,  2 Aug 2015 at 09:41, Kaushal wrote:
  I export with my custom Leuven theme (a light theme) css and it works fine.
  I also have my emacs theme as a dark theme by default.
 
  ;; (setq org-html-htmlize-output-type 'inline-css) ; default
  (setq org-html-htmlize-output-type 'css)
  ;; (setq org-html-htmlize-font-prefix ) ; default
  (setq org-html-htmlize-font-prefix org-)


 I have tried both setting a local variable and also using #+bind: but
 neither approach works for some reason.  I did not expect the local
 variable setting to work, of course.


Both should work. Are you sure you have `org-export-allow-bind-keywords' set?
Why wouldn't you expect local variables to work?

rick

Re: [O] controlling how htmlize fontifies code

[Rick Frankel]

On Sun, Aug 02, 2015 at 10:24:25AM +0100, Eric S Fraga wrote:
 Now, I can simply start up emacs with a light background, export my
 slides and everything is fine.  However, it would be nice to not have to
 start up a new emacs just for this.  Is there an easy way to pretend,
 for export to HTML, that emacs is using a light background?  Maybe a way
 to advise the exporter?

 PS - ideally, code export to HTML would make use of CSS instead of
  hard-coding in the colours but that's a discussion for another
  day...

Check the documentation for the variable `org-html-htmlize-output-type'. Since
ox-reveal is derived from ox-html, it should work as specified. I personally
use ox-deck (also derived from html), so YMMV.

rick

Re: [O] Org-Mode and Mac OS X advice

[Rick Frankel]

On Thu, Mar 26, 2015 at 02:57:40PM +0100, Alan Schmitt wrote:
 On 2015-03-26 14:50, Bernd Haug bernd.h...@xaidat.com writes:

 I'm using this nice trick (passed to me by a colleague) that sets the
 environment variables and path to be the same in zsh and emacs (launched
 From the GUI).

 #+begin_src emacs-lisp
 (let ((vars (split-string-and-unquote (shell-command-to-string . ~/.zshrc; 
 export) \n)))
   (mapcar (lambda (X) (let ((var_val (split-string-and-unquote X =)))
 (setenv (car var_val) (cadr var_val vars)
   (setq exec-path
 (append
  (split-string-and-unquote (getenv PATH) :)
  exec-path)))
 #+end_src

You could also use the `exec-path-from-shell' package, which will set a
specified list of variables (defaults to MANPATH, PATH) from the shell.

rick

[O] BUG: Cached named call lines

[Rick Frankel]

There are bugs with calling named call lines and blocks when they are cached.

If the callee is cached, the results vary when the caller is re-evaluated.

The following file demonstrates the bug(s). Unfortunately I don't have time
right now to debug...

#+BEGIN_SRC org
  ,* Cached results bug
  ,** Tests
  ,*** Fails with error:
  mapconcat: Wrong type argument: listp, string=\foo bar\
  ,#+call: bad-src(string=foo bar)

  ,*** Fails with =nil= second time evaluated
  ,#+call: word(data=cached(string=bar fly))

  ,*** Returns different results on second call (quotes words)
  ,#+call: word(data=cached-unwrapped(string=bar fly))

  ,*** Works
  ,#+call: word(data=src(string=bar fly))

  ,#+call: word(data=uncached(string=bar fly))
  ,** Intermediate calls
  ,#+name: cached
  ,#+call: src(string=foo bar) :cache yes :results wrap

  ,#+name: uncached
  ,#+call: src(string=foo bar) :results wrap

  ,#+name: cached-unwrapped
  ,#+call: src(string=foo bar) :cache yes

  ,** Blocks
  ,#+name: bad-src
  ,#+BEGIN_SRC emacs-lisp :var string= :cache yes
string
  ,#+END_SRC

  This block works when called
  ,#+name: src
  ,#+BEGIN_SRC emacs-lisp :var string=
string
  ,#+END_SRC

  ,#+name: word
  ,#+BEGIN_SRC emacs-lisp :var data=
(split-string data)
  #+END_SRC
#+END_SRC

Re: [O] html export using html5 elements and bootstrap framework

[Rick Frankel]

On Sun, Jan 04, 2015 at 02:32:03AM +0100, Rasmus wrote:
 Hi,
 
 RC re...@yahoo.com writes:
 
  If the default heading and content classes used by ox-html could be
  changed or aliased it should work well with org-mode html
 
 Maybe you can set up filters then to replace e.g. section into the desired
 naming-scheme.  AFAIR class-names are hard-coded in ox-html.

As Rasmus mentioned in a previous email, there is no way currently to add html
attributes to lists w/ ATTR_HTML.

A filter, a mentioned above, is your simplest approach. The best (IMHO) would
be to create a derived exporter (ox-bootstrap?) based on ox-html. You can look
at one of the slideshow backends (ox-deck, ox-s5, ox-reveal) for
examples (e.g., `org-deck-item' or org-s5-headline for how to advise the
html exporter functions.)

rick

Re: [O] html export using html5 elements and bootstrap framework

[Rick Frankel]

On Fri, Jan 02, 2015 at 03:47:36PM +, R C wrote:
 I would like to have org mode export a project using html5 elements and
 bootstrap framework adapting the worg tutorial: 
 org-publish-html-tutorial.html 
 
 - template with links to bootstrap css and js files, and a local.js file
 with my macro definitions for mathjax: ~/web/org-templates/level-0.org 
 with lines of the form:
 #+STYLE:   link href=css/bootstrap.min.css rel=stylesheet 
 media=screen

I don't believe `STYLE' is used by the HTML exporter. See: `HTML_HEAD'
(`org-html-head') and `HTML_HEAD_EXTRA' (`org-html-head-extra'.)

 I also have: (setq org-html-html5-fancy t)

This only affects the use of html5 specific tags (section, article). The
exported doctype is controlled by HTML_DOCTYPE (`org-html-doctype')

 However tst.html does not show any inclusions from the level-0.org file and
 does not seem to use the html5 doctype:

Because there were no valid HTML options in level-0 and the doctype wasn't
set? Not having the contents of the file I can't be 100% sure.


Regardless, I don't think bootstrap will work very well. Doesn't it require
specific classes on the markup? To make it work you will probably need to add
additonal classes to every heading, etc.

rick

Re: [O] How to export to S5 HTML presentation

[Rick Frankel]

On Sat, Sep 27, 2014 at 07:59:13AM -0700, Jay Iyer wrote:
Hi,
I would like to use the S5 backend for HTML presentations but I am not
able to figure out how: (1) to set up headlines for incremental slide
builds and (2) to add speaker notes.� I spent a lot of time on the mailing
list archive and other places but couldn’t find clear instructions on
what property values and/or tags are needed on the headlines and their
subheadings.� Are there any additional exporter settings� needed in the
buffer? � I am using Org 8.2.5h on Emacs 24.3.1 (Apple build) and the
built in exporter engines.


Documentation for ox-s5 is @ https://github.com/cybercode/org-slides#ox-s5el,
although personally i use ox-deck (documented at the same location) now.

rick

Re: [O] org-table: missing vertical boundary when exported

[Rick Frankel]

On 2014-08-13 00:46, Shiyuan wrote:

Rick, 
   Do you mean that  table border=2 and table style=border:2px
don't mean the same thing? Their names suggest they do the same
things. That's a terrible naming. Changing the former to the latter
does fix the problem though. Why is that? 


Please read the HTML specifications for an explaination. By my reading
border=2 is in fact invalid in html5:

The border attribute may be specified on a table element to
explicitly indicate that the table element is not being used for
layout purposes. If specified, the attribute's value must either
be the empty string or the value 1. The attribute is used by
certain user agents as an indication that borders should be drawn
around cells of the table.

In html4 it does seem to do the same thing:

border = pixels [CN]
This attributes specifies the width (in pixels only) of the frame
around a table (see the Note below for more information about this
attribute).

     
Using the #+HTML_HEAD_EXTRA options as you suggest can also fix the
problem. But could you explain why using the HTML_HEAD_EXTRA is more
advisable than setting the table style=border:2px directly as
table attributes? What would you suggest if we want some tables have
orders and others don't have borders in the same html webpage? 


Use css selectors. If you want to set the style attribute directly on
the table element in a post-processor you may, but is is not
considered best practice.

Re: [O] Need info about code block header arguments in (HTML) export

[Rick Frankel]

On 2014-08-11 10:58, Avdi Grimm wrote:

Hi there, Org experts!

I write books in org-mode, and one of the features I've really started
to need is to be able to automatically include filename information
when exporting source code listings. That is, given some Org source
like this:

    #+BEGIN_SRC ruby :tangle foo/bar.rb
      puts hello, world
    #+END_SRC

...the final HTML might look something like this:

    div class=org-src-container
    div class=src-pathfoo/bar.rb/div



Currently, you can acheive similar html output by using the
`#+CAPTION' header argument;

#+CAPTION: foo/bar.pl
#+BEGIN_SRC perl :exports code
print foo\n;
#+END_SRC

which would generate this html:

#+BEGIN_SRC html
div class=org-src-container
label class=org-src-namefoo/bar.pl/label
pre class=src src-perlspan style=color: #458b00;print/span 
span style=color: #006400;foo\n/span;

/pre
/div
#+END_SRC

I don't see a way to get the `:tangle' keyword during export, as the
parser does not include that in list passed to the src-block export
function.


rick

Re: [O] org-table: missing vertical boundary when exported

[Rick Frankel]

On Sat, Aug 09, 2014 at 05:49:27PM -0700, Shiyuan wrote:
Hi,�
� � I learned a bit a about html/css and took another look the issue. It
turns out that org-mode uses the border attribute which is not respected
by my browser(Google Chrome version 36.0.1985.125 on Mac 10.9.4) .�
Org mode generated this line in the html for table but the border is not
displayed,�
table border=2 cellspacing=0 cellpadding=6 rules=groups
frame=hsides

The border attribute has nothing to do with it. It's the frame attribute
which sets the default top and bottom borders.

If we use css style to specify the border, � the table border would show
up:�
table style=border:2px cellspacing=0 cellpadding=6 rules=groups
frame=hsides

No. The CSS should be in the header, not an attribute of the tag. Have you
tried setting the 'HTML_HEAD_EXTRA' option?  somehting like:

#+HTML_HEAD_EXTRA: style type=text/css
#+HTML_HEAD_EXTRA: table {border-left: 1px solid black; border-right: 1px solid 
black;}
#+HTML_HEAD_EXTRA: /style


rick

Re: [O] HTML export of - [ ] does not display box anymore

[Rick Frankel]

On Wed, Aug 06, 2014 at 10:05:25AM +0200, Rainer Stengele wrote:
Am 05.08.2014 um 15:39 schrieb Rick Frankel:

I do not see the checkbox box anymore as I did in older versions.
I tried to find an export setting, tried several settings related to
todos but I cannot find a setting stopping the box to be exported.


I have these set correctly. What I get is: (I run Org-mode version 8.3beta
(release_8.3beta-167-g003edd)

You are correct. This was broken in commit c9ca0b6... ox-html: Use options
instead of hard-coded variables.

I will look into a fix later.

rick

Re: [O] HTML export of - [ ] does not display box anymore

[Rick Frankel]

On Wed, Aug 06, 2014 at 10:05:25AM +0200, Rainer Stengele wrote:
Am 05.08.2014 um 15:39 schrieb Rick Frankel:
  On 2014-08-05 08:25, Rainer Stengele wrote:
doing an html export of
 
* headline
- [ ] checkbox
- item
 
I do not see the checkbox box anymore as I did in older versions.
I tried to find an export setting, tried several settings related to
todos but I cannot find a setting stopping the box to be exported.
 

The fix was easier than i thought. Please pull master and retry.

rick

Re: [O] HTML export of - [ ] does not display box anymore

[Rick Frankel]

On 2014-08-05 08:25, Rainer Stengele wrote:

Hi,

doing an html export of

* headline
- [ ] checkbox
- item

I do not see the checkbox box anymore as I did in older versions.
I tried to find an export setting, tried several settings related to
todos but I cannot find a setting stopping the box to be exported.

Any hint where I could search for?


Checkbox export is handled by a constant and a custom variable:

- `org-html-checkbox-types' :: A constant defining the output for
unicode (entity), ascii, and html (form) versions of the
checkboxes.
- `org-html-checkbox-type' :: A customizable variable defining
which version of the above to use. The default is ascii,
which should result in backwards compatible output.

Here's the output i get for your list above (using the default ascii
option):

ul class=org-ul
li class=offcode[#xa0;]/code checkbox
/li
liitem
/li
/ul

which seems correct to me.

Re: [O] Possible to use src block to generate org headlines for export?

[Rick Frankel]

On 2014-07-22 22:35, Matt Lundin wrote:

Nick Dokos ndo...@gmail.com writes:

In short, is there a more graceful and export-friendly way to use babel
to generate org headlines for export? Or is there an easy way to get 
the

export backend to delete the opening part of the drawer (i.e.,
:RESULTS:)?

Any advice would be greatly appreciated.


No solace for your pain alas.  See
http://thread.gmane.org/gmane.emacs.orgmode/88557

My suggestion (as it was for Ronald, except that he had already 
rejected

it :-) ) would be to use raw: you lose the idempotency of results
production, but I don't know of any other problems.

However, since the headlines I'm generating are always at the end of 
the

file, I've hacked my way to a solution with the following:

#+BEGIN_SRC emacs-lisp :exports none :results none
(save-excursion
(goto-char (point-min))
(while (re-search-forward #\\+RESULTS: generate-blog-summary nil t)
(beginning-of-line)
(delete-region (point) (point-max
#+END_SRC

#+NAME: generate-blog-summary
#+BEGIN_SRC perl :exports results :results output org raw
print * Headline One\n;
print * Headline Two\n;
print * Headline Three\n;
#+END_SRC



Close. I have a complex process which generates org source that is
then executed as part of the export. I generate org under a single
heading and give the heading a unique id. You can the goto the named
reference and `org-cut-subtree' to remove the output before
re-executing the block to generate the code. This way it can go
anywhere in the file and you don't have to worry about the
`RESULTS:' tag. Here's an abbreviated version of the code i use
(which generated a lot of org tables):

#+BEGIN_SRC org
,#+name: run-parse-spreadsheet
,#+BEGIN_SRC emacs-lisp :results raw none :exports results
(condition-case nil
(progn
(widen)
(org-id-goto REFERENCE-TABLES)
(org-cut-subtree))
(error t))
(org-babel-goto-named-src-block parse-spreadsheet)
(org-babel-execute-src-block
nil nil '((:eval . yes) (:results . raw output)))
(org-table-map-tables 'org-table-align 'quietly)
,#+END_SRC

# *Note:* This is set to =:eval never= because the generated output
# needs to be removed before execution and refreshed after
# generation by executing the source block [[run-parse-spreadsheet]]
# above instead of running this directly.
,#+name: parse-spreadsheet
,#+HEADER: :var spreadsheet=spreadsheet
,#+BEGIN_SRC perl :results output :eval never
print join(\n,
*** Tables,
:PROPERTIES:,
:ID: REFERENCE-TABLES,
:END:,
'',
);
print  Table 1\n;
# ...
,#+END_SRC
#+END_SRC

Re: [O] How to call org-display-inline-images so that after a graphviz block is evaluated the image is refreshed?

[Rick Frankel]

On 2014-07-11 20:28, Ken Mankoff wrote:

Try (org-redisplay-inline-images). Note re.

#+BEGIN_SRC lang :post (org-redisplay-inline-images)
#+END_SRC
#+RESULTS:


I believe it is on WORG somewhere:

#+BEGIN_SRC emacs-lisp
(add-hook 'org-babel-after-execute-hook
(lambda () (org-display-inline-images nil t)))
#+END_SRC

rick

Re: [O] html-encode in mathjax latex fragments

[Rick Frankel]

On 2014-06-30 06:54, Nicolas Goaziou wrote:

Hello,

Eric Schulte schulte.e...@gmail.com writes:

From the link above it sounds like replacing just ,  and 
should be sufficient, if the full html encoding in my previous patch 
was

too heavy weight.

By default, `org-html-encode-plain-text' just takes care about , 
and , which is what you're looking. However, it is configurable
through `org-html-protect-char-alist', which may cause trouble.

FWIW I think a hard-coded function dedicated to the task, or simply
a hard-coded replacement within `org-html-format-latex', may be safer 
in

the long run. Anyway Rick Frankel may have an opinion here.


Not sure why `org-html-protect-char-alist' is a custom and not just a
var, but IMHO, `org-html-encode-plain-text' is the correct solution.

rick

Re: [O] Tables orgmode2html styles

[Rick Frankel]

On 2014-06-30 05:32, silgon wrote:

Hello guys. I just wanted to say that when you're converting the tables
the properties of the tables are different. The properties are not
longer part of the parameters of the tag, they are part of the css
configuration. I realized that by using *org-reveal* to do my
presentations.


Not really enough information here... But I am assuming that you mean
that when you export an org-reveal slideshow the =table= tag does
not contain any attributes like =border=2=, etc.

This is not a bug, but correct behavior. reveal exports the document
as html5, and those attributes are not supported but must be defined
in the CSS. If you would like to export org-mode files with embedded
table attributes you need to use an html4 compatible format.

rick

Re: [O] unattractive list spacing in ox-html export

[Rick Frankel]

On 2014-06-24 09:24, Nicolas Goaziou wrote:

Hello,

Achim Gratz strom...@nexgo.de writes:

You can disagree all you want, that doesn't make the underlying problem 
go
away.  The reason for the unattractive spacing is that list items, 
while
conceptually paragraphs, do not have additional spacing after them so 
the
list becomes more compact.  The W3C doesn't really encourage to use 
lists
with paragraphs, but if you do (like Org), an explicit paragraph inside 
a
list environment either should also not have that spacing or should 
have it
at the beginning (in which case the first paragraph must be implicit).  
So

you'll have to modify the CSS anyway or the lists are still having ugly
spacing. Your patch only makes it consistently ugly as soon as there is 
a

single explicit paragraph needed.

So, would a better solution be to remove the patch and tweak default 
CSS

so it provides better spacing for paragraphs in li tags?


Yes. But arguably, in a multi-paragraph list item, the first paragraph
should be explicit and not implicit --- hence my previous suggestion to
wrap all list items longer that [X] in an explicit paragraph.

rick

Re: [O] unattractive list spacing in ox-html export

[Rick Frankel]

On 2014-06-24 08:46, Achim Gratz wrote:

Eric Schulte schulte.eric at gmail.com writes:
I disagree, editing CSS shouldn't be required for reasonable default
list spacing on HTML export.

You can disagree all you want, that doesn't make the underlying problem 
go
away.  The reason for the unattractive spacing is that list items, 
while
conceptually paragraphs, do not have additional spacing after them so 
the
list becomes more compact.  The W3C doesn't really encourage to use 
lists
with paragraphs, but if you do (like Org), an explicit paragraph inside 
a
list environment either should also not have that spacing or should 
have it
at the beginning (in which case the first paragraph must be implicit).  
So

you'll have to modify the CSS anyway or the lists are still having ugly
spacing. Your patch only makes it consistently ugly as soon as there is 
a

single explicit paragraph needed.



I pretty much agree w/ Achim. Lists are in general meant to be compact
and have short content. But given that  lists are often abused to
contain paragraph text, perhaps a better approach would be to wrap
anything in a list element longer than X (2 lines, ~160 characters?)
in a paragraph (or multiple if required) and change the default css to
only paragraph space _between_ paragraphs in list elements (i.e., after
all but the last paragraph, or before all but the first.)

rick

Re: [O] Publishing sitemap

[Rick Frankel]

On 2014-06-18 03:54, Vikas Rawal wrote:

When I publish my web-site using org-mode, with suitable options in my
org-publish-projects-alist, I can get org-publish to create a sitemap.

Is it possible to just create the sitemap without publishing the whole
project? I sometimes update a single file, and just publish it using
org-publish-current-file. I would like the changes (for example, date)
or if a new file is being published, the file itself, reflected in the
sitemap.  But I can’t do it unless I publish the whole project.

Is there a way to deal with this?


Looking at the source for `org-publish-projects' (grep for sitemamp in 
ox-publish) it looks like the sitemap is generated in this line:


(if sitemap-p (funcall sitemap-function project sitemap-filename))

where `sitemap-function' defaults to `org-publish-org-sitemap'.

So (untested), you could try:

(org-publish-org-sitemap (assoc my-project-name
org-publish-project-alist)

where project is the actual properties list from `org-p

Re: [O] Publishing sitemap

[Rick Frankel]

Sorry, hit the wrong key... completed response below.

On 2014-06-18 03:54, Vikas Rawal wrote:

When I publish my web-site using org-mode, with suitable options in my
org-publish-projects-alist, I can get org-publish to create a sitemap.

Is it possible to just create the sitemap without publishing the whole
project? I sometimes update a single file, and just publish it using
org-publish-current-file. I would like the changes (for example, date)
or if a new file is being published, the file itself, reflected in the
sitemap.  But I can’t do it unless I publish the whole project.

Is there a way to deal with this?


Looking at the source for `org-publish-projects' (grep for sitemamp in
ox-publish) it looks like the sitemap is generated in this line:

(if sitemap-p (funcall sitemap-function project sitemap-filename))

where `sitemap-function' defaults to `org-publish-org-sitemap'.

So (untested), you could try:

(org-publish-org-sitemap
(assoc my-project-name org-publish-project-alist)
sitemap.txt)

rick

Re: [O] org-table: missing vertical boundary when exported

[Rick Frankel]

On 2014-06-07 17:15, Shiyuan wrote:

    I am following the manual
example http://orgmode.org/worg/org-tutorials/tables.html [1]. But the
two vertical boundary line on the very left and right 
is not showing up when exported to html.  Anything I am missing? 
Thanks. 


My guess is that it is related to the css being used to style the table
in your setup.

Could you post a minimal example with the html output?

rick

Re: [O] Add a class for first paragraph in ox-html?

[Rick Frankel]

On 2014-06-06 18:37, kuanyui wrote:

If you export an Org file to HTML, which has a paragraph before the
first outline, the paragraph will be only wrapped with p and no
class/id:



This is an obstacle for write CSS for org HTML page. Maybe this can be
fix by add a seperate class or id for this paragraph? Thanks.


Adding a class or wrapping the paragraphs (there can be more than one)
before the first headline is non-trivial.

However, I believe these are the only paragraphs as direct children of
the content div, you can use the css selector #content  p to
reference them.

rick

Re: [O] DTD prohibited

[Rick Frankel]

On 2014-06-04 12:52, AW wrote:

Am Mittwoch, 4. Juni 2014, 17:04:14 schrieb Eric Abrahamsen:
Eric S Fraga e.fr...@ucl.ac.uk writes:
 On Tuesday,  3 Jun 2014 at 22:14, AW wrote:

 [...]

 Hi,

 thank you, I started again digging into this strange thing and the
 culprit
 seems the first line of the html-file:

 ?xml version=1.0 encoding=utf-8?

Seems like simply exporting as html5 might solve the problem.

Yes, it does, thank you. But the price is that tabulars lose the frames 
and

lines. I did not invest whether due to export without those elements or
because Word had issues with html5.


It's because the html5 export has no default style for tables --
before opening in word, try opening the html in a browser, you will
see that xhtml-strict export adds style info to the table element, but 
xhtml5 doesn't.


If you want the same style in html5 as html4, try the following
preamble in your org file:

#+HTML_DOCTYPE: xhtml5
#+HTML_HEAD: style type=text/css
#+HTML_HEAD: table {
#+HTML_HEAD: border-top: thin solid gray;
#+HTML_HEAD: border-bottom: thin solid gray;
#+HTML_HEAD: }
#+HTML_HEAD: thead {border-bottom: thin solid grey;}
#+HTML_HEAD: td, th {padding: 6px;}
#+HTML_HEAD:/style

FYI, here's the table definition output in html4:

table border=2 cellspacing=0 cellpadding=6 rules=groups
frame=hsides

and html5

table

rick

Re: [O] LaTex export questions

[Rick Frankel]

On 2014-05-27 23:25, Steven Arntson wrote:

Nick Dokos ndo...@gmail.com writes:

Igor Sosa Mayor joseleopoldo1...@gmail.com writes:

Steven Arntson ste...@stevenarntson.com writes:

Hi, I'm trying to export an org-mode doc to LaTex and subsequently to
PDF. This is a literary novel, written in prose. Right now when I run
the export command, the resulting file is incorrectly formatted for the
literary world, and I'm not sure how to change it. Is there a dialog or
customize menu that allows users to eliminate some default settings,
and add others?
But perhaps the OP can clarify: what does incorrectly formatted for
the literary world mean?

Literary format redux:
+ 12 point text
+ Title page has title and author name, centered both horizontally and
vertically. Contact info for agent is in the bottom left, single 
spaced.

+ Remaining pages are double-spaced
+ Page numbers are centered at the bottom of the page (but no page 
number

on title page)
+ Each page has a right-justified header in the format LASTNAME/TITLE



A quick google for latex novel manuscript template leads to
http://goer.org/Journal/2011/01/publishing_with_sphinx_rest_and_sffms_latex.html,
which leads to: http://www.mcdemarco.net/sffms/, which looks like what
you want...

rick

Re: [O] Superscript and subscript in HTML?

[Rick Frankel]

On 2014-05-28 07:47, Peter Davis wrote:

Is there any markup which will let me get superscripts and subscripts
in HTML export?

It would be great if the HTML exporter recognized ^{...} and _{...} so
the same markup would work for both LaTeX/PDF and for HTML.


It does for me. I believe it always has. Are you sure your options are
set correctly? Also, are you sure that the html source doesn't contain
sup/ and sub/ tags that aren't being styled?

Here's a example and the output

#+BEGIN_SRC org
,#+OPTIONS: toc:nil
,* Super and subscript
this is a super^{1} script. and a sub_{2} script.

another super^3 and another sub_4
#+END_SRC

and the results (C-c C-e C-b h H)

#+BEGIN_EXAMPLE
div id=outline-container-sec-1 class=outline-2
h2 id=sec-1Super and subscript/h2
div class=outline-text-2 id=text-1
p
this is a supersup1/sup script. and a subsub2/sub script.
/p

p
another supersup3/sup and another subsub4/sub/p
/div
/div

#+END_EXAMPLE

Re: [O] Superscript and subscript in HTML?

[Rick Frankel]

On 2014-05-28 09:22, Peter Davis wrote:

On Wed, May 28, 2014 at 08:50:20AM -0400, Rick Frankel wrote:
On 2014-05-28 07:47, Peter Davis wrote:
Is there any markup which will let me get superscripts and subscripts
in HTML export?

It would be great if the HTML exporter recognized ^{...} and _{...} so
the same markup would work for both LaTeX/PDF and for HTML.

It does for me. I believe it always has. Are you sure your options are
set correctly? Also, are you sure that the html source doesn't contain
sup/ and sub/ tags that aren't being styled?

Here's a example and the output

#+BEGIN_SRC org
,#+OPTIONS: toc:nil
,* Super and subscript
this is a super^{1} script. and a sub_{2} script.

another super^3 and another sub_4
#+END_SRC

and the results (C-c C-e C-b h H)

#+BEGIN_EXAMPLE
div id=outline-container-sec-1 class=outline-2
h2 id=sec-1Super and subscript/h2
div class=outline-text-2 id=text-1
p
this is a supersup1/sup script. and a subsub2/sub script.
/p

p
another supersup3/sup and another subsub4/sub/p
/div
/div

#+END_EXAMPLE


Here's what I get for the body, using your example:

+==
div class=org-src-container

pre class=src src-orgspan style=color: #b2;#+OPTIONS: 
toc:nil/span

span style=color: #ff;* Super and subscript/span
this is a super^{1} script. and a sub_{2} script.

another super^3 and another sub_4
/pre
/div
+==

Leaving out the #+BEGIN_SRC/#+END_SRC doesn't work either. This is
with emacs 24.3.3, org-mode 8.2.5g


The begin/end src lines are just that, markers to show where the org
source starts and end. What you have formatted is a source code
listing, not the source code.

1. Create a new org mode buffer.
2. Copy the contents WITHIN the begin/end src block to the buffer.
3. Remove the leading commas (,).
4. With your cursor on the #+OPTION line type [C-c C-c].
5. Generate the html output.

If it still doesn't work edit the file with:

emacs -Q -Lpath to org 8.2.5g mytest.org

and try again.

rick

Re: [O] Superscript and subscript in HTML?

[Rick Frankel]

On 2014-05-28 09:36, Peter Davis wrote:

On Wed, May 28, 2014 at 09:29:44AM -0400, Rick Frankel wrote:

The begin/end src lines are just that, markers to show where the org
source starts and end. What you have formatted is a source code
listing, not the source code.

If you're giving an example of org buffer contents, #+BEGIN_SRC and
#+END_SRC are probably not the best delimiters to use to set off your
example, since they're valid org markup.


#+BEGIN_SRC org
^^^

Is the common method on this list for specifying org (or any other)
source code in an email. Org can embed org source in org.


Anyway, it turns out some options I had enabled were preventing the
superscript/subscript markup from being recognized. I had this

#+OPTIONS:   H:5 \n:nil @:t ::t |:t ^:nil -:t f:t *:t :t


^

at the top of the buffer. Removing that line seems to get me proper
HTML markup.


You are explicitly disabling super/subscripts. It would be the same
for latex output.

Re: [O] emacs24-starter-kit and Aquamacs 3.0

[Rick Frankel]

On 2014-05-15 07:59, Axel Kielhorn wrote:

I never wanted to learn Emacs.
There is probably a more elegant way to add a /.emacs.d to the path
when the editor is Aquamacs, but I have to learn some elisp for that.

Or a way to tell Aquamacs to use a different init file.

Any suggestions are appreciated.


Probably not the answer you want, but as a long-time mac and emacs
user, my suggestion would be to use the vanilla os x version of emacs.

IMHO, there is no longer any compelling reason to use aquamacs. It was
started at a time when the core gnu emacs did not support os x, this
is no longer the case.

The nextstep build of emacs runs as a native app, supports
anti-aliased fonts, etc. Personally, i find that the keyboard
rebinding in aquamacs just make it it harder to use/learn emacs, as
all the documentation, etc, is based on the standard, cross-platform
bindings. Once you learn them, you will be able to use emacs on any
platform -- mac, windows, unix. Also, your configuration will be
portable across all the same platforms.

rick

Re: [O] emacs24-starter-kit and Aquamacs 3.0

[Rick Frankel]

On 2014-05-15 10:31, Vikas Rawal wrote:

Probably not the answer you want, but as a long-time mac and emacs
user, my suggestion would be to use the vanilla os x version of emacs.

The nextstep build of emacs runs as a native app,

You are suggesting to a Mac user to build his own Emacs?
Do you know what that takes?
About 10 minutes :-)

I just realized that it is even possible to download it prebuilt.

I recommend a homebrew-based install of emacs.

I like the version available from railwaycat/emacsmacport tap
(https://github.com/railwaycat/emacs-mac-port [1]).


Not familiar w/ emacsports, will take a look at it this weekend. My
problem w/ the homebrew install (and i'm a homebrew fan) is that
i prefer the all-in-one (--with-ns) package and not having the app
spread around /usr/local in unix fashion the way the homebrew install
works.

Personally, i used homebrew to install the build dependencies
(autoconf, automake, imagemagick, etc) and the git mirror of the emacs
trunk (http://git.sv.gnu.org/emacs.git) YMMV.

rick

Re: [O] Export HTML with Free Form Text

[Rick Frankel]

On 2014-05-13 11:03, Esben Stien wrote:

If I have a heading like this:
** foo
bar
baz

..and I export it to html, it comes out like this:

** foo
bar baz

Is there any way to tell export that free form text like this is
allowed?


What you want is verbatim text, or Literal examples, not really
free-form. HTML by definition treats runs of whitespace as a single
space, so you need to do something to get it to treat the text as
separate lines. You have (at least ;) two choices in org: example
blocks or verse block.

Here's an example:

 8 cut here 8 -

* Literal text

#+BEGIN_VERSE
this
is
a
verse
#+END_VERSE

#+BEGIN_EXAMPLE
this
is
a
verse
#+END_EXAMPLE

And the html output:

#+BEGIN_HTML
p class=verse
thisbr  /
#xa0;#xa0;isbr  /
#xa0;#xa0;#xa0;#xa0;abr  /
versebr  /
/p

pre class=example
this
is
a
verse
/pre
#+END_HTML

Re: [O] How to change org-export-html-style

[Rick Frankel]

On 2014-04-15 23:25, Rustom Mody wrote:
On Tue, Apr 15, 2014 at 10:39 PM, Rick Frankel r...@rickster.com 
wrote:


On 2014-04-15 07:30, Rustom Mody wrote:

I need (for various reasons) to inline these styles

I have this code in my init to change the html style

(defun rusi/load-css()
  Returns string from css file (hardwired) suitable for inline css
  (interactive)
  (setq org-export-html-style
    (with-temp-buffer
      (insert nstyle type=text/cssn)
      (insert-file-contents (expand-file-name my-org.css 
~/orghacks))

      (goto-char (point-max))
      (insert n/stylen)
      (buffer-string
(rusi/load-css)
Now if I edit and save the my-org.css file and then call M-: 
(rusi/load-css)

it does not work.
Restarting emacs makes it work.
Ive checked that org-export-html-style is actually changed.
However org-mode seems to be keeping some internal copy after first 
use.

org-reload is not helping here

Can you explain not working? There's not enough info here to see
what problem you are having.



On further examination, I'm not sure how it works at all!
`org-export-html-style' is a customization variable from the (old)
version of org included w/ emacs:

#+BEGIN_SRC emacs-lisp
(describe-variable 'org-export-html-style)
#+END_SRC

#+RESULTS:
#+begin_example
org-export-html-style is a variable defined in `org-html.el'.
snip/
#+end_example

The source file for the current exporter is `ox-html.el'.

Try setting `org-html-head' and `org-html-head-include-default-style'.

rick

Re: [O] Is it possible to add a class to a paragraph in HTML export?

[Rick Frankel]

On Wed, Apr 02, 2014 at 09:06:48AM +0200, Nicolas Goaziou wrote:

 If deemed useful, I think this patch should use
 `org-html--make-attribute-string' instead of hard-coding class
 attribute:

   (attributes (org-html--make-attribute-string
(org-export-read-attribute :attr_html paragraph)))

 ...

   (t (format p%s%s\n%s/p attributes extra contents))

 This way, attributes will not be limited to class only. See, for
 example, `org-html-special-block'.

A version of this patch using Nicolas' approach has been pushed to master.

rick

Re: [O] Export Org checkboxes in ox-html using UTF-8 symbols

[Rick Frankel]

On Sat, Mar 29, 2014 at 03:12:14PM +0100, Marcin Borkowski wrote:
 Dnia 2014-03-28, o godz. 10:59:43
 Rick Frankel r...@rickster.com napisał(a):
 
  On 2014-03-28 10:01, Sebastien Vauban wrote:
   Rick Frankel wrote:
   BTW, i used [nbsp;] for the unchecked box (we use the same for
   checked and trans)... I think i'll change the unchecked box to
   #x2610; to match the checked box (same as sachua).
   
   Isn't it error-prone and very misleading to have 3 different states
   in the Org files, and just 2 different in the HTML exports?
  
 Wouldn't it be better to have (maybe in addition) three distinct
 classes for the li elements with checkboxes in various states?  This
 would make styling them with CSS possible.

The =li= elements for checklists now have the class `on', `off' or
`trans' depending on the state of the checkbox.

Thanx for the suggestion.

rick

Re: [O] Export Org checkboxes in ox-html using UTF-8 symbols

[Rick Frankel]

On 2014-03-29 10:12, Marcin Borkowski wrote:

Dnia 2014-03-28, o godz. 10:59:43
Rick Frankel r...@rickster.com napisał(a):

On 2014-03-28 10:01, Sebastien Vauban wrote:
 Rick Frankel wrote:
 BTW, i used [nbsp;] for the unchecked box (we use the same for
 checked and trans)... I think i'll change the unchecked box to
 #x2610; to match the checked box (same as sachua).

Wouldn't it be better to have (maybe in addition) three distinct
classes for the li elements with checkboxes in various states?  This
would make styling them with CSS possible.


Nice idea. I'll look at adding classes to each (checked, or transient)
=li=. I think that the use of classes is minimal due to the orginal
stand-alone (inline css) nature of the html exporter. I certainly
agree that more modern html output is desireable, but it's a big
project...

rick

Re: [O] Export Org checkboxes in ox-html using UTF-8 symbols

[Rick Frankel]

On 2014-03-28 10:01, Sebastien Vauban wrote:

Rick Frankel wrote:
BTW, i used [nbsp;] for the unchecked box (we use the same for
checked and trans)... I think i'll change the unchecked box to
#x2610; to match the checked box (same as sachua).

Isn't it error-prone and very misleading to have 3 different states in
the Org files, and just 2 different in the HTML exports?


There *are* three different states in the exported file -- the
transient mode is for partially completed rollups:

#+BEGIN_SRC org
,* rollup
- [-] All done
- [X] one
- [ ] two
#+END_SRC

Generates (abbreviated and indented):

#+BEGIN_SRC html
ul class=org-ul
licode[-]/code All done
ul class=org-ul
licode[X]/code one
/li
licode[#xa0;]/code two
/li
/ul
/li
/ul
#+END_SRC

rick

Re: [O] Export Org checkboxes in ox-html using UTF-8 symbols

[Rick Frankel]

On 2014-03-27 04:43, Nicolas Goaziou wrote:

Hello,

Grant Rettke g...@wisdomandwonder.com writes:

Sacha Chua made a nice hack to export checkboxes as unicode symbols to
HTML here:

http://sachachua.com/blog/2014/03/emacs-tweaks-export-org-checkboxes-using-utf-8-symbols/?shareadraft=baba27119_533313c944f64

(defun sacha/org-html-checkbox (checkbox)
Format CHECKBOX into HTML.
(case checkbox (on span class=\check\#x2611;/span) ;
checkbox (checked)
(off span class=\checkbox\#x2610;/span)
(trans code[-]/code)
(t )))
(defadvice org-html-checkbox (around sacha activate)
(setq ad-return-value (sacha/org-html-checkbox (ad-get-arg 0

Thanks Sacha.

There is also:

(setq org-html-checkbox-type 'unicode)


You need a recent Org, though (maybe development version, I didn't 
check).


I didn't apply it in maint, so it's only in master.

BTW, i used [nbsp;] for the unchecked box (we use the same for 
checked and trans)... I think i'll change the unchecked box to #x2610; 
to match the checked box (same as sachua).


rick

Re: [O] [Patch] Few small fixes to html header

[Rick Frankel]

On 2014-03-27 15:57, Marcin Antczak wrote:
I've attached patch below, but I'm affraid that there is something 
wrong

with indentation.
I'm not sure if there is problem with my settings or just entire
ox-html.el is indented badly.


Unfortunately, ox-html is indented with a combination of tabs and
spaces, you can turn on whitespace-mode to see. I'm not sure why your
saving the file has touched areas you didn't edit. Did you do a
re-indent or have a whitespace-cleanup or convert-tabs-to-spaces hook
turned on?


My patch fixes HTML meta data produced on export by ox-html.el

1. Meta charset definition should be set before title as document
title can contain
some unicode symbols etc.


I believe this is the gist of your patch (bug fix?) -- putting the
content-type declaration before the title (it's hard to tell due to
all the changes in your patch)? If so, i don't see the need. Following
is a sample org file w/ a unicode character in the title. It renders
correctly on both internet explorer 9 and chrome 31.0.1650.63, the
only browsers i have available right now. I believe that the meta
content is parsed before the rendering, so the position within the
header is irrelevant.

#+BEGIN_SRC org
,#+TITLE: ☑ \gamma
,#+OPTIONS: toc:nil

,* Test utf-8 title
Put  ☑ \gamma (checkbox and gamma) unicode characters in the title.
#+END_SRC


2. Added viewport declaration as described here:

https://github.com/h5bp/html5-boilerplate/blob/v4.3.0/doc/html.md

here:

https://developer.apple.com/library/safari/documentation/AppleApplications/Reference/SafariWebContent/UsingtheViewport/UsingtheViewport.html


I don't believe it's appropriate to have as a default in ox-html as
the current exporter makes no attempt at responsive design. If you
would like your exported documents to include it, you can use the
HTML_HEAD_EXTRA property on a per-file basis, or customize the
variable `org-html-head-extra'.


3. Fixed unnecessary \n at the end of Description meta.
4. Removed unnecessary spaces in meta tags.


Are these bugs or simply stylistic cleanup?

rick

Re: [O] [Patch] Few small fixes to html header

[Rick Frankel]

On 2014-03-28 11:16, Marcin Antczak wrote:

Rick Frankel writes:

On 2014-03-27 15:57, Marcin Antczak wrote:
I've attached patch below, but I'm affraid that there is something
wrong
with indentation.
I'm not sure if there is problem with my settings or just entire
ox-html.el is indented badly.

Unfortunately, ox-html is indented with a combination of tabs and
spaces, you can turn on whitespace-mode to see. I'm not sure why your
saving the file has touched areas you didn't edit. Did you do a
re-indent or have a whitespace-cleanup or convert-tabs-to-spaces hook
turned on?

Why ox-html is indented in a way that doesn't follow guidelines
described on Emacs Lisp Coding Conventions?


good question. I think because it's actually a very old file.


Could we fix it?


Another good question. Bastien- Do you think it makes sense to do a
whitespace cleanup only commit of ox-html to master?



My patch fixes HTML meta data produced on export by ox-html.el

1. Meta charset definition should be set before title as document
title can contain
some unicode symbols etc.

But it's still bug.

1. Most modern browsers fallback to UTF-8 currently.
2. Charset is often set by server content type.

So, this is why you can see your example rendered correctly.
But there could be a case where it will not render properly.


Not true. This file renders incorrectly when opened from the file
system in ie 9 and chrome:

#+BEGIN_SRC html
html
head
title☑/title
/head
body
p☑ checkbox/p
/body
/html
#+END_SRC

But this one renders correctly:
#+BEGIN_SRC html
html
head
title☑/title
meta http-equiv=Content-Type content=text/html;charset=utf-8 /
/head
body
p☑ checkbox/p
/body
/html
#+END_SRC


From logical point of view - charset should be first. And it's in most
html frameworks such as HTML5 Boilerplate, Twitter Bootstrap etc.


That may be, but it's a stylistic issue, not a bug. My read of the
html dtd does not specify the order of elements in the head. Can you
show me an example where the order of the elements causes incorrect
display of the title?



2. Added viewport declaration as described here:

https://github.com/h5bp/html5-boilerplate/blob/v4.3.0/doc/html.md

here:

https://developer.apple.com/library/safari/documentation/AppleApplications/Reference/SafariWebContent/UsingtheViewport/UsingtheViewport.html

I don't believe it's appropriate to have as a default in ox-html as
the current exporter makes no attempt at responsive design. If you
would like your exported documents to include it, you can use the
HTML_HEAD_EXTRA property on a per-file basis, or customize the
variable `org-html-head-extra'.

Ok.

3. Fixed unnecessary \n at the end of Description meta.
4. Removed unnecessary spaces in meta tags.

Are these bugs or simply stylistic cleanup?

3. This is a bug for me. Meta shouldn't render closing  in new
line.


Does it cause output which is incorrectly displayed? Otherwise it's
not really a bug, but i will look at changing it the next time i need
to touch the file.

I'm worried about touching (4) w/o tests, as sometimes attributes are
concatenated, and removing a leading whitespace could cause breakage.

While source whitespace and output formatting are annoying, our
approach to modifications of this (quite old) file has been to not
make changes which don't materially affect functionality or fix bugs
(the rule of least damage :).

rick

Re: [O] Zotero: import HTML -- org syntax?

[Rick Frankel]

On 2014-03-28 10:43, Matt Price wrote:

Hi,

(1) is there already an HTML import function that I just don't know 
about?


Have you looked at pandoc:

http://johnmacfarlane.net/pandoc/

rick

Re: [O] A problem with publishing

[Rick Frankel]

On 2014-03-28 00:44, Marcin Borkowski wrote:

Dnia 2014-03-26, o godz. 09:26:15
Rick Frankel r...@rickster.com napisał(a):

On 2014-03-23 17:01, Marcin Borkowski wrote:
BTW, org-publish has built-in support for pushing to a remote server.
You can use a tramp url as the publishing-directory, bypassing the
completion function.

I know, but I read in the manual that it may not be the fastest thing
in the world.  (In fact, I use a very simple Makefile, which in turn
uses rsync, so it /might/ indeed be faster, not copying unnecessary
stuff.  Not sure whether Emacs+Tramp would do it.)



Org publish uses a timestamp cache, so while the wire protocol may be
slower, it doesn't copy unnecessary files and doesn't need to
communicate with the remote host to decide which files to copy.

Bonus of course is that the org-publish approach is self-contained
and reproducible.

rick

Re: [O] A problem with publishing

[Rick Frankel]

On 2014-03-23 17:01, Marcin Borkowski wrote:

Hi list,

publishing doesn't work.  I guess that I broke something;).  May the
source and publishing directories be the same?  I have this in my
init.el:

(setq org-publish-project-alist
'((fnis2014
:base-directory ~/directory
:publishing-directory ~/directory
:base-extension org\\|css\\|jpg\\|png
:publishing-function org-reveal-export-to-html
:completion-function (lambda () (compile make install)

The make install means just rsync'ing to a remote server.

When I export (C-c C-e R R) and then publish (C-c C-e P x) (or
M-x compile), everything is ok.  When I just publish, changes seem
not to be pushed to the remote server, and I'm left with some *Org
export* process buffers.


My guess is that using *-export-to-html as the publishing function is
the culprit. There should/needs to be an org-reveal-publish-to-html
publishing function. I'm guessing the reason it works when you
manually export is that since the html file is up-to-date vis. the org
source, the code path bypasses that step (and just runs the completion
function).

If org-reveal doesn't have a publishing function, try (not tested):

(lambda (plist filename pubdir)
(org-publish-org-to 'reveal filename .html plist pubdir))

BTW, org-publish has built-in support for pushing to a remote server.
You can use a tramp url as the publishing-directory, bypassing the
completion function.

rick

Re: [O] org-html5presentation

[Rick Frankel]

On 2014-03-25 09:31, Dov Grobgeld wrote:

Rick Frankel's ox-slidy.el from:

http://lists.gnu.org/archive/html/emacs-orgmode/2013-10/msg00781.html 
[3]


also works really well for me. He is just to modest to let you know 
himself. :-)


Actually, i forgot i did the slidy port (it was a quick hack because 
someone wanted to use slidy)! I currently use ox-deck (also mine) for my 
presentations, i like the clean (swiss) presentation style w/o fancy 
transitions and colors, so reveal is a bit overkill for me.


rick

Re: [O] Fwd: Question: how to disable htmlize during exporting?

[Rick Frankel]

On 2014-03-25 08:29, Kelvin Hu wrote:

2014-03-25 16:25 GMT+08:00 Bastien b...@gnu.org:

I'd try to set `org-html-htmlize-output-type' to nil but I didn't
test.  If it does not work, this is a bug.

Thanks for your reply, I have tried this approach, but it reports
error: (void function nil).
Per the definition in `ox-html.el', it must be either 'inline-css or 
'css.




But it's an excellent idea. I have a patch to ox-html which will allow 
ox-htmlize-output type to be set to `nil', to explicitly return plain 
text.


I will push it to master tonight when i get out from behind the 
firewall...


rick

P.S. Attached for review...
From b49fa8b36b983f32ca9ff090eec0be7ff45a50c3 Mon Sep 17 00:00:00 2001
From: Rick Frankel r...@rickster.com
Date: Tue, 25 Mar 2014 11:27:07 -0400
Subject: [PATCH] Allow disabling of htmlization in ox-html export.

* lisp/ox-html.el (org-html-htmlize-output-type): Add `nil'
  option (no htmlization).
(org-html-fontify-code): Return plain text if
`org-html-htmlize-output-type' is `nil'.
---
 lisp/ox-html.el | 13 +
 1 file changed, 9 insertions(+), 4 deletions(-)

diff --git a/lisp/ox-html.el b/lisp/ox-html.el
index 52795a3..a843441 100644
--- a/lisp/ox-html.el
+++ b/lisp/ox-html.el
@@ -756,9 +756,10 @@ link's path.
 
 (defcustom org-html-htmlize-output-type 'inline-css
   Output type to be used by htmlize when formatting code snippets.
-Choices are `css', to export the CSS selectors only, or `inline-css', to
-export the CSS attribute values inline in the HTML.  We use as default
-`inline-css', in order to make the resulting HTML self-containing.
+Choices are `css' to export the CSS selectors only,`inline-css'
+to export the CSS attribute values inline in the HTML or `nil' to
+export plain text.  We use as default `inline-css', in order to
+make the resulting HTML self-containing.
 
 However, this will fail when using Emacs in batch mode for export, because
 then no rich font definitions are in place.  It will also not be good if
@@ -771,7 +772,7 @@ all the faces you are interested in are defined, for example by loading files
 in all modes you want.  Then, use the command
 \\[org-html-htmlize-generate-css] to extract class definitions.
   :group 'org-export-html
-  :type '(choice (const css) (const inline-css)))
+  :type '(choice (const css) (const inline-css) (const nil)))
 
 (defcustom org-html-htmlize-font-prefix org-
   The prefix for CSS class names for htmlize font specifications.
@@ -1894,6 +1895,10 @@ is the language used for CODE, as a string, or nil.
   (message Cannot fontify src block (htmlize.el = 1.34 required))
   ;; Simple transcoding.
   (org-html-encode-plain-text code))
+ ;; Case 3: plain text explicitly set
+ ((not org-html-htmlize-output-type)
+  ;; Simple transcoding.
+  (org-html-encode-plain-text code))
  (t
   ;; Map language
   (setq lang (or (assoc-default lang org-src-lang-modes) lang))
-- 
1.8.0

Re: [O] org-html5presentation

[Rick Frankel]

On Sun, Mar 23, 2014 at 07:00:17PM +0100, Marcin Borkowski wrote:
 Dnia 2014-03-23, o godz. 18:52:35
 Bastien b...@gnu.org napisał(a):
 
  Rustom Mody rustompm...@gmail.com writes:
  
   Just checked with org 7.something (dunno for sure since org-version
   does not work -- I had kept around an old directory in case of
   upgrade hiccups)

  So you get the answer: it works with 7.5 but not with recent Org.
  I suggest to ping the author to let him know he needs to update
  the code.
  
 
 Just my 2 cents: I've just tried org-reveal and it works like a charm.

There are also s5 (ox-s5) and deck.js (ox-deck) exporters in contrib ;).

rick

Re: [O] [patch][ox-html] Stylistic changes

[Rick Frankel]

On 2014-03-18 15:46, Rasmus wrote:

Rick Frankel r...@rickster.com writes:

On 2014-03-17 23:36, Rasmus wrote:
When you refer above to utf-8 entities, do you mean the named html
entities (e.g., lt;) or the actual utf-8 encoded characters?

The latter.  Do M-x describe-char on such an character.  Emacs will
tell you the code points.  My conjecture is therefore that one could
write a script that would translate html values to these weird hex
string or codepoints.  It would create more ugly source output, but
perhaps better for XHTML.  Personally, I don't care about XHTML as I
have little intuition as to when to use. . .


Do you close the empty tags in your html (e.g., br /, hr /)? Then
you're using xhtml.


I believe the named entities are encoding independent, while including
encoded characters in html output is fine -- although making sure the
page is served with the correct character encoding is another issue
entirely.

Not what I meant.  I'm only addressing your concern about
HUMAN-READABLE-NAME; vs %HEX-VALUE;.

As to using a more extensive set of named entities, as i said above,
the problem is that the xhtml flavors don't support them, and I don't
see any advantage in making the exporter handle character encoding
differently based on ouput doctype.

Definitely not.  Why I ask if there's a point in changing nice
entities to ugly entities for the sake of not getting them in
XHTML-encoded documents.


Yes we should. You can't properly post-process the html if it's
invalid xml. And the definition of pretty and ugly are subjective.

The question is, do we want to generate valid (x)html or not? My vote
is yes. In our case, html is an output format and not a source format.
In fact, we should probably compress out unnecessary whitespace, etc.
the way other web generators do to make the smallest/most efficent
output for webserving.


As Nicolas would point out, you can always use a filter to map all the
entities in the output.

With ox-latex.el we for instance don't include entities that are not
supported by the default package alist.  A similar concern could be at
play here.


Agreed.

Re: [O] [patch][ox-html] Support for level based containers

[Rick Frankel]

On 2014-03-18 15:41, Rasmus wrote:

Rick Frankel r...@rickster.com writes:
On 2014-03-17 23:31, Rasmus wrote:



A general rule is that the section element is appropriate only if
the element's contents would be listed explicitly in the
document's outline.



So, using this definition, in html5, the wrappers should be =sections=
to the same level as the toc heading level specified for the document,
and =divs= after.[1]

So you want it to be section until h:N?  That should be easy.

1. The default should stay the same as it is now -- the string div

As you prefer.

But, after reviewing the spec (see above vis. =section= and
=article=), i would submit that a better patch would be to
implement [1] above -- remove the defcustom (i only added to support
using a different default wrapper element in html5), and use =section=
and =div= based on toc level when html5-fancy is true. As far as i can
tell from the spec, =article= would almost never be correct for the
average org doc. Here's a relevant quote from the spec:

OK.  That certainly makes it easier.  But should it not then be a cons
or an alist specifying which container to use when the headline level
is above or below h:N and deepening on whether html5-fancy is used?


Not really necessary. It's overly complex with no obvious advantage. I
guess the right question to ask is (it may have been mentioned much
earlier in the thread) -- what problem does the patch solve?


Authors are encouraged to use the article element instead of the
section element when it would make sense to syndicate the contents
of the element.

So blogs, technical docs and similar?  I can see people using Org such
things?  Or do W3-people thinkg of something different when they say
it is syndicatable


Yes, a a blog is the prototypical example -- but only the index page,
where multiple articles are concatenated into a single page.

Most likely, an org document implementing this would have the
=article=s (indvidual blog posts) at level 1, and sections below.

In the most common use, the  =article= would probably be the outer
wrapper around the entire body section of the output, and would be set
as the content wrapper in =org-html-divs=. BTW, the html5 version of
=org-html-divs= would be:

#+BEGIN_SRC emacs-lisp
'((preamble  header preamble)
(content   article content)
(postamble footer postamble))
#+END_SRC


I think the best way to implement this would be letting the user
specify it with the =HTML_CONTAINER= property already implemented. As
this seems very much in keeping with the spec, i will implement this
change when i have some time in the next couple of weeks if i don't
hear any strong arguments against.

I can change my patch to this behavior if you want.  Though I think
it's pretty strong to hardcode values, as one would might have reasons
to change it in say an ox-publish project.


Using =PROPERTIES= on org heading is not really hardcoding. It's the
org-way of associating things with document sections/headings.

To recap, I don't really see a compelling reason to specify a
hierarchy of wrappers specific to html5-fancy output. After reviewing
the spec, i do see the value in wrapping org document sections in
=section= tags per the rules in [1] above (from previous email).

rick

Re: [O] [patch][ox-html] Stylistic changes

[Rick Frankel]

On 2014-03-17 23:36, Rasmus wrote:

Rick Frankel r...@rickster.com writes:

On Mon, Mar 17, 2014 at 11:19:27PM +0100, Rasmus wrote:
Hi Rick,


Rick Frankel r...@rickster.com writes:

 On Mon, Mar 17, 2014 at 03:17:10AM +0100, Bastien wrote:
 Hello,

 Nicolas Goaziou n.goaz...@gmail.com writes:

  So if the change is only stylistic, I see no reason to break
  compatibility with ox-freemind.el.

 I would favor a solution where the HTML backend uses what's
 readable (mdash; and friends) and where the Freemind backend
 deals with this.

 Maybe `org-html-special-string-regexps' could be a variable
 and Freemind could temporarily set it up to what it needs?

 The use of numeric vs. named entities is not just stylistic.
 XHMTL[45] only support the 5 basic named entities interally:

   - amp; - the ampersand 
   - quot; - the double quote 
   - apos; single quote '
   - lt; - less-than 
   - gt; - greater-than 

 So including any others will generate non-conforming output.
 Since the change is cosmetic, I don't see the purpose in adding a lot
 of conditional code to the exporter to output different entities for
 html[45] vs xhtml[45].

AFAIK, we have a lot more entities in org-entities with PRETTY-NAME;.
When I've entities I've used a pretty name over a numeric value when I
found one.  What's you'r opinion on that?  Should we go for readable
or aim towards replacing them with these numeric values?

We should use only those named entities (above) which are valid in
xhtml(5). So, yes, we should change to using numeric entites for any
other than the above.

Since Emacs knows both the codepoints and the hex for utf8 entities it
may be fairly simple to change the HTML representations, though I
don't like it. . .


When you refer above to utf-8 entities, do you mean the named html
entities (e.g., lt;) or the actual utf-8 encoded characters?

I believe the named entities are encoding independent, while including
encoded characters in html output is fine -- although making sure the
page is served with the correct character encoding is another issue
entirely.

As to using a more extensive set of named entities, as i said above,
the problem is that the xhtml flavors don't support them, and I don't
see any advantage in making the exporter handle character encoding
differently based on ouput doctype.

As Nicolas would point out, you can always use a filter to map all the
entities in the output.

rick

Re: [O] [patch][ox-html] Support for level based containers

[Rick Frankel]

On 2014-03-17 23:31, Rasmus wrote:

It's a variable that you can set in your project or in your Org file
or in your init file.  I don't see why div × 3 is better than section
article div or something else conditional on two variables being
explicitly set to get fancy HTML5. . .  In any case, I don't have
strong—if any—preferences on this.


Because using these tags is assigning semantic meaning which may or
may not be valid for the current document. Based on the spec, your use
of =section= seems ok (but could also be used for the other levels),
but your use of =article= is probably wrong in most cases. From
http://www.w3.org/html/wg/drafts/html/master/sections.html#the-article-element:

The article element represents a complete, or self-contained,
composition in a document, page, application, or site and that is,
in principle, independently distributable or reusable, e.g. in
syndication. This could be a forum post, a magazine or newspaper
article, a blog entry, a user-submitted comment, an interactive
widget or gadget, or any other independent item of content.

As to the =section= element, the from the above doc:

The section element represents a generic section of a document or
application. A section, in this context, is a thematic grouping of
content. The theme of each section should be identified, typically
by including a heading (h1-h6 element) as a child of the section
element.

and

A general rule is that the section element is appropriate only if
the element's contents would be listed explicitly in the
document's outline.

So, using this definition, in html5, the wrappers should be =sections=
to the same level as the toc heading level specified for the document,
and =divs= after.[1]


org-html-text-markup-alist is nice.  What do you want to see in
addition to the current structure (in patch v2)?

Somehow I never saw the original thread, only the email cc'ing me
directly. I went to gmane to find the patch, and obviously grabbed the
wrong one.

Could you please send me the (new) patch so that i can review it?

Here's the Gmane link.  I believe it's different than what you
reviewed before, but perhaps I'm wrong. . .


No, i got the wrong patch from gmane. This one looks better modulo:

1. The default should stay the same as it is now -- the string div
2. Minor typo, but backward comparability should be backwards
compatibility.

But, after reviewing the spec (see above vis. =section= and
=article=), i would submit that a better patch would be to
implement [1] above -- remove the defcustom (i only added to support
using a different default wrapper element in html5), and use =section=
and =div= based on toc level when html5-fancy is true. As far as i can
tell from the spec, =article= would almost never be correct for the
average org doc. Here's a relevant quote from the spec:

Authors are encouraged to use the article element instead of the
section element when it would make sense to syndicate the contents
of the element.

I think the best way to implement this would be letting the user
specify it with the =HTML_CONTAINER= property already implemented. As
this seems very much in keeping with the spec, i will implement this
change when i have some time in the next couple of weeks if i don't
hear any strong arguments against.

As an aside, the complex semantics of the new html5 tags is why we
have been slow in implementing them in ox-html. =div= is by
definition a non-semantic tag meant to be used for grouping and
styling, but the new tags have very specific meanings associated with
them and their mis-use is worse than their non-use.

rick

Re: [O] How to use an image as an anchor in HTML export?

[Rick Frankel]

On 2014-03-18 11:46, William Denton wrote:

I would like to use an image as an anchor in an HTML export
(specifically in a reveal.js export---I really like this). I can't
figure out how to make it work, and just end up with either a link
with a missing image or an image with no link. I don't see this
documented.  Is it possible?

What I want to end up with in the output is something like:

a href=foo.htmlimg src=./images/foo.jpg/a



#+BEGIN_SRC org
,* Test image link
[[http://example.com][file:image1.png]]
#+END_SRC

which generates (with subtree export):

#+BEGIN_SRC html
!DOCTYPE html
html xmlns=http://www.w3.org/1999/xhtml; lang=en xml:lang=en
head
titleTest image link/title
meta  charset=utf-8 /
meta  name=generator content=Org-mode /
meta  name=author content=Rick Frankel /
link rel=stylesheet href=org.css /
/head
body
div id=content
h1 class=titleTest image link/h1

div class=figure
pa href=http://example.com;img src=image1.png alt=image1.png 
//a

/p
/div
/div
/body
/html
#+END_SRC

Re: [O] [patch][ox-html] Stylistic changes

[Rick Frankel]

On Mon, Mar 17, 2014 at 03:17:10AM +0100, Bastien wrote:
 Hello,

 Nicolas Goaziou n.goaz...@gmail.com writes:

  So if the change is only stylistic, I see no reason to break
  compatibility with ox-freemind.el.

 I would favor a solution where the HTML backend uses what's
 readable (mdash; and friends) and where the Freemind backend
 deals with this.

 Maybe `org-html-special-string-regexps' could be a variable
 and Freemind could temporarily set it up to what it needs?

The use of numeric vs. named entities is not just stylistic.
XHMTL[45] only support the 5 basic named entities interally:

  - amp; - the ampersand 
  - quot; - the double quote 
  - apos; single quote '
  - lt; - less-than 
  - gt; - greater-than 

So including any others will generate non-conforming output.
Since the change is cosmetic, I don't see the purpose in adding a lot
of conditional code to the exporter to output different entities for
html[45] vs xhtml[45].

rick

Re: [O] [patch][ox-html] Support for level based containers

[Rick Frankel]

On Mon, Mar 17, 2014 at 03:15:50AM +0100, Bastien wrote:
 Hi Rasmus and Nicolas,

 Nicolas Goaziou n.goaz...@gmail.com writes:

  Let me know if you find you'd be willing to merge something like this
 
  I don't know enough HTML to have an opinion here.


I don't think it's a bad change, but i have a couple of concerns:

1. It's a breaking change.
2. The default should mimic the current functionality:
   ='((div . div))=
3. The customization should be more structured, not just a
   string (see e.g., =org-html-text-markup-alist=.)

Attached is a modification of the patch which fixes 2  3. #1 is a
question more for Nicolas  Bastien...

rick
From 21aed5d34613f9f922c2d1c8f5f67caac918c9cf Mon Sep 17 00:00:00 2001
From: Rick Frankel git...@rickster.com
Date: Mon, 17 Mar 2014 13:27:12 -0400
Subject: [PATCH] Support for heading level based containers in ox-html.

* ox-html.el (org-html-container-element): Change to list of cons
cells for heading level containers.
(org-html--container): Use heading level entries from
org-html-container-element.
---
 lisp/ox-html.el | 27 +++
 1 file changed, 19 insertions(+), 8 deletions(-)

diff --git a/lisp/ox-html.el b/lisp/ox-html.el
index cb95161..b51a746 100644
--- a/lisp/ox-html.el
+++ b/lisp/ox-html.el
@@ -938,17 +938,23 @@ versions 8 and below.
   :package-version '(Org . 8.0)
   :type 'boolean)
 
-(defcustom org-html-container-element div
-  HTML element to use for wrapping top level sections.
+(defcustom org-html-container-element '((div . div))
+
+  HTML elements to use for wrapping sections.
 Can be set with the in-buffer HTML_CONTAINER property or for
 publishing, with :html-container.
 
-Note that changing the default will prevent you from using
-org-info.js for your website.
+Should be a list of cons cells with positions corresponding to
+heading levels.  If `org-html-html5-fancy' is t the cdr is used
+otherwise the car.
+
+Note that changing the default will prevent you from
+using org-info.js for your website.
   :group 'org-export-html
   :version 24.4
   :package-version '(Org . 8.0)
-  :type 'string)
+  :type '(alist :key-type (string :tag HTML4)
+   :value-type (string :tag HTML5)))
 
 (defcustom org-html-divs
   '((preamble  div preamble)
@@ -2410,9 +2416,14 @@ holding contextual information.
 
 (defun org-html--container (headline info)
   (or (org-element-property :HTML_CONTAINER headline)
-  (if (= 1 (org-export-get-relative-level headline info))
- (plist-get info :html-container)
-   div)))
+  (let* ((hc (plist-get info :html-container))
+(n (org-export-get-relative-level headline info)))
+   (cond ((listp hc)
+  (or (funcall (if org-html-html5-fancy 'cdr-safe 'car-safe)
+   (nth (1- (min n (length hc))) hc)) div))
+ ((and (stringp hc) (= 1 n))
+  (plist-get info :html-container))
+ (t div)
 
  Horizontal Rule
 
-- 
1.8.5.2 (Apple Git-48)

Re: [O] [patch][ox-html] Support for level based containers

[Rick Frankel]

On Mon, Mar 17, 2014 at 11:26:28PM +0100, Rasmus wrote:
 Rick Frankel r...@rickster.com writes:

  On Mon, Mar 17, 2014 at 03:15:50AM +0100, Bastien wrote:
  Hi Rasmus and Nicolas,
 
 
  Nicolas Goaziou n.goaz...@gmail.com writes:
 
   Let me know if you find you'd be willing to merge something like this
  
   I don't know enough HTML to have an opinion here.
 
 
  I don't think it's a bad change, but i have a couple of concerns:
 
  1. It's a breaking change.
  2. The default should mimic the current functionality:
 ='((div . div))=
  3. The customization should be more structured, not just a
 string (see e.g., =org-html-text-markup-alist=.)
 
  Attached is a modification of the patch which fixes 2  3. #1 is a
  question more for Nicolas  Bastien...

 It seems you modified v1 rather than v2 that I send last night¹?  I'm
 not sure if point 1 holds in the second revision as it explicitly
 allows for a string as now. I think I disagree with your point 2 as it
 only shows up when you use HTML5-fancy.  On point 3,

But not everyone using html5-fancy would agree with your choice of
hierarchy, and it should be up to indvidual users to add additional
semantic structure to the output.

 org-html-text-markup-alist is nice.  What do you want to see in
 addition to the current structure (in patch v2)?

Somehow I never saw the original thread, only the email cc'ing me
directly. I went to gmane to find the patch, and obviously grabbed the
wrong one.

Could you please send me the (new) patch so that i can review it?

thanx,
rick

Re: [O] font-lock error on html export with src blocks

[Rick Frankel]

On 2014-02-27 10:00, Matt Price wrote:


face-attribute: Wrong type argument: symbolp, (quote 
font-lock-constant-face)



Did you try with emacs -Q?

Have you tried resetting the definition of font-lock-constant-face?

rick

Re: [O] css classes to tables in html export

[Rick Frankel]

On Tue, Feb 18, 2014 at 06:08:50PM +0100, Vikas Rawal wrote:
 Sorry, you forgot to reply to the mailing list. I am copying mailing
 list in my reply. I hope it sticks to the thread.

 My intent was to add classes, so that when I export to html, I get
 something like this:

 Table class=table table-striped table-bordered table-condensed

So, use the class attribute.

#+ATTR_HTML: :class table table-striped table-bordered table-condensed
| a | b | c |
|---+---+---|
| 1 | 2 | 3 |

table border=2 cellspacing=0 cellpadding=6 rules=groups frame=hsides 
class=table table-striped table-bordered table-condensed



 On Mon, Feb 17, 2014 at 03:22:13PM -0500, Rick Frankel wrote:
  On Sun, Feb 16, 2014 at 10:31:04PM +0100, Vikas Rawal wrote:
   How do I add custom css classes to tables while publishing my project?
  
 
  * Table attributes
  This
  #+BEGIN_EXAMPLE
  #+ATTR_HTML: :style background-color:grey :cellpadding 1em
  | a | b | c |
  |---+---+---|
  | 1 | 2 | 3 |
  #+END_EXAMPLE
 
  results in this:
 
  #+BEGIN_HTML
  table border=2 cellspacing=0 cellpadding=1em rules=groups 
  frame=hsides style=background-color:grey
 
  colgroup
  col  class=right /
 
  col  class=right /
 
  col  class=right /
  /colgroup
  thead
  tr
  th scope=col class=righta/th
  th scope=col class=rightb/th
  th scope=col class=rightc/th
  /tr
  /thead
  tbody
  tr
  td class=right1/td
  td class=right2/td
  td class=right3/td
  /tr
  /tbody
  /table
  /div
  /div
  #+END_HTML
 
 
  rick

Re: [O] Proposal/request for input: slidify export for html slides

[Rick Frankel]

On Thu, Jan 30, 2014 at 12:57:46AM +, Ahmadou Dicko wrote:
I love slidify too and I think that having similar functionnality in org
could be great.
I think that you have everything to do that using the html backend, you
just need to interface the right Javascript/HTML5 library.
In slidify you can use io2012, deck.js, shower and landslide and I know
that you can use deck.js through ox-deck and it will not be difficult to
create and interface for other library too.
For example if you need a nice non Beamer library you can also check
ox-reveal which interface reveal.js.

Just to follow-up and expand. It looks like slidy is an interface for
Rstudio to a number of html slide (javascript) libraries, and uses
markdown as it markup language, while providing the ability to execute
R code interspersed with the markup (literate programming/reproducable
results)

Org is it's own markup language and allow interspersing executable
code (and its output) in a literate, reproducable way
(babel). Including, but not limited to, R.

In addion org has export interfaces to multiple output types. For
slideshow there are (at least):

  - ox-s5
  - ox-deck
  - ox-reveal
  - beamer

As well as pdf, html and others.

So it doesn't seem to make sense to use org as a frontend to Rstudio,
but i may be wrong...

rick

Re: [O] Org heading properties in code block?

[Rick Frankel]

On 2014-01-21 14:08, Christopher Kotfila wrote:

Is it possible to include org heading properties directly in
codeblocks on tangle?



** Some Subheading
:PROPERTIES:
:FOO: bar
:END:

#+BEGIN_SRC emacs-lisp :tangle /path/to/.dir-locals.el :noweb yes
((python-mode . ((some-var . FOO

#+END_SRC



how about:

* As a variable
:PROPERTIES:
:header-args: :var foo=bar
:END:

#+BEGIN_SRC emacs-lisp
foo
#+END_SRC
* As a noweb source block

#+name: foo
#+BEGIN_SRC emacs-lisp :exports none :eval never
bar
#+END_SRC

#+BEGIN_SRC emacs-lisp :noweb yes
(foo . foo)
#+END_SRC

rick

Re: [O] [BUG] Testing fails after rename of ob-sh

[Rick Frankel]

On 2014-01-17 12:34, Eric Schulte wrote:

Achim Gratz strom...@nexgo.de writes:

What commit were you on before the pull and what branch/commit are you
on now?  Also, what's the output of make config-test (if you've added
sh to BTEST_OB_LANGUAGES, simply remove it).


I believe Achim's suggestion should be the correct one.  See the 
comment

of the commit making this change.

,
| commit b319475a86451defbdbac064684dd59fd6b0b7d0
| Author: Eric Schulte schulte.e...@gmail.com
| Date:   Fri Dec 13 10:03:05 2013 -0700
|
| fix tests with the renamed ob-shell.el
|
|   Note, users may have to edit their local.mk files to change the
|   value of BTEST_OB_LANGUAGES to remove sh and include shell.
`


Guess I missed that commit message. I looked at the original commit
but not the fix.

FWIW, I ran it with an clean checkout (but copied my old local.mk), so
I guess the issue is that the orginal genaration of local.mk added sh
to the list of languages (i never added it manually).

I think this is going to bite a lot of people using the master branch.

rick

Re: [O] Buffer local alias?

[Rick Frankel]

On 2014-01-16 11:44, Achim Gratz wrote:

Andreas Leha writes:
Yes, I know.  That's why I am sighing a bit:  Both approaches need work
or are inconvenient in one way or the other.

That trait of reproducibility is shared with security.  You might want
to have alook at this:

https://www.vagrantup.com/

(no direct experience yet).


FWIW, I've just started using vagrant and virtualbox for creating a
reproducible development environment for a ruby-on-rails class I am
teaching.

So far, it's great. Trying to get students to setup a rails dev
environment, esp. on windows, is extremely difficult. With vagrant I
have created a script which will build an ubuntu vm with everything
needed (ruby, postgres, etc.) installed and configured. (Identical
every time modulo 'apt-get upgrade'.). I then distribute THAT to the
students (via vagrant), guaranteeing they are all working on identical
virtual machines.

rick

[O] [BUG] Testing fails after rename of ob-sh

[Rick Frankel]

Eric-

After doing a git pull including the rename of ob-sh.el to
ob-shell.el, testing fails with the error:

Cannot open load file: no such file or directory, ob-sh

rick

Re: [O] [RFC] img vs object in HTML export

[Rick Frankel]

On Sat, Jan 11, 2014 at 10:21:39AM +0100, Bastien wrote:
 Rick Frankel r...@rickster.com writes:
 
  I thing the solution is to use an object tag for svg, but an img
  tag for the rest.
 
 Yes -- I'm no HTML guru, but this corresponds to what I see in most
 HTML pages.

Change applied. You can use the html attribute ':fallback' to specify
a fallback image file.e.g.

  #+ATTR_HTML: :width 100 :height 50 :fallback my.png
  [[file:my.svg]]

rick

Re: [O] Bug: s5-export: Improved title template default. [8.2.1 (8.2.1-dist @ /usr/share/emacs/site-lisp/org-mode/)]

[Rick Frankel]

On Sat, Jan 11, 2014 at 02:27:01AM +0100, Arne Babenhauserheide wrote:
 The following in ox-s5.el should fix this:
 
 (defcustom org-s5-title-slide-template
   h1%t/h1
 h3%a/h3
 h4%e/h4
 h4%d/h4

applied in maint and master.

Re: [O] colorize html output when batch exporting

[Rick Frankel]

On 2014-01-15 03:04, Alan Schmitt wrote:

Quick summary: I'm now able to generate the css, but I don't understand
how it can change the colors.



However, I still find there is a problem. Here is the html source
generated from a snippet of the file:

#+BEGIN_SRC html
div class=org-src-container

pre class=src src-coqInductive expr :=
| expr_this : expr
| expr_identifier : string -gt; expr
| expr_literal : literal -gt; expr
| expr_object : list (propname * propbody) -gt; expr
| expr_function : option string -gt; list string -gt; funcbody -gt; 
expr

| expr_access : expr -gt; expr -gt; expr
| expr_member : expr -gt; string -gt; expr
| expr_new : expr -gt; list expr -gt; expr
| expr_call : expr -gt; list expr -gt; expr
| expr_unary_op : unary_op -gt; expr -gt; expr
| expr_binary_op : expr -gt; binary_op -gt; expr -gt; expr
| expr_conditional : expr -gt; expr -gt; expr -gt; expr
| expr_assign : expr -gt; option binary_op -gt; expr -gt; expr
/pre
/div
#+END_SRC

I don't understand how things are supposed to be colorized, as there is
no mention in the html of span elements to put color on. For instance,
Inductive is a keyword, and in a coq buffer it has face
font-lock-keyword-face. Shouldn't it have class org-keyword in the
generated html?


Yes, it should. Something is not right with your output. I'm not
familiar with coq, and i don't have coq-mode.el, but from the above it
looks like a BNF grammar. Are you sure coq-mode was loaded when you
did the export? Could you try a simple example? Here's a mimimal org
file

#+BEGIN_SRC org
,#+OPTIONS: html-postamble:nil html-preamble:nil html-scripts:nil 
html-style:nil

,#+HTML_HEAD_EXTRA:  link rel=stylesheet href=org.css /
,#+HTML_DOCTYPE: xhtml5

,* Test htmlize
,*Note:* =org-html-htmlize-output-type= is  ~css~

,#+BEGIN_SRC perl :exports code
print foo\n;
,#+END_SRC
#+END_SRC

and the results i get:

#+BEGIN_HTML
!DOCTYPE html
html xmlns=http://www.w3.org/1999/xhtml; lang=en xml:lang=en
head
titlehtml/title
meta  charset=utf-8 /
meta  name=generator content=Org-mode /
meta  name=author content=Rick Frankel /
link rel=stylesheet href=org.css /
/head
body
div id=content
h1 class=titlehtml/h1
div id=table-of-contents
h2Table of Contents/h2
div id=text-table-of-contents
ul
lia href=#sec-1Test htmlize/a/li
/ul
/div
/div

div id=outline-container-sec-1 class=outline-2
h2 id=sec-1Test htmlize/h2
div class=outline-text-2 id=text-1
p
bNote:/b codeorg-html-htmlize-output-type/code is  
codecss/code

/p
div class=org-src-container

pre class=src src-perlspan 
class=org-cperl-nonoverridableprint/span span 
class=org-stringfoo\n/span;

/pre
/div
/div
/div
/div
/body
/html
#+END_HTML

Re: [O] colorize html output when batch exporting

[Rick Frankel]

On 2014-01-14 08:45, Alan Schmitt wrote:

Hello,

I'm trying to batch export a file, and I don't seem to have 
colorization

working. Reading the documentation a bit, I found this information:

Following these instructions, I set up this variable in the init.el
called upon batch exporting, among other things:



Unfortunately I could not complete the next step (to get a start on the
css file), as `org-html-htmlize-generate-css` results in an error
face-attribute: Invalid face: font-lock-comment. I tried to toggle
debug on error, but it does nothing.

Are there suggestions on how to generate this css file for a nice
coloring of my code?


Which version of emacs are you using? FWIW, I just had this problem
yesterday (although it choked on a different face) in emacs trunk
(24.4.x). But on my machine @work on (24.3.8) it is working fine.

It seems that htmlize is choking on invalid face definitions.
Somewhere you have a reference to a face font-lock-comment which
does not exist (the correct definition in this case is
font-lock-comment-face), so if you can find the customization that
refers to font-lock-comment and fix it you should be able to
generate the CSS.

rick

Re: [O] [RFC] img vs object in HTML export

[Rick Frankel]

On 2014-01-09 16:10, Nick Dokos wrote:


Exporting this to HTML produces img tags like this:

,
| div class=figure
| pimg src=foo.svg alt=foo.svg /
| /p
| /div
|
|
| div class=figure
| pimg src=foo.png alt=foo.png /
| /p
| /div
`

I attach a patch[fn:1] that changes these to object tags (the patch 
is

proof-of-concept only, not meant for integration into org core - it'll
need a fair amount of work before that happens, if it ever happens.)
With the patch, the relevant output is changed to this:

,
| div class=figure
| pobject data=foo.svg type=image/svg+xml /object
| /p
| /div
|
|
| div class=figure
| pobject data=foo.png type=image/png /object
| /p
| /div
`
Open questions
Do I have this right? I'm neither an SVG nor an HTML expert. If there 
is

another way to do what I want, please let me know.

Do most browsers support object tags? Do they do the right thing with
images in object tags?



BTW, I tried using



object data=foo.png type=image/png/


This does not work because the close tag is required according to the
spec (like a script tag).

From a quick read on the interwebs, yes, it seems that object is an
html4 specification. One problem with your solution, is that object
does not allow an 'alt' attribute

The problem w/ img src='foo.svg/ according to my reading, is that
it is not officially supported, and is only incidentally supported by
the browsers (but, as you can see, without svg interactivity).

I thing the solution is to use an object tag for svg, but an img
tag for the rest. It might also make sense to just inline the svg?

see:
http://www.w3.org/Graphics/SVG/IG/resources/svgprimer.html#SVG_in_HTML
for an interesting writeup on the issues.

rick

Re: [O] Org Table Export to Markdown Table Question

[Rick Frankel]

On 2014-01-08 15:41, Aric wrote:
I am trying to use org-mode now with R code in it to write manuscripts. 
That

does unfortunately mean that it must be eventually exported to some doc
format. I have been able to export to markdown and everything looks 
good in
markdown (even previewed on github) with the exception of latex code 
which is
not converted. However, using pandoc to convert the markdown to docx, 
the

tables are not converted properly (all a single column).


I'm not sure why you are using markdown as an intermediate file
format. Org will export to latex, pdf (via latex) and openoffice odt
(which can be exported from open/libre office to doc/docx.).

Both the above exporters are much more mature that the markdown
exporter.

rick

Re: [O] [poll] Fontify code in code blocks

[Rick Frankel]

On 2014-01-09 07:22, Sebastien Vauban wrote:

Hello,
(setq org-src-fontify-natively t)

as the default value of `org-src-fontify-natively' is `nil'.

WDYT if we turn it on by default?


+1.

Re: [O] html5 generation minor bug

[Rick Frankel]

Bastien-

On 2014-01-04 09:36, Bastien wrote:

I will look at making this the default when i have time if the doctype
is html5 (`org-html-html5-p' is true), but it requires some work to
get the info structure passed down to `org-html--anchor'.

Sure -- please let us know when you have more time for this,
I'll not touch anything in this area.


Re-visiting this, it seems to me that there is really --- with current
browsers --- no reason to default to having both a name and id
attribute on anchors (`org-html-allow-name-attribute-in-anchors' t).

Having both is a throwback to early browsers (ie6 anyone :) that
wouldn't recognize the id attribute on anchors.

Changing the default to nil, would fix the issue with html5 without, i
believe, having any negative effect on (x)html4 output.

Agreed?

rick

Re: [O] html checkbox output

[Rick Frankel]

Bastien-

Top quoting to keep the history but save the search to the bottom
:)...

Yes, i will rework/simplify the patch (remove the free-form option and
the in-buffer setting), but I've been short on time the last week or
so.. Will fix it and push this week.

BTW, I've kept ascii output as the default mostly so I don't break the
regression test. Should I leave it alone or make utf-8 the default and
update the test?


rick
On Sat, Jan 04, 2014 at 10:36:13AM +0100, Bastien wrote:
 Hi Nicolas and Rick,
 
 Nicolas Goaziou n.goaz...@gmail.com writes:
 
  A new buffer keyword (which needs to be documented in org.texi),
  a defcustom with a completely free sexp... Isn't it a bit too much for
  mere checkboxes?
 
 Personally I think the defcustom is enough, as this choice is likely
 to be made for all Org documents.
 
  Filters provide almost the same functionality:
 
(defun my-checkbox-filter (item backend info)
  (when (org-export-derived-backend-p backend 'html)
(replace-regexp-in-string 
  \\`.*\\(code\\[\\(X\\|#xa0;\\|-\\)\\]/code\\).*$
  (lambda (rep)
(let ((check (match-string 2 rep)))
  (cond ((equal check X) #x2611;)
((equal check -) #x2610;)
(t #x2610;
  item
  nil nil 1)))
(add-to-list 'org-export-filter-item-functions 'my-checkbox-filter)
 
 Yes, but a defcustom would be easier.
 
  Anyway, here are a few comments.
 
  +(defcustom org-html-checkbox-type ascii
  +  The type of checkboxes to use for html export. See
 
  First line of a docstring has to be a single complete sentence.
 
  +(defun org-html-checkbox (checkbox info)
  +  Format CHECKBOX into HTML. This can be overriden on a
 
  Ditto.
 
  +(cdr
  + (assoc checkbox
 
(assq checkbox
 
  +  (if (listp checkboxes) checkboxes
  +(if (string-equal (substring checkboxes 0 1) ()
 
(if (eq (aref checkboxes 0) ?\()
 
  +(read checkboxes)
 
  This looks cheesy. `read'? Do you really want to parse arbitrary
  Sexps?
 
 Can we re-work Rick's patch/code and add this feature?  Rick,
 are you still on it?
 
 Thanks,
 

Re: [O] Question about the math mode table exporting for latex and html

[Rick Frankel]

On Tue, Jan 07, 2014 at 05:39:06PM +0100, Nicolas Goaziou wrote:
 Rasmus ras...@gmx.us writes:
 
  AFAIK, mathjax supports amsmath matrices, e.g. the third example here¹ .
  Thus, we'd really just want to insert the output of org-latex-table in
  the html-file.
 
  Perhaps something like the following would be OK?  Nicholas?
 
  #+ATTR_HTML: :mode latex
  #+ATTR_LATEX: :mode math :environment pmatrix :math-prefix \mathbf{H}=
  | \vdots | 0 | \vdots |
  | \vdots | H | \vdots |
  | \vdots | 0 | \vdots |
 
  This would tell ox-html.el to transcode the table via ox-latex-tabel
  and feed the string via org-html-format-latex (assuming latex-frag is
  a string).  
 
 FWIW, I think it's worth trying. I'm Cc'ing Rick Frankel for his
 opinion.
 

I have no opinion on this one. Nicolas, if you think this is the
correct approach syntactically, then it works for me.

rick

Re: [O] html5 generation minor bug

[Rick Frankel]

On 2013-12-27 12:23, Bastien wrote:

Rustom Mody rustompm...@gmail.com writes:

When the html-doctype is set to html5 the generator still generates
name attributes in links which is not correct html5
http://dev.w3.org/html5/markup/a.html#a-constraints

Can you give an example of what it does and what it should do?


Rustom is referring to the fact that the `name' attribute has been
marked obsolete in HTML5.

While the html5 spec suggests using the id attribute on a surrounding
container rather than a named anchor, the id attribute is still valid
on an anchor in html5.

In fact, ox-html already has support for handling the issue:

(defcustom org-html-allow-name-attribute-in-anchors t
When nil, do not set \name\ attribute in anchors.
By default, anchors are formatted with both \id\ and \name\
attributes, when appropriate.
:group 'org-export-html
:version 24.4
:package-version '(Org . 8.0)
:type 'boolean)


Rustom-

For now, just set this variable to nil and the anchors will be
exported with an id and no name attribute. If `org-export-allow-BIND'
is true, putting the following in the head of the document will work:

#+BIND: org-html-allow-name-attribute-in-anchors nil

Bastien-

I will look at making this the default when i have time if the doctype
is html5 (`org-html-html5-p' is true), but it requires some work to
get the info structure passed down to `org-html--anchor'.

Re: [O] [BUG] Add ob-J.el

[Rick Frankel]

On Fri, Dec 20, 2013 at 10:12:24AM -0700, Eric Schulte wrote:
 Applied, Thanks!
 
 I've played with APL but never seriously, however I can see it being a
 perfect tool for manipulating Org-mode tables.
 
 If you have time to put some documentation up on Worg as a new [1]
 linked from [2] that'd be great.
 
 I added ob-J to the org-babel-load-languages customization variable and
 it is now compiling with make.

The org-mode build and install now fails for me due to the fact that
ob-J requires j-console, which seems to be part of the package
'j-mode', and is not part of the standard emacs.

Perhaps this should be in contrib, unless the depency on j-console can
be factored out.

rick

[O] html checkbox output

[Rick Frankel]

So, here's a patch I would like a couple of people to try before i
commit it. It provides customization of checkbox formatting for html
output (unicode, ascii, checkbox input fields or custom). I couldn't
figure out how to add an association list customization with preset
options to a customization choice, so the custom option is a
partilally pre-filled sexp.

The default is still ascii, partially so that the checkbox tests don't
fail w/o being changed.

Let me know if this works for every of if it is too complex a solution
befor I apply it to master.

tia
rick
From 41da34c352f9c3899ece8294c3f618b665f12281 Mon Sep 17 00:00:00 2001
From: Rick Frankel r...@rickster.com
Date: Tue, 3 Dec 2013 14:37:30 -0500
Subject: [PATCH] Add customization options for html checkboxes.

* lisp/ox-html.el (html): Add in-buffer option HTML_CHECKBOX_TYP
(org-html-checkbox-types): New constant. Contains unicode, ascii and html
checkbox alists.
(org_html_checkbox_type): New customzation variable can be set to one
of the above choices or a user-entered alist.
(org_html_checkbox): Use of `:html-checkbox-type' export option.
---
 lisp/ox-html.el | 62 ++---
 1 file changed, 55 insertions(+), 7 deletions(-)

diff --git a/lisp/ox-html.el b/lisp/ox-html.el
index 9fa0a8c..8d0e3e3 100644
--- a/lisp/ox-html.el
+++ b/lisp/ox-html.el
@@ -126,6 +126,7 @@
 (:html-head-include-scripts nil html-scripts 
org-html-head-include-scripts)
 (:html-table-attributes nil nil org-html-table-default-attributes)
 (:html-table-row-tags nil nil org-html-table-row-tags)
+(:html-checkbox-type HTML_CHECKBOX_TYPE nil org-html-checkbox-type)
 (:html-xml-declaration nil nil org-html-xml-declaration)
 (:html-inline-images nil nil org-html-inline-images)
 (:infojs-opt INFOJS_OPT nil nil)
@@ -973,6 +974,42 @@ org-info.js for your website.
   (list :tag Postamble (const :format  postamble)
 (string :tag  id) (string :tag element
 
+(defconst org-html-checkbox-types
+  '((unicode .
+ ((on . #x2611;) (off . #x2610;) (trans . #x2610;)))
+(ascii .
+ ((on . code[X]/code)
+  (off . code[#xa0;]/code)
+  (trans . code[-]/code)))
+(html .
+ ((on . input type='checkbox' checked='checked' /)
+ (off . input type='checkbox' /)
+ (trans . input type='checkbox' /
+  Alist of checkbox types.
+The cdr of each entry is an alist list three checkbox types for
+html export: \on\, \off\ and \trans\.
+
+The choices are:
+  - unicode characters (html entities)
+  - ascii characters
+  - html checkboxes
+  - a user defined alist
+Note that only the ascii characters implement tri-state
+checkboxes. The other two use the \off\ checkbox for \trans\.)
+
+(defcustom org-html-checkbox-type ascii
+  The type of checkboxes to use for html export. See
+`org-html-checkbox-types' for for the preset values.
+  :group 'org-export-html
+  :version 24.4
+  :package-version '(Org . 8.0)
+  :type '(choice
+ (const :tag Unicode characters unicode)
+ (const :tag Ascii characters ascii)
+ (const :tag HTML checkboxes html)
+ (sexp :tag Custom alist
+   ((on . ) (off . ) (trans . )
+
 (defcustom org-html-metadata-timestamp-format %Y-%m-%d %a %H:%M
   Format used for timestamps in preamble, postamble and metadata.
 See `format-time-string' for more information on its components.
@@ -2415,18 +2452,29 @@ contextual information.
 
  Item
 
-(defun org-html-checkbox (checkbox)
-  Format CHECKBOX into HTML.
-  (case checkbox (on code[X]/code)
-   (off code[#xa0;]/code)
-   (trans code[-]/code)
-   (t )))
+(defun org-html-checkbox (checkbox info)
+  Format CHECKBOX into HTML. This can be overriden on a
+per-buffer basis with the \HTML_CHECKBOX_TYPE\ property,
+which can be either the name of one of the entries in the
+`org-html-checkbox-types' variable or an alist of the form:
+   ((on . \\) (off . \\) (trans . \\).
+See `org-html-checkbox-type' for customization.
+  (let ((checkboxes (plist-get info :html-checkbox-type)))
+(cdr
+ (assoc checkbox
+   (if (listp checkboxes) checkboxes
+ (if (string-equal (substring checkboxes 0 1) ()
+ (read checkboxes)
+   (cdr (assoc
+   (intern checkboxes)
+   org-html-checkbox-types
 
 (defun org-html-format-list-item (contents type checkbox info
 optional term-counter-id
 headline)
   Format a list item into HTML.
-  (let ((checkbox (concat (org-html-checkbox checkbox) (and checkbox  )))
+  (let ((checkbox (concat (org-html-checkbox checkbox info)
+ (and checkbox  )))
(br (org-html-close-tag br nil info)))
 (concat
  (case type
-- 
1.8.0

Re: [O] how to prevent html export from including the default javascript?

[Rick Frankel]

On 2013-12-05 03:56, Gijs Hillenius wrote:

Hello

I have trouble finding the correct explanation in ox-html.el.gz and
searching on the web. I'm trying to tell the html exporter *not* to
include the !--/*--![CDATA[/*!--*/ ... javascript

I'm trying to use the #+OPTIONS: to define this for a given foo.org
file.


The correct options setting (for org v8) is =html-scripts:nil=.

If you run org export dispatch, and insert the html header, it will
give you all the default options. ie:

C-c C-e # html RET

rick

Re: [O] Getting checkboxes in HTML output?

[Rick Frankel]

On 2013-12-02 11:38, Peter Davis wrote:

I've now changed ox-html.el to include this:

(defun org-html-checkbox (checkbox)
Format CHECKBOX into HTML.
(case checkbox (on #9746;)
(off #9744;)
(trans #9745;)
(t )))


This is sort of close to using
[ ] for unchecked
[/] for partially checked
[X] for checked

To my aging eyes, the check in U#9745 looks almost like a forward
slash. Certainly, though, this would be potentially confusing,
especially if no [X] boxes were present, so that only [ ] or [/] were
visible.


Right. I am going to make this a configurable option in ox-html,
although consensus is that trying to emulate the partial checkbox
([-]) w/ other unicode symbols is too confusing, so we will simply use
an empty ballot box.

rick

Re: [O] Getting checkboxes in HTML output?

[Rick Frankel]

On 2013-12-02 03:44, Sebastien Vauban wrote:

Hello,

Carsten Dominik wrote:
I agree, but couldn't think of any other way. There are 3 other
unicode options:

1. A box with an X  (☒ U+2612 BALLOT BOX WITH X)
2. A bare (unboxed) X (✗ U+2717 BALLOT X)
3 A bare checkmark (✓ U+2713 CHECK MARK)

I  also found this character:

U+237B ⍻ not check mark

If you think one of those would work we could use it instead.

No, I don't think any of them does it.

From http://en.wikipedia.org/wiki/Checkbox:

╭ Tri-state checkbox
│
│ Some applications use checkboxes that allow an indeterminate state in
│ addition to the two provided by a normal checkbox. This third state 
is
│ shown as a square or dash in the checkbox, and indicates that its 
state

│ is neither checked nor unchecked. This is most often used when the
│ checkbox is tied to a collection of items in mixed states.
╰

Something like [-] could be nice, then, as corresponds to the Org look
and feel.


Unfortunately, a symbol like this is unavailable in unicode and the
html checkbox is only two state. The only HTML solutions i've found
involve javascript and images rather than html checkbox (input)
elements.


rick

Re: [O] Getting checkboxes in HTML output?

[Rick Frankel]

On Sat, Nov 30, 2013 at 07:54:42AM +0100, Carsten Dominik wrote:

 I don't thing the partial ones work - we should just make then
 unchecked in export if there is nothing better.  the grey dos not
 convey the right information.

I agree, but couldn't think of any other way. There are 3 other
unicode options:

1. A box with an X  (☒ U+2612 BALLOT BOX WITH X)
2. A bare (unboxed) X (✗ U+2717 BALLOT X)
3 A bare checkmark (✓ U+2713 CHECK MARK)

I  also found this character:

   U+237B ⍻ not check mark

If you think one of those would work we could use it instead.


 My vote:
 - Unicode characters as default
 - Both active and inactive checkboxes as option for people who want
 them, via a customize variable.
 - Partial checkboxes should be shown as unchecked.

I will implement the replacement of the ascii characters with the
unicode and the look at the html checkbox options.

FWIW, there are other issues w/ the active version besides the changes
not being saved -- If you are using hierarchical list or rollups
indicators ([x/y], [x%]), they will not be updated w/o some
javascript.

rick
 
 
 On 29.11.2013, at 17:11, Rick Frankel r...@rickster.com wrote:
 
  On 2013-11-28 16:58, Matt Price wrote:
  On Thu, Nov 28, 2013 at 4:26 PM, Sebastien Vauban
  sva-n...@mygooglest.com wrote:
  Achim Gratz wrote:
  Rick Frankel writes:
  For xhtml compatibility, it would need to be 'checked=checked'. I've
  done a quick look at the html dtd, and i does look like input elements
  are allowed outside of forms, but i would need to double
  check... Also, the fallback to [-] for the partially checked state
  is a bit inconsistent, perhaps changing background color or other
  attributre of the checkbox would be better.
  I'd much prefer if you'd be using character entities for that since you
  can't do any input on the HTML anyway (WHITE MEDIUM SQUARE, SQUARE WITH
  LOWER RIGHT DIAGONAL BLACK and BLACK MEDIUM SQUARE look like good
  candidates).  That probably makes it UTF-8 only since I don't think
  these symbols are defined for plain (X)HTML, so for other encodings
  things should probably stay as they are.
  FWIW, here's what I do for the HTML export:
  In JS:
  #+begin_src js
  $(function () {
  $('li  code:contains([X])')
  .parent()
  .addClass('checked')
  .end()
  .remove();
  $('li  code:contains([-])')
  .parent()
  .addClass('halfchecked')
  .end()
  .remove();
  $('li  code:contains([ ])')
  .parent()
  .addClass('unchecked')
  .end()
  .remove();
  });
  #+end_src
  In CSS:
  #+begin_src css
  li.checked {
  list-style-image: url('../images/checked.png');
  }
  li.halfchecked {
  list-style-image: url('../images/halfchecked.png');
  }
  li.unchecked {
  list-style-image: url('../images/unchecked.png');
  }
  #+end_src
  with 3 nice pictures of green V, red X, and blue || (line pause on
  recorders).
  so, I don't know if I'm the only one here who feels this way, but I
  would like to be able to export to an HTML file with ACTUAL HECKBOXES
  that I cna check off, say on a phone, when I put the milk in the
  shopping art, or pack the swim goggles in the vacation bag, or
  whatever.  Maybe though I should be thinking in terms of some other
  export application, remember the milk or something.  Am I describing a
  different use case than other users here, perhaps?
  
  My 3 cents:
  
  I don't see that active checkboxes would help since i don't see a use
  case where you can save the html back with the modified input. The
  github usecase mentioned in anothre thread requires a bunch of
  javascript to work (and write-out the modified file).
  
  While Sebastien's solution is visually appealing, i don't think
  requiring image assets is viable for the core exporter (note that it
  could be done w/o javascript, another dependency i would like to
  avoid).
  
  I've attached an html file which shows the various possible options. My
  comments:
  
  1. As mentioned above, I don't see active checkboxes as useful
  since the modified state is transient.
  2. I don't really like the disabled checkboxes visually.
  3. Either of the other two approaches (the list item style, which
  parallels Sebastien's approach w/o using images) works for me.
  Visually I like the list item style solution, but doesn't really
  make the intent clear.
  
  So, my vote is to change the exporter to use the BALLOT BOX and BALLOT
  BOX WITH CHECK instead of the ascii character currently used and
  indicate partially checked boxes ([-]) with greyed text.
  
  Opinions?
  
  rick
  
  checkbox.html

Re: [O] Getting checkboxes in HTML output?

[Rick Frankel]

On 2013-11-28 16:58, Matt Price wrote:

On Thu, Nov 28, 2013 at 4:26 PM, Sebastien Vauban
sva-n...@mygooglest.com wrote:
Achim Gratz wrote:
Rick Frankel writes:
For xhtml compatibility, it would need to be 'checked=checked'. I've
done a quick look at the html dtd, and i does look like input elements
are allowed outside of forms, but i would need to double
check... Also, the fallback to [-] for the partially checked state
is a bit inconsistent, perhaps changing background color or other
attributre of the checkbox would be better.

I'd much prefer if you'd be using character entities for that since you
can't do any input on the HTML anyway (WHITE MEDIUM SQUARE, SQUARE WITH
LOWER RIGHT DIAGONAL BLACK and BLACK MEDIUM SQUARE look like good
candidates).  That probably makes it UTF-8 only since I don't think
these symbols are defined for plain (X)HTML, so for other encodings
things should probably stay as they are.

FWIW, here's what I do for the HTML export:

In JS:

#+begin_src js
$(function () {
$('li  code:contains([X])')
.parent()
.addClass('checked')
.end()
.remove();
$('li  code:contains([-])')
.parent()
.addClass('halfchecked')
.end()
.remove();
$('li  code:contains([ ])')
.parent()
.addClass('unchecked')
.end()
.remove();
});
#+end_src

In CSS:

#+begin_src css
li.checked {
list-style-image: url('../images/checked.png');
}

li.halfchecked {
list-style-image: url('../images/halfchecked.png');
}

li.unchecked {
list-style-image: url('../images/unchecked.png');
}
#+end_src

with 3 nice pictures of green V, red X, and blue || (line pause on
recorders).



so, I don't know if I'm the only one here who feels this way, but I
would like to be able to export to an HTML file with ACTUAL HECKBOXES
that I cna check off, say on a phone, when I put the milk in the
shopping art, or pack the swim goggles in the vacation bag, or
whatever.  Maybe though I should be thinking in terms of some other
export application, remember the milk or something.  Am I describing a
different use case than other users here, perhaps?


My 3 cents:

I don't see that active checkboxes would help since i don't see a use
case where you can save the html back with the modified input. The
github usecase mentioned in anothre thread requires a bunch of
javascript to work (and write-out the modified file).

While Sebastien's solution is visually appealing, i don't think
requiring image assets is viable for the core exporter (note that it
could be done w/o javascript, another dependency i would like to
avoid).

I've attached an html file which shows the various possible options. My
comments:

1. As mentioned above, I don't see active checkboxes as useful
since the modified state is transient.
2. I don't really like the disabled checkboxes visually.
3. Either of the other two approaches (the list item style, which
parallels Sebastien's approach w/o using images) works for me.
Visually I like the list item style solution, but doesn't really
make the intent clear.

So, my vote is to change the exporter to use the BALLOT BOX and BALLOT
BOX WITH CHECK instead of the ascii character currently used and
indicate partially checked boxes ([-]) with greyed text.

Opinions?

rick

Title: checkbox test

  
  
Checkbox samples
Active

   unchecked
   checked
  
 partial

Inactive

   unchecked
   checked
  
 partial

List item style

  unchecked
  checked
  partial

Unicode characters

   unchecked (BALLOT BOX)
   checked (BALLOT BOX WITH CHECK)
  
 partial (BALLOT BOX WITH CHECK)
  
   alternative checked (BALLOT BOX WITH X)

  

Re: [O] Getting checkboxes in HTML output?

[Rick Frankel]

On Wed, Nov 27, 2013 at 01:20:59PM -0500, Peter Davis wrote:
 On Wed, Nov 27, 2013 at 11:03:38AM -0500, Nick Dokos wrote:
  Peter Davis p...@pfdstudio.com writes:
 
   I noticed that HTML output contains [ ] and [X], just like
 the
   mark-up. Wouldn't it make sense to use actual unchecked or
 checked
   checkboxes in HTML?
  
   Is there a simple way to do this that I've overlooked?
  
 
  A cursory glance through ox-html.el uncovered this:
 
  --8---cut here---start-8---
  (defun org-html-checkbox (checkbox)
Format CHECKBOX into HTML.
(case checkbox (on code[X]/code)
  (off code[#xa0;]/code)
  (trans code[-]/code)
  (t )))
  --8---cut here---end---8---
 
  Maybe you can redefine this function to do what you want?

 Yes, this works:

 --8---cut here---start-8---
 (defun org-html-checkbox (checkbox)
   Format CHECKBOX into HTML.
   (case checkbox (on input type=\checkbox\ checked /)
   (off input type=\checkbox\ /)
   (trans code[-]/code)
   (t )))
 --8---cut here---end---8---

For xhtml compatibility, it would need to be 'checked=checked'. I've
done a quick look at the html dtd, and i does look like input elements
are allowed outside of forms, but i would need to double
check... Also, the fallback to [-] for the partially checked state
is a bit inconsistent, perhaps changing background color or other
attributre of the checkbox would be better.

I would be willing to make this change (as an option?) to the html
exporter if others agree.

rick

Re: [O] not handling failing sql statements in ob-sql.el with postgresql

[Rick Frankel]

On 2013-11-27 04:49, Joost Helberg wrote:

Hi,

in case psql (version 9.1 and later) encounters a SQL error, e.g. a
syntax error, it doesn't exit with an error-code. Instead it
continues and exits with 0. This means that evaluating faulty SQL-code
in org-mode/babel leaves the user with no clue of why the result set is
empty.

I changed the code in ob-sql.el by adding the
command-line option to the psql command in order to make things work
correct. This option not only makes psql exit at the first error, it
also exits with a not 0 error-code.

line 125 and further of my ob-sql.el:
('postgresql (format
	  psql --set=\ON_ERROR_STOP=1\ -A -P footer=off -F \\t\  -f %s -o 
%s %s

  (org-babel-process-file-name in-file)
  (org-babel-process-file-name out-file)
  (or cmdline )))

Is this a change worth applying? Or will it break things?


Did a quick check, and this option goes all the way back to postgresql
7.1, so it looks like it won't break anything that shouldn't be
broken :), and should be applied.

rick

Re: [O] Babel: the disappearing hline

[Rick Frankel]

On 2013-11-13 09:17, Eric Schulte wrote:

Perhaps we should change `org-babel-default-inline-header-args' to
include `(:hlines yes)'.  If there is no push back on that change I'd
be happy to make it.


I agree. It would probably make the behavior less confusing.

rick

[O] [BUG] call results not creating #results

[Rick Frankel]

Eric-

Since you're looking at call lines :)...

there is a (fairly new i think) bug:

When searching forward for results, following call lines are not
being respected as stop points. For instance, given:

#+BEGIN_SRC org
,* Call block test
,#+name: call-me
,#+BEGIN_SRC emacs-lisp :var v=one
v
,#+END_SRC

,#+RESULTS: call-me
: one

,#+call: call-me(v=two)

,#+RESULTS:
: two
#+END_SRC

If i insert a new call-block before two and execute it, the following 
occurs


#+BEGIN_SRC org
,* Call block test
,#+name: call-me
,#+BEGIN_SRC emacs-lisp :var v=one
v
,#+END_SRC

,#+RESULTS: call-me
: one

,#+call: call-me(v=three)

,#+call: call-me(v=two)

,#+RESULTS:
: three
#+END_SRC

as you can see, it replaced the results for call-line two.

Note that if i had named two and executed it before adding in call 
line three, the results would be

ok:

#+BEGIN_SRC org
,* Call block test
,#+name: call-me
,#+BEGIN_SRC emacs-lisp :var v=one
v
,#+END_SRC

,#+RESULTS: call-me
: one

,#+call: call-me(v=three)

,#+RESULTS:
: three

,#+name: two
,#+call: call-me(v=two)

,#+RESULTS: two
: two
#+END_SRC

rick

Re: [O] Babel: the disappearing hline

[Rick Frankel]

On 2013-11-12 01:16, Jarmo Hurri wrote:

Eric Schulte schulte.e...@gmail.com writes:

There are two paces to specify header arguments in a call line, the
arguments in the [] are applied to the input-table function, *not* to
the call line, so they change the inputs.  The trailing header
arguments are applied to the call line.

So there is an implicit post-processing function that takes the result
of the called block as input, and hline pruning is applied in this
function?

I put on the table a suggestion that the default behaviour of #+CALL
w.r.t. the handling of hlines is changed from removing hlines in output
to not removing them. I am suggesting this partly because I don't
understand why the default behaviour is as it is now, and secondly
because the current behavious differs from the way hlines are handled 
in

other block evaluations:


This behavior is controlled globally by the value of
`org-babel-default-header-args'. This is overriden by the value of
`org-babel-default-header-args:{lang}' and of course, the setting on
individual source blocks and call lines. As you can see from the below
output, the default is =:hlines no=. Note that in versions of org-mode
prior to commit 6857d139 of 2013-09-28 (below), this was overridden in
the setting of `org-babel-default-header-args:emacs-lisp, so this may
be why you are seeing and inconsistency between the call line and
the emacs-lisp source block.

If you want hlines to be included by default, you can modify the value
of `org-babel-default-header-args'.

I have attached an org file i have been working on to see the results
of various settings of =colnames= and =hlines= on table evaluation in
various languages, you may find it useful.

rick

--
commit 6857d139e1b5ea5c235e3555dbe15aeab227aaef
Author: Eric Schulte schulte.e...@gmail.com
Date:   Sat Sep 28 06:37:54 2013 -0600

set default emacs-lisp header args to nil

The difference between elisp and every other language was causing
confusion, so simpler just to set these to nil.

* lisp/ob-emacs-lisp.el (org-babel-default-header-args:emacs-lisp):
Set to nil.

1 file changed, 1 insertion(+), 2 deletions(-)
lisp/ob-emacs-lisp.el | 3 +--

Modified   lisp/ob-emacs-lisp.el
diff --git a/lisp/ob-emacs-lisp.el b/lisp/ob-emacs-lisp.el
index 886645d..4505129 100644
--- a/lisp/ob-emacs-lisp.el
+++ b/lisp/ob-emacs-lisp.el
@@ -28,8 +28,7 @@
;;; Code:
(require 'ob)

-(defvar org-babel-default-header-args:emacs-lisp
-  '((:hlines . yes) (:colnames . no))
+(defvar org-babel-default-header-args:emacs-lisp nil
Default arguments for evaluating an emacs-lisp source block.)

(declare-function orgtbl-to-generic org-table (table params))
#+TITLE: Colnames handling
#+DATE: {{{modification-time(%Y-%m-%d)}}}
#+AUTHOR: Rick Frankel
#+EMAIL: ut0598@rtasdv12
#+OPTIONS: ':nil *:t -:t ::t :t H:3 \n:nil ^:t arch:headline
#+OPTIONS: author:t c:nil creator:comment d:(not LOGBOOK) date:t
#+OPTIONS: e:t email:nil f:t inline:t num:nil p:nil pri:nil stat:t
#+OPTIONS: tags:t tasks:t tex:t timestamp:nil toc:t todo:t |:t
#+DESCRIPTION:
#+EXCLUDE_TAGS: noexport
#+KEYWORDS:
#+LANGUAGE: en
#+SELECT_TAGS: export

Evaluate the subtree [[Test generator]] with =org-babel-execute-subtree= (=C-c C-v C-s=).
It will:

1. Run [[generate-colnames-and-hlines-tests]] to create the [[colnames and
   hlines]] tests.
2. Run the tests.

Note that it will automatically require the file ob-{lang} for
each language block specified in [[Language functions]] below.

* Language functions
:PROPERTIES:
:results:  silent
:exports:  code
:var:  table=table
:ID:   LANGUAGES
:END:
This function should modify each cell of the input table by appending
/-o/ to the value of the cell and convert ='hline= rows in the
input to the literal /hline/, so it appears in the output table.

Create one for each babel language to be tested.

#+CAPTION: emacs-lisp
#+BEGIN_SRC emacs-lisp
  (mapcar
   (lambda (r)
 (if (sequencep r)
 (mapcar
  (lambda (c)
(if (integerp c)
(format %d-o c)
  (concat c -o)))
  r)
   (list r)))
   table)
#+END_SRC

#+CAPTION: perl
#+BEGIN_SRC perl :results value
  return [map {
  ref $_ ? [map { $_ . -o } @$_] : $_
  } @$table];
#+END_SRC

#+CAPTION: python
#+name: python
#+BEGIN_SRC python
  return [isinstance(r,list) and [str(c)+-o for c in r] or [r] for r in table]
#+END_SRC

#+CAPTION: ruby
#+BEGIN_SRC ruby
  table.collect do |r|
r.instance_of?(Array) ? r.collect { |c| #{c}-o } : [r]
  end
#+END_SRC

* Test generator
#+CAPTION: Input table
#+name: table
| a | b | c |
|---+---+---|
| 1 | 2 | 3 |
| 4 | 5 | 6 |
|---+---+---|
| 7 | 8 | 9 |

#+CAPTION: Function to list default header args by language
#+name: list-defaults
#+HEADER:  :var val='org-babel-default-header-args :eval never :exports code
#+BEGIN_SRC emacs-lisp :colnames '(option value)
  (or
   (mapcar
(lambda (x) (list (car x) (cdr x))) (eval val)) '(( )))
#+END_SRC

#+name: generate-colnames-and-hlines

Re: [O] Babel: the disappearing hline

[Rick Frankel]

On 2013-11-12 11:09, Jarmo Hurri wrote:

Rick Frankel r...@rickster.com writes:

Greetings Rick.

Note that in versions of org-mode prior to commit 6857d139 of
2013-09-28 (below), this was overridden in the setting of
`org-babel-default-header-args:emacs-lisp, so this may be why you are
seeing and inconsistency between the call line and the emacs-lisp
source block.

If I understand correctly, you are referring to the possibility that 
the

inconsistency would be caused by an old version of org. I do not think
that this is the case: I have been pulling the newest version every
day. Below is the output of the test, including a printout of my org
version number.


I don't think 8.2.3a is the lastest version from git, containing the
change eric made to the header args:

% git diff release_8.2.3a..6857d139 lisp/ob-emacs-lisp.el|cat
diff --git a/lisp/ob-emacs-lisp.el b/lisp/ob-emacs-lisp.el
index 886645d..4505129 100644
--- a/lisp/ob-emacs-lisp.el
+++ b/lisp/ob-emacs-lisp.el
@@ -28,8 +28,7 @@
;;; Code:
(require 'ob)

-(defvar org-babel-default-header-args:emacs-lisp
-  '((:hlines . yes) (:colnames . no))
+(defvar org-babel-default-header-args:emacs-lisp nil
Default arguments for evaluating an emacs-lisp source block.)

(declare-function orgtbl-to-generic org-table (table params))

what is the output of:

#+BEGIN_SRC emacs-lisp
(mapcar 'list
org-babel-default-header-args:emacs-lisp))
#+END_SRC

Regardless, I get the same results you do. I think the issue is this:

hlines are stripped in the input to a block and added back after
depending on the value of the :hlines header argument. Since your code
is outputting literal hlines, there is no processing on output from
the literal block as there where no inputs.

However, if you do the following you will see that the hlines follow
the header rules (stripping the hlines by default:

#+BEGIN_SRC emacs-lisp :var data=func()
data
#+END_SRC

#+RESULTS:
| a |
| b |
| c |

As to the call lines, think of the output of the called block as
being input to an anonymous block (the #+call), so the hlines are
stripped.


Or is there something weird in my setup? Do you get a different output
with my test cases?


No, nothing weird, but the issue is not specific to call lines, it's
just related to the way babel processes input and output tablular data.

It's not entirely obvious (and affects colnames as well as hlines).

Again, the solution is to globally set the :hline property to =yes=
instead of the default =no=, and you will get the results you want.
Change the value of `org-babel-default-header-args' in your startup
or just change the :hlines property on a file or headline basis:

#+PROPERTY: hlines yes

or

* hline pruning in output
:PROPERTIES:
:hlines:   yes
:END:


I will look at the other stuff you sent a bit later.

All the best,

Jarmo

# 
--


* hline pruning in output

# test org version
#+BEGIN_SRC emacs-lisp
(org-version)
#+END_SRC

#+RESULTS:
: 8.2.3a

# case 1: hlines are retained by default when a source code block is
# defined and evaluated
#+NAME: func
#+BEGIN_SRC emacs-lisp
(list '(a) '(b) 'hline '(c))
#+END_SRC

#+RESULTS: func
| a |
| b |
|---|
| c |

# case 2: hlines are retained by default when source code is called
# by post
#+BEGIN_SRC emacs-lisp :post func()

#+END_SRC

#+RESULTS:
| a |
| b |
|---|
| c |

# case 3: but hlines are removed by default when source code is
# called by #+CALL
#+CALL: func()

#+RESULTS:
| a |
| b |
| c |

Re: [O] [BUG] hline references on left side of table formula

[Rick Frankel]

On 2013-11-07 00:59, Michael Brand wrote:

On Wed, Nov 6, 2013 at 7:50 PM, Rick Frankel r...@rickster.com wrote:
+  (not (string-match \.\.@ (car x

This would be the same as

+  (not (string-match ..@ (car x

but you meant

+  (not (string-match \\.\\.@ (car x



Of course, you are right.

rick

Re: [O] [BUG] hline references on left side of table formula

[Rick Frankel]

On 2013-11-06 15:14, Achim Gratz wrote:

Achim Gratz writes:
[...]
with these formulas:
#+TBLFM: $=vsum(@-II..@-I)

whoops, press C-c C-c in the wrong buffer.

I meant these formulas:

#+TBLFM: @$=vsum(@-II..@-I)
#+TBLFM: @II=vsum(@-II..@-I)
#+TBLFM: @III=vsum(@-II..@-I)
#+TBLFM: @=vsum(@-II..@-I)
#+TBLFM: @II..$2=vsum(@-II..@-I)
#+TBLFM: @III..$2=vsum(@-II..@-I)
#+TBLFM: @..$2=vsum(@-II..@-I)
#+TBLFM: @II+1..@II$2=vsum(@-II..@-I)
#+TBLFM: @II$2..@II+1$2=vsum(@-II..@-I)

Some of the results are useful when your table has a certain, even
though in general this does the wrong thing as Carsten said.  I'm not
really having an opinion on whether this should be an error (as your
previous patch does, which should then add a correction to the test 
that

is now failing) or if some / all of this should stay allowed until
somebody musters the time to fix it properly (I think this would amount
to re-implementing a good part of what is org-table).



Ok, i see what's happening in your examples (a testing org file
attached), though i question the usefullness of most of the results ;).

The updated patch attached to the previous email (fixed as pointed out
by michael):

--- a/lisp/org-table.el
+++ b/lisp/org-table.el
@@ -3016,8 +3016,9 @@ known that the table will be realigned a little 
later anyway.

;; Insert constants in all formulas
(setq eqlist
(mapcar (lambda (x)
- (if (string-match ^@-?I+ (car x))
- (user-error Can't assign to hline relative reference))
+ (if (and (string-match ^@-?I+ (car x))
+  (not (string-match \\.\\.@ (car x
+ (user-error Can't assign to hline relative reference 
without a range specification.))

(when (string-match \\`$[] (car x))
(setq lhs1 (car x))
(setq x (cons (substring

Both fixes the testing issue and allows what seems to me to be the
most relevant use-case.

I have no real position on whether the best solution is to back out
the change, or modify it as above to make the test pass and allow the
logical usecase.

If the first, I think it would be useful for the documentation to
(somehow) explain what happens if an explicit column specificaton is
made without a corresponding range.

Please chime in on which patch should be applied.

rick* Code
:PROPERTIES:
:eval: never
:END:
#+name: table
#+BEGIN_SRC emacs-lisp :results silent :eval yes
| a | b |
|---+---|
| w | 1 |
| x | 2 |
|---+---|
|   |   |
|   |   |
|---+---|
| y | 3 |
| z | 4 |
|---+---|
|   |   |
#+END_SRC
#+name: expand-tables
#+BEGIN_SRC emacs-lisp
  (save-excursion
  (while (re-search-forward org-table-TBLFM-begin-regexp)
(org-table-calc-current-TBLFM)))
#+END_SRC
#+name: generate-tables
#+BEGIN_SRC emacs-lisp :var table=table :results wrap
  (mapconcat
   (lambda (fm)
 (mapconcat
  'identity (list (concat ** (substring fm 8)) table fm) \n))
   (list #+TBLFM: @$=vsum(@-II..@-I)
 #+TBLFM: @II=vsum(@-II..@-I)
 #+TBLFM: @III=vsum(@-II..@-I)
 #+TBLFM: @=vsum(@-II..@-I)
 #+TBLFM: @II..$2=vsum(@-II..@-I)
 #+TBLFM: @III..$2=vsum(@-II..@-I)
 #+TBLFM: @..$2=vsum(@-II..@-I)
 #+TBLFM: @II+1..@II$2=vsum(@-II..@-I)
 #+TBLFM: @II$2..@II+1$2=vsum(@-II..@-I)) \n)
#+END_SRC

* Eval me! (=\C-c\C-v\C-s=)
:PROPERTIES:
:ID: EVAL-ME
:END:
#+name: call-generate
#+call: generate-tables[:eval yes](table=table) :results wrap
#+call: expand-tables[:eval yes]() :results silent

#+RESULTS: call-generate
:RESULTS:
** @$=vsum(@-II..@-I)
| a | b |
|---+---|
| w | 1 |
| x | 2 |
|---+---|
|   |   |
|   |   |
|---+---|
| y | 3 |
| z | 4 |
|---+---|
| y + z |   |
#+TBLFM: @$=vsum(@-II..@-I)
** @II=vsum(@-II..@-I)
| a | b |
|---+---|
| w | 1 |
| x | 2 |
|---+---|
| w + x |   |
| w + x |   |
|---+---|
| w + x + w + x | 3 |
| w + x + w + x | 4 |
|---+---|
| w + x + w + x + w + x + w + x |   |
#+TBLFM: @II=vsum(@-II..@-I)
** @III=vsum(@-II..@-I)
| a | b |
|---+---|
| w | 1 |
| x | 2 |
|---+---|
|   |   |
|   |   |
|---+---|
| 0 | 3 |
| 0 | 4 |
|---+---|
| 0 |   |
#+TBLFM: @III=vsum(@-II..@-I)
** @=vsum(@-II..@-I)
| a | b |
|---+---|
| w | 1 |
| x | 2 |
|---+---|
|   |   |
|   |   |
|---+---|
| y | 3 |
| z | 4 |
|---+---|
| y + z |   |
#+TBLFM: @=vsum(@-II..@-I)
** @II..$2=vsum(@-II..@-I)
| a |  b |
|---+|
| w |  1 |
| x |  2 |
|---+|
| w + x |  3 |
| w + x |  3 |
|---+|
| w + x + w + x |  

Re: [O] [BUG] hline references on left side of table formula

[Rick Frankel]

On 2013-11-06 03:23, Bastien wrote:

lom...@voila.fr writes:

I was interested to use hline references on the left side. However I 
found out that it

is not completely unsupported.
When the left side consist of:
* single cells references, it does not work
* ranged cells, it works for me (org 8.0.3)

(I'm not sure I fully understand the issue.)

The patch below tranforms the single cell references to ranged cells .

However it still does not work for references like @+ or @- I$1.. ,
which can be solve using references like @I+1#1.

If you come up with a complete patch, please submit it by following
the guidelines here: http://orgmode.org/worg/org-contribute.html


What he is saying, is that references like =@II$2=, or =@II+1$2= do not
work correctly on the left-hand side of a table format (verified by
carsten in a previous thread) which is why i created the patch to
disallow hline-relative references on th LHS.

However, he has found that ranged references line as =@II$2..@II+2$2=
do in fact work to reference a single cell on the left hand side on a
formula.

For example:

Given the input table:

| a | b |
|---+---|
| x | 1 |
| y | 2 |
|---+---|
|   |   |
|   |   |

The following results occur:

| a | b |
|---+---|
| x | 1 |
| y | 2 |
|---+---|
| x + y | 3 |
| x + y | 3 |
#+TBLFM: @II$2=vsum(@I..@II)

| a | b |
|---+---|
| x | 1 |
| y | 2 |
|---+---|
|   | 3 |
|   |   |
#+TBLFM: @II$2..@II+1$2=vsum(@I..@II)

| a | b |
|---+---|
| x | 1 |
| y | 2 |
|---+---|
| 3 | 3 |
| 3 | 3 |
#+TBLFM: @II$2=vsum(@I$2..@II$2)

| a | b |
|---+---|
| x | 1 |
| y | 2 |
|---+---|
|   | 3 |
|   |   |
#+TBLFM: @II$2..@II+1$2=vsum(@I$2..@II$2)

So, perhaps my patch was premature, but should instead should check
for hline refs w/o ranges on the lhs. Here's a new patch to only
error-out if there is no range spec. Note that this also fixes Achim's
issue w/ the colnames test failing.


rick

 8 
--- a/lisp/org-table.el
+++ b/lisp/org-table.el
@@ -3016,8 +3016,9 @@ known that the table will be realigned a little 
later anyway.

;; Insert constants in all formulas
(setq eqlist
(mapcar (lambda (x)
- (if (string-match ^@-?I+ (car x))
- (user-error Can't assign to hline relative reference))
+ (if (and (string-match ^@-?I+ (car x))
+  (not (string-match \.\.@ (car x
+ (user-error Can't assign to hline relative reference 
without a range specification.))

(when (string-match \\`$[] (car x))
(setq lhs1 (car x))
(setq x (cons (substring

Re: [O] make new links show as figures?

[Rick Frankel]

On 2013-10-31 06:04, Alan Schmitt wrote:

r...@rickster.com writes:

So it turns out that this is a REALLY simple patch (two characters):

+++ b/lisp/org.el
@@ -18853,7 +18853,7 @@ BEG and END default to the buffer boundaries.
(widen)
(setq beg (or beg (point-min)) end (or end (point-max)))
(goto-char beg)
-   (let ((re (concat 
\\[\\[\\(\\(file:\\)\\|\\([./~]\\)\\)\\([^]\n]+?

+   (let ((re (concat
\\[.*\\[\\(\\(file:\\)\\|\\([./~]\\)\\)\\([^]\n]+?
(substring (org-image-file-name-regexp) 0 -2)
\\)\\] (if include-linked  \\])))
(case-fold-search t)

This seems to work in all cases I can think of (see test file below).
Let me know if this works for you and i will apply to master when i
get home and have git push access.

I tried it on some files with images as links, and it works
great. Thanks a lot!


So, I've done some testing of the export functions (html and latex
only) and found the following behaviors with this patch:

- HTML
- image in description only displayed if the protocol (file:) is
included.
- LaTeX
- same, required file: protocol in description
- additionally, pdflatex \includgraphics barfs on any path w/ a
=./= path prefix -- this is true for the current implmenation as
well.

Changing the regexp for in-buffer image expansion to mimic the export
behavior is difficult at best. I think the inconsistency is
acceptable, and I will documentment the behavior in the
`org-display-inline-images' docstring.

The latex breakage on paths beginning with =./= should perhaps be
addressed in the latex exporter, but this is orthogonal to the
current issue.

If there is no objection, I will push a fix tonight or tomorrow.

rick

Re: [O] make new links show as figures?

[Rick Frankel]

On 2013-10-31 12:20, Cook, Malcolm wrote:


 So it turns out that this is a REALLY simple patch (two characters):

 +++ b/lisp/org.el
 @@ -18853,7 +18853,7 @@ BEG and END default to the buffer 
boundaries.

 (widen)
 (setq beg (or beg (point-min)) end (or end (point-max)))
 (goto-char beg)
 -   (let ((re (concat
 \\[\\[\\(\\(file:\\)\\|\\([./~]\\)\\)\\([^]\n]+?
 +   (let ((re (concat
 \\[.*\\[\\(\\(file:\\)\\|\\([./~]\\)\\)\\([^]\n]+?
 (substring (org-image-file-name-regexp) 0 -2)
 \\)\\] (if include-linked  \\])))
 (case-fold-search t)

 This seems to work in all cases I can think of (see test file 
below).

 Let me know if this works for you and i will apply to master when i
 get home and have git push access.

 I tried it on some files with images as links, and it works
 great. Thanks a lot!
[Cook, Malcolm]

Hi - I'm trying to follow this thread but having a challenge.  Can you
please summarize/repeat the original intended effect of this
change


To make images in link descriptions (e.g, [[file.dot][file.png]]
displayed inline rather than showing the text (file.png)




So, I've done some testing of the export functions (html and latex
only) and found the following behaviors with this patch:

- HTML
- image in description only displayed if the protocol (file:) is
included.
- LaTeX
- same, required file: protocol in description
- additionally, pdflatex \includgraphics barfs on any path w/ a
=./= path prefix -- this is true for the current implmenation as
well.

Changing the regexp for in-buffer image expansion to mimic the export
behavior is difficult at best. I think the inconsistency is
acceptable, and I will documentment the behavior in the
`org-display-inline-images' docstring.

The latex breakage on paths beginning with =./= should perhaps be
addressed in the latex exporter, but this is orthogonal to the
current issue.

If there is no objection, I will push a fix tonight or tomorrow.

rick