[O] greek letters (parameters) in formula for a spreadsheet
Dear list, When I have a table like | $ | | rho=33 | |---+---+| | # | 3 | 99 | #+TBLFM: $3=$rho*$2 it works ok. But as soon as I replace rho -> \rho to get a nice greek letter (I also use #+STARTUP: entitiespretty), I get | $ | | \rho=33 | |---+---+| | # | 3 | #ERROR | #+TBLFM: $3=$\rho*$2 Can I do something about this? Thanks Ruda
Re: [O] PATCH: Extract HTML attributes from link if present
Hello, Jens Lechtenboerger writes: > for HTML export, attributes are added to links with what is called a > “HACK” in a comment in ox-html.el: Attribute :attr_html is read from > the parent, to be transferred to the first link. > > That mechanism can used to assign attributes to the first link in > each paragraph/sentence. For org-reveal, I would like to assign > computed classes to links in general (several per paragraph). The > attached patch extends the current functionality to add attributes > of the link to those of the parent. Applied. Thank you. Regards, -- Nicolas Goaziou
Re: [O] “Fuzzy” times (“evening”, “morning”, “night”…)
On 2018-12-08 at 09:47 -0800, Leo Gaspard wrote: > However, I think it may be a good idea to allow eg. this kind of > timestamps: > <2018-02-04 Tue evening> That would be handled as though it > was eg. <2018-02-04 Tue 18:00-22:00> (which would be configurable), so > that it would be both semantically correct (the time is still fuzzy) > and correctly displayed (eg. on an agenda) > [...] > What do you think about this idea? Is there a better way to do what > I'm trying to do with current tools? I think this would be a neat feature. But as a first pass which can work immediately, what about using one of the multiple text expansion packages that are Org-agnostic to achieve this: Yasnippets or abbrev mode, for example? This doesn't maintain the "semantics (time still fuzzy)", but does let you define and enter time ranges in a simpler way. -k.
[O] “Fuzzy” times (“evening”, “morning”, “night”…)
Hello, In the process of migrating all my self-organization to org-mode, I noticed there is something that cannot currently be encoded in timestamps: fuzzy times, where an appointment is made for “Dec 4, Tue, evening” but with the hours not yet fixed. Currently my way of handling this has been to mark the tasks with time spans approx. correct and add a comment to fix them. However, I think it may be a good idea to allow eg. this kind of timestamps: <2018-02-04 Tue evening> That would be handled as though it was eg. <2018-02-04 Tue 18:00-22:00> (which would be configurable), so that it would be both semantically correct (the time is still fuzzy) and correctly displayed (eg. on an agenda) To be perfectly honest, my ulterior motive here is to auto-generate tasks “Decide of an exact time for [task]” a few days before the timestamp. However, I haven't investigated yet whether that'd actually be doable and I'm still pretty new to the lisp/emacs/org-mode ecosystems, so this may be completely impossible. What do you think about this idea? Is there a better way to do what I'm trying to do with current tools? Cheers, Leo
[O] PATCH: Extract HTML attributes from link if present
Hi there, for HTML export, attributes are added to links with what is called a “HACK” in a comment in ox-html.el: Attribute :attr_html is read from the parent, to be transferred to the first link. That mechanism can used to assign attributes to the first link in each paragraph/sentence. For org-reveal, I would like to assign computed classes to links in general (several per paragraph). The attached patch extends the current functionality to add attributes of the link to those of the parent. Could that please be included? Best wishes Jens >From 3ac50ac3a3c8951d59a1d30b047ae0407731b789 Mon Sep 17 00:00:00 2001 From: Jens Lechtenboerger Date: Sat, 8 Dec 2018 16:44:06 +0100 Subject: [PATCH] ox-html.el: Export attributes specified with :attr_html for links * lisp/ox-html.el (org-html-link): Export :attr_html from link --- lisp/ox-html.el | 30 ++ 1 file changed, 18 insertions(+), 12 deletions(-) diff --git a/lisp/ox-html.el b/lisp/ox-html.el index 6a81be126..bbe38d8e2 100644 --- a/lisp/ox-html.el +++ b/lisp/ox-html.el @@ -3045,19 +3045,25 @@ INFO is a plist holding contextual information. See "#" (org-publish-resolve-external-link option path t)) (t raw-path))) - ;; Extract attributes from parent's paragraph. HACK: Only do - ;; this for the first link in parent (inner image link for - ;; inline images). This is needed as long as attributes - ;; cannot be set on a per link basis. (attributes-plist - (let* ((parent (org-export-get-parent-element link)) - (link (let ((container (org-export-get-parent link))) - (if (and (eq (org-element-type container) 'link) - (org-html-inline-image-p link info)) - container - link - (and (eq (org-element-map parent 'link 'identity info t) link) - (org-export-read-attribute :attr_html parent + (org-combine-plists + ;; Extract attributes from parent's paragraph. HACK: Only do + ;; this for the first link in parent (inner image link for + ;; inline images). This is needed as long as attributes + ;; cannot be set on a per link basis. + (let* ((parent (org-export-get-parent-element link)) + (link (let ((container (org-export-get-parent link))) + (if (and (eq (org-element-type container) 'link) + (org-html-inline-image-p link info)) + container + link + (and (eq (org-element-map parent 'link 'identity info t) link) + (org-export-read-attribute :attr_html parent))) + ;; Also add attributes from link itself. Currently, those need + ;; to be added programmatically before org-html-link is invoked, + ;; for example, by backends building upon HTML export, such as + ;; org-reveal. + (org-export-read-attribute :attr_html link))) (attributes (let ((attr (org-html--make-attribute-string attributes-plist))) (if (org-string-nw-p attr) (concat " " attr) "" -- 2.17.1
Re: [O] PATCH: Allow class attribute for headline in HTML export
Hello! On 2018-12-08, at 12:46, Nicolas Goaziou wrote: > Jens Lechtenboerger writes: > >> Function org-reveal-headline calls org-html-headline to generate >> h-elements. Of course, I could parse the generated HTML in >> ox-reveal and add a class attribute based on org properties, but >> doing so in ox-html seems much cleaner to me. (Besides, given the >> current situation of ox-reveal [1], that change would only make it >> into my fork, not into the original project.) > > Fair enough. I applied your patch on "next" branch. Thank you, I really appreciate this change! Best wishes Jens
Re: [O] Bug: Latex preview fg color w/tikz (known problem, fix suggested) [9.1.9 (release_9.1.9-65-g5e4542 @ /home/carlos/local/stow/emacs-26/share/emacs/26.1.90/lisp/org/)]
On Saturday, 8 Dec 2018 at 10:56, Nicolas Goaziou wrote: > I'm nowhere close to being a LaTeX expert. If depending on xcolor is not > too invasive, I'd rather do it than introduce yet another customization > option. > > Maybe real LaTeX experts could chime in. Whether expert or not, I can say that I have had xcolor in my org-latex-packages-alist for years and have never noticed any problem. -- Eric S Fraga via Emacs 27.0.50, Org release_9.1.14-1035-gfeb442
Re: [O] PATCH: Allow class attribute for headline in HTML export
Hello, Jens Lechtenboerger writes: > Function org-reveal-headline calls org-html-headline to generate > h-elements. Of course, I could parse the generated HTML in > ox-reveal and add a class attribute based on org properties, but > doing so in ox-html seems much cleaner to me. (Besides, given the > current situation of ox-reveal [1], that change would only make it > into my fork, not into the original project.) Fair enough. I applied your patch on "next" branch. Thank you! Regards, -- Nicolas Goaziou
Re: [O] Bug: Org capture: Invalid use of ‘\’ in replacement text [9.1.14 (9.1.14-1049-g04641c-elpaplus @ /home/ionasal/.emacs.d/elpa/org-plus-contrib-20181203/)]
Hello,
Allen Li writes:
> There's an escaping bug in Org capture:
>
> 1. emacs -Q
> 2. Evaluate:
>
> (setq org-capture-templates
>'(("Z" "org-protocol capture" entry
> (file "/tmp/tmp")
> "* %?
> %(let ((x \"%:annotation\")) (if (string= x \"\") \"\" (concat x
> \"\\n\")))%i")))
>
> 3. Evaluate (require 'org-protocol)
>
> 4. Evaluate to simulate org protocol capture:
>
> (org-protocol-capture '(:template "Z" :body "foo\nbar\n"))
>
> Causes error:
>
> (error "Capture abort: (error Invalid use of ‘\\’ in replacement
> text)")
Fixed. Thank you.
Regards,
--
Nicolas Goaziou
Re: [O] Bug: Latex preview fg color w/tikz (known problem, fix suggested) [9.1.9 (release_9.1.9-65-g5e4542 @ /home/carlos/local/stow/emacs-26/share/emacs/26.1.90/lisp/org/)]
Hello, Carlos Pita writes: >> Would you want to provide a patch for that? > > Yes, sure, just give me a few days since I'm quite busy right know. > > Are you ok with depending on xcolor by default or do you prefer a > customization option? I'm nowhere close to being a LaTeX expert. If depending on xcolor is not too invasive, I'd rather do it than introduce yet another customization option. Maybe real LaTeX experts could chime in. Regards, -- Nicolas Goaziou
Re: [O] [PATCH] Bug: Org capture: Invalid use of ‘\’ in replacement text [9.1.14 (9.1.14-1049-g04641c-elpaplus @ /home/ionasal/.emacs.d/elpa/org-plus-contrib-20181203/)]
Hello, Allen Li writes: > Attached patch fixing this. > > This was caused by a bug in a feature that I did not realize existed > (prefixing each line in %i). I have also included patches to clarify > the documentation. Thank you. However, with the documentation patch, along with your past contributions, you would be over the limit allowed for tiny changes. IOW, you need to sign FSF papers so that we can apply it. Regards, -- Nicolas Goaziou
Re: [O] Noweb blocks duplicate during Org export if part of #+include
Hello, Kaushal Modi writes: > Here is a MWE: > > 1. With point on the "** Foo" section, running C-c C-e C-s h o, will > result in noweb-duplicate-bug.html with the <> block > expanded only once, as expected. > > 2. But with point on the "* Foo Included" section, running the same > C-c C-e C-s h o, will result in foo_included.html with the > <> block expanded twice! It seems like the Noweb > expansion happens first as usual, and then again when parsing > #+include (which shouldn't happen?). That's not exactly what is happening. INCLUDE keywords are always expanded before Babel kicks in. Moreover, when exporting a subtree, only INCLUDE keywords from the subtree are expanded. So, in your first example, nothing fancy happens. Now, onto the second case. When evaluating Babel code, the whole initial buffer is taken as reference. It allows, for example, to define source blocks in a dedicated section, and export another one that calls them. When the INCLUDE keyword is expanded, there are two ":noweb-ref some_snippet". Even if they are outside the exported subtree, they are still concatenated and used as a replacement for "<". In a nutshell, that can be surprising, but this is to be expected. Regards, -- Nicolas Goaziou
