Re: [O] Custom column environment in beamer export
Hi Nicolas, On Tue, Jun 16, 2015 at 01:57:06PM +0200, Nicolas Goaziou wrote: Rasmus ras...@gmx.us writes: Unfortunately, BEAMER_OPTs are wrapped in square brackets thanks to org-beamer--normalize-argument, so the above won't actually work (see org-beamer--format-block). From the looks of it I'd be willing to call it a bug, but Nicolas may have had something in mind. IIRC it was a pre-8.0 feature already. In any case, it allows sloppy writing for options, i.e., with or without square brackets. Yes, I think so. Perhaps these days it would be nice to allow the third element of org-beamer-environments-extra to be a λ taking either the object or so. Then again, perhaps this is an overkill and too low-level. More simply, we can also add placeholders in templates, e.g., %R raw action specification %O raw options argument Indeed, that would work well I think. One can wrap the raw arguments anyway you wish in the template. Cheers, -- Suvayu Open source is the future. It sets us free.
Re: [O] Trouble passing variables into shell blocks on windows
On Sun 14 Jun 2015, Johan W. Klüwer wrote: I'm having difficulties passing org variables into shell source blocks. This is using Windows 7 and Cygwin with bash shell. For instance, the following #+BEGIN_SRC sh :var x=. ls $x #+END_SRC fails with the error message (as displayed in emacs) ls: cannot access .^M^M : No such file or directory As far as I can see, the first ^M stems from org-babel-sh-var-quote-fmt, and the second from org-babel-expand-body:generic, but I haven't been able to figure out a solution. Any suggestions? I can reproduce this using the native Windows build of emacs. If you are using cygwin tools, consider using a cygwin build of emacs, which will not suffer from this problem. If you running an X server then the cygwin emacs-X11 package is what you need. If you don't want to run an X server then the emacs-w32 package may fit your needs (a cygwin native build of emacs that uses the Windows GUI for display). HTH, AndyM
Re: [O] Tangling takes long - profiling and calling R
Nicolas Goaziou m...@nicolasgoaziou.fr writes: Rainer M Krug rai...@krugs.de writes: I would not remove it as even I have some org files using them - shame on me. To be clear, are we talking of constructs such as: --8---cut here---start-8--- ** Subtree :PROPERTIES: :tangle: no :END: --8---cut here---end---8--- ? We can check for that in Org Lint and warn the user. But what about making it user configurable? a variable ~org-babel-tangle-use-deprecated-header-args~ which if set to non-nil would enable this additional code, if nil it would be skipped? The default should be set to ~t~ to be backward compatible. This looks like backward-compatibility hell to me. If we make it conditional the feature is no longer deprecated, is it? I understand your point, and I'm enclined to agree with you (for a long-term sanity and stability of the mode we all cherish) -- even if I dunno yet if I still use such (Well, if this is the above structure, then, yes, I use it a lot as well...). The more general question is: how many years do we need to wait before removing a deprecated (i.e., marked as such) feature? Your suggestion with Org-lint, or even writing a function that would convert from the old to the new syntax, makes a shorter period acceptable IMO. Best regards, Seb -- Sebastien Vauban
Re: [O] Custom column environment in beamer export
Hello, Rasmus ras...@gmx.us writes: Unfortunately, BEAMER_OPTs are wrapped in square brackets thanks to org-beamer--normalize-argument, so the above won't actually work (see org-beamer--format-block). From the looks of it I'd be willing to call it a bug, but Nicolas may have had something in mind. IIRC it was a pre-8.0 feature already. In any case, it allows sloppy writing for options, i.e., with or without square brackets. Perhaps these days it would be nice to allow the third element of org-beamer-environments-extra to be a λ taking either the object or so. Then again, perhaps this is an overkill and too low-level. More simply, we can also add placeholders in templates, e.g., %R raw action specification %O raw options argument WDYT? Regards, -- Nicolas Goaziou
Re: [O] Links
Hello,
Fabrice Popineau fabrice.popin...@gmail.com writes:
Assume the following file :
[...]
** First link
[...]
** Second link
[2015-06-16 mar. 13:58]
- [[First%20link][First link]]
[...]
The exporter fails to resolve the (fuzzy) link First%20link.
However, if I click on the link, I jump to the right heading.
Am I missing something or should this be made consistent ?
You are not missing something, but making it consistent is not as
trivial as it sounds.
The problem is that, AFAIK, we cannot tell if a given string is
url-encoded or not. Also, url-encoding is not idempotent.
So, export process doesn't url-decode links, and cannot handle the link
above. OTOH, `org-open-at-point' assumes links are url-encoded (and they
are if you stored them with `org-store-link') so it url-decodes the link
above and is able to follow it.
I think it would be a mistake to expect all links to be url-encoded as
it is a pain when you enter most of your internal links manually.
However, forbidding url-encoding for internal links is also a mistake
because some of them cannot be expressed otherwise (e.g., headlines
containing square brackets). The current situation is also problematic,
of course. Well.
At this point, it seems that all is left are cheesy approaches. E.g,
when a path matches %[A-Za-z0-9]\\{2\\}, decode it during export. This
leaves pathological cases (e.g., when you really meant, for some very
good reason, to have a headline called * %25), though. That's not
great either.
WDYT?
Regards,
--
Nicolas Goaziou
Re: [O] Tangling takes long - profiling and calling R
Hello, Sebastien Vauban sva-news-D0wtAvR13HarG/idocf...@public.gmane.org writes: To be clear, are we talking of constructs such as: ** Subtree :PROPERTIES: :tangle: no :END: ? Yes, we are. Your suggestion with Org-lint, or even writing a function that would convert from the old to the new syntax, makes a shorter period acceptable IMO. What about the following check, which could be integrated in Org Lint: (defun check-deprecated-babel-properties () (interactive) (let ((deprecated-babel-properties (mapcar (lambda (arg) (symbol-name (car arg))) org-babel-common-header-args-w-values))) (org-element-map (org-element-parse-buffer 'element) 'node-property (lambda (p) (let ((key (org-element-property :key p))) (when (member-ignore-case key deprecated-babel-properties) (error Deprecated Babel property \%s\ at line %d. Use :header-args: instead key (save-excursion (goto-char (org-element-property :begin p)) (org-current-line) Regards, -- Nicolas Goaziou
[O] Links
Hi, I think I need some refresh on what's valid and what is not. Assume the following file : #+TITLE: Foo #+DATE: 2014-11-19 01:10:58 * FOO [2015-06-16 mar. 13:58] Lorem ipsum dolor sit amet, consectetuer adipiscing elit. Donec hendrerit tempor tellus. Donec pretium posuere tellus. Proin quam nisl, tincidunt et, mattis eget, convallis nec, purus. Cum sociis natoque penatibus et magnis dis parturient montes, nascetur ridiculus mus. Nulla posuere. Donec vitae dolor. Nullam tristique diam non turpis. Cras placerat accumsan nulla. Nullam rutrum. Nam vestibulum accumsan nisl. * BAR [2015-06-16 mar. 13:58] ** First link [2015-06-16 mar. 13:58] Lorem ipsum dolor sit amet, consectetuer adipiscing elit. Donec hendrerit tempor tellus. Donec pretium posuere tellus. Proin quam nisl, tincidunt et, mattis eget, convallis nec, purus. Cum sociis natoque penatibus et magnis dis parturient montes, nascetur ridiculus mus. Nulla posuere. Donec vitae dolor. Nullam tristique diam non turpis. Cras placerat accumsan nulla. Nullam rutrum. Nam vestibulum accumsan nisl. ** Second link [2015-06-16 mar. 13:58] - [[First%20link][First link]] - [[file:sample.org][sample.org]] - [[http://www.google.com][Google]] The exporter fails to resolve the (fuzzy) link First%20link. However, if I click on the link, I jump to the right heading. Am I missing something or should this be made consistent ? Fabrice
Re: [O] Links
2015-06-16 14:50 GMT+02:00 Nicolas Goaziou m...@nicolasgoaziou.fr:
Hello,
So, export process doesn't url-decode links, and cannot handle the link
above.
This is what I was missing :-)
At this point, it seems that all is left are cheesy approaches. E.g,
when a path matches %[A-Za-z0-9]\\{2\\}, decode it during export. This
leaves pathological cases (e.g., when you really meant, for some very
good reason, to have a headline called * %25), though. That's not
great either.
WDYT?
I don't know what is realistic. I see the tradeoffs are tight.
Ideally, url encoded links should have been prefixed with some kind of uri
syntax.
This way, you could know what to decode and what not.
Now, I guess the heuristic you propose would be fine in most cases.
I don't see that people will put a lot of percentages in their links.
Thanks for the explanations !
Fabrice
Regards,
--
Nicolas Goaziou
Re: [O] Custom column environment in beamer export
Rasmus ras...@gmx.us writes: The third argument is hard-coded to 'option in org-beamer--format-block ATM. ox-beamer expects options to be wrapped within square brackets. If they are not, it does that task. This is a bit drastic, but it works well in practice. Indeed. That's the incremental fix. Done in cf5fd31f0c4f18bd0256157adb98306d53f8a52c. Regards,
Re: [O] Custom column environment in beamer export
Hi, Nicolas Goaziou m...@nicolasgoaziou.fr writes: Unfortunately, BEAMER_OPTs are wrapped in square brackets thanks to org-beamer--normalize-argument, so the above won't actually work (see org-beamer--format-block). From the looks of it I'd be willing to call it a bug, but Nicolas may have had something in mind. IIRC it was a pre-8.0 feature already. In any case, it allows sloppy writing for options, i.e., with or without square brackets. The third argument is hard-coded to 'option in org-beamer--format-block ATM. Perhaps these days it would be nice to allow the third element of org-beamer-environments-extra to be a λ taking either the object or so. Then again, perhaps this is an overkill and too low-level. More simply, we can also add placeholders in templates, e.g., %R raw action specification %O raw options argument WDYT? Indeed. That's the incremental fix. Rasmus -- 9000!
Re: [O] Tangling takes long - profiling and calling R
Envoyé de mon iPhone Le 16 juin 2015 à 14:45, Sebastien Vauban sva-n...@mygooglest.com a écrit : Nicolas Goaziou m...@nicolasgoaziou.fr writes: Rainer M Krug rai...@krugs.de writes: I would not remove it as even I have some org files using them - shame on me. To be clear, are we talking of constructs such as: --8---cut here---start-8--- ** Subtree :PROPERTIES: :tangle: no :END: --8---cut here---end---8--- ? We can check for that in Org Lint and warn the user. But what about making it user configurable? a variable ~org-babel-tangle-use-deprecated-header-args~ which if set to non-nil would enable this additional code, if nil it would be skipped? The default should be set to ~t~ to be backward compatible. This looks like backward-compatibility hell to me. If we make it conditional the feature is no longer deprecated, is it? I understand your point, and I'm enclined to agree with you (for a long-term sanity and stability of the mode we all cherish) -- even if I dunno yet if I still use such (Well, if this is the above structure, then, yes, I use it a lot as well...). The more general question is: how many years do we need to wait before removing a deprecated (i.e., marked as such) feature? Your suggestion with Org-lint, or even writing a function that would convert from the old to the new syntax, makes a shorter period acceptable IMO. I don't think that it is that easy, as the new syntax is not equivalent to the old syntax. One example; defining one tangle target for the mother tree, and others for the child trees. This is by no means trivial (or even possible) with the new syntax, while it would be possible with the old syntax (if I remember correctly). So for backward compatibility, the support should stay, but one had to enable it explicitly. Cheers, Rainer Best regards, Seb -- Sebastien Vauban
Re: [O] Custom column environment in beamer export
On Tue, Jun 16, 2015 at 03:33:03PM +0200, Nicolas Goaziou wrote:
Rasmus ras...@gmx.us writes:
Indeed. That's the incremental fix.
Done in cf5fd31f0c4f18bd0256157adb98306d53f8a52c.
Works great! I went with this template:
(add-to-list 'org-beamer-environments-extra
'(minipage m \\begin{minipage}%O{%R} \\end{minipage}%))
For my use case, I rarely use overlay actions, so I repurposed it for
environment arguments.
Thanks a lot!
PS: OT, within beamer I find minipage is easier to manage than columns.
--
Suvayu
Open source is the future. It sets us free.
Re: [O] Tangling takes long - profiling and calling R
Envoyé de mon iPhone Le 16 juin 2015 à 13:46, Nicolas Goaziou m...@nicolasgoaziou.fr a écrit : Rainer M Krug rai...@krugs.de writes: I would not remove it as even I have some org files using them - shame on me. We can check for that in Org Lint and warn the user. That would be a really good idea! But what about making it user configurable? a variable ~org-babel-tangle-use-deprecated-header-args~ which if set to non-nil would enable this additional code, if nil it would be skipped? The default should be set to ~t~ to be backward compatible. This looks like backward-compatibility hell to me. If we make it conditional the feature is no longer deprecated, is it? The more general question is: how many years do we need to wait before removing a deprecated (i.e., marked as such) feature? Before deleting it, one should get a warning that a certain feature is deprecated. At the moment, it is only mentioned in the help (as far as I am aware). Regards,
[O] org-publish-project yields Eager macro-expansion failure
Hello. Frequently, when I try to org-publish-project, I get a Eager macro-expansion failure The message buffer and backtrace are available here: https://gist.github.com/julienchastang/98b268e9601882d8d81c Indeed, I can simply reproduce this problem by calling (load-with-code-conversion path/elpa/org-20150615/ox-html.el path/elpa/org-20150615/ox-html.el nil t) which gets called somewhere in the org-publish-project invocation (see backtrace). So I am concluding the error has nothing to do with my project. What can I do to publish my project again? Many thanks. -- Julien Chastang Scientific Software Developer Unidata-UCAR
Re: [O] [RFC] Org linting library
Rainer M Krug rai...@krugs.de writes: something along the line of Link to non-existent local file ... in the description part would make clear that it is ion the description of a link. Done. Thanks. Regards,
Re: [O] Tangling takes long - profiling and calling R
Rainer M Krug r.m.k...@gmail.com writes: We can check for that in Org Lint and warn the user. That would be a really good idea! Done. Before deleting it, one should get a warning that a certain feature is deprecated. At the moment, it is only mentioned in the help (as far as I am aware). It has been mentioned in the manual for the last two years. See footnote in (info (org)Header arguments in Org mode properties). Regards,
Re: [O] Links
Fabrice Popineau fabrice.popin...@gmail.com writes: Ideally, url encoded links should have been prefixed with some kind of uri syntax. This way, you could know what to decode and what not. The encoded link could be copied from somewhere else. Also, there are numerous links in the wild without this prefix. Now, I guess the heuristic you propose would be fine in most cases. I don't see that people will put a lot of percentages in their links. I pushed something along these lines in master. It should solve your initial issue. Thank you. Regards,
Re: [O] current status of citation syntax discussion
Matt Price mopto...@gmail.com writes: Is the discussion stalled out then? What would have to happen to move it along? Everybody got time constrains. Mine are binding severely at the moment (not that I have contributed org-cite code). I think it will be more of a priority after org 8.3. -- The Kids call him Billy the Saint
[O] Bug with label names in beamer export
Hi,
I encountered a strange problem today, exporting to beamer didn't
produce any pages eventhough it compiled just fine! It turns out it's
how Org exported the labels. They should be wrapped in {..}. See this
TeX.SX question for more: http://tex.stackexchange.com/q/250640/4416
The attached patch should fix the issue.
Cheers,
--
Suvayu
Open source is the future. It sets us free.
From e82cd7bf86dc01d1038a442fd66ba8b97ec7a23e Mon Sep 17 00:00:00 2001
From: Suvayu Ali fatkasuvayu+li...@gmail.com
Date: Tue, 16 Jun 2015 21:04:21 +0200
Subject: [PATCH] ox-beamer: Wrap labels in braces in beamer export
* lisp/ox-beamer.el (org-beamer--get-label): wrap labels in {..}
The `:' in the label name causes an argument parsing problem, for more
see http://tex.stackexchange.com/q/250640/4416.
---
lisp/ox-beamer.el | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/lisp/ox-beamer.el b/lisp/ox-beamer.el
index dafadb3..3119bd4 100644
--- a/lisp/ox-beamer.el
+++ b/lisp/ox-beamer.el
@@ -337,7 +337,7 @@ function assumes HEADLINE will be treated as a frame.
(if (and (stringp opt)
(string-match \\(?:^\\|,\\)label=\\(.*?\\)\\(?:$\\|,\\) opt))
(match-string 1 opt)
- (concat sec: (org-export-get-reference headline info)
+ (format {sec:%s} (org-export-get-reference headline info)
(defun org-beamer--frame-level (headline info)
Return frame level in subtree containing HEADLINE.
--
2.4.3
Re: [O] Bug with label names in beamer export
Rasmus ras...@gmx.us writes:
I like sec:, but the only package that actually relies on this, on the
top of my head, is autoref. I prefer {sec:whatever} over
sec-whatever.
OK. Let's keep it this way then. Thanks.
Regards,
Re: [O] current status of citation syntax discussion
On Jun 16, 2015 3:51 PM, Rasmus ras...@gmx.us wrote:
Matt Price mopto...@gmail.com writes:
Am just wondering what the current status is of the work that was being
done earlier this year on improved citation support in org. Has an
official syntax been settled on?
AFAIK: No. Some people wanted something like [cite/type: pre @key post].
Some people wanted additional key-value support, something like
[cite: pre @key post]{:key val}. Some people wanted @key
to be able to contain arbitrary characters such as punctuation.
Is the discussion stalled out then? What would have to happen to move it
along?
Are there blessed citation managers and export solutions?
ox-bibtex supports \cite{key} and I think [[cite:key]].
I would like to figure out a personal system over the summer, and would
prefer to adhere to whatever stand(s) others have settled on.
There's about as many systems as there are org users. I use
[[citetype: pre @key post]].
(hmm, are spaces allowed in pre and post? If so how is the expression
parsed? )
If it's not too much trouble, could you provide some examples of code you
use to
- generate cite links
- export those links to (preferably non-latex) formats
?
Thanks as always,
Matt
Rasmus
--
May the Force be with you
And with you.
Re: [O] Bug with label names in beamer export
Hello,
Rasmus ras...@gmx.us writes:
Suvayu Ali fatkasuvayu+li...@gmail.com writes:
The attached patch should fix the issue.
Pushed, thanks. I changed the commit message slightly.
* lisp/ox-beamer.el (org-beamer--get-label): wrap labels in {..}
You don't need the lisp/ prefix. Capitalize after the colon. Should
end with period.
Thanks. Nitpick however: wouldn't it be more readable to use sec- as
a prefix instead of sec: in order to solve the issue?
Regards,
--
Nicolas Goaziou
Re: [O] current status of citation syntax discussion
Hello, Matt Price mopto...@gmail.com writes: Is the discussion stalled out then? What would have to happen to move it along? There is a wip-cite branch in the git repo with basic Org syntax for citations. We're mainly waiting for implementations making use of it, on both export and references management side. Regards, -- Nicolas Goaziou
Re: [O] Bug with label names in beamer export
Nicolas Goaziou m...@nicolasgoaziou.fr writes:
Thanks. Nitpick however: wouldn't it be more readable to use sec- as
a prefix instead of sec: in order to solve the issue?
I like sec:, but the only package that actually relies on this, on the
top of my head, is autoref. I prefer {sec:whatever} over sec-whatever.
Rasmus
--
Dobbelt-A
Re: [O] org-cite and org-citeproc
On Mon, Apr 6, 2015 at 2:51 PM, Richard Lawrence
richard.lawre...@berkeley.edu wrote:
Hi Aaron and all,
Richard Lawrence richard.lawre...@berkeley.edu writes:
Alright, I'll try to move to json.el, and possibly change to having
org-citeproc generate Org markup in the meantime.
Just a heads up: I've pushed some changes to my branch of Org to make
org-cite use json.el, and to add a basic Org format writer to
org-citeproc.
I have not made any other changes to org-cite to use the Org formatted
output from org-citeproc, though, as I believe doing this properly will
involve parsing the output and inserting it into Org's exporter's parse
tree (to accommodate the bibliography and note-based styles). I won't
have time to work on that this week, but I'll come back to it.
Best,
Richard
Hi Richard et al,
I'm wondering what kind of work is required to make use of org-cite and
org-citeproc at present. In particular, I'm wondering what kinds of changes
I'll need to make to my current setup, and whether it's worthwhile to use
my ultra-slow coding skills to create whatever glue is still necessary.
Here's my setup at present:
I currently use Zotero for most of my bibliography management; it's
relatively easy to get zotero to export a bibtex bibliography (cf.
https://github.com/robintw/AutoZotBib), and I will switch to bibtex if
absolutely necessary. I'd rather just keep using Zotero, though.
I use zotxt-emacs to insert references in org files.
I export my work to html and odt. I use this small bit of code to manage
exports:
;; zotxt
(org-add-link-type zotero
(lambda (rest)
(zotxt-select-key (substring rest 15)))
(lambda (path desc format)
(if (string-match ^@\\(.*\\)$ desc)
(cond ((eq format 'latex)
(format \\cite{%s} (match-string 1 desc)))
((eq format 'md)
desc)
((eq format 'html)
(deferred:$
(zotxt-get-item-bibliography-deferred
`(:key , (substring path 15)))
(deferred:nextc it
(lambda (item)
(plist-get item :citation-html)))
(deferred:sync! it)))
((eq format 'odt)
(deferred:$
(zotxt-get-item-deferred `(:key ,
(substring path 15)) :248bebf1-46ab-4067-9f93-ec3d2960d0cd)
(deferred:nextc it
(lambda (item)
(plist-get item
:248bebf1-46ab-4067-9f93-ec3d2960d0cd)))
(deferred:sync! it)))
(t nil)
nil
currently this grabs a full html citation and pastes it into the html
export, while for odt it produces strings of the form { | Herzig, 2006 | |
|zotero://select/items/0_SKDIF737}, which Zotero can understand withthe aid
of an RDF/ODF scan plugin.
All of this is fine for my current purposes, but I would like to figure out
a more flexible and enduring solution, so I'd like to try out org-cite and
org-citeproc. But I'm not quite sure what's required, and whether there's
support currently for odt and html export.
Thanks very much for your help,
Matt
Re: [O] Bug with label names in beamer export
Suvayu Ali fatkasuvayu+li...@gmail.com writes:
The attached patch should fix the issue.
Pushed, thanks. I changed the commit message slightly.
* lisp/ox-beamer.el (org-beamer--get-label): wrap labels in {..}
You don't need the lisp/ prefix. Capitalize after the colon. Should
end with period.
Rasmus
--
Slowly unravels in a ball of yarn and the devil collects it
Re: [O] current status of citation syntax discussion
Matt Price mopto...@gmail.com writes:
Am just wondering what the current status is of the work that was being
done earlier this year on improved citation support in org. Has an
official syntax been settled on?
AFAIK: No. Some people wanted something like [cite/type: pre @key post].
Some people wanted additional key-value support, something like
[cite: pre @key post]{:key val}. Some people wanted @key
to be able to contain arbitrary characters such as punctuation.
Are there blessed citation managers and export solutions?
ox-bibtex supports \cite{key} and I think [[cite:key]].
I would like to figure out a personal system over the summer, and would
prefer to adhere to whatever stand(s) others have settled on.
There's about as many systems as there are org users. I use
[[citetype: pre @key post]].
Rasmus
--
May the Force be with you
Re: [O] Organizing and taming hectic Academia work (faculty viewpoint)? Tips or a good guides sought after :)
On 16/06/15 11:49, Bob Newell wrote: Julian Burgos jul...@hafro.is writes: b) I write the manuscript in org-mode. Then I send the org-mode file to my coauthor. Because the org-mode file is just a text file, my coauthor can use Word to edit it. I ask him/her *not* to use track changes and to save the edited version also as a text file. Then, when I receive it I use ediff in emacs to compare both documents and incorporate the edits I want. Simple is best, and I wish I had thought of this simple idea before I took an 87,000 word novel that I wrote in org-mode, output as ODT, converted to DOCX, and then sent to an editor. I got back all the track changes stuff and even worse, margin notes, and punctuation (like quotes and ellipses) changed over to Word-ish characters. It wasn't utterly useless but it created a lot of extra work, which still isn't over. Next time I'll do as per above, tell her to just edit the thing directly, write her notes in-line, and keep it as pure ASCII. I really believe she thinks I was going to use Word to publish the novel. Failure to communicate on my part. I could say lack of judgment on her part but that's unfair; in her world, most everyone uses Word at some stage in the process. I used this method when working with an editor on the last edition of my book on banking law: almost 300,000 words. I had a few special constructs that I asked her not to meddle with, and she put editors notes in-line. It worked a treat although the publisher actually required Word files at the end. Cheers, Alan -- Alan L Tyreehttp://www2.austlii.edu.au/~alan Tel: 04 2748 6206 sip:typh...@iptel.org
[O] Why navigating in Org mode is so slow in overview mode?
Hello everyone, I am view this file http://doc.norang.ca/org-mode.org It's a prettey long document, when it all folded up, navigating to previous line and next line takes about 2 seconds. When the sub heading is shown, it's more responsive. Is this a bug? Thank you!
Re: [O] org-ref helm-bibtex notes
Yeah, helm bibtex is awesome. This has been a major topic of discussion in the module development. See: https://github.com/tmalsburg/helm-bibtex/issues/40 Last I talked with the developer, he was thinking hard about it and had maybe even started development on single-note file options. Julian Burgos jul...@hafro.is writes: Dear list, I have been using org-ref for a while, using reftex to insert citations in my org documents. Now I am switching to helm-bibtex, which is pretty awesome. I have a couple of question about the note files. Org-ref uses a single file to keep notes (e.g. notes.org), but helm-bibtex assumes that notes are kept in separate files, one per article. My questions are: a) Do you have a preference in the single file vs multiple files question? Are advantages/disadvantages? I tend to prefer the single file option, it makes search easy and also I can add TODO items that later I can pull out in the agenda view. With multiple files this would not be as easy. Do you agree? b) Helm-bibtex identifies which references have a note file, adding a symbol on the reference list. Can we make helm-bibtex look into a single file (say the notes.org file), look for the :Custom_ID: properties of the entries, and use that to mark the reference list? I am teaching myself emacs-lisp but this is above my capacity right now. Many thanks, Julian
Re: [O] org-ref helm-bibtex notes
Julian Burgos writes: Dear list, I have been using org-ref for a while, using reftex to insert citations in my org documents. Now I am switching to helm-bibtex, which is pretty awesome. I have a couple of question about the note files. Org-ref uses a single file to keep notes (e.g. notes.org), but helm-bibtex assumes that notes are kept in separate files, one per article. My questions are: a) Do you have a preference in the single file vs multiple files question? Are advantages/disadvantages? I tend to prefer the single file option, it makes search easy and also I can add TODO items that later I can pull out in the agenda view. I prefer the single file, for the reasons you describe. With multiple files this would not be as easy. Do you agree? This is not totally true. You can add your directory of org notes to your org-agenda-files, e.g. (setq org-agenda-files '(~/path/to/org-notes)) and it will add all org files in that directory to your agenda. If you use helm, it is probably easy to search all of the files too. -- Professor John Kitchin Doherty Hall A207F Department of Chemical Engineering Carnegie Mellon University Pittsburgh, PA 15213 412-268-7803 @johnkitchin http://kitchingroup.cheme.cmu.edu
Re: [O] org-ref helm-bibtex notes
On 2015-06-16 Tue 17:39, Julian Burgos wrote: Dear list, I have been using org-ref for a while, using reftex to insert citations in my org documents. Now I am switching to helm-bibtex, which is pretty awesome. I have a couple of question about the note files. Org-ref uses a single file to keep notes (e.g. notes.org), but helm-bibtex assumes that notes are kept in separate files, one per article. My questions are: a) Do you have a preference in the single file vs multiple files question? Are advantages/disadvantages? I tend to prefer the single file option, it makes search easy and also I can add TODO items that later I can pull out in the agenda view. With multiple files this would not be as easy. Do you agree? Hi, I’m the author of helm-bibtex. There was recently a discussion about this on Github: https://github.com/tmalsburg/helm-bibtex/issues/40 Someone convinced me that storing all notes in one file is better and there is an experimental (and incomplete) implementation in a topic branch: https://github.com/tmalsburg/helm-bibtex/tree/note-files (Multiple note files will still be possible for users who prefer that.) b) Helm-bibtex identifies which references have a note file, adding a symbol on the reference list. Can we make helm-bibtex look into a single file (say the notes.org file), look for the :Custom_ID: properties of the entries, and use that to mark the reference list? I am teaching myself emacs-lisp but this is above my capacity right now. Yes, something like that needs to be included. The unresolved question is how BibTeX keys should be stored in the notes file. I find property drawers incredibly clunky and in my experience they can considerably slow down Emacs in large org files (that’s the reason why I don’t use org-contacts as much as a would like). My current favorite format for entries in the notes file is the following: * Author: Title (year) :BibTeXkey: Here are the notes … The only problem I see with this is that BibTeX allows keys to contain colons, and a key with a colon would break org’s tag syntax. Suggestions welcome. Titus Many thanks, Julian signature.asc Description: PGP signature
Re: [O] Why navigating in Org mode is so slow in overview mode?
It slows everything, even change buffer takes about 2 seconds. And all this slowness disappear when the buffer is unfolded.
[O] org-ref helm-bibtex notes
Dear list, I have been using org-ref for a while, using reftex to insert citations in my org documents. Now I am switching to helm-bibtex, which is pretty awesome. I have a couple of question about the note files. Org-ref uses a single file to keep notes (e.g. notes.org), but helm-bibtex assumes that notes are kept in separate files, one per article. My questions are: a) Do you have a preference in the single file vs multiple files question? Are advantages/disadvantages? I tend to prefer the single file option, it makes search easy and also I can add TODO items that later I can pull out in the agenda view. With multiple files this would not be as easy. Do you agree? b) Helm-bibtex identifies which references have a note file, adding a symbol on the reference list. Can we make helm-bibtex look into a single file (say the notes.org file), look for the :Custom_ID: properties of the entries, and use that to mark the reference list? I am teaching myself emacs-lisp but this is above my capacity right now. Many thanks, Julian
Re: [O] bug in ox-koma-letter
Hello,
· Nicolas Goaziou m...@nicolasgoaziou.fr wrote:
Hello,
Rasmus ras...@gmx.us writes:
Thomas Holst thomas_ho...@gmx.de writes:
when I try to export an subtree with koma letter I get the following
error:
cond: Symbol's value as variable is void: with-title
This seems to be related to the following commit:
d3196f0 * ox-koma-letter: Fix missing \begin{document}
because if I switch to the commit prior to this one (6463b6c *
ox-koma-letter: Fix typo in docstring) everything works
fine and I don't get an error.
Emacs Version: 24.3.1 on Ubuntu 12.04
org-version: most recent git
Can you please provide a minimal example that triggers the bug from
emacs -q? I'm unable to produce it with the example from org (with one
extra outer level).
My bad. Fixed in bfe1b2fbe2baa62cd26bf9a76077e56a9c243075.
I can confirm that export with koma letter works again.
Thank you.
--
Bis neulich ...
Thomas
Re: [O] Tangling takes long - profiling and calling R
Charles C. Berry ccbe...@ucsd.edu writes: On Mon, 15 Jun 2015, Rainer M Krug wrote: Hi I have a relatively large file with about 200 =source blocks (R) to be tangled to get an R package. But the tangling takes about 20 seconds. Profiling the tangling showed that the call to ~mapcar~ in ~org-babel-params-from-properties~ takes about 40% of the execution time (see profiler excerpt below). Is there anything one can do to make this faster? In addition to this, I observed there is some interaction with ESS when tangling, which in my understanding is not necessary. I get messages like , | ... | Wrote /Users/rainerkrug/Documents/Projects/EnergyBalance/.Rbuildignore | Wrote /Users/rainerkrug/Documents/Projects/EnergyBalance/tests/wpLELTest.R | You are developing: (EnergyBalance) | Wrote /Users/rainerkrug/Documents/Projects/EnergyBalance/R/plotwpLELFitListParDistr.R | You are developing: (EnergyBalance) | ... ` where the messages You are developing: (EnergyBalance) come from ESS. Is this to be expected that R is called for some blocks, but not for others, when tangling? The major mode is invoked when tangling, if possible. This enables comments to be rendered. See the docstring for `org-babel-spec-to-string'. HTH, Yes - thanks, Rainer Chuck -- Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology, UCT), Dipl. Phys. (Germany) Centre of Excellence for Invasion Biology Stellenbosch University South Africa Tel : +33 - (0)9 53 10 27 44 Cell: +33 - (0)6 85 62 59 98 Fax : +33 - (0)9 58 10 27 44 Fax (D):+49 - (0)3 21 21 25 22 44 email: rai...@krugs.de Skype: RMkrug PGP: 0x0F52F982 signature.asc Description: PGP signature
Re: [O] Tangling takes long - profiling and calling R
Nicolas Goaziou m...@nicolasgoaziou.fr writes: Hello, Rainer M Krug rai...@krugs.de writes: I have a relatively large file with about 200 =source blocks (R) to be tangled to get an R package. But the tangling takes about 20 seconds. Profiling the tangling showed that the call to ~mapcar~ in ~org-babel-params-from-properties~ takes about 40% of the execution time (see profiler excerpt below). Is there anything one can do to make this faster? In this function, there is ;; DEPRECATED header arguments specified as separate property at ;; point of definition (let (val sym) (org-babel-parse-multiple-vars (delq nil (mapcar (lambda (header-arg) (and (setq val (org-entry-get (point) header-arg t)) (cons (intern (concat : header-arg)) (org-babel-read val (mapcar #'symbol-name (mapcar #'car (org-babel-combine-header-arg-lists org-babel-common-header-args-w-values (progn (setq sym (intern (concat org-babel-header-args: lang))) (and (boundp sym) (eval sym)) While the 3 `mapcar' calls could be turned into a single one, I wonder if this snippet could be removed altogether instead. It has been deprecated for 2 years already. WDYT? I would not remove it as even I have some org files using them - shame on me. But what about making it user configurable? a variable ~org-babel-tangle-use-deprecated-header-args~ which if set to non-nil would enable this additional code, if nil it would be skipped? The default should be set to ~t~ to be backward compatible. Cheers, Rainer Regards, -- Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology, UCT), Dipl. Phys. (Germany) Centre of Excellence for Invasion Biology Stellenbosch University South Africa Tel : +33 - (0)9 53 10 27 44 Cell: +33 - (0)6 85 62 59 98 Fax : +33 - (0)9 58 10 27 44 Fax (D):+49 - (0)3 21 21 25 22 44 email: rai...@krugs.de Skype: RMkrug PGP: 0x0F52F982 signature.asc Description: PGP signature
Re: [O] Specifying ATTR_LATEX document wide?
Nicolas Goaziou m...@nicolasgoaziou.fr writes: Rainer M Krug rai...@krugs.de writes: Thanks for the clarification. Is there a technical or security reason for this? because especially for export, file local variables would make sense to avoid the #+BIND keywords? ISTR there is a technical reason for this. Under some circumstances, local variables are not activated during export. I cannot remember which ones, unfortunately. Thanks for the info. Also, unlike to local variables, BIND keywords can be set through SETUPFILE keywords. Oh the SETUPFILE - have never thought about that one. Thanks, Rainer Regards, -- Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology, UCT), Dipl. Phys. (Germany) Centre of Excellence for Invasion Biology Stellenbosch University South Africa Tel : +33 - (0)9 53 10 27 44 Cell: +33 - (0)6 85 62 59 98 Fax : +33 - (0)9 58 10 27 44 Fax (D):+49 - (0)3 21 21 25 22 44 email: rai...@krugs.de Skype: RMkrug PGP: 0x0F52F982 signature.asc Description: PGP signature
Re: [O] Custom column environment in beamer export
On Tue, Jun 16, 2015 at 12:30:09AM +0200, Rasmus wrote:
Suvayu Ali fatkasuvayu+li...@gmail.com writes:
* Fitting technique :B_minipage:
:PROPERTIES:
:BEAMER_env: minipage
:BEAMER_arg: 0.1\linewidth
:END:
+/cFit/+
The closest would probably be something like
(add-to-list 'org-beamer-environments-extra
'(minipage
m
\\begin{minipage}%o%a\n\\structure{%h}
\\end{minipage}))
Which would afford you something like
* slide
** Fitting technique:B_minipage:
:PROPERTIES:
:BEAMER_env: minipage
:BEAMER_OPT: [t]{0.1\linewidth}
:BEAMER_ACT: 5
:END:
/cFit/
Well, I would rather keep the formatting in the org file, so no
\structure in the template. But otherwise your suggestion seems exactly
what I need :).
Unfortunately, BEAMER_OPTs are wrapped in square brackets thanks to
org-beamer--normalize-argument, so the above won't actually work (see
org-beamer--format-block). From the looks of it I'd be willing to call it
a bug, but Nicolas may have had something in mind.
I was thinking the same. That's why I felt the need for the old
BEAMER_arg property!
Perhaps these days it would be nice to allow the third element of
org-beamer-environments-extra to be a λ taking either the object or so.
Then again, perhaps this is an overkill and too low-level.
This might be nice, but as you say could be overkill. Although, there
are a few other cases which is harder to use with the current syntax.
Take minipage as an example, it takes 3 optional arguments[1].
Presently there is no way of dealing with something like that. Removing
the autowrapping of brackets would allow such cases, but it would
probably break a few Org files in the wild. From that perspective, a
lambda might be the way to go.
Personally, I'd use a block, e.g.
#+attr_latex: :options [t]{.1\textwidth}
#+begin_minipage
Cfit
#+end_minipage
Nice idea. I have never really explored using blocks (other than for
raw latex), maybe I should ...
Thanks,
Footnotes:
[1] https://en.wikibooks.org/wiki/LaTeX/Boxes#minipage_and_parbox
--
Suvayu
Open source is the future. It sets us free.
Re: [O] Tangling takes long - profiling and calling R
Rainer M Krug rai...@krugs.de writes: I would not remove it as even I have some org files using them - shame on me. We can check for that in Org Lint and warn the user. But what about making it user configurable? a variable ~org-babel-tangle-use-deprecated-header-args~ which if set to non-nil would enable this additional code, if nil it would be skipped? The default should be set to ~t~ to be backward compatible. This looks like backward-compatibility hell to me. If we make it conditional the feature is no longer deprecated, is it? The more general question is: how many years do we need to wait before removing a deprecated (i.e., marked as such) feature? Regards,
Re: [O] How to make footnotes be fnlocal by default?
Hello, William Denton w...@pobox.com writes: Attached is a tiny patch to add mention of this variable in the section of the docs where all those options are listed. Thank you. Would you mind using git format-patch for it and add a proper commit message? Also, wouldn't it make sense to use @vindex org-footnote-section in the paragraph above? Regards, -- Nicolas Goaziou
