Re: [O] bug-tracker

[Andreas Röhler]

Am 25.02.2013 16:51, schrieb Sebastien Vauban:

Hi,

Suvayu Ali wrote:

On Fri, Feb 22, 2013 at 08:56:54PM +0100, Andreas Röhler wrote:

With exception of the noise, M-x report-emacs-bugs tends to send.


Org already uses one of its own: org-submit-bug-report


Maybe we could add an alias such as `M-x report-org-bugs' to mimick that one?

Best regards,
   Seb


+1

[O] org-create-formula-image-with-imagemagick conflicts with org-latex-pdf-process

[Florian Beck]

`org-create-formula-image-with-imagemagick' doesn't handle the case that
`org-latex-pdf-process' is set to a function.

To reproduce:

 - set `org-latex-pdf-process' to a function
 - (setq org-latex-create-formula-image-program 'imagemagick)
   this makes preview fail
 - set #+OPTIONS: latex:imagemagick => html export broken

However, just calling this function from
`org-create-formula-image-with-imagemagick' would not be a good idea.
How about adding a new variable `org-latex-formula-pdf-process'?

-- 
Florian Beck

Re: [O] How to make the new exporter open PDF using evince?

[Martin Marier]

Hi James,

Here is a third vote for mailcap.  I have (only) this in my .mailcap
file:

application/pdf; okular '%s';  test=test -n "$DISPLAY"

It does the job.

Cheers,
Martin

PS Cool to see a (notorious) sc user on this list as well.


2013-13-25 08:06   James Harkins :
> On Feb 25, 2013 2:52 PM, "Nick Dokos"  wrote:
>> I like putting things in ~/.mailcap, but you can season to taste.
>
> Ok, that's 2 votes so far for mailcap. I'll try that later. Thanks!
>
> hjh

-- 
Martin Marier
http://www.martinmarier.com

Re: [O] 13 failures on make ./update

[Jude DaShiell]

Sorry about the misinformation, wheezy current is using emacs 23.4 not 
emacs 23.5.

On Mon, 25 Feb 2013, Michael Gauland wrote:

> Jude DaShiell  shellworld.net> writes:
> 
> > In toplevel form:
> 
> > ox.el:80:1:Error: Cannot open load file: tabulated-list
> 
> I ran into this as well, and resolved it by adding the tabulated-list package
> from ELPA, and adding "-L ~/.emacs.d/elpa/tabulated-list-0" to the definition 
> of
> EMACS in my local.mk.
> 
> Hope that helps.
> 
> Kind Regards,
> Mike
> 
> 
> 
> 

---
jude 
Remember Microsoft didn't write Tiger 10.4 or any of its successors.

Re: [O] C-c ^ not fully useful

[François Pinard]

Bastien  writes:

> [1] http://orgmode.org/cgit.cgi/org-mode.git/commit/?id=30d6dc
> [2] http://orgmode.org/cgit.cgi/org-mode.git/commit/?id=662cb9

While your commits are rather small, I would likely never have figured
out how to do them, the magic goes over my head.  It's a little like
playing go against someone who is far from your own level: you
objectively observe that the heavens is falling apart on your head, but
you just don't understand how nor why it is happening. :-)

By the way, Bastien, it seems that your correction wonderfully works.
It's so comfortable being able to see long lists of links (visually)
sorted in a correct way.  Thanks a lot for this.

François

P.S. About an option to sort the previous way, that is, by the physical
contents of the line, visible or not, I do not have a use case for it, I
would not need such an option.

I sometimes, yet not often, need to group together links by their
originating site, and then, the standard Emacs line sorting function
gave me a very good approximation, good enough for my little needs.

Re: [O] Add agenda entries into diary to export weelky calendar

[SAKURAI Masashi]

Hi,

> Alternatives:
> I read about calfw and org2hpda. However, I did not found a way to generate a 
> printable version of
> calfw (and I had trouble to set it up). For org2hpda I still struggle with 
> the installation and it
> seems to be broken at the moment. Not sure.

I'm an author of calfw. I would help you about calfw.

After displaying your calfw buffer, you can get a HTML buffer 
with M-x htmlfontify-buffer.


Regards,
--
SAKURAI, Masashi (family, given)
m.saku...@kiwanami.net

Re: [O] [new exporter][latex] does org-preview-latex-fragment use #+latex_header ?

[Myles English]

Nicolas Goaziou writes:

>> I have a problem where org-preview-latex-fragment appears not to use a
>> style file the latex header.
>>
>> Starting emacs like this:
>>
>> emacs -Q -l ~/minimal.el ~/file.org
>>
>> When I export the whole buffer to pdf it looks right.
>>
>> When I call org-preview-latex-fragment on the fragment the definitions
>> in a.sty are not picked up.  This previously worked when using the
>> new exporter before it was merged.
>> -- ~/bug.sty --
>> \newcommand{\mysymbol}{\mathbf v}
>>
>> -- minimal.el 
>> (add-to-list 'load-path "~/.emacs.d/plugins/org-mode/lisp")
>> (require 'ox)
>>
>> -- file.org ---
>>
>> #+STARTUP: indent
>> #+LATEX_HEADER: \usepackage{~/bug}
>>
>>
>> * heading
>>
>> \[ \mysymbol = f \]-- NO WORK
>>
>> \[ 0 = f \]-- WORKS
>>
>> --
>
> I removed this functionality when clearing out old exporter from org.el.
> It should be back in master.

Thanks for looking at this, I tried just now and can't see any change in
what I reported above.

Myles

Re: [O] {New exporter] What happened to the export template

[Suvayu Ali]

Hey Seb,

On Mon, Feb 25, 2013 at 02:15:05PM +0100, Sebastien Vauban wrote:
> 
> PS- By the way, there is already such a sort of template for Beamer...

I believe Nicolas' argument was, for the new exporter such a template
depends on the backend hence a default one for beamer makes sense but
not a backend agnostic template.

I'm not completely sure I follow the argument though, since keywords
like TITLE, DATE, AUTHOR, or even an OPTIONS line seem generic enough
for most backends.  But then I have not thought long enough to spot any
inconsistencies.  :-p

Cheers,

-- 
Suvayu

Open source is the future. It sets us free.

Re: [O] New HTML exporter: Oddities with figure placement

[Stefan Vollmar]

Dear Nicolas,

On 26.02.2013, at 00:14, Nicolas Goaziou wrote:

>> [...] This code used to be suppressed by
>> 
>> :style-include-default nil
>> :style-include-scripts nil
>> 
>> in the org-publish-project-alist - either this functionality is
>> currently not available or the keyword has changed. Thanks for any
>> help with this!
> 
> It should be :html-style-include-default and :html-style-include-scripts
> according to html back-end definition in ox-html.el (lines 122, 123).


sorry, I could have looked that up myself - and, again, thank you (somehow 
these lightning fast responses and fixes of yours remind me of a thread several 
years ago in which there was speculation about the actual number of excellent 
programmers using the pseudonym "Carsten Dominik", and of course there also 
quite a few "Bastien's" out there...).

Warm regards, 
 Stefan
-- 
Dr. Stefan Vollmar, Dipl.-Phys.
Head of IT group
Max-Planck-Institut für neurologische Forschung
Gleuelerstr. 50, 50931 Köln, Germany
Tel.: +49-221-4726-213  FAX +49-221-4726-298
Tel.: +49-221-478-5713  Mobile: 0160-93874279
Email: voll...@nf.mpg.de   http://www.nf.mpg.de








smime.p7s
Description: S/MIME cryptographic signature

Re: [O] New exporter: Stack overflow in regexp matcher on HTML export of large-ish org-babel blocks

[Kyle Machulis]

Just tested it, works now. Thanks! :D

On Mon, Feb 25, 2013 at 3:31 PM, Nicolas Goaziou wrote:

> Hello,
>
> Kyle Machulis  writes:
>
> > I'm trying to html export my babel'd config. It seems to be choking on
> some
> > of the larger blocks (300+ lines) of code (offending blocks seem to be
> org,
> > erc, programming config). I should probably chop these down a bit for
> > readability (still working on finshing org-ifying it), but I'd also
> figure
> > we probably shouldn't be dying on the matcher function.
>
> This should be fixed in master.
>
> Thank you for reporting this.
>
>
> Regards,
>
> --
> Nicolas Goaziou
>

Re: [O] New exporter: Stack overflow in regexp matcher on HTML export of large-ish org-babel blocks

[Nicolas Goaziou]

Hello,

Kyle Machulis  writes:

> I'm trying to html export my babel'd config. It seems to be choking on some
> of the larger blocks (300+ lines) of code (offending blocks seem to be org,
> erc, programming config). I should probably chop these down a bit for
> readability (still working on finshing org-ifying it), but I'd also figure
> we probably shouldn't be dying on the matcher function.

This should be fixed in master.

Thank you for reporting this.


Regards,

-- 
Nicolas Goaziou

[O] New exporter: Stack overflow in regexp matcher on HTML export of large-ish org-babel blocks

[Kyle Machulis]

I'm trying to html export my babel'd config. It seems to be choking on some
of the larger blocks (300+ lines) of code (offending blocks seem to be org,
erc, programming config). I should probably chop these down a bit for
readability (still working on finshing org-ifying it), but I'd also figure
we probably shouldn't be dying on the matcher function.

Original file:

http://github.com/qdot/conf_emacs/emacs_conf.org

Crappy hand-entered backtrace that's missing huge parameters:

(string-match ...)
(org-html-fontify-code ...)
...

org-version:
Org-mode version 7.9.3e (7.9.3e-3-gb07a9b @
/usr/share/emacs/24.3.50/lisp/org/)

Re: [O] New HTML exporter: Oddities with figure placement

[Nicolas Goaziou]

Hello,

Stefan Vollmar  writes:

> if you look at the HTML code generated by Org-mode you will find this line in 
> the embedded CSS code (line 45):
>
>   div.figure p { text-align: center; }
>
> which causes the effect you have described.
> This code used to be suppressed by
>
> :style-include-default nil
> :style-include-scripts nil
>
> in the org-publish-project-alist - either this functionality is
> currently not available or the keyword has changed. Thanks for any
> help with this!

It should be :html-style-include-default and :html-style-include-scripts
according to html back-end definition in ox-html.el (lines 122, 123).


Regards,

-- 
Nicolas Goaziou

Re: [O] [new exporter][latex] does org-preview-latex-fragment use #+latex_header ?

[Nicolas Goaziou]

Hello,

Myles English  writes:

> I have a problem where org-preview-latex-fragment appears not to use a
> style file the latex header.
>
> Starting emacs like this:
>
> emacs -Q -l ~/minimal.el ~/file.org
>
> When I export the whole buffer to pdf it looks right.
>
> When I call org-preview-latex-fragment on the fragment the definitions
> in a.sty are not picked up.  This previously worked when using the
> new exporter before it was merged.
>
> Can anyone help?
>
> Thanks,
> Myles
>
>
> -- ~/bug.sty --
> \newcommand{\mysymbol}{\mathbf v}
>
> -- minimal.el 
> (add-to-list 'load-path "~/.emacs.d/plugins/org-mode/lisp")
> (require 'ox)
>
> -- file.org ---
>
> #+STARTUP: indent
> #+LATEX_HEADER: \usepackage{~/bug}
>
>
> * heading
>
> \[ \mysymbol = f \]-- NO WORK
>
> \[ 0 = f \]-- WORKS
>
> --

I removed this functionality when clearing out old exporter from org.el.
It should be back in master.

Thank you for your report.


Regards,

-- 
Nicolas Goaziou

Re: [O] pxref in texinfo export

[Nicolas Goaziou]

Jonathan Leech-Pepin  writes:

>  For @xref{} I would need to know if it was at the start of a sentence and
> followed
> by a comma or period.
> For @pxref{} I would need to determine if it was at end of sentence,
> mid sentence followed by a comma or within parentheses, and not preceeded by
> "see" or "see".  Although even this would not suffice, since there are
> contexts where
> @ref{} is the better choice.

FWIW, from `org-texinfo-link',

  (org-export-data (org-export-get-previous-element link info t) info)

will give you the exported string so far in the container element and 

  (org-export-data (org-export-get-next-element link info t) info)

will return the string that will follow your link.

You need to upgrade Org for the first snippet, as order for `o-e-g-p-e'
return value has changed.


Regards,

-- 
Nicolas Goaziou

Re: [O] New HTML exporter: Oddities with figure placement

[Stefan Vollmar]

Dear Richard,

On 25.02.2013, at 18:55, Richard Stanton wrote:

> It seems that figure placement has changed in HTML files generated by the
> new (compared with the old) exporter.
> 
> For example, here's a simple org file:
> 
> -
> 
> This is an org file
> 
> [[file:figure.png]]
> 
> * Abstract
> This is an abstract
> 
> -
> 
> When I export, all looks fine, except that the figure is centered (left to
> right) rather than being left-justified, which I could have sworn it used
> to be. Since I prefer left justification by default, I tried adding the
> line
[...]

You are right, the effect has to do with the new exporter but is easy to 
explain and change:

if you look at the HTML code generated by Org-mode you will find this line in 
the embedded CSS code (line 45):

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

which causes the effect you have described.
This code used to be suppressed by

:style-include-default nil
:style-include-scripts nil

in the org-publish-project-alist - either this functionality is currently not 
available or the keyword has changed. Thanks for any help with this!

However, here is a simple fix for now: include this line in a CSS file (it will 
be parsed after the embedded CSS code and overwrites it):

  div.figure p { text-align: left; }

Warm regards,
 Stefan
-- 
Dr. Stefan Vollmar, Dipl.-Phys.
Head of IT group
Max-Planck-Institut für neurologische Forschung
Gleuelerstr. 50, 50931 Köln, Germany
Tel.: +49-221-4726-213  FAX +49-221-4726-298
Tel.: +49-221-478-5713  Mobile: 0160-93874279
Email: voll...@nf.mpg.de   http://www.nf.mpg.de








smime.p7s
Description: S/MIME cryptographic signature

Re: [O] pxref in texinfo export

[Jonathan Leech-Pepin]

Hello

On 25 February 2013 16:48, Subhan Tindall wrote:

> I don't think there is a specific context that can clearly separate
> them. The differences are largely semantic, not syntactic. What is
> needed is some sort of marker on the tag in the original file telling
>  it what kind of link is to be used.
>

Agreed, although there is a semi-syntactic method potentially.


>
> On Mon, Feb 25, 2013 at 1:38 PM, Nicolas Goaziou 
> wrote:
> > Hello,
> >
> > Jonathan Leech-Pepin  writes:
> >
> >> I had to compare these possible outcomes when working on the texinfo
> >> exporter.  Since links are parsed before being included in their
> >> paragraphs, I did not have a way to obtain context and therefore
> >> attempt to guess (and be successful) at which type of reference was
> >> intended by a link in Org.
> >
> > What kind of context would you need to know? The string that will be
> > exported just before the current ref link?
> >


 For @xref{} I would need to know if it was at the start of a sentence and
followed
by a comma or period.
For @pxref{} I would need to determine if it was at end of sentence,
mid sentence followed by a comma or within parentheses, and not preceeded by
"see" or "see".  Although even this would not suffice, since there are
contexts where
@ref{} is the better choice.

Allowing for attributes on the links would allow for differentiating,
however the
alternative (which is the current behaviour) is just to create them all as
@ref{} and
then include the semantic context (See, see or nil) as appropriate for
export.

Regards,

Jon


> > Regards,
> >
> > --
> > Nicolas Goaziou
>
>
>
> --
> Subhan Michael Tindall | Software Developer
> | s...@rentrakmail.com
> RENTRAK | www.rentrak.com | NASDAQ: RENT
>

Re: [O] pxref in texinfo export

[Jonathan Leech-Pepin]

Hello

On 25 February 2013 16:34, Subhan Tindall wrote:

> I noticed you left out @inforef, was that by design?  It actually does
> behave quite differently than other members of the @*ref family, and
> the more arguments it gets the more different it looks IE Here's an
> example with a full 5 arguments:
> REF *note Arg2: (Arg4)Lore Ipsum.
>  INFOREF *note Arg2: (Arg3)Lore Ipsum Arg4, Arg5


I omitted @inforef, @uref, @url @email by design because they are
external links in an org file and can be processed differently.

Org Links only have 2 arguments at most (destination and description)
so the additional arguments are skipped as well.

Info links are format: [[info::][description] or
[[info:#][description]] so can provide the 3 arguments
by splitting between file and node.

Regards

>
>
> On Mon, Feb 25, 2013 at 12:29 PM, Jonathan Leech-Pepin
>  wrote:
> > (Here are the attached files, forgot to add them)
> >
> >
> > On 25 February 2013 15:24, Jonathan Leech-Pepin
> >  wrote:
> >>
> >> Hello,
> >>
> >> On 25 February 2013 14:01, Subhan Tindall <
> subhan.tind...@rentrakmail.com>
> >> wrote:
> >>>
> >>> The point being that compiling .texinfo source into an Info file
> >>> treats references differently. For example:
> >>> (@pxref{my_node_name}).  will compile just fine.
> >>> (@ref{my_node_name}). will not.
> >>
> >>
> >> Both work perfectly fine for me.
> >> makeinfo (GNU texinfo) 5.0
> >>
> >>>
> >>> There are also differences in case
> >>> (see v. See, note v. Note), and differences in output by ref type
> >>> depending on target output of file (info, DVI, HTML,...). For example,
> >>> @pxref generates different punctuation for typeset v. info files, @ref
> >>> does not generate a 'See ' in printed material while @xref does, etc.
> >>>
> >>> Although the differences are subtle, they really are not equivalent
> >>> and should not be treated as such.
> >>
> >>
> >> With a slight amount of work on the user's part, they can be made
> >> functionally equivalent on export.
> >>
> >> Using the two attached minimal .texi files (good-ref.texi is using
> >> @xref/@pxref as is preferred while ref.texi is using @ref with
> >> appropriate See/see added in the text) and disregarding filename
> >> differences (since they are noted in the info output) I get the
> >> following differences:
> >>
> >> > makeinfo --html --no-split good-ref.texi ref.texi
> >> 0 Diffs
> >>
> >> > makeinfo --docbook --no-split good-ref.texi ref.texi
> >> Filename ID appears in diff
> >>
> >> > makeinfo --xml --no-split good-ref.texi ref.texi
> >> Filename difference.
> >>
> >> Links are different since TexinfoML does still distinguish xref/pxref
> >> and ref in how they create the links.
> >>
> >> > makeinfo --no-split good-ref.texi ref.texi
> >>
> >> The info file does show the expected differences between the two
> >> documents, notably that the "@xref{}" becomes "*Note" while the
> >> equivalent "See @ref{}" becomes "See *note" with @pxref{}->*note vs
> >> see @ref{} -> see *note.
> >>
> >> However once they are viewed within the *info* buffer (C-u C-h i
> >> good-ref.info/ref-only.info) the lines in question are visually
> >> identical since *Note becomes "See" and *note becomes "see" if there
> >> is not already "see" present.
> >>
> >> I will not disagree that @ref, @pxref and @xref are subtly different,
> >> however with slight user intervention @ref can be used in the same
> >> above locations by simply replacing:
> >>
> >> @xref{}  -> "See @ref{}"
> >> @pxref{} -> "see @ref{}"
> >>
> >> I had to compare these possible outcomes when working on the texinfo
> >> exporter.  Since links are parsed before being included in their
> >> paragraphs, I did not have a way to obtain context and therefore
> >> attempt to guess (and be successful) at which type of reference was
> >> intended by a link in Org.  Restricting it to @ref{} in all cases,
> >> even if it added a slight burden to the user (4 additional characters
> >> to type in Org) if they wanted to emulate @xref or @pxref was in my
> >> opinion the best choice.
> >>
> >> Regards,
> >>
> >> --
> >> Jon
> >>
> >> [...]
> >>
> >
>
>
>
> --
> Subhan Michael Tindall | Software Developer
> | s...@rentrakmail.com
> RENTRAK | www.rentrak.com | NASDAQ: RENT
>

Re: [O] [ox-beamer] Frame subtitles are not handled anymore

[Sebastien Vauban]

Hi Nicolas,

Nicolas Goaziou wrote:
> "Sebastien Vauban" writes:
>>
>> It took me quite some time, but I'm at the end of converting a 90 slides
>> presentation from the old to the new exporter.
>>
>> In that presentation, there is (just!) one thing which does not work
>> anymore: the frame subtitles.

BTW, it has to be emphasized: just ONE thing for which I could not find a
direct mapping toward a solution; that's pretty excellent!

>> Before, I could write:
>>
>> * News \\ Technology
>>
>> ...
>>
>> and get that exported as:
>>
>> \begin{frame}
>>   \frametitle{News}
>>   \framesubtitle{Technology}
>>   ...
>> \end{frame}
>>
>> (or similar.)
>>
>> Now, such a title is simply cut over 2 lines; hence, the use of a bad font
>> (in LaTeX) for the subtitle (font as big as the one customized for the
>> title itself).
>>
>> How could we write subtitles again in Beamer presentations?
>
> It was discussed a few months ago.

I must have missed it.

> To sum it up, I don't like that syntax, because it's very close to line
> breaks.

But the advantage was that you could almost not expect that markup as a valid
string. While, would we opt for:

- [Title] Subtitle
- Title > Subtitle

you wouldn't be so sure.

Note that, to be closer to the real Beamer syntax, one could think of:

- {Title} Subtitle
- Title {Subtitle}

Such syntax have the advantage to stay readable and quite explicit, even if
translated "verbatim" in other backends (such as HTML): that was already the
case of the old syntax: in HTML, "Title \\ Subtitle" was very readable, even
if not processed in any particular way (and one could image a CSS-only
solution to even present it more as a real subtitle).

> But I'm not against some easy way to add a subtitle to a frame.
>
> A special property isn't satisfactory either, because those aren't
> parsed. So
>
>   :beamer_subtitle: *bold*
>
> will probably not give you what you expect. Do you have any suggestion
> about it?

No, it would not be really satisfactory, not really for bold (as, anyway,
titles are generally bold), but more for = markups: "Code for =org-agenda=",
for an example of subtitle.

> Meanwhile, doesn't the following work?
>
>   #+BEAMER: \framesubtitle{Technology}

Yes, meanwhile, that does work.

Best regards,
  Seb

--
Sebastien Vauban

Re: [O] [PATCH] bug in expansion of variables in babel Perl

[D M German]

 Achim> D M German  uvic.ca> writes:
 >> I think the issue is that, at least in my computer the variable $\
 >> returns empty (the record separator).

 Achim> Thinko on my side, what I wanted was the input record separator "$/"
 Achim> (to avoid
 Achim> specifying a literal newline for those systems where this is actually
 Achim> multi-character).

Hi Achim,

Once I changed it:

(defvar org-babel-perl-wrapper-method
  "{
  my @r = eval( q(
%s
  ));
  open my $BO, qq(>%s) or die qq( Perl: Could not open output file.$\\ );
  print $BO join($/, @r), $/ ;
}")

the result now has \n in between fields (literally):

#+name: t_output_table
#+begin_src perl :results table
print "Test\n";
(1, 2)
#+end_src

#+RESULTS: t_output_table
| 1\n2\n |

what is the expected field separator for Org-babel?

 Achim> Regards,
 Achim> Achim.




--
Daniel M. German  "Prose is intrinsically linear; 
   a good book carries the reader forward
   The Economist ->on the crest of the words"
http://turingmachine.org/
http://silvernegative.com/
dmg (at) uvic (dot) ca
replace (at) with @ and (dot) with .

 

[O] [Feature] Highlighting of timestamps

[Sebastien Vauban]

Hello,

With recent versions of Org mode, the Highlighting of timestamps is not
happening between the right positions anymore: it begins one character before
the beginning of the timestamp, as you can see on
http://screencast.com/t/llxtNT3m.

Best regards,
  Seb

-- 
Sebastien Vauban

Re: [O] pxref in texinfo export

[Subhan Tindall]

I don't think there is a specific context that can clearly separate
them. The differences are largely semantic, not syntactic. What is
needed is some sort of marker on the tag in the original file telling
it what kind of link is to be used.



On Mon, Feb 25, 2013 at 1:38 PM, Nicolas Goaziou  wrote:
> Hello,
>
> Jonathan Leech-Pepin  writes:
>
>> I had to compare these possible outcomes when working on the texinfo
>> exporter.  Since links are parsed before being included in their
>> paragraphs, I did not have a way to obtain context and therefore
>> attempt to guess (and be successful) at which type of reference was
>> intended by a link in Org.
>
> What kind of context would you need to know? The string that will be
> exported just before the current ref link?
>
>
> Regards,
>
> --
> Nicolas Goaziou



-- 
Subhan Michael Tindall | Software Developer
| s...@rentrakmail.com
RENTRAK | www.rentrak.com | NASDAQ: RENT

Re: [O] pxref in texinfo export

[Nicolas Goaziou]

Hello,

Jonathan Leech-Pepin  writes:

> I had to compare these possible outcomes when working on the texinfo
> exporter.  Since links are parsed before being included in their
> paragraphs, I did not have a way to obtain context and therefore
> attempt to guess (and be successful) at which type of reference was
> intended by a link in Org.

What kind of context would you need to know? The string that will be
exported just before the current ref link?


Regards,

-- 
Nicolas Goaziou

Re: [O] pxref in texinfo export

[Subhan Tindall]

I noticed you left out @inforef, was that by design?  It actually does
behave quite differently than other members of the @*ref family, and
the more arguments it gets the more different it looks IE Here's an
example with a full 5 arguments:
REF *note Arg2: (Arg4)Lore Ipsum.
INFOREF *note Arg2: (Arg3)Lore Ipsum Arg4, Arg5




On Mon, Feb 25, 2013 at 12:29 PM, Jonathan Leech-Pepin
 wrote:
> (Here are the attached files, forgot to add them)
>
>
> On 25 February 2013 15:24, Jonathan Leech-Pepin
>  wrote:
>>
>> Hello,
>>
>> On 25 February 2013 14:01, Subhan Tindall 
>> wrote:
>>>
>>> The point being that compiling .texinfo source into an Info file
>>> treats references differently. For example:
>>> (@pxref{my_node_name}).  will compile just fine.
>>> (@ref{my_node_name}). will not.
>>
>>
>> Both work perfectly fine for me.
>> makeinfo (GNU texinfo) 5.0
>>
>>>
>>> There are also differences in case
>>> (see v. See, note v. Note), and differences in output by ref type
>>> depending on target output of file (info, DVI, HTML,...). For example,
>>> @pxref generates different punctuation for typeset v. info files, @ref
>>> does not generate a 'See ' in printed material while @xref does, etc.
>>>
>>> Although the differences are subtle, they really are not equivalent
>>> and should not be treated as such.
>>
>>
>> With a slight amount of work on the user's part, they can be made
>> functionally equivalent on export.
>>
>> Using the two attached minimal .texi files (good-ref.texi is using
>> @xref/@pxref as is preferred while ref.texi is using @ref with
>> appropriate See/see added in the text) and disregarding filename
>> differences (since they are noted in the info output) I get the
>> following differences:
>>
>> > makeinfo --html --no-split good-ref.texi ref.texi
>> 0 Diffs
>>
>> > makeinfo --docbook --no-split good-ref.texi ref.texi
>> Filename ID appears in diff
>>
>> > makeinfo --xml --no-split good-ref.texi ref.texi
>> Filename difference.
>>
>> Links are different since TexinfoML does still distinguish xref/pxref
>> and ref in how they create the links.
>>
>> > makeinfo --no-split good-ref.texi ref.texi
>>
>> The info file does show the expected differences between the two
>> documents, notably that the "@xref{}" becomes "*Note" while the
>> equivalent "See @ref{}" becomes "See *note" with @pxref{}->*note vs
>> see @ref{} -> see *note.
>>
>> However once they are viewed within the *info* buffer (C-u C-h i
>> good-ref.info/ref-only.info) the lines in question are visually
>> identical since *Note becomes "See" and *note becomes "see" if there
>> is not already "see" present.
>>
>> I will not disagree that @ref, @pxref and @xref are subtly different,
>> however with slight user intervention @ref can be used in the same
>> above locations by simply replacing:
>>
>> @xref{}  -> "See @ref{}"
>> @pxref{} -> "see @ref{}"
>>
>> I had to compare these possible outcomes when working on the texinfo
>> exporter.  Since links are parsed before being included in their
>> paragraphs, I did not have a way to obtain context and therefore
>> attempt to guess (and be successful) at which type of reference was
>> intended by a link in Org.  Restricting it to @ref{} in all cases,
>> even if it added a slight burden to the user (4 additional characters
>> to type in Org) if they wanted to emulate @xref or @pxref was in my
>> opinion the best choice.
>>
>> Regards,
>>
>> --
>> Jon
>>
>> [...]
>>
>



-- 
Subhan Michael Tindall | Software Developer
| s...@rentrakmail.com
RENTRAK | www.rentrak.com | NASDAQ: RENT

Re: [O] [RFC] Org version of the Org manual

[Carsten Dominik]

Hi Tom,

wow, a daring project.  This would indeed be a testimony to the quality of the 
exporter if this works and gives proper output!  I am curious and looking 
forward to seeing the results.

- Carsten

On 25.2.2013, at 21:21, Thomas S. Dye  wrote:

> Aloha all,
> 
> An experiment to see if it is possible to convert the Org manual to Org
> is now (hopefully) at the "proof of concept" stage and I would like to
> determine whether or not the approach is viable. The experiment is here:
> 
> https://github.com/tsdye/orgmanual.git
> 
> The file orgmanual.org has a heading, * Instructions for use, that
> explains how to set up asynchronous export with the new exporter. The
> repo also contains orgmanual.info in case you don't want to hassle with
> exporting the org file and just want to see what it looks like in info.
> I'm able to generate an info file without makeinfo raising any errors or
> warnings. 
> 
> There is also a heading, * Improvements and fixes, that includes a list
> of problems that either need to be fixed or are in the process of being
> fixed. Obviously, the file is not perfect, but I do believe it is good
> enough to judge whether success will be possible. At any rate, I need to
> pull myself away from this project for a week or so to do other things
> and can't get caught up making editorial changes or working on the (to
> me) thorny issues that remain.
> 
> Sections with problems have been given FIXME keywords. In some cases,
> problem text (especially in macros) has been replaced with `XXX'.
> Proposed fixes for these nagging issues will be greatly appreciated.
> 
> By way of background, my initial goal was to replicate the Org manual
> precisely. This goal was abandoned when I realized that the various
> contributors to the manual (including me a few years ago) had different
> ideas about what a .texi file should look like and had created a somewhat
> eclectic product.  The goal now is to have a "functional equivalent" of
> the manual.
> 
> The ultimate goal is to maintain the Org manual in Org, rather than
> .texi, and to have the infrastructure in place in time to support the
> major revisions required by the forthcoming release of version 8.0.
> 
> Many thanks to Nicolas Goaziou and to Jonathan Leech-Pepin for their
> excellent work on the new exporter framework and the texinfo exporter,
> and for their patience with my sometimes exasperated (and exasperating)
> queries.  Jonathan showed me the way forward at an early stage and
> devised most of the macros.
> 
> I look forward to picking this project up again in a week or so, or
> learning from my Org colleagues that the project ought to be scuttled.
> 
> All the best,
> Tom
> 
> -- 
> T.S. Dye & Colleagues, Archaeologists
> 735 Bishop St, Suite 315, Honolulu, HI 96813
> Tel: 808-529-0866, Fax: 808-529-0884
> http://www.tsdye.com
> 

Re: [O] [PATCH] datetree: Recognize year headline with tags as a match

[Tim Burt]

Jeffrey Brent McBeth  writes:

> On Mon, Feb 25, 2013 at 10:48:16AM +0100, Bastien wrote:
>> Hi Tim,
>> 
>> Tim Burt  writes:
>> 
>> > * lisp/org-datetree.el (org-datetree-find-year-create):
>> >  Include regexp for tags.  Syntax was taken directly
>> >  from org-todo-line-tags-regexp in org.el.
>> 
>> Applied, thanks a lot for the patch and the detailed change log!
>> 
>> Best,
>
> I can confirm that latest git fixes my use case.  Thank you both so much.

Excellent all the way 'round.


>
> Jeff

-- 
Tim Burt
www.rketburt.org
"It is healthful to every sane man to utter the art within him;" -- GK 
Chesterton

Re: [O] latex exporter: different itemize environment

[Andreas Leha]

Hi Nicolas,

Nicolas Goaziou  writes:

> Hello,
>
> Andreas Leha  writes:
>
>> Hi all (and Nicolas),
>>
>> from =org-e-latex.el= (I have to upgrade - I know):
>> ,
>> | ;; Plain lists accept two optional attributes: `:environment' and
>> | ;; `:options'.  The first one allows to use a non-standard environment
>> | ;; (i.e. "inparaenum").  The second one allows to specify optional
>> | ;; arguments for that environment (square brackets are not mandatory).
>> `
>>
>> I can not make the :enviroment switch work.
>>
>> Following is a small presentation with a non-indented version of
>> itemize.  But when I export it, I still get an \begin{itemize} when
>> instead I'd like \begin{nonindentlist}.
>>
>> What am I missing?
>
> [...]
>
>>#+ATTR_LATEX: :environment nonindentlist
>>- some
>>- bullet
>>- points
>
> It should be #+attr_beamer: :environment nonindentlist since this
> property is defined in Beamer back-end's documentation.

Thanks for this.  #+attr_beamer: works fine (although I am not sure, I
understand what you said here...)

>
> Since arguments are the same and beamer back-end is derived from latex
> anyway, lists should now accept both, though.
>

Regards,
Andreas

Re: [O] HTML export: no date in postamble unless set manually

[Nick Dokos]

Nick Dokos  wrote:

> Richard Stanton  wrote:
> 
> > I have  org-export-html-postamble set to t. When I export a simple org
> > file that has no explicit #+date line (using the new exporter), I get a
> > line that says "Date:" at the bottom of the resulting HTML file, but
> > there's no date listed next to it. If I add an explicit #+date line, it is
> > correctly transferred to the bottom of the HTML file, but wouldn't it make
> > sense to have today's date listed if no explicit alternative is provided?
> > At any rate, adding a line that says "Date:" with nothing after the colon
> > doesn't seem like the optimal default setting.
> > 
> 
> The backend-specific variables have been renamed in the new exporter: try
> org-html-postamble. Check the FAQ:
> 
> http://orgmode.org/worg/org-faq.html#new-exporter-switch
> 
> for more details.
> 

OK, now that I've tried it a bit, I can see that the variable name is
not the reason: I can reproduce the empty date after setting
org-html-postamble to t.  The code looks like this
(ox-html.el:org-html--build-postamble):

,
|  (let ((date (if (not (plist-get info :with-date)) ""
|(org-export-data (plist-get info :date) info)))
`

:with-date (i.e. org-export-with-date) is set to t but there is no
default for an absent :date.

This is probably another case of too many cooks (or variables in this
case: org-export-with-date, org-html-postamble-format, and the :date
entry in the plist have to cooperate in order to produce the desired
result), so the behavior is difficult to explain and it's not clear that
all the different combinations make sense - e.g. if org-export-with-date
is nil, but the format includes a %d, we probably should not have an
empty date field, whereas if org-export-with-date is t but there is no
date supplied, it should probably default to today.

Apologies for rushing to judgment.

Nick

Re: [O] Bug: New HTML exporter incorrect attributes

[T.F. Torrey]

Hello Nicolas,

Thanks for your prompt reply, though I think our discussion is a little
off-track here, as noted below.

Nicolas Goaziou  writes:

> tftor...@tftorrey.com (T.F. Torrey) writes:
>
>>> It would be ATTR_HTML: :class "XXX". I try to unify syntax for
>>> attributes with syntax for Babel and AFAICT, `html' is the last back-end
>>> to have key="value" syntax.

This was your response to my comment that it would be handy to apply
attributes to paragraphs, not the links or images within them.

>> I see that this does not presently work, and the author listed on
>> ox-html.el is not currently active on this list.  I hope you are not the
>> only one working on this.  It would be our great misfortune for you to
>> become burned out.
>
> It's not much work once we agree about the real syntax. For example, for
> links, there are two ways to replace:

I think you are now talking about a syntax for adding attributes to
links and images within paragraphs.  In the e-mail to which you are
replying, I thought were agreeing that modifying the inline link and
image syntax was the best solution to these, and had thoughts on what
that might look like in another thread.  What you describe here still
has the limitation that either all links and images in a paragraph must
have the same attributes, or some must be invalid, or only the first is
reachable.

Apart from that, I have other more general concerns with this approach
noted below.

>   #+ATTR_HTML: width="400px"
>
> The easiest one, is simply to ask for `:options' before:
>
>   #+ATTR_HTML: :options "width=\"400px\""
>
> This is heavier but will be consistent with other back-ends.

Yes, this is heavy.  Escaping the quotes is unwieldy, and raises doubts
about what else might need to be escaped.  Also, given that the whole
and only point of the ATTR_HTML keyword is for describing options,
adding ":options" is redundant.  From a design standpoint, it might be
elegant that it matches other things, but here it seems very awkward,
and I don't understand who it would benefit.

This seems another step away from "plain text" toward "another
programming language".  The first syntax looks like plain text.  The
second looks like programming.  For babel, and actual programming
languages, I'm sure this makes good sense.  For applying a width to an
image, it's overkill.

For instance, compare this "plain text":

#+ATTR_HTML: :options "width=\"400px\" title=\"My image\""
[[file:image.jpg]]

to the HTML alternative:



Shouldn't the plain text be more straightforward to enter and easier to
understand that what it is replacing?

Here is the same thing in AsciiDoc:

image:image.jpg["My image",width=400]

Granted, I've already noted that I think we are moving toward inline
attribute specifications, so this syntax for images and links is
probably moot anyway, but I think the larger point still stands.

I hate to say that I have other concerns as well, but I do, below.

> Otherwise, there is also:
>
>   #+ATTR_HTML: :width "400px"
>
> But this requires to have a list of all properties supported. If we take
> that route, here is a suggested list of such properties for  tag:
>
>   - rel
>   - target
>   - type
>   - accesskey
>   - class
>   - style
>   - title
>
> and for 
>
>   - alt
>   - height
>   - width
>
> What do you think about it?

I think it is rather heavy-handed.  I don't understand why this
"requires" a list of properties supported.  The old exporter would
simply plug whatever you told it into the tag, trusting that you knew
what you were doing.  I'm sure this simplified the code, and it gave
great power to the user.  Why should the user need "permission" from the
developers to apply any arbitrary attributes to their elements?

Imposing these restrictions on users seems to make more work for the
users, and more work for the developers, to the benefit of no one.

Also, I don't know why attributes should be defined for each backend
rather than once for everywhere.  The attributes would be designated for
an object, and each backend would decide which to use or ignore.

For instance, though I know the LaTeX syntax not correct, this seems
like massive overkill for making a link red:

#+ATTR_LATEX: :options "text-color: red"
#+ATTR_HTML: :options "class=\"red\""
Here is a [[file:doc.html]][red link]].

FWIW, the same thing in AsciiDoc would be this:

Here is a [red]#link:doc.html#[red link].

And it would work correctly for every backend, current or future.

In AsciiDoc, the attributes belong to the item, and every backend is
free to use or ignore them.  Plain text sure looks appealing.

Again, this is applying the old ATTR_ syntax instead of the suggested
inline attribute designations, but if the new link syntax matches the
spirit of the existing structure, something like this is in the works:

Here is a [[file:doc.html][red link][@@html: "class=\"red\""@@ @@latex:
"text-color: red"@@]].

IMHO, the AsciiDoc approach is much better.

>> The HTML exporter should produce valid H

Re: [O] pxref in texinfo export

[Jonathan Leech-Pepin]

(Here are the attached files, forgot to add them)

On 25 February 2013 15:24, Jonathan Leech-Pepin <
jonathan.leechpe...@gmail.com> wrote:

> Hello,
>
> On 25 February 2013 14:01, Subhan Tindall 
> wrote:
>
>> The point being that compiling .texinfo source into an Info file
>> treats references differently. For example:
>> (@pxref{my_node_name}).  will compile just fine.
>> (@ref{my_node_name}). will not.
>
>
> Both work perfectly fine for me.
> makeinfo (GNU texinfo) 5.0
>
>
>> There are also differences in case
>> (see v. See, note v. Note), and differences in output by ref type
>> depending on target output of file (info, DVI, HTML,...). For example,
>> @pxref generates different punctuation for typeset v. info files, @ref
>> does not generate a 'See ' in printed material while @xref does, etc.
>>
>> Although the differences are subtle, they really are not equivalent
>> and should not be treated as such.
>>
>
> With a slight amount of work on the user's part, they can be made
> functionally equivalent on export.
>
> Using the two attached minimal .texi files (good-ref.texi is using
> @xref/@pxref as is preferred while ref.texi is using @ref with
> appropriate See/see added in the text) and disregarding filename
> differences (since they are noted in the info output) I get the
> following differences:
>
> > makeinfo --html --no-split good-ref.texi ref.texi
> 0 Diffs
>
> > makeinfo --docbook --no-split good-ref.texi ref.texi
> Filename ID appears in diff
>
> > makeinfo --xml --no-split good-ref.texi ref.texi
> Filename difference.
>
> Links are different since TexinfoML does still distinguish xref/pxref
> and ref in how they create the links.
>
> > makeinfo --no-split good-ref.texi ref.texi
>
> The info file does show the expected differences between the two
> documents, notably that the "@xref{}" becomes "*Note" while the
> equivalent "See @ref{}" becomes "See *note" with @pxref{}->*note vs
> see @ref{} -> see *note.
>
> However once they are viewed within the *info* buffer (C-u C-h i
> good-ref.info/ref-only.info) the lines in question are visually
> identical since *Note becomes "See" and *note becomes "see" if there
> is not already "see" present.
>
> I will not disagree that @ref, @pxref and @xref are subtly different,
> however with slight user intervention @ref can be used in the same
> above locations by simply replacing:
>
> @xref{}  -> "See @ref{}"
> @pxref{} -> "see @ref{}"
>
> I had to compare these possible outcomes when working on the texinfo
> exporter.  Since links are parsed before being included in their
> paragraphs, I did not have a way to obtain context and therefore
> attempt to guess (and be successful) at which type of reference was
> intended by a link in Org.  Restricting it to @ref{} in all cases,
> even if it added a slight burden to the user (4 additional characters
> to type in Org) if they wanted to emulate @xref or @pxref was in my
> opinion the best choice.
>
> Regards,
>
> --
> Jon
>
> [...]
>
>


good-ref.texi
Description: TeXInfo document


ref.texi
Description: TeXInfo document

[O] [patch] ox-koma-letter

[Rasmus]

Hi,

I have been working on extending the KOMA letter support in Org.  The
backend is still rough and I would like to more stuff such as
designing firstfood and firsthead with org elements (e.g. I use a
tabularx for my firstfood with varioues stuff).

I have changed the following objects:

  1. Make keys sane; no reason why open pdf is O rather than o and why
 k is used in place of l (as in the tex exporter).
  2. Added AFTER_CLOSING and AFTER_LETTER keywords for arbitrary code
 after \closing{.} and \end{letter}, respectively.
 a. A weird bug I don't understand is why I cannot have
#+AFTER_CLOSING{\ps{ps:}}
 b. Would it be better to have a dedicated, say, PS and ENCL rather
than the generic AFTER_CLOSING?
  3. Added from-bank, invoice and other keywords like that.  Still
 many to go, but some of them would probably need some thought.
 For instance firstfoot should work differently depending on
 whether it is given a NAMEd table or a string.  Any though? 

I'm not a good programmer, so if someone could look through it, and
say whether it's OK it'd be happy to work more on in and submit it a
proper patch if deemed worthy.

Also, if someone has thoughts on how to improve the letter experience
that would be interesting to hear.  

I'd love to hear an explanation of point a. above.

Further, perhaps we should remove all the silly defaults from the
defcustoms in ox-koma-letter?  

–Rasmus

-- 
. . . Stallman was indeed the tallest possible mountain and by
standing on his shoulders you could see forever. . .diff --git a/contrib/lisp/ox-koma-letter.el b/contrib/lisp/ox-koma-letter.el
index 07633e3..069d458 100644
--- a/contrib/lisp/ox-koma-letter.el
+++ b/contrib/lisp/ox-koma-letter.el
@@ -91,6 +91,23 @@
   :group 'org-export-koma-letter
   :type 'string)
 
+(defcustom org-koma-letter-from-bank ""
+  "Sender's bank account, as a string."
+  :group 'org-export-koma-letter
+  :type 'string)
+
+(defcustom org-koma-letter-from-fax ""
+  "Sender's fax number, as a string."
+  :group 'org-export-koma-letter
+  :type 'string)
+
+(defcustom org-koma-letter-from-url ""
+  "Sender's url, as a string."
+  :group 'org-export-koma-letter
+  :type 'string)
+
+
+
 (defcustom org-koma-letter-opening "Dear Sir,"
   "Letter's opening, as a string."
   :group 'org-export-koma-letter
@@ -106,33 +123,42 @@
   :group 'org-export-koma-letter
   :type 'string)
 
-
+
 ;;; Define Back-End
 
 (org-export-define-derived-backend koma-letter latex
   :options-alist
-  ((:closing "CLOSING" nil org-koma-letter-closing)
+  ((:after-closing "AFTER_CLOSING" nil "" newline)
+   (:after-letter "AFTER_LETTER" nil "" newline)
+   (:closing "CLOSING" nil org-koma-letter-closing)
(:from-address "FROM_ADDRESS" nil org-koma-letter-from-address newline)
+   (:from-bank "FROM_BANK" nil org-koma-letter-from-bank t)
+   (:from-fax "FROM_FAX" nil org-koma-letter-from-fax t)
+   (:from-url "FROM_FAX" nil org-koma-letter-from-url t)
+   (:invoice "INVOICE" nil "" t)
+   (:my-ref "MY_REF" nil "" t)
+   (:your-ref "YOUR_REF" nil "" t)
(:lco "LCO" nil org-koma-letter-class-option-file)
(:opening "OPENING" nil org-koma-letter-opening)
(:phone-number "PHONE_NUMBER" nil org-koma-letter-phone-number)
-   (:signature "SIGNATURE" nil nil newline)
-   (:to-address "TO_ADDRESS" nil nil newline))
+   (:signature "SIGNATURE" nil user-full-name newline)
+   (:to-address "TO_ADDRESS" nil nil newline)
+   )
   :translate-alist ((export-block . org-koma-letter-export-block)
 (export-snippet . org-koma-letter-export-snippet)
 (keyword . org-koma-letter-keyword)
 (template . org-koma-letter-template))
   :menu-entry
   (?k "Export with KOMA Scrlttr2"
-  ((?K "As LaTeX buffer" org-koma-letter-export-as-latex)
-   (?k "As LaTeX file" org-koma-letter-export-to-latex)
+  ((?L "As LaTeX buffer" org-koma-letter-export-as-latex)
+   (?l "As LaTeX file" org-koma-letter-export-to-latex)
(?p "As PDF file" org-koma-letter-export-to-pdf)
-   (?O "As PDF file and open"
+   (?o "As PDF file and open"
(lambda (a s v b)
  (if a (org-koma-letter-export-to-pdf t s v b)
   (org-open-file (org-koma-letter-export-to-pdf nil s v b
 
-
+
 ;;; Transcode Functions
 
  Export Block
@@ -204,7 +230,15 @@ holding export options."
(format "\\setkomavar{signature}{%s}\n" (plist-get info :signature))
(format "\\setkomavar{fromemail}{%s}\n"
(org-export-data (plist-get info :email) info))
+   (format "\\setkomavar{frombank}{%s}\n"
+   (org-export-data (plist-get info :from-bank) info))
(format "\\setkomavar{fromphone}{%s}\n" (plist-get info :phone-number))
+   (format "\\setkomavar{frombank}{%s}\n" (plist-get info :from-bank))
+   (format "\\setkomavar{fromfax}{%s}\n" (plist-get info :from-fax))
+   (format "\\setkomavar{fromurl}{%s}\n" (plist-get info :from-url))
+   (format "\\setko

[O] [RFC] Org version of the Org manual

[Thomas S. Dye]

Aloha all,

An experiment to see if it is possible to convert the Org manual to Org
is now (hopefully) at the "proof of concept" stage and I would like to
determine whether or not the approach is viable. The experiment is here:

https://github.com/tsdye/orgmanual.git

The file orgmanual.org has a heading, * Instructions for use, that
explains how to set up asynchronous export with the new exporter. The
repo also contains orgmanual.info in case you don't want to hassle with
exporting the org file and just want to see what it looks like in info.
I'm able to generate an info file without makeinfo raising any errors or
warnings. 

There is also a heading, * Improvements and fixes, that includes a list
of problems that either need to be fixed or are in the process of being
fixed. Obviously, the file is not perfect, but I do believe it is good
enough to judge whether success will be possible. At any rate, I need to
pull myself away from this project for a week or so to do other things
and can't get caught up making editorial changes or working on the (to
me) thorny issues that remain.

Sections with problems have been given FIXME keywords. In some cases,
problem text (especially in macros) has been replaced with `XXX'.
Proposed fixes for these nagging issues will be greatly appreciated.

By way of background, my initial goal was to replicate the Org manual
precisely. This goal was abandoned when I realized that the various
contributors to the manual (including me a few years ago) had different
ideas about what a .texi file should look like and had created a somewhat
eclectic product.  The goal now is to have a "functional equivalent" of
the manual.

The ultimate goal is to maintain the Org manual in Org, rather than
.texi, and to have the infrastructure in place in time to support the
major revisions required by the forthcoming release of version 8.0.

Many thanks to Nicolas Goaziou and to Jonathan Leech-Pepin for their
excellent work on the new exporter framework and the texinfo exporter,
and for their patience with my sometimes exasperated (and exasperating)
queries.  Jonathan showed me the way forward at an early stage and
devised most of the macros.

I look forward to picking this project up again in a week or so, or
learning from my Org colleagues that the project ought to be scuttled.

All the best,
Tom

-- 
T.S. Dye & Colleagues, Archaeologists
735 Bishop St, Suite 315, Honolulu, HI 96813
Tel: 808-529-0866, Fax: 808-529-0884
http://www.tsdye.com

Re: [O] HTML export: no date in postamble unless set manually

[Nick Dokos]

Richard Stanton  wrote:

> I have  org-export-html-postamble set to t. When I export a simple org
> file that has no explicit #+date line (using the new exporter), I get a
> line that says "Date:" at the bottom of the resulting HTML file, but
> there's no date listed next to it. If I add an explicit #+date line, it is
> correctly transferred to the bottom of the HTML file, but wouldn't it make
> sense to have today's date listed if no explicit alternative is provided?
> At any rate, adding a line that says "Date:" with nothing after the colon
> doesn't seem like the optimal default setting.
> 

The backend-specific variables have been renamed in the new exporter: try
org-html-postamble. Check the FAQ:

http://orgmode.org/worg/org-faq.html#new-exporter-switch

for more details.

Nick

Re: [O] Sending reminder Emails to other people with org-mode

[Nick Dokos]

Thomas Koch  wrote:

> Hi,
> 
> A common workflow (of mine) is: Work on something, submit and wait several 
> days or weeks for a review or reply before I can continue. So I switch to the 
> next task.
> 
> I'd love if org-mode could keep track of tasks that are waiting for others 
> and 
> semi-automatically remind those others in a weekly email that I'm waiting for 
> them.
> 
> I imagine a command that I could run over my tasks. The command finds such 
> tasks, prepares a reminder mail that I can send directly from within emacs 
> and 
> remembers the date when I last naged the other.
> 
> Any ideas? Thanks for your attention,
> 

It depends on how you set up your tasks, but I imagine something like the 
following
will be fairly easy to set up:

o When you submit, the task goes into a WAITING state and several
  properties are added: (who to nag, when the last nag went out).

o You can then write a function that finds waiting tasks, and checks the
  relevant properties in order to construct the nagging email. The
  details will vary of course, but the mapping and property APIs should
  be able to deal with the org aspects. See

(info "(org) Using the mapping API")
(info "(org) Using the property API")

  The is-it-time-to-nag logic can be easily done in elisp. Sending email
  is also quite possible in elisp, but the details will depend on the
  mail package you decide to use.

o The function can be run using a timer. See

(info "(elisp) Timers for Delayed Execution")

There are lots of details elided in the above description of course, but
this is probably a reasonable first approximation.

Nick

[O] Sending reminder Emails to other people with org-mode

[Thomas Koch]

Hi,

A common workflow (of mine) is: Work on something, submit and wait several 
days or weeks for a review or reply before I can continue. So I switch to the 
next task.

I'd love if org-mode could keep track of tasks that are waiting for others and 
semi-automatically remind those others in a weekly email that I'm waiting for 
them.

I imagine a command that I could run over my tasks. The command finds such 
tasks, prepares a reminder mail that I can send directly from within emacs and 
remembers the date when I last naged the other.

Any ideas? Thanks for your attention,

Thomas Koch, http://www.koch.ro

Re: [O] org-sync and redmine

[Daimrod]

Hello Bastien,

Bastien  writes:
> hob...@poukram.net (Rémi Letot) writes:
>> So I get to ask if anyone that I'm not aware of is still currently
>> working on org-sync, and if yes if they are interrested in fixing the
>> redmine backend ?
>
> Daimrod is working on it and I think he is interested in the Redmine
> sync too.

Yes, I would like to get the redmine backend practical, but I need time
to understand org-sync and time to work on it, and I don't expect to
find the time before mid-april.

> Daimrod, let me know if you want write access to org-sync.git repo
> on orgmode.org, you could then merge your changes directly.

I'm still only playing with org-sync and I don't fully understand the
changes I've merged, so I won't push before I'm more confident with my
understanding of org-sync.

Unless Aurélien is against it, because he wants to discuss before
changes are made, you can give me the write access and I'll merge when I
could.

-- 
Daimrod/Greg


pgp45PrLKeLyB.pgp
Description: PGP signature

Re: [O] pxref in texinfo export

[Subhan Tindall]

The point being that compiling .texinfo source into an Info file
treats references differently. For example:
(@pxref{my_node_name}).  will compile just fine.
(@ref{my_node_name}). will not.  There are also differences in case
(see v. See, note v. Note), and differences in output by ref type
depending on target output of file (info, DVI, HTML,...). For example,
@pxref generates different punctuation for typeset v. info files, @ref
does not generate a 'See ' in printed material while @xref does, etc.

Although the differences are subtle, they really are not equivalent
and should not be treated as such.

On Mon, Feb 25, 2013 at 10:48 AM, Jonathan Leech-Pepin
 wrote:
> Hello,
>
> On 25 February 2013 13:40, Subhan Tindall 
> wrote:
>>
>> There are 4 different ref commands, all with slightly syntactic
>> requirements and outputs when compiled using makeinfo.  I for one use
>> @pxref{} a lot, and it has different requirements for placement than
>> @ref or @xref (namely those two MUST have a . or , following the end
>> of the ref)
>
>
> Not entirely true, @ref{} will add a period after the end of the reference
> in the info output
> if no period or comma present, @xref{} needs a comma or period.  @pxref{}
> can be
> followed by a period, comma or right parenthesis, otherwise the info output
> will include
> a period as well.
>
> So all three must have some sort of punctuation (or paren) following them to
> ensure that
> the references are clearly delimited.
>
> Regards,
>
>>
>> 8.1 Different Cross Reference Commands
>> There are four different cross reference commands:
>> @xref Used to start a sentence in the printed manual saying ‘See . . .
>> ’ or an Info
>>  cross-reference saying ‘*Note name : node.’.
>> @ref Used within or, more often, at the end of a sentence; same as
>> @xref for Info;
>> produces just the reference in the printed manual without a preceding
>> ‘See’.
>> @pxref Used within parentheses to make a reference that suits both an
>> Info file and a
>> printed book. Starts with a lower case ‘see’ within the
>> printed manual. (‘p’ is
>>for ‘parenthesis’.)
>> @inforef Used to make a reference to an Info file for which there is
>> no printed manual.
>>
>> (from the Texinfo manual)
>>
>> On Mon, Feb 25, 2013 at 10:32 AM, Jonathan Leech-Pepin
>>  wrote:
>> > Hello Tom,
>> >
>> > On 25 February 2013 12:52, Thomas S. Dye  wrote:
>> >>
>> >> Aloha all,
>> >>
>> >> IIUC, there is currently no support for @pxref{} in the texinfo
>> >> exporter.  This is a texinfo @-command that does one thing in the info
>> >> output and another in the LaTeX output.
>> >
>> >
>> > Ultimately there is actually no real difference between "see @ref{}"
>> > and "@pxref{}".  I just checked using the first @pxref{} in org.texi
>> > (Under Activation).
>> >
>> > In org.texi it is shown as (@pxref{Conflicts}), in org.html it
>> > becomes: (see Conflicts) while in the info
>> > file (org) it is shown as (*note Conflicts::).
>> >
>> > Opening the info file in Info (C-u C-h i ), *node
>> > Conflicts:: becomes "see Conflicts".  Adding "see" manually
>> > before *note does not change the output.  The same is the case for
>> > @xref{}.  @xref{} adds "See" before the link in html/LaTeX, and
>> > uses *Note in the info document; "See [[link]]" produces the same See in
>> > html/LaTeX, and creates "See *note" in the info file (which is
>> > inserted as "See " in Emacs Info.
>> >
>> > Yes the output is different if looking at the info file directly,
>> > however when viewing it withing Emacs the text is consistent.
>> >
>> > I didn't implement support for @xref{} or @pxref{} in the texinfo
>> > exporter, because I could not find a way to reliably determine the
>> > context so as to use the right type of link in the texi file.
>> >
>> > Using occur there were already 47 cases in org.texi where "[Ss]ee
>> > @ref" was used rather than the stylistically appropriate @pxref/@xref.
>> >
>> > Regards,
>> >
>> > Jon
>> >
>> >>
>> >> My idea is to create a custom link type, something like this:
>> >>
>> >> (org-add-link-type
>> >>"pxref" nil
>> >>(lambda (path desc format)
>> >>  (cond
>> >>   ((eq format 'html)
>> >>(format "%s" path))
>> >>   ((eq format 'latex)
>> >>(format "\\ref{%s}" path))
>> >>   ((eq format 'texinfo)
>> >>(format "@pxref{%s,%s}" path desc)
>> >>
>> >> I haven't tested this, but it should export approximately correctly and
>> >> I'm confident I can get the export part working.
>> >>
>> >> What I can't figure out is how to have Org recognize that a link like
>> >> this:
>> >>
>> >> [[pxref:Internal link]]
>> >>
>> >> is really an internal link, rather than an external link.  I'd like to
>> >> be able to click on this and end up at <> in the Org
>> >> buffer.
>> >>
>> >> Is this possible?  If so, can you point me to a solution?
>> >>
>> >>
>> >> All the best,
>> >> Tom
>> >>
>> >> --
>> >> T.S. Dye & Colleagues, Archaeologists
>> >> 735 Bishop 

Re: [O] M-S-(down-arrow) worked briefly this morning and now does not

[Susan Cragin]

Works. 
My mistake. 
Thanks for help. 
Susan

Re: [O] pxref in texinfo export

[Jonathan Leech-Pepin]

Hello,

On 25 February 2013 13:40, Subhan Tindall wrote:

> There are 4 different ref commands, all with slightly syntactic
> requirements and outputs when compiled using makeinfo.  I for one use
> @pxref{} a lot, and it has different requirements for placement than
> @ref or @xref (namely those two MUST have a . or , following the end
> of the ref)
>

Not entirely true, @ref{} will add a period after the end of the reference
in the info output
if no period or comma present, @xref{} needs a comma or period.  @pxref{}
can be
followed by a period, comma or right parenthesis, otherwise the info output
will include
a period as well.

So all three must have some sort of punctuation (or paren) following them
to ensure that
the references are clearly delimited.

Regards,


> 8.1 Different Cross Reference Commands
> There are four different cross reference commands:
> @xref Used to start a sentence in the printed manual saying ‘See . . .
> ’ or an Info
>  cross-reference saying ‘*Note name : node.’.
> @ref Used within or, more often, at the end of a sentence; same as
> @xref for Info;
> produces just the reference in the printed manual without a preceding
> ‘See’.
> @pxref Used within parentheses to make a reference that suits both an
> Info file and a
> printed book. Starts with a lower case ‘see’ within the
> printed manual. (‘p’ is
>for ‘parenthesis’.)
> @inforef Used to make a reference to an Info file for which there is
> no printed manual.
>
> (from the Texinfo manual)
>
> On Mon, Feb 25, 2013 at 10:32 AM, Jonathan Leech-Pepin
>  wrote:
> > Hello Tom,
> >
> > On 25 February 2013 12:52, Thomas S. Dye  wrote:
> >>
> >> Aloha all,
> >>
> >> IIUC, there is currently no support for @pxref{} in the texinfo
> >> exporter.  This is a texinfo @-command that does one thing in the info
> >> output and another in the LaTeX output.
> >
> >
> > Ultimately there is actually no real difference between "see @ref{}"
> > and "@pxref{}".  I just checked using the first @pxref{} in org.texi
> > (Under Activation).
> >
> > In org.texi it is shown as (@pxref{Conflicts}), in org.html it
> > becomes: (see Conflicts) while in the info
> > file (org) it is shown as (*note Conflicts::).
> >
> > Opening the info file in Info (C-u C-h i ), *node
> > Conflicts:: becomes "see Conflicts".  Adding "see" manually
> > before *note does not change the output.  The same is the case for
> > @xref{}.  @xref{} adds "See" before the link in html/LaTeX, and
> > uses *Note in the info document; "See [[link]]" produces the same See in
> > html/LaTeX, and creates "See *note" in the info file (which is
> > inserted as "See " in Emacs Info.
> >
> > Yes the output is different if looking at the info file directly,
> > however when viewing it withing Emacs the text is consistent.
> >
> > I didn't implement support for @xref{} or @pxref{} in the texinfo
> > exporter, because I could not find a way to reliably determine the
> > context so as to use the right type of link in the texi file.
> >
> > Using occur there were already 47 cases in org.texi where "[Ss]ee
> > @ref" was used rather than the stylistically appropriate @pxref/@xref.
> >
> > Regards,
> >
> > Jon
> >
> >>
> >> My idea is to create a custom link type, something like this:
> >>
> >> (org-add-link-type
> >>"pxref" nil
> >>(lambda (path desc format)
> >>  (cond
> >>   ((eq format 'html)
> >>(format "%s" path))
> >>   ((eq format 'latex)
> >>(format "\\ref{%s}" path))
> >>   ((eq format 'texinfo)
> >>(format "@pxref{%s,%s}" path desc)
> >>
> >> I haven't tested this, but it should export approximately correctly and
> >> I'm confident I can get the export part working.
> >>
> >> What I can't figure out is how to have Org recognize that a link like
> >> this:
> >>
> >> [[pxref:Internal link]]
> >>
> >> is really an internal link, rather than an external link.  I'd like to
> >> be able to click on this and end up at <> in the Org
> >> buffer.
> >>
> >> Is this possible?  If so, can you point me to a solution?
> >>
> >>
> >> All the best,
> >> Tom
> >>
> >> --
> >> T.S. Dye & Colleagues, Archaeologists
> >> 735 Bishop St, Suite 315, Honolulu, HI 96813
> >> Tel: 808-529-0866, Fax: 808-529-0884
> >> http://www.tsdye.com
> >>
> >
>
>
>
> --
> Subhan Michael Tindall | Software Developer
> | s...@rentrakmail.com
> RENTRAK | www.rentrak.com | NASDAQ: RENT
>

Re: [O] pxref in texinfo export

[Subhan Tindall]

There are 4 different ref commands, all with slightly syntactic
requirements and outputs when compiled using makeinfo.  I for one use
@pxref{} a lot, and it has different requirements for placement than
@ref or @xref (namely those two MUST have a . or , following the end
of the ref)
8.1 Different Cross Reference Commands
There are four different cross reference commands:
@xref Used to start a sentence in the printed manual saying ‘See . . .
’ or an Info
 cross-reference saying ‘*Note name : node.’.
@ref Used within or, more often, at the end of a sentence; same as
@xref for Info;
produces just the reference in the printed manual without a preceding ‘See’.
@pxref Used within parentheses to make a reference that suits both an
Info file and a
printed book. Starts with a lower case ‘see’ within the
printed manual. (‘p’ is
   for ‘parenthesis’.)
@inforef Used to make a reference to an Info file for which there is
no printed manual.

(from the Texinfo manual)

On Mon, Feb 25, 2013 at 10:32 AM, Jonathan Leech-Pepin
 wrote:
> Hello Tom,
>
> On 25 February 2013 12:52, Thomas S. Dye  wrote:
>>
>> Aloha all,
>>
>> IIUC, there is currently no support for @pxref{} in the texinfo
>> exporter.  This is a texinfo @-command that does one thing in the info
>> output and another in the LaTeX output.
>
>
> Ultimately there is actually no real difference between "see @ref{}"
> and "@pxref{}".  I just checked using the first @pxref{} in org.texi
> (Under Activation).
>
> In org.texi it is shown as (@pxref{Conflicts}), in org.html it
> becomes: (see Conflicts) while in the info
> file (org) it is shown as (*note Conflicts::).
>
> Opening the info file in Info (C-u C-h i ), *node
> Conflicts:: becomes "see Conflicts".  Adding "see" manually
> before *note does not change the output.  The same is the case for
> @xref{}.  @xref{} adds "See" before the link in html/LaTeX, and
> uses *Note in the info document; "See [[link]]" produces the same See in
> html/LaTeX, and creates "See *note" in the info file (which is
> inserted as "See " in Emacs Info.
>
> Yes the output is different if looking at the info file directly,
> however when viewing it withing Emacs the text is consistent.
>
> I didn't implement support for @xref{} or @pxref{} in the texinfo
> exporter, because I could not find a way to reliably determine the
> context so as to use the right type of link in the texi file.
>
> Using occur there were already 47 cases in org.texi where "[Ss]ee
> @ref" was used rather than the stylistically appropriate @pxref/@xref.
>
> Regards,
>
> Jon
>
>>
>> My idea is to create a custom link type, something like this:
>>
>> (org-add-link-type
>>"pxref" nil
>>(lambda (path desc format)
>>  (cond
>>   ((eq format 'html)
>>(format "%s" path))
>>   ((eq format 'latex)
>>(format "\\ref{%s}" path))
>>   ((eq format 'texinfo)
>>(format "@pxref{%s,%s}" path desc)
>>
>> I haven't tested this, but it should export approximately correctly and
>> I'm confident I can get the export part working.
>>
>> What I can't figure out is how to have Org recognize that a link like
>> this:
>>
>> [[pxref:Internal link]]
>>
>> is really an internal link, rather than an external link.  I'd like to
>> be able to click on this and end up at <> in the Org
>> buffer.
>>
>> Is this possible?  If so, can you point me to a solution?
>>
>>
>> All the best,
>> Tom
>>
>> --
>> T.S. Dye & Colleagues, Archaeologists
>> 735 Bishop St, Suite 315, Honolulu, HI 96813
>> Tel: 808-529-0866, Fax: 808-529-0884
>> http://www.tsdye.com
>>
>



-- 
Subhan Michael Tindall | Software Developer
| s...@rentrakmail.com
RENTRAK | www.rentrak.com | NASDAQ: RENT

Re: [O] pxref in texinfo export

[Jonathan Leech-Pepin]

Hello Tom,

On 25 February 2013 12:52, Thomas S. Dye  wrote:

> Aloha all,
>
> IIUC, there is currently no support for @pxref{} in the texinfo
> exporter.  This is a texinfo @-command that does one thing in the info
> output and another in the LaTeX output.
>

Ultimately there is actually no real difference between "see @ref{}"
and "@pxref{}".  I just checked using the first @pxref{} in org.texi
(Under Activation).

In org.texi it is shown as (@pxref{Conflicts}), in org.html it
becomes: (see Conflicts) while in the info
file (org) it is shown as (*note Conflicts::).

Opening the info file in Info (C-u C-h i ), *node
Conflicts:: becomes "see Conflicts".  Adding "see" manually
before *note does not change the output.  The same is the case for
@xref{}.  @xref{} adds "See" before the link in html/LaTeX, and
uses *Note in the info document; "See [[link]]" produces the same See in
html/LaTeX, and creates "See *note" in the info file (which is
inserted as "See " in Emacs Info.

Yes the output is different if looking at the info file directly,
however when viewing it withing Emacs the text is consistent.

I didn't implement support for @xref{} or @pxref{} in the texinfo
exporter, because I could not find a way to reliably determine the
context so as to use the right type of link in the texi file.

Using occur there were already 47 cases in org.texi where "[Ss]ee
@ref" was used rather than the stylistically appropriate @pxref/@xref.

Regards,

Jon


> My idea is to create a custom link type, something like this:
>
> (org-add-link-type
>"pxref" nil
>(lambda (path desc format)
>  (cond
>   ((eq format 'html)
>(format "%s" path))
>   ((eq format 'latex)
>(format "\\ref{%s}" path))
>   ((eq format 'texinfo)
>(format "@pxref{%s,%s}" path desc)
>
> I haven't tested this, but it should export approximately correctly and
> I'm confident I can get the export part working.
>
> What I can't figure out is how to have Org recognize that a link like
> this:
>
> [[pxref:Internal link]]
>
> is really an internal link, rather than an external link.  I'd like to
> be able to click on this and end up at <> in the Org
> buffer.
>
> Is this possible?  If so, can you point me to a solution?
>

All the best,
> Tom
>
> --
> T.S. Dye & Colleagues, Archaeologists
> 735 Bishop St, Suite 315, Honolulu, HI 96813
> Tel: 808-529-0866, Fax: 808-529-0884
> http://www.tsdye.com
>
>

Re: [O] [texinfo] Bug(?) in detailed node listing

[Thomas S. Dye]

Hi Jon,

Jonathan Leech-Pepin  writes:

> Hello Tom,
>
>> One nit: You have one space between the `::' at the end of a long title
>> and the start of the description, where the Org manual has two spaces.
>>
>>
> This should now be fixed (along with a logic error that was actually
> inserting
> description at column+5)
>

I hadn't detected the logic error, but can confirm that the other fix
works.

Thanks!

All the best,
Tom

-- 
Thomas S. Dye
http://www.tsdye.com

Re: [O] M-S-(down-arrow) worked briefly this morning and now does not

[Nick Dokos]

Susan Cragin  wrote:

> Hi. 
> I updated my emacs git, got the new org-mode, and tried M-S-UpArrow. 
> And it worked. I was elated. 
> And then I closed the program and re-opened it, and now it no longer works. 
> The message is:
> This command is active in special context like tables, headlines or items

Not sure what version you are using, but in the version I'm using which is from
yesterday or the day before:

Org-mode version 7.9.3f (release_7.9.3f-1199-g3a0e55 @ 
/home/nick/elisp/org-mode/lisp/)

that message is only triggered if S-M-left or S-M-right is invoked on
the non-special context (i.e. just an ordinary line).

OTOH, S-M-up and S-M-down end up calling org-drag-line-backward and
org-drag-line-forward respectively. So either you are pressing the wrong
arrow key or a bug has been introduced in the last day or so.

Nick

[O] HTML export: no date in postamble unless set manually

[Richard Stanton]

I have  org-export-html-postamble set to t. When I export a simple org
file that has no explicit #+date line (using the new exporter), I get a
line that says "Date:" at the bottom of the resulting HTML file, but
there's no date listed next to it. If I add an explicit #+date line, it is
correctly transferred to the bottom of the HTML file, but wouldn't it make
sense to have today's date listed if no explicit alternative is provided?
At any rate, adding a line that says "Date:" with nothing after the colon
doesn't seem like the optimal default setting.

Thanks.

Richard Stanton

Re: [O] Possible to both clock into :CLOCK: and put notes in :LOGBOOK: ?

[Achim Gratz]

Steinar Bang writes:
> But if I have this setting then notes created with `C-c C-z' end up on
> the top level, even if I manually create a :LOGBOOK: drawer.
>
> Is it possible to have both?

Unless it's been broken recently it should, but you probably need to
customize org-log-into-drawer to "t" (for LOGBOOK) or set the property
LOG_INTO_DRAWER if you want to keep this setting different in different
subtrees.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

SD adaptation for Waldorf Blofeld V1.15B11:
http://Synth.Stromeko.net/Downloads.html#WaldorfSDada

[O] New HTML exporter: Oddities with figure placement

[Richard Stanton]

It seems that figure placement has changed in HTML files generated by the
new (compared with the old) exporter.

For example, here's a simple org file:

-

This is an org file

[[file:figure.png]]

* Abstract
This is an abstract

-

When I export, all looks fine, except that the figure is centered (left to
right) rather than being left-justified, which I could have sworn it used
to be. Since I prefer left justification by default, I tried adding the
line

#+ATTR_HTML: align="left"

immediately before the figure link. Now when I export to HTML, the figure
is left justified as I want, but the following text appears to the right
of the figure, not below it, which isn't what I want. It seems odd that
this would happen even when I have a blank line separating the figure link
from the following text. Am I missing something?

Thanks.

Richard Stanton

[O] pxref in texinfo export

[Thomas S. Dye]

Aloha all,

IIUC, there is currently no support for @pxref{} in the texinfo
exporter.  This is a texinfo @-command that does one thing in the info
output and another in the LaTeX output.  

My idea is to create a custom link type, something like this:

(org-add-link-type
   "pxref" nil
   (lambda (path desc format)
 (cond
  ((eq format 'html)
   (format "%s" path))
  ((eq format 'latex)
   (format "\\ref{%s}" path))
  ((eq format 'texinfo)
   (format "@pxref{%s,%s}" path desc)

I haven't tested this, but it should export approximately correctly and
I'm confident I can get the export part working.

What I can't figure out is how to have Org recognize that a link like
this:

[[pxref:Internal link]]

is really an internal link, rather than an external link.  I'd like to
be able to click on this and end up at <> in the Org
buffer. 

Is this possible?  If so, can you point me to a solution?

All the best,
Tom

-- 
T.S. Dye & Colleagues, Archaeologists
735 Bishop St, Suite 315, Honolulu, HI 96813
Tel: 808-529-0866, Fax: 808-529-0884
http://www.tsdye.com

[O] M-S-(down-arrow) worked briefly this morning and now does not

[Susan Cragin]

Hi. 
I updated my emacs git, got the new org-mode, and tried M-S-UpArrow. 
And it worked. I was elated. 
And then I closed the program and re-opened it, and now it no longer works. 
The message is:
This command is active in special context like tables, headlines or items
--Susan

Re: [O] Correct / best way of loading packages in contrib when using org compiled from git?

[Achim Gratz]

Rainer M Krug writes:
> Well - I could and I guess nothing would change. Why I like my setup at the 
> moment is, that I have
> all emacs config, installation and elpa in my .emacs.d directory. Would this 
> be the same after
> using "make up2"? Would I have to change paths somewhere?

You can install Org wherever you like if you let your Emacs
configuration find it.  You need to put suitable definitions for lispdir
datadir and infodir into local.mk, the easiest way is probably to just
point prefix at your emacs.d (you must use the absolute path, not the
tilde abbreviation ~/...).  Check the result of these changes with "make
config" before you first install.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

SD adaptation for Waldorf rackAttack V1.04R1:
http://Synth.Stromeko.net/Downloads.html#WaldorfSDada

Re: [O] Warning with latest git pull

[Achim Gratz]

Bastien writes:
> I fixed the comment, thanks.

I'm starting to sound like Drew, but the new comment says exactly what
the old one did, just the two parts juxtaposed.

The point of having the new macro is to avoid the question about
reverting the file when the file visited by a buffer has been edited
outside Emacs.  You can do exactly the same changes (cosmetic or not)
with both macros, but org-unmodified will ask you when the file and the
buffer have diverged due to the file changing outside Emacs.  You
shouldn't do this of course unless you know with certainty that you are
never going to save the file.  There's another difference between these
two: org-unmodified does not let you change read-only buffers (I don't
know if that's intentional or not).  With all this said, the
compatibility part of org-with-silent-modifications can't simply be
plugging in org-unmodified (this loses functionality that presumably was
needed).  The change to make from the implementation I gave would be
losing the let-bindings for buffer-file-name buffer-file-truename and
perhaps inhibit-read-only.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

SD adaptation for Waldorf microQ V2.22R2:
http://Synth.Stromeko.net/Downloads.html#WaldorfSDada

Re: [O] [texinfo] Bug(?) in detailed node listing

[Jonathan Leech-Pepin]

Hello Tom,

On 25 February 2013 11:57, Thomas S. Dye  wrote:

> Hi Jon,
>
> Jonathan Leech-Pepin  writes:
>
> > Hi Tom,
> >
> > On 21 February 2013 18:44, Thomas S. Dye  wrote:
> >
> >> Hi Jon,
> >> [...]
> >>
> >> Based on this example from the Org manual, it looks as if the
> >> descriptions should start on column 32 or the third column after the end
> >> of the title, whichever is greater.
> >>
> >>
> > I've just pushed a fix for this.  It also introduces a new defcustom
> > to allow for choosing the column you want it to align at
> > (org-texinfo-node-description-column).
> >
>
> Nice.  Thanks!
>
> One nit: You have one space between the `::' at the end of a long title
> and the start of the description, where the Org manual has two spaces.
>
>
This should now be fixed (along with a logic error that was actually
inserting
description at column+5)

Regards,

Jon

> All the best,
> Tom
>
> --
> Thomas S. Dye
> http://www.tsdye.com
>

Re: [O] org-drill - properties displayed during card review

[Paul Rudin]

Paul Sexton  writes:

> I just never got around to fixing that minor glitch until now. I have
> committed a fix to the org-drill repository at
>
> http://bitbucket.org/eeeickythump/org-drill
>
> So if you download and use the org-drill.el from there, the problem
> will be fixed.

Thanks very much - that seems to have done the trick.

Re: [O] [org-e-texinfo] generate menu items

[Thomas S. Dye]

Hi Jon,

Jonathan Leech-Pepin  writes:

> Hello,
>
> On 23 February 2013 18:04, Nicolas Goaziou  wrote:
>
>> Hello,
>>
>> [...]
>>
>> I eventually added :OPTIONAL_TITLE: property. Get its parsed value with
>> `org-export-get-optional-title' function.
>>
>> I patched ox-ascii, ox-latex and ox-html so they use it when building
>> a TOC. I think only ox-odt and ox-texinfo are missing.
>>
>> Jonathan, could you have a look at it?
>>
>
> I've replaced the use of :TEXINFO_MENU_TITLE: with :OPTIONAL_TITLE:.
>
> Tom,
>
> This will cause the menu titles to no longer export properly until you
> change the property names.

I can confirm that this works.

Thanks!

All the best,
Tom
-- 
Thomas S. Dye
http://www.tsdye.com

Re: [O] [texinfo] Appendix?

[Thomas S. Dye]

Hi Jon,

Jonathan Leech-Pepin  writes:

> Hello Tom,
>
> I've now fixed this.
>
> Headlines with an :INDEX: property will now export as:
>
> #+BEGIN_EXAMPLE
> @unnumbered  (or equivalent unnumbered subheading)
>
> 
>
> @printindex  (assuming INDEX is a recognized type, otherwise it
> will simply be an unnumbered headline.

Yes, this works nicely.

>
> I've additionally added support for appendices.  These will export as
> @appendix .
>

An :APPENDIX: property triggers this one, which works as advertised.

Thanks!

All the best,
Tom

-- 
Thomas S. Dye
http://www.tsdye.com

Re: [O] [texinfo] Bug(?) in detailed node listing

[Thomas S. Dye]

Hi Jon,

Jonathan Leech-Pepin  writes:

> Hi Tom,
>
> On 21 February 2013 18:44, Thomas S. Dye  wrote:
>
>> Hi Jon,
>> [...]
>>
>> Based on this example from the Org manual, it looks as if the
>> descriptions should start on column 32 or the third column after the end
>> of the title, whichever is greater.
>>
>>
> I've just pushed a fix for this.  It also introduces a new defcustom
> to allow for choosing the column you want it to align at
> (org-texinfo-node-description-column).
>

Nice.  Thanks!

One nit: You have one space between the `::' at the end of a long title
and the start of the description, where the Org manual has two spaces.

All the best,
Tom

-- 
Thomas S. Dye
http://www.tsdye.com

Re: [O] {New exporter] What happened to the export template

[Nicolas Goaziou]

Hello,

"Sebastien Vauban"
 writes:

> Hello Bastien,
>
> Bastien wrote:
>> Nicolas Goaziou  writes:
>>
>>> It has been removed. Such a template depends on the back-end used, which
>>> was not the case of the previous implementation.
>>
>> One idea would be to have an equivalent of the now-defunct
>> `org-insert-export-options-template' but for each backend.
>>
>> For example `C-c C-e h t' would insert the default template
>> for the HTML export.
>>
>> Is anyone interested in this?
>
> My personal answer is: yes!
>
> I constantly used it for inserting a title (defaulting to the name of the
> file, which is the best default), timestamp, etc.

You can also type #+ti M-TAB M-TAB to get the same result. It works for
most default keywords.


Regards,

-- 
Nicolas Goaziou

Re: [O] org-drill - properties displayed during card review

[Bastien]

Hi Paul,

Paul Sexton  writes:

> So if you download and use the org-drill.el from there, the problem
> will be fixed.

Thanks for maintaining org-drill.el!  I updated the version in the
contrib/ repository to org-drill.el 2.3.7.

Best,

-- 
 Bastien

Re: [O] tabulated-list

[François Pinard]

Nicolas Goaziou  writes:

> this change because I was reinventing the wheel in
> `org-export-stack'. I hadn't realized [tabulated-list.el] was emacs24
> only.  Bastien, is there another solution besides reverting the
> commit?

Could tabulated-list.el be conveyed within Org as org-tabulated-list.el
and loaded only if tabulated-list is not already available?

François

Re: [O] [texinfo] Appendix?

[Jonathan Leech-Pepin]

Hello Tom,

On 22 February 2013 18:28, Jonathan Leech-Pepin <
jonathan.leechpe...@gmail.com> wrote:

Hello Tom

On 22 February 2013 17:55, Thomas S. Dye  wrote:

Aloha Jon,

[...]
I don't understand.  This:

* Concept index
:PROPERTIES:
:TEXINFO_MENU_TITLE: Concept Index
:INDEX:cp
:END:

Gives me a numbered headline and an empty section.

If I add this:


@@info:@printindex cp@@

then an index is generated.  The headline is still numbered.

Am I doing something wrong?

I don't think so.  From the looks of things, index wasn't fixed along
with other properties to be uppercase in ox-texinfo.el.
I should be able to fix it on Monday (and make sure it now works),
along with the spacing of the detailed node listing.
Regards,
Jon


I've now fixed this.

Headlines with an :INDEX: property will now export as:

#+BEGIN_EXAMPLE
@unnumbered  (or equivalent unnumbered subheading)



@printindex  (assuming INDEX is a recognized type, otherwise it
will simply be an unnumbered headline.

I've additionally added support for appendices.  These will export as
@appendix .

Indexes and appendices are mutually exclusive, indexes are tested for
first.

Regards,

Jon

Re: [O] [org-e-texinfo] generate menu items

[Nicolas Goaziou]

Hello,

Jonathan Leech-Pepin  writes:

> I've replaced the use of :TEXINFO_MENU_TITLE: with :OPTIONAL_TITLE:.

Thank you for looking into it.

Though, please use `org-export-get-optional-title' function instead.
OPTIONAL_TITLE property only contains the raw string. The function will
return the parsed string.

Note: the function may be renamed soon, but I'll take care of that when
it happens.


Regards,

-- 
Nicolas Goaziou

Re: [O] how can I insert a new heading after all at this level?

[Jonathan Leech-Pepin]

Hello David,

On 19 February 2013 14:53, David Naumann  wrote:

> I'm a happy, frequent user of org mode but there's something I can't
> figure out from the manual.
>
> What I would like to be able to do is insert a new heading at the same
> level as current, _following_ all the others.  For example, with the
> cursor on the A in this tree:
>
> * top
> ->  ** A
> ** B
> ** C
> * next
>
> I would like to insert a last sibling and move to it:
>
> * top
> ** A
> ** B
> ** C
> ->  **
> * next
>
> Use case: adding to a very long chronological list.  I have not seen a
> quick way to do this using the structure motion/editing commands in
> the manual, without scrolling in one way or another.
>
> If you have a hint, please reply to my address; I'm not on this
> mailing list.
>

The following is a little long, however only one function is actually
interactive.

#+begin_src emacs-lisp
  (require 'org-element)

  (defun zin/org-next-element ()
"Move to the end of the current element (start of next)."
(let ((end (org-element-property :end (org-element-at-point
  (goto-char end)))

  (defun zin/org-element-check-element (type &optional name)
"Check if current element is of type TYPE.
  If not move to next element using `zin/org-next-element'.

  If NAME is non-nil, verify that the :name or :drawer-name
  property matches it."
(save-excursion
  (save-restriction
(save-excursion
  (org-up-element)
  (org-narrow-to-element))
   (catch 'element
 (while (not (eobp))
   (let ((cur-type (car (org-element-at-point)))
 ;; Allows for adaptation to non-headline cases.
 (cur-name (or (org-element-property
:name (org-element-at-point))
   (org-element-property
:drawer-name (org-element-at-point)
 (if (and (string= type cur-type)
  (string= name cur-name))
 (throw 'element (point))
   (zin/org-next-element

  (defun zin/org-element-start-or-end (start &optional level)
"Find start or ending point of an element's content.

  If START is non-nil, return the beginning of the content, if nil
  return the end.

  If LEVEL is equal to 1, parse the buffer for level 1 headlines.
  Any other value is ignored."
;; If level is 1, looking at top level headlines, there is no
;; containing element.
(if (and level
 (= 1 level))
(let* ((map   (org-element-map (org-element-parse-buffer) 'headline
(lambda (hl)
  ;; return a list of beginning and ending
  ;; points of all level 1 headlines.
  (list
   (org-element-property :begin hl)
   (org-element-property :end hl))) 'nil 'nil
'headline))
   ;; Find smallest (when start is 't) or largest (when
   ;; start is 'nil) point.
   (point (if start
  (apply 'min (mapcar 'car map))
(apply 'max (mapcar 'cadr map)
  point)
  ;; Not in a top level headline, deal with contents directly.
  (let ((top(org-element-property :contents-begin
(org-element-at-point)))
(bottom (org-element-property :contents-end
(org-element-at-point
(if start
top
  bottom

  (defun zin/org-add-heading (start &optional title)
"Create a new heading at the before or after all headings of current
level.

  If START is non-nil, the new heading will be the first in the
  list.  If nil it will be created after all the others.

  With optional TITLE, automatically insert the desired title,
  leaving the point on the following line."
(interactive "P")
(org-back-to-heading)
(let* ((level (org-element-property :level (org-element-at-point)))
   (point (save-excursion
(ignore-errors (org-up-element))
(zin/org-element-start-or-end start level)))
   ;; Org-element minimal version of a headline at LEVEL with
   ;; TITLE (or blank)
   (headline `(headline (:level ,level :title ,(or title "")
  (if start
  ;; If placing headline above existing headlines, ensure you do
  ;; not place it above the content of the parent headline.
  (progn
;; Search from top of content of parent headline.  Without
;; this it will put it above the current headline.
(goto-char point)
;; Do not check to make sure content is skipped if in a
;; level 1 headline, just return the start of the top
;; headline.
(unless
(= 1 level)
  (goto-char (zin/org-element-check-element "headline"
(goto-char point))
  (org-sa

Re: [O] [bug] orgstruct has suddenly become overly opinionated about legal keystrokes

[Christopher Schmidt]

"Sebastien Vauban"  
writes:
>> [...] is new behavior as of the last couple of weeks.
>
> ... and I also experience a quite recent change.
>
> Before, when composing an email, I could edit lists and convert them
> from itemized to enumerated ones, such in:
>
>   - blond   ->   1. blond
>   - brown   ->   2. brown
>
> ... by S-right'ing on it:

This should be fixed in master.

de5ff23 org.el: Bind org-shift* in orgstruct-mode.

Christopher

Re: [O] [org-e-texinfo] generate menu items

[Jonathan Leech-Pepin]

Hello

On 25 February 2013 11:09, Nicolas Goaziou  wrote:

> Hello,
>
> Jonathan Leech-Pepin  writes:
>
> > I've replaced the use of :TEXINFO_MENU_TITLE: with :OPTIONAL_TITLE:.
>
> Thank you for looking into it.
>
> Though, please use `org-export-get-optional-title' function instead.
> OPTIONAL_TITLE property only contains the raw string. The function will
> return the parsed string.
>
> I actually did use (org-export-get-optional-title), I just wrote the wrong
information
in the changelog.  Sorry

Regards,

Jon


> Note: the function may be renamed soon, but I'll take care of that when
> it happens.
>
>
> Regards,
>
> --
> Nicolas Goaziou
>

Re: [O] Adventures with org-footnote-auto-adjust

[Nicolas Goaziou]

t...@tsdye.com (Thomas S. Dye) writes:

> In my case, the intended effects of `org-footnote-auto-adjust' were
> purely cosmetic in the Org buffer and didn't affect the output.  Is
> there a situation where it does something that has an effect on
> output?

No, there is none.

> OK. Apologies for the graphic term. I hope it didn't offend. Dismay got
> the better of tact, I think.

No offence taken. I couldn't come with a better name either.


Regards,

-- 
Nicolas Goaziou

Re: [O] [bug] orgstruct has suddenly become overly opinionated about legal keystrokes

[Sebastien Vauban]

Hello,

Eric Schulte wrote:
> I use orgstruct mode in my message mode, so that I may easily include
> tables and lists when writing and responding to mail.

So do I...

> [...] is new behavior as of the last couple of weeks.

... and I also experience a quite recent change.

Before, when composing an email, I could edit lists and convert them from
itemized to enumerated ones, such in:

  - blond   ->   1. blond
  - brown   ->   2. brown

... by S-right'ing on it:

  ╭
  │  runs the command org-shiftright, which is an interactive Lisp
  │ function in `org.el'.
  │ 
  │ It is bound to , 
, <1 Day 
Later>.
  │ 
  │ (org-shiftright &optional ARG)
  │ 
  │ Cycle the thing at point or in the current line, depending on context.
  │ Depending on context, this does one of the following:
  │ 
  │ - switch a timestamp at point one day into the future
  │ - on a headline, switch to the next TODO keyword.
  │ - on an item, switch entire list to the next bullet type
  │ - on a property line, switch to the next allowed value
  │ - on a clocktable definition line, move time block into the future
  ╰

Now, in emails (not in regular Org files), that does not work anymore:

  ╭
  │  (translated from ) runs the command right-char, which is an
  │ interactive compiled Lisp function in `bindings.el'.
  │ 
  │ It is bound to .
  │ 
  │ (right-char &optional N)
  │ 
  │ Move point N characters to the right (to the left if N is negative).
  │ On reaching beginning or end of buffer, stop and signal error.
  │ 
  │ Depending on the bidirectional context, this may move either forward
  │ or backward in the buffer.  This is in contrast with C-f
  │ and C-b, which see.
  ╰

Best regards,
  Seb

-- 
Sebastien Vauban

Re: [O] [org-e-texinfo] generate menu items

[Jonathan Leech-Pepin]

Hello,

On 23 February 2013 18:04, Nicolas Goaziou  wrote:

> Hello,
>
> [...]
>
> I eventually added :OPTIONAL_TITLE: property. Get its parsed value with
> `org-export-get-optional-title' function.
>
> I patched ox-ascii, ox-latex and ox-html so they use it when building
> a TOC. I think only ox-odt and ox-texinfo are missing.
>
> Jonathan, could you have a look at it?
>

I've replaced the use of :TEXINFO_MENU_TITLE: with :OPTIONAL_TITLE:.

Tom,

This will cause the menu titles to no longer export properly until you
change the property names.

Regards,

--
Jon


> Thank you.
>
>
> Regards,
>
> --
> Nicolas Goaziou
>

Re: [O] Adventures with org-footnote-auto-adjust

[Thomas S. Dye]

Nicolas Goaziou  writes:

> Hello,
>
> t...@tsdye.com (Thomas S. Dye) writes:
>
>> I've learned that there are certain conditions (I don't know how many)
>> where the space after a sentence won't accept a footnote insertion.
>
> There shouldn't be any of such conditions.

Great.  I'll be on the lookout and will report when I find them.

>
>> The example sentence is one of these. Apparently, it is the `~.'
>> combination that triggers the condition. Org is good enough to
>> prohibit inserting a new footnote into one of these "black holes"
>> (which is how I discovered them), but it doesn't mind if I cut and
>> paste a footnote into one.
>
> I fixed it. Footnote references should be allowed there.

Yes, I can confirm that this is fixed.  Thanks!
>
>> I'm not certain how much mischief this might have caused. I discovered
>> the problem when the text of *both* footnotes in a section of the
>> document were incorrect.
>>
>> In my case, org-footnote-auto-adjust doesn't perform any crucial
>> function--it just makes the Org mode buffer seem more orderly.  Given
>> that there are "black holes" in the buffer, whose presence have the
>> ability to confuse org-footnote-auto-adjust so that data are lost,
>> should org-footnote-auto-adjust be deprecated?
>
> `org-footnote-auto-adjust' still does its job when, for example, a new
> footnote is created or a footnote is deleted. It is fragile when
> copy-pasting a footnote reference across some text.
>

In my case, the intended effects of `org-footnote-auto-adjust' were
purely cosmetic in the Org buffer and didn't affect the output.  Is
there a situation where it does something that has an effect on output?

> Anyway, it should be possible to fix most of these "black holes", if
> only we are aware of them.

OK. Apologies for the graphic term. I hope it didn't offend. Dismay got
the better of tact, I think.

All the best,
Tom

-- 
Thomas S. Dye
http://www.tsdye.com

Re: [O] bug-tracker

[Sebastien Vauban]

Hi,

Suvayu Ali wrote:
> On Fri, Feb 22, 2013 at 08:56:54PM +0100, Andreas Röhler wrote:
>> With exception of the noise, M-x report-emacs-bugs tends to send.
>
> Org already uses one of its own: org-submit-bug-report

Maybe we could add an alias such as `M-x report-org-bugs' to mimick that one?

Best regards,
  Seb

-- 
Sebastien Vauban

Re: [O] [texinfo] Bug(?) in detailed node listing

[Jonathan Leech-Pepin]

Hi Tom,

On 21 February 2013 18:44, Thomas S. Dye  wrote:

> Hi Jon,
> [...]
>
> Based on this example from the Org manual, it looks as if the
> descriptions should start on column 32 or the third column after the end
> of the title, whichever is greater.
>
>
I've just pushed a fix for this.  It also introduces a new defcustom
to allow for choosing the column you want it to align at
(org-texinfo-node-description-column).

Regards,

--
Jon

> Thanks for your help on this.
>
> All the best,
> Tom
>
> --
> Thomas S. Dye
> http://www.tsdye.com
>

Re: [O] [texinfo] Info links

[Jonathan Leech-Pepin]

Hello Tom.

On 21 February 2013 18:26, Thomas S. Dye  wrote:

> Hi Jon,
>
> Jonathan Leech-Pepin  writes:
>
> > Hello Tom,
> >
> > On 21 February 2013 15:09, Thomas S. Dye  wrote:
> >
> >> Aloha all,
> >>
> >> This link (which works correctly in the Org mode buffer):
> >>
> >> [[info:emacs#Indirect Buffers][GNU Emacs Manual]]
> >>
> >> exports to texinfo like this:
> >>
> >> @ref{top,GNU Emacs Manual,,emacs#Indirect Buffers,}
> >>
> >> when I was hoping to approximate this:
> >>
> >> @ref{Indirect Buffers,,,emacs,GNU Emacs Manual}
> >>
> >> Is this a bug, or should I be doing something differently?
> >>
> >> This was an oversight by me.  I only set ':' as the splitter in the
> path.
> > I'm not at the machine that has the right SSH key to be able to push
> > the fix, however if you change the # to : it should export properly (I'll
> > add # as a marker to split on as well once I'm at the right machine).
> >
> > This will also work properly in Org to access the correct node.
>
> Yes, the : works fine everywhere.  Thanks!
>

I've added support for both # and : in info links.  So now it should
work either way.

Regards,

--
Jon


> All the best,
> Tom
>
> --
> Thomas S. Dye
> http://www.tsdye.com
>

Re: [O] Exporter question

[Nicolas Goaziou]

Hello,

Bastien  writes:

> Carsten Dominik  writes:
>
>> I am curious why you chose the name "optional_title" for the
>> property?  Why not, for example "TOC_TITLE" or something like this?
>
> I suggest EXPORT_ALT_TITLE instead.
>
> The EXPORT_ prefix seems more consistent with EXPORT_TITLE,
> and ALT sounds clearer (and short enough) to me.

Has it to be an export only property? I mean, it could be used in
a library like org-toc.el.

Also EXPORT_KEYWORD prefix is mostly used when there is a global
#+KEYWORD: available. There is no #+ALT_TITLE: (yet?).

So, what about ALT_TITLE instead?


Regards,

-- 
Nicolas Goaziou

Re: [O] [PATCH] ob-R.el, ox-latex.el: support for tikz graphics

[Nicolas Goaziou]

Hello,

Thanks for extracting that patch from the other one.

Aaron Ecay  writes:
> Tikz graphics should be exported to LaTeX by \include, not as a link.
> This commit changes the file extension used for tikz graphics from .tex
> to .tikz.

I'm wondering if it's really meant to be inserted as an inline image.
Does it support wrapfigure environment or width optional attribute?

If it doesn't, it may be better to implement a dedicated (or a more
general "input" function) formatting function that would be called from
`org-latex-link'.

What do you think?


Regards,

-- 
Nicolas Goaziou

Re: [O] {New exporter] What happened to the export template

[Sebastien Vauban]

Hello Bastien,

Bastien wrote:
> Nicolas Goaziou  writes:
>
>> It has been removed. Such a template depends on the back-end used, which
>> was not the case of the previous implementation.
>
> One idea would be to have an equivalent of the now-defunct
> `org-insert-export-options-template' but for each backend.
>
> For example `C-c C-e h t' would insert the default template
> for the HTML export.
>
> Is anyone interested in this?

My personal answer is: yes!

I constantly used it for inserting a title (defaulting to the name of the
file, which is the best default), timestamp, etc.

Regarding Rasmus objections, yes, maybe there are too much defaults inserted,
or not yours. Maybe the template could be customized, but present in the code
base with a common, good default?

If not, anyway, I'll just mimick the old template with a YASnippet.

Best regards,
  Seb

PS- By the way, there is already such a sort of template for Beamer...

-- 
Sebastien Vauban

Re: [O] tabulated-list

[Nicolas Goaziou]

Hello,

François Pinard  writes:

> This morning, I could not load Org because ox.el calls function
> tabulated-list, which does not seem to exist on this version of Emacs.
> So I fetched the one at https://github.com/sigma/tabulated-list.el to
> get going, but others will likely have the same problem.

Indeed, I introduced this change because I was reinventing the wheel in
`org-export-stack'. I hadn't realized it was emacs24 only.

Bastien, is there another solution besides reverting the commit?


Regards,

-- 
Nicolas Goaziou

[O] tabulated-list

[François Pinard]

Hi, Org people.

This morning, I could not load Org because ox.el calls function
tabulated-list, which does not seem to exist on this version of Emacs.
So I fetched the one at https://github.com/sigma/tabulated-list.el to
get going, but others will likely have the same problem.

François

Re: [O] evaluation of perl in babel

[Eric Schulte]

dmg  writes:

> On Mon, Feb 25, 2013 at 1:54 AM, D M German  wrote:
>>
>>  Achim> You may misunderstand some things, or I don't understand what you are
>>  Achim> asking.  It is (at least currently) the responsibility of the Perl
>>  Achim> program (or any other Babel language) to deliver the result in such a
>>  Achim> way that it can be interpreted correctly by the result type chosen 
>> (in
>>  Achim> other word, the program output must be valid Org syntax in the given
>>  Achim> context).  You can't have the same program produce tables, vectors 
>> and
>>  Achim> LaTeX output just by switching the results type.
>>
>> I understand. But what I want is the output to be wrapped accordingly,
>> and my script to deliver exactly the output as expected. So say I want
>> to generate HTML in my script, I can use :results output, but then I
>> have to change to replace the #+being_example with #+begin_HTML.
>>
>> I guess that I can generate a two dimensional table with perl too
>> using output (printing the necessary | and \n), but then it will be
>> wrapped with #+begin_example.
>
> Ok, I got it. What I need is to return a string with whatever I need.
> A bit cumbersome, but I can live with it
>

It might be worth spending some time with the Org-mode manual.
http://orgmode.org/manual/Working-With-Source-Code.html

You could also use ":results org" or ":results raw", and
then return raw Org-mode from your Perl script instead of html.

Best,

>
>
> #+begin_src perl :results html
> "
> a 
> 
> "
> #+end_src
>
> #+RESULTS:
> #+BEGIN_HTML
> 
> a 
> 
> #+END_HTML
>
> thanks again for the explanation,

-- 
Eric Schulte
http://cs.unm.edu/~eschulte

Re: [O] [PATCH] datetree: Recognize year headline with tags as a match

[Jeffrey Brent McBeth]

On Mon, Feb 25, 2013 at 10:48:16AM +0100, Bastien wrote:
> Hi Tim,
> 
> Tim Burt  writes:
> 
> > * lisp/org-datetree.el (org-datetree-find-year-create):
> >   Include regexp for tags.  Syntax was taken directly
> >   from org-todo-line-tags-regexp in org.el.
> 
> Applied, thanks a lot for the patch and the detailed change log!
> 
> Best,

I can confirm that latest git fixes my use case.  Thank you both so much.

Jeff

-- 
"The man who does not read good books has no advantage over 
 the man who cannot read them."
 -- Mark Twain

[O] Possible to both clock into :CLOCK: and put notes in :LOGBOOK: ?

[Steinar Bang]

Platform: 
 GNU Emacs 23.2.1 (i386-mingw-nt6.1.7600) of 2010-05-08 on G41R2F1
 Org-mode version 7.9.1 (release_7.9.1-321-g9ebf47.dirty-git @ 
c:/Users/steinarb/Documents/git/org-mode/lisp/)


I have org-clock-into-drawer set to "CLOCK".

The idea is to put clocking info in the :CLOCK: drawer to avoid clutter,
and this works.

But if I have this setting then notes created with `C-c C-z' end up on
the top level, even if I manually create a :LOGBOOK: drawer.

Is it possible to have both?

Ie. for a particular node, both:
 - Put clocking into the :CLOCK: drawer
 - Put notes into the :LOGBOOK: drawer (if there is one)

Re: [O] Bug: New HTML exporter incorrect attributes

[Nicolas Goaziou]

Hello,

Vincent Beffara  writes:

>> #+ATTR_HTML: :options "width=\"400px\""
>> 
>> This is heavier but will be consistent with other back-ends. Otherwise,
>> there is also:
>> 
>> #+ATTR_HTML: :width "400px"
>> 
>> But this requires to have a list of all properties supported.
>
> How about both? I.e. a short-list of common options (class, title, id for 
> links typically) plus a generic "options" as a back up to put whatever is not 
> in the short-list ?

A generic :options keyword is a good idea, indeed.

But we still have to agree on the common options part. For example,
I think :id is dangerous, because Org already provides its own way to
generate these properties (e.g. through #+NAME: keywords).

If we make a list of such options, per tag type, I can try to implement
it. Anyone wants to start?


Regards,

-- 
Nicolas Goaziou

Re: [O] Bug: New HTML exporter incorrect attributes

[Vincent Beffara]

> #+ATTR_HTML: :options "width=\"400px\""
> 
> This is heavier but will be consistent with other back-ends. Otherwise,
> there is also:
> 
> #+ATTR_HTML: :width "400px"
> 
> But this requires to have a list of all properties supported.
How about both? I.e. a short-list of common options (class, title, id for links 
typically) plus a generic "options" as a back up to put whatever is not in the 
short-list ?

/v, big fan of the ugliest solutions imaginable
> If we take
> that route, here is a suggested list of such properties for  tag:
> 
> - rel
> - target
> - type
> - accesskey
> - class
> - style
> - title
> 
> and for 
> 
> - alt
> - height
> - width
> 
> What do you think about it?
> 
> > The HTML exporter should produce valid HTML regardless of the input.
> 
> We cannot remove the ability to shoot oneself in the foot. The HTML
> back-end cannot be responsible for undefined syntax. Think about:
> 
> @@html:@@
> 
> > The Org manual describes ATTR_HTML as a feature that applies to the
> > following image or link. It makes no mention of restrictions to
> > following content in the paragraph, and neither does it say it will
> > apply to all following images or links. The manual could be amended to
> > say that ATTR_HTML applies to just the next image or link. To fit the
> > current situation, it might say, "In cases where ATTR_HTML is applied to
> > an image in a paragraph, following links will not be made invalid." But
> > why would anyone be expecting invalid HTML in the first place?
> > 
> > Incidentally, I always thought that simply using another HTML_ATTR would
> > handle multiple images or links in the old exporter. In other words,
> > this:
> > 
> > #+ATTR_HTML: width="10" alt=" [Cool thing] "
> > [[file:cool_thing.jpg]]
> > This is a paragraph about cool things.
> > #+ATTR_HTML: class="bar"
> > Cool thing found here [[http://example.com/][example.com]].
> > 
> > Would become this:
> > 
> > 
> > This is a 
> > paragraph about cool things. Cool thing found here  > href="http://example.com/"; class="bar">example.com (http://example.com).
> > 
> > 
> > I don't remember using that in the old exporter, but I thought it would
> > work.
> > 
> > It almost works in the new exporter, but it begins a new paragraph
> > before the second #+ATTR_HTML. I'm not sure this is the intended
> > behavior, though, because it isn't formatted like other new
> > paragraphs.
> 
> 
> 
> This is the intended behaviour. Affiliated keywords can only exist at
> the beginning of the element they refer to. So, in the previous example,
> you start two paragraphs.
> 
> > Alternatively, having ATTR_HTML (or something more general) apply to the
> > next thing, and having that work within paragraphs, is another
> > possibility. However, this may not fit within the limitations of the
> > new parser. Plus it's kind of ugly.
> 
> 
> 
> The parser won't support it. It goes against the definition of an
> affiliated keyword. Moreover, it's merely a hack (what about links in
> tables?). And it's ugly, indeed.
> 
> > Until there is a "proper" solution, however, could we please modify the
> > exporter to apply ATTR_HTML to only the next image or link? I am very
> > sure that was the spirit of the old exporter, and it would be nice if I
> > could maintain my documents in Org without resorting to (even more)
> > hacks.
> 
> 
> 
> Done.
> 
> 
> Regards,
> 
> -- 
> Nicolas Goaziou

Re: [O] Bug: New HTML exporter incorrect attributes

[Nicolas Goaziou]

tftor...@tftorrey.com (T.F. Torrey) writes:

>> It would be ATTR_HTML: :class "XXX". I try to unify syntax for
>> attributes with syntax for Babel and AFAICT, `html' is the last back-end
>> to have key="value" syntax.
>
> I see that this does not presently work, and the author listed on
> ox-html.el is not currently active on this list.  I hope you are not the
> only one working on this.  It would be our great misfortune for you to
> become burned out.

It's not much work once we agree about the real syntax. For example, for
links, there are two ways to replace:

  #+ATTR_HTML: width="400px"

The easiest one, is simply to ask for `:options' before:

  #+ATTR_HTML: :options "width=\"400px\""

This is heavier but will be consistent with other back-ends.  Otherwise,
there is also:

  #+ATTR_HTML: :width "400px"

But this requires to have a list of all properties supported. If we take
that route, here is a suggested list of such properties for  tag:

  - rel
  - target
  - type
  - accesskey
  - class
  - style
  - title

and for 

  - alt
  - height
  - width

What do you think about it?

> The HTML exporter should produce valid HTML regardless of the input.

We cannot remove the ability to shoot oneself in the foot. The HTML
back-end cannot be responsible for undefined syntax. Think about:

  @@html:@@

> The Org manual describes ATTR_HTML as a feature that applies to the
> following image or link.  It makes no mention of restrictions to
> following content in the paragraph, and neither does it say it will
> apply to all following images or links.  The manual could be amended to
> say that ATTR_HTML applies to just the next image or link.  To fit the
> current situation, it might say, "In cases where ATTR_HTML is applied to
> an image in a paragraph, following links will not be made invalid."  But
> why would anyone be expecting invalid HTML in the first place?
>
> Incidentally, I always thought that simply using another HTML_ATTR would
> handle multiple images or links in the old exporter.  In other words,
> this:
>
> #+ATTR_HTML: width="10" alt=" [Cool thing] "
> [[file:cool_thing.jpg]]
> This is a paragraph about cool things.
> #+ATTR_HTML: class="bar"
> Cool thing found here [[http://example.com/][example.com]].
>
> Would become this:
>
> 
> This is a 
> paragraph about cool things. Cool thing found here  href="http://example.com/"; class="bar">example.com.
> 
>
> I don't remember using that in the old exporter, but I thought it would
> work.
>
> It almost works in the new exporter, but it begins a new paragraph
> before the second #+ATTR_HTML.  I'm not sure this is the intended
> behavior, though, because it isn't formatted like other new
> paragraphs.

This is the intended behaviour. Affiliated keywords can only exist at
the beginning of the element they refer to. So, in the previous example,
you start two paragraphs.

> Alternatively, having ATTR_HTML (or something more general) apply to the
> next thing, and having that work within paragraphs, is another
> possibility.  However, this may not fit within the limitations of the
> new parser.  Plus it's kind of ugly.

The parser won't support it. It goes against the definition of an
affiliated keyword. Moreover, it's merely a hack (what about links in
tables?). And it's ugly, indeed.

> Until there is a "proper" solution, however, could we please modify the
> exporter to apply ATTR_HTML to only the next image or link?  I am very
> sure that was the spirit of the old exporter, and it would be nice if I
> could maintain my documents in Org without resorting to (even more)
> hacks.

Done.


Regards,

-- 
Nicolas Goaziou

Re: [O] CSS link in html export for v. 7.9.3e woes

[Sebastien Vauban]

Hi Daniel,

Daniel Hawthorne wrote:
> Greetings,
>  After updating to 7.9.3e, I no longer am able to include a stylesheet
> link with the following syntax:
>
> #+STYLE:  href="../relative/path/to/mystyle.css"/>
>
> If I go back to my previous version, it works as expected. It is not a path
> issue; On the resulting site, it never tries to load the stylesheet. The
> release notes do not mention anything that would lead me to believe that
> this should have changed. Suggestions welcome.

I got into the same trouble days ago. Nicolas' answer was to use the new
syntax therefore, that is:

  #+HTML_STYLE: ...

Best regards,
  Seb

-- 
Sebastien Vauban

[O] Bug: turn-on-font-lock breaks org-mode in recent emacs [7.9.3e (7.9.3e-3-gb07a9b @ /usr/share/emacs/24.3.50/lisp/org/)]

[Gijs Hillenius]

Until today, I had have these two (legacy) lines in my orgmode configuration

;; (global-font-lock-mode 1) ; for all buffers

which is already a default in emacs. This is also noted in the manual
http://orgmode.org/manual/Activation.html

However: it is still recommended in the Org-Mode Beginners Customization
Guide http://orgmode.org/worg/org-configs/org-customization-guide.html

The second line made a bit of a mess of my .org files with the
20130224 version of emacs-snapshot 

;; (add-hook 'org-mode-hook 'turn-on-font-lock)  ; org-mode buffers only

org files would still open, but show up as (imaginary example)
[[gnus:982.3334][link]] instead of the nice underlined clickable links.








Emacs  : GNU Emacs 24.3.50.1 (i486-pc-linux-gnu, GTK+ Version 3.4.2)
 of 2013-02-24 on dex, modified by Debian
Package: Org-mode version 7.9.3e (7.9.3e-3-gb07a9b @ 
/usr/share/emacs/24.3.50/lisp/org/)

current state:
==
(setq
 org-export-blocks '((src org-babel-exp-src-block nil) (export-comment 
org-export-blocks-format-comment t)
 (ditaa org-export-blocks-format-ditaa nil) (dot 
org-export-blocks-format-dot nil))
 org-ctrl-c-ctrl-c-hook '(org-babel-hash-at-point 
org-babel-execute-safely-maybe)
 org-reverse-note-order t
 org-agenda-skip-scheduled-if-done t
 org-export-preprocess-before-selecting-backend-code-hook 
'(org-beamer-select-beamer-code)
 org-tab-first-hook '(org-hide-block-toggle-maybe 
org-src-native-tab-command-maybe org-babel-hide-result-toggle-maybe 
org-babel-header-arg-expand)
 org-refile-targets '((org-agenda-files :level . 1))
 org-modules '(org-bbdb org-bibtex org-crypt org-docview org-gnus org-info 
org-jsinfo org-irc org-mew org-mhe org-rmail org-vm org-wl org-w3m)
 org-cycle-hook '(org-cycle-hide-archived-subtrees org-cycle-hide-drawers 
org-cycle-show-empty-lines org-optimize-window-after-visibility-change)
 org-agenda-before-write-hook '(org-agenda-add-entry-text)
 org-speed-command-hook '(org-speed-command-default-hook 
org-babel-speed-command-hook)
 org-babel-pre-tangle-hook '(save-buffer)
 org-occur-hook '(org-first-headline-recenter)
 org-export-interblocks '((src org-babel-exp-non-block-elements))
 org-log-done 'time
 org-metaup-hook '(org-babel-load-in-session-maybe)
 org-reveal-start-hook '(org-decrypt-entry)
 org-confirm-elisp-link-function 'yes-or-no-p
 org-export-latex-format-toc-function 'org-export-latex-format-toc-default
 org-export-preprocess-before-normalizing-links-hook 
'(org-remove-file-link-modifiers)
 org-clock-out-hook '(org-clock-remove-empty-clock-drawer)
 org-crypt-key nil
 org-agenda-include-diary t
 org-export-first-hook '(org-beamer-initialize-open-trackers)
 org-mode-hook '(#[nil "\300\301\302\303\304$\207" [add-hook before-save-hook 
org-encrypt-entries nil t] 5]
 #[nil "\300\301\302\303\304$\207" [org-add-hook 
change-major-mode-hook org-show-block-all append local] 5]
 #[nil "\300\301\302\303\304$\207" [org-add-hook 
change-major-mode-hook org-babel-show-result-all append local] 5]
 org-babel-result-hide-spec org-babel-hide-all-hashes)
 org-link-frame-setup '((vm . vm-visit-folder-other-frame) (gnus . gnus) (file 
. find-file-other-window))
 org-agenda-start-on-weekday nil
 org-tags-exclude-from-inheritance '("crypt")
 org-directory "~/d/org"
 org-export-latex-final-hook '(org-beamer-amend-header org-beamer-fix-toc 
org-beamer-auto-fragile-frames
   org-beamer-place-default-actions-for-lists)
 org-export-latex-after-initial-vars-hook '(org-beamer-after-initial-vars)
 org-metadown-hook '(org-babel-pop-to-session-maybe)
 org-src-mode-hook '(org-src-babel-configure-edit-buffer 
org-src-mode-configure-edit-buffer)
 org-after-todo-state-change-hook '(org-clock-out-if-current)
 org-confirm-shell-link-function 'yes-or-no-p
 )
-- 
BOFH excuse #94:

Internet outage

Re: [O] How to make the new exporter open PDF using evince?

[James Harkins]

On Feb 25, 2013 2:52 PM, "Nick Dokos"  wrote:
> I like putting things in ~/.mailcap, but you can season to taste.

Ok, that's 2 votes so far for mailcap. I'll try that later. Thanks!

hjh

Re: [O] [PATCH] Make html exporter respect css-url configuration variable.

[Nicolas Goaziou]

By the way, `org-html-htmlized-org-css-url' docstring looks wrong.
`org-export-as-org' doesn't exist anymore, neither do "batch mode".

So, is the variable still useful? If it is, could someone could fix its
docstring so it reflects what is really happening?

Thank you.


Regards,

-- 
Nicolas Goaziou

Re: [O] [PATCH] bug in expansion of variables in babel Perl

[Achim Gratz]

D M German  uvic.ca> writes:
> I think the issue is that, at least in my computer the variable $\
> returns empty (the record separator).

Thinko on my side,  what I wanted was the input record separator "$/" (to avoid
specifying a literal newline for those systems where this is actually
multi-character).


Regards,
Achim.

Re: [O] [PATCH] Make html exporter respect css-url configuration variable.

[Nicolas Goaziou]

Hello,

Rick Frankel  writes:

> * lisp/ox-html.el:
>   (org-export-define-backend): add css url option
>   (org-export-htmlized-org-css-url):  modify docstring and options.
>   (org-html--build-style): include css-url if specified.

Applied. Thank you.


Regards,

-- 
Nicolas Goaziou

[O] new version of org-mew.el

[Tokuya Kameshima]

Hi,

The attached is the new version of org-mew.el with several new features.
I would appreciate it if some of Mew users could try this.

If this is fine, I would like Bastien to incorporate it to the git repo.

The changes are as follows:

org-mew-store-link
- Works in mew message mode as well as mew summary mode.

org-mew-open
- Locates the message in the inbox folder given by `org-mew-inbox-folder'
  if the message is not found in the link's folder.
- Uses id.db to search the message if the message is not found or the
  folder is not specified by the link.  You can disable this by
  setting `org-mew-use-id-db' to nil.

org-mew-search - new function
- Shows all entries related to the message using `org-search-view'.
  See the docstring for details.

org-mew-capture - new function
- Guesses the capture template from the folder name and invoke
  `org-capture'.  See the docstring for details.



My daily workflow using these features is something like this.

~/.mew.el:
(define-key mew-summary-mode-map "'" 'org-mew-search)
(eval-after-load "mew-summary"
  '(define-key mew-summary-mode-map "\C-o" 'org-mew-capture))

1. In the Mew's inbox folder, I take a glance at new messages to find
   a message that requires any action.
2. If the message is a reply from somebody and associated with the
   existing orgmode entry, type M-x org-mew-search (or press ['] key
   simply) to find the entry.  If I can find the entry successfully
   and think I should start the task right now, start the task by M-x
   org-agenda-clock-in.
3. If the message is a brand-new message, type M-x org-mew-capture,
   enter the refile folder, and the buffer to capture the message is
   shown up (without selecting the template by hand!).  And I fill the
   template and type C-c C-c to complete the capture.  Note that I
   have configured `org-capture-templates' so that the captured entry
   has a link to the message.

Thanks,
--Tokuya
;;; org-mew.el --- Support for links to Mew messages from within Org-mode

;; Copyright (C) 2008-2013 Free Software Foundation, Inc.

;; Author: Tokuya Kameshima 
;; Keywords: outlines, hypermedia, calendar, wp
;; Homepage: http://orgmode.org

;; This file is part of GNU Emacs.

;; GNU Emacs is free software: you can redistribute it and/or modify
;; it under the terms of the GNU General Public License as published by
;; the Free Software Foundation, either version 3 of the License, or
;; (at your option) any later version.

;; GNU Emacs is distributed in the hope that it will be useful,
;; but WITHOUT ANY WARRANTY; without even the implied warranty of
;; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
;; GNU General Public License for more details.

;; You should have received a copy of the GNU General Public License
;; along with GNU Emacs.  If not, see .
;
;;
;;; Commentary:

;; This file implements links to Mew messages from within Org-mode.
;; Org-mode loads this module by default - if this is not what you want,
;; configure the variable `org-modules'.

;;; Code:

(require 'org)

(defgroup org-mew nil
  "Options concerning the Mew link."
  :tag "Org Startup"
  :group 'org-link)

(defcustom org-mew-link-to-refile-destination t
  "Create a link to the refile destination if the message is marked as refile."
  :group 'org-mew
  :type 'boolean)

(defcustom org-mew-inbox-folder nil
  "The folder where new messages are incorporated.
If `org-mew-inbox-folder' is non-nil, `org-mew-open' locates the message
in this inbox folder as well as the folder specified by the link."
  :group 'org-mew
  :type 'string)

(defcustom org-mew-use-id-db t
  "Use ID database to locate the message if id.db is created."
  :group 'org-mew
  :type 'boolean)

(defcustom org-mew-subject-alist
  (list (cons (concat "^\\(?:\\(?:re\\|fwd?\\): *\\)*"
  "\\(?:[[(][a-z0-9._-]+[:,]? [0-9]+[])]\\)? *"
  "\\(?:\\(?:re\\|fwd?\\): *\\)*"
  "\\(.*\\)[ \t]*")
  1))
  "Alist of subject regular expression and matched group number for search."
  :group 'org-mew
  :type '(repeat (cons (regexp) (integer

(defcustom org-mew-capture-inbox-folders nil
  "List of the inbox folders whose messages need refile marked before capture.
`org-mew-capture' will ask you to put the refile mark on the message
if the message's folder is any of these folders and the message is not marked.
Nil means `org-mew-capture' never ask you destination folders before capture."
  :group 'org-mew
  :type '(repeat string))

(defcustom org-mew-capture-guess-alist nil
  "Alist of the regular expression of the folder name and the capture
template selection keys.

For example,
'((\"^%emacs-orgmode$\" . \"o\")
  (\"\" . \"t\"))
the messages in \"%emacs-orgmode\" folder will be captured with
the capture template associated with \"o\" key, and any other
messages will be captured with the captur

[O] Add agenda entries into diary to export weelky calendar

[Torsten Wagner]

Hi,

still trying to get a printed calendar including all org-agendas, I noticed
that the calendar/diary built-in function in emacs allows export of
calendar views.
Guess that and some post-processing for the print-job is all I need.

However, I did not find a way how-to add org-agenda entries into the diary
resp. into the calendar export.
I know it works vice versa, seeing diary entries in org-agenda views.

Did someone manage to achieve this.

Alternatively, would it be of interest (and how difficult would it be) to
get org-agenda exports as daily/weekly/monthly calendar as PDF (via LaTeX)
or HTML? Guess to start this one would have to look into the new exporter
functions and create a list of all agenda entries feeding this into a
template. However, most of the functionality is already there via
calendar/diary and I wonder which way would be the best; using those
functions or create own.

Alternatives:
I read about calfw and org2hpda. However, I did not found a way to generate
a printable version of calfw (and I had trouble to set it up). For org2hpda
I still struggle with the installation and it seems to be broken at the
moment. Not sure.


All the best

Torsten

Re: [O] Bug: New HTML exporter incorrect attributes

[T.F. Torrey]

Hello Nicolas,

Nicolas Goaziou  writes:

> tftor...@tftorrey.com (T.F. Torrey) writes:
>
>>> You don't assign attributes to an image in a paragraph, you assign
>>> attributes to the paragraph itself.
>>
>> It would be nice if there actually was a way to assign an attribute to a
>> paragraph, so that the ATTR_HTML: class="XXX" syntax would export as > class="XXX">, but that is a different issue.
>
> It would be ATTR_HTML: :class "XXX". I try to unify syntax for
> attributes with syntax for Babel and AFAICT, `html' is the last back-end
> to have key="value" syntax.

I see that this does not presently work, and the author listed on
ox-html.el is not currently active on this list.  I hope you are not the
only one working on this.  It would be our great misfortune for you to
become burned out.

>>> For the time being, Org syntax
>>> doesn't allow to specify attributes per link object.
>>
>> I think what you are saying is that the current intended behavior is for
>> whatever is specified by ATTR_HTML to apply to every image or link in
>> the paragraph.
>
> No. I am saying that ATTR_HTML behaviour in _undefined_ when a paragraph
> contains more than one link, as it has always been.
>
> If you carefully look at Org manual (in application with previous
> exporter framework), in "Images in HTML export", you will notice that
> HTML attributes only apply to a single link pointing to an image, not to
> a paragraph containing many links.

I see no such limitation in the Org manual (12.5.6).  It says this:

If you need to add attributes to an inlined image, use a
`#+ATTR_HTML'.

Though the example that follows doesn't show a paragraph, calling them
"inline" indicates they will be within a paragraph.  Org manual section
12.5.4 also shows ATTR_HTML applying to a hyperlink by itself, but
hyperlinks would rarely be used that way in real life, and in fact the
old exporter always applied ATTR_HTML attributes to the next item in a
paragraph.

I have always understood the manual to mean that an ATTR_HTML would
apply to *the next thing* in the document that it could, and that was
what happened in practice.  That was a useful thing for them to do.

>>> As a consequence, attributes will be assigned to every link within the
>>> paragraph.
>>
>> Is this behavior helpful to anyone in any practical circumstances?
>
> I never said it was. It's not even a feature. I'm just explaining what
> is happening.

If it isn't intended behavior, and it isn't helpful, then we should make
it stop doing that.

>> Moreover, this means that, not only does the new exporter fail where the
>> old one succeeded,
>
> I worked hard to make the new export framework compatible with defined
> behaviour of previous exporter, not with handy undocumented side-effects
> it may have.
>
>> It seems to me that, whether the user is happy with the output or not,
>> the HTML exporter ought to produce valid HTML.
>
> I agree. But, in this case, you're using undefined Org syntax (which,
> admittedly, used to "work" for you).

The HTML exporter should produce valid HTML regardless of the input.

> If there's a simple patch that mimics this for html back-end, I don't
> mind applying it. But it still won't make up for a real solution.
>
> Unless, that is, it is decided that this behaviour is an official
> feature supported by Org, in which case, it should be added to the
> manual.

The Org manual describes ATTR_HTML as a feature that applies to the
following image or link.  It makes no mention of restrictions to
following content in the paragraph, and neither does it say it will
apply to all following images or links.  The manual could be amended to
say that ATTR_HTML applies to just the next image or link.  To fit the
current situation, it might say, "In cases where ATTR_HTML is applied to
an image in a paragraph, following links will not be made invalid."  But
why would anyone be expecting invalid HTML in the first place?

Incidentally, I always thought that simply using another HTML_ATTR would
handle multiple images or links in the old exporter.  In other words,
this:

#+ATTR_HTML: width="10" alt=" [Cool thing] "
[[file:cool_thing.jpg]]
This is a paragraph about cool things.
#+ATTR_HTML: class="bar"
Cool thing found here [[http://example.com/][example.com]].

Would become this:


This is a 
paragraph about cool things. Cool thing found here http://example.com/"; class="bar">example.com.


I don't remember using that in the old exporter, but I thought it would
work.

It almost works in the new exporter, but it begins a new paragraph
before the second #+ATTR_HTML.  I'm not sure this is the intended
behavior, though, because it isn't formatted like other new paragraphs.

>> A more general workaround that would help everyone affected would be to
>> temporarily modify ox-html.el so that attributes from ATTR_HTML only
>> apply to the *first* item in the paragraph.  This would have the
>> advantage of mimicking the behavior of the old exporter (thus not
>> breaking exist

Re: [O] Adventures with org-footnote-auto-adjust

[Nicolas Goaziou]

Hello,

t...@tsdye.com (Thomas S. Dye) writes:

> In the document I'm editing, I have sentences like this:
>
>   If you want a list to start with a different value (e.g., 20),[fn:17]
>   start the text of the item with ~[@20]~.
>
> As a matter of style, I prefer the footnote (which contains qualifying
> text, rather than a reference) be at the end of the sentence, and that
> it immediately follow the period.  So, I cut and paste to get this:
>
>   If you want a list to start with a different value (e.g., 20),
>   start the text of the item with ~[@20]~.[fn:17]
>
> Now, the next time I insert a footnote, with C-c C-x f, I get something
> like this:
>
>   If you want a list to start with a different value (e.g., 20),[fn:17]
>   start the text of the item with ~[@20]~.[fn:17]
>
> The text of the original footnote, [fn:17], is lost, though the mark
> remains in the text.  If the new [fn:17] is some distance away, then the
> problem of duplicate numbers isn't readily apparent in the midst of
> other work.  Of course, I subsequently discovered that `~.[fn:17]'
> wasn't working and put the space back in.  Now, the footnote refers to
> the wrong text.
>
> I've learned that there are certain conditions (I don't know how many)
> where the space after a sentence won't accept a footnote insertion.

There shouldn't be any of such conditions.

> The example sentence is one of these. Apparently, it is the `~.'
> combination that triggers the condition. Org is good enough to
> prohibit inserting a new footnote into one of these "black holes"
> (which is how I discovered them), but it doesn't mind if I cut and
> paste a footnote into one.

I fixed it. Footnote references should be allowed there.

> I'm not certain how much mischief this might have caused. I discovered
> the problem when the text of *both* footnotes in a section of the
> document were incorrect.
>
> In my case, org-footnote-auto-adjust doesn't perform any crucial
> function--it just makes the Org mode buffer seem more orderly.  Given
> that there are "black holes" in the buffer, whose presence have the
> ability to confuse org-footnote-auto-adjust so that data are lost,
> should org-footnote-auto-adjust be deprecated?

`org-footnote-auto-adjust' still does its job when, for example, a new
footnote is created or a footnote is deleted. It is fragile when
copy-pasting a footnote reference across some text.

Anyway, it should be possible to fix most of these "black holes", if
only we are aware of them.

Thanks for your report.


Regards,

-- 
Nicolas Goaziou

Re: [O] Warning with latest git pull

[Bastien]

Hi Achim,

Achim Gratz  writes:

> We shouldn't define things that don't have an org prefix.

Fair enough.

(Note that `with-buffer-modified-unmodified', from which
org-unmodified was heavily copied, lives in bookmark.el.  Perhaps
Emacs should put it elsewhere.)

> I don't really see why we needed to replace org-unmodified in the
> first place, especially since with-silent-modifications does _more_
> than org-unmodified,

Especially *because* it does more.  In particular, it does set
`buffer-file-name' and `buffer-file-truename' to nil, which is 
a problem when preparing the agenda buffers.

> not less as your comment in org-macs would imply.

I fixed the comment, thanks.

> Here's a patch to restore org-unmodified in the sources, make it an
> alias to with-silent-modifications when possible and augment the
> replacement definition with a few things that with-silent-modifications
> does on top of what org-unmodified did.  We might even copy the whole
> macro definition from subr.el, but I think we're close enough with this.

Thanks -- I applied a different patch, using `org-with-silent-modifications'
as a compatibility macro for `with-silent-modifications'.

Best,

-- 
 Bastien

Re: [O] C-c ^ not fully useful

[Carsten Dominik]

On 25 feb. 2013, at 10:28, Bastien  wrote:

> Hi François,
> 
> sorting list items and headlines is now done against the visible
> part of the item and headlines, i.e., it ignores hidden links and
> emphasis markers.

Hi Bastien,

are you sure it removes emphasis markers as well?  Looks to me that 
org-sort-remove-invisible only removes links.  I guess it could be rewritten 
looking at invisibility properties, but that might be problematic when sorting 
includes a part of the buffer that has not yet been visible in a window and 
therefore might not be propertized properly.

- Carsten

> 
> I am not sure it is useful to add a parameter to `org-sort-list' and
> `org-sort-entries' to let the user change this default behavior: do
> you have a significant use-case for this?
> 
> François Pinard  writes:
> 
>> - Could some parameterisation be added so one could map user written
>>  functions over (free) option letters?
> 
> Here again, my feeling is that it would be over-engineered -- would
> you use it yourself?  How?
> 
> Thanks for suggesting this improvements!
> 
> -- 
> Bastien
> 


-- 
Having an entire horizon of things you half-care about. -- Merlin Mann in 
"Inbox Zero"

Re: [O] C-c ^ not fully useful

[Bastien]

Hi Carsten,

Carsten Dominik  writes:

> are you sure it removes emphasis markers as well?  Looks to me that
> org-sort-remove-invisible only removes links.  I guess it could be
> rewritten looking at invisibility properties, but that might be problematic
> when sorting includes a part of the buffer that has not yet been visible in
> a window and therefore might not be propertized properly.

You are right, the version that removes emphasis markers based on the
visibility[1] specs is buggy.  I tweaked `org-sort-remove-invisible'
so that it removes emphasis markers for good[2].  I did some testing
and it works okay, let me know if you anticipate any other problem.

Thanks,

[1] http://orgmode.org/cgit.cgi/org-mode.git/commit/?id=30d6dc
[2] http://orgmode.org/cgit.cgi/org-mode.git/commit/?id=662cb9

-- 
 Bastien

Re: [O] Correct / best way of loading packages in contrib when using org compiled from git?

[Bastien]

Rainer M Krug  writes:

> Quick follow up question - what is the value for the Ubuntu package?

I'm not using Ubuntu so I don't know, sorry!

-- 
 Bastien

Re: [O] [new exporter] headline export to LaTeX

[henry atting]

Nicolas Goaziou  writes:

> Hello,
>
> henry atting  writes:
>
>> Since the last pull (release_7.9.3f-1205-g0030e1) headlines are exported
>> to LaTeX like this:
>>
>> \subsection*[Headline]{Headline}
>>
>> which does not produce proper headlines in the resulting pdf.
>
> It should be fixed now. Thank you.

Yes, thank you.

Regards,

-- 
henry atts, web: http://literaturlatenight.de

Re: [O] org-fill-paragraph leaves point at end of table

[Eric Abrahamsen]

Carsten Dominik  writes:

> On 25 feb. 2013, at 10:10, Nicolas Goaziou  wrote:
>
>> Hello,
>> 
>> Eric Abrahamsen  writes:
>> 
>>> Calling `org-fill-paragraph' inside a table leaves point at the end of
>>> the table, for reasons that are totally unclear to me.
>>> 
>>> I've tested this with up-to-date org and emacs -Q, so I'm hoping it's
>>> reproducible. I edebugged org-fill-paragraph, and it appears to do the
>>> right thing, going from the save-excursion to the cond to the org-table
>>> cond statement, and there calling `org-table-align'. That works
>>> correctly, but stepping forward you come to the end of the enclosing
>>> `save-excursion', and emerging from `save-excursion' puts point at the
>>> end of the table -- precisely what it's not supposed to do!
>>> 
>>> I made a minimum sexp to reproduce the relevant bits of
>>> org-fill-paragraph:
>>> 
>>> #+BEGIN_SRC emacs-lisp
>>>  (save-excursion
>>>(let ((element (org-element-at-point)))
>>>  (case (org-element-type element)
>>>(table-row (org-table-align) t
>>> #+END_SRC
>>> 
>>> Putting point in a table and eval'ing that also leaves point at the end
>>> of the table. I tried using (call-interactively 'org-table-align) and it
>>> did the same thing.
>>> 
>>> I'm baffled, particularly as it doesn't do this for any other element
>>> type. Any clever ideas? M-q after a bit of typing is already stuck in my
>>> fingers, and this bit of strangeness doesn't set the mark, so editing
>>> long tables is a pain...
>> 
>> `org-table-align' inserts a whole new table and removes completely the
>> previous one. This confuses `save-excursion' which doesn't recognize any
>> familiar location anymore.
>> 
>> I've pushed a fix for it. All filling tests pass, but if you notice
>> anything suspicious, please signal it.
>
> I do not expect problems, because you now fall back onto
> org-table-align without any save-excursion around it, AFAICS.
> org-table-align remembers line number and table row number and
> restores them, so this should work.

And sure enough, it does!

Sorry for all the table-related stuff. I'm in one of those moments where
you throw caution to the wind and entrust a time-sensitive company
project to areas of git-master Orgmode you've never used before. Likely
very stupid, but it's too late to turn back now.

Thanks!
E

Re: [O] [new exporter] headline export to LaTeX

[Nicolas Goaziou]

Hello,

henry atting  writes:

> Since the last pull (release_7.9.3f-1205-g0030e1) headlines are exported
> to LaTeX like this:
>
> \subsection*[Headline]{Headline}
>
> which does not produce proper headlines in the resulting pdf.

It should be fixed now. Thank you.


Regards,

-- 
Nicolas Goaziou

Re: [O] Correct / best way of loading packages in contrib when using org compiled from git?

[Rainer M Krug]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 22/02/13 22:17, Achim Gratz wrote:
> Rainer M Krug writes:
>> Ok - that makes sense. I just checked in my contrib/lisp and I only have .el 
>> there, so none
>> are compiled.
> 
> Look in lisp, not contrib/lisp.

True - because it compiles it there.

> 
>>> If you set the load-path to include the "contrib/lisp/" directory, then you 
>>> don't need to 
>>> install org-notmuch, and (require 'org-notmuch) will find it.
>> 
>> Well - I don't install org, but just specify the load-path, so I have to 
>> specify that one as
>> well. No problem.
> 
> No, you don't want that if you use ORG_ADD_CONTRIB.

Absolutely - if I use ORG_ADD_CONTRIB I don't want / need it, but If I don't, I 
do.

> 
>> Yes - that is what I am doing as well.
> 
> Just curious, what would change for you if you installed Org into a user 
> directory (besides
> using "make up2" instead of "make update")?

Well - I could and I guess nothing would change. Why I like my setup at the 
moment is, that I have
all emacs config, installation and elpa in my .emacs.d directory. Would this be 
the same after
using "make up2"? Would I have to change paths somewhere?

> 
>> Just for clarifications: is there any problem with adding
>> 
>> ORG_ADD_CONTRIB = *
>> 
>> to the local.mk file, apart from slightly longer compilation times?
> 
> Yes, you don't want all of contrib (htmlize.el in particular).

Makes sense - changed it as described in the other email.

> 
 PS: I update my git almost daily via the following script:
>>> 
>>> This should be enough
> 
> Actually, the "git checkout master" at the beginning should probably stay 
> there as a defensive
> measure.

Ok - I just re-activate this command - shouldn't hurt.

Thanks a lot,

Rainer

> 
> 
> Regards, Achim.
> 

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJRKzddAAoJENvXNx4PUvmCl+QIAK7kGmIbrO1j/cgOjEJXd/Xr
6snTTUf4epB0ZAuOVEXoC38GA7bdVcxJa8kJlE/LC6SCgTncljS57T8PXXmlF29F
66QY5GMsMhS0ySR4NERrloo3TWlomcfD6jSc/EzBJHP4ErDQ4J52EL0RwcO71/F6
sTK96TM06UlSta389/cKn/PMtIwVqi/oav2z1zFINVNFjYCxEOVkj0+ei03k/bmO
8aywm19q0UOPPL2mjnCI8cxEzfpzX2/WZllplXvSYYUIf5bz+JmMMZfQsawmmzWA
9YX31Usb7i3TM/7OhlOX/sahjdlJ2JvV7uqxg2Dj2KnzrlXCXq1+jyNKU0GlFbQ=
=4J3Q
-END PGP SIGNATURE-

Re: [O] Correct / best way of loading packages in contrib when using org compiled from git?

[Rainer M Krug]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 22/02/13 16:42, Achim Gratz wrote:
> Bastien  altern.org> writes:
>>> Just for clarifications: is there any problem with adding
>>> 
>>> ORG_ADD_CONTRIB = *
>>> 
>>> to the local.mk file, apart from slightly longer compilation times?
>> 
>> This should be okay, but it's not safe.  If any non-emacs-lisp file gets 
>> added to
>> contrib/lisp/ (e.g. a README file) then you will try to compile non-elisp 
>> files.  *\.el is
>> safer.
> 
> This is a globbing pattern, not a regular expression, hence: "*.el", but that 
> would also pull
> in htmlize which you most likely don't want, so you might follow the lead in 
> server.mk and make
> that "org-*" or "org-*.el" if you are worried that the Org maintainer forgets 
> that only lisp
> files should go into the lisp directory.  :-)

Thanks Bastien and Achim - I will then use "org-*.el"

Quick follow up question - what is the value for the Ubuntu package?

Rainer

> 
> 
> Regards, Achim.
> 
> 
> 

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJRKzZNAAoJENvXNx4PUvmC1EcH/AojCzTMu46oEjEClVLLfG0S
dju5QTA+1hfl8UfbTcY34aOwXP0CiGSxQtGF53M0CYxjFMI44o5yXVfHoKtKLwHQ
oII+6f6KT3kl2uhxJ6KUxZuvVZ5TRbse6Wse2NeacZRyHlioYYlf+nBVPBarZH+M
hPJIOYYPQUN4tEOdVRpjaWGGMzrXHxUqbY3KEWlVR6tYgPhsg4Pv7dzTr6ObW9qV
zrcBzHMoVTlgZXkNIcJu6wghwS2j/vLeFL3AHpxJyuM01nehY13KYsXxxl8ztDt3
YgGPsW3vbD0YdfEmhJLTPYxdskb13L5bFPMaFFObuoLdhI69PlmY3EEIXqUF0ZE=
=teLG
-END PGP SIGNATURE-