Re: [O] [PATCH] * lisp/ob-core.el (org-babel-execute-src-block): insert hash for silent results
2013ko martxoak 8an, Eric Schulte-ek idatzi zuen: > > I would agree. I don't believe *any* changes should take place in the > buffer when a code block is executed with ":results none". A common use case for me is to use a babel block to load a large dataset into R. I want this to be cached, in the sense that I want it not to be run again (by e.g. C-c C-v C-b) unless the code changes. But I also don’t want to see its result in the (mini)buffer. Is there a way to accommodate this usage of the cache functionality? > I prefer leaving the hash with the results, as it is the results which > are "hashed". Also, same input does not always guarantee same output, > e.g., > > #+begin_src sh > date > #+end_src In this case, the code block shouldn’t be marked :cache. Unless the desired (and odd, IMO) behavior is to have a datestamp that is only updated when the user forcibly re-evaluates the block (with C-u C-c C-c). Also, with regard to: > The hyphen should only be required for multi-word functions, e.g., > `listp' has no hyphen but `hash-table-p' does have a hyphen. The context surrounding this code binds cache-p; the lack of a hyphen was just a typo in the patch. I agree that cachep is more idiomatic (in fact, that is what led to the typo), but I tried to make the smallest possible patch to address my intention. -- Aaron Ecay
Re: [O] org-exp-bibtex missing in git?
Hi Rasmus,
2013ko martxoak 7an, Rasmus Pank Roulund-ek idatzi zuen:
>
> In my book it would seem 'natural' to strive towards the following:
>
> 1. It should be Bibtex-based. I.e. Bibtex should be the 'database'
> or storage for citation information. It may be stored in
> Org-Bibtex-whatever, but Bibtex should be the natural base.
> 2. Citation selection should be possible via Reftex.
In principle this is true, but I think RefTeX is deeply intertwined with
the assumption that it is running in a LaTeX buffer. Going through its
code and making it major-mode-agnostic is a worthy project all of its
own. But it might take less effort and be more long-run maintainable to
just wire up the bibtex.el bundled with emacs, CompletionUI
(http://www.emacswiki.org/CompletionUI) and YAsnippet
(http://emacswiki.org/emacs/Yasnippet).
> 3. It should look nice in the buffer. For instance, with the
> current link hacks I am shown the pre or post notes in place of
> the citation. Ideally, it should be able to specify a
> reftex-cite-format string on how to display stuff in the buffer.
> Notes should be viewable in an non-disturbing way.
> Ideally, I would want to see something like:
>(POSTFIX, Jensen, 1906, SUFFIX)
> or
>Jensen (POSTFIX, 1906, SUFFIX)
> (If my memory serves me correctly this is how BibLatex places
> notes).
One could do this with font-lock and the new citation syntax I proposed
in my other email. We would need two alists. One would pair citation
lookup types with functions to resolve them to a location, and to get
their properties. The other would pair display types with two
functions: one to return a format string that would be displayed by
font-lock instead of the citation markup, and one to return the code to
export the citation.
So, a citation like [cite:doi:parens:some-doi:key=val&key2=val2] would be
displayed by:
1. call (org-lookup-cite-doi "some-doi") -> (:author "Foo" :title "bar" ...)
2. call (org-display-cite-parens '(:author "Foo" :title "bar" ...)) ->
"(Foo 2000)"
3. (font-lock puts an overlay over the citation markup, with the
returned string)
If you click on the citation, org would open the location (URL or local
file) returned by (org-resolve-cite-doi "some-doi")
A citation could exported by calling (org-export-cite-parens 'doi
"some-doi" (:author "foo" :title "bar") current-backend). This function
could just return \parencite{foo} if exporting to latex and the citation
was already in a bibtex file. But it could also just return “Foo 2000”
as a static string for dumb backends like ASCII, or write the
information to a temporary bibtex file (so that latex can atomatically
use the bibliographic info looked up from a DOI citation).
In any event, this is a big, complicated project. Step zero for me (and
many people, I guess) is to get a slightly less hackish way to export
Bibtex-based citations to latex, and the other pieces can be built on
top of that.
--
Aaron Ecay
Re: [O] org-exp-bibtex missing in git?
Hello Bastien (et al), 2013ko martxoak 7an, Bastien-ek idatzi zuen: > > Hi Nicolas, > > I like Aaron's idea (maybe others proposed this too) of having > parameters in links: > > [[file:my.bib::key&&prenote=my prenote&&postnote=my postnote]] > > [[http://perdu.com&&title=You're lost?]] > > This is orthogonal to my proposal of extending #+LINK to be able > to define new protocols (by allowing to add a follow and an export > functions); and this is orthogonal to whether link abbrevs can have > more than one formatting string %s. > > We would just need to pass the parameters as keywords to the export > function, either the default one, either the defined by the protocol. > > E.g., the first link would be represented by the parser like this: > >(:type "file" > :path "my.bib" > :raw-link "file:orgmode.org::test2" > :application nil > :search-option "test2" > :parameters '(:title "You're lost") > :begin 63 > :end 97 > :contents-begin 90 > :contents-end 95 > :post-blank 0 > :parent #3) This is now implemented, in the first of three patches attached to this email. The second patch is a reworked version of the bibliography support in my last patch, and the third implements link attributes for HTML links. To Nicolas: > I think that if we ever implement a bibliography/citations handlers, > they should be first class objects in Org syntax (like footnotes). > Overloading link syntax would, IMO, be wrong in that case. Do you have a proposal for how this syntax would look? You certainly know the parser very well, so you probably have an idea of what will work and not conflict with other things. I think minimally we need to include info on: - how to look up the citation (DOI, arXiv id, in a bibtex file, ...) - how to display/export the citation (parens, footnote, in-text, ...) - a list of properties (incl. at least pre- and post-note) - (of course) the citation key So maybe: [cite:lookup-type:display-type:key:prop1=val1,prop2=val2] Alternatively, the lookup-type and display-type could just be made properties, as long as there is a clear notion of what the default for these should be. >From 69e7a98a2f8044362597de31789b43b955e1fc7a Mon Sep 17 00:00:00 2001 From: Aaron Ecay Date: Fri, 8 Mar 2013 13:31:38 -0500 Subject: [PATCH 1/3] Add support for link properties MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit * lisp/org-element.el (org-element-link-parser): include :properties in plist of parsed link * lisp/org.el (org-make-link-string): don’t escape properties * lisp/ox-html.el (org-html-link) lisp/ox-latex.el (org-latex-link): pass link properties to org-link-protocols functions The properties of a link are appended to the link path, separated by the string “&&”. Each property should have the form key=val. No escaping is applied to key or val, and they must not contain an “=” character. The properties of a link are passed as the optional fourth argument to export functions defined by org-add-link-type and org-link-protocols. (Currently only for the HTML and LaTeX backends). --- lisp/org-element.el | 18 ++ lisp/org.el | 15 +-- lisp/ox-html.el | 3 ++- lisp/ox-latex.el| 3 ++- 4 files changed, 27 insertions(+), 12 deletions(-) diff --git a/lisp/org-element.el b/lisp/org-element.el index 6810b98..b944ffd 100644 --- a/lisp/org-element.el +++ b/lisp/org-element.el @@ -2982,7 +2982,7 @@ Assume point is at the beginning of the link." (save-excursion (let ((begin (point)) end contents-begin contents-end link-end post-blank path type - raw-link link search-option application) + raw-link link search-option application properties) (cond ;; Type 1: Text targeted from a radio target. ((and org-target-link-regexp (looking-at org-target-link-regexp)) @@ -2998,9 +2998,18 @@ Assume point is at the beginning of the link." ;; abbreviation in it. raw-link (org-translate-link (org-link-expand-abbrev - (org-match-string-no-properties 1))) - link (org-link-unescape raw-link)) - ;; Determine TYPE of link and set PATH accordingly. + (org-match-string-no-properties 1 + (when (string-match "&&" raw-link) + (let ((components (split-string raw-link "&&")) + p) + (setq raw-link (nth 0 components)) + (dolist (prop (cdr components)) + (setq p (split-string prop "=")) + (setq properties (plist-put properties + (intern (concat ":" (nth 0 p))) + (nth 1 p)) +(setq link (org-link-unescape raw-link)) +;; Determine TYPE of link and set PATH accordingly. (cond ;; File type. ((or (file-name-absolute-p link) (string-match "^\\.\\.?/" link)) @@ -3058,6 +3067,7 @@ Assume point is at the beginning of the link." :raw-link (or raw-link path) :application application :search-option search-option + :properties properties :begin begin :end
Re: [O] [BUG] attr_latex in new exporter
Hi Thomas, I think the following patch (on top of current master) will fix the problem: -cut-here- diff --git c/lisp/ox-latex.el w/lisp/ox-latex.el index d17dd60..eefb272 100644 --- c/lisp/ox-latex.el +++ w/lisp/ox-latex.el @@ -1811,9 +1811,9 @@ used as a communication channel." ;; It is possible to specify width and height in the ;; ATTR_LATEX line, and also via default variables. (width (format "%s" (cond ((plist-get attr :width)) - ((eq float 'figure) "0.7\\textwidth") + ((plist-get attr :height) "") + ((eq float 'figure) "0.7\\textwidth") ((eq float 'wrap) "0.48\\textwidth") - ((plist-get attr :height) "") (t org-latex-image-default-width (height (format "%s" (cond ((plist-get attr :height)) ((or (plist-get attr :width) -cut-here- Nicolas, I’m not sure I understand the logic behind (memq float '(figure wrap)) in the cond for setting height. I think that it would be very rare for someone to set the default height to something other than "", but in the event that the user does so I don’t see why it shoudl make a difference whether the image is floating or not. -- Aaron Ecay
Re: [O] org-exp-bibtex missing in git?
2013ko martxoak 6an, Bastien-ek idatzi zuen:
> I'd suggest to treat org-link-abbrev-alist and locally defined
> abbreviated links differently when opening the link at point and
> when exporting the buffer.
>
> At expand time, the exporter could attach a list of export functions
> (filters?) to the expanded link, depending on the local setting for
> the abbreviated link or `org-link-abbrev-alist'. For example:
>
> #+LINK: cite file:my.bib::%s org-latex-bibtex-link
>
> (setq org-link-abbrev-alist
>'(("cite" "file:my.bib::%s" 'org-latex-bibtex-link)))
>
> Then org-latex-bibtex-link would internally find the link, process
> the BibTeX entry and return a sensible \cite{...} string.
>
> What do you think?
I’m not sure I understand this proposal correctly. Specifically, the
exporter needs to know to insert a link to the bib file in the header of
the document (for BibLaTeX, this is the \addbibresource command); I’m
not sure where that information would come from in this proposal: would
the backend have to inspect the value of ‘org-link-abbrev-alist’?
I’ve got some mostly-working code that exports citations, only for
latex, using a different approach (similar to Eric’s). I’ve cleaned it
up some, and attached it as a patch to this email. It uses the
following syntax for links: [[type:key;pre;post][desc]]. I agree with
Eric that an expanded syntax for encoding pre and post citation commands
would be welcome. This code does insert the commands to load the bibtex
file(s) into the document’s header. It shoudl support multiple bib
files, as well as setting the file with an EXPORT_BIBLIOGRAPHY property
on a subtree, though I haven’t tested either of those functions
thoroughly. It also supports following a link to either a bibtex file
or (if you manage your bibliography with org-bibtex) an org file.
Things it doesn’t yet do:
- automatically insert the latex code to print the bibliography (because
I couldn’t think of a way to do this customizably enough – someone
might want to have the bibliography at the end, not at the end, one
bibliography per section, ...)
- automatically insert the proper \usepackage into the header. I think
the code should eventually do this, but Nicolas might disagree that
that should instead go into org-latex-classes.
Obviously this code needs work, but perhaps it can be a base on which to
build. Supporting non-biblatex latex packages is an obvious low-hanging
fruit. Support for HTML could probably come from citeproc-js
(https://bitbucket.org/fbennett/citeproc-js/wiki/Home), but I will leave
work on that to someone who is more familiar with HTML/JS/the ox-html
backend than I.
>From 044f84632ecf8518184f45802a97a9fa91f9a6d6 Mon Sep 17 00:00:00 2001
From: Aaron Ecay
Date: Thu, 7 Mar 2013 00:22:07 -0500
Subject: [PATCH] Support export of bibliography links (WIP)
---
lisp/ox-bib.el | 108 +++
lisp/ox-latex.el | 8 +
lisp/ox.el | 1 +
3 files changed, 117 insertions(+)
create mode 100644 lisp/ox-bib.el
diff --git a/lisp/ox-bib.el b/lisp/ox-bib.el
new file mode 100644
index 000..d726e31
--- /dev/null
+++ b/lisp/ox-bib.el
@@ -0,0 +1,108 @@
+(require 'bibtex)
+(require 'ox)
+
+(defvar ox-bib-find-entries-in-org-file nil
+ "Whether to look for bibliogrpahy entries in an org mode file
+or a bibtex file.")
+
+(defun ox-bib-get-bibliography ()
+ (mapcar (lambda (s)
+(org-no-properties s))
+ ;; Don't explode if before the first headline
+ (or
+ (condition-case nil
+ (plist-get (org-export-get-environment nil t) :bibliography)
+ (error nil))
+ (save-excursion
+ (widen)
+ (goto-char (point-min))
+ (plist-get (org-export-get-environment) :bibliography)
+
+(defun ox-bib-get-key (path &optional desc)
+ "Extract cite key from a link path and desc.
+
+Currently expects links in the format:
+\[[type:key;pre;post;][desc]]"
+ (nth 0 (split-string path ";")))
+
+(defun ox-bib-get-pre (path &optional desc)
+ "Extract pre-citation arg from a link path and desc.
+
+Currently expects links in the format:
+\[[type:key;pre;post;][desc]]"
+ (or (nth 1 (split-string path ";")) ""))
+
+(defun ox-bib-get-post (path &optional desc)
+ "Extract post-citation arg from a link path and desc.
+
+Currently expects links in the format:
+\[[type:key;pre;post;][desc]]"
+ (or (nth 2 (split-string path ";")) ""))
+
+;; Adapted from org-find-entry-with-custom-id; there might be a better
+;; way to do this
+(defun org-find-entry-with-custom-id (ident)
+ (let ((id ident)
+(case-fold-search nil))
+(save-excursion
+ (save-restriction
+(widen)
+(goto-char (point-min))
+(when (re-search-forward
+ (concat "^[ \t]*:CUSTOM_ID:[ \t]+" (regexp-quote id) "[ \t]*$")
+ nil t)
+ (org-back-to-heading t)
+ (point))
+
+(defun ox-bib-cite-follow (
Re: [O] [PATCH] ox-latex: provide width and height options for images
2013ko otsailak 27an, Nicolas Goaziou-ek idatzi zuen:
> Thank you for your patch. Here are a few comments.
Thank you for the comments! I think the patch is simpler and better
thanks to them.
>
>> These are implemented with \resizebox, and thus are uniform across
>> different types of image inclusion (\includegraphics, \input of tikz
>> images). This differs from the older way of using width and height
>> optional args to \includegraphics.
>
> I tend to agree with Rasmus. It would be better to keep height and
> width options in \includegraphics when possible.
Okay.
>
>> Thus, the default value for org-latex-image-default-options is left
>> untouched, to avoid breaking compatibility with older code. After a
>> transition period, the 0.9\linewidth value should be moved into
>> org-latex-image-default-width, and the -options variable set to the
>> empty string.
>
> We don't need this precaution. The exporter code for 8.0 introduced
> many incompatibilities already. Also, this one is easy to discover.
Okay.
>
> I think it's a good step forward. It will need to be documented in the
> comments at the beginning of ox-latex.el, where all attributes
> properties relative to different syntactical elements are explained.
Okay – see what you think of the documentation in the new patch.
>
> Here, you can obtain \resizebox{!}{!}{%s}, which is wrong, isn't it?
No...it is a no-op. That said, the code should no longer do this.
>
> This needs to be changed as these options would interfere with :width
> argument. For example, (eq float 'float) could set :width property if
> it is undefined. Obviously, this means the check has to be done before
> WIDTH and HEIGHT strings are built.
This should now be handled. The new patch will follow this email. In
related news, I have completed the FSF copyright assignment process, so
the patch can be merged whenever it is deemed ready.
Thanks again,
--
Aaron Ecay
