Re: [O] [ANN] Merge of new export framework on Wednesday
Nicolas Goaziou writes: […] Nicolas, moving the old exporter files to contrib/lisp/ will create problems for the org-plus-contrib ELPA archive. Can I move them to contrib/oldexp/ instead? Regards, Achim. -- +[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]+ SD adaptations for Waldorf Q V3.00R3 and Q+ V3.54R2: http://Synth.Stromeko.net/Downloads.html#WaldorfSDada
Re: [O] Macro expansion in new exporter
Hello,
tftor...@tftorrey.com (T.F. Torrey) writes:
Right now, though, it's giving me a small problem: in the export to
HTML, macro's are not expanded, so I have {{{title}}}, for instance, in
the HTML output.
I haven't been following the list as closely as I'd like, so I'm hoping
I missed something relevant in the changeover.
If anyone has any ideas, I'd appreciate them before I go digging.
Macro expansion happens before export back-ends kick-in, as does Babel
code evaluation and file inclusion through #+include keywords. So the
problem (if there's one) doesn't come from ox-html.el.
On that topic, the main difference with the previous exporter is that
macros are now required to be in a context that can be parsed. Thus, for
example, the following is not a macro:
~{{{title}}}~
Emacs : GNU Emacs 24.3.50.1 (i686-pc-linux-gnu, GTK+ Version 3.6.0)
of 2012-12-24 on menkib, modified by Debian
Package: Org-mode version 7.9.2+ (7.9.2+-GNU-Emacs-24-3 (commit 488eea) @
mixed installation! /usr/share/emacs/24.3.50/lisp/org/ and
/home/tftorrey/.emacs.d/elisp/org/lisp/)
You have a mixed installation. You should perhaps fix this before trying
again.
Regards,
--
Nicolas Goaziou
Re: [O] [ANN] Merge of new export framework on Wednesday
Hello, Achim Gratz strom...@nexgo.de writes: Nicolas Goaziou writes: […] Nicolas, moving the old exporter files to contrib/lisp/ will create problems for the org-plus-contrib ELPA archive. Can I move them to contrib/oldexp/ instead? As far as I am concerned, you can. Bastien (CC'ed) might have another plan for these files, though. Regards, -- Nicolas Goaziou
Re: [O] navigating between non-code blocks?
Hi Bill, Bill White bi...@wolfram.com writes: And thanks for implementing it. One small code problem, though - I think BLOCK-REGEXP should default to org-block-regexp. Otherwise, block-regexp isn't defined and the function just goes to the next org-babel-src-block-regexp Of course, I just push this change. (Sorry, I don't recall offhand how to set that up in elisp.) And, echoing Sebastien, `F' and `B' as speed commands would be very handy. Done! -- Bastien
Re: [O] [ANN] Merge of new export framework on Wednesday
Achim Gratz strom...@nexgo.de writes: Nicolas, moving the old exporter files to contrib/lisp/ will create problems for the org-plus-contrib ELPA archive. Can I move them to contrib/oldexp/ instead? Yes, please go ahead. Thanks, -- Bastien
[O] Running a sudo in a #+begin_src sh fails to get tty and askpass
Dear list, I want to compile (C-c C-c) the following code #+begin_src sh sudo apt-get update #+end_src The following warning/error appears in the Org-Babel Error Output: sudo: sin tty presente y no hay programa askpass especificado sudo: sin tty presente y no hay programa askpass especificado Sorry, try again. sudo: sin tty presente y no hay programa askpass especificado sudo: sin tty presente y no hay programa askpass especificado Sorry, try again. sudo: sin tty presente y no hay programa askpass especificado sudo: sin tty presente y no hay programa askpass especificado Sorry, try again. sudo: 3 intentos de contraseña The translation is sudo: no tty present and no askpass program specified How should I configure Org mode or my system to run this chunk? I am running ppa:cassou/emacs in Lubuntu: GNU Emacs 24.3.50.1 (i686-pc-linux-gnu, GTK+ Version 3.4.2) of 2013-01-01 on nannyberry, modified by Debian Thanks! Emilio
Re: [O] Running a sudo in a #+begin_src sh fails to get tty and askpass
Emilio Torres Manzanera tor...@uniovi.es writes: Dear list, I want to compile (C-c C-c) the following code #+begin_src sh sudo apt-get update #+end_src #+begin_src sh :dir /sudo:: apt-get update #+end_src Thanks! Emilio Best regards, Michael.
Re: [O] [ANN] Merge of new export framework on Wednesday
Bastien writes: Nicolas, moving the old exporter files to contrib/lisp/ will create problems for the org-plus-contrib ELPA archive. Can I move them to contrib/oldexp/ instead? Yes, please go ahead. Done, please check that I didn't miss any file. Regards, Achim. -- +[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]+ Factory and User Sound Singles for Waldorf rackAttack: http://Synth.Stromeko.net/Downloads.html#WaldorfSounds
Re: [O] [ANN] Merge of new export framework on Wednesday
Achim Gratz strom...@nexgo.de writes: Done, please check that I didn't miss any file. org2rem.el and org-export-generic.el both require org-exp.el. Shouldn't they go into oldexp, too? Regards, -- Nicolas Goaziou
Re: [O] [ANN] Merge of new export framework on Wednesday
Nicolas Goaziou n.goaz...@gmail.com writes: Achim Gratz strom...@nexgo.de writes: Done, please check that I didn't miss any file. org2rem.el and org-export-generic.el both require org-exp.el. Shouldn't they go into oldexp, too? Indeed, done. -- Bastien
Re: [O] ocaml babel no longer works?
Alan Schmitt writes: Hello, I recently updated org-mode (from git), and ocaml source code is no longer recognized. If I have a very simple file, like this: #+BEGIN_SRC ocaml let x = 2 in x #+END_SRC I don't get syntax highlighting, and trying to evaluate it result in an error: Evaluate this ocaml code block on your system? (y or n) y executing Ocaml code block... face-spec-choose: Wrong type argument: listp, class I have found the problem: I was missing a new line at the end of the #+END_SRC. Unfortunately the evaluation of the code does not work with recent tuareg. I first had to add: (defalias 'tuareg-run-caml 'tuareg-run-ocaml) to my configuration file. But even with this it gets stuck saying executing Ocaml code block... until I ctrl-G it. I'll try to see what is happening. Any suggestion as how to debug this? Thanks, Alan
Re: [O] edit-src on read-only files
Hi all, Eric S Fraga e.fr...@ucl.ac.uk writes: Greg Minshall minsh...@umich.edu writes: hi. i use RCS on my .org files. it's happened to me more than once (1 == shame on me) that i've entered C-c ' on a read-only .org file, spent some time editing the source code fragment, then done C-c ', only to lose my edits, as the original buffer was read-only. Yes, I share your shame... this has happened to me more than once as well. Thank you for the simple solution which I have installed! I have installed that as well. Very nice thanks. But you are correct that org should check for this case. Or at least provide a mechanism for saving the source code block elsewhere... Seconded. On a related note: I'd also love to see the changes in the source code buffers be autosaved in the org file. I've lost some big edits already due to power loss on my (old) laptop. Cheers, Andreas
Re: [O] LaTeX export: Theorem with an author
Hi Nicolas,
How to generate latex code for a theorem with an author, like this:
\begin{theorem}[Newton]
Blah.
\end{theorem}
With the old exporter, you could do this:
#+BEGIN_theorem Newton
Blah.
#+END_theorem
[...]
I was not aware of that possibility in the old exporter. Neat!
There's no right way at the moment: I forgot to implement this.
Anyway, since this feature was LaTeX only, what do you think about the
following syntax (which doesn't work yet):
#+attr_latex: :options [Newton]
#+begin_theorem
Blah.
#+end_theorem
It is heavier but it seems more consistent to me.
Even if it *was* LaTeX only, shouldn't it be up to the backend to
provide translation of such arguments? I'd vote for the shorter version
to have a (possibly future) backend-agnostic version.
Just my 2ct.
- Andreas
Re: [O] LaTeX export: Theorem with an author
Hello, Andreas Leha andreas.l...@med.uni-goettingen.de writes: #+attr_latex: :options [Newton] #+begin_theorem Blah. #+end_theorem It is heavier but it seems more consistent to me. Even if it *was* LaTeX only, shouldn't it be up to the backend to provide translation of such arguments? I'd vote for the shorter version to have a (possibly future) backend-agnostic version. Well, I already have implemented this syntax. We'll see how it goes. Regards, -- Nicolas Goaziou
Re: [O] LaTeX export: Theorem with an author
Hi Nicolas, #+attr_latex: :options [Newton] #+begin_theorem Blah. #+end_theorem It is heavier but it seems more consistent to me. Even if it *was* LaTeX only, shouldn't it be up to the backend to provide translation of such arguments? I'd vote for the shorter version to have a (possibly future) backend-agnostic version. Well, I already have implemented this syntax. We'll see how it goes. Since I go the LaTeX-route most times, I'll be a most-times-happy user of this. Thanks for implementing it! Exporting to multiple backends takes more efforts than I'd like, anyway. So I try to avoid that and concentrate on one backend per project. I'd just rather like to see the differences decrease -- not increase ;-) - Andreas
Re: [O] [ANN] Merge of new export framework on Wednesday
On Fri, Feb 8, 2013 at 4:45 PM, Sebastien Vauban
wxhgmqzgw...@spammotel.com wrote:
Sean O'Halpin wrote:
I suggest we rename it to #+HTML_HEAD.
But I'd like to propose HTML_HEADER instead (?), to mirror what LaTeX_HEADER
does -- at least, if that one still exists, which I'm not sure about (not
enough played with the new exporter yet).
I'm going on the assumption that what comes after the =#+HTML_= prefix
is specific to the HTML back-end. Where LaTeX has a /conceptual/
header, HTML has a /concrete/ =head= element. There's nothing to
mirror =LaTeX_CLASS= for example because the concept of document class
does not exist in HTML.
This raises another question which is more about Org document export
headers in general: why do we have specific document headers for LaTeX
and HTML? Because we need to able to insert raw markup at specific
points in the exported document. (We also have =html-preamble= and
=html-postamble= which act on every document.) But what about other
exporter back-ends? Say we get a native org to docbook exporter. What
would be the mechanism for inserting markup into the =artheader=?
Would there be a =#+DOCBOOK_HEADER=?
Please forgive my meandering here. It's just struck me that we might
need a more general mechanism for document-level export directives
that will avoid multiplying the number of =#+HTML_= style directives
we already have. Perhaps something along the lines of:
#+BEGIN_SRC ORG
,#+EXPORT html head style .../
,#+EXPORT latex header \usepackage{xyz}
#+END_SRC
where =head= and =header= represent specific places in the exported
document that the exporter in question has defined as places you can
insert raw markup. So, Org would define the =#+EXPORT= protocol,
specific back-ends would define the names and places.
Regards,
Sean
Re: [O] [ANN] Merge of new export framework on Wednesday
Hello,
Sean O'Halpin sean.ohal...@gmail.com writes:
This raises another question which is more about Org document export
headers in general: why do we have specific document headers for LaTeX
and HTML? Because we need to able to insert raw markup at specific
points in the exported document. (We also have =html-preamble= and
=html-postamble= which act on every document.) But what about other
exporter back-ends? Say we get a native org to docbook exporter. What
would be the mechanism for inserting markup into the =artheader=?
Would there be a =#+DOCBOOK_HEADER=?
Please forgive my meandering here. It's just struck me that we might
need a more general mechanism for document-level export directives
that will avoid multiplying the number of =#+HTML_= style directives
we already have. Perhaps something along the lines of:
#+BEGIN_SRC ORG
,#+EXPORT html head style .../
,#+EXPORT latex header \usepackage{xyz}
#+END_SRC
where =head= and =header= represent specific places in the exported
document that the exporter in question has defined as places you can
insert raw markup. So, Org would define the =#+EXPORT= protocol,
specific back-ends would define the names and places.
Not every back-end has a concept of head (think about Markdown
back-end). We don't need a general concept for something that isn't
general.
Also, completely unifying every back-end is close to impossible, unless
the same person writes every back-end[1]. Most of the options are
shared, that's the goal of ox.el, but in the end, each back-end decides
how it handles the others.
Regards,
[1] Even then, back-ends are so different that it would ultimately fail,
anyway.
--
Nicolas Goaziou
Re: [O] [ANN] Merge of new export framework on Wednesday
Achim Gratz strom...@nexgo.de writes: Nicolas Goaziou writes: […] Nicolas, moving the old exporter files to contrib/lisp/ will create problems for the org-plus-contrib ELPA archive. Can I move them to contrib/oldexp/ instead? I recommend contrib/obsolete/ or contrib/attic/. Regards, Achim. --
[O] org-caldav problem: void-function url-http-options
Since a few days (maybe an emacs update) I get this error message whenever I run org-caldav-sync. --8---cut here---start-8--- Debugger entered--Lisp error: (void-function url-http-options) url-http-options(https://www.google.com/calendar/dav/0fseo5jbfp99polnfc6ic38...@group.calendar.google.com/events/;) url-dav-supported-p(https://www.google.com/calendar/dav/0fseo5jbfp99polnfc6ic38...@group.calendar.google.com/events/;) (or (and (boundp (quote url-dav-patched-version)) url-dav-patched-version) (url-dav-supported-p (org-caldav-events-url))) (if (or (and (boundp (quote url-dav-patched-version)) url-dav-patched-version) (url-dav-supported-p (org-caldav-events-url))) nil (error You have to either use Emacs from bzr, or the patched `url-dav' package from the org-caldav repository.)) org-caldav-sync() call-interactively(org-caldav-sync record nil) command-execute(org-caldav-sync record) execute-extended-command(nil org-caldav-sync) call-interactively(execute-extended-command nil nil) --8---cut here---end---8--- I've been digging around a bit and url-http-options is defined in url-http.el which is present on my system (/usr/share/emacs/24.3.50/lisp/url/url-http.el.gz) so I don't understand why it isn't found (assuming that void-function message actually means it can't find the definition of the function). Everything was working fine with org-caldav before and I was very happy with it. Thanks a lot to its developper. Julien.
Re: [O] org-caldav problem: void-function url-http-options
Julien Cubizolles writes: Since a few days (maybe an emacs update) I get this error message whenever I run org-caldav-sync. Debugger entered--Lisp error: (void-function url-http-options) I've been digging around a bit and url-http-options is defined in url-http.el which is present on my system (/usr/share/emacs/24.3.50/lisp/url/url-http.el.gz) so I don't understand why it isn't found (assuming that void-function message actually means it can't find the definition of the function). Does doing a (require 'url-http) before calling org-caldav help? -David
[O] format of the ID property in the new HTML exporter
Hi, in ox-html.el there's a line with an assert (the only one): (assert (org-uuidgen-p path)) 1. I have some IDs like o5y98600aze0 which don't conform to that uuidgen format; they were created by early versions of org. Should only UUIDs be accepted as ID? 2. I think the ID should be editable by hand to what you like, as long as they are unique. If you don't need to export it you don't need a CUSTOM_ID, and having both ID and CUSTOM_ID is not the simplest way. So I think that assert is too strict. My short IDs seem as good as the long UUIDs.
Re: [O] compilation issues of new export framework
Hi Nicolas,
an oddity occurs since the new exporter moved into core (I don't think I
had seen this before, so maybe you can relate to what is different now):
--8---cut here---start-8---
Compiling /lisp/org-mode/lisp/org.el...
Loading org-element...
Loading org-element...
Loading org-element...
Loading org-element...
Loading org-element...
Loading org-element...
Loading org-element...
Loading org-element...
Loading org-element...
Loading org-element...
Loading org-element...
Loading org-element...
Loading org-element...
Loading org-element...
Loading org-element...
Loading org-element...
Loading org-element...
Loading org-element...
Loading org-element...
--8---cut here---end---8---
This only happens when using byte-recompile-directory, which means
org-element has already been loaded in that session and is present as a
byte-compiled file. I haven't yet found where in org.el these loads are
triggered, but it seems that this might be related to macro expansion.
In any case, the resulting org.elc file therefore depends on the
compilation method, which is highly undesirable. I haven't been able to
analyse this further.
Another sticky point is your use of declare-function: some of these are
actually defsubst, not defun:
org-element-{contents,nested-p,element-property,put-property}
I don't think they will be inlined unless their definition has been
interned, declaration alone will not suffice. I don't see an easy way
to factor out those parts from org-element that are needed by org, but I
suggest that we should find one.
There are more errors when doing a make ORGCM=slint2 compile in the
last pass. These files are probably all just missing an
(eval-when-compile (require 'cl))
but I only checked ox-md.
--8---cut here---start-8---
Compiling single /lisp/org-mode/lisp/ox-beamer.el...
In end of data:
ox-beamer.el:1250:1:Warning: the following functions are not known to be
defined: case, action, defaction, option, otherwise, headline, target
Wrote /lisp/org-mode/lisp/ox-beamer.elc
Compiling single /lisp/org-mode/lisp/ox-icalendar.el...
In org-icalendar-entry:
ox-icalendar.el:504:44:Warning: `(quote t)' is a malformed function
ox-icalendar.el:504:44:Warning: `(quote t)' is a malformed function
ox-icalendar.el:504:44:Warning: `(quote t)' is a malformed function
In end of data:
ox-icalendar.el:974:1:Warning: the following functions are not known to be
defined: case, category, todo-state, local-tags, all-tags, incf, all,
unblocked, hour, day, week, month, year
Wrote /lisp/org-mode/lisp/ox-icalendar.elc
Compiling single /lisp/org-mode/lisp/ox-jsinfo.el...
In end of data:
ox-jsinfo.el:261:1:Warning: the following functions are not known to be
defined: case, path, sdepth, tdepth, otherwise
Compiling single /lisp/org-mode/lisp/ox-md.el...
In end of data:
ox-md.el:494:1:Warning: the following functions are not known to be defined:
case, on, trans, off
--8---cut here---end---8---
Regards,
Achim.
--
+[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]+
Wavetables for the Terratec KOMPLEXER:
http://Synth.Stromeko.net/Downloads.html#KomplexerWaves
[O] freeplane exporter too?
hey guys, would the new freemind exporter be able to handle files created with freeplane, or would there have to be a freeplane exporter too? Freeplane files and Freemind files are similar, but not the same. Just something to consider... -- -tom
[O] Highlighting LaTeX fragments
Hi,
I was quite fond of org-highlight-latex-fragments-and-specials which
was recently removed ¹. I'm sure there were good reasons for removing
it.
Basically stuff like α would be displayed with a special face.
Likewise,
\begin{equation}
X
\end{equation}
would be highlighted.
Does anybody have a good idea on how to replicate this?
Thanks,
Rasmus
Footnotes:
¹
http://orgmode.org/w/org-mode.git?p=org-mode.git;a=commit;h=a2f56264c918b679b53c5b7df0ef2e01a77c63d4
--
C is for Cookie
Re: [O] org-caldav problem: void-function url-http-options
David Engster d...@randomsample.de writes: Julien Cubizolles writes: Since a few days (maybe an emacs update) I get this error message whenever I run org-caldav-sync. Debugger entered--Lisp error: (void-function url-http-options) I've been digging around a bit and url-http-options is defined in url-http.el which is present on my system (/usr/share/emacs/24.3.50/lisp/url/url-http.el.gz) so I don't understand why it isn't found (assuming that void-function message actually means it can't find the definition of the function). Does doing a (require 'url-http) before calling org-caldav help? Yes it does, thanks, I should have thought of it. Why has it become necessary ? It seems that url-http-options is called by url-dav-supported-p, defined in url-dav.el. Shouldn't url-dav.el require url-http.el ? Julien.
Re: [O] compilation issues of new export framework
Hello,
Achim Gratz strom...@nexgo.de writes:
an oddity occurs since the new exporter moved into core (I don't think I
had seen this before, so maybe you can relate to what is different now):
Compiling /lisp/org-mode/lisp/org.el...
Loading org-element...
Loading org-element...
Loading org-element...
Loading org-element...
Loading org-element...
Loading org-element...
Loading org-element...
Loading org-element...
Loading org-element...
Loading org-element...
Loading org-element...
Loading org-element...
Loading org-element...
Loading org-element...
Loading org-element...
Loading org-element...
Loading org-element...
Loading org-element...
Loading org-element...
Yes, I noticed this one too, but I don't know yet from where it could
come from.
This only happens when using byte-recompile-directory, which means
org-element has already been loaded in that session and is present as a
byte-compiled file. I haven't yet found where in org.el these loads are
triggered, but it seems that this might be related to macro expansion.
In any case, the resulting org.elc file therefore depends on the
compilation method, which is highly undesirable. I haven't been able to
analyse this further.
Another sticky point is your use of declare-function: some of these are
actually defsubst, not defun:
org-element-{contents,nested-p,element-property,put-property}
I don't think they will be inlined unless their definition has been
interned, declaration alone will not suffice.
I don't know either how inline functions behave in this situation.
I don't see an easy way to factor out those parts from org-element
that are needed by org, but I suggest that we should find one.
It is always possible to make them regular functions. Some profiling may
be necessary, though.
There are more errors when doing a make ORGCM=slint2 compile in the
last pass. These files are probably all just missing an
(eval-when-compile (require 'cl))
but I only checked ox-md.
Indeed. Fixed. Thank you.
Regards,
--
Nicolas Goaziou
Re: [O] compilation issues of new export framework
Nicolas Goaziou writes: Yes, I noticed this one too, but I don't know yet from where it could come from. Hmm. If you don't know, then this is even more worrysome. Can't spend more time on this now, unfortunately. Regards, Achim. -- +[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]+ Waldorf MIDI Implementation additional documentation: http://Synth.Stromeko.net/Downloads.html#WaldorfDocs
Re: [O] Highlighting LaTeX fragments
Hello,
Rasmus ras...@gmx.us writes:
Basically stuff like α would be displayed with a special face.
It's still the case. This part is done by `org-fontify-entities'
(toggled by `org-pretty-entities').
Likewise,
\begin{equation}
X
\end{equation}
would be highlighted.
Does anybody have a good idea on how to replicate this?
Maybe rewrite a similar function with all references to the export
sub-system removed. Also make sure it doesn't overlap with existing
facilities.
Fontifying a latex environment is perfectly fine, but fontifying it only
if some export option has been defined somewhere is a bit too much.
To begin with, it should be useful to know what is missing exactly.
Regards,
--
Nicolas Goaziou
Re: [O] [ANN] Merge of new export framework on Wednesday
On Sat, Feb 9, 2013 at 1:56 PM, Nicolas Goaziou n.goaz...@gmail.com wrote:
Hello,
Sean O'Halpin sean.ohal...@gmail.com writes:
This raises another question which is more about Org document export
headers in general: why do we have specific document headers for LaTeX
and HTML? Because we need to able to insert raw markup at specific
points in the exported document. (We also have =html-preamble= and
=html-postamble= which act on every document.) But what about other
exporter back-ends? Say we get a native org to docbook exporter. What
would be the mechanism for inserting markup into the =artheader=?
Would there be a =#+DOCBOOK_HEADER=?
Please forgive my meandering here. It's just struck me that we might
need a more general mechanism for document-level export directives
that will avoid multiplying the number of =#+HTML_= style directives
we already have. Perhaps something along the lines of:
#+BEGIN_SRC ORG
,#+EXPORT html head style .../
,#+EXPORT latex header \usepackage{xyz}
#+END_SRC
where =head= and =header= represent specific places in the exported
document that the exporter in question has defined as places you can
insert raw markup. So, Org would define the =#+EXPORT= protocol,
specific back-ends would define the names and places.
Not every back-end has a concept of head (think about Markdown
back-end). We don't need a general concept for something that isn't
general.
I haven't made myself clear. I'm not suggesting a general concept of
head. What I am suggesting is that the back-ends handle these
back-end specific concepts themselves, rather than add more buffer
keywords for every new exporter. The general concept is that we want
to communicate document level information to the back-end, in this
case, bits of text to insert at specific places which are dependent on
the specific back-end in question.
Also, completely unifying every back-end is close to impossible, unless
the same person writes every back-end[1]. Most of the options are
shared, that's the goal of ox.el, but in the end, each back-end decides
how it handles the others.
This would not require unifying every back-end at all. In fact, quite
the opposite. All you would need would be for the generic exporter
framework to provide the back-end a dictionary of key value pairs,
such as ((:head script.../) ...), which the back-end would
interpret. You would avoid having to add document level keywords such
as HTML_STYLE and MAN_CLASS_OPTIONS for new exporters. It would be the
back-end's responsibility to validate and document these options. My
suggestion is really not so different from what the new exporter does
anyway. Where we now have =#+HTML_LINK_UP: ...=, I'm suggesting we
have =#+EXPORT: html link-up ...=.
Perhaps I'm just expressing a preference for fewer buffer-level
keywords - feel free to ignore the suggestion.
Regards,
Sean
Re: [O] Still Wishing for Snooze
Hi, Michael Brand michael.ch.br...@gmail.com writes: The usefulness of a SCHEDULED delay I see together with a TODO and repeater to implement an _exception_ (to simplify: exception just for the first date, before the repetitions). For example SCHEDULED: 2013-02-01 Fri +1w -3d would mean: Usually start working on the entry earliest on the first day of the month except [2013-02-01 Fri] when work can not start before [2013-02-04 Mon]. It would start to show in the agenda on [2013-02-04 Mon], [2013-03-01 Fri], [2013-04-01 Mon], [2013-05-01 Wed], [2013-06-01 Sat] etc. On let’s say [2013-02-05 Tue] it would be set to DONE and would change to: SCHEDULED: 2013-03-01 Fri +1w Note the automatically removed delay. Am I missing something? I quite agree with you. It is also the way I understood it, with the automatic removal of the -3d. Only a tiny glitch there, I suppose you guessed it was written SCHEDULED: 2013-02-01 Fri +1m -3d and not SCHEDULED: 2013-02-01 Fri +1w -3d Because your description is about a monthly repeated event while the example shows a weekly event. It is really nothing but I think someone might find it confusing. -- Konubinix GPG Key: 7439106A Fingerprint: 5993 BE7A DA65 E2D9 06CE 5C36 75D2 3CED 7439 106A pgphC_SaB0cC7.pgp Description: PGP signature
Re: [O] org-caldav problem: void-function url-http-options
Julien Cubizolles writes: David Engster d...@randomsample.de writes: Julien Cubizolles writes: Since a few days (maybe an emacs update) I get this error message whenever I run org-caldav-sync. Debugger entered--Lisp error: (void-function url-http-options) I've been digging around a bit and url-http-options is defined in url-http.el which is present on my system (/usr/share/emacs/24.3.50/lisp/url/url-http.el.gz) so I don't understand why it isn't found (assuming that void-function message actually means it can't find the definition of the function). Does doing a (require 'url-http) before calling org-caldav help? Yes it does, thanks, I should have thought of it. Why has it become necessary ? This change here is responsible: revno: 110337 committer: Stefan Monnier monn...@iro.umontreal.ca branch nick: trunk timestamp: Mon 2012-10-01 23:48:01 -0400 message: * lisp/url/url-http.el (url-http-user-agent-string): Leak less info. (url-http, url-http-file-exists-p, url-http-file-readable-p) (url-http-file-attributes, url-http-options, url-https-default-port) (url-https-asynchronous-p): Don't autoload. It seems that url-http-options is called by url-dav-supported-p, defined in url-dav.el. Shouldn't url-dav.el require url-http.el ? Yes, it should. Could you file a bug report about this? -David
Re: [O] Bug? in texinfo exporter
Hello,
t...@tsdye.com (Thomas S. Dye) writes:
The following text:
LaTeX math snippets (see [[LaTeX fragments]])
is being exported to texinfo like this:
@LaTeX{} math snippets (see @ref{@LaTeX{} fragments,})
^
I think the marked comma is giving makeinfo a heartache. Makeinfo tells me:
/Users/dk/org/orgmanual//orgmanual.texi:11726: Cross reference to
nonexistent node `@LaTeX{} fragments' (perhaps incorrect sectioning?).
Help?
It should be fixed in master. Could you confirm it?
Thank you for reporting this.
Regards,
--
Nicolas Goaziou
Re: [O] Highlighting LaTeX fragments
Nicolas Goaziou n.goaz...@gmail.com writes: Basically stuff like α would be displayed with a special face. It's still the case. This part is done by `org-fontify-entities' (toggled by `org-pretty-entities'). This just turns \alpha into α. It does not give it a special color (on my system at least). Maybe rewrite a similar function with all references to the export sub-system removed. Also make sure it doesn't overlap with existing facilities. Would the best way to go about it be using regexps? To begin with, it should be useful to know what is missing exactly. Colors. E.g. it used to be that if an equation was too long to be supported by $-signs it would go from brown (on my system) to the normal black, giving visual feedback as to whether \(·\) should be used. Also, it made it quicker to distinguish inline math from text (also display math but this can be replaced by babel blocks). –Rasmus -- . . . The proofs are technical in nature and provides no real understanding.
Re: [O] How to pass a block of text to a code block as data?
On Sat, Feb 9, 2013 at 2:59 AM, Michael Baum maab...@gmail.com wrote:
- What signals the end of the block of text to be used as data? I take it
that it's important that these all be comment lines staring with a colon
after the #+name label? Is there a way to do the same thing with a begin and
end block construction?
- In this line:
#+begin_src sh :stdin lines-of-text :results output
does the flag :stdin mean that the following named block literally becomes
the STDIN stream for the code block? If I replace your shell/grep example
with this:
#+begin_src perl :stdin lines-of-text :results output
while () {
print $_;
}
#+end_src
...it doesn't work, although as far as I know that perl code snippet should
in fact simply print out the incoming lines from stdin.
Thanks again,
Michael
Hi,
The :stdin option is only defined for shell and awk AFAIK. (Might be
an idea to add to other languages..)
You can pass in a variable referring to the block of text, as shown
below (example for ruby but should work for perl):
#+begin_src org
#+name: more-lines-of-text
#+begin_example
What signals the end of the block of text to be used as data? I take
it that it's important that these all be comment lines staring with a
colon after the #+name label? Is there a way to do the same thing with
a begin and end block construction?
#+end_example
#+begin_src ruby :var lines=more-lines-of-text :results output
puts lines.reverse
#+end_src
#+RESULTS:
: ?noitcurtsnoc kcolb dne dna nigeb a
: htiw gniht emas eht od ot yaw a ereht sI ?lebal eman+# eht retfa noloc
: a htiw gnirats senil tnemmoc eb lla eseht taht tnatropmi s'ti taht ti
: ekat I ?atad sa desu eb ot txet fo kcolb eht fo dne eht slangis tahW
#+end_src
Regards,
Sean
Re: [O] [ANN] Merge of new export framework on Wednesday
Sean O'Halpin sean.ohal...@gmail.com writes: I haven't made myself clear. I'm not suggesting a general concept of head. What I am suggesting is that the back-ends handle these back-end specific concepts themselves, rather than add more buffer keywords for every new exporter. Each back-end adds its own keywords, define them, document them and interpret them. So, basically, backends handle these concept themselves, don't they? This would not require unifying every back-end at all. In fact, quite the opposite. All you would need would be for the generic exporter framework to provide the back-end a dictionary of key value pairs, such as ((:head script.../) ...), which the back-end would interpret. This is exactly what is happening. You would avoid having to add document level keywords such as HTML_STYLE and MAN_CLASS_OPTIONS for new exporters. It would be the back-end's responsibility to validate and document these options. My suggestion is really not so different from what the new exporter does anyway. Where we now have =#+HTML_LINK_UP: ...=, I'm suggesting we have =#+EXPORT: html link-up ...=. Honestly, besides the syntax, I don't see any difference. Regards, -- Nicolas Goaziou
Re: [O] navigating between non-code blocks?
Bill White bi...@wolfram.com writes: C-c C-F (`org-next-block') C-c C-B (`org-previous-block') And, echoing Sebastien, `F' and `B' as speed commands would be very handy. Bastien b...@altern.org writes: Of course, I just push this change. Done! Hi, all. Quickly seeing this exchange, and realizing I do not understand what speed commands are, I decided to search for the expression in the Org manual, and did not find it. (This is after a git pull, done earlier today.) Should I seek the concept under some other name? Within Emacs, `C-c C-f' is bound to org-next-block, while the manual, in the Motion node, says that `C-c C-f' is bound to org-forward-same-level. As for `C-c C-F' (really `C-c C-S-f'), it does not seem to be bound and fall back on `C-c C-f'. So, I'm a bit lost :-). Which is not a problem to me, as I was merely curious. Franĉois
Re: [O] Still Wishing for Snooze
Hi Samuel On Sat, Feb 9, 2013 at 7:06 PM, Samuel Loury konubi...@gmail.com wrote: [...] I quite agree with you. It is also the way I understood it, with the automatic removal of the -3d. Only a tiny glitch there, I suppose you guessed it was written SCHEDULED: 2013-02-01 Fri +1m -3d and not SCHEDULED: 2013-02-01 Fri +1w -3d [...] Yes, my bad... Thanks for pointing out. Michael
Re: [O] [ANN] Merge of new export framework on Wednesday
Nicolas Goaziou n.goaz...@gmail.com writes: Sean O'Halpin sean.ohal...@gmail.com writes: You would avoid having to add document level keywords such as HTML_STYLE and MAN_CLASS_OPTIONS for new exporters. It would be the back-end's responsibility to validate and document these options. My suggestion is really not so different from what the new exporter does anyway. Where we now have =#+HTML_LINK_UP: ...=, I'm suggesting we have =#+EXPORT: html link-up ...=. Honestly, besides the syntax, I don't see any difference. IIUC, the difference is that #+HTML_LINK_UP and friends are all direct children of the document in the former case, and in the latter case all exporter-related options are grouped. An intermediate solution would be to group all options specific to one backend in #+EXPORT_backend (and in this case, there could be a generic #+EXPORT: that could be used by every backend). OTOH, most #+keywords statements are meant for the exporter (there are exceptions) anyway, so this might sound like premature or over-generalization. I didn't read the whole thread and do not actually export very often so might have completely missed the point. -- Nico.
Re: [O] navigating between non-code blocks?
Hi François, François Pinard wrote: Bill White bi...@wolfram.com writes: C-c C-F (`org-next-block') C-c C-B (`org-previous-block') And, echoing Sebastien, `F' and `B' as speed commands would be very handy. Bastien b...@altern.org writes: Of course, I just push this change. Done! Hi, all. Quickly seeing this exchange, and realizing I do not understand what speed commands are, I decided to search for the expression in the Org manual, and did not find it. (This is after a git pull, done earlier today.) Should I seek the concept under some other name? Yes, my bad; I should have said speed keys. See the following: ;;** 15.3 (info (org)Speed keys) Well, you know that since 25 Sep 2012 22:31; I remember an exchange on that with you: see http://comments.gmane.org/gmane.emacs.orgmode/60873. Within Emacs, `C-c C-f' is bound to org-next-block, while the manual, in the Motion node, says that `C-c C-f' is bound to org-forward-same-level. As for `C-c C-F' (really `C-c C-S-f'), it does not seem to be bound and fall back on `C-c C-f'. I'll test, and report. Best regards, Seb -- Sebastien Vauban
Re: [O] ocaml babel no longer works?
Alan Schmitt alan.schm...@polytechnique.org writes: Alan Schmitt writes: Hello, I recently updated org-mode (from git), and ocaml source code is no longer recognized. If I have a very simple file, like this: #+BEGIN_SRC ocaml let x = 2 in x #+END_SRC I don't get syntax highlighting, and trying to evaluate it result in an error: Evaluate this ocaml code block on your system? (y or n) y executing Ocaml code block... face-spec-choose: Wrong type argument: listp, class I have found the problem: I was missing a new line at the end of the #+END_SRC. Unfortunately the evaluation of the code does not work with recent tuareg. I first had to add: (defalias 'tuareg-run-caml 'tuareg-run-ocaml) to my configuration file. Hey Alan, Thanks for looking into this. I've applied a patch to ob-ocaml.el which should handle the two different tuareg execution functions. But even with this it gets stuck saying executing Ocaml code block... until I ctrl-G it. I'll try to see what is happening. Any suggestion as how to debug this? I would recommend evaluating first org-babel-execute:ocaml then possibly org-babel-prep-session:ocaml in edebug mode. This can be done by running `eval-defun' on these functions with a prefix argument, or equivalently doing M-: (eval-defun t). I would guess this is due to a change in tuareg mode. -- Eric Schulte http://cs.unm.edu/~eschulte
Re: [O] navigating between non-code blocks?
Hi François, Sebastien Vauban wrote: François Pinard wrote: Bastien b...@altern.org writes: Bill White bi...@wolfram.com writes: C-c C-F (`org-next-block') C-c C-B (`org-previous-block') And, echoing Sebastien, `F' and `B' as speed commands would be very handy. Of course, I just push this change. Done! Within Emacs, `C-c C-f' is bound to org-next-block, while the manual, in the Motion node, says that `C-c C-f' is bound to org-forward-same-level. As for `C-c C-F' (really `C-c C-S-f'), it does not seem to be bound and fall back on `C-c C-f'. I'll test, and report. Indeed... ╭ C-h k C-c C-S-f │ │ C-c C-f (translated from C-c C-S-f) runs the command org-next-block, which is │ an interactive Lisp function in `org.el'. │ │ It is bound to C-c C-f. │ │ (org-next-block ARG optional BACKWARD BLOCK-REGEXP) │ │ Jump to the next block. ╰ and ╭ C-h k C-c C-f │ │ C-c C-f runs the command org-next-block, which is an interactive Lisp function │ in `org.el'. │ │ It is bound to C-c C-f. │ │ (org-next-block ARG optional BACKWARD BLOCK-REGEXP) │ │ Jump to the next block. ╰ So, C-c C-F does work on code blocks, but for a bad reason (C-c C-f, instead). And, don't know why, but the speed key `F' is not working for me, on a freshly pulled Org: Org-mode version 7.9.3e (7.9.3e-965-g16118a @ d:/Users/fni/Public/Repositories/org-mode/lisp/) Best regards, Seb -- Sebastien Vauban
Re: [O] ocaml babel no longer works?
Hi Eric, Eric Schulte wrote: Alan Schmitt alan.schm...@polytechnique.org writes: I have found the problem: I was missing a new line at the end of the #+END_SRC. Unfortunately the evaluation of the code does not work with recent tuareg. I first had to add: (defalias 'tuareg-run-caml 'tuareg-run-ocaml) to my configuration file. But even with this it gets stuck saying executing Ocaml code block... until I ctrl-G it. I'll try to see what is happening. Any suggestion as how to debug this? I would recommend evaluating first org-babel-execute:ocaml then possibly org-babel-prep-session:ocaml in edebug mode. This can be done by running `eval-defun' on these functions with a prefix argument, or equivalently doing M-: (eval-defun t). Or, even shorted, C-u C-M-x with point somewhere in the defun. Best regards, Seb -- Sebastien Vauban
[O] make update failures
Aloha all, I just got around to 'make update', the first one in about a week. It usually runs smoothly, but now it doesn't. In toplevel form: ox.el:80:1:Error: Symbol's value as variable is void: org-ts-regexp Done (Total of 9 files compiled, 101 failed, 3 skipped) Scrolling through the many errors, all appear to complain about org-ts-regexp. Did I miss a step? 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] Fwd: Re: Bug? in texinfo exporter
-- Forwarded message --
From: Jonathan Leech-Pepin jonathan.leechpe...@gmail.com
Date: Feb 9, 2013 8:57 AM
Subject: Re: [O] Bug? in texinfo exporter
To: Thomas S. Dye t...@tsdye.com
Cc:
Just realized I hit reply not reply-all
If Nick's fix fixes it do much the better.com but I'm pretty sure the comma
isn't the culprit.
Regards,
Hello Tom,
On Feb 8, 2013 10:11 PM, Thomas S. Dye t...@tsdye.com wrote:
Aloha all,
The following text:
LaTeX math snippets (see [[LaTeX fragments]])
is being exported to texinfo like this:
@LaTeX{} math snippets (see @ref{@LaTeX{} fragments,})
^
I think the marked comma is giving makeinfo a heartache. Makeinfo
tells me:
The issue is more likely that it is escaping LaTeX within the reference
while the headline had it literally.
I'm not at a computer right now but I should be able to look into it and
hopefully fix it this week.
/Users/dk/org/orgmanual//orgmanual.texi:11726: Cross reference to
nonexistent node `@LaTeX{} fragments' (perhaps incorrect sectioning?).
Help?
All the best,
Tom
Regards,
Jon
--
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] make update failures
Hey Tom, I committed this problem this morning. I just pushed up a fix. Thanks for catching, t...@tsdye.com (Thomas S. Dye) writes: Aloha all, I just got around to 'make update', the first one in about a week. It usually runs smoothly, but now it doesn't. In toplevel form: ox.el:80:1:Error: Symbol's value as variable is void: org-ts-regexp Done (Total of 9 files compiled, 101 failed, 3 skipped) Scrolling through the many errors, all appear to complain about org-ts-regexp. Did I miss a step? All the best, Tom -- Eric Schulte http://cs.unm.edu/~eschulte
Re: [O] Highlighting LaTeX fragments
Rasmus ras...@gmx.us writes:
Nicolas Goaziou n.goaz...@gmail.com writes:
To begin with, it should be useful to know what is missing exactly.
Colors. E.g. it used to be that if an equation was too long to be
supported by $-signs it would go from brown (on my system) to the
normal black, giving visual feedback as to whether \(·\) should be
used.
Also, it made it quicker to distinguish inline math from text (also
display math but this can be replaced by babel blocks).
Would you mind testing the following patch? I don't like it much because
it's an all or nothing fontification. I think latex snippets, entities
and sub/superscript should be separated.
Anyway, does it replace the missing functionality?
Regards,
--
Nicolas Goaziou
From f0f165ef1b3a3e3d161da509cf0548171a6f68fb Mon Sep 17 00:00:00 2001
From: Nicolas Goaziou n.goaz...@gmail.com
Date: Sun, 10 Feb 2013 00:07:48 +0100
Subject: [PATCH] Fontify latex, entities and sub/superscript again
* lisp/org-faces.el (org-latex-and-special): Renamed from
`org-latex-and-export-specials', which wasn't appropriate anymore.
* lisp/org.el (org-highlight-latex-and-special,
org-latex-and-special-regexp): New variables.
(org-compute-latex-and-special-regexp, org-do-latex-and-special): New
function, revived from a previous commit.
(org-set-regexps-and-options, org-set-font-lock-defaults): Use new
functions.
---
lisp/org-faces.el | 2 +-
lisp/org.el | 47 +++
2 files changed, 48 insertions(+), 1 deletion(-)
diff --git a/lisp/org-faces.el b/lisp/org-faces.el
index de5a08c..a841ba3 100644
--- a/lisp/org-faces.el
+++ b/lisp/org-faces.el
@@ -765,7 +765,7 @@ level org-n-level-faces
:version 24.1
:type 'boolean)
-(defface org-latex-and-export-specials
+(defface org-latex-and-special
(let ((font (cond ((assq :inherit custom-face-attributes)
'(:inherit underline))
(t '(:underline t)
diff --git a/lisp/org.el b/lisp/org.el
index 2bfca4e..908fcb4 100644
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -3889,6 +3889,11 @@ org-level-* faces.
:group 'org-appearance
:type 'boolean)
+(defcustom org-highlight-latex-and-special nil
+ Non-nil means fontify LaTeX stuff, entities and sub/superscript.
+ :group 'org-appearance
+ :type 'boolean)
+
(defcustom org-hide-emphasis-markers nil
Non-nil mean font-lock should hide the emphasis marker characters.
:group 'org-appearance
@@ -4987,6 +4992,7 @@ but the stars and the body are.)
(mapcar (lambda (w) (substring w 0 -1))
(list org-scheduled-string org-deadline-string
org-clock-string org-closed-string)))
+ (org-compute-latex-and-special-regexp)
(org-set-font-lock-defaults
(defun org-file-contents (file optional noerror)
@@ -5837,9 +5843,49 @@ by a #.
(goto-char e)
t)))
+(defvar org-latex-and-special-regexp nil
+ Regular expression for highlighting LaTeX, entities and sub/superscript.)
(defvar org-match-substring-regexp)
(defvar org-match-substring-with-braces-regexp)
+(defun org-compute-latex-and-special-regexp ()
+ Compute regular expression for LaTeX stuff, entities and sub/superscript.
+ (org-set-local
+ 'org-latex-and-special-regexp
+ (if (not org-highlight-latex-and-special) nil
+ (let* ((re-sub
+ (cond ((eq org-use-sub-superscripts '{})
+ (list org-match-substring-with-braces-regexp))
+ (org-use-sub-superscripts
+ (list org-match-substring-regexp
+ (matchers (plist-get org-format-latex-options :matchers))
+(re-latex (delq nil
+ (mapcar (lambda (x)
+ (and (member (car x) matchers) (nth 1 x)))
+org-latex-regexps)))
+(re-macros (list \\(there4\\|sup[123]\\|frac[13][24]\\|[a-zA-Z]+\\)\\($\\|{}\\|[^[:alpha:]]\\
+ (mapconcat 'identity (append re-latex re-macros re-sub) \\|)
+
+(defun org-do-latex-and-special (limit)
+ Search down to LIMIT and fontify LaTeX snippets and entities.
+Fontification happens only if `org-latex-and-special-regexp' is
+non-nil.
+ (when org-latex-and-special-regexp
+(let (rtn d)
+ (while (and (not rtn)
+ (re-search-forward org-latex-and-special-regexp limit t))
+ (unless (memq (car-safe (get-text-property (1+ (match-beginning 0))
+ 'face))
+ '(org-code org-verbatim underline))
+ (setq
+ rtn t
+ d (if (memq (char-after (1+ (match-beginning 0))) '(?_ ?^)) 1 0))
+ (font-lock-prepend-text-property
+ (+ d (match-beginning 0)) (match-end 0) 'face 'org-latex-and-special)
+ (add-text-properties (+ d (match-beginning 0)) (match-end 0)
+ '(font-lock-multiline t
+ rtn)))
+
(defun org-restart-font-lock ()
Restart `font-lock-mode', to force refontification.
(when (and (boundp 'font-lock-mode) font-lock-mode)
@@ -6000,6 +6046,7 @@ needs to be inserted at a specific
Re: [O] make update failures
Eric Schulte schulte.e...@gmail.com writes: Hey Tom, I committed this problem this morning. I just pushed up a fix. Done (Total of 110 files compiled, 3 skipped) Thanks for the quick fix. All the best, Tom -- Thomas S. Dye http://www.tsdye.com
Re: [O] navigating between non-code blocks?
Sebastien Vauban wxhgmqzgwmuf-genee64ty+gs+fvcfc7...@public.gmane.org writes: ;;** 15.3 (info (org)Speed keys) OK, got it now. I tried =?= as per the documentation suggests, and there is a great deal there indeed. Well, you know that since 25 Sep 2012 22:31; I remember an exchange on that with you: see http://comments.gmane.org/gmane.emacs.orgmode/60873. You surely have a lot of method for (apparently) easily finding this message! Yes, I remember this, but did not get at the time that the SPC at the beginning of a header was not an isolated feature, but part of a greater scheme. Thanks for your patience. François
[O] [New exporter] custom emphasis in org-emphasis-alist
Cudos for all the work that has been done on migrating to the new exporter. I so welcome that exporting now is approaching a clean design! I am currently migrating my system and contribute my first stop: custom emphasis characters that I use extensively: - ! is used for exclamations, - ? for questions, and - # for in-text comments that I do not want exported. This is my org-emphasis-alist configuration: #+BEGIN_SRC emacs-lisp (setq org-emphasis-alist (quote ((* bold b /b) (/ italic i /i) (_ underline span style=\text-decoration:underline;\ /span) (= (:box t :foreground #AAF) code /code verbatim) (~ org-headline-done u /u verbatim) (+ (:strike-through t) del /del) (? gk-org-question span class=\org-question\ /span) (! gk-org-exclamation span class=\org-exclamation\ /span) (# font-lock-comment-face !-- -- #+END_SRC These emphases are currently not working . During debugging I found the following to be the reason: Though org-element-text-markup-successor recognizes emphasis by using org-emph-re, it returns only one of a set of hard-coded symbols (`bold', `italic', `underline', `strike-through', `code' and `verbatim'). IMHO org-element-text-markup-successor should recognize org-emphasis-alist. Maybe return the face configured in the cadr of the respective org-emphasis-alist element. However, the drawback would be that this would disenable quick-and-dirty face specification as with (:box t :foreground #AAF) above. On the other hand, I do not know how plans with org-emphasis-alist are, as caddr,... for html export and org-export-latex-emphasis-alist probably are obsolete with the new exporter. With the following setup, the following test case worked. However, changing deconsts and defuns in org-element surely is not a good approach. Do you have any suggestions? Thank you all for your amazing work on orgmode, Gregor * Test Case With these settings these work: the test *bold*, (invisible comment?!), and . But these still do not work: *bold*, (\leftarrow invisible comment?!), !exclamation! and ?question?. These examples stop working after the comment. : (org-export-to-file 'my-html test.html) * Changes I played around further by adding lines to org-element-text-markup-successor #+BEGIN_SRC emacs-lisp (defun org-element-text-markup-successor (limit) Search for the next text-markup object. LIMIT bounds the search. Return value is a cons cell whose CAR is a symbol among `bold', `italic', `underline', `strike-through', `code' and `verbatim' and CDR is beginning position. (save-excursion (unless (bolp) (backward-char)) (when (re-search-forward org-emph-re limit t) (let ((marker (match-string 3))) (cons (cond ((equal marker *) 'bold) ((equal marker /) 'italic) ((equal marker _) 'underline) ((equal marker +) 'strike-through) ((equal marker ~) 'code) ((equal marker =) 'verbatim) ((equal marker #) 'emph-comment) ((equal marker ?) 'emph-question) ((equal marker !) 'emph-exclamation) (t (error Unknown marker at %d (match-beginning 3 (match-beginning 2)) #+END_SRC and then trying to define org-element-emph-comment-parser copy-pasting org-element-italic-parser: #+BEGIN_SRC emacs-lisp (defun org-element-emph-comment-parser () Parse comment object at point. Return a list whose CAR is `italic' and CDR is a plist with `:begin', `:end', `:contents-begin' and `:contents-end' and `:post-blank' keywords. Assume point is at the first # marker. (save-excursion (unless (bolp) (backward-char 1)) (looking-at org-emph-re) (let ((begin (match-beginning 2)) (contents-begin (match-beginning 4)) (contents-end (match-end 4)) (post-blank (progn (goto-char (match-end 2)) (skip-chars-forward \t))) (end (point))) (list 'emph-comment (list :begin begin :end end :contents-begin contents-begin :contents-end contents-end :post-blank post-blank) (defun org-element-emph-comment-interpreter (italic contents) Interpret ITALIC object as Org syntax. CONTENTS is the contents of the object. (format #%s# contents)) (defun org-element-emph-exclamation-parser () Parse exclamation object at point. Return a list whose CAR is `italic' and CDR is a plist with `:begin', `:end', `:contents-begin' and `:contents-end' and `:post-blank' keywords. Assume point is at the first # marker. (save-excursion (unless (bolp) (backward-char 1)) (looking-at org-emph-re) (let ((begin (match-beginning 2))
Re: [O] [New exporter] custom emphasis in org-emphasis-alist
Gregor Kappler g.kapp...@gmx.net writes: Cudos for all the work that has been done on migrating to the new exporter. I so welcome that exporting now is approaching a clean design! Let me join my voice to the chorus! Munch congratulations, and thanks! There is an impressive amount of work in all this, it has been a major undertaking. I'm very glad to see that is now in the process of falling back into place in a definitive way. Very good news for us all! François
[O] bug#13668: 24.2.93; strike-through in org mode
Hi Roland, Roland Winkler wink...@gnu.org writes: visit the following org file with emacs -Q cat foo.org EOF * foo bar (+.2 to .5) baz (+.2 to .5) bar (+.2 to .5) baz +.2 to .5) EOF Why are part of the second and third line striked through? Because + tries to add fontification. According to the org info pages there is some regexp-based feature of that kind. Yes, see `org-emphasis-regexp-components'. But it appears to me that this feature could use a more sophisticated regexp matcher. Note that the 5th and 6th line are not striked through. Because the space isn't allowed within +...+ fontified constructs. Also, as an occassional org mode user without a need for very fancy things, I am wondering whether I can simply switch off such structural markup elements. (setq org-fontify-emphasized-text nil) The org info node on structural markup elements does not mention such a possibility. Mhh.. yes, I'll perhaps update the manual, or just add a Worg FAQ for this. I would prefer if, as a general strategy, the default values for such features were less aggressive. We try to not make them agressive. But the text you quoted above looks like an example that could be in fixed-with block like this : : bar (+.2 to .5) : baz (+.2 to .5) : bar (+.2 to .5) : baz +.2 to .5) or in another block where *...* constructs are not fontified. Thanks, -- Bastien
[O] how to indent plain lists in ASCII
The old exporter indented plain lists. This does not seem to fix it: (add-to-list 'org-export-filter-plain-list-functions (lambda (plain-list back-end rest _rest) (if (eq back-end 'ascii) (replace-regexp-in-string ^plain-list) plain-list)) I don't know what a communication channel is in a filter function, however. Thanks. -- The Kafka Pandemic: http://thekafkapandemic.blogspot.com The disease DOES progress. MANY people have died from it. ANYBODY can get it. There is no hope without action.
Re: [O] accessibility bug: export menu unusable
On 2/7/13, Nicolas Goaziou n.goaz...@gmail.com wrote: The new export window is unusable. It shows the second half of the menu. Out of curiosity, how did you make the previous export window usable under these conditions? It was 28-line high with no scrolling mechanism either. I don't remember whether the old exporter worked or not because I called the functions I needed directly. In the new exporter, I don't know what features it has or how to call them so I need the menu. Until then, you may want to set `org-export-dispatch-use-expert-ui' to a non-nil value, assuming you know which kind of export you want. I don't know what the options are. You can also remove back-ends you don't need from `org-export-backends', or hide them from the menu with `org-export-invisible-backends'. I will try this, but I don't think it will be sufficient. Thanks. Samuel -- The Kafka Pandemic: http://thekafkapandemic.blogspot.com The disease DOES progress. MANY people have died from it. ANYBODY can get it. There is no hope without action.
Re: [O] navigating between non-code blocks?
Hi François, François Pinard wrote: Sebastien Vauban writes: ;;** 15.3 (info (org)Speed keys) OK, got it now. I tried =?= as per the documentation suggests, and there is a great deal there indeed. As well, M-x org-speed-command-help... Hé, that's from here the fact I'm talking of speed commands. Maybe we could rename that one to speed keys... Well, you know that since 25 Sep 2012 22:31; I remember an exchange on that with you: see http://comments.gmane.org/gmane.emacs.orgmode/60873. You surely have a lot of method for (apparently) easily finding this message! Yes, I remember this, but did not get at the time that the SPC at the beginning of a header was not an isolated feature, but part of a greater scheme. Just Google with our names, org-mode and speed... Thanks for your patience. You're very welcome! Best regards, Seb -- Sebastien Vauban
