[O] Exporting html: any way to customize format h1 class="title"?
I greatly appreciate the new export backends (thanks Nicolas!). The filter functions are fantastic. One thing that I'm having difficulty finding, however, is some way to modify the content of the and headings in the html. The function org-html-template hard-codes the formatting of the title: ,[ox-html.el [lines 1864-1865] |(let ((title (plist-get info :title))) | (format "%s\n" (org-export-data (or title "") info))) ` AFAICT, there is no filter that would enable one to bypass the tag her or to give it different text than the tag. The reason I ask is because I would like to omit the h1 header on the home page of my website or to give it different text than that given to . Since my site will display a banner with my name at the top of all pages, I would prefer to avoid the redundancy of "Name" or a pedantic "Home" at the top the home page.[fn:1] On other pages, it would also be nice to be able to give different text to the and tags. For instance, many sites append the site name to the page title in the tag. In the old export backends there were hooks that allowed some small modifications on the html after exporting it However, the two hooks of the new export backend hooks (org-export-before-processing-hook, org-export-before-parsing-hook) are called on copies of the org source. Are there any clever means that I've missed to modify the title tags? Thanks, Matt Footnotes: [fn:1] I know I can hide h1.title it with "display:none;" in the CSS, but I'd prefer not to do so, since it seems that hiding a major element can seem spammy to search engines. And now that I notice it, the org-mode site uses "display: none" in its css file to hide h1.title on all pages. Wouldn't it be easier to have an option in ox-html.el to omit the tag from the exported file?
Re: [O] org-contact Export
Esben Stien writes: Hello Esben, > Is there any way to retrieve a single org-contact as CSV or maybe a VCF > file? > > I know I can export all of them, but is there a function to get just the > one under point? It wasn't possible, but it is now. I've slightly modified `org-contacts-export-as-vcard' so that it will prompt for a user name when called with a prefix argument. The new function's behovior when called interactively is the following: 1. no prefix : do as before, export all contacts to `org-contacts-vcard-file'. 2. C-u : prompt for a contact name and use the contact at point if it exists, then export the matching contacts to `org-contacts-vcard-file'. 3. C-u C-u : same as 2. but prompt for a file name where to export instead of `org-contacts-vcard-file'. 4. C-u C-u C-u : same as 3. but prompt for a buffer name instead of a file name. When the function isn't called interactively it behaves as it did before. WDYT? Best, -- Daimrod/Greg
Re: [O] how to enter ==
You should use Org-mode Symbols.
~\ equal~ (without space hehind ~\~). If you have string behind it, you
should append ~{}~, like this: ~\ equal{}test~ (without space too).
Rustom Mody writes:
> If I enter code inline that has an == that is taken as an escape for code
> So how to enter '==' literally
[O] Setup Org-mode to write diary.
I want to know how to configure Org-mode to write diary with a easy way. I hope someone can provide his way. Here is what I think what Org-mode write diary should have. - [ ] *open/create* a buffer to write current day's diary quickly. - [ ] *navigate* diary entry like viewing day entries in Calendar. - [ ] *manage* diary files with some kind of style like (date, folder, etc). - [ ] *search* diary content. If you have some hints, welcome to tell me, thanks in advance.
[O] org-contact Export
Is there any way to retrieve a single org-contact as CSV or maybe a VCF file? I know I can export all of them, but is there a function to get just the one under point? -- Esben Stien is b0ef@e s a http://www. s tn m irc://irc. b - i . e/%23contact sip:b0ef@ e e jid:b0ef@n n
Re: [O] A gentle introduction to Emacs & Org-mode?
Marcin Borkowski writes: > Hi list, > > this is only partially Org-ode related, but I hope I'll be excused. > A friend of mine uses Scrivener; he also does some simple > JavaScript/jQuery programming and HTML/CSS editing. He *is* interested > in Emacs & Org-mode, but does not want to spend more than, say, 2 days > on installing, configuring and learning basics of E&Om. Are there any > resources which might help? I offered him some help with installing > and teaching, but what could I use? (Of course, the built-in tutorial > and Sacha Chua's sketch-tutorials are great, but what else does there > exist? Also, is prelude or Emacs Starter Kit a good idea? I > understand this is opinion-based, but maybe someone has some experience > *teaching* Emacs and Org-mode?) > > Best, Hi Marcin, I don't have much specifically to offer here as I'm a fairly new emacser, but I did switch to Org-mode directly from Scrivener. It took awhile, especially getting used to the keybindings as I simultaneously tried to understand various other packages that seemed useful (especially version control through magit). I love those bindings and packages now, however, and wouldn't go back. The simplicity and speed of the keyboard-oriented interface has considerably sped my workflow, especially in dealing with large projects, and even helped my arthritis a little ... :) As a last note, I do think it would take more than 2 days to get a proper sense of the pros and cons. I had a kind of insane glee over emacs that got me through the first month or so. Good luck to your friend! -steven
Re: [O] Possible to use src block to generate org headlines for export?
Nicolas Goaziou writes: > Andreas Leha writes: > >> But then, I do not understand your statement 'headlines are the only >> limitation to raw+replace behaviour'. >> >> This code block does not seem to respect 'raw+replace' for me: >> >> #+name: dtrn >> #+BEGIN_SRC R :results raw replace >> nwords <- 500 >> nletters <- sapply(1:nwords, function(i) sample(1:10, 1)) >> words <- sapply(nletters, function(i) paste(sample(letters, i), >> collapse="")) >> words[sample(nwords, 100)] <- "\n" >> paste(words, collapse=" ") >> #+END_SRC > > That was not clear, indeed. > > "raw" behaviour is only "useful" (i.e., mandatory) when you want to > insert a headline (or a drawer) as a result of a code block evaluation. > But then, you lose the ability to replace results. That's the limitation > I'm talking about. > > In any other case, "drawer+replace" is the superior choice. Thanks for this clarification. But in that case let me return to and refine my proposal: Why not have "drawer" as the default unless "raw" is given? One could argue, that the extent of the results is implicitly given when the results are not "raw", but being explicit here would allow for some additional features (such as different background for results -- is anyone doing this? I'd be interested). One could also argue, that the users are free to put their results in drawers if they wish. But on the other hand what would be lost by defaulting to drawers? < main part ends here Having said all that, I want to add, that I do not particularly like the visual appearance of drawers for results blocks; I think they - add one more line than necessary and they - differ too much from the appearance of source blocks This is the state in org This is what I'd prefer... --8<--start>8--- --8<--start>8--- #+PROPERTY: results drawer #+PROPERTY: results drawer * Test * Test #+name: dtrn #+name: dtrn #+begin_src R :exports both#+begin_src R :exports both "hello""hello" #+end_src #+end_src #+results: dtrn :RESULTS: #+begin_results dtrn hello hello :END: #+end_results --8<---end->8--- --8<---end->8--- But do not take this too seriously. I am more than happy to live with the standard appearance of drawers here. Regards, Andreas
Re: [O] c-c ' strips final newline or adds blank line, but never neither
[this is why i mentioned the blank lines. both settings of this variable fail. one adds blank lines and the other removes the final newline.] On 7/25/14, Thorsten Jolitz wrote: > ,[ C-h v org-src-strip-leading-and-trailing-blank-lines RET ]
Re: [O] c-c ' strips final newline or adds blank line, but never neither
hi thorsten, did you try it? samuel On 7/25/14, Thorsten Jolitz wrote: > Samuel Wales writes: > >> i find that when i do c-c ' on a source block, it either strips the >> final newline in the editing buffer or adds an unwanted blank line in >> the source block. >> >> i like to have final newlines in all of my buffers, including editing >> buffers. what setting allows this without introducing a blank line at >> the end of a source block? > > ,[ C-h v org-src-strip-leading-and-trailing-blank-lines RET ] > | org-src-strip-leading-and-trailing-blank-lines is a variable defined > | in `org-src.el'. Its value is nil > | > | Documentation: > | If non-nil, blank lines are removed when exiting the code edit buffer. > ` > > -- > cheers, > Thorsten > > > -- The Kafka Pandemic: http://thekafkapandemic.blogspot.com The disease DOES progress. MANY people have died from it. And ANYBODY can get it. Denmark: free Karina Hansen NOW.
Re: [O] File name with space
Chris Henderson writes: > How do I link a local file or folder that has space? Looks like the link goes > broken. > > e.g. file+sys:///Users/chris/projects/marketing plan for 2014 <-- doesn't > work. > > I tried: > > file+sys:///Users/chris/projects/marketing\ plan\ for\ 2014 <-- which also > doesn't work. file+sys:///Users/chris/projects/marketing%20plan%20for%202014 should work at least in the buffer and HTML export. Nick
[O] bug#18104: 24.3.92.1; Infloop when capturing Org note
PS perhaps this is related to your earlier http://debbugs.gnu.org/cgi/bugreport.cgi?bug=17651 Both seem to involve the cache.
[O] bug#18104: 24.3.92.1; Infloop when capturing Org note
Experience shows that issues with Org are best reported to the Org list. I have reassigned the bug accordingly.
[O] File name with space
How do I link a local file or folder that has space? Looks like the link goes broken. e.g. file+sys:///Users/chris/projects/marketing plan for 2014 <-- doesn't work. I tried: file+sys:///Users/chris/projects/marketing\ plan\ for\ 2014 <-- which also doesn't work.
Re: [O] Bug: wrong interpretation of LaTeX [8.2.6 (8.2.6-47-ge3d2c1-elpa @ c:/Users/beffa/.emacs.d/elpa/org-20140526/)]
Of course \[ 1+1 \] is valid LaTeX syntax, just as inline
\begin{displaymath} 1+1 \end{displaymath} is valid. In LaTeX you can
also separate paragraphs with \par without using any empty line, but
that's not very readable and in practice this method is only used
when constructing macros.
My point is that the two forms have identical meaning in LaTeX, but
they are represented differently in org-mode.
In my opinion a construct which will be displayed on a line by itself
and with some space separating it from the preceding and the following
text lines such as "\[ ... \]" would be better represented as a
latex-environment and not an inline latex-fragment. In this way the
org-mode text representation with proper fill-paragraph handling would
be much more readable and consistent with the meaning of the syntax
that it borrowed.
Regards,
Fede
On Fri, Jul 25, 2014 at 8:32 PM, Nicolas Goaziou wrote:
> Hello,
>
> Federico Beffa writes:
>
>> According to the LaTeX manual and reference "LaTeX: A Document
>> Preparation System", L. Lamport, \[ ... \] is a short form for a
>> displaymath environment. Citing the reference:
>> "... Because displayed equations are used so frequently in
>> mathematics, LaTeX allows you to type \[ ... \] instead of
>> \begin{displaymath} ... \end{displaymath}. ..."
>>
>> However, org-mode classify \[ ... \] as a latex-fragment, the same as
>> \(...\). The two are however very different in LaTeX because, while
>> the latter displays some mathematical expression *inline*, the former
>> makes its content stand out by putting it on *its own line*.
>
> AFAIK, LaTeX allows to inline "\[...\]" constructs, so something like
>
> Some \[1+1\] text
>
> is perfectly valid. Thus, I think we need to support them.
>
> The other thing to consider is that having the same syntax for an inline
> and a non-inline element could introduce some bugs (e.g. when filling
> a paragraph).
>
> OTOH, allowing inline \[...\] is pretty harmless.
>
>> What I do not like about this is that "org-fill-paragraph" considers
>> the \[ ...\] environment part of a paragraph and therefore the
>> environment gets "lost" in the middle of a line.
>
> This is a minor annoyance, indeed. However, you can use the verbose form
> in this case (i.e., "\begin{displaymath}").
>
>
> Regards,
>
> --
> Nicolas Goaziou
[O] [RFC] Deprecate `org-list-empty-line-terminates-plain-lists'
Hello, `org-list-empty-line-terminates-plain-lists' is an old variable (formely known as `org-empty-line-terminates-plain-lists) which doesn't make much sense nowadays. Indeed, since "org-list.el" revamp (around Org 7.0.1 IIRC), inserting two blank lines in a row terminates a list anyway. This is consistent with footnote definitions. Now it just makes Org files less portable without any benefit. Therefore, I suggest to mark it as deprecated in Org 8.3 release notes, and remove it altogether in Org 8.4. WDYT? Regards, -- Nicolas Goaziou
Re: [O] Bug: wrong interpretation of LaTeX [8.2.6 (8.2.6-47-ge3d2c1-elpa @ c:/Users/beffa/.emacs.d/elpa/org-20140526/)]
Hello,
Federico Beffa writes:
> According to the LaTeX manual and reference "LaTeX: A Document
> Preparation System", L. Lamport, \[ ... \] is a short form for a
> displaymath environment. Citing the reference:
> "... Because displayed equations are used so frequently in
> mathematics, LaTeX allows you to type \[ ... \] instead of
> \begin{displaymath} ... \end{displaymath}. ..."
>
> However, org-mode classify \[ ... \] as a latex-fragment, the same as
> \(...\). The two are however very different in LaTeX because, while
> the latter displays some mathematical expression *inline*, the former
> makes its content stand out by putting it on *its own line*.
AFAIK, LaTeX allows to inline "\[...\]" constructs, so something like
Some \[1+1\] text
is perfectly valid. Thus, I think we need to support them.
The other thing to consider is that having the same syntax for an inline
and a non-inline element could introduce some bugs (e.g. when filling
a paragraph).
OTOH, allowing inline \[...\] is pretty harmless.
> What I do not like about this is that "org-fill-paragraph" considers
> the \[ ...\] environment part of a paragraph and therefore the
> environment gets "lost" in the middle of a line.
This is a minor annoyance, indeed. However, you can use the verbose form
in this case (i.e., "\begin{displaymath}").
Regards,
--
Nicolas Goaziou
Re: [O] Evaluating inline source blocks on export issue
Understood. Somehow got the call syntax suck in my head and didn't see
that the underscore named syntax only works for LoB stuff and works
perfectly when you just make a plain old language call.
Thanks!
This feature is really, really important.
Grant Rettke | ACM, ASA, FSF, IEEE, SIAM
g...@wisdomandwonder.com | http://www.wisdomandwonder.com/
“Wisdom begins in wonder.” --Socrates
((λ (x) (x x)) (λ (x) (x x)))
“Life has become immeasurably better since I have been forced to stop
taking it seriously.” --Thompson
On Thu, Jul 24, 2014 at 8:53 PM, Ista Zahn wrote:
> On Thu, Jul 24, 2014 at 6:14 AM, Andreas Leha
> wrote:
>> Nick Dokos writes:
>>
>>> Grant Rettke writes:
>>>
Thanks for looking Thomas and Nick.
When I set this and export
,
| (setq org-export-babel-evaluate t)
`
I get the expected result of
,
| Here is a `16', stuck in the middle of some prose.
`
But when I do this and export
,
| (setq org-export-babel-evaluate 'inline-only)
`
I get this output which is not what I expected
,
| Here is a , stuck in the middle of some prose.
`
I thought that I was enabling inline code block execution correctly
and making the inline call correctly.
How does it look should it be doing what I had wanted?
>>>
>>> I don't think you can: the `type' (see below) of the inline code is not
>>> `inline' as one might think at first, but `lob', presumably because
>>> call_foo is defined in the library-of-babel.
>>>
>>> The relevant code is in ob-exp.el:org-babel-exp-results:
>>>
>>> ,
>>> | ...
>>> | (when (and (or (eq org-export-babel-evaluate t)
>>> | (and (eq type 'inline)
>>> | (eq org-export-babel-evaluate 'inline-only)))
>>> | (not (and hash (equal hash (org-babel-current-result-hash)
>>> | ...
>>> `
>>
>> Then I would like to turn this into a feature request: Enable
>> inline-block-specific settings.
>
> I'm not sure if this solves your problem, but
>
> --8<---cut here---start->8---
> #+name: squareFun
> #+begin_src emacs-lisp :exports none
>(defun square (it) (* it it))
> #+end_src
>
> #+RESULTS: squareFun
> : square
>
> Here is a src_emacs-lisp{(square 10)}, from an inline source block.
> --8<---cut here---end--->8---
>
> does work with org-export-babel-evaluate set to 'inline-only. You do
> have to evaluate the squareFun block before exporting.
>
> Best,
> Ista
>
>
>
>>
>> This does not only hold for the evaluation, but also for default header
>> arguments. Different settings for inline code are quite useful. I do
>> have to specify [:results raw] on the block-to-block basis quite a lot
>> and would benefit a lot from global inline-specific settings.
>>
>> As always, point me to the way to do it, if (quite likely) this is
>> possible already.
>>
>> Regards,
>> Andreas
>>
>>
>
[O] proposal for improved integration of cdlatex
Hi,
when you enable org-cdlatex and insert a LaTeX environment by pressing
M-{, the new environment is inserted ignoring indentation. To correct
for that it is not enough to press TAB as TAB is locally bound to
cdlatex-tab and moves the cursor to the next "interesting" part of the
environment.
For this reason I would like to propose an improved default binding to
the org-cdlatex-mode-map M-{ as follows:
---
(defun org-cdlatex-environment-indent (&optional environment item)
(interactive)
(cdlatex-environment environment item)
(save-excursion
(org-mark-element)
(org-indent-region (point) (mark
(org-defkey org-cdlatex-mode-map "\C-c{"
'org-cdlatex-environment-indent)
---
Regards,
Fede
Re: [O] Possible to use src block to generate org headlines for export?
Andreas Leha writes: > But then, I do not understand your statement 'headlines are the only > limitation to raw+replace behaviour'. > > This code block does not seem to respect 'raw+replace' for me: > > #+name: dtrn > #+BEGIN_SRC R :results raw replace > nwords <- 500 > nletters <- sapply(1:nwords, function(i) sample(1:10, 1)) > words <- sapply(nletters, function(i) paste(sample(letters, i), > collapse="")) > words[sample(nwords, 100)] <- "\n" > paste(words, collapse=" ") > #+END_SRC That was not clear, indeed. "raw" behaviour is only "useful" (i.e., mandatory) when you want to insert a headline (or a drawer) as a result of a code block evaluation. But then, you lose the ability to replace results. That's the limitation I'm talking about. In any other case, "drawer+replace" is the superior choice. Regards, -- Nicolas Goaziou
Re: [O] Org-entities-user in caption of Latex export
Nicolas Goaziou writes: >> I'm setting variables buffer local as a way to make reproducible >> research documents self-contained. The line that sets org-entities-user >> nil is the culprit. Without it, I get the output I expect. With it, I >> get the behavior I described. >> >> Here is my try at an ECM: > > [...] > > This should be fixed. Thank you for reporting it. Yes, it works here. Thanks for looking into this. All the best, Tom -- Thomas S. Dye http://www.tsdye.com
Re: [O] org-special-keyword face not showing in sublevels anymore since commit 69700e1
Martin Carlé wrote: > It appears that by commit 69700e1 [22.04.2014 13:09] a little bug > slipped into the codebase, sinc the org-special-keyword face is only > shown at the top level in the correct face, but then gets simply > overwritten by the respective sublevel face. I did not understand exactly what you meant by sublevel face. Could you explain more accurately, maybe with an ECM and a screenshot of how it was before and after the above commit? Best regards, Seb -- Sebastien Vauban
Re: [O] Using #+NAME for single value, not table?
Rainer M Krug wrote: > Aaron Ecay writes: >> 2014ko ekainak 26an, Rainer M Krug-ek idatzi zuen: >>> >>> I use #+NAME to define some parameters for my analysis, which works >>> quite nice for tables. but I would now like to use the same apprioach >>> for values, e.g. a single number, but I don't manage. Is this possible? >>> For illustration a short example: >>> >>> --8<---cut here---start->8--- >>> *** Species names and iespece codes >>> #+NAME: SPECIES >>> | | fullName| shortName | iespece | IFNName | color >>> | >>> |-+-+---+-+-+---| >>> | fagus | Fagus sylvatica | fagus | 4 | fagus_sylvatica | red >>> | >>> | quercus | Quercus robur | quercus | 3 | quercus_robur | green >>> | >>> >>> *** Random Number Definition >>> Defines random number generator kind, normal.kind and seed (see set.seed >>> help in R for details) >>> #+NAME: RNGSEED >>> 13 >>> --8<---cut here---end--->8--- >>> >>> SPECIES works, but how do I get RNGSEED to be 13? >> >> You can use a verbatim block: >> >> , >> | #+name: xyz >> | : hi >> | >> | #+begin_src emacs-lisp :var abc=xyz >> | (concat "*" abc "*") >> | #+end_src >> | >> | #+RESULTS: >> | : *hi* >> ` > > Perfect - this is exactly what I was looking for. If I'm not mistaken, I see two solutions for you: #+name: RNGSEED : 13 or #+PROPERTY: var RNGSEED=13 Best regards, Seb -- Sebastien Vauban
Re: [O] agenda htmlize-buffer exception
Rainer Stengele wrote: > Trying to htmlize my org agenda buffer stops with exception below. > I cannot understand the reason. > I use zenburn color-theme. > > org-priority-faces is a variable defined in `org-faces.el'. > Its value is > ((67 . "#7cb8bb") > (66 . "#bfebbf") > (65 . "cornflowerblue") > (68 . "grey") > (69 . "grey") > (70 . "grey")) > > Can please anybody help! An ECM would really help here... Though, 65 is the ASCII code for the letter A. Would it be related to priority cookies such as #A? Best regards, Seb -- Sebastien Vauban
Re: [O] still seeing semi-regular lockups
Nicolas Goaziou wrote: > York Zhao writes: > >> I'm sorry but I really shouldn't send this document to anyone other than a >> lawyer :-) > > [...] > >> Just want to confirm that you want me to run this command in that buffer >> and see >> if the problem can be reproduced? > > Calling the provided command on your sensitive buffer will create a copy > in a temporary buffer with all its contents hidden, just preserving > structure. > > If you can reproduce the problem in this new buffer and no information > leaked (the command is just a quick hack so be sure to check it is > fine), you can send its the contents. There are bonus points if you can > also explain me how to reproduce it. I tested your functions on my huge Org LP file for my Emacs config. It does work as a charm, preserving code blocks (necessary for reproducibility purpose). I think this should clearly make its way into Org code base... Best regards, Seb -- Sebastien Vauban
Re: [O] Possible to use src block to generate org headlines for export?
Andreas Leha writes:
> But then, I do not understand your statement 'headlines are the only
> limitation to raw+replace behaviour'.
>
> This code block does not seem to respect 'raw+replace' for me:
>
> #+name: dtrn
> #+BEGIN_SRC R :results raw replace
> nwords <- 500
> nletters <- sapply(1:nwords, function(i) sample(1:10, 1))
> words <- sapply(nletters, function(i) paste(sample(letters, i),
> collapse=""))
> words[sample(nwords, 100)] <- "\n"
> paste(words, collapse=" ")
> #+END_SRC
neither for me, see this thread (I hope the link works):
[[gnus:nntp+news.gmane.org:gmane.emacs.orgmode#87vbraroza@gmail.com][Email
from Thorsten Jolitz: {BUG} src_blocks - :results ra]]
--
cheers,
Thorsten
Re: [O] Add a new face for org-verbatim?
kuanyui wrote:
> Org-verbatim syntax is '=STRING=' ,but the equal symbol makes it look
> not distinguishing ('=' itself looks like it seems to be a part of
> STRING). I misread them often.
>
> So, I think maybe Org-mode can add a new face for equal symbol itself? I
> mean, user can dim the face of '=' to avoid confusion.
(setq org-hide-emphasis-markers t)
Though, it has an impact on table alignment!
Best regards,
Seb
--
Sebastien Vauban
Re: [O] Possible to use src block to generate org headlines for export?
Nicolas Goaziou writes: > Andreas Leha writes: > >> Nicolas Goaziou writes: > >>> No matter how special the results drawer is, it cannot (and shouldn't) >>> contain headlines. >> >> You are the master of the parser... > > That's why I carefully avoid shooting myself in the foot. There is (at > least) a good reason why only headlines can contain headlines, which is > speed, as a consequence of CFG. > >> IIUC, you are saying that raw+replace is possible right now for any >> content in the results (other than headlines), if the results are in a >> drawer? > > If the results are in a drawer, this is not "raw" anymore, but "drawer". > Anyway you can put anything in your drawer besides a headline and > another drawer. But then, I do not understand your statement 'headlines are the only limitation to raw+replace behaviour'. This code block does not seem to respect 'raw+replace' for me: #+name: dtrn #+BEGIN_SRC R :results raw replace nwords <- 500 nletters <- sapply(1:nwords, function(i) sample(1:10, 1)) words <- sapply(nletters, function(i) paste(sample(letters, i), collapse="")) words[sample(nwords, 100)] <- "\n" paste(words, collapse=" ") #+END_SRC > >> Then, my follow-up question is simply, why are drawers not the default >> for results, then? Is there any drawback (apart from an additional >> line)? > > The block may insert a headline, or another drawer, within the results > drawer, thus breaking the document. > I understand that. Will update my local 'defaults' then to drawer. Regards, Andreas
[O] Bug: wrong interpretation of LaTeX [8.2.6 (8.2.6-47-ge3d2c1-elpa @ c:/Users/beffa/.emacs.d/elpa/org-20140526/)]
Hi,
I'm a long time LaTeX user starting to use the excellent org-mode.
I've noticed what I believe is a wrong interpretation of the LaTeX
syntax by org-mode:
According to the LaTeX manual and reference "LaTeX: A Document
Preparation System", L. Lamport, \[ ... \] is a short form for a
displaymath environment. Citing the reference:
"... Because displayed equations are used so frequently in
mathematics, LaTeX allows you to type \[ ... \] instead of
\begin{displaymath} ... \end{displaymath}. ..."
However, org-mode classify \[ ... \] as a latex-fragment, the same as
\(...\). The two are however very different in LaTeX because, while
the latter displays some mathematical expression *inline*, the former
makes its content stand out by putting it on *its own line*.
What I do not like about this is that "org-fill-paragraph" considers
the \[ ...\] environment part of a paragraph and therefore the
environment gets "lost" in the middle of a line.
Here a simple org file:
--
* Intro
First paragraph with equation environment:
\begin{equation}
E = mc^2 .
\end{equation}
Second paragraph with short form of displaymath environment:
\[
E = \hbar\omega .
\]
(setq fbe-tmp (org-element-parse-buffer))
--
and here how it is parsed
--
(org-data nil
(headline
(:raw-value "Intro" :begin 1 :end 226 :pre-blank 1 :hiddenp nil
:contents-begin 10 :contents-end 226 :level 1 :priority nil :tags nil
:todo-keyword nil :todo-type nil :post-blank 0 :footnote-section-p nil
:archivedp nil :commentedp nil :quotedp nil :CATEGORY nil :title
(#("Intro" 0 5
(:parent #1)))
:parent #0)
(section
(:begin 10 :end 226 :contents-begin 10 :contents-end 226
:post-blank 0 :parent #1)
(paragraph
(:begin 10 :end 53 :contents-begin 10 :contents-end 53
:post-blank 0 :post-affiliated 10 :parent #2)
#("First paragraph with equation environment:\n" 0 43
(:parent #3)))
(latex-environment
(:begin 53 :end 98 :value "\\begin{equation}\nE = mc^2
.\n\\end{equation}\n" :post-blank 1 :post-affiliated 53 :parent #2))
(paragraph
(:begin 98 :end 185 :contents-begin 98 :contents-end 184
:post-blank 1 :post-affiliated 98 :parent #2)
#("Second paragraph with short form of displaymath environment:\n" 0 61
(:parent #3))
(latex-fragment
(:value "\\[\nE = \\hbar\\omega .\n\\]" :begin 159 :end 183
:post-blank 0 :parent #3))
#("\n" 0 1
(:parent #3)))
(paragraph
(:begin 185 :end 226 :contents-begin 185 :contents-end 226
:post-blank 0 :post-affiliated 185 :parent #2)
#("(setq fbe-tmp (org-element-parse-buffer))" 0 41
(:parent #3))
--
Regards,
Fede
Emacs : GNU Emacs 24.3.1 (i386-mingw-nt6.1.7601)
of 2013-03-17 on MARVIN
Package: Org-mode version 8.2.6 (8.2.6-47-ge3d2c1-elpa @
c:/Users/beffa/.emacs.d/elpa/org-20140526/)
Re: [O] Org-entities-user in caption of Latex export
Hello, t...@tsdye.com (Thomas S. Dye) writes: > Nicolas Goaziou writes: > >> I cannot reproduce it. Do you have an ECM? Are you setting >> `org-entities-user' in a special way (i.e, not globally through `setq' >> or customize)? > > In the process of putting together an ECM (which hopefully doesn't > reflect my setup!), I think I found what triggers it. > > I'm setting variables buffer local as a way to make reproducible > research documents self-contained. The line that sets org-entities-user > nil is the culprit. Without it, I get the output I expect. With it, I > get the behavior I described. > > Here is my try at an ECM: [...] This should be fixed. Thank you for reporting it. Regards, -- Nicolas Goaziou
Re: [O] Possible to use src block to generate org headlines for export?
Andreas Leha writes: > Nicolas Goaziou writes: >> No matter how special the results drawer is, it cannot (and shouldn't) >> contain headlines. > > You are the master of the parser... That's why I carefully avoid shooting myself in the foot. There is (at least) a good reason why only headlines can contain headlines, which is speed, as a consequence of CFG. > IIUC, you are saying that raw+replace is possible right now for any > content in the results (other than headlines), if the results are in a > drawer? If the results are in a drawer, this is not "raw" anymore, but "drawer". Anyway you can put anything in your drawer besides a headline and another drawer. > Then, my follow-up question is simply, why are drawers not the default > for results, then? Is there any drawback (apart from an additional > line)? The block may insert a headline, or another drawer, within the results drawer, thus breaking the document. Regards, -- Nicolas Goaziou
Re: [O] Possible to use src block to generate org headlines for export?
Hi Nicolas, Nicolas Goaziou writes: > Hello, > > Andreas Leha writes: > >> Is that a valid feature request: >> Allow the combination of :results raw and :results replace -- regardless >> of the produced content? >> >> IIUC the parser does not allow this right now. But (without any >> knowledge on the parser) I can imagine >> 'special' results drawers that do not have any function/effect other than >> delimiting babel results (plus possibly folding). >> If these existed, I would even enable them by default no matter of 'raw' >> or not. > > No matter how special the results drawer is, it cannot (and shouldn't) > contain headlines. > You are the master of the parser... > There are a few options to mark raw output even with headlines: > > 1. Use text properties to mark the part of the buffer generated by > a given source block. The main drawback is that Org is not just > plain text anymore (some information is hidden and cannot be found > just looking at the text). > > 2. Use comment cookies around the area: > > # Raw Babel Output : src-name (begin) > * Some headline > # Raw Babel Output : src-name (end) > > This is not very pretty. Also, it may be difficult to handle > overlapping changes around the same region. > > OTOH, headlines are the only limitation to raw+replace behaviour. Some > decent workarounds to this problem were offered in this thread. We can > also live with it. > IIUC, you are saying that raw+replace is possible right now for any content in the results (other than headlines), if the results are in a drawer? Then, my follow-up question is simply, why are drawers not the default for results, then? Is there any drawback (apart from an additional line)? Regards, Andreas
Re: [O] Translations
Carlos Sosa writes: > David Arroyo Menendez writes: > >> Bastien writes: >> >>> Hi David, >>> >>> David Arroyo Menendez writes: >>> > * Guía Compacta de Org Mode (http://davidam.com/docu/orgguide.es.html y > fuentes en worg) This book needs a full review. >>> >>> You may also want to ask on the orgmode mailing list, where there are >>> more users who are both Org-mode users and spanish speakers. >>> >>> Thanks for your continued efforts about this, >> >> Good idea! I'm looking for people who is interested in make a full >> review of Guía Compacta de Org Mode. I will do a new call, when I've >> finished my own review of Una Introducción a Emacs Lisp en Español. >> >> Thanks! > > I would like to review both guides. I will look first at the "Guía > Compacta de Org Mode". Is "Una Introducción a Emacs Lisp en Español." > available? Who do I send my notes to regarding "Guía Compacta de Org > Mode"? > > Thanks. > -- Carlos Sosa I've created a TODO.org in the directory orgguide, perhaps we could coordinate work with it? Thanks
Re: [O] Bug: org-master (release_8.3beta-56-gdb0130) ascii exporter ignores org-export-preserve-breaks
Hello, Miguel Ruiz writes: > After more detailed review I have figure out that the problem more generic > and the opposite of the exposed in my previous message: > > - org-maint ascii exporter takes org-export-preserve-breaks into account > (default is nil; it works as expected, both nil and t) > > - org-master ascii exporter doesn't take org-export-preserve-breaks into > account (default is nil, it always preserves breaks) > > - Minimal example: > > #8<->8 > > hello > bye > > #8<->8 > > and M-x org-ascii-export-as-ascii. > > - Org-maint (org-export-preserve-breaks nil) output: > > hello bye > > - Org-maint (org-export-preserve-breaks nil) output: > > hello > bye This should now be fixed. Thank you for reporting it. Regards, -- Nicolas Goaziou
Re: [O] What happened to clocktable in pdf export?
Buddy Butterfly writes: > How can I easily fix it in my Ubuntu dist? I am running the standard > repo version from Ubuntu 14.04. Any .el or something like that? Since it is fixed in maint, you can update Org from ELPA. It will be updated in a few hours. > Just a small one. As now the line for the clocktable becomes longer, > is there a method to break up the clocktable header into multiple > lines? Not yet, but ultimately :header property should probably be moved to #+HEADER: keyword above the dynamic block, much like source blocks: #+header: #+attr_latex: :align l|r|r|r :environment longtable #+header: :fontsize \footnotesize #+BEGIN: clocktable :maxlevel 7 :scope tree3 :indent t ... Though, there's no standard syntax to include a newline there, e.g., #+header: #+attr_latex: :align l|r|r|r :environment longtable #+header: :fontsize \footnotesize\n#+caption: Some caption #+BEGIN: clocktable :maxlevel 7 :scope tree3 :indent t ... Regards, -- Nicolas Goaziou
Re: [O] How to get results into export?
On Fri, 25 Jul 2014 11:11:23 +0200
Manfred Lotz wrote:
> On Fri, 25 Jul 2014 10:03:14 +0200
> Thorsten Jolitz wrote:
>
> > Manfred Lotz writes:
> >
> > > I have this minimal example using minted:
> > >
> > > #+TITLE: Minimal example
> > > #+LaTeX_HEADER: \usemintedstyle{emacs}
> > > * Example
> > > - some code
> > > #+BEGIN_SRC sh :results values code
> > > echo # of items
> > > echo \# of items
> > > echo "# of items"
> > > #+END_SRC
> > >
> > > #+RESULTS:
> > > #+BEGIN_SRC sh
> > >
> > > # of items
> > > # of items
> > > #+END_SRC
> > >
> > >
> > > I evaluated the source code block and got the results. Now, when
> > > exporting the file to say PDF the results won't appear in the PDF.
> > >
> > > Is there a possibility to make this happen?
> >
> > Try header arg
> >
> > ,
> > | :exports results
> > `
> >
> > (untested)
> >
>
> Oops yes, it is such easy. In my case :results both is what I want.
>
Sorry, I wanted to say: :exports both
-- Manfred
Re: [O] What happened to clocktable in pdf export?
Hi,
this is sooo cool! Was not aware of this syntax change.
It works now as expected.
Regarding
"\__" syntax doesn't exist anymore, so no exporter will recognize it.
The replacement is "\emsp". I fixed it in maint. Thank you for reporting
it.
How can I easily fix it in my Ubuntu dist? I am running the standard
repo version from Ubuntu 14.04. Any .el or something like that?
Just a small one. As now the line for the clocktable becomes longer,
is there a method to break up the clocktable header into multiple lines?
Thanks a lot man, you saved my docs ;-)
Cheers,
Matt
Am 25.07.2014 um 11:06 schrieb Nicolas Goaziou:
> Hello,
>
> Buddy Butterfly writes:
>
>> 1. Even though the column separators are given in latex, they are not
>> printed
>>anymore. Only when using the org-table standard feature |<>|. But such
>>an additional line will be deleted after a clocktable refresh.
> This is because syntax has changed. Attributes specific to the table
> have to be inserted above the table, not above the dynamic block. What
> you really want is (note the differences in "attr_latex" line)
>
> #+BEGIN: clocktable :maxlevel 7 :scope tree3 :indent t
> #+ATTR_LATEX: :environment longtable :align l|r|r|r
> | Headline | Time | | |
> ...
> #+END:
>
> Since the table is auto generated, you have to send this line through
> the :header property:
>
> #+BEGIN: clocktable :maxlevel 7 :scope tree3 :indent t :header
> "#+attr_latex: :align l|r|r|r :environment longtable\n"
> ...
> #+END:
>
> Now you can also avoid using both "#+latex:" lines with appropriate
> properties:
>
> #+BEGIN: clocktable :maxlevel 7 :scope tree3 :indent t :header
> "#+attr_latex: :align l|r|r|r :environment longtable :center t :font
> \\footnotesize\n"
> ...
> #+END:
>
> Eventually you can also insert a caption with, e.g.,
>
> #+BEGIN: clocktable :maxlevel 7 :scope tree3 :indent t :header
> "#+attr_latex: :align l|r|r|r :environment longtable :center t :font
> \\footnotesize\n#+caption: Clock summary at {{{time(%c)}}}\n"
>
>> 2. The indentation underscores are printed, which did not come before.
>> Especially
>>this makes it ugly. Before the _ have not been exported.
> "\__" syntax doesn't exist anymore, so no exporter will recognize it.
>
> The replacement is "\emsp". I fixed it in maint. Thank you for reporting
> it.
>
>
> Regards,
>
Re: [O] Bug: [PATCH] Make org-narrow-to-subtree usable out of Org mode [8.2.7b (release_8.2.7b-6-g07d470 @ /home/youngfrog/sourcetrees/org-mode/lisp/)]
Nicolas Richard writes: > But now that I think about it, org mode simply should avoid narrow-map > completely : users (me included) won't randomly try to run > org-narrow-to-subtree outside of org buffers (and those who do deserve a > bad error message) but they might want to give "C-x n s" a try if it is > available. > > While writing a patch for changing that, I see that the code is: > (if (boundp 'narrow-map) > (org-defkey narrow-map "s" 'org-narrow-to-subtree) > (org-defkey org-mode-map "\C-xns" 'org-narrow-to-subtree)) > (if (boundp 'narrow-map) > (org-defkey narrow-map "b" 'org-narrow-to-block) > (org-defkey org-mode-map "\C-xnb" 'org-narrow-to-block)) > (if (boundp 'narrow-map) > (org-defkey narrow-map "e" 'org-narrow-to-element) > (org-defkey org-mode-map "\C-xne" 'org-narrow-to-element)) > > IOW, org.el purposely binds in narrow-map ! So now I don't get it : > either it's in narrow-map and should be usable widely, or it's in > org-mode-map only for org-mode files. I don't know the answer either, but it is strange indeed. Carsten introduced it in 2008 in commit 6321ab8a852252ff242386eb9fef8ae12112f3a8, but the commit message is rather terse. I'm CC'ing him for more information, hopefully. Regards, -- Nicolas Goaziou
Re: [O] How to get results into export?
On Fri, 25 Jul 2014 10:03:14 +0200
Thorsten Jolitz wrote:
> Manfred Lotz writes:
>
> > I have this minimal example using minted:
> >
> > #+TITLE: Minimal example
> > #+LaTeX_HEADER: \usemintedstyle{emacs}
> > * Example
> > - some code
> > #+BEGIN_SRC sh :results values code
> > echo # of items
> > echo \# of items
> > echo "# of items"
> > #+END_SRC
> >
> > #+RESULTS:
> > #+BEGIN_SRC sh
> >
> > # of items
> > # of items
> > #+END_SRC
> >
> >
> > I evaluated the source code block and got the results. Now, when
> > exporting the file to say PDF the results won't appear in the PDF.
> >
> > Is there a possibility to make this happen?
>
> Try header arg
>
> ,
> | :exports results
> `
>
> (untested)
>
Oops yes, it is such easy. In my case :results both is what I want.
--
Thanks a lot, Manfred
Re: [O] What happened to clocktable in pdf export?
Hello,
Buddy Butterfly writes:
> 1. Even though the column separators are given in latex, they are not
> printed
>anymore. Only when using the org-table standard feature |<>|. But such
>an additional line will be deleted after a clocktable refresh.
This is because syntax has changed. Attributes specific to the table
have to be inserted above the table, not above the dynamic block. What
you really want is (note the differences in "attr_latex" line)
#+BEGIN: clocktable :maxlevel 7 :scope tree3 :indent t
#+ATTR_LATEX: :environment longtable :align l|r|r|r
| Headline | Time | | |
...
#+END:
Since the table is auto generated, you have to send this line through
the :header property:
#+BEGIN: clocktable :maxlevel 7 :scope tree3 :indent t :header "#+attr_latex:
:align l|r|r|r :environment longtable\n"
...
#+END:
Now you can also avoid using both "#+latex:" lines with appropriate
properties:
#+BEGIN: clocktable :maxlevel 7 :scope tree3 :indent t :header "#+attr_latex:
:align l|r|r|r :environment longtable :center t :font \\footnotesize\n"
...
#+END:
Eventually you can also insert a caption with, e.g.,
#+BEGIN: clocktable :maxlevel 7 :scope tree3 :indent t :header "#+attr_latex:
:align l|r|r|r :environment longtable :center t :font
\\footnotesize\n#+caption: Clock summary at {{{time(%c)}}}\n"
>
> 2. The indentation underscores are printed, which did not come before.
> Especially
>this makes it ugly. Before the _ have not been exported.
"\__" syntax doesn't exist anymore, so no exporter will recognize it.
The replacement is "\emsp". I fixed it in maint. Thank you for reporting
it.
Regards,
--
Nicolas Goaziou
Re: [O] Possible to use src block to generate org headlines for export?
Hello, Andreas Leha writes: > Is that a valid feature request: > Allow the combination of :results raw and :results replace -- regardless > of the produced content? > > IIUC the parser does not allow this right now. But (without any > knowledge on the parser) I can imagine > 'special' results drawers that do not have any function/effect other than > delimiting babel results (plus possibly folding). > If these existed, I would even enable them by default no matter of 'raw' > or not. No matter how special the results drawer is, it cannot (and shouldn't) contain headlines. There are a few options to mark raw output even with headlines: 1. Use text properties to mark the part of the buffer generated by a given source block. The main drawback is that Org is not just plain text anymore (some information is hidden and cannot be found just looking at the text). 2. Use comment cookies around the area: # Raw Babel Output : src-name (begin) * Some headline # Raw Babel Output : src-name (end) This is not very pretty. Also, it may be difficult to handle overlapping changes around the same region. OTOH, headlines are the only limitation to raw+replace behaviour. Some decent workarounds to this problem were offered in this thread. We can also live with it. Regards, -- Nicolas Goaziou
Re: [O] How to get results into export?
Manfred Lotz writes:
> I have this minimal example using minted:
>
> #+TITLE: Minimal example
> #+LaTeX_HEADER: \usemintedstyle{emacs}
> * Example
> - some code
> #+BEGIN_SRC sh :results values code
> echo # of items
> echo \# of items
> echo "# of items"
> #+END_SRC
>
> #+RESULTS:
> #+BEGIN_SRC sh
>
> # of items
> # of items
> #+END_SRC
>
>
> I evaluated the source code block and got the results. Now, when
> exporting the file to say PDF the results won't appear in the PDF.
>
> Is there a possibility to make this happen?
Try header arg
,
| :exports results
`
(untested)
--
cheers,
Thorsten
Re: [O] c-c ' strips final newline or adds blank line, but never neither
Samuel Wales writes: > i find that when i do c-c ' on a source block, it either strips the > final newline in the editing buffer or adds an unwanted blank line in > the source block. > > i like to have final newlines in all of my buffers, including editing > buffers. what setting allows this without introducing a blank line at > the end of a source block? ,[ C-h v org-src-strip-leading-and-trailing-blank-lines RET ] | org-src-strip-leading-and-trailing-blank-lines is a variable defined | in `org-src.el'. Its value is nil | | Documentation: | If non-nil, blank lines are removed when exiting the code edit buffer. ` -- cheers, Thorsten
Re: [O] Bug: org-master (release_8.3beta-56-gdb0130) ascii exporter ignores org-export-preserve-breaks
Sorry: last block, I meant - Org-master (org-export-preserve-breaks nil) output: hello bye > -Original Message- > From: rbeni...@inbox.com > Sent: Thu, 24 Jul 2014 23:53:57 -0800 > To: emacs-orgmode@gnu.org > Subject: Re: [O] Bug: org-master (release_8.3beta-56-gdb0130) ascii > exporter ignores org-export-preserve-breaks > > After more detailed review I have figure out that the problem more > generic and the opposite of the exposed in my previous message: > > - org-maint ascii exporter takes org-export-preserve-breaks into account > (default is nil; it works as expected, both nil and t) > > - org-master ascii exporter doesn't take org-export-preserve-breaks into > account (default is nil, it always preserves breaks) > > - Minimal example: > > #8<->8 > > hello > bye > > #8<->8 > > and M-x org-ascii-export-as-ascii. > > - Org-maint (org-export-preserve-breaks nil) output: > > hello bye > > - Org-maint (org-export-preserve-breaks nil) output: > > hello > bye > > > HTH > > Miguel. > > >> -Original Message- >> From: rbeni...@inbox.com >> Sent: Wed, 23 Jul 2014 23:41:09 -0800 >> To: emacs-orgmode@gnu.org >> Subject: [O] org-maint exporting ignores \n in python babel output ascii >> export; org-master doesn't though >> >> #+BEGIN_SRC python :exports results :results raw >> return "Hello\nBye" >> #+END_SRC >> >> exports as: >> >> Hello Bye >> >> with org-ascii-export-as/to-ascii (Org-mode version 8.2.7b >> (release_8.2.7b-5-gc9613c)) >> >> But it exports correctly with Org-mode version 8.3beta >> (release_8.3beta-56-gdb0130) >> >> >> >> Miguel. >> >> >> Protect your computer files with professional cloud backup. >> Get PCRx Backup and upload unlimited files automatically. >> Learn more at http://backup.pcrx.com/mail > > > FREE 3D EARTH SCREENSAVER - Watch the Earth right on your desktop! > Check it out at http://www.inbox.com/earth Send any screenshot to your friends in seconds... Works in all emails, instant messengers, blogs, forums and social networks. TRY IM TOOLPACK at http://www.imtoolpack.com/default.aspx?rc=if2 for FREE
Re: [O] Bug: org-master (release_8.3beta-56-gdb0130) ascii exporter ignores org-export-preserve-breaks
After more detailed review I have figure out that the problem more generic and the opposite of the exposed in my previous message: - org-maint ascii exporter takes org-export-preserve-breaks into account (default is nil; it works as expected, both nil and t) - org-master ascii exporter doesn't take org-export-preserve-breaks into account (default is nil, it always preserves breaks) - Minimal example: #8<->8 hello bye #8<->8 and M-x org-ascii-export-as-ascii. - Org-maint (org-export-preserve-breaks nil) output: hello bye - Org-maint (org-export-preserve-breaks nil) output: hello bye HTH Miguel. > -Original Message- > From: rbeni...@inbox.com > Sent: Wed, 23 Jul 2014 23:41:09 -0800 > To: emacs-orgmode@gnu.org > Subject: [O] org-maint exporting ignores \n in python babel output ascii > export; org-master doesn't though > > #+BEGIN_SRC python :exports results :results raw > return "Hello\nBye" > #+END_SRC > > exports as: > > Hello Bye > > with org-ascii-export-as/to-ascii (Org-mode version 8.2.7b > (release_8.2.7b-5-gc9613c)) > > But it exports correctly with Org-mode version 8.3beta > (release_8.3beta-56-gdb0130) > > > > Miguel. > > > Protect your computer files with professional cloud backup. > Get PCRx Backup and upload unlimited files automatically. > Learn more at http://backup.pcrx.com/mail FREE 3D EARTH SCREENSAVER - Watch the Earth right on your desktop! Check it out at http://www.inbox.com/earth
