This is a second patch in a series that makes some straightforward
corrections to a number of docstrings. Each change is normally to:
- correct a typo, or
- fix up hyperlinks to function or variable names, or
- ensure slightly better conformance with the documentation guidelines
and tips given in the Elisp manual
No attempt is made to provide missing docstrings or document arguments.
Cheers,
Phil
* lisp/org-html.el (org-export-html-preprocess): Call org-format-latex,
possibly with a protect-only argument.
* lisp/org.el (org-format-latex): New argument PROTECT-ONLY.
with the switch #+OPTIONS: LaTeX:verbatim ,
LaTeX code will be exported verbatim to HTML, so that jsmath can grab
and convert it.
Proposed by Christian Moe.
* lisp/org-exp.el (org-export-format-source-code-or-example): Mark examples
by a property. o
* lisp/org-html.el (org-export-html-close-lists-maybe): Check if raw
HTML stuff was actually made from an example
Daniel Mahler writes:
> 2. I would like to embed source blocks in numbered lists, without
> breaking the numbering ie:
>
> 1) get ready
> #+BEGIN_SRC sh
> get_ready
> #+END_SRC
> 2) go
> #+BEGIN_SRC sh
> go
> #+END_SRC
>
> currently the src blocks cause the numbering to reset, so all
> items in a sequence like this are numbered 1
This patch fixes this issue - but I cannot say anymore why the code in
org-export-html-close-lists-maybe does in fact work. The code looks
wrong, but it seems to work. What looks wrong is that i does not
check for the true indentation in the case when the line is not
protected. It must be that this case is covered by some other code
further down in the exporter.
* contrib/lisp/org-special-blocks.el (org-special-blocks-make-special-cookies):
Emacs 22 doesn't have string-match-p
* lisp/org-freemind.el (org-freemind-write-mm-buffer):
(org-freemind-get-node-style):
Emacs 22 doesn't have string-match-p
* lisp/org-html.el (org-html-make-link):
Use new org-string-match-p for compatibility
Patch by Stephen Peters.
Stephen writes:
> When creating a table, I was noticing that the
> <colgroup><col>... provides useful alignment information based on
> whether or not the column has numbers in it. I think, however, that
> there is a mistake in this routine. Take, for example, the following
> table:
>
> | Id | Task | Developer | Estimate | Spent | Remaining | Comp.% | Updated |
> |-----+--------------+-----------+----------+-------+-----------+--------+-----------------|
> | 1 | Task One | SLP | 1 | 0 | 1 | 0 | SLP, 2010-04-27 |
> | 2 | Task Two | SLP | 1 | 0 | 1 | 0 | SLP, 2010-04-27 |
> | 3 | Task Three | SLP | 2 | 0 | 2 | 0 | SLP, 2010-04-27 |
> | 4 | Task Four | SLP | 2 | 0 | 2 | 0 | SLP, 2010-04-27 |
> | 5 | Task Five | SLP | .25 | 0 | 0.25 | 0 | SLP, 2010-04-27 |
> | 5.1 | Another Task | XML team | 0 | 1 | 0 | 0 | SLP, 2010-04-27 |
> | 6 | Task Six | SLP | .25 | 0 | 0.25 | 0 | SLP, 2010-04-27 |
> | 6.1 | More Tasks | DB team | 3 | 0 | 3 | 0 | SLP, 2010-04-27 |
> | 7 | Task Seven | SLP | 3 | 0 | 3 | 0 | SLP, 2010-04-27 |
>
> When the colgroup list is created for this table, it reads:
>
> <colgroup><col align="right" /><col align="left" /><col align="left" /><col align="right" /><col align="right" /><col align="left" /><col align="left" /><col align="left" />
> </colgroup>
>
> Note that the first columns are correct, but the last few are not. It
> should read right, left, left, right, right, right, right, left.
>
> I believe that this is due to the (< i nline) comparison within
> org-format-org-table-html, which is nonsensical because it's trying to
> compare a column number with a number of rows. I've attached a patch
> for the problem.
Sebastien Rose writes:
> there was much discussion about a terminator and I ran into a problem,
> that made me think we need one. But then I found we had one --- it's
> just not used on HTML export.
>
>
> Below is a little file I wrote. Thanks to the `- __' items, it results
> in the XHTML closely to what I wanted it to.
> But only as long as I use those _undocumented_ `- __' items. Once you
> remove them, you'll see, that the `#+html: </div...' stuff ends up
> inside the last list item and the XHTML will not validate.
>
>
> As I looked at it, I found the most natural solution would be, to
> terminate the list by regarding the indentation of `#+WHATEVER' and
> `#+BEGIN_WHATEVER' if inside lists [fn:1].
>
>
>
> The patch below (diffed against `remove-compatibility-code') makes
> XHTML-export honor the indentation of `#+SPECIALS'.
>
>
>
> Here's the Org-file I wrote (remove and add the `- __' list items to see
> the effect):
>
> #+OPTIONS: toc:nil
> #+STYLE: <style type="text/css">
> #+STYLE: body,p,div,td{font-size:13px;font-family:sans-serif;}
> #+STYLE: div { text-align:left; }
> #+STYLE: #content {width:550px;
> #+STYLE: margin-left:auto;margin-right:auto;text-align:center; }
> #+STYLE: #postamble { width:550px;clear:both;border-top:1px solid black;
> #+STYLE: margin-left:auto;margin-right:auto;text-align:center; }
> #+STYLE: </style>
>
> * List of design patterns
>
> #+HTML: <div style="width:48%;float:left;">
> *Behavioural Patterns*
> - [[file:BatchCommand][BatchCommand]]
> - [[file:ChainOfResponsibility.org][Chain Of Responsibility]]
> - [[file:Command.org][Command]], UndoableCommand and BatchCommand
> - [[file:Interpreter.org][Interpreter]]
> - [[file:Iterator.org][Iterator]]
> - [[file:Mediator.org][Mediator]]
> - [[file:Memento.org][Memento]]
> - [[file:NullObject][NullObject]]
> - [[file:Observer.org][Observer]]
> - [[file:State.org][State]]
> - [[file:Strategy.org][Strategy]]
> - [[file:TemplateMethod.org][Template Method]]
> - [[file:Visitor.org][Visitor]]
> *Creational Patterns*
> - [[file:AbstractFactory.org][Abstract Factory]]
> - [[file:Builder.org][Builder]]
> - [[file:Factory.org][Factory]]
> - [[file:FactoryMethod.org][Factory Method]]
> - [[file:Prototype.org][Prototype]]
> - [[file:Singleton.org][Singleton]]
> - __
> #+html: </div>
> #+html: <div style="width:48%;float:right;">
> *Structural Patterns*
> - [[file:Adapter.org][Adapter]]
> - [[file:Composite.org][Composite]]
> - [[file::Bridge.org][Bridge]]
> - [[file:Decorator.org][Decorator]]
> - [[file:Facade.org][Facade]]
> - [[file:Flyweight.org][Flyweight]]
> - [[file:Proxy.org][Proxy]]
> *Unsorted*
> - [[file:BusinessDelegate.org][Business Delegate]]
> - [[file:DataAccessObject.org][Data Access Object]]
> - [[file:DataTransferObject.org][Data Transfer Object]]
> - [[file:DependencyInjection.org][Dependency Injection]]
> - [[file:FluentInterface.org][Fluent Interface]]
> - [[file:InversionOfControl.org][Inversion Of Control]]
> - [[file:ModelViewControler.org][Model View Controler]]
> - [[file:ModelViewPresenter.org][Model View Presenter]]
> - [[file:Plugin.org][Plugin]]
> - __
> #+HTML: </div>
Dan Davison writes:
> Bug report
> ==========
> If I have this:
>
> A [[file:zz.org::#mytarget][link]] to a target with a custom ID
>
> and export it to HTML, I get
>
> A <a href="zz.html##mytarget">link</a> to a target with a custom ID
>
> which (in firefox on linux) links to the file but does not jump to the
> target. However, if I change the '##' to '#' then firefox jumps to the
> correct location. Is this an org bug?
>
> Very tentatively proposed patch
> ===============================
> I've investigated a bit (notes below), resulting in this proposed patch:
>
> --8<---------------cut here---------------start------------->8---
> diff --git a/lisp/org-html.el b/lisp/org-html.el
> index aa70408..5ee5b19 100644
> --- a/lisp/org-html.el
> +++ b/lisp/org-html.el
> @@ -1110,7 +1110,7 @@ lang=\"%s\" xml:lang=\"%s\">
> (abs-p (file-name-absolute-p filename))
> thefile file-is-image-p search)
> (save-match-data
> - (if (string-match "::\\(.*\\)" filename)
> + (if (string-match "::#?\\(.*\\)" filename)
> (setq search (match-string 1 filename)
> filename (replace-match "" t nil filename)))
> (setq valid
> --8<---------------cut here---------------end--------------->8---
>
> Doc patch
> =========
> The link above (file:zz.org::#mytarget) was created by C-c l on a
> heading with a CUSTOM_ID property. However, I couldn't see where in the
> manual links of this form are documented. Do we need to add this link
> type to section 4.7 "Search options in file links", e.g.
>
> --8<---------------cut here---------------start------------->8---
> diff --git a/doc/org.texi b/doc/org.texi
> index f49f056..c8cc1a5 100644
> --- a/doc/org.texi
> +++ b/doc/org.texi
> @@ -3116,6 +3116,7 @@ link, together with an explanation:
> [[file:~/code/main.c::255]]
> [[file:~/xx.org::My Target]]
> [[file:~/xx.org::*My Target]]
> +[[file:~/xx.org::#my-custom-id]]
> [[file:~/xx.org::/regexp/]]
> @end example
>
> @@ -3130,6 +3131,8 @@ link will become an HTML reference to the corresponding named anchor in
> the linked file.
> @item *My Target
> In an Org file, restrict search to headlines.
> +@item #my-custom-id
> +Link to a heading with a @code{CUSTOM_ID} property
> @item /regexp/
> Do a regular expression search for @code{regexp}. This uses the Emacs
> command @code{occur} to list all matches in a separate window. If the
> --8<---------------cut here---------------end--------------->8---
>
> Notes
> =====
> At line 1134 of org-html.el there is
>
> (setq thefile (concat thefile "#"
> (org-solidify-link-text
> (org-link-unescape search)))))
>
> during evaluation of which 'search is bound to "#mytarget", which
> suggested that the problem might be in the regexp parsing creating
> 'search.
Daniel Clemente writesL
> Hi, I found an HTML export bug with org-mode 6.34c-140-g44c8 and
> older. I used:
>
> --------------------------------------------------------
> * only one section
> #+BEGIN_EXAMPLE:
>
> We need:
> ,* pears
> ,* lettuce
> ,* watermelons
>
> Very important!
> #+END_EXAMPLE:
> --------------------------------------------------------
>
> And the outputed table of contents had this code:
>
> --------------------------------------------------------
> <div id="text-table-of-contents">
> <ul>
> <li><a href="#sec-1">1 only one section </a></li>
> <li><a href="#sec-2">2 pears</a></li>
> <li><a href="#sec-3">3 lettuce</a></li>
> <li><a href="#sec-4">4 watermelons</a></li>
> </ul>
> </div>
> --------------------------------------------------------
>
> This is wrong because the asterisks inside the example don't
> represent headers. There should be only one header.
This support was totally broken. It works now again. Unfortunately
it is not possible to edit the table directly in the org-mode buffer
anymore - to edit such a table, you have to use C-c '
