Re: [O] How to differentiate between lists in HTML export
Marcin Borkowski writes: > Thanks, but this is not really what I'd like to have: the strings > generated by org-export-get-ordinal are /not/ unique throughout the file > (they seem to be unique within one level of hierarchy). They should be unique. How did you use this function? Regards,
Re: [O] [PATH] Speedups to org-table-recalculate
Updated patches attached. 0001-org-table.el-org-table-recalculate-early-returns.patch Description: Binary data 0002-org-table.el-org-table-recalculate-is-quieter.patch Description: Binary data
Re: [O] Org and ledger
On Sunday, 9 Nov 2014 at 11:34, Daniel Clemente wrote: [...] > I prefer beancount (very similar to ledger but stricter): beancount > supports org out of the box! My beancount file is an org file (with > structure, tasks, priorities, agenda, etc. except :CLOCK:) and it > parses correctly as a ledger. Interesting. Could you post an example file? The documentation you linked to on Google docs does not mention org anywhere that I could see. thanks. -- : Eric S Fraga (0xFFFCF67D), Emacs 25.0.50.1, Org release_8.3beta-475-g25d50e
Re: [O] [PATH] Speedups to org-table-recalculate
Hi Nathaniel On Sun, Nov 9, 2014 at 11:18 AM, Nathaniel Flath wrote: > Updated patches attached. The second does not apply after the first on today's release_8.3beta-552-ga95cfeb. Unrelated: The second has new closing parentheses on an own line. Michael
Re: [O] odt export of subtree: set/suppress the date in the export
> CM : > I cannot reproduce either problem, though I seem to remember some > difficulty with changing date fields in the past. What Org version are > you using? Um... a heap of different versions it looks like, on the systems I use regularily, some from ELPA (one of the ELPA archives), some from org git, and the version delivered with emacs 24.3. Right now I'm on a debian box using git org, and I've done make clean git pull make and started a fresh emacs. And here I see a different behaviour > You can turn the use of date fields in LibreOffice on or off with > org-odt-use-date-fields. With date fields set to t: Hm... 'C-h v org-odt-use-date-fields RET' says: org-odt-use-date-fields is a variable defined in `ox-odt.el'. Its value is nil > - Setting :EXPORT_DATE: in the subtree and exporting the subtree results > in an ODT export with that date in the header, not today's date. > - Inspecting the date field shows that the date is "fixed". (In > LibreOffice, right-click the date and select "Fields" from the popup > menu.) > - Indeed, the date remains unchanged when I do "Update all" or export > to PDF from LibreOffice does indeed keep the same date. Hm... I may play around with these settings, but for now I'm happy with the default behaviour (no date stamp). I'll go to git org on all of my emacsen. Thanks!
Re: [O] Best way to include references/license
Nicolas Goaziou writes:
> It should be \ref{photo1}/\label{photo1} in this case. I pushed a fix
> for that in maint.
Thanks for the fix.
Julien.
Re: [O] How to differentiate between lists in HTML export
On 2014-11-09, at 09:24, Nicolas Goaziou wrote: > Marcin Borkowski writes: > >> Thanks, but this is not really what I'd like to have: the strings >> generated by org-export-get-ordinal are /not/ unique throughout the file >> (they seem to be unique within one level of hierarchy). > > They should be unique. How did you use this function? Sorry for the noise, it seems to be working now. (I threw out the code, but AFAIR the non-uniqueness arised with ordinals of /items/ in different lists.) > Regards, Thanks, -- Marcin Borkowski http://octd.wmi.amu.edu.pl/en/Marcin_Borkowski Adam Mickiewicz University
Re: [O] How to differentiate between lists in HTML export
Marcin Borkowski writes: > Sorry for the noise, it seems to be working now. (I threw out the > code, but AFAIR the non-uniqueness arised with ordinals of /items/ in > different lists.) Yes, ordinals for items are relative to the list they belong to. OTOH for plain lists, this is the sequence number among other plain lists in the buffer (see docstring). Regards,
Re: [O] issues with non-bracketed links in org 8.3
Christopher Dannheim writes: > org-element-context yields: > (paragraph (:begin 6145 :end 6166 :contents-begin 6145 :contents-end 6165 > :post-blank 1 :post-affiliated 6145 ...)) > > After relaoding org: > (link (:type "textcite" :path "Hobart2003" :raw-link "textcite:Hobart2003" > :application nil :search-option nil :begin 6145 ...)) > > and the link is working again! Why is that the case? A new type means that link syntax has to be updated. The parser didn't do it. It should now be fixed. Thank you for reporting the problem. Regards,
Re: [O] How to differentiate between lists in HTML export
On 2014-11-10, at 00:08, Nicolas Goaziou wrote: > Marcin Borkowski writes: > >> Sorry for the noise, it seems to be working now. (I threw out the >> code, but AFAIR the non-uniqueness arised with ordinals of /items/ in >> different lists.) > > Yes, ordinals for items are relative to the list they belong to. OTOH > for plain lists, this is the sequence number among other plain lists in > the buffer (see docstring). That's exactly what I thought. (I need ordinals for plain lists, since I sometimes convert them to groups of radio buttons in my derived html backend; at first, I mistakenly took ordinals of items...) Tip to myself (and to whoever might need it): to have a unique id of a list item, combine the id of the parent list with the (relative) id of the item. > Regards, Best, -- Marcin Borkowski http://octd.wmi.amu.edu.pl/en/Marcin_Borkowski Adam Mickiewicz University
Re: [O] patch to add new link type "infoi" that leverages Info-index command
Nicolas,
Thanks for your feedback. I agree that using the same link type is better.
Hence I took an alternate approach as detailed in the attached patch.
Enhanced org-info-follow-link to attempt index lookup if node lookup fails.
Following is my check in message found in the attached patch:
Enhanced org-info-follow-link to attempt index lookup if node lookup
fails.
Info index is almost always finer grain than info nodes. For example
with this change, [[info:libc#close]] brings up not only
"(libc)Opening and Closing Files" info node, but also place the cursor
on the line that documents "close" function within the node. This is
done by looking up "close"in the index upon failing to find a node
named "close". Hence one can now link function, variable and other
names that are in the index rather than being limited to info node
names. Typically there are far more index items than there are node
names. For example libc manual has about 700 nodes, but over
4000 concept, type, function, and variables index items.
On 6 November 2014 10:41, Nicolas Goaziou wrote:
> Hello,
>
> Richard Kim writes:
>
> > A patch is provided below which implements a new link type called "infoi"
> > as a complement to "info" type that exist already.
>
> Thanks for your patch.
>
> > Why new link type? Because info index is almost always finer grain
> > than info nodes. For example [[infoi:libc#close]] brings up not only
> > "(libc)Opening and Closing Files" info node, but also place the cursor
> > on the line that documents "open" function within the node. Hence it
> > is more useful to link function, variable and other names that are in
> > the index. Most info documents have very rich indexes.
>
> OK. I would have preferred to merge both features into the same link
> type, but I see no elegant syntax to distinguish between a node and an
> index search.
>
> > I am not familiar with org coding style, so I share this patch to
> > present the idea rather than as a finished patch that can be checked
> > in. I assume that name changes and other changes will be needed prior
> > to being acceptable for check in assuming that the idea is ok.
>
> The idea is OK. Some comments follow.
>
> > org-info.el: Add new link type "infoi" that looks up info file index.
>
> No full stop at the end of the summary.
>
> > * lisp/org-info.el (org-info-index-open): New function to implement
> > new link type named "infoi".
>
> "New function" is enough here.
>
> You can describe the motivation behind the patch farther in the commit
> message, after another blank line.
>
> > +;;; info-index
> > +
> > +(org-add-link-type "infoi" 'org-info-index-open)
> > +
> > +(declare-function Info-index "info" (topic))
> > +
> > +(defun org-info-index-open (name)
> > + "Follow an Info file and look up index item specified by NAME."
> > + (if (or (string-match "\\(.*\\)[#:]:?\\(.*\\)" name)
> > + (string-match "\\(.*\\)" name))
> > + (let ((nodename (match-string 2 name)))
> > +(require 'info)
> > +(Info-find-node (match-string 1 name) "Top")
> > +(if nodename ; If there isn't a node, choose "Top"
> > +(Info-index nodename)))
>
> Prefer `when' over one-armed `if'.
>
> > +(message "Could not open: %s" name)))
>
> This introduce some code duplication in "org-info.el". Could you factor
> it out?
>
>
> Regards,
>
> --
> Nicolas Goaziou
>
From c850804267f343d020f91499e18cbde84a3fb897 Mon Sep 17 00:00:00 2001
From: Kim
Date: Sun, 9 Nov 2014 19:43:18 -0800
Subject: [PATCH] Enhanced org-info-follow-link to attempt index lookup if node
lookup fails.
Info index is almost always finer grain than info nodes. For example
with this change, [[info:libc#close]] brings up not only
"(libc)Opening and Closing Files" info node, but also place the cursor
on the line that documents "close" function within the node. This is
done by looking up "close"in the index upon failing to find a node
named "close". Hence one can now link function, variable and other
names that are in the index rather than being limited to info node
names. Typically there are far more index items than there are node
names. For example libc manual has about 700 nodes, but over
4000 concept, type, function, and variables index items.
---
doc/org.texi | 2 +-
lisp/org-info.el | 15 +++
2 files changed, 12 insertions(+), 5 deletions(-)
diff --git a/doc/org.texi b/doc/org.texi
index db1490a..08e071d 100644
--- a/doc/org.texi
+++ b/doc/org.texi
@@ -3575,7 +3575,7 @@ gnus:group@r{Gnus group link}
gnus:group#id @r{Gnus article link}
bbdb:R.*Stallman @r{BBDB link (with regexp)}
irc:/irc.com/#emacs/bob @r{IRC link}
-info:org#External links @r{Info node link}
+info:org#External links @r{Info node or index link}
shell:ls *.org@r{A shell c
Re: [O] 'remembering' not quite working right.
Sharon Kimble writes: > I am able to 'remember' text with highlighting the text required, and > copying it to the clipboard, and then "C-c r" remembers it, and shows in > its popup buffer that I need to "C-c C-c" to copy/move it to my remember > storage file. Except, the last bit doesn't work for me, instead it > calls the "Tag" command which opens "Tag: " in the mini-buffer which > just sits and waits for some response. > > When I 'remember' something, this shows in its buffer - > > # C-c C-c "~/.emacs.d/org/remember.org" -> "* Interesting" > # C-u C-c C-c like C-c C-c, and immediately visit note at target location > # C-0 C-c C-c "???" -> "* ???" > # C-1 C-c C-c to select file and header location interactively. > # C-2 C-c C-c as child (C-3: as sibling) of the currently clocked item > # To switch templates, use `M-x org-remember'. To abort use `C-c C-k'. > > How then can I get it working right please? > Remember (ha!) that org-remember is obsolete, replaced by org-capture. -- Nick
Re: [O] Org and ledger
I have been curious too and found this file: https://bitbucket.org/blais/beancount/src/tip/examples/tutorial/example.beancount Eric S Fraga schrieb am Sun, 09. Nov 13:29: On Sunday, 9 Nov 2014 at 11:34, Daniel Clemente wrote: [...] I prefer beancount (very similar to ledger but stricter): beancount supports org out of the box! My beancount file is an org file (with structure, tasks, priorities, agenda, etc. except :CLOCK:) and it parses correctly as a ledger. Interesting. Could you post an example file? The documentation you linked to on Google docs does not mention org anywhere that I could see. thanks. -- : Eric S Fraga (0xFFFCF67D), Emacs 25.0.50.1, Org release_8.3beta-475-g25d50e -- mit freundlichen Grüßen Bernhard Pröll
